From nobody Thu May 1 00:03:36 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6161A0A15 for ; Thu, 1 May 2014 00:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioDvFm3Z48Jx for ; Thu, 1 May 2014 00:03:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id AF28A1A0A29 for ; Thu, 1 May 2014 00:03:30 -0700 (PDT) Received: from BL2PR03CA021.namprd03.prod.outlook.com (10.141.66.29) by BL2PR03MB228.namprd03.prod.outlook.com (10.255.231.21) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 07:03:26 +0000 Received: from BL2FFO11FD036.protection.gbl (2a01:111:f400:7c09::169) by BL2PR03CA021.outlook.office365.com (2a01:111:e400:c1b::29) with Microsoft SMTP Server (TLS) id 15.0.929.12 via Frontend Transport; Thu, 1 May 2014 07:03:27 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD036.mail.protection.outlook.com (10.173.161.132) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Thu, 1 May 2014 07:03:26 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.63]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0174.002; Thu, 1 May 2014 07:02:56 +0000 From: Mike Jones To: "Hollenbeck, Scott" , Brian Campbell Thread-Topic: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-25 Thread-Index: AQHPU2RzcJshBhie6kap9ZpttPs22psrbfmQ Date: Thu, 1 May 2014 07:02:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439A1A145A@TK5EX14MBXC288.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.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439A1A145ATK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(438001)(377454003)(51914003)(51444003)(189002)(199002)(24454002)(13464003)(15202345003)(77982001)(66066001)(92566001)(92726001)(86612001)(46102001)(20776003)(16236675002)(80022001)(33656001)(74662001)(512954002)(74502001)(31966008)(86362001)(85852003)(2656002)(79102001)(97736001)(83072002)(2009001)(84326002)(84676001)(81542001)(50986999)(99396002)(76176999)(54356999)(15975445006)(6806004)(4396001)(19300405004)(19580405001)(19580395003)(83322001)(44976005)(55846006)(76482001)(87936001)(81342001)(71186001)(80976001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB228; H:mail.microsoft.com; FPR:DA2EF23F.AFF2501D.32E37FC9.4326FD6A.2031E; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01986AE76B Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/zkQQoZ0kX6u8BO4RJVnXtl-xMxE Cc: "Kaliski, Burt" , "jose@ietf.org" Subject: Re: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-25 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:03:34 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439A1A145ATK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-3= .4 has been augmented to clarify that the R and S representations conform t= o SEC1. I hope that this addresses the issue that you raised, Scott. And = thanks for the useful follow-up comments, Brian. Thanks all, -- Mike From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Tuesday, April 08, 2014 12:43 PM To: Mike Jones Cc: Hollenbeck, Scott; jose@ietf.org; Kaliski, Burt Subject: Re: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorit= hms-25 But that section (6.2.1.2) is about the EC parameters x and y in JWK. The c= omment was about the ECDSA signature values R & S in section 3.4 for JWS. I= believe that Scott is correct in saying that it is currently ambiguous and= could be clarified. I think that left zero padding is what was intended an= d what most of us have (eventually) inferred should be done. But it should = probably be stated explicitly. On Mon, Apr 7, 2014 at 3:57 PM, Mike Jones > wrote: Thanks for the useful reviews, Scott and Burt. Replies are inline. -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On = Behalf Of Hollenbeck, Scott Sent: Friday, April 04, 2014 5:43 PM To: jose@ietf.org Cc: Kaliski, Burt Subject: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-= 25 Sec. 3.4: For ECDSA P-521 SHA-512, as noted, "R and S will be 521 bits eac= h, resulting in a 132-octet sequence." Unclear how R and S are to be conve= rted into respective 66-octet values (pad with 0 bits on the left versus ri= ght). Should be consistent with practice in other specifications, e.g., IE= EE 1363. Per http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#secti= on-6.2.1.2, this is specified by the SEC1 specification, which the "x" and = "y" definitions reference. (SEC1 specifies padding on the left in Section = 2.3.1 - "BitString-to-OctetString Conversion".) --_000_4E1F6AAD24975D4BA5B16804296739439A1A145ATK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://too= ls.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-3.4 has been augmented to clarify that the R and S representations conform to = SEC1.  I hope that this addresses the issue that you raised, Scott.&nb= sp; And thanks for the useful follow-up comments, Brian.<= /p>

 <= /p>

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

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

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Tuesday, April 08, 2014 12:43 PM
To: Mike Jones
Cc: Hollenbeck, Scott; jose@ietf.org; Kaliski, Burt
Subject: Re: [jose] WG Last Call Comments: draft-ietf-jose-json-web-= algorithms-25

 

But that section (6.2.1.2) is about the EC parameter= s x and y in JWK. The comment was about the ECDSA signature values R & = S in section 3.4 for JWS. I believe that Scott is correct in saying that it= is currently ambiguous and could be clarified. I think that left zero padding is what was intended and what most of us ha= ve (eventually) inferred should be done. But it should probably be stated e= xplicitly.

 

On Mon, Apr 7, 2014 at 3:57 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Thanks for the useful reviews, Scott and Burt.  Replies are inline.

-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Hollenbeck, Scott
Sent: Friday, April 04, 2014 5:43 PM
To: jose@ietf.org Cc: Kaliski, Burt
Subject: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-= 25

Sec. 3.4:  For ECDSA P-521 SHA-512, as noted, "R and S will be= 521 bits each, resulting in a 132-octet sequence."  Unclear how = R and S are to be converted into respective 66-octet values (pad with 0 bit= s on the left versus right).  Should be consistent with practice in other specifications, e.g., IEEE 1363.

 

Per http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#sec= tion-6.2.1.2, this is specified by the SEC1 specification, which the “x” and= “y” definitions reference.  (SEC1 specifies padding on th= e left in Section 2.3.1 – “BitString-to-OctetString Conversion&= #8221;.)

--_000_4E1F6AAD24975D4BA5B16804296739439A1A145ATK5EX14MBXC288r_-- From nobody Thu May 1 00:10:46 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB41A0A25 for ; Thu, 1 May 2014 00:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Qjra_52TzV for ; Thu, 1 May 2014 00:10:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) by ietfa.amsl.com (Postfix) with ESMTP id ABC711A0A24 for ; Thu, 1 May 2014 00:10:38 -0700 (PDT) Received: from DM2PR03CA010.namprd03.prod.outlook.com (10.141.52.158) by DM2PR03MB558.namprd03.prod.outlook.com (10.141.83.155) with Microsoft SMTP Server (TLS) id 15.0.921.12; Thu, 1 May 2014 07:10:35 +0000 Received: from BL2FFO11FD014.protection.gbl (2a01:111:f400:7c09::136) by DM2PR03CA010.outlook.office365.com (2a01:111:e400:2414::30) with Microsoft SMTP Server (TLS) id 15.0.929.12 via Frontend Transport; Thu, 1 May 2014 07:10:35 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Thu, 1 May 2014 07:10:34 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.63]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0174.002; Thu, 1 May 2014 07:09:11 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [jose] AD review of draft-ietf-jose-json-web-algorithms Thread-Index: AQHPWkx0MohT4foJy0+5ox2RzsAQFpsWAxPQgABOCICADI7/AIAAPl5QgAhEwzA= Date: Thu, 1 May 2014 07:09:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439A1A14A2@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439A15D3B1@TK5EX14MBXC286.redmond.corp.microsoft.com> <00db01cf5a82$db1c7f80$91557e80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739439A1971D7@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A1971D7@TK5EX14MBXC288.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_4E1F6AAD24975D4BA5B16804296739439A1A14A2TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(438001)(199002)(189002)(51704005)(51444003)(13464003)(43784003)(24454002)(377454003)(479174003)(164054003)(69224002)(46102001)(86612001)(4396001)(71186001)(20776003)(54356999)(74502001)(77982001)(92566001)(50986999)(31966008)(512874002)(66066001)(16297215004)(83072002)(19300405004)(80976001)(19580405001)(79102001)(85852003)(76482001)(83322001)(16236675002)(76176999)(15975445006)(99396002)(81342001)(80022001)(2656002)(33656001)(84326002)(2009001)(44976005)(81542001)(92726001)(87936001)(55846006)(74662001)(97736001)(86362001)(15202345003)(84676001)(19580395003)(6806004)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR03MB558; H:mail.microsoft.com; FPR:CE0CDDED.A3F2D3DD.7DDF3D4B.9AAAF960.209D1; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01986AE76B Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/WDELj8cyl3Vxp90FD3CdOrUQKo4 Cc: "jose@ietf.org" Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:10:44 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439A1A14A2TK5EX14MBXC288r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGFsZ29yaXRobSBuYW1lIOKAnFJTQS1PQUVQLTI1NuKAnSBmb3IgUlNBRVMgT0FFUCB1c2lu ZyBTSEEtMjU2IGFuZCBNR0YxIHdpdGggU0hBLTI1NiBoYXMgYmVlbiBhZGRlZCBhdCBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0y NiNzZWN0aW9uLTQuMywgcGVyIHlvdXIgcmVxdWVzdCwgS2F0aGxlZW4uDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogam9zZSBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IEZyaWRheSwgQXByaWwgMjUsIDIwMTQg NjozOCBQTQ0KVG86IEthdGhsZWVuIE1vcmlhcnR5OyBKaW0gU2NoYWFkDQpDYzogam9zZUBpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXNAdG9vbHMuaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbam9zZV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qc29uLXdl Yi1hbGdvcml0aG1zDQoNCg0KVGhhbmtzLCBLYXRobGVlbi4gIENvbW1lbnRzIGFyZSBpbmxpbmUs IG1hcmtlZCDigJxNaWtlPuKAneKApg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGpvc2UgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBL YXRobGVlbiBNb3JpYXJ0eQ0KU2VudDogRnJpZGF5LCBBcHJpbCAyNSwgMjAxNCAyOjA3IFBNDQpU bzogSmltIFNjaGFhZA0KQ2M6IE1pa2UgSm9uZXM7IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1h bGdvcml0aG1zQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt YWxnb3JpdGhtc0B0b29scy5pZXRmLm9yZz47IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2pvc2VdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItYWxnb3JpdGhtcw0KDQoNCg0KU29ycnkgZm9yIHRoZSBkZWxheSBpbiBteSByZXNw b25zZS4gIEknbGwgYW5zd2VyIGluLWxpbmUgYmVsb3cuDQoNCg0KDQpUaGFua3MhDQoNCg0KDQpP biBUaHUsIEFwciAxNywgMjAxNCBhdCA1OjIwIFBNLCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNl bGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gd3JvdGU6DQoNCj4NCg0K Pg0KDQo+DQoNCj4NCg0KPiBGcm9tOiBqb3NlIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNywg MjAxNCAxMDo0NiBBTQ0KDQo+IFRvOiBLYXRobGVlbiBNb3JpYXJ0eTsgam9zZUBpZXRmLm9yZzxt YWlsdG86am9zZUBpZXRmLm9yZz4NCg0KPiBDYzogZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFs Z29yaXRobXNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1h bGdvcml0aG1zQHRvb2xzLmlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFJlOiBbam9zZV0gQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zDQoNCj4NCg0KPg0KDQo+ DQoNCj4gVGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gZG8gdGhlIHJldmlldywgS2F0aGxl ZW4uICBSZXNwb25zZXMgYXJlDQoNCj4gaW5saW5lLCBmbGFnZ2VkIGJ5IOKAnE1pa2U+4oCdLiAg SSBhbHNvIHBhc3RlZCB5b3VyIGZvbGxvdy1vbiBub3RlIGluIGFuZA0KDQo+IHJlc3BvbmRlZCB0 byBpdCBhcyB3ZWxsLg0KDQo+DQoNCj4NCg0KPg0KDQo+IEZyb206IEthdGhsZWVuIE1vcmlhcnR5 IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQoNCj4gU2VudDogVGh1 cnNkYXksIEFwcmlsIDE3LCAyMDE0IDc6NTEgQU0NCg0KPiBUbzogam9zZUBpZXRmLm9yZzxtYWls dG86am9zZUBpZXRmLm9yZz4NCg0KPiBDYzogTWlrZSBKb25lczsgZHJhZnQtaWV0Zi1qb3NlLWpz b24td2ViLWFsZ29yaXRobXNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1hbGdvcml0aG1zQHRvb2xzLmlldGYub3JnPg0KDQo+IFN1YmplY3Q6IEFEIHJldmll dyBvZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcw0KDQo+DQoNCj4NCg0KPg0K DQo+IEhlbGxvIE1pa2UgJiBKT1NFIG1lbWJlcnMsDQoNCj4NCg0KPg0KDQo+DQoNCj4gSSBhbSB3 b3JraW5nIG15IHdheSB0aHJvdWdoIHRoZSByZXF1ZXN0ZWQgcmV2aWV3cyB0byBwcm9ncmVzcyB0 aGUgSk9TRQ0KDQo+IGRyYWZ0cyBhbmQgY2FuIHNlZSBhIGxvdCBvZiB3b3JrIGhhcyBiZWVuIGRv bmUsIHRoYW5rIHlvdS4gIEFzIEkgcmVhZA0KDQo+IHRocm91Z2ggdGhlIEFsZ29yaXRobXMgKEpX QSkgZHJhZnQgdGhlcmUgYXJlIHNvbWUgY2hhbmdlcyB0aGF0IHdpbGwNCg0KPiBuZWVkIHRvIGJl IG1hZGUgdG8gYXZvaWQgcHJvYmxlbXMgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIFRoaXMgaXMg YQ0KDQo+IHByZXR0eSBiaWcgY2hhbmdlIGZvciB0aGUgZHJhZnQsIGJ1dCB3aWxsIGhlbHAgbWFr ZSB0aGUgcmV2aWV3IGFuZCBhcHByb3ZhbCBmYXN0ZXIuDQoNCj4gVHlwaWNhbGx5LCB0aGUgbGlz dHMgb2YgYWxnb3JpdGhtcyBhcmUgaGFuZGxlZCB0aHJvdWdoIGEgZHJhZnQgdXBkYXRlDQoNCj4g YXMgb3Bwb3NlZCB0byBjcmVhdGluZyBhbiBJQU5BIHJlZ2lzdHJ5LiAgQSBnb29kIGV4YW1wbGUg aXMgYSByZWNlbnQNCg0KPiB1cGRhdGUgb2YgYSBkcmFmdCBpbiB0aGUgSVBTRUNNRSB3b3JraW5n IGdyb3VwIHNvIHlvdSBjYW4gc2VlIHRoZQ0KDQo+IHN0cnVjdHVyZSBhbmQgdGhlIHByZWNlZGVu Y2UgZm9yIHRoaXMgbW9kZWwuDQoNCj4NCg0KPg0KDQo+DQoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLWVzcC1haC1yZXF0cw0KDQo+DQoNCj4N Cg0KPg0KDQo+IE1pa2U+IFNvIHlvdeKAmXJlIHN1Z2dlc3RpbmcgdGhhdCBmdXR1cmUgSldBIGRy YWZ0cyBtaWdodCBvYnNvbGV0ZSB0aGUNCg0KPiBNaWtlPiBjdXJyZW50DQoNCj4gb25lLCBtdWNo IGxpa2UgZHJhZnQtaWV0Zi1pcHNlY21lLWVzcC1haC1yZXF0cyB3aWxsIG9ic29sZXRlIFJGQyA0 ODM1LA0KDQo+IHdoaWNoIG9ic29sZXRlZCBSRkMgNDMwNSwgZXRjLj8gIElmIHNvLCBjb3VsZCB3 b3JrIG9uIHJldmlzaW5nIHRoZSBKV0ENCg0KPiBkcmFmdCBhY2NvcmRpbmdseSBhbmQgc2VuZCBw cm9wb3NlZCBjaGFuZ2VzIHRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQo+DQoNCj4NCg0KS00+IEkg YW0gbm90IHN1cmUgd2hlcmUgSmltJ3MgcmVzcG9uc2UgaXMsIGJ1dCBJIGhhdmUgYmVlbiBsb29r aW5nDQoNCmludG8gdGhpcy4gIE15IGluaXRpYWwgbWVzc2FnZSBjYW1lIGFmdGVyIHNvbWUgY29u dmVyc2F0aW9ucyB3aXRoIFNlYW4uICBJbiByZXNwb25zZSB0byB5b3VyIHBvc3RzLCBJIHJlYWNo ZWQgb3V0IHRvIGEgY291cGxlIG9mIG90aGVyIEFEcyB3aG8gbWF5IGhhdmUgaGFkIGNvbmNlcm5z IGFuZCAqdGhpbmsqIHdlIGFyZSBva2F5IGFzIGxvbmcgYXMgdGhlIHJlZ2lzdHJpZXMgd2lsbCBi ZSB1c2VkIHdpdGggYSBkZXNpZ25hdGVkIGV4cGVydCByZXZpZXcgdG8gYWRkIHRvIHRoZSByZWdp c3RyeS4gIElmIGEgZHJhZnQgaXMgcmVxdWlyZWQgZm9yIGFuIHVwZGF0ZSwgdGhhdCB3b3VsZCBj YXVzZSBwcm9ibGVtcyBhcyBvcHBvc2VkIHRvIGEgZHJhZnQgd2l0aCBubyByZWdpc3RyaWVzLiAg U29ycnkgZm9yIHRoZSBjb25mdXNpb24gaGVyZS4NCg0KDQoNCk1pa2U+IEppbeKAmXMgcmVzcG9u c2UgaXMgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVu dC9tc2cwNDA3MS5odG1sLCBzdGFydGluZyB3aXRoIOKAnFtKTFNdIEthdGhsZWVuLCBJIGRvbuKA mXQga25vdyB0aGF0IEkgYWdyZWUgd2l0aCB0aGlzIHN0YXRlbWVudC4gIFRoZXJlIGFyZSBhIG51 bWJlciBvZiBkaWZmZXJlbnQgcGxhY2VzIHdoZXJlIElBTkEgcmVnaXN0cmllcyBhcmUgdXNlZCBm b3IgdGhlIHB1cnBvc2Ugb2YgaGF2aW5nIGxpc3RzIG9mIGFsZ29yaXRobXMu4oCdICBBbGwgdGhl IHJlZ2lzdHJpZXMgZXN0YWJsaXNoZWQgYWxyZWFkeSByZXF1aXJlIGV4cGVydCByZXZpZXcsIGFz IGRlc2NyaWJlZCBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItYWxnb3JpdGhtcy0yNSNzZWN0aW9uLTcuICBTbyBpdCBzb3VuZHMgbGlrZSB3ZSBz aG91bGQgYmUgT0suICBUaGF04oCZcyBnb29kLiAgVGhhbmtzIGZvciB3b3JraW5nIHRoZSBpc3N1 ZS4NCg0KDQoNCj4NCg0KPiBOb3cgZm9yIG90aGVyIGVkaXRzIGFuZCBxdWVzdGlvbnM6DQoNCj4N Cg0KPg0KDQo+DQoNCj4gU2VjdGlvbiAzLjYgLSBDYW4geW91IGV4cGxhaW4gd2h5IHdvdWxkIHRo aXMgYmUgaW5jbHVkZWQ/ICBJZiB5b3UgYXJlDQoNCj4gbm90IGdvaW5nIHRvIHNpZ24sIEkgYW0g bm90IHN1cmUgd2h5IG9uZSB3b3VsZCB1c2UgSk9TRSBhdCBhbGwuDQoNCj4NCg0KPg0KDQo+DQoN Cj4gTWlrZT4gVGhpcyBpcyBpbmNsdWRlZCB0byBlbmFibGUgcmVwcmVzZW50aW5nIGNvbnRlbnQg dGhhdCBpcw0KDQo+IE1pa2U+IG9wdGlvbmFsbHkNCg0KPiBzaWduZWQgaW4gcHJvdG9jb2xzIHVz aW5nIEpXUy4gIEhhdmluZyB0aGlzIG1lYW5zIHRoYXQgd2hldGhlciBvciBub3QNCg0KPiB0aGUg Y29udGVudCBpcyBzaWduZWQsIGl0IGNhbiB1c2UgYSB1bmlmb3JtIHJlcHJlc2VudGF0aW9uLCB3 aGljaCBpcw0KDQo+IGVhc3kgdG8gcGFyc2UuICBUaGlzIGlzIGluIHByb2R1Y3Rpb24gdXNlLCBm b3IgaW5zdGFuY2UsIHRvIGVuYWJsZQ0KDQo+IE9BdXRoIGF1dGhvcml6YXRpb24gcmVxdWVzdCBt ZXNzYWdlcyB0aGF0IGFyZSBvcHRpb25hbGx5IHNpZ25lZC4NCg0KPiBTb21ldGltZXMgY29udGVu dCBuZWVkIG5vdCBiZSBzaWduZWQgYXQgdGhlIEpXUyBsZXZlbCBiZWNhdXNlIGl04oCZcw0KDQo+ IGludGVncml0eSBwcm90ZWN0ZWQgYnkgb3RoZXIgcHJvdG9jb2wgbGF5ZXJzIOKAkyBpbiBwYXJ0 aWN1bGFyLCBvZnRlbiBieQ0KDQo+IHRoZSB1c2Ugb2YgVExTLiAgQW5vdGhlciB1c2UgY2FzZSBp cyB3aGVyZSBzaWduaW5nIGFkZHMgYWRkaXRpb25hbA0KDQo+IG9wdGlvbmFsIHZhbHVlLCBidXQg d2hlcmUgdGhlcmXigJlzIG5vIGhhcm0gaW4gdXNpbmcgdW5zaWduZWQgY29udGVudCDigJMNCg0K PiBmb3IgaW5zdGFuY2UsIHdoaWxlIG5vcm1hbCBPQXV0aCByZXF1ZXN0cyBhcmUgaW5saW5lIGFu ZCB1bnNpZ25lZCwgYQ0KDQo+IHJlZ2lzdGVyZWQgZXh0ZW5zaW9uIGVuYWJsZXMgcmVxdWVzdCBw YXJhbWV0ZXJzIHRvIGJlIHBhc3NlZCBieQ0KDQo+IHJlZmVyZW5jZSwgcmF0aGVyIHRoYW4gYnkg dmFsdWU7IHRoZSBvYmplY3QgcmVmZXJlbmNlZCBjb250YWluaW5nIHRoZQ0KDQo+IHBhcmFtZXRl cnMgaXMgYSBKV1M7IHRoZSBKV1MgY2FuIG9wdGlvbmFsbHkgYmUgc2lnbmVkLiAgVGhlIGN1cnJl bnQsDQoNCj4gY2FyZWZ1bGx5IHJlZmluZWQgdHJlYXRtZW50IG9mIOKAnG5vbmXigJ0gaXMgdGhl IHJlc3VsdCBvZiBzdWJzdGFudGlhbCBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbnMgYW5kIGRpc2N1 c3Npb25zIG9uIHdvcmtpbmcgZ3JvdXAgY2FsbHMuDQoNCj4gV2hpbGUgYSBsZXNzIHBhcmFsbGVs IHRyZWF0bWVudCBvZiB1bnNpZ25lZCBKV1NzIHdhcyBwcm9wb3NlZCBpbg0KDQo+IGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMzYsIHRoaXMgYWx0ZXJuYXRp dmUNCg0KPiBzeW50YXggd2FzIHJlamVjdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwIGluIGZhdm9y IG9mIHRoZSBjdXJyZW50IGFwcHJvYWNoLg0KDQo+DQoNCj4NCg0KS00+IEkgcmVzcG9uZGVkIHRv IFZsYWRhbWlyIG9uIHRoaXMgb25lIGFuZCB3b3VsZCBqdXN0IGxpa2UgdG8ga25vdyBpZg0KDQp0 aGVyZSBpcyBXRyBjb25zZW5zdXMgYmVoaW5kIHRoZSBkZWNpc2lvbi4gIENhbiB5b3UgcG9pbnQg bWUgdG8gZGlzY3Vzc2lvbnMgb24gdGhpcz8NCg0KDQoNCk1pa2U+IEJyaWFuIENhbXBiZWxsIGRp ZCBhIGdvb2Qgam9iIHN1bW1hcml6aW5nIHRoZSBjb25zZW5zdXMgaW4gaGlzIG5vdGUgaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDA4Mi5odG1s LiAgSmltIFNjaGFhZCBkb2N1bWVudGVkIHRoZSBjb25zZW5zdXMgaW4gaGlzIG5vdGUgY2xvc2lu ZyBpc3N1ZSAjMzYgYXQgdGhlIGVuZCBvZiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9q b3NlL3RyYWMvdGlja2V0LzM2Lg0KDQoNCg0KTWlrZT4gVGhpcyB3YXMgZXh0ZW5zaXZlbHkgZGlz Y3Vzc2VkIG9uIGEgdGhyZWFkIHRpdGxlZCDigJxbam9zZV0gIzM2OiBBbGdvcml0aG0gIm5vbmUi IHNob3VsZCBiZSByZW1vdmVk4oCdIGJldHdlZW4gNy8zMS8xMyBhbmQgOC8yMi8xMyBhbmQgdGhl biBhbHNvIG9uIGEgZm9sbG93LXVwIHRocmVhZCBuYW1lZCDigJxbam9zZV0gVGV4dCBhYm91dCBh cHBsaWNhdGlvbnMgYW5kICJhbGciOiJub25lIuKAnSBiZXR3ZWVuIDkvMy8xMyBhbmQgOS85LzEz LiAgVGhlIGxhdHRlciB0aHJlYWQgcmVzdWx0ZWQgZnJvbSBhbiBhY3Rpb24gaXRlbXMgZnJvbSB0 aGUgcHJlY2VkaW5nIGludGVyaW0gd29ya2luZyBncm91cCBjYWxsICh0aGUgYWdlbmRhIGZvciB3 aGljaCB3YXMgcHVibGlzaGVkIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50 ZXJpbS8yMDEzLzA4LzE5L2pvc2UvYWdlbmRhL2FnZW5kYS1pbnRlcmltLTIwMTMtam9zZS01KS4N Cg0KDQoNCk1pa2U+IFRoZSB0ZXh0IGFncmVlZCB0byBieSB0aGUgd29ya2luZyBncm91cCB0aGF0 IEJyaWFuIHJlZmVycmVkIHRvIHdhcyBhZGRlZCBpbiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt YWxnb3JpdGhtcy0xNiwgcHVibGlzaGVkIG9uIDkvMTUvMTMuICBKaW0gY2xvc2VkIHRoZSBpc3N1 ZSBvbiAxMC8yOC8xMy4NCg0KDQoNCj4NCg0KPiBTZWN0aW9uIDUuMiAtIFRoZSB3cml0ZSB1cCBv ZiB0aGlzIHNlY3Rpb24gc2VlbXMgYSBiaXQgbW9yZQ0KDQo+IGNvbXBsaWNhdGVkIHRoYW4gbmVj ZXNzYXJ5LiAgSXQgc2VlbXMgaXQgd291bGQgaGF2ZSBqdXN0IGJlZW4gc2ltcGxlcg0KDQo+IHRv IHN0YXRlIHRoYXQgdGhlIHNpemVzIHZhcnkgYXMgcmVxdWlyZWQgYnkgdGhlIGFsZ29yaXRobXMg YW5kIGtleQ0KDQo+IGxlbmd0aHMgdXNlZCByYXRoZXIgdGhhbiBwcm92aWRpbmcgdGhlIGRpZmZl cmVuY2VzIGZyb20gb25lIHRvIHRoZSBuZXh0LiAgQ2FuIHlvdSBzaW1wbGlmeSB0aGlzPw0KDQo+ DQoNCj4gQWZ0ZXIgbG9va2luZyB0aHJvdWdoIHNvbWUgb2YgdGhlIG1haWxpbmcgbGlzdCBkaXNj dXNzaW9ucywgaXQgc2VlbXMNCg0KPiB0aGVyZSB3YXMgYWxyZWFkeSBhZ3JlZW1lbnQgdG8gc2xp bSB0aGlzIGFuZCBvdGhlciBzZWN0aW9ucyBkb3duIGJ5DQoNCj4gcG9pbnRpbmcgdG8gdGhlIGRy YWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyDQoNCj4NCg0KPg0KDQo+DQoNCj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwMjI3Ni5o dG1sDQoNCj4NCg0KPiBDYW4gSSBnZXQgYW4gdXBkYXRlIGFzIHRvIHdoZXJlIHRoYXQgc3RhbmRz LCByZWZlcmVuY2luZyB3aGF0IHlvdSBjYW4NCg0KPiBmcm9tIHRoYXQgZHJhZnQgYXMgb3Bwb3Nl ZCB0byBkdXBsaWNhdGluZyB0ZXh0PyAgVGhhbmtzIQ0KDQo+DQoNCj4gTWlrZT4gU3VyZS4gIFRo ZSBrZXkgcGFydCBvZiB0aGUgbWVzc2FnZSB5b3UgY2l0ZWQgaXMg4oCcT25jZSB0aGUgTWNHcmV3 DQoNCj4gTWlrZT4gZHJhZnQNCg0KPiBoYXMgYmVlbiByZWZhY3RvcmVkIHRvIHNlcGFyYXRlIHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgY2FsY3VsYXRpb24NCg0KPiBzdGVwcyAod2hpY2ggSk9TRSBp cyB1c2luZykgZnJvbSB0aGUgQUVBRCByZXByZXNlbnRhdGlvbiBzdGVwcyAod2hpY2gNCg0KPiBK T1NFIGlzIG5vdCB1c2luZyksIGFuZCB0byBpbmNsdWRlIHRlc3QgdmVjdG9yIHZhbHVlcyB0aGF0 IHNob3cNCg0KPiByZXN1bHRzIHdpdGhvdXQgcGVyZm9ybWluZyB0aGUgQUVBRCByZXByZXNlbnRh dGlvbiBjb25jYXRlbmF0aW9ucywgSQ0KDQo+IGFncmVlIHRoYXQgd2UnbGwgYmUgYWJsZSB0byBq dXN0IHJlZmVyZW5jZSBpdCwgcmF0aGVyIHRoYW4gZHVwbGljYXRpbmcNCg0KPiBpdC7igJ0gIFRo ZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHJlZmFjdG9yaW5nIHdhcyBuZXZlciBkb25lLiAgVGhlDQoN Cj4gYWxnb3JpdGhtIGRlc2NyaXB0aW9uIGluDQoNCj4gZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNi Yy1obWFjLXNoYTIgaXMgd3JpdHRlbiBpbiBzdWNoIGEgd2F5IHRoYXQgdGhlDQoNCj4gY2lwaGVy dGV4dCBDLCBhcyBkZXNjcmliZWQsIGFsc28gaW5jbHVkZXMgdGhlIElWIHZhbHVlIGFzIGEgcHJl Zml4IGFuZA0KDQo+IHRoZSBhdXRoZW50aWNhdGlvbiB0YWcgVCBhcyBhIHN1ZmZpeCwgcmF0aGVy IHRoYW4gdHJlYXRpbmcgZWFjaCBvZg0KDQo+IHRob3NlIGFzIHNlcGFyYXRlIHZhbHVlcy4gIFRo ZSB0ZXN0IHZlY3RvcnMgZG8gdGhlIHNhbWUuICBZZXMsIERhdmlkDQoNCj4gYWRkZWQgYXBwZW5k aXggQiBzYXlpbmcgdGhhdCB0aGUgdmFsdWVzIGNvdWxkIGJlIHRyZWF0ZWQgYXMgc2VwYXJhdGUs DQoNCj4gYnV0IHRoZSB3cml0ZS11cCBkb2VzIG5vIGZhdm9ycyB0byBpbXBsZW1lbnRlcnMsIGFz IGJvdGggdGhlIGNvcmUNCg0KPiBhbGdvcml0aG0gZGVzY3JpcHRpb24gYW5kIHRoZSB0ZXN0IHZl Y3RvcnMgYXNzdW1lIHRoZXkgYXJlIGNvbWJpbmVkLg0KDQo+IChJIHBlcnNvbmFsbHkga25vdyB0 aGF0IHdvcmtpbmcgb3V0IGhvdyB0byB0cmVhdCB0aGVtIGFzIHNlcGFyYXRlIGZyb20NCg0KPiBE YXZpZOKAmXMgY3VycmVudCBkcmFmdCBpcyBhIHRlZGlvdXMgYW5kIGVycm9yLXByb25lIGV4ZXJj aXNlLCBoYXZpbmcNCg0KPiBoYWQgdG8gZG8gc28gdG8gdGVhc2UgdGhlbSBhcGFydCBmb3IgdGhl IGN1cnJlbnQgSldBIHdyaXRlLXVwLikgIERhdmlkDQoNCj4gaGFzIGJlZW4gYXNrZWQgYWJvdXQg ZG9pbmcgdGhlIHJlZmFjdG9yaW5nIHNldmVyYWwgdGltZXMgYnkgbXVsdGlwbGUNCg0KPiBwYXJ0 aWVzLCBidXQgaGXigJlzIGEgYnVzeSBndXksIGFuZCBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIGV2 ZXIgcmVhY2hlZCB0aGUNCg0KPiB0b3Agb2YgaGlzIHF1ZXVlLiAgQXMgaXQgaXMsIHRoZSBKV0Eg ZGVzY3JpcHRpb24gaXMgY2xlYXIgYW5kDQoNCj4gc2VtYW50aWNhbGx5IGVxdWl2YWxlbnQgYW5k IGltcGxlbWVudGVycyBoYXZlIHNob3duIHRoYXQgdGhleSBjYW4NCg0KPiBzdWNjZXNzZnVsbHkg YnVpbGQgaXQuICBGaW5hbGx5LCB3ZSB3b3VsZG7igJl0IHdhbnQgdG8gdGFrZSBhIG5vcm1hdGl2 ZQ0KDQo+IGRlcGVuZGVuY3kgdXBvbiBhIGRyYWZ0IHRoYXQgYXBwZWFycyB0byBoYXZlIGJlZW4g bGFyZ2VseSBhYmFuZG9uZWQNCg0KPiAob3IgYXQgbGVhc3QgbmVnbGVjdGVkKSwgYXMgZG9pbmcg c28gY291bGQgaW5kZWZpbml0ZWx5IHN0YWxsIHB1YmxpY2F0aW9uIG9mIFJGQyB2ZXJzaW9ucyBv ZiB0aGUgSk9TRSBzcGVjcy4NCg0KPg0KDQo+DQoNCj4NCg0KPiBbSkxTXSAgSSBhbHdheXMgY29u c2lkZXJlZCB0aGlzIHRvIGJlIGEgc3VmZmljaWVudCByZWZhY3RvcmluZyB0byB1c2UNCg0KPiB0 aGUgbWNncmV3IGRyYWZ0IGFzIGEgYmFzaXMuICBJIGRpZCBub3QgaGF2ZSB0aGUgc2FtZSB0eXBl IG9mIHByb2JsZW1zDQoNCj4gd2l0aCBicmVha2luZyB0aGUgdGVzdCB2ZWN0b3JzIGFwYXJ0IHRo YXQgeW91IHNlZW0gdG8gaGF2ZSBoYWQuDQoNCj4NCg0KDQoNCktNPiBPSywgaGFzIGFueW9uZSBy ZWFjaGVkIG91dCB0byBEYXZlIE1jR3JldyB0byBkaXNjdXNzPyAgSG93IGNhbiB3ZQ0KDQpjbGVh ciB0aGlzIHVwPw0KDQoNCg0KTWlrZT4gSeKAmWQgaGFkIGluLXBlcnNvbiBhbmQgcGhvbmUgY29u dmVyc2F0aW9ucyB3aXRoIGhpbSBhYm91dCBpdCBsYXN0IHllYXIsIGJ1dCBub3QgbXVjaCBoYXBw ZW5lZCBhcyBhIHJlc3VsdC4NCg0KDQoNCk1pa2U+IEkgd3JvdGUgbW9yZSBhYm91dCB5b3VyIHF1 ZXN0aW9uIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJl bnQvbXNnMDQwNzQuaHRtbCBpbiB3aGljaCBJIHBvaW50ZWQgb3V0IGVycm9ycyBhbmQgc291cmNl cyBvZiBjb25mdXNpb24gaW4gRGF2aWTigJlzIGRyYWZ0IHRoYXQgd291bGQgY29tcGxpY2F0ZSBs aWZlIGZvciBkZXZlbG9wZXJzIGFuZCBwb3NzaWJseSByZXN1bHQgaW4gaW5jb3JyZWN0IGltcGxl bWVudGF0aW9uczsgSmltIHJlc3BvbmRlZCBhdCBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDc1Lmh0bWwuICBJ4oCZbGwgc2VuZCBhIG5vdGUg dG8gRGF2aWQgcG9pbnRpbmcgdGhlc2Ugb3V0IGFuZCBvZmZlcmluZyB0byBwcm9kdWNlIHByb3Bv c2VkIGNoYW5nZXMgZm9yIGhpbSB0byBpbmNvcnBvcmF0ZSwgYnV0IHVubGVzcyBoZSBlaXRoZXIg ZGVjaWRlcyB0byBkZXZvdGUgYmFuZHdpZHRoIHRvIGFkdmFuY2luZyB0aGUgZHJhZnQgKGl04oCZ cyBhbHJlYWR5IGV4cGlyZWQgb25jZSkgb3IgaXMgd2lsbGluZyB0byBkZWxlZ2F0ZSBpdCB0byB1 cyB0byBkbyBzbywgSSB0aGluayB3ZSBkb27igJl0IGhhdmUgbXVjaCBjaG9pY2UgYnV0IHRvIGNv bnRpbnVlIHRvIGhhdmUgYSBjb21wbGV0ZSBhbmQgYWNjdXJhdGUgZGVzY3JpcHRpb24gb2YgdGhl IGFsZ29yaXRobXMgaW4gdGhlIEpXQSBkb2MsIGFuZCBsZXQgaGlzIGRyYWZ0IGFkdmFuY2UgYXQg aXRzIG93biBwYWNlLiAgSeKAmWxsIG5vdGUgdGhhdCB3ZSBhbHNvIGRvbuKAmXQgaGF2ZSBhIHB1 YmxpY2F0aW9uIHZlaGljbGUgZm9yIHRoZSBkcmFmdCB0byBiZWNvbWUgYW4gUkZDLCBiZWNhdXNl IGl04oCZcyBub3QgaW4gYW55IHdvcmtpbmcgZ3JvdXAsIG5vciBkb2VzIGl0IGhhdmUgQUQgc3Bv bnNvcnNoaXAgdGhhdCBJ4oCZbSBhd2FyZSBvZi4NCg0KDQoNCj4NCg0KPg0KDQo+IFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zOiBXaGlsZSBpdCBpcyB0cnVlIHRoZSBjb250ZW50IGlzIGNvdmVyZWQg aW4NCg0KPiBvdGhlciBwbGFjZXMsIHRoaXMgc2VjdGlvbiBjb3VsZCBiZW5lZml0IGZyb20gaW1w cm92ZW1lbnQgYmVmb3JlIGl0DQoNCj4gZ29lcyB0byB0aGUgU2VjRGlyIHJldmlldy4gIFRoZSBz ZWNvbmQgc2VudGVuY2UgaW4gdGhlIGZpcnN0IHBhcmFncmFwaA0KDQo+IHNheXMgdGhlDQoNCj4g Zm9sbG93aW5nOg0KDQo+DQoNCj4gICAgQW1vbmcgdGhlc2UgaXNzdWVzIGFyZQ0KDQo+DQoNCj4g ICAgcHJvdGVjdGluZyB0aGUgdXNlcidzIHByaXZhdGUgYW5kIHN5bW1ldHJpYyBrZXlzLCBwcmV2 ZW50aW5nDQoNCj4gdmFyaW91cw0KDQo+DQoNCj4gICAgYXR0YWNrcywgYW5kIGhlbHBpbmcgdGhl IHVzZXIgYXZvaWQgbWlzdGFrZXMgc3VjaCBhcyBpbmFkdmVydGVudGx5DQoNCj4NCg0KPiAgICBl bmNyeXB0aW5nIGEgbWVzc2FnZSBmb3IgdGhlIHdyb25nIHJlY2lwaWVudC4NCg0KPg0KDQo+IEl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGV4cGFuZCB0aGUgdGV4dCBhbmQgbWFrZSBp dCBtb3JlDQoNCj4gZGVzY3JpcHRpdmUgYW5kIGFwcGxpY2FibGUgdG8gdGhpcyBkb2N1bWVudC4g IEZvciBleGFtcGxlLCBzaG91bGRu4oCZdA0KDQo+IHRoZSBmaXJzdCBzZWN0aW9uIHNheSB1c2Vy 4oCZcyBwcml2YXRlIGFzeW1tZXRyaWMgYW5kIHN5bW1ldHJpYyBrZXlzPyAgSQ0KDQo+IGFzc3Vt ZSB0aGF0IGlzIHdoYXQgd2FzIGludGVuZGVkIHdpdGggcHJpdmF0ZSwgYnV0IGl0IHJlYWRzIGZ1 bm55IHRvDQoNCj4gbWUgd2l0aG91dCB0aGF0LiAgVGhlIG9ubHkg4oCYYXR0YWNr4oCZIG9yIGNh dXRpb24gbWVudGlvbmVkIGluIHRoZQ0KDQo+IGRvY3VtZW50IGlzIGZvciB0aGUgYXBwbGljYXRp b24gdG8gcHJldmVudCBhIHVzZXIgZnJvbSBzZWxlY3RpbmcgdGhlDQoNCj4gd3Jvbmcga2V5LiAg UGxlYXNlIGluY2x1ZGUgc29tZSBhdHRhY2tzIHRoYXQgZGV2ZWxvcGVycyBhbmQNCg0KPiBpbXBs ZW1lbnRlcnMgc2hvdWxkIGJlIGF3YXJlIGFuZCBjYXV0aW9uZWQgb24sIG9yIHN0YXRlIHRoYXQg c3BlY2lmaWMNCg0KPiBhdHRhY2tzIGFuZCBjb25zaWRlcnMgYXJlIGRldGFpbGVkIGluIHRoZSBz dWJzZWN0aW9ucyB0byBmb2xsb3cuDQoNCj4NCg0KPg0KDQo+DQoNCj4gTWlrZT4gT0ssIEkgY2Fu IHdvcmsgb24gZXhwYW5kaW5nIHRoYXQuICBUaGVyZSBhcmUgc29tZSBvdGhlciBhdHRhY2tzDQoN Cj4gbWVudGlvbmVkIGluIHRoZSBvdGhlciBkcmFmdHMsIHN1Y2ggYXMgdGltaW5nIGF0dGFja3Ms IHdoaWNoIGNhbg0KDQo+IHByb2JhYmx5IGF0IGxlYXN0IGJlIG1lbnRpb25lZCBoZXJlLiAgSeKA mWxsIHNlbmQgZHJhZnQgdGV4dCB0byB0aGUgbGlzdA0KDQo+IGFuZCBjb25zdWx0IHdpdGggeW91 IGJlZm9yZSBkb2luZyBhbnl0aGluZyB0byB0aGUgYWN0dWFsIGRyYWZ0cy4NCg0KPiBTcGVjaWZp YyBzdWdnZXN0aW9ucyBmcm9tIHdvcmtpbmcgZ3JvdXAgcGFydGljaXBhbnRzIHdvdWxkIGFsc28g YmUgaGlnaGx5IGFwcHJlY2lhdGVkLg0KDQo+DQoNCj4NCg0KS00+IEdyZWF0LCB0aGFuayB5b3Uh DQoNCj4NCg0KPiBJIHRoaW5rIHRoYXQncyBpdCBmb3Igbm93LiBBbHRob3VnaCBJIGRvIG5lZWQg dG8gbG9vayB0aHJvdWdoIHNvbWUNCg0KPiBtb3JlIG9mIHRoZSBwcmV2aW91cyBjb252ZXJzYXRp b25zIG9uIHRoZSBtYWlsaW5nIGxpc3QgYW5kIGluIHRoZSBpc3N1ZSB0cmFja2VyLg0KDQo+DQoN Cj4NCg0KPg0KDQo+IEkgc2VlIHRoZXJlIGFyZSBzb21lIG9wZW4gZGlzY3Vzc2lvbnMsIGxpa2Ug dGhlIG9uZSBSaWNoYXJkIHJhaXNlZA0KDQo+IHllc3RlcmRheSB0aGF0IG5lZWQgdG8gYmUgcmVz b2x2ZWQgaW4gdGhlIGRvY3VtZW50IGFzIHdlbGwgYmVmb3JlIHdlDQoNCj4gbW92ZSBmb3J3YXJk IHdpdGggdGhpcyBvbmUuICBUaGFua3MgZm9yIGFsbCBvZiB5b3VyIGVmZm9ydCBvbiB0aGlzIGRy YWZ0ISENCg0KPg0KDQo+DQoNCj4NCg0KPiBNaWtlPiBQZXIgbXkgbm90ZQ0KDQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwNjEuaHRtbCwg SQ0KDQo+IGRvbuKAmXQgYmVsaWV2ZSB0aGF0IHRoYXQgcGFydGljdWxhciBpc3N1ZSBpcyBvcGVu LiAgSXQgaGFkIGJlZW4NCg0KPiBleHRlbnNpdmVseSBkaXNjdXNzZWQgd2l0aGluIHRoZSB3b3Jr aW5nIGdyb3VwIG11bHRpcGxlIHRpbWVzIGFuZCB0aGUNCg0KPiBpc3N1ZSB3YXMgZXhwbGljaXRs eSBjbG9zZWQgYnkgdGhlIGNoYWlycywgbGVhdmluZyB0aGUgc3RhdHVzIHF1byBpbg0KDQo+IHBs YWNlIGluIHdoaWNoIHRoZXJlIGFyZSByZXF1aXJlZCBhbGdvcml0aG1zIGZvciBpbnRlcm9wZXJh YmlsaXR5IHJlYXNvbnMuDQoNCj4NCg0KPg0KDQo+DQoNCj4gSSdtIGdvaW5nIHRvIGFkZCBvbmUg bW9yZSBxdWVzdGlvbiB0byB0aGUgcmV2aWV3IGFzIEkgaGFkIHRoZSBzYW1lDQoNCj4gdGhvdWdo dCBhcyBTY290dCAmIEJ1cnQgaW4gdGhlaXIgcmV2aWV3IG9mIEpXQSAoYW5kIGFsc28gaW4gSldT KS4gIFdoeQ0KDQo+IGFyZSB0aGVyZSBubyBvdGhlciBvcHRpb25zIGluIGFkZGl0aW9uIHRvIFNI QTE/ICBUaGUgcmVzcG9uc2UgdG8gU2NvdHQNCg0KPiBwb2ludGVkIGJhY2sgdG8gZWFybHkgV0cg ZGVjaXNpb25zLCBidXQgSSBoYXZlIGhlYXJkIHRoaXMgY29uY2VybiBmcm9tDQoNCj4gb3RoZXJz IGFuZCBoYXZlIGl0IG15c2VsZiwgc28gSSBhbSBub3Qgc3VyZSB0aGlzIG9uZSBpcyByZXNvbHZl ZC4gIEknZCBsaWtlIHRvIHJldmlzaXQgaXQuDQoNCj4NCg0KPg0KDQo+DQoNCj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDAyMC5odG1sDQoN Cj4NCg0KPg0KDQo+DQoNCj4gTWlrZT4gSWYgYWRkaW5nIGEgbmV3IOKAnFJTQS1PQUVQLTI1NuKA nSBhbGdvcml0aG0gaWRlbnRpZmllciBmb3Ig4oCcUlNBRVMNCg0KPiBNaWtlPiB3aXRoDQoNCj4g T3B0aW1hbCBBc3ltbWV0cmljIEVuY3J5cHRpb24gUGFkZGluZyB1c2luZyB0aGUgTUdGMSBtYXNr IGdlbmVyYXRpb24NCg0KPiBmdW5jdGlvbiBhbmQgdGhlIFNIQS0yNTYgaGFzaCBmdW5jdGlvbuKA nSB3b3VsZCBtYWtlIGEgbnVtYmVyIG9mIHBlb3BsZQ0KDQo+IG1vcmUgY29tZm9ydGFibGUsIGlu Y2x1ZGluZyB5b3UsIHRoZXJl4oCZcyBub3RoaW5nIHdyb25nIHdpdGggZG9pbmcgc28uDQoNCj4g SG93ZXZlciwgaXTigJlzIGFsc28gbm90IGNsZWFyIHRoYXQgaXQgd291bGQgYmUgb2YgbXVjaCBz aG9ydC10ZXJtDQoNCj4gcHJhY3RpY2FsIGJlbmVmaXQgYmVjYXVzZSwgYXQgbGVhc3QgYXMgb2Yg dGhlIGltcGxlbWVudGF0aW9uIHN1cnZleQ0KDQo+IGRvbmUgaW4gSnVseSAyMDEyLCBtYW55IGNy eXB0byBsaWJyYXJpZXMgZG9u4oCZdCBleHBvc2UgYSB3YXkgdG8gZ2V0IGF0IHRoaXMgYWxnb3Jp dGhtIGNvbWJpbmF0aW9uLg0KDQo+IEhvd2V2ZXIsIHRoZSBzYW1lIGFyZ3VtZW50IGNvdWxkIGJl IG1hZGUgYWJvdXQgUlNBU1NBLVBTUywgd2hpY2ggd2UNCg0KPiBkaWQgYWRkIGlkZW50aWZpZXJz IGZvciBpbiB0aGUgZW5kLiAgSW4gc2hvcnQsIEkgZG9u4oCZdCB0aGluayBhbnlvbmUgaW4NCg0K PiB0aGUgd29ya2luZyBncm91cCB3b3VsZCBzdHJpZGVudGx5IG9iamVjdCBpZiB5b3UgYXNrZWQg Zm9yIHRoaXMNCg0KPiBhZGRpdGlvbmFsIGFsZ29yaXRobSBpZGVudGlmaWVyIHRvIGJlIGFkZGVk LiAgWW91ciBjYWxs4oCmDQoNCj4NCg0KS00+IEknZCBzYXkgdG8gYWRkIGl0LiAgSSdsbCBoYXZl IGEgc2ltaWxhciBjb21tZW50IGZvciB0aGUgSldTIGRyYWZ0DQoNCmZvciBTSEEyNTYgc3VwcG9y dCBvbiB0aHVtYnByaW50cy4NCg0KDQoNCk1pa2U+IE9LIOKAkyBJ4oCZbGwgYWRkIGl0Lg0KDQoN Cg0KTWlrZT4gUGVyIHlvdXIgSldTIGNvbW1lbnQsIFNIQS0xIHRodW1icHJpbnRzIGFyZSB3aWRl bHkgZGVwbG95ZWQuICBJ4oCZbSBhd2FyZSBvZiBubyBTSEEtMjU2IGNlcnRpZmljYXRlIHRodW1i cHJpbnQgZGVwbG95bWVudHMuICBJ4oCZbGwgbm90ZSB0aGF0IGV2ZW4gaWYgU0hBLTEgd2VyZSBj b21wbGV0ZWx5IGJyb2tlbiwgdGhhdCB3b3VsZG7igJl0IGJlIGEgc2VjdXJpdHkgaXNzdWUgYmVj YXVzZSBpdOKAmXMganVzdCBiZWluZyB1c2VkIHRvIGdlbmVyYXRlIGEgZGlnZXN0IG9mIHB1Ymxp Y2x5IGF2YWlsYWJsZSBjZXJ0aWZpY2F0ZSBpbmZvcm1hdGlvbi4gIEl04oCZcyBub3QgYmVpbmcg dXNlZCB0byBjcnlwdG9ncmFwaGljYWxseSBvYnNjdXJlIGFueXRoaW5nLiAgKEJ1dCB0aGF04oCZ cyBhY3R1YWxseSBhIGRpc2N1c3Npb24gZm9yIGFub3RoZXIgZHJhZnQuIOKYuikNCg0KDQoNCj4N Cg0KPg0KDQo+IC0tDQoNCj4NCg0KPg0KDQo+DQoNCj4gQmVzdCByZWdhcmRzLA0KDQo+DQoNCj4g S2F0aGxlZW4NCg0KPg0KDQo+DQoNCj4NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYQ0KDQo+IGJ1bmNoLA0KDQo+ DQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQo+DQoNCj4NCg0KDQoNCg0KDQoNCg0KLS0NCg0KDQoNCkJlc3Qg cmVnYXJkcywNCg0KS2F0aGxlZW4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCmpvc2UgbWFpbGluZyBsaXN0DQoNCmpvc2VAaWV0Zi5vcmc8 bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vam9zZQ0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739439A1A14A2TK5EX14MBXC288r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQ bGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+VGhlIGFsZ29yaXRobSBuYW1lIOKAnFJTQS1PQUVQLTI1NuKAnSBm b3INCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+UlNBRVMgT0FFUCB1c2luZyBTSEEtMjU2IGFuZCBN R0YxIHdpdGggU0hBLTI1NiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmhhcyBi ZWVuIGFkZGVkIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0yNiNzZWN0aW9uLTQuMyI+DQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0yNiNz ZWN0aW9uLTQuMzwvYT4sIHBlciB5b3VyIHJlcXVlc3QsIEthdGhsZWVuLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8Yj48bzpwPjwvbzpwPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gam9zZSBbbWFpbHRvOmpvc2UtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEFwcmlsIDI1LCAyMDE0IDY6MzggUE08YnI+DQo8Yj5Ubzo8L2I+IEthdGhs ZWVuIE1vcmlhcnR5OyBKaW0gU2NoYWFkPGJyPg0KPGI+Q2M6PC9iPiBqb3NlQGlldGYub3JnOyBk cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtc0B0b29scy5pZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGFua3MsIEthdGhsZWVuLiZu YnNwOyBDb21tZW50cyBhcmUgaW5saW5lLCBtYXJrZWQg4oCcTWlrZSZndDvigJ3igKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogam9zZSBbPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBLYXRobGVlbiBN b3JpYXJ0eTxicj4NClNlbnQ6IEZyaWRheSwgQXByaWwgMjUsIDIwMTQgMjowNyBQTTxicj4NClRv OiBKaW0gU2NoYWFkPGJyPg0KQ2M6IE1pa2UgSm9uZXM7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtc0B0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRm LWpvc2UtanNvbi13ZWItYWxnb3JpdGhtc0B0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1h aWx0bzpqb3NlQGlldGYub3JnIj4NCmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6 IFtqb3NlXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U29ycnkgZm9yIHRoZSBkZWxheSBpbiBteSBy ZXNwb25zZS4mbmJzcDsgSSdsbCBhbnN3ZXIgaW4tbGluZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PbiBU aHUsIEFwciAxNywgMjAxNCBhdCA1OjIwIFBNLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWls dG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L3NwYW4+PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZyb206IGpvc2UgWzxhIGhyZWY9Im1haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT5dIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNywgMjAxNCAxMDo0NiBBTTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUbzogS2F0aGxlZW4g TW9yaWFydHk7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+am9zZUBpZXRmLm9yZzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IENjOiA8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXNAdG9vbHMuaWV0 Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zQHRvb2xzLmlldGYub3JnPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU3Vi amVjdDogUmU6IFtqb3NlXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFs Z29yaXRobXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhhbmtzIGZvciB0YWtpbmcgdGhl IHRpbWUgdG8gZG8gdGhlIHJldmlldywgS2F0aGxlZW4uJm5ic3A7IFJlc3BvbnNlcyBhcmUNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBpbmxpbmUsIGZsYWdn ZWQgYnkg4oCcTWlrZSZndDvigJ0uJm5ic3A7IEkgYWxzbyBwYXN0ZWQgeW91ciBmb2xsb3ctb24g bm90ZSBpbiBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyByZXNwb25kZWQgdG8gaXQgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJv bTogS2F0aGxlZW4gTW9yaWFydHkgWzxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5p ZXRmQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPm1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48 L2E+XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZW50OiBU aHVyc2RheSwgQXByaWwgMTcsIDIwMTQgNzo1MSBBTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5qb3NlQGll dGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgQ2M6IE1pa2UgSm9uZXM7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtc0B0b29scy5pZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFs Z29yaXRobXNAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1q b3NlLWpzb24td2ViLWFsZ29yaXRobXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSGVsbG8g TWlrZSAmYW1wOyBKT1NFIG1lbWJlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEkgYW0g d29ya2luZyBteSB3YXkgdGhyb3VnaCB0aGUgcmVxdWVzdGVkIHJldmlld3MgdG8gcHJvZ3Jlc3Mg dGhlIEpPU0UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBk cmFmdHMgYW5kIGNhbiBzZWUgYSBsb3Qgb2Ygd29yayBoYXMgYmVlbiBkb25lLCB0aGFuayB5b3Uu Jm5ic3A7IEFzIEkgcmVhZA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHRocm91Z2ggdGhlIEFsZ29yaXRobXMgKEpXQSkgZHJhZnQgdGhlcmUgYXJlIHNvbWUg Y2hhbmdlcyB0aGF0IHdpbGwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBuZWVkIHRvIGJlIG1hZGUgdG8gYXZvaWQgcHJvYmxlbXMgZHVyaW5nIHRoZSBJRVNH IHJldmlldy4mbmJzcDsgVGhpcyBpcyBhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgcHJldHR5IGJpZyBjaGFuZ2UgZm9yIHRoZSBkcmFmdCwgYnV0IHdpbGwg aGVscCBtYWtlIHRoZSByZXZpZXcgYW5kIGFwcHJvdmFsIGZhc3Rlci48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVHlwaWNhbGx5LCB0aGUgbGlzdHMgb2YgYWxn b3JpdGhtcyBhcmUgaGFuZGxlZCB0aHJvdWdoIGEgZHJhZnQgdXBkYXRlDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYXMgb3Bwb3NlZCB0byBjcmVhdGluZyBh biBJQU5BIHJlZ2lzdHJ5LiZuYnNwOyBBIGdvb2QgZXhhbXBsZSBpcyBhIHJlY2VudA0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHVwZGF0ZSBvZiBhIGRyYWZ0 IGluIHRoZSBJUFNFQ01FIHdvcmtpbmcgZ3JvdXAgc28geW91IGNhbiBzZWUgdGhlDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc3RydWN0dXJlIGFuZCB0aGUg cHJlY2VkZW5jZSBmb3IgdGhpcyBtb2RlbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21l LWVzcC1haC1yZXF0cyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1p cHNlY21lLWVzcC1haC1yZXF0czwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IE1pa2UmZ3Q7IFNvIHlvdeKAmXJlIHN1Z2dlc3RpbmcgdGhhdCBmdXR1cmUgSldBIGRyYWZ0cyBt aWdodCBvYnNvbGV0ZSB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBNaWtlJmd0OyBjdXJyZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IG9uZSwgbXVjaCBsaWtlIGRyYWZ0LWlldGYtaXBzZWNtZS1lc3AtYWgtcmVx dHMgd2lsbCBvYnNvbGV0ZSBSRkMgNDgzNSwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyB3aGljaCBvYnNvbGV0ZWQgUkZDIDQzMDUsIGV0Yy4/Jm5ic3A7IElm IHNvLCBjb3VsZCB3b3JrIG9uIHJldmlzaW5nIHRoZSBKV0ENCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkcmFmdCBhY2NvcmRpbmdseSBhbmQgc2VuZCBwcm9w b3NlZCBjaGFuZ2VzIHRvIHRoZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+S00mZ3Q7IEkgYW0gbm90IHN1cmUgd2hlcmUgSmltJ3MgcmVzcG9uc2UgaXMsIGJ1dCBJ IGhhdmUgYmVlbiBsb29raW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5pbnRvIHRoaXMuJm5ic3A7IE15IGluaXRpYWwgbWVzc2FnZSBjYW1lIGFmdGVyIHNvbWUgY29u dmVyc2F0aW9ucyB3aXRoIFNlYW4uJm5ic3A7IEluIHJlc3BvbnNlIHRvIHlvdXIgcG9zdHMsIEkg cmVhY2hlZCBvdXQgdG8gYSBjb3VwbGUgb2Ygb3RoZXIgQURzIHdobyBtYXkgaGF2ZSBoYWQgY29u Y2VybnMgYW5kICp0aGluayogd2UgYXJlIG9rYXkgYXMgbG9uZyBhcyB0aGUgcmVnaXN0cmllcyB3 aWxsIGJlIHVzZWQgd2l0aA0KIGEgZGVzaWduYXRlZCBleHBlcnQgcmV2aWV3IHRvIGFkZCB0byB0 aGUgcmVnaXN0cnkuJm5ic3A7IElmIGEgZHJhZnQgaXMgcmVxdWlyZWQgZm9yIGFuIHVwZGF0ZSwg dGhhdCB3b3VsZCBjYXVzZSBwcm9ibGVtcyBhcyBvcHBvc2VkIHRvIGEgZHJhZnQgd2l0aCBubyBy ZWdpc3RyaWVzLiZuYnNwOyBTb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbiBoZXJlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+TWlrZSZndDsg Smlt4oCZcyByZXNwb25zZSBpcyBhdCA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDcxLmh0bWwiPg0KaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDA3MS5odG1sPC9hPiwgc3Rh cnRpbmcgd2l0aCDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltKTFNdIEth dGhsZWVuLCBJIGRvbuKAmXQga25vdyB0aGF0IEkgYWdyZWUgd2l0aCB0aGlzIHN0YXRlbWVudC4m bmJzcDsgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwbGFjZXMgd2hlcmUgSUFOQSBy ZWdpc3RyaWVzIGFyZSB1c2VkIGZvcg0KIHRoZSBwdXJwb3NlIG9mIGhhdmluZyBsaXN0cyBvZiBh bGdvcml0aG1zLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+4oCdJm5ic3A7IEFs bCB0aGUgcmVnaXN0cmllcyBlc3RhYmxpc2hlZCBhbHJlYWR5IHJlcXVpcmUgZXhwZXJ0IHJldmll dywgYXMgZGVzY3JpYmVkIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0yNSNzZWN0aW9uLTciPg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMt MjUjc2VjdGlvbi03PC9hPi4mbmJzcDsgU28gaXQgc291bmRzIGxpa2Ugd2Ugc2hvdWxkIGJlIE9L LiZuYnNwOyBUaGF04oCZcyBnb29kLiZuYnNwOyBUaGFua3MgZm9yIHdvcmtpbmcgdGhlIGlzc3Vl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBOb3cgZm9yIG90aGVyIGVkaXRzIGFuZCBxdWVzdGlvbnM6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IFNlY3Rpb24gMy42IC0gQ2FuIHlvdSBleHBsYWluIHdoeSB3b3Vs ZCB0aGlzIGJlIGluY2x1ZGVkPyZuYnNwOyBJZiB5b3UgYXJlDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbm90IGdvaW5nIHRvIHNpZ24sIEkgYW0gbm90IHN1 cmUgd2h5IG9uZSB3b3VsZCB1c2UgSk9TRSBhdCBhbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IE1pa2UmZ3Q7IFRoaXMgaXMgaW5jbHVkZWQgdG8gZW5hYmxlIHJlcHJlc2VudGluZyBjb250 ZW50IHRoYXQgaXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBNaWtlJmd0OyBvcHRpb25hbGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IHNpZ25lZCBpbiBwcm90b2NvbHMgdXNpbmcgSldTLiZuYnNwOyBIYXZpbmcgdGhp cyBtZWFucyB0aGF0IHdoZXRoZXIgb3Igbm90DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdGhlIGNvbnRlbnQgaXMgc2lnbmVkLCBpdCBjYW4gdXNlIGEgdW5p Zm9ybSByZXByZXNlbnRhdGlvbiwgd2hpY2ggaXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBlYXN5IHRvIHBhcnNlLiZuYnNwOyBUaGlzIGlzIGluIHByb2R1 Y3Rpb24gdXNlLCBmb3IgaW5zdGFuY2UsIHRvIGVuYWJsZQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE9BdXRoIGF1dGhvcml6YXRpb24gcmVxdWVzdCBtZXNz YWdlcyB0aGF0IGFyZSBvcHRpb25hbGx5IHNpZ25lZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTb21ldGltZXMgY29udGVudCBuZWVkIG5vdCBi ZSBzaWduZWQgYXQgdGhlIEpXUyBsZXZlbCBiZWNhdXNlIGl04oCZcw0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGludGVncml0eSBwcm90ZWN0ZWQgYnkgb3Ro ZXIgcHJvdG9jb2wgbGF5ZXJzIOKAkyBpbiBwYXJ0aWN1bGFyLCBvZnRlbiBieQ0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoZSB1c2Ugb2YgVExTLiZuYnNw OyBBbm90aGVyIHVzZSBjYXNlIGlzIHdoZXJlIHNpZ25pbmcgYWRkcyBhZGRpdGlvbmFsDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgb3B0aW9uYWwgdmFsdWUs IGJ1dCB3aGVyZSB0aGVyZeKAmXMgbm8gaGFybSBpbiB1c2luZyB1bnNpZ25lZCBjb250ZW50IOKA kw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGZvciBpbnN0 YW5jZSwgd2hpbGUgbm9ybWFsIE9BdXRoIHJlcXVlc3RzIGFyZSBpbmxpbmUgYW5kIHVuc2lnbmVk LCBhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVnaXN0 ZXJlZCBleHRlbnNpb24gZW5hYmxlcyByZXF1ZXN0IHBhcmFtZXRlcnMgdG8gYmUgcGFzc2VkIGJ5 DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVmZXJlbmNl LCByYXRoZXIgdGhhbiBieSB2YWx1ZTsgdGhlIG9iamVjdCByZWZlcmVuY2VkIGNvbnRhaW5pbmcg dGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcGFyYW1l dGVycyBpcyBhIEpXUzsgdGhlIEpXUyBjYW4gb3B0aW9uYWxseSBiZSBzaWduZWQuJm5ic3A7IFRo ZSBjdXJyZW50LA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGNhcmVmdWxseSByZWZpbmVkIHRyZWF0bWVudCBvZiDigJxub25l4oCdIGlzIHRoZSByZXN1bHQg b2Ygc3Vic3RhbnRpYWwgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zIGFuZCBkaXNjdXNzaW9ucyBv biB3b3JraW5nIGdyb3VwIGNhbGxzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBXaGlsZSBhIGxlc3MgcGFyYWxsZWwgdHJlYXRtZW50IG9mIHVuc2lnbmVkIEpX U3Mgd2FzIHByb3Bvc2VkIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFj L3RpY2tldC8zNiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8z Njwvc3Bhbj48L2E+LCB0aGlzIGFsdGVybmF0aXZlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgc3ludGF4IHdhcyByZWplY3RlZCBieSB0aGUgd29ya2luZyBn cm91cCBpbiBmYXZvciBvZiB0aGUgY3VycmVudCBhcHByb2FjaC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPktNJmd0OyBJIHJlc3BvbmRlZCB0byBWbGFkYW1pciBvbiB0aGlzIG9uZSBhbmQg d291bGQganVzdCBsaWtlIHRvIGtub3cgaWY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPnRoZXJlIGlzIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhlIGRlY2lzaW9uLiZuYnNw OyBDYW4geW91IHBvaW50IG1lIHRvIGRpc2N1c3Npb25zIG9uIHRoaXM/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5NaWtlJmd0OyBCcmlh biBDYW1wYmVsbCBkaWQgYSBnb29kIGpvYiBzdW1tYXJpemluZyB0aGUgY29uc2Vuc3VzIGluIGhp cyBub3RlDQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9z ZS9jdXJyZW50L21zZzA0MDgyLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwODIuaHRtbDwvYT4uJm5ic3A7IEppbSBTY2hhYWQgZG9j dW1lbnRlZCB0aGUgY29uc2Vuc3VzIGluIGhpcyBub3RlIGNsb3NpbmcgaXNzdWUgIzM2IGF0IHRo ZSBlbmQgb2YNCjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJh Yy90aWNrZXQvMzYiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNr ZXQvMzY8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+TWlr ZSZndDsgVGhpcyB3YXMgZXh0ZW5zaXZlbHkgZGlzY3Vzc2VkIG9uIGEgdGhyZWFkIHRpdGxlZCDi gJxbam9zZV0gIzM2OiBBbGdvcml0aG0gJnF1b3Q7bm9uZSZxdW90OyBzaG91bGQgYmUgcmVtb3Zl ZOKAnSBiZXR3ZWVuIDcvMzEvMTMgYW5kIDgvMjIvMTMgYW5kIHRoZW4gYWxzbyBvbiBhIGZvbGxv dy11cCB0aHJlYWQgbmFtZWQg4oCcW2pvc2VdIFRleHQgYWJvdXQgYXBwbGljYXRpb25zDQogYW5k ICZxdW90O2FsZyZxdW90OzomcXVvdDtub25lJnF1b3Q74oCdIGJldHdlZW4gOS8zLzEzIGFuZCA5 LzkvMTMuJm5ic3A7IFRoZSBsYXR0ZXIgdGhyZWFkIHJlc3VsdGVkIGZyb20gYW4gYWN0aW9uIGl0 ZW1zIGZyb20gdGhlIHByZWNlZGluZyBpbnRlcmltIHdvcmtpbmcgZ3JvdXAgY2FsbCAodGhlIGFn ZW5kYSBmb3Igd2hpY2ggd2FzIHB1Ymxpc2hlZCBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTMvMDgvMTkvam9zZS9hZ2VuZGEvYWdlbmRhLWlu dGVyaW0tMjAxMy1qb3NlLTUiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRl cmltLzIwMTMvMDgvMTkvam9zZS9hZ2VuZGEvYWdlbmRhLWludGVyaW0tMjAxMy1qb3NlLTU8L2E+ KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPk1pa2UmZ3Q7IFRo ZSB0ZXh0IGFncmVlZCB0byBieSB0aGUgd29ya2luZyBncm91cCB0aGF0IEJyaWFuIHJlZmVycmVk IHRvIHdhcyBhZGRlZCBpbiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0xNiwg cHVibGlzaGVkIG9uIDkvMTUvMTMuJm5ic3A7IEppbSBjbG9zZWQgdGhlIGlzc3VlIG9uIDEwLzI4 LzEzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBTZWN0aW9uIDUuMiAtIFRoZSB3cml0ZSB1cCBvZiB0aGlzIHNlY3Rp b24gc2VlbXMgYSBiaXQgbW9yZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IGNvbXBsaWNhdGVkIHRoYW4gbmVjZXNzYXJ5LiZuYnNwOyBJdCBzZWVtcyBpdCB3 b3VsZCBoYXZlIGp1c3QgYmVlbiBzaW1wbGVyDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdG8gc3RhdGUgdGhhdCB0aGUgc2l6ZXMgdmFyeSBhcyByZXF1aXJl ZCBieSB0aGUgYWxnb3JpdGhtcyBhbmQga2V5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgbGVuZ3RocyB1c2VkIHJhdGhlciB0aGFuIHByb3ZpZGluZyB0aGUg ZGlmZmVyZW5jZXMgZnJvbSBvbmUgdG8gdGhlIG5leHQuJm5ic3A7IENhbiB5b3Ugc2ltcGxpZnkg dGhpcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQWZ0ZXIgbG9va2lu ZyB0aHJvdWdoIHNvbWUgb2YgdGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9ucywgaXQgc2VlbXMN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGVyZSB3YXMg YWxyZWFkeSBhZ3JlZW1lbnQgdG8gc2xpbSB0aGlzIGFuZCBvdGhlciBzZWN0aW9ucyBkb3duIGJ5 DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcG9pbnRpbmcg dG8gdGhlIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9qb3NlL2N1cnJlbnQvbXNnMDIyNzYuaHRtbCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2pvc2UvY3VycmVudC9tc2cwMjI3Ni5odG1sPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2FuIEkgZ2V0IGFuIHVwZGF0ZSBhcyB0byB3aGVy ZSB0aGF0IHN0YW5kcywgcmVmZXJlbmNpbmcgd2hhdCB5b3UgY2FuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZnJvbSB0aGF0IGRyYWZ0IGFzIG9wcG9zZWQg dG8gZHVwbGljYXRpbmcgdGV4dD8mbmJzcDsgVGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBNaWtlJmd0OyBTdXJlLiZuYnNwOyBUaGUga2V5IHBhcnQgb2YgdGhl IG1lc3NhZ2UgeW91IGNpdGVkIGlzIOKAnE9uY2UgdGhlIE1jR3Jldw0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE1pa2UmZ3Q7IGRyYWZ0PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGhhcyBiZWVuIHJlZmFjdG9yZWQgdG8g c2VwYXJhdGUgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBjYWxjdWxhdGlvbg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHN0ZXBzICh3aGljaCBKT1NFIGlzIHVz aW5nKSBmcm9tIHRoZSBBRUFEIHJlcHJlc2VudGF0aW9uIHN0ZXBzICh3aGljaA0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEpPU0UgaXMgbm90IHVzaW5nKSwg YW5kIHRvIGluY2x1ZGUgdGVzdCB2ZWN0b3IgdmFsdWVzIHRoYXQgc2hvdw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJlc3VsdHMgd2l0aG91dCBwZXJmb3Jt aW5nIHRoZSBBRUFEIHJlcHJlc2VudGF0aW9uIGNvbmNhdGVuYXRpb25zLCBJDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYWdyZWUgdGhhdCB3ZSdsbCBiZSBh YmxlIHRvIGp1c3QgcmVmZXJlbmNlIGl0LCByYXRoZXIgdGhhbiBkdXBsaWNhdGluZw0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGl0LuKAnSZuYnNwOyBUaGUg cHJvYmxlbSBpcyB0aGF0IHRoZSByZWZhY3RvcmluZyB3YXMgbmV2ZXIgZG9uZS4mbmJzcDsgVGhl DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYWxnb3JpdGht IGRlc2NyaXB0aW9uIGluPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGlzIHdyaXR0ZW4gaW4gc3Vj aCBhIHdheSB0aGF0IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGNpcGhlcnRleHQgQywgYXMgZGVzY3JpYmVkLCBhbHNvIGluY2x1ZGVzIHRoZSBJViB2 YWx1ZSBhcyBhIHByZWZpeCBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyB0aGUgYXV0aGVudGljYXRpb24gdGFnIFQgYXMgYSBzdWZmaXgsIHJhdGhlciB0 aGFuIHRyZWF0aW5nIGVhY2ggb2YNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyB0aG9zZSBhcyBzZXBhcmF0ZSB2YWx1ZXMuJm5ic3A7IFRoZSB0ZXN0IHZlY3Rv cnMgZG8gdGhlIHNhbWUuJm5ic3A7IFllcywgRGF2aWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhZGRlZCBhcHBlbmRpeCBCIHNheWluZyB0aGF0IHRoZSB2 YWx1ZXMgY291bGQgYmUgdHJlYXRlZCBhcyBzZXBhcmF0ZSwNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBidXQgdGhlIHdyaXRlLXVwIGRvZXMgbm8gZmF2b3Jz IHRvIGltcGxlbWVudGVycywgYXMgYm90aCB0aGUgY29yZQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFsZ29yaXRobSBkZXNjcmlwdGlvbiBhbmQgdGhlIHRl c3QgdmVjdG9ycyBhc3N1bWUgdGhleSBhcmUgY29tYmluZWQuJm5ic3A7DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgKEkgcGVyc29uYWxseSBrbm93IHRoYXQg d29ya2luZyBvdXQgaG93IHRvIHRyZWF0IHRoZW0gYXMgc2VwYXJhdGUgZnJvbQ0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IERhdmlk4oCZcyBjdXJyZW50IGRy YWZ0IGlzIGEgdGVkaW91cyBhbmQgZXJyb3ItcHJvbmUgZXhlcmNpc2UsIGhhdmluZw0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGhhZCB0byBkbyBzbyB0byB0 ZWFzZSB0aGVtIGFwYXJ0IGZvciB0aGUgY3VycmVudCBKV0Egd3JpdGUtdXAuKSZuYnNwOyBEYXZp ZA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGhhcyBiZWVu IGFza2VkIGFib3V0IGRvaW5nIHRoZSByZWZhY3RvcmluZyBzZXZlcmFsIHRpbWVzIGJ5IG11bHRp cGxlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcGFydGll cywgYnV0IGhl4oCZcyBhIGJ1c3kgZ3V5LCBhbmQgSSBkb27igJl0IHRoaW5rIGl04oCZcyBldmVy IHJlYWNoZWQgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgdG9wIG9mIGhpcyBxdWV1ZS4mbmJzcDsgQXMgaXQgaXMsIHRoZSBKV0EgZGVzY3JpcHRpb24g aXMgY2xlYXIgYW5kDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgc2VtYW50aWNhbGx5IGVxdWl2YWxlbnQgYW5kIGltcGxlbWVudGVycyBoYXZlIHNob3duIHRo YXQgdGhleSBjYW4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBzdWNjZXNzZnVsbHkgYnVpbGQgaXQuJm5ic3A7IEZpbmFsbHksIHdlIHdvdWxkbuKAmXQgd2Fu dCB0byB0YWtlIGEgbm9ybWF0aXZlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgZGVwZW5kZW5jeSB1cG9uIGEgZHJhZnQgdGhhdCBhcHBlYXJzIHRvIGhhdmUg YmVlbiBsYXJnZWx5IGFiYW5kb25lZA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IChvciBhdCBsZWFzdCBuZWdsZWN0ZWQpLCBhcyBkb2luZyBzbyBjb3VsZCBp bmRlZmluaXRlbHkgc3RhbGwgcHVibGljYXRpb24gb2YgUkZDIHZlcnNpb25zIG9mIHRoZSBKT1NF IHNwZWNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBbSkxTXSZuYnNwOyBJIGFsd2F5cyBj b25zaWRlcmVkIHRoaXMgdG8gYmUgYSBzdWZmaWNpZW50IHJlZmFjdG9yaW5nIHRvIHVzZQ0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoZSBtY2dyZXcgZHJh ZnQgYXMgYSBiYXNpcy4mbmJzcDsgSSBkaWQgbm90IGhhdmUgdGhlIHNhbWUgdHlwZSBvZiBwcm9i bGVtcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdpdGgg YnJlYWtpbmcgdGhlIHRlc3QgdmVjdG9ycyBhcGFydCB0aGF0IHlvdSBzZWVtIHRvIGhhdmUgaGFk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5LTSZndDsgT0ssIGhhcyBhbnlvbmUgcmVhY2hlZCBv dXQgdG8gRGF2ZSBNY0dyZXcgdG8gZGlzY3Vzcz8mbmJzcDsgSG93IGNhbiB3ZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Y2xlYXIgdGhpcyB1cD88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPk1pa2UmZ3Q7IEni gJlkIGhhZCBpbi1wZXJzb24gYW5kIHBob25lIGNvbnZlcnNhdGlvbnMgd2l0aCBoaW0gYWJvdXQg aXQgbGFzdCB5ZWFyLCBidXQgbm90IG11Y2ggaGFwcGVuZWQgYXMgYSByZXN1bHQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5NaWtlJmd0OyBJIHdyb3RlIG1vcmUg YWJvdXQgeW91ciBxdWVzdGlvbiBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDA3NC5odG1sIj5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDc0Lmh0bWw8L2E+IGluIHdo aWNoIEkgcG9pbnRlZCBvdXQgZXJyb3JzIGFuZCBzb3VyY2VzIG9mIGNvbmZ1c2lvbiBpbiBEYXZp ZOKAmXMgZHJhZnQgdGhhdCB3b3VsZCBjb21wbGljYXRlIGxpZmUgZm9yIGRldmVsb3BlcnMgYW5k DQogcG9zc2libHkgcmVzdWx0IGluIGluY29ycmVjdCBpbXBsZW1lbnRhdGlvbnM7IEppbSByZXNw b25kZWQgYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pv c2UvY3VycmVudC9tc2cwNDA3NS5odG1sIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwNzUuaHRtbDwvYT4uJm5ic3A7IEnigJlsbCBzZW5k IGEgbm90ZSB0byBEYXZpZCBwb2ludGluZyB0aGVzZSBvdXQgYW5kIG9mZmVyaW5nIHRvIHByb2R1 Y2UgcHJvcG9zZWQgY2hhbmdlcyBmb3IgaGltIHRvIGluY29ycG9yYXRlLCBidXQgdW5sZXNzIGhl IGVpdGhlciBkZWNpZGVzIHRvIGRldm90ZSBiYW5kd2lkdGggdG8gYWR2YW5jaW5nIHRoZSBkcmFm dCAoaXTigJlzDQogYWxyZWFkeSBleHBpcmVkIG9uY2UpIG9yIGlzIHdpbGxpbmcgdG8gZGVsZWdh dGUgaXQgdG8gdXMgdG8gZG8gc28sIEkgdGhpbmsgd2UgZG9u4oCZdCBoYXZlIG11Y2ggY2hvaWNl IGJ1dCB0byBjb250aW51ZSB0byBoYXZlIGEgY29tcGxldGUgYW5kIGFjY3VyYXRlIGRlc2NyaXB0 aW9uIG9mIHRoZSBhbGdvcml0aG1zIGluIHRoZSBKV0EgZG9jLCBhbmQgbGV0IGhpcyBkcmFmdCBh ZHZhbmNlIGF0IGl0cyBvd24gcGFjZS4mbmJzcDsgSeKAmWxsIG5vdGUgdGhhdCB3ZQ0KIGFsc28g ZG9u4oCZdCBoYXZlIGEgcHVibGljYXRpb24gdmVoaWNsZSBmb3IgdGhlIGRyYWZ0IHRvIGJlY29t ZSBhbiBSRkMsIGJlY2F1c2UgaXTigJlzIG5vdCBpbiBhbnkgd29ya2luZyBncm91cCwgbm9yIGRv ZXMgaXQgaGF2ZSBBRCBzcG9uc29yc2hpcCB0aGF0IEnigJltIGF3YXJlIG9mLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZWN1 cml0eSBDb25zaWRlcmF0aW9uczogV2hpbGUgaXQgaXMgdHJ1ZSB0aGUgY29udGVudCBpcyBjb3Zl cmVkIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgb3Ro ZXIgcGxhY2VzLCB0aGlzIHNlY3Rpb24gY291bGQgYmVuZWZpdCBmcm9tIGltcHJvdmVtZW50IGJl Zm9yZSBpdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGdv ZXMgdG8gdGhlIFNlY0RpciByZXZpZXcuJm5ic3A7IFRoZSBzZWNvbmQgc2VudGVuY2UgaW4gdGhl IGZpcnN0IHBhcmFncmFwaA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHNheXMgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsgQW1vbmcgdGhlc2UgaXNzdWVzIGFyZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBwcm90ZWN0aW5nIHRoZSB1c2Vy J3MgcHJpdmF0ZSBhbmQgc3ltbWV0cmljIGtleXMsIHByZXZlbnRpbmcNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB2YXJpb3VzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0dGFja3MsIGFuZCBoZWxw aW5nIHRoZSB1c2VyIGF2b2lkIG1pc3Rha2VzIHN1Y2ggYXMgaW5hZHZlcnRlbnRseTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBlbmNyeXB0 aW5nIGEgbWVzc2FnZSBmb3IgdGhlIHdyb25nIHJlY2lwaWVudC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgSXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgZXhw YW5kIHRoZSB0ZXh0IGFuZCBtYWtlIGl0IG1vcmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBkZXNjcmlwdGl2ZSBhbmQgYXBwbGljYWJsZSB0byB0aGlzIGRv Y3VtZW50LiZuYnNwOyBGb3IgZXhhbXBsZSwgc2hvdWxkbuKAmXQNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgZmlyc3Qgc2VjdGlvbiBzYXkgdXNlcuKA mXMgcHJpdmF0ZSBhc3ltbWV0cmljIGFuZCBzeW1tZXRyaWMga2V5cz8mbmJzcDsgSQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFzc3VtZSB0aGF0IGlzIHdo YXQgd2FzIGludGVuZGVkIHdpdGggcHJpdmF0ZSwgYnV0IGl0IHJlYWRzIGZ1bm55IHRvDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbWUgd2l0aG91dCB0aGF0 LiAmbmJzcDtUaGUgb25seSDigJhhdHRhY2vigJkgb3IgY2F1dGlvbiBtZW50aW9uZWQgaW4gdGhl DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZG9jdW1lbnQg aXMgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBwcmV2ZW50IGEgdXNlciBmcm9tIHNlbGVjdGluZyB0 aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3cm9uZyBr ZXkuJm5ic3A7IFBsZWFzZSBpbmNsdWRlIHNvbWUgYXR0YWNrcyB0aGF0IGRldmVsb3BlcnMgYW5k DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaW1wbGVtZW50 ZXJzIHNob3VsZCBiZSBhd2FyZSBhbmQgY2F1dGlvbmVkIG9uLCBvciBzdGF0ZSB0aGF0IHNwZWNp ZmljDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYXR0YWNr cyBhbmQgY29uc2lkZXJzIGFyZSBkZXRhaWxlZCBpbiB0aGUgc3Vic2VjdGlvbnMgdG8gZm9sbG93 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBNaWtlJmd0OyBPSywgSSBjYW4gd29yayBvbiBl eHBhbmRpbmcgdGhhdC4mbmJzcDsgVGhlcmUgYXJlIHNvbWUgb3RoZXIgYXR0YWNrczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBtZW50aW9uZWQgaW4gdGhlIG90 aGVyIGRyYWZ0cywgc3VjaCBhcyB0aW1pbmcgYXR0YWNrcywgd2hpY2ggY2FuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcHJvYmFibHkgYXQgbGVhc3QgYmUg bWVudGlvbmVkIGhlcmUuJm5ic3A7IEnigJlsbCBzZW5kIGRyYWZ0IHRleHQgdG8gdGhlIGxpc3QN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhbmQgY29uc3Vs dCB3aXRoIHlvdSBiZWZvcmUgZG9pbmcgYW55dGhpbmcgdG8gdGhlIGFjdHVhbCBkcmFmdHMuJm5i c3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU3BlY2lm aWMgc3VnZ2VzdGlvbnMgZnJvbSB3b3JraW5nIGdyb3VwIHBhcnRpY2lwYW50cyB3b3VsZCBhbHNv IGJlIGhpZ2hseSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPktNJmd0 OyBHcmVhdCwgdGhhbmsgeW91ITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBJIHRoaW5rIHRoYXQncyBpdCBmb3Igbm93LiBBbHRob3VnaCBJIGRvIG5lZWQgdG8gbG9vayB0 aHJvdWdoIHNvbWUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBtb3JlIG9mIHRoZSBwcmV2aW91cyBjb252ZXJzYXRpb25zIG9uIHRoZSBtYWlsaW5nIGxpc3Qg YW5kIGluIHRoZSBpc3N1ZSB0cmFja2VyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJIHNl ZSB0aGVyZSBhcmUgc29tZSBvcGVuIGRpc2N1c3Npb25zLCBsaWtlIHRoZSBvbmUgUmljaGFyZCBy YWlzZWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB5ZXN0 ZXJkYXkgdGhhdCBuZWVkIHRvIGJlIHJlc29sdmVkIGluIHRoZSBkb2N1bWVudCBhcyB3ZWxsIGJl Zm9yZSB3ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1v dmUgZm9yd2FyZCB3aXRoIHRoaXMgb25lLiZuYnNwOyBUaGFua3MgZm9yIGFsbCBvZiB5b3VyIGVm Zm9ydCBvbiB0aGlzIGRyYWZ0ISE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTWlrZSZndDsg UGVyIG15IG5vdGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVu dC9tc2cwNDA2MS5odG1sIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9j dXJyZW50L21zZzA0MDYxLmh0bWw8L3NwYW4+PC9hPiwgSQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRvbuKAmXQgYmVsaWV2ZSB0aGF0IHRoYXQgcGFydGlj dWxhciBpc3N1ZSBpcyBvcGVuLiZuYnNwOyBJdCBoYWQgYmVlbg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGV4dGVuc2l2ZWx5IGRpc2N1c3NlZCB3aXRoaW4g dGhlIHdvcmtpbmcgZ3JvdXAgbXVsdGlwbGUgdGltZXMgYW5kIHRoZQ0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGlzc3VlIHdhcyBleHBsaWNpdGx5IGNsb3Nl ZCBieSB0aGUgY2hhaXJzLCBsZWF2aW5nIHRoZSBzdGF0dXMgcXVvIGluDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcGxhY2UgaW4gd2hpY2ggdGhlcmUgYXJl IHJlcXVpcmVkIGFsZ29yaXRobXMgZm9yIGludGVyb3BlcmFiaWxpdHkgcmVhc29ucy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgSSdtIGdvaW5nIHRvIGFkZCBvbmUgbW9yZSBxdWVzdGlvbiB0 byB0aGUgcmV2aWV3IGFzIEkgaGFkIHRoZSBzYW1lDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgdGhvdWdodCBhcyBTY290dCAmYW1wOyBCdXJ0IGluIHRoZWly IHJldmlldyBvZiBKV0EgKGFuZCBhbHNvIGluIEpXUykuJm5ic3A7IFdoeQ0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFyZSB0aGVyZSBubyBvdGhlciBvcHRp b25zIGluIGFkZGl0aW9uIHRvIFNIQTE/Jm5ic3A7IFRoZSByZXNwb25zZSB0byBTY290dA0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHBvaW50ZWQgYmFjayB0 byBlYXJseSBXRyBkZWNpc2lvbnMsIGJ1dCBJIGhhdmUgaGVhcmQgdGhpcyBjb25jZXJuIGZyb20N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBvdGhlcnMgYW5k IGhhdmUgaXQgbXlzZWxmLCBzbyBJIGFtIG5vdCBzdXJlIHRoaXMgb25lIGlzIHJlc29sdmVkLiZu YnNwOyBJJ2QgbGlrZSB0byByZXZpc2l0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50 L21zZzA0MDIwLmh0bWwiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1 cnJlbnQvbXNnMDQwMjAuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IE1pa2UmZ3Q7IElmIGFkZGluZyBhIG5ldyDigJxSU0EtT0FFUC0yNTbigJ0gYWxnb3JpdGhtIGlk ZW50aWZpZXIgZm9yIOKAnFJTQUVTDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgTWlrZSZndDsgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBPcHRpbWFsIEFzeW1tZXRyaWMgRW5jcnlwdGlvbiBQYWRkaW5nIHVzaW5n IHRoZSBNR0YxIG1hc2sgZ2VuZXJhdGlvbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IGZ1bmN0aW9uIGFuZCB0aGUgU0hBLTI1NiBoYXNoIGZ1bmN0aW9u4oCd IHdvdWxkIG1ha2UgYSBudW1iZXIgb2YgcGVvcGxlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgbW9yZSBjb21mb3J0YWJsZSwgaW5jbHVkaW5nIHlvdSwgdGhl cmXigJlzIG5vdGhpbmcgd3Jvbmcgd2l0aCBkb2luZyBzby4mbmJzcDsNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIb3dldmVyLCBpdOKAmXMgYWxzbyBub3Qg Y2xlYXIgdGhhdCBpdCB3b3VsZCBiZSBvZiBtdWNoIHNob3J0LXRlcm0NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBwcmFjdGljYWwgYmVuZWZpdCBiZWNhdXNl LCBhdCBsZWFzdCBhcyBvZiB0aGUgaW1wbGVtZW50YXRpb24gc3VydmV5DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZG9uZSBpbiBKdWx5IDIwMTIsIG1hbnkg Y3J5cHRvIGxpYnJhcmllcyBkb27igJl0IGV4cG9zZSBhIHdheSB0byBnZXQgYXQgdGhpcyBhbGdv cml0aG0gY29tYmluYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IEhvd2V2ZXIsIHRoZSBzYW1lIGFyZ3VtZW50IGNvdWxkIGJlIG1hZGUgYWJvdXQgUlNB U1NBLVBTUywgd2hpY2ggd2UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBkaWQgYWRkIGlkZW50aWZpZXJzIGZvciBpbiB0aGUgZW5kLiZuYnNwOyBJbiBzaG9y dCwgSSBkb27igJl0IHRoaW5rIGFueW9uZSBpbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoZSB3b3JraW5nIGdyb3VwIHdvdWxkIHN0cmlkZW50bHkgb2Jq ZWN0IGlmIHlvdSBhc2tlZCBmb3IgdGhpcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IGFkZGl0aW9uYWwgYWxnb3JpdGhtIGlkZW50aWZpZXIgdG8gYmUgYWRk ZWQuJm5ic3A7IFlvdXIgY2FsbOKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ S00mZ3Q7IEknZCBzYXkgdG8gYWRkIGl0LiZuYnNwOyBJJ2xsIGhhdmUgYSBzaW1pbGFyIGNvbW1l bnQgZm9yIHRoZSBKV1MgZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPmZvciBTSEEyNTYgc3VwcG9ydCBvbiB0aHVtYnByaW50cy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPk1pa2UmZ3Q7IE9LIOKAkyBJ4oCZbGwgYWRkIGl0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+TWlrZSZndDsgUGVyIHlvdXIgSldTIGNv bW1lbnQsIFNIQS0xIHRodW1icHJpbnRzIGFyZSB3aWRlbHkgZGVwbG95ZWQuJm5ic3A7IEnigJlt IGF3YXJlIG9mIG5vIFNIQS0yNTYgY2VydGlmaWNhdGUgdGh1bWJwcmludCBkZXBsb3ltZW50cy4m bmJzcDsgSeKAmWxsIG5vdGUgdGhhdCBldmVuIGlmIFNIQS0xIHdlcmUgY29tcGxldGVseSBicm9r ZW4sIHRoYXQgd291bGRu4oCZdCBiZSBhIHNlY3VyaXR5DQogaXNzdWUgYmVjYXVzZSBpdOKAmXMg anVzdCBiZWluZyB1c2VkIHRvIGdlbmVyYXRlIGEgZGlnZXN0IG9mIHB1YmxpY2x5IGF2YWlsYWJs ZSBjZXJ0aWZpY2F0ZSBpbmZvcm1hdGlvbi4mbmJzcDsgSXTigJlzIG5vdCBiZWluZyB1c2VkIHRv IGNyeXB0b2dyYXBoaWNhbGx5IG9ic2N1cmUgYW55dGhpbmcuJm5ic3A7IChCdXQgdGhhdOKAmXMg YWN0dWFsbHkgYSBkaXNjdXNzaW9uIGZvciBhbm90aGVyIGRyYWZ0Lg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzAwNzBDMCI+Sjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEth dGhsZWVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5r cyBhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYnVuY2gs PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZXN0IHJlZ2FyZHMsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5LYXRobGVlbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+am9zZSBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhy ZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+am9zZUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2pvc2U8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFnYWluLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439A1A14A2TK5EX14MBXC288r_-- From nobody Thu May 1 09:12:08 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F037E1A6F83 for ; Thu, 1 May 2014 09:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19XZ3RQi_jAT for ; Thu, 1 May 2014 09:12:04 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0021A08D0 for ; Thu, 1 May 2014 09:12:02 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKU2JyUNpyY+VBmY3q8jOpDMYbHV6cy49y@postini.com; Thu, 01 May 2014 09:12:02 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s41GBxOl004738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 12:11:59 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 1 May 2014 12:11:45 -0400 From: "Hollenbeck, Scott" To: Mike Jones , Brian Campbell Thread-Topic: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-25 Thread-Index: AQHPU2RzcJshBhie6kap9ZpttPs22psrbfmQgACbV6A= Date: Thu, 1 May 2014 16:11:58 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F493C5A43@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <4E1F6AAD24975D4BA5B16804296739439A1A145A@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A1A145A@TK5EX14MBXC288.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F493C5A43BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/ucjvXDOB-zYxebLk91L_Q-Dq6tY Cc: "Kaliski, Burt" , "jose@ietf.org" Subject: Re: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-25 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 16:12:07 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F493C5A43BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks fine to me - thanks! Scott From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, May 01, 2014 3:03 AM To: Hollenbeck, Scott; Brian Campbell Cc: jose@ietf.org; Kaliski, Burt Subject: RE: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorit= hms-25 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-3= .4 has been augmented to clarify that the R and S representations conform t= o SEC1. I hope that this addresses the issue that you raised, Scott. And = thanks for the useful follow-up comments, Brian. Thanks all, -- Mike From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Tuesday, April 08, 2014 12:43 PM To: Mike Jones Cc: Hollenbeck, Scott; jose@ietf.org; Kaliski, Burt Subject: Re: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorit= hms-25 But that section (6.2.1.2) is about the EC parameters x and y in JWK. The c= omment was about the ECDSA signature values R & S in section 3.4 for JWS. I= believe that Scott is correct in saying that it is currently ambiguous and= could be clarified. I think that left zero padding is what was intended an= d what most of us have (eventually) inferred should be done. But it should = probably be stated explicitly. On Mon, Apr 7, 2014 at 3:57 PM, Mike Jones > wrote: Thanks for the useful reviews, Scott and Burt. Replies are inline. -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On = Behalf Of Hollenbeck, Scott Sent: Friday, April 04, 2014 5:43 PM To: jose@ietf.org Cc: Kaliski, Burt Subject: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-= 25 Sec. 3.4: For ECDSA P-521 SHA-512, as noted, "R and S will be 521 bits eac= h, resulting in a 132-octet sequence." Unclear how R and S are to be conve= rted into respective 66-octet values (pad with 0 bits on the left versus ri= ght). Should be consistent with practice in other specifications, e.g., IE= EE 1363. Per http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#secti= on-6.2.1.2, this is specified by the SEC1 specification, which the "x" and = "y" definitions reference. (SEC1 specifies padding on the left in Section = 2.3.1 - "BitString-to-OctetString Conversion".) --_000_831693C2CDA2E849A7D7A712B24E257F493C5A43BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks fine to me – thanks!

 

Scott<= o:p>

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, May 01, 2014 3:03 AM
To: Hollenbeck, Scott; Brian Campbell
Cc: jose@ietf.org; Kaliski, Burt
Subject: RE: [jose] WG Last Call Comments: draft-ietf-jose-json-web-= algorithms-25

 

http://too= ls.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-3.4 has been augmented to clarify that the R and S representations conform to = SEC1.  I hope that this addresses the issue that you raised, Scott.&nb= sp; And thanks for the useful follow-up comments, Brian.<= /p>

 <= /p>

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

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

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@ping= identity.com]
Sent: Tuesday, April 08, 2014 12:43 PM
To: Mike Jones
Cc: Hollenbeck, Scott; jose@ietf.or= g; Kaliski, Burt
Subject: Re: [jose] WG Last Call Comments: draft-ietf-jose-json-web-= algorithms-25

 

But that section (6.2.1.2) is about the EC parameter= s x and y in JWK. The comment was about the ECDSA signature values R & = S in section 3.4 for JWS. I believe that Scott is correct in saying that it= is currently ambiguous and could be clarified. I think that left zero padding is what was intended and what most of us ha= ve (eventually) inferred should be done. But it should probably be stated e= xplicitly.

 

On Mon, Apr 7, 2014 at 3:57 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Thanks for the useful reviews, Scott and Burt.  Replies are inline.

-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Hollenbeck, Scott
Sent: Friday, April 04, 2014 5:43 PM
To: jose@ietf.org Cc: Kaliski, Burt
Subject: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-= 25

Sec. 3.4:  For ECDSA P-521 SHA-512, as noted, "R and S will be= 521 bits each, resulting in a 132-octet sequence."  Unclear how = R and S are to be converted into respective 66-octet values (pad with 0 bit= s on the left versus right).  Should be consistent with practice in other specifications, e.g., IEEE 1363.

 

Per http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#sec= tion-6.2.1.2, this is specified by the SEC1 specification, which the “x” and= “y” definitions reference.  (SEC1 specifies padding on th= e left in Section 2.3.1 – “BitString-to-OctetString Conversion&= #8221;.)

--_000_831693C2CDA2E849A7D7A712B24E257F493C5A43BRN1WNEXMBX01vc_-- From nobody Thu May 1 10:46:53 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1091A6FD9 for ; Thu, 1 May 2014 10:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT1B2SJXbRLk for ; Thu, 1 May 2014 10:46:47 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 55F451A6FCF for ; Thu, 1 May 2014 10:46:47 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id p9so2363684lbv.34 for ; Thu, 01 May 2014 10:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qZ4iEytPDHRvMhOyWAsru0TWWqnXBrt+tIveC5lyefE=; b=S0WojG9ZUM4T2dV0FjnTRapwwcHN9FPoCC6F8kusIIlSIZv82g/tni3mEwICs4N0N1 t9JWUCICpnRq+0dZYYxqRBiHKuoE33lMaz8MV03vgyfyh1SFr5XGfB3KpkZJkmjeKjvA Ytc2BaLBcaFq9pREtyjbXAKmGEoxozxa+rfUotdREYH/NNT2QGo07U8GIqSelJCWwSfN Zj6koyzgwrETD/Md+N4a87BjpsAIT4rkREIUiYz18SiJQTS9sJ5S/p371Xzts6kG++4Y 098BE8rArbT0kMVgd1LXMKGO7SPJ5O1SQbP2DcO3rssvw2zF57OfZQ5bjiV5fiZb86Nr YzYw== MIME-Version: 1.0 X-Received: by 10.152.170.193 with SMTP id ao1mr8511960lac.27.1398966404797; Thu, 01 May 2014 10:46:44 -0700 (PDT) Received: by 10.112.26.142 with HTTP; Thu, 1 May 2014 10:46:44 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A1A14A2@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439A15D3B1@TK5EX14MBXC286.redmond.corp.microsoft.com> <00db01cf5a82$db1c7f80$91557e80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739439A1971D7@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A14A2@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Thu, 1 May 2014 13:46:44 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/jose/SJyp5qNPUoVO4DX_IG2eo09s1aU Cc: "jose@ietf.org" Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:46:51 -0000 Hi Mike, Thanks for posting the updated draft. At a minimum, the security considerations update still needs to be updated. I'd like an okay from Jim, the document shepherd when he thinks this is all ready in case I am missing any other open issues. The rest is in-line as this seems to summarize all of the issues and there were discussions in other threads that I would prefer to not see them get lost. On Thu, May 1, 2014 at 3:09 AM, Mike Jones wr= ote: > The algorithm name =E2=80=9CRSA-OAEP-256=E2=80=9D for RSAES OAEP using SH= A-256 and MGF1 with > SHA-256 has been added at > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section= -4.3, > per your request, Kathleen. > > > > > -- Mike > > > > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Friday, April 25, 2014 6:38 PM > > > To: Kathleen Moriarty; Jim Schaad > Cc: jose@ietf.org; draft-ietf-jose-json-web-algorithms@tools.ietf.org > > Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms > > > > Thanks, Kathleen. Comments are inline, marked =E2=80=9CMike>=E2=80=9D=E2= =80=A6 > > > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Friday, April 25, 2014 2:07 PM > To: Jim Schaad > Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org; > jose@ietf.org > Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms > > > > Sorry for the delay in my response. I'll answer in-line below. > > > > Thanks! > > > > On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad wrot= e: > >> > >> > >> > >> > >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones > >> Sent: Thursday, April 17, 2014 10:46 AM > >> To: Kathleen Moriarty; jose@ietf.org > >> Cc: draft-ietf-jose-json-web-algorithms@tools.ietf.org > >> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms > >> > >> > >> > >> Thanks for taking the time to do the review, Kathleen. Responses are > >> inline, flagged by =E2=80=9CMike>=E2=80=9D. I also pasted your follow-o= n note in and > >> responded to it as well. > >> > >> > >> > >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > >> Sent: Thursday, April 17, 2014 7:51 AM > >> To: jose@ietf.org > >> Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org > >> Subject: AD review of draft-ietf-jose-json-web-algorithms > >> > >> > >> > >> Hello Mike & JOSE members, > >> > >> > >> > >> I am working my way through the requested reviews to progress the JOSE > >> drafts and can see a lot of work has been done, thank you. As I read > >> through the Algorithms (JWA) draft there are some changes that will > >> need to be made to avoid problems during the IESG review. This is a > >> pretty big change for the draft, but will help make the review and >> approval faster. > >> Typically, the lists of algorithms are handled through a draft update > >> as opposed to creating an IANA registry. A good example is a recent > >> update of a draft in the IPSECME working group so you can see the > >> structure and the precedence for this model. > >> > >> > >> > >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts > >> > >> > >> > >> Mike> So you=E2=80=99re suggesting that future JWA drafts might obsolete= the > >> Mike> current > >> one, much like draft-ietf-ipsecme-esp-ah-reqts will obsolete RFC 4835, > >> which obsoleted RFC 4305, etc.? If so, could work on revising the JWA > >> draft accordingly and send proposed changes to the working group. > >> > >> > > KM> I am not sure where Jim's response is, but I have been looking > > into this. My initial message came after some conversations with Sean. = In > response to your posts, I reached out to a couple of other ADs who may ha= ve > had concerns and *think* we are okay as long as the registries will be us= ed > with a designated expert review to add to the registry. If a draft is > required for an update, that would cause problems as opposed to a draft w= ith > no registries. Sorry for the confusion here. > > > > Mike> Jim=E2=80=99s response is at > http://www.ietf.org/mail-archive/web/jose/current/msg04071.html, starting > with =E2=80=9C[JLS] Kathleen, I don=E2=80=99t know that I agree with this= statement. There > are a number of different places where IANA registries are used for the > purpose of having lists of algorithms.=E2=80=9D All the registries estab= lished > already require expert review, as described at > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section= -7. > So it sounds like we should be OK. That=E2=80=99s good. Thanks for work= ing the > issue. > > > >> > >> Now for other edits and questions: > >> > >> > >> > >> Section 3.6 - Can you explain why would this be included? If you are > >> not going to sign, I am not sure why one would use JOSE at all. > >> > >> > >> > >> Mike> This is included to enable representing content that is > >> Mike> optionally > >> signed in protocols using JWS. Having this means that whether or not > >> the content is signed, it can use a uniform representation, which is > >> easy to parse. This is in production use, for instance, to enable > >> OAuth authorization request messages that are optionally signed. > >> Sometimes content need not be signed at the JWS level because it=E2=80= =99s > >> integrity protected by other protocol layers =E2=80=93 in particular, of= ten by > >> the use of TLS. Another use case is where signing adds additional > >> optional value, but where there=E2=80=99s no harm in using unsigned cont= ent =E2=80=93 > >> for instance, while normal OAuth requests are inline and unsigned, a > >> registered extension enables request parameters to be passed by > >> reference, rather than by value; the object referenced containing the > >> parameters is a JWS; the JWS can optionally be signed. The current, > >> carefully refined treatment of =E2=80=9Cnone=E2=80=9D is the result of s= ubstantial mailing >> list discussions and discussions on working group calls. > >> While a less parallel treatment of unsigned JWSs was proposed in > >> http://trac.tools.ietf.org/wg/jose/trac/ticket/36, this alternative > >> syntax was rejected by the working group in favor of the current approac= h. > >> > >> > > KM> I responded to Vladamir on this one and would just like to know if > > there is WG consensus behind the decision. Can you point me to discussio= ns > on this? > > > > Mike> Brian Campbell did a good job summarizing the consensus in his note > http://www.ietf.org/mail-archive/web/jose/current/msg04082.html. Jim Sch= aad > documented the consensus in his note closing issue #36 at the end of > http://trac.tools.ietf.org/wg/jose/trac/ticket/36. > > > > Mike> This was extensively discussed on a thread titled =E2=80=9C[jose] #= 36: > Algorithm "none" should be removed=E2=80=9D between 7/31/13 and 8/22/13 a= nd then > also on a follow-up thread named =E2=80=9C[jose] Text about applications = and > "alg":"none"=E2=80=9D between 9/3/13 and 9/9/13. The latter thread resul= ted from an > action items from the preceding interim working group call (the agenda fo= r > which was published at > http://www.ietf.org/proceedings/interim/2013/08/19/jose/agenda/agenda-int= erim-2013-jose-5). > > > > Mike> The text agreed to by the working group that Brian referred to was > added in draft-ietf-jose-json-web-algorithms-16, published on 9/15/13. J= im > closed the issue on 10/28/13. > My read of the threads and issue tracker was that implementations won out to close this discussion, but that there was no consensus. There were many involved in the discussion that provided arguments and support for not including alg none. I'll support this as a WG decision based on implementations, as that's how I read it. I appreciate all of the feedback on actual use of this as it will be helpful in case this comes up during last call. > > >> > >> Section 5.2 - The write up of this section seems a bit more > >> complicated than necessary. It seems it would have just been simpler > >> to state that the sizes vary as required by the algorithms and key > >> lengths used rather than providing the differences from one to the next. >> Can you simplify this? > >> > >> After looking through some of the mailing list discussions, it seems > >> there was already agreement to slim this and other sections down by > >> pointing to the draft-mcgrew-aead-aes-cbc-hmac-sha2 > >> > >> > >> > >> http://www.ietf.org/mail-archive/web/jose/current/msg02276.html > >> > >> Can I get an update as to where that stands, referencing what you can > >> from that draft as opposed to duplicating text? Thanks! > >> > >> Mike> Sure. The key part of the message you cited is =E2=80=9COnce the = McGrew > >> Mike> draft > >> has been refactored to separate the description of the calculation > >> steps (which JOSE is using) from the AEAD representation steps (which > >> JOSE is not using), and to include test vector values that show > >> results without performing the AEAD representation concatenations, I > >> agree that we'll be able to just reference it, rather than duplicating > >> it.=E2=80=9D The problem is that the refactoring was never done. The > >> algorithm description in > >> draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the > >> ciphertext C, as described, also includes the IV value as a prefix and > >> the authentication tag T as a suffix, rather than treating each of > >> those as separate values. The test vectors do the same. Yes, David > >> added appendix B saying that the values could be treated as separate, > >> but the write-up does no favors to implementers, as both the core > >> algorithm description and the test vectors assume they are combined. > >> (I personally know that working out how to treat them as separate from > >> David=E2=80=99s current draft is a tedious and error-prone exercise, hav= ing > >> had to do so to tease them apart for the current JWA write-up.) David > >> has been asked about doing the refactoring several times by multiple > >> parties, but he=E2=80=99s a busy guy, and I don=E2=80=99t think it=E2=80= =99s ever reached the > >> top of his queue. As it is, the JWA description is clear and > >> semantically equivalent and implementers have shown that they can > >> successfully build it. Finally, we wouldn=E2=80=99t want to take a norm= ative > >> dependency upon a draft that appears to have been largely abandoned > >> (or at least neglected), as doing so could indefinitely stall publicatio= n >> of RFC versions of the JOSE specs. > >> > >> > >> > >> [JLS] I always considered this to be a sufficient refactoring to use > >> the mcgrew draft as a basis. I did not have the same type of problems > >> with breaking the test vectors apart that you seem to have had. > >> > > > > KM> OK, has anyone reached out to Dave McGrew to discuss? How can we > > clear this up? > > > > Mike> I=E2=80=99d had in-person and phone conversations with him about it= last year, > but not much happened as a result. > > > > Mike> I wrote more about your question at > http://www.ietf.org/mail-archive/web/jose/current/msg04074.html in which = I > pointed out errors and sources of confusion in David=E2=80=99s draft that= would > complicate life for developers and possibly result in incorrect > implementations; Jim responded at > http://www.ietf.org/mail-archive/web/jose/current/msg04075.html. I=E2=80= =99ll send > a note to David pointing these out and offering to produce proposed chang= es > for him to incorporate, but unless he either decides to devote bandwidth = to > advancing the draft (it=E2=80=99s already expired once) or is willing to = delegate it > to us to do so, I think we don=E2=80=99t have much choice but to continue= to have a > complete and accurate description of the algorithms in the JWA doc, and l= et > his draft advance at its own pace. I=E2=80=99ll note that we also don=E2= =80=99t have a > publication vehicle for the draft to become an RFC, because it=E2=80=99s = not in any > working group, nor does it have AD sponsorship that I=E2=80=99m aware of. > > Thank you, please keep us posted on the status/progress so we know how to move forward. > >> > >> > >> Security Considerations: While it is true the content is covered in > >> other places, this section could benefit from improvement before it > >> goes to the SecDir review. The second sentence in the first paragraph > >> says the > >> following: > >> > >> Among these issues are > >> > >> protecting the user's private and symmetric keys, preventing > >> various > >> > >> attacks, and helping the user avoid mistakes such as inadvertently > >> > >> encrypting a message for the wrong recipient. > >> > >> It would be helpful if you could expand the text and make it more > >> descriptive and applicable to this document. For example, shouldn=E2=80= =99t > >> the first section say user=E2=80=99s private asymmetric and symmetric ke= ys? I > >> assume that is what was intended with private, but it reads funny to > >> me without that. The only =E2=80=98attack=E2=80=99 or caution mentioned= in the > >> document is for the application to prevent a user from selecting the > >> wrong key. Please include some attacks that developers and > >> implementers should be aware and cautioned on, or state that specific > >> attacks and considers are detailed in the subsections to follow. > >> > >> > >> > >> Mike> OK, I can work on expanding that. There are some other attacks > >> mentioned in the other drafts, such as timing attacks, which can > >> probably at least be mentioned here. I=E2=80=99ll send draft text to th= e list > >> and consult with you before doing anything to the actual drafts. > >> Specific suggestions from working group participants would also be highl= y >> appreciated. > >> > The Security Considerations section requires updating, let me know when this has been done. Thanks! >> > > KM> Great, thank you! > >> > >> I think that's it for now. Although I do need to look through some > >> more of the previous conversations on the mailing list and in the issue >> tracker. > >> > >> > >> > >> I see there are some open discussions, like the one Richard raised > >> yesterday that need to be resolved in the document as well before we > >> move forward with this one. Thanks for all of your effort on this draft= !! > >> > >> > >> > >> Mike> Per my note > >> http://www.ietf.org/mail-archive/web/jose/current/msg04061.html, I > >> don=E2=80=99t believe that that particular issue is open. It had been > >> extensively discussed within the working group multiple times and the > >> issue was explicitly closed by the chairs, leaving the status quo in > >> place in which there are required algorithms for interoperability reason= s. > >> > >> > >> > >> I'm going to add one more question to the review as I had the same > >> thought as Scott & Burt in their review of JWA (and also in JWS). Why > >> are there no other options in addition to SHA1? The response to Scott > >> pointed back to early WG decisions, but I have heard this concern from > >> others and have it myself, so I am not sure this one is resolved. I'd >> like to revisit it. > >> > >> > >> > >> http://www.ietf.org/mail-archive/web/jose/current/msg04020.html > >> > >> > >> > >> Mike> If adding a new =E2=80=9CRSA-OAEP-256=E2=80=9D algorithm identifie= r for =E2=80=9CRSAES > >> Mike> with > >> Optimal Asymmetric Encryption Padding using the MGF1 mask generation > >> function and the SHA-256 hash function=E2=80=9D would make a number of p= eople > >> more comfortable, including you, there=E2=80=99s nothing wrong with doin= g so. > >> However, it=E2=80=99s also not clear that it would be of much short-term > >> practical benefit because, at least as of the implementation survey > >> done in July 2012, many crypto libraries don=E2=80=99t expose a way to g= et at this >> algorithm combination. > >> However, the same argument could be made about RSASSA-PSS, which we > >> did add identifiers for in the end. In short, I don=E2=80=99t think any= one in > >> the working group would stridently object if you asked for this > >> additional algorithm identifier to be added. Your call=E2=80=A6 > >> > > KM> I'd say to add it. I'll have a similar comment for the JWS draft > > for SHA256 support on thumbprints. > > > > Mike> OK =E2=80=93 I=E2=80=99ll add it. > Thanks, and I see Scott's review and okay as well, which is helpful. > > > Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed. I=E2= =80=99m > aware of no SHA-256 certificate thumbprint deployments. I=E2=80=99ll not= e that even > if SHA-1 were completely broken, that wouldn=E2=80=99t be a security issu= e because > it=E2=80=99s just being used to generate a digest of publicly available c= ertificate > information. It=E2=80=99s not being used to cryptographically obscure an= ything. > (But that=E2=80=99s actually a discussion for another draft. J) > This is in place for the XML equivalents and should be possible for JSON. I used this at least 2 years ago in the XML Oxygen editor. I believe this has been brought up before in terms of JSON, so I am not the first. But it is another draft... I'd like to get through these all soon :-) > > >> > >> > >> -- > >> > >> > >> > >> Best regards, > >> > >> Kathleen > >> > >> > >> > >> Thanks a > >> bunch, > >> > >> -- Mike > >> > >> > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > Thanks > again, > > -- Mike > > Thanks for your help!! --=20 Best regards, Kathleen From nobody Thu May 1 11:11:24 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962E01A7028 for ; Thu, 1 May 2014 11:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX2qylMTBsEj for ; Thu, 1 May 2014 11:11:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 461551A093A for ; Thu, 1 May 2014 11:11:13 -0700 (PDT) Received: from BL2PR03MB162.namprd03.prod.outlook.com (10.255.230.145) by BL2PR03MB195.namprd03.prod.outlook.com (10.255.230.153) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 18:11:10 +0000 Received: from BL2PR03CA014.namprd03.prod.outlook.com (10.141.66.22) by BL2PR03MB162.namprd03.prod.outlook.com (10.255.230.145) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 18:11:08 +0000 Received: from BY2FFO11FD043.protection.gbl (2a01:111:f400:7c0c::143) by BL2PR03CA014.outlook.office365.com (2a01:111:e400:c1b::22) with Microsoft SMTP Server (TLS) id 15.0.934.12 via Frontend Transport; Thu, 1 May 2014 18:11:08 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD043.mail.protection.outlook.com (10.1.14.228) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Thu, 1 May 2014 18:11:08 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.63]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0181.007; Thu, 1 May 2014 18:10:27 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [jose] AD review of draft-ietf-jose-json-web-algorithms Thread-Index: AQHPWkx0MohT4foJy0+5ox2RzsAQFpsWAxPQgABOCICADI7/AIAAPl5QgAhEwzCAALLNAIAAA+lQ Date: Thu, 1 May 2014 18:10:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439A1A3C64@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439A15D3B1@TK5EX14MBXC286.redmond.corp.microsoft.com> <00db01cf5a82$db1c7f80$91557e80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739439A1971D7@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A14A2@TK5EX14MBXC288.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(52084003)(52604005)(51704005)(377454003)(479174003)(41574002)(40764003)(51444003)(164054003)(189002)(199002)(24454002)(13464003)(50986999)(80022001)(4396001)(79102001)(15975445006)(97736001)(54356999)(86612001)(76482001)(46102001)(92566001)(55846006)(2009001)(31966008)(20776003)(92726001)(77982001)(66066001)(83322001)(6806004)(85852003)(44976005)(19580395003)(80976001)(84676001)(19580405001)(86362001)(47776003)(83072002)(2656002)(81342001)(76176999)(99396002)(74502001)(81542001)(23676002)(87936001)(15202345003)(33656001)(50466002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB162; H:mail.microsoft.com; FPR:CE0CDDED.A3F2D3DD.FDD73D4B.9AAAF871.20A87; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01986AE76B Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/PI7vQsT1CCHmmOv0epyIWgt9_Cc Cc: "jose@ietf.org" Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:11:17 -0000 WWVzLCBJIHJlYWxpemUgdGhhdCBJIGhhdmVuJ3QgcmV2aXNlZCB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgeWV0LiAgSSBzdGFydGVkIHRvIGRvIGl0IGFuZCByZWFsaXplZCB0aGF0IGl0IHdh cyBhIG1vcmUgaW50cmljYXRlIGV4ZXJjaXNlIHRoYW4gSSdkIG9yaWdpbmFsbHkgYW50aWNpcGF0 ZWQsIHNvIGRlY2lkZWQgdG8gZ2V0IHRoZSAtMjYgZHJhZnRzIG91dCB3aXRoIHRoZSBlYXN5IHN0 dWZmIGZpcnN0LCBmb3Igd29ya2luZyBncm91cCByZXZpZXcuICBUaGVzZSBtb3N0bHkgYWRkcmVz cyBjb21tZW50cyBieSB5b3UsIFNjb3R0LCBIYW5uZXMgVHNjaG9mZW5pZyAod2hpY2ggd2FzIGFj dHVhbGx5IGEgY29tbWVudCBvbiBKV1QsIGJ1dCB0aGF0IGFwcGxpZWQgdG8gSk9TRSBhcyB3ZWxs KSwgYW5kIEFudG9uaW8gU2Fuc28uDQoNCldPUktJTkcgR1JPVVA6ICBJIHdvdWxkIGFwcHJlY2lh dGUgYW55IHNwZWNpZmljIHN1Z2dlc3Rpb25zIG9uIGFkZGl0aW9ucyB0aGF0IHlvdSdkIGxpa2Ug dG8gaGF2ZSBtYWRlIHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGF0IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0 aG1zLTI2I3NlY3Rpb24tOC4NCg0KSSBhbHNvIHJlYWxpemUgdGhhdCBJIHN0aWxsIG5lZWQgdG8g d3JpdGUgdGhlIG5vdGUgdG8gRGF2aWQgTWNHcmV3Lg0KDQpLYXRobGVlbiwgY2FuIHlvdSBwb2lu dCB1cyB0byB0aGUgWE1MIGVxdWl2YWxlbnRzIG9mIGNlcnRpZmljYXRlIHRodW1icHJpbnRzIHRo YXQgeW91IHVzZWQ/ICBUaGF0IGNvdWxkIGJlIGludGVyZXN0aW5nLiAgRllJLCBJIGFsc28gc3Vi bWl0dGVkIGFuIGluZGl2aWR1YWwgLTAwIEpTT04gdGh1bWJwcmludCBkcmFmdCBsYXN0IG1vbnRo IGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWpvc2UtandrLXRodW1i cHJpbnQtMDAgKGJlY2F1c2UgdGhlIG5lZWQgZm9yIGEgSlNPTi1iYXNlZCB0aHVtYnByaW50IGNh bWUgdXAgaW4gcHJhY3RpY2UpLCBidXQgSSdtIG5vdCBwcm9wb3NpbmcgdGhhdCB3ZSB0cnkgdG8g amFtIGl0IGludG8gSldTIGF0IHRoaXMgcG9pbnQuICBJdCdzIGZpbmUgZm9yIHRoYXQgdG8gYmUg d29yayBhZnRlciBhIHJlY2hhcnRlciwgc2hvdWxkIHRoZSBXRyB3YW50IHRvIHRha2UgaXQgdXAu DQoNCgkJCQlCZXN0IHdpc2hlcywNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5 LmlldGZAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBNYXkgMDEsIDIwMTQgMTA6NDcgQU0N ClRvOiBNaWtlIEpvbmVzDQpDYzogam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMNCg0KSGkgTWlr ZSwNCg0KVGhhbmtzIGZvciBwb3N0aW5nIHRoZSB1cGRhdGVkIGRyYWZ0LiAgQXQgYSBtaW5pbXVt LCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdXBkYXRlIHN0aWxsIG5lZWRzIHRvIGJlIHVw ZGF0ZWQuICBJJ2QgbGlrZSBhbiBva2F5IGZyb20gSmltLCB0aGUgZG9jdW1lbnQgc2hlcGhlcmQg d2hlbiBoZSB0aGlua3MgdGhpcyBpcyBhbGwgcmVhZHkgaW4gY2FzZSBJIGFtIG1pc3NpbmcgYW55 IG90aGVyIG9wZW4gaXNzdWVzLiAgVGhlIHJlc3QgaXMgaW4tbGluZSBhcyB0aGlzIHNlZW1zIHRv IHN1bW1hcml6ZSBhbGwgb2YgdGhlIGlzc3VlcyBhbmQgdGhlcmUgd2VyZSBkaXNjdXNzaW9ucyBp biBvdGhlciB0aHJlYWRzIHRoYXQgSSB3b3VsZCBwcmVmZXIgdG8gbm90IHNlZSB0aGVtIGdldCBs b3N0Lg0KDQpPbiBUaHUsIE1heSAxLCAyMDE0IGF0IDM6MDkgQU0sIE1pa2UgSm9uZXMgPE1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IFRoZSBhbGdvcml0aG0gbmFtZSDigJxS U0EtT0FFUC0yNTbigJ0gZm9yIFJTQUVTIE9BRVAgdXNpbmcgU0hBLTI1NiBhbmQgDQo+IE1HRjEg d2l0aA0KPiBTSEEtMjU2IGhhcyBiZWVuIGFkZGVkIGF0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTI2I3NlY3QNCj4gaW9u LTQuMywNCj4gcGVyIHlvdXIgcmVxdWVzdCwgS2F0aGxlZW4uDQo+DQo+DQo+DQo+DQo+IC0tIE1p a2UNCj4NCj4NCj4NCj4gRnJvbTogam9zZSBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNCj4gU2VudDogRnJpZGF5LCBBcHJpbCAyNSwgMjAxNCA2 OjM4IFBNDQo+DQo+DQo+IFRvOiBLYXRobGVlbiBNb3JpYXJ0eTsgSmltIFNjaGFhZA0KPiBDYzog am9zZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXNAdG9vbHMu aWV0Zi5vcmcNCj4NCj4gU3ViamVjdDogUmU6IFtqb3NlXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMNCj4NCj4NCj4NCj4gVGhhbmtzLCBLYXRobGVlbi4g IENvbW1lbnRzIGFyZSBpbmxpbmUsIG1hcmtlZCDigJxNaWtlPuKAneKApg0KPg0KPg0KPg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqb3NlIFttYWlsdG86am9zZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gDQo+IE1vcmlhcnR5DQo+IFNlbnQ6 IEZyaWRheSwgQXByaWwgMjUsIDIwMTQgMjowNyBQTQ0KPiBUbzogSmltIFNjaGFhZA0KPiBDYzog TWlrZSBKb25lczsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXNAdG9vbHMuaWV0 Zi5vcmc7DQo+IGpvc2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtqb3NlXSBBRCByZXZpZXcg b2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMNCj4NCj4NCj4NCj4gU29ycnkg Zm9yIHRoZSBkZWxheSBpbiBteSByZXNwb25zZS4gIEknbGwgYW5zd2VyIGluLWxpbmUgYmVsb3cu DQo+DQo+DQo+DQo+IFRoYW5rcyENCj4NCj4NCj4NCj4gT24gVGh1LCBBcHIgMTcsIDIwMTQgYXQg NToyMCBQTSwgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQo+DQo+ Pg0KPg0KPj4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4gRnJvbTogam9zZSBbbWFpbHRvOmpvc2UtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNCj4NCj4+IFNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAxNywgMjAxNCAxMDo0NiBBTQ0KPg0KPj4gVG86IEthdGhsZWVuIE1vcmlhcnR5 OyBqb3NlQGlldGYub3JnDQo+DQo+PiBDYzogZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29y aXRobXNAdG9vbHMuaWV0Zi5vcmcNCj4NCj4+IFN1YmplY3Q6IFJlOiBbam9zZV0gQUQgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zDQo+DQo+Pg0KPg0KPj4NCj4N Cj4+DQo+DQo+PiBUaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byBkbyB0aGUgcmV2aWV3LCBL YXRobGVlbi4gIFJlc3BvbnNlcyBhcmUNCj4NCj4+IGlubGluZSwgZmxhZ2dlZCBieSDigJxNaWtl PuKAnS4gIEkgYWxzbyBwYXN0ZWQgeW91ciBmb2xsb3ctb24gbm90ZSBpbiBhbmQNCj4NCj4+IHJl c3BvbmRlZCB0byBpdCBhcyB3ZWxsLg0KPg0KPj4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4gRnJvbTog S2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNv bV0NCj4NCj4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNywgMjAxNCA3OjUxIEFNDQo+DQo+PiBU bzogam9zZUBpZXRmLm9yZw0KPg0KPj4gQ2M6IE1pa2UgSm9uZXM7IGRyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1hbGdvcml0aG1zQHRvb2xzLmlldGYub3JnDQo+DQo+PiBTdWJqZWN0OiBBRCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMNCj4NCj4+DQo+DQo+Pg0K Pg0KPj4NCj4NCj4+IEhlbGxvIE1pa2UgJiBKT1NFIG1lbWJlcnMsDQo+DQo+Pg0KPg0KPj4NCj4N Cj4+DQo+DQo+PiBJIGFtIHdvcmtpbmcgbXkgd2F5IHRocm91Z2ggdGhlIHJlcXVlc3RlZCByZXZp ZXdzIHRvIHByb2dyZXNzIHRoZSANCj4+IEpPU0UNCj4NCj4+IGRyYWZ0cyBhbmQgY2FuIHNlZSBh IGxvdCBvZiB3b3JrIGhhcyBiZWVuIGRvbmUsIHRoYW5rIHlvdS4gIEFzIEkgcmVhZA0KPg0KPj4g dGhyb3VnaCB0aGUgQWxnb3JpdGhtcyAoSldBKSBkcmFmdCB0aGVyZSBhcmUgc29tZSBjaGFuZ2Vz IHRoYXQgd2lsbA0KPg0KPj4gbmVlZCB0byBiZSBtYWRlIHRvIGF2b2lkIHByb2JsZW1zIGR1cmlu ZyB0aGUgSUVTRyByZXZpZXcuICBUaGlzIGlzIGENCj4NCj4+IHByZXR0eSBiaWcgY2hhbmdlIGZv ciB0aGUgZHJhZnQsIGJ1dCB3aWxsIGhlbHAgbWFrZSB0aGUgcmV2aWV3IGFuZCANCj4+IGFwcHJv dmFsIGZhc3Rlci4NCj4NCj4+IFR5cGljYWxseSwgdGhlIGxpc3RzIG9mIGFsZ29yaXRobXMgYXJl IGhhbmRsZWQgdGhyb3VnaCBhIGRyYWZ0IHVwZGF0ZQ0KPg0KPj4gYXMgb3Bwb3NlZCB0byBjcmVh dGluZyBhbiBJQU5BIHJlZ2lzdHJ5LiAgQSBnb29kIGV4YW1wbGUgaXMgYSByZWNlbnQNCj4NCj4+ IHVwZGF0ZSBvZiBhIGRyYWZ0IGluIHRoZSBJUFNFQ01FIHdvcmtpbmcgZ3JvdXAgc28geW91IGNh biBzZWUgdGhlDQo+DQo+PiBzdHJ1Y3R1cmUgYW5kIHRoZSBwcmVjZWRlbmNlIGZvciB0aGlzIG1v ZGVsLg0KPg0KPj4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLWVzcC1haC1yZXF0cw0KPg0KPj4NCj4NCj4+DQo+ DQo+Pg0KPg0KPj4gTWlrZT4gU28geW914oCZcmUgc3VnZ2VzdGluZyB0aGF0IGZ1dHVyZSBKV0Eg ZHJhZnRzIG1pZ2h0IG9ic29sZXRlIHRoZQ0KPg0KPj4gTWlrZT4gY3VycmVudA0KPg0KPj4gb25l LCBtdWNoIGxpa2UgZHJhZnQtaWV0Zi1pcHNlY21lLWVzcC1haC1yZXF0cyB3aWxsIG9ic29sZXRl IFJGQyANCj4+IDQ4MzUsDQo+DQo+PiB3aGljaCBvYnNvbGV0ZWQgUkZDIDQzMDUsIGV0Yy4/ICBJ ZiBzbywgY291bGQgd29yayBvbiByZXZpc2luZyB0aGUgDQo+PiBKV0ENCj4NCj4+IGRyYWZ0IGFj Y29yZGluZ2x5IGFuZCBzZW5kIHByb3Bvc2VkIGNoYW5nZXMgdG8gdGhlIHdvcmtpbmcgZ3JvdXAu DQo+DQo+Pg0KPg0KPj4NCj4NCj4gS00+IEkgYW0gbm90IHN1cmUgd2hlcmUgSmltJ3MgcmVzcG9u c2UgaXMsIGJ1dCBJIGhhdmUgYmVlbiBsb29raW5nDQo+DQo+IGludG8gdGhpcy4gIE15IGluaXRp YWwgbWVzc2FnZSBjYW1lIGFmdGVyIHNvbWUgY29udmVyc2F0aW9ucyB3aXRoIA0KPiBTZWFuLiAg SW4gcmVzcG9uc2UgdG8geW91ciBwb3N0cywgSSByZWFjaGVkIG91dCB0byBhIGNvdXBsZSBvZiBv dGhlciANCj4gQURzIHdobyBtYXkgaGF2ZSBoYWQgY29uY2VybnMgYW5kICp0aGluayogd2UgYXJl IG9rYXkgYXMgbG9uZyBhcyB0aGUgDQo+IHJlZ2lzdHJpZXMgd2lsbCBiZSB1c2VkIHdpdGggYSBk ZXNpZ25hdGVkIGV4cGVydCByZXZpZXcgdG8gYWRkIHRvIHRoZSANCj4gcmVnaXN0cnkuICBJZiBh IGRyYWZ0IGlzIHJlcXVpcmVkIGZvciBhbiB1cGRhdGUsIHRoYXQgd291bGQgY2F1c2UgDQo+IHBy b2JsZW1zIGFzIG9wcG9zZWQgdG8gYSBkcmFmdCB3aXRoIG5vIHJlZ2lzdHJpZXMuICBTb3JyeSBm b3IgdGhlIGNvbmZ1c2lvbiBoZXJlLg0KPg0KPg0KPg0KPiBNaWtlPiBKaW3igJlzIHJlc3BvbnNl IGlzIGF0DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJl bnQvbXNnMDQwNzEuaHRtbCwgDQo+IHN0YXJ0aW5nIHdpdGgg4oCcW0pMU10gS2F0aGxlZW4sIEkg ZG9u4oCZdCBrbm93IHRoYXQgSSBhZ3JlZSB3aXRoIHRoaXMgDQo+IHN0YXRlbWVudC4gIFRoZXJl IGFyZSBhIG51bWJlciBvZiBkaWZmZXJlbnQgcGxhY2VzIHdoZXJlIElBTkEgDQo+IHJlZ2lzdHJp ZXMgYXJlIHVzZWQgZm9yIHRoZSBwdXJwb3NlIG9mIGhhdmluZyBsaXN0cyBvZiBhbGdvcml0aG1z LuKAnSAgDQo+IEFsbCB0aGUgcmVnaXN0cmllcyBlc3RhYmxpc2hlZCBhbHJlYWR5IHJlcXVpcmUg ZXhwZXJ0IHJldmlldywgYXMgDQo+IGRlc2NyaWJlZCBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0yNSNzZWN0aW9uLTcuDQo+ IFNvIGl0IHNvdW5kcyBsaWtlIHdlIHNob3VsZCBiZSBPSy4gIFRoYXTigJlzIGdvb2QuICBUaGFu a3MgZm9yIHdvcmtpbmcgDQo+IHRoZSBpc3N1ZS4NCj4NCj4NCj4NCj4+DQo+DQo+PiBOb3cgZm9y IG90aGVyIGVkaXRzIGFuZCBxdWVzdGlvbnM6DQo+DQo+Pg0KPg0KPj4NCj4NCj4+DQo+DQo+PiBT ZWN0aW9uIDMuNiAtIENhbiB5b3UgZXhwbGFpbiB3aHkgd291bGQgdGhpcyBiZSBpbmNsdWRlZD8g IElmIHlvdSBhcmUNCj4NCj4+IG5vdCBnb2luZyB0byBzaWduLCBJIGFtIG5vdCBzdXJlIHdoeSBv bmUgd291bGQgdXNlIEpPU0UgYXQgYWxsLg0KPg0KPj4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4gTWlr ZT4gVGhpcyBpcyBpbmNsdWRlZCB0byBlbmFibGUgcmVwcmVzZW50aW5nIGNvbnRlbnQgdGhhdCBp cw0KPg0KPj4gTWlrZT4gb3B0aW9uYWxseQ0KPg0KPj4gc2lnbmVkIGluIHByb3RvY29scyB1c2lu ZyBKV1MuICBIYXZpbmcgdGhpcyBtZWFucyB0aGF0IHdoZXRoZXIgb3Igbm90DQo+DQo+PiB0aGUg Y29udGVudCBpcyBzaWduZWQsIGl0IGNhbiB1c2UgYSB1bmlmb3JtIHJlcHJlc2VudGF0aW9uLCB3 aGljaCBpcw0KPg0KPj4gZWFzeSB0byBwYXJzZS4gIFRoaXMgaXMgaW4gcHJvZHVjdGlvbiB1c2Us IGZvciBpbnN0YW5jZSwgdG8gZW5hYmxlDQo+DQo+PiBPQXV0aCBhdXRob3JpemF0aW9uIHJlcXVl c3QgbWVzc2FnZXMgdGhhdCBhcmUgb3B0aW9uYWxseSBzaWduZWQuDQo+DQo+PiBTb21ldGltZXMg Y29udGVudCBuZWVkIG5vdCBiZSBzaWduZWQgYXQgdGhlIEpXUyBsZXZlbCBiZWNhdXNlIGl04oCZ cw0KPg0KPj4gaW50ZWdyaXR5IHByb3RlY3RlZCBieSBvdGhlciBwcm90b2NvbCBsYXllcnMg4oCT IGluIHBhcnRpY3VsYXIsIG9mdGVuIA0KPj4gYnkNCj4NCj4+IHRoZSB1c2Ugb2YgVExTLiAgQW5v dGhlciB1c2UgY2FzZSBpcyB3aGVyZSBzaWduaW5nIGFkZHMgYWRkaXRpb25hbA0KPg0KPj4gb3B0 aW9uYWwgdmFsdWUsIGJ1dCB3aGVyZSB0aGVyZeKAmXMgbm8gaGFybSBpbiB1c2luZyB1bnNpZ25l ZCBjb250ZW50IOKAkw0KPg0KPj4gZm9yIGluc3RhbmNlLCB3aGlsZSBub3JtYWwgT0F1dGggcmVx dWVzdHMgYXJlIGlubGluZSBhbmQgdW5zaWduZWQsIGENCj4NCj4+IHJlZ2lzdGVyZWQgZXh0ZW5z aW9uIGVuYWJsZXMgcmVxdWVzdCBwYXJhbWV0ZXJzIHRvIGJlIHBhc3NlZCBieQ0KPg0KPj4gcmVm ZXJlbmNlLCByYXRoZXIgdGhhbiBieSB2YWx1ZTsgdGhlIG9iamVjdCByZWZlcmVuY2VkIGNvbnRh aW5pbmcgdGhlDQo+DQo+PiBwYXJhbWV0ZXJzIGlzIGEgSldTOyB0aGUgSldTIGNhbiBvcHRpb25h bGx5IGJlIHNpZ25lZC4gIFRoZSBjdXJyZW50LA0KPg0KPj4gY2FyZWZ1bGx5IHJlZmluZWQgdHJl YXRtZW50IG9mIOKAnG5vbmXigJ0gaXMgdGhlIHJlc3VsdCBvZiBzdWJzdGFudGlhbCANCj4+IG1h aWxpbmcgbGlzdCBkaXNjdXNzaW9ucyBhbmQgZGlzY3Vzc2lvbnMgb24gd29ya2luZyBncm91cCBj YWxscy4NCj4NCj4+IFdoaWxlIGEgbGVzcyBwYXJhbGxlbCB0cmVhdG1lbnQgb2YgdW5zaWduZWQg SldTcyB3YXMgcHJvcG9zZWQgaW4NCj4NCj4+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dn L2pvc2UvdHJhYy90aWNrZXQvMzYsIHRoaXMgYWx0ZXJuYXRpdmUNCj4NCj4+IHN5bnRheCB3YXMg cmVqZWN0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgaW4gZmF2b3Igb2YgdGhlIGN1cnJlbnQgYXBw cm9hY2guDQo+DQo+Pg0KPg0KPj4NCj4NCj4gS00+IEkgcmVzcG9uZGVkIHRvIFZsYWRhbWlyIG9u IHRoaXMgb25lIGFuZCB3b3VsZCBqdXN0IGxpa2UgdG8ga25vdyBpZg0KPg0KPiB0aGVyZSBpcyBX RyBjb25zZW5zdXMgYmVoaW5kIHRoZSBkZWNpc2lvbi4gIENhbiB5b3UgcG9pbnQgbWUgdG8gDQo+ IGRpc2N1c3Npb25zIG9uIHRoaXM/DQo+DQo+DQo+DQo+IE1pa2U+IEJyaWFuIENhbXBiZWxsIGRp ZCBhIGdvb2Qgam9iIHN1bW1hcml6aW5nIHRoZSBjb25zZW5zdXMgaW4gaGlzIA0KPiBNaWtlPiBu b3RlDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQv bXNnMDQwODIuaHRtbC4gIEppbSANCj4gU2NoYWFkIGRvY3VtZW50ZWQgdGhlIGNvbnNlbnN1cyBp biBoaXMgbm90ZSBjbG9zaW5nIGlzc3VlICMzNiBhdCB0aGUgDQo+IGVuZCBvZiBodHRwOi8vdHJh Yy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzM2Lg0KPg0KPg0KPg0KPiBNaWtl PiBUaGlzIHdhcyBleHRlbnNpdmVseSBkaXNjdXNzZWQgb24gYSB0aHJlYWQgdGl0bGVkIOKAnFtq b3NlXSAjMzY6DQo+IEFsZ29yaXRobSAibm9uZSIgc2hvdWxkIGJlIHJlbW92ZWTigJ0gYmV0d2Vl biA3LzMxLzEzIGFuZCA4LzIyLzEzIGFuZCANCj4gdGhlbiBhbHNvIG9uIGEgZm9sbG93LXVwIHRo cmVhZCBuYW1lZCDigJxbam9zZV0gVGV4dCBhYm91dCBhcHBsaWNhdGlvbnMgDQo+IGFuZCAiYWxn Ijoibm9uZSLigJ0gYmV0d2VlbiA5LzMvMTMgYW5kIDkvOS8xMy4gIFRoZSBsYXR0ZXIgdGhyZWFk IA0KPiByZXN1bHRlZCBmcm9tIGFuIGFjdGlvbiBpdGVtcyBmcm9tIHRoZSBwcmVjZWRpbmcgaW50 ZXJpbSB3b3JraW5nIGdyb3VwIA0KPiBjYWxsICh0aGUgYWdlbmRhIGZvciB3aGljaCB3YXMgcHVi bGlzaGVkIGF0IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAx My8wOC8xOS9qb3NlL2FnZW5kYS9hZ2VuZGEtaW50ZXJpbS0yMDEzLWpvc2UtNSkuDQo+DQo+DQo+ DQo+IE1pa2U+IFRoZSB0ZXh0IGFncmVlZCB0byBieSB0aGUgd29ya2luZyBncm91cCB0aGF0IEJy aWFuIHJlZmVycmVkIHRvIA0KPiBNaWtlPiB3YXMNCj4gYWRkZWQgaW4gZHJhZnQtaWV0Zi1qb3Nl LWpzb24td2ViLWFsZ29yaXRobXMtMTYsIHB1Ymxpc2hlZCBvbiA5LzE1LzEzLiAgDQo+IEppbSBj bG9zZWQgdGhlIGlzc3VlIG9uIDEwLzI4LzEzLg0KPg0KDQpNeSByZWFkIG9mIHRoZSB0aHJlYWRz IGFuZCBpc3N1ZSB0cmFja2VyIHdhcyB0aGF0IGltcGxlbWVudGF0aW9ucyB3b24gb3V0IHRvIGNs b3NlIHRoaXMgZGlzY3Vzc2lvbiwgYnV0IHRoYXQgdGhlcmUgd2FzIG5vIGNvbnNlbnN1cy4gIFRo ZXJlIHdlcmUgbWFueSBpbnZvbHZlZCBpbiB0aGUgZGlzY3Vzc2lvbiB0aGF0IHByb3ZpZGVkIGFy Z3VtZW50cyBhbmQgc3VwcG9ydCBmb3Igbm90IGluY2x1ZGluZyBhbGcgbm9uZS4gIEknbGwgc3Vw cG9ydCB0aGlzIGFzIGEgV0cgZGVjaXNpb24gYmFzZWQgb24gaW1wbGVtZW50YXRpb25zLCBhcyB0 aGF0J3MgaG93IEkgcmVhZCBpdC4gIEkgYXBwcmVjaWF0ZSBhbGwgb2YgdGhlIGZlZWRiYWNrIG9u IGFjdHVhbCB1c2Ugb2YgdGhpcyBhcyBpdCB3aWxsIGJlIGhlbHBmdWwgaW4gY2FzZSB0aGlzIGNv bWVzIHVwIGR1cmluZyBsYXN0IGNhbGwuDQoNCj4NCj4NCj4+DQo+DQo+PiBTZWN0aW9uIDUuMiAt IFRoZSB3cml0ZSB1cCBvZiB0aGlzIHNlY3Rpb24gc2VlbXMgYSBiaXQgbW9yZQ0KPg0KPj4gY29t cGxpY2F0ZWQgdGhhbiBuZWNlc3NhcnkuICBJdCBzZWVtcyBpdCB3b3VsZCBoYXZlIGp1c3QgYmVl biBzaW1wbGVyDQo+DQo+PiB0byBzdGF0ZSB0aGF0IHRoZSBzaXplcyB2YXJ5IGFzIHJlcXVpcmVk IGJ5IHRoZSBhbGdvcml0aG1zIGFuZCBrZXkNCj4NCj4+IGxlbmd0aHMgdXNlZCByYXRoZXIgdGhh biBwcm92aWRpbmcgdGhlIGRpZmZlcmVuY2VzIGZyb20gb25lIHRvIHRoZSBuZXh0Lg0KPj4gQ2Fu IHlvdSBzaW1wbGlmeSB0aGlzPw0KPg0KPj4NCj4NCj4+IEFmdGVyIGxvb2tpbmcgdGhyb3VnaCBz b21lIG9mIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbnMsIGl0IHNlZW1zDQo+DQo+PiB0aGVy ZSB3YXMgYWxyZWFkeSBhZ3JlZW1lbnQgdG8gc2xpbSB0aGlzIGFuZCBvdGhlciBzZWN0aW9ucyBk b3duIGJ5DQo+DQo+PiBwb2ludGluZyB0byB0aGUgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1o bWFjLXNoYTINCj4NCj4+DQo+DQo+Pg0KPg0KPj4NCj4NCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDIyNzYuaHRtbA0KPg0KPj4NCj4NCj4+ IENhbiBJIGdldCBhbiB1cGRhdGUgYXMgdG8gd2hlcmUgdGhhdCBzdGFuZHMsIHJlZmVyZW5jaW5n IHdoYXQgeW91IGNhbg0KPg0KPj4gZnJvbSB0aGF0IGRyYWZ0IGFzIG9wcG9zZWQgdG8gZHVwbGlj YXRpbmcgdGV4dD8gIFRoYW5rcyENCj4NCj4+DQo+DQo+PiBNaWtlPiBTdXJlLiAgVGhlIGtleSBw YXJ0IG9mIHRoZSBtZXNzYWdlIHlvdSBjaXRlZCBpcyDigJxPbmNlIHRoZSANCj4+IE1pa2U+IE1j R3Jldw0KPg0KPj4gTWlrZT4gZHJhZnQNCj4NCj4+IGhhcyBiZWVuIHJlZmFjdG9yZWQgdG8gc2Vw YXJhdGUgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBjYWxjdWxhdGlvbg0KPg0KPj4gc3RlcHMgKHdo aWNoIEpPU0UgaXMgdXNpbmcpIGZyb20gdGhlIEFFQUQgcmVwcmVzZW50YXRpb24gc3RlcHMgKHdo aWNoDQo+DQo+PiBKT1NFIGlzIG5vdCB1c2luZyksIGFuZCB0byBpbmNsdWRlIHRlc3QgdmVjdG9y IHZhbHVlcyB0aGF0IHNob3cNCj4NCj4+IHJlc3VsdHMgd2l0aG91dCBwZXJmb3JtaW5nIHRoZSBB RUFEIHJlcHJlc2VudGF0aW9uIGNvbmNhdGVuYXRpb25zLCBJDQo+DQo+PiBhZ3JlZSB0aGF0IHdl J2xsIGJlIGFibGUgdG8ganVzdCByZWZlcmVuY2UgaXQsIHJhdGhlciB0aGFuIA0KPj4gZHVwbGlj YXRpbmcNCj4NCj4+IGl0LuKAnSAgVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgcmVmYWN0b3Jpbmcg d2FzIG5ldmVyIGRvbmUuICBUaGUNCj4NCj4+IGFsZ29yaXRobSBkZXNjcmlwdGlvbiBpbg0KPg0K Pj4gZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgaXMgd3JpdHRlbiBpbiBzdWNo IGEgd2F5IHRoYXQgdGhlDQo+DQo+PiBjaXBoZXJ0ZXh0IEMsIGFzIGRlc2NyaWJlZCwgYWxzbyBp bmNsdWRlcyB0aGUgSVYgdmFsdWUgYXMgYSBwcmVmaXggDQo+PiBhbmQNCj4NCj4+IHRoZSBhdXRo ZW50aWNhdGlvbiB0YWcgVCBhcyBhIHN1ZmZpeCwgcmF0aGVyIHRoYW4gdHJlYXRpbmcgZWFjaCBv Zg0KPg0KPj4gdGhvc2UgYXMgc2VwYXJhdGUgdmFsdWVzLiAgVGhlIHRlc3QgdmVjdG9ycyBkbyB0 aGUgc2FtZS4gIFllcywgRGF2aWQNCj4NCj4+IGFkZGVkIGFwcGVuZGl4IEIgc2F5aW5nIHRoYXQg dGhlIHZhbHVlcyBjb3VsZCBiZSB0cmVhdGVkIGFzIHNlcGFyYXRlLA0KPg0KPj4gYnV0IHRoZSB3 cml0ZS11cCBkb2VzIG5vIGZhdm9ycyB0byBpbXBsZW1lbnRlcnMsIGFzIGJvdGggdGhlIGNvcmUN Cj4NCj4+IGFsZ29yaXRobSBkZXNjcmlwdGlvbiBhbmQgdGhlIHRlc3QgdmVjdG9ycyBhc3N1bWUg dGhleSBhcmUgY29tYmluZWQuDQo+DQo+PiAoSSBwZXJzb25hbGx5IGtub3cgdGhhdCB3b3JraW5n IG91dCBob3cgdG8gdHJlYXQgdGhlbSBhcyBzZXBhcmF0ZSANCj4+IGZyb20NCj4NCj4+IERhdmlk 4oCZcyBjdXJyZW50IGRyYWZ0IGlzIGEgdGVkaW91cyBhbmQgZXJyb3ItcHJvbmUgZXhlcmNpc2Us IGhhdmluZw0KPg0KPj4gaGFkIHRvIGRvIHNvIHRvIHRlYXNlIHRoZW0gYXBhcnQgZm9yIHRoZSBj dXJyZW50IEpXQSB3cml0ZS11cC4pICANCj4+IERhdmlkDQo+DQo+PiBoYXMgYmVlbiBhc2tlZCBh Ym91dCBkb2luZyB0aGUgcmVmYWN0b3Jpbmcgc2V2ZXJhbCB0aW1lcyBieSBtdWx0aXBsZQ0KPg0K Pj4gcGFydGllcywgYnV0IGhl4oCZcyBhIGJ1c3kgZ3V5LCBhbmQgSSBkb27igJl0IHRoaW5rIGl0 4oCZcyBldmVyIHJlYWNoZWQgdGhlDQo+DQo+PiB0b3Agb2YgaGlzIHF1ZXVlLiAgQXMgaXQgaXMs IHRoZSBKV0EgZGVzY3JpcHRpb24gaXMgY2xlYXIgYW5kDQo+DQo+PiBzZW1hbnRpY2FsbHkgZXF1 aXZhbGVudCBhbmQgaW1wbGVtZW50ZXJzIGhhdmUgc2hvd24gdGhhdCB0aGV5IGNhbg0KPg0KPj4g c3VjY2Vzc2Z1bGx5IGJ1aWxkIGl0LiAgRmluYWxseSwgd2Ugd291bGRu4oCZdCB3YW50IHRvIHRh a2UgYSBub3JtYXRpdmUNCj4NCj4+IGRlcGVuZGVuY3kgdXBvbiBhIGRyYWZ0IHRoYXQgYXBwZWFy cyB0byBoYXZlIGJlZW4gbGFyZ2VseSBhYmFuZG9uZWQNCj4NCj4+IChvciBhdCBsZWFzdCBuZWds ZWN0ZWQpLCBhcyBkb2luZyBzbyBjb3VsZCBpbmRlZmluaXRlbHkgc3RhbGwgDQo+PiBwdWJsaWNh dGlvbiBvZiBSRkMgdmVyc2lvbnMgb2YgdGhlIEpPU0Ugc3BlY3MuDQo+DQo+Pg0KPg0KPj4NCj4N Cj4+DQo+DQo+PiBbSkxTXSAgSSBhbHdheXMgY29uc2lkZXJlZCB0aGlzIHRvIGJlIGEgc3VmZmlj aWVudCByZWZhY3RvcmluZyB0byB1c2UNCj4NCj4+IHRoZSBtY2dyZXcgZHJhZnQgYXMgYSBiYXNp cy4gIEkgZGlkIG5vdCBoYXZlIHRoZSBzYW1lIHR5cGUgb2YgDQo+PiBwcm9ibGVtcw0KPg0KPj4g d2l0aCBicmVha2luZyB0aGUgdGVzdCB2ZWN0b3JzIGFwYXJ0IHRoYXQgeW91IHNlZW0gdG8gaGF2 ZSBoYWQuDQo+DQo+Pg0KPg0KPg0KPg0KPiBLTT4gT0ssIGhhcyBhbnlvbmUgcmVhY2hlZCBvdXQg dG8gRGF2ZSBNY0dyZXcgdG8gZGlzY3Vzcz8gIEhvdyBjYW4gd2UNCj4NCj4gY2xlYXIgdGhpcyB1 cD8NCj4NCj4NCj4NCj4gTWlrZT4gSeKAmWQgaGFkIGluLXBlcnNvbiBhbmQgcGhvbmUgY29udmVy c2F0aW9ucyB3aXRoIGhpbSBhYm91dCBpdCBsYXN0IA0KPiBNaWtlPiB5ZWFyLA0KPiBidXQgbm90 IG11Y2ggaGFwcGVuZWQgYXMgYSByZXN1bHQuDQo+DQo+DQo+DQo+IE1pa2U+IEkgd3JvdGUgbW9y ZSBhYm91dCB5b3VyIHF1ZXN0aW9uIGF0DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwNzQuaHRtbCBpbiANCj4gd2hpY2ggSSBwb2ludGVk IG91dCBlcnJvcnMgYW5kIHNvdXJjZXMgb2YgY29uZnVzaW9uIGluIERhdmlk4oCZcyBkcmFmdCAN Cj4gdGhhdCB3b3VsZCBjb21wbGljYXRlIGxpZmUgZm9yIGRldmVsb3BlcnMgYW5kIHBvc3NpYmx5 IHJlc3VsdCBpbiANCj4gaW5jb3JyZWN0IGltcGxlbWVudGF0aW9uczsgSmltIHJlc3BvbmRlZCBh dCANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9t c2cwNDA3NS5odG1sLiAgSeKAmWxsIA0KPiBzZW5kIGEgbm90ZSB0byBEYXZpZCBwb2ludGluZyB0 aGVzZSBvdXQgYW5kIG9mZmVyaW5nIHRvIHByb2R1Y2UgDQo+IHByb3Bvc2VkIGNoYW5nZXMgZm9y IGhpbSB0byBpbmNvcnBvcmF0ZSwgYnV0IHVubGVzcyBoZSBlaXRoZXIgZGVjaWRlcyANCj4gdG8g ZGV2b3RlIGJhbmR3aWR0aCB0byBhZHZhbmNpbmcgdGhlIGRyYWZ0IChpdOKAmXMgYWxyZWFkeSBl eHBpcmVkIG9uY2UpIA0KPiBvciBpcyB3aWxsaW5nIHRvIGRlbGVnYXRlIGl0IHRvIHVzIHRvIGRv IHNvLCBJIHRoaW5rIHdlIGRvbuKAmXQgaGF2ZSANCj4gbXVjaCBjaG9pY2UgYnV0IHRvIGNvbnRp bnVlIHRvIGhhdmUgYSBjb21wbGV0ZSBhbmQgYWNjdXJhdGUgDQo+IGRlc2NyaXB0aW9uIG9mIHRo ZSBhbGdvcml0aG1zIGluIHRoZSBKV0EgZG9jLCBhbmQgbGV0IGhpcyBkcmFmdCANCj4gYWR2YW5j ZSBhdCBpdHMgb3duIHBhY2UuICBJ4oCZbGwgbm90ZSB0aGF0IHdlIGFsc28gZG9u4oCZdCBoYXZl IGEgDQo+IHB1YmxpY2F0aW9uIHZlaGljbGUgZm9yIHRoZSBkcmFmdCB0byBiZWNvbWUgYW4gUkZD LCBiZWNhdXNlIGl04oCZcyBub3QgaW4gYW55IHdvcmtpbmcgZ3JvdXAsIG5vciBkb2VzIGl0IGhh dmUgQUQgc3BvbnNvcnNoaXAgdGhhdCBJ4oCZbSBhd2FyZSBvZi4NCj4NCj4NCg0KVGhhbmsgeW91 LCBwbGVhc2Uga2VlcCB1cyBwb3N0ZWQgb24gdGhlIHN0YXR1cy9wcm9ncmVzcyBzbyB3ZSBrbm93 IGhvdyB0byBtb3ZlIGZvcndhcmQuDQoNCj4NCj4+DQo+DQo+Pg0KPg0KPj4gU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnM6IFdoaWxlIGl0IGlzIHRydWUgdGhlIGNvbnRlbnQgaXMgY292ZXJlZCBpbg0K Pg0KPj4gb3RoZXIgcGxhY2VzLCB0aGlzIHNlY3Rpb24gY291bGQgYmVuZWZpdCBmcm9tIGltcHJv dmVtZW50IGJlZm9yZSBpdA0KPg0KPj4gZ29lcyB0byB0aGUgU2VjRGlyIHJldmlldy4gIFRoZSBz ZWNvbmQgc2VudGVuY2UgaW4gdGhlIGZpcnN0IA0KPj4gcGFyYWdyYXBoDQo+DQo+PiBzYXlzIHRo ZQ0KPg0KPj4gZm9sbG93aW5nOg0KPg0KPj4NCj4NCj4+ICAgIEFtb25nIHRoZXNlIGlzc3VlcyBh cmUNCj4NCj4+DQo+DQo+PiAgICBwcm90ZWN0aW5nIHRoZSB1c2VyJ3MgcHJpdmF0ZSBhbmQgc3lt bWV0cmljIGtleXMsIHByZXZlbnRpbmcNCj4NCj4+IHZhcmlvdXMNCj4NCj4+DQo+DQo+PiAgICBh dHRhY2tzLCBhbmQgaGVscGluZyB0aGUgdXNlciBhdm9pZCBtaXN0YWtlcyBzdWNoIGFzIGluYWR2 ZXJ0ZW50bHkNCj4NCj4+DQo+DQo+PiAgICBlbmNyeXB0aW5nIGEgbWVzc2FnZSBmb3IgdGhlIHdy b25nIHJlY2lwaWVudC4NCj4NCj4+DQo+DQo+PiBJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBj b3VsZCBleHBhbmQgdGhlIHRleHQgYW5kIG1ha2UgaXQgbW9yZQ0KPg0KPj4gZGVzY3JpcHRpdmUg YW5kIGFwcGxpY2FibGUgdG8gdGhpcyBkb2N1bWVudC4gIEZvciBleGFtcGxlLCBzaG91bGRu4oCZ dA0KPg0KPj4gdGhlIGZpcnN0IHNlY3Rpb24gc2F5IHVzZXLigJlzIHByaXZhdGUgYXN5bW1ldHJp YyBhbmQgc3ltbWV0cmljIGtleXM/ICANCj4+IEkNCj4NCj4+IGFzc3VtZSB0aGF0IGlzIHdoYXQg d2FzIGludGVuZGVkIHdpdGggcHJpdmF0ZSwgYnV0IGl0IHJlYWRzIGZ1bm55IHRvDQo+DQo+PiBt ZSB3aXRob3V0IHRoYXQuICBUaGUgb25seSDigJhhdHRhY2vigJkgb3IgY2F1dGlvbiBtZW50aW9u ZWQgaW4gdGhlDQo+DQo+PiBkb2N1bWVudCBpcyBmb3IgdGhlIGFwcGxpY2F0aW9uIHRvIHByZXZl bnQgYSB1c2VyIGZyb20gc2VsZWN0aW5nIHRoZQ0KPg0KPj4gd3Jvbmcga2V5LiAgUGxlYXNlIGlu Y2x1ZGUgc29tZSBhdHRhY2tzIHRoYXQgZGV2ZWxvcGVycyBhbmQNCj4NCj4+IGltcGxlbWVudGVy cyBzaG91bGQgYmUgYXdhcmUgYW5kIGNhdXRpb25lZCBvbiwgb3Igc3RhdGUgdGhhdCBzcGVjaWZp Yw0KPg0KPj4gYXR0YWNrcyBhbmQgY29uc2lkZXJzIGFyZSBkZXRhaWxlZCBpbiB0aGUgc3Vic2Vj dGlvbnMgdG8gZm9sbG93Lg0KPg0KPj4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4gTWlrZT4gT0ssIEkg Y2FuIHdvcmsgb24gZXhwYW5kaW5nIHRoYXQuICBUaGVyZSBhcmUgc29tZSBvdGhlciBhdHRhY2tz DQo+DQo+PiBtZW50aW9uZWQgaW4gdGhlIG90aGVyIGRyYWZ0cywgc3VjaCBhcyB0aW1pbmcgYXR0 YWNrcywgd2hpY2ggY2FuDQo+DQo+PiBwcm9iYWJseSBhdCBsZWFzdCBiZSBtZW50aW9uZWQgaGVy ZS4gIEnigJlsbCBzZW5kIGRyYWZ0IHRleHQgdG8gdGhlIA0KPj4gbGlzdA0KPg0KPj4gYW5kIGNv bnN1bHQgd2l0aCB5b3UgYmVmb3JlIGRvaW5nIGFueXRoaW5nIHRvIHRoZSBhY3R1YWwgZHJhZnRz Lg0KPg0KPj4gU3BlY2lmaWMgc3VnZ2VzdGlvbnMgZnJvbSB3b3JraW5nIGdyb3VwIHBhcnRpY2lw YW50cyB3b3VsZCBhbHNvIGJlIA0KPj4gaGlnaGx5IGFwcHJlY2lhdGVkLg0KPg0KPj4NCj4NCg0K VGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gcmVxdWlyZXMgdXBkYXRpbmcsIGxl dCBtZSBrbm93IHdoZW4gdGhpcyBoYXMgYmVlbiBkb25lLiAgVGhhbmtzIQ0KPj4NCj4NCj4gS00+ IEdyZWF0LCB0aGFuayB5b3UhDQo+DQo+Pg0KPg0KPj4gSSB0aGluayB0aGF0J3MgaXQgZm9yIG5v dy4gQWx0aG91Z2ggSSBkbyBuZWVkIHRvIGxvb2sgdGhyb3VnaCBzb21lDQo+DQo+PiBtb3JlIG9m IHRoZSBwcmV2aW91cyBjb252ZXJzYXRpb25zIG9uIHRoZSBtYWlsaW5nIGxpc3QgYW5kIGluIHRo ZSANCj4+IGlzc3VlIHRyYWNrZXIuDQo+DQo+Pg0KPg0KPj4NCj4NCj4+DQo+DQo+PiBJIHNlZSB0 aGVyZSBhcmUgc29tZSBvcGVuIGRpc2N1c3Npb25zLCBsaWtlIHRoZSBvbmUgUmljaGFyZCByYWlz ZWQNCj4NCj4+IHllc3RlcmRheSB0aGF0IG5lZWQgdG8gYmUgcmVzb2x2ZWQgaW4gdGhlIGRvY3Vt ZW50IGFzIHdlbGwgYmVmb3JlIHdlDQo+DQo+PiBtb3ZlIGZvcndhcmQgd2l0aCB0aGlzIG9uZS4g IFRoYW5rcyBmb3IgYWxsIG9mIHlvdXIgZWZmb3J0IG9uIHRoaXMgZHJhZnQhIQ0KPg0KPj4NCj4N Cj4+DQo+DQo+Pg0KPg0KPj4gTWlrZT4gUGVyIG15IG5vdGUNCj4NCj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwNjEuaHRtbCwgSQ0KPg0K Pj4gZG9u4oCZdCBiZWxpZXZlIHRoYXQgdGhhdCBwYXJ0aWN1bGFyIGlzc3VlIGlzIG9wZW4uICBJ dCBoYWQgYmVlbg0KPg0KPj4gZXh0ZW5zaXZlbHkgZGlzY3Vzc2VkIHdpdGhpbiB0aGUgd29ya2lu ZyBncm91cCBtdWx0aXBsZSB0aW1lcyBhbmQgdGhlDQo+DQo+PiBpc3N1ZSB3YXMgZXhwbGljaXRs eSBjbG9zZWQgYnkgdGhlIGNoYWlycywgbGVhdmluZyB0aGUgc3RhdHVzIHF1byBpbg0KPg0KPj4g cGxhY2UgaW4gd2hpY2ggdGhlcmUgYXJlIHJlcXVpcmVkIGFsZ29yaXRobXMgZm9yIGludGVyb3Bl cmFiaWxpdHkgcmVhc29ucy4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4NCj4NCj4+IEknbSBnb2luZyB0 byBhZGQgb25lIG1vcmUgcXVlc3Rpb24gdG8gdGhlIHJldmlldyBhcyBJIGhhZCB0aGUgc2FtZQ0K Pg0KPj4gdGhvdWdodCBhcyBTY290dCAmIEJ1cnQgaW4gdGhlaXIgcmV2aWV3IG9mIEpXQSAoYW5k IGFsc28gaW4gSldTKS4gIA0KPj4gV2h5DQo+DQo+PiBhcmUgdGhlcmUgbm8gb3RoZXIgb3B0aW9u cyBpbiBhZGRpdGlvbiB0byBTSEExPyAgVGhlIHJlc3BvbnNlIHRvIA0KPj4gU2NvdHQNCj4NCj4+ IHBvaW50ZWQgYmFjayB0byBlYXJseSBXRyBkZWNpc2lvbnMsIGJ1dCBJIGhhdmUgaGVhcmQgdGhp cyBjb25jZXJuIA0KPj4gZnJvbQ0KPg0KPj4gb3RoZXJzIGFuZCBoYXZlIGl0IG15c2VsZiwgc28g SSBhbSBub3Qgc3VyZSB0aGlzIG9uZSBpcyByZXNvbHZlZC4gIA0KPj4gSSdkIGxpa2UgdG8gcmV2 aXNpdCBpdC4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4NCj4NCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwMjAuaHRtbA0KPg0KPj4NCj4NCj4+ DQo+DQo+Pg0KPg0KPj4gTWlrZT4gSWYgYWRkaW5nIGEgbmV3IOKAnFJTQS1PQUVQLTI1NuKAnSBh bGdvcml0aG0gaWRlbnRpZmllciBmb3Ig4oCcUlNBRVMNCj4NCj4+IE1pa2U+IHdpdGgNCj4NCj4+ IE9wdGltYWwgQXN5bW1ldHJpYyBFbmNyeXB0aW9uIFBhZGRpbmcgdXNpbmcgdGhlIE1HRjEgbWFz ayBnZW5lcmF0aW9uDQo+DQo+PiBmdW5jdGlvbiBhbmQgdGhlIFNIQS0yNTYgaGFzaCBmdW5jdGlv buKAnSB3b3VsZCBtYWtlIGEgbnVtYmVyIG9mIHBlb3BsZQ0KPg0KPj4gbW9yZSBjb21mb3J0YWJs ZSwgaW5jbHVkaW5nIHlvdSwgdGhlcmXigJlzIG5vdGhpbmcgd3Jvbmcgd2l0aCBkb2luZyBzby4N Cj4NCj4+IEhvd2V2ZXIsIGl04oCZcyBhbHNvIG5vdCBjbGVhciB0aGF0IGl0IHdvdWxkIGJlIG9m IG11Y2ggc2hvcnQtdGVybQ0KPg0KPj4gcHJhY3RpY2FsIGJlbmVmaXQgYmVjYXVzZSwgYXQgbGVh c3QgYXMgb2YgdGhlIGltcGxlbWVudGF0aW9uIHN1cnZleQ0KPg0KPj4gZG9uZSBpbiBKdWx5IDIw MTIsIG1hbnkgY3J5cHRvIGxpYnJhcmllcyBkb27igJl0IGV4cG9zZSBhIHdheSB0byBnZXQgYXQg DQo+PiB0aGlzIGFsZ29yaXRobSBjb21iaW5hdGlvbi4NCj4NCj4+IEhvd2V2ZXIsIHRoZSBzYW1l IGFyZ3VtZW50IGNvdWxkIGJlIG1hZGUgYWJvdXQgUlNBU1NBLVBTUywgd2hpY2ggd2UNCj4NCj4+ IGRpZCBhZGQgaWRlbnRpZmllcnMgZm9yIGluIHRoZSBlbmQuICBJbiBzaG9ydCwgSSBkb27igJl0 IHRoaW5rIGFueW9uZSANCj4+IGluDQo+DQo+PiB0aGUgd29ya2luZyBncm91cCB3b3VsZCBzdHJp ZGVudGx5IG9iamVjdCBpZiB5b3UgYXNrZWQgZm9yIHRoaXMNCj4NCj4+IGFkZGl0aW9uYWwgYWxn b3JpdGhtIGlkZW50aWZpZXIgdG8gYmUgYWRkZWQuICBZb3VyIGNhbGzigKYNCj4NCj4+DQo+DQo+ IEtNPiBJJ2Qgc2F5IHRvIGFkZCBpdC4gIEknbGwgaGF2ZSBhIHNpbWlsYXIgY29tbWVudCBmb3Ig dGhlIEpXUyBkcmFmdA0KPg0KPiBmb3IgU0hBMjU2IHN1cHBvcnQgb24gdGh1bWJwcmludHMuDQo+ DQo+DQo+DQo+IE1pa2U+IE9LIOKAkyBJ4oCZbGwgYWRkIGl0Lg0KPg0KDQpUaGFua3MsIGFuZCBJ IHNlZSBTY290dCdzIHJldmlldyBhbmQgb2theSBhcyB3ZWxsLCB3aGljaCBpcyBoZWxwZnVsLg0K Pg0KPg0KPiBNaWtlPiBQZXIgeW91ciBKV1MgY29tbWVudCwgU0hBLTEgdGh1bWJwcmludHMgYXJl IHdpZGVseSBkZXBsb3llZC4gIA0KPiBNaWtlPiBJ4oCZbQ0KPiBhd2FyZSBvZiBubyBTSEEtMjU2 IGNlcnRpZmljYXRlIHRodW1icHJpbnQgZGVwbG95bWVudHMuICBJ4oCZbGwgbm90ZSANCj4gdGhh dCBldmVuIGlmIFNIQS0xIHdlcmUgY29tcGxldGVseSBicm9rZW4sIHRoYXQgd291bGRu4oCZdCBi ZSBhIHNlY3VyaXR5IA0KPiBpc3N1ZSBiZWNhdXNlIGl04oCZcyBqdXN0IGJlaW5nIHVzZWQgdG8g Z2VuZXJhdGUgYSBkaWdlc3Qgb2YgcHVibGljbHkgDQo+IGF2YWlsYWJsZSBjZXJ0aWZpY2F0ZSBp bmZvcm1hdGlvbi4gIEl04oCZcyBub3QgYmVpbmcgdXNlZCB0byBjcnlwdG9ncmFwaGljYWxseSBv YnNjdXJlIGFueXRoaW5nLg0KPiAoQnV0IHRoYXTigJlzIGFjdHVhbGx5IGEgZGlzY3Vzc2lvbiBm b3IgYW5vdGhlciBkcmFmdC4gSikNCj4NCg0KVGhpcyBpcyBpbiBwbGFjZSBmb3IgdGhlIFhNTCBl cXVpdmFsZW50cyBhbmQgc2hvdWxkIGJlIHBvc3NpYmxlIGZvciBKU09OLiAgSSB1c2VkIHRoaXMg YXQgbGVhc3QgMiB5ZWFycyBhZ28gaW4gdGhlIFhNTCBPeHlnZW4gZWRpdG9yLiAgSSBiZWxpZXZl IHRoaXMgaGFzIGJlZW4gYnJvdWdodCB1cCBiZWZvcmUgaW4gdGVybXMgb2YgSlNPTiwgc28gSSBh bSBub3QgdGhlIGZpcnN0LiAgQnV0IGl0IGlzIGFub3RoZXIgZHJhZnQuLi4gSSdkIGxpa2UgdG8g Z2V0IHRocm91Z2ggdGhlc2UgYWxsIHNvb24gOi0pDQoNCj4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4g LS0NCj4NCj4+DQo+DQo+Pg0KPg0KPj4NCj4NCj4+IEJlc3QgcmVnYXJkcywNCj4NCj4+DQo+DQo+ PiBLYXRobGVlbg0KPg0KPj4NCj4NCj4+DQo+DQo+Pg0KPg0KPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzIGENCj4NCj4+ IGJ1bmNoLA0KPg0KPj4NCj4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4NCj4+DQo+DQo+Pg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPiAtLQ0KPg0KPg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+IEthdGhsZWVu DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+DQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+DQo+IGpvc2VAaWV0Zi5vcmcNCj4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQo+DQo+DQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUaGFua3MgDQo+IGFnYWluLA0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gDQo+IE1pa2UNCj4NCj4NCg0KVGhh bmtzIGZvciB5b3VyIGhlbHAhIQ0KDQotLSANCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg== From nobody Fri May 2 07:18:30 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756B31A6FBC for ; Fri, 2 May 2014 07:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq_rgGH3ikqX for ; Fri, 2 May 2014 07:18:26 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 317561A6FB4 for ; Fri, 2 May 2014 07:18:26 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rl12so5128402iec.0 for ; Fri, 02 May 2014 07:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DllfIoImtkfsVBT8ocghoNgp1vVr2OiRi1ZgzXK6c9E=; b=evL7gQ70/4RPjOlF216wamnuUzr3nKigX43iCFW2cEztPoFBMaVxWyfE5QBMYK4dJt MTDUXl2FlcCn2ygp6Thm0M9qGfdABs6fmTKNGQVgrotuJtOYdhXuDcdXtSHv2TKNRWuD m8ctcmPomt5InBVk1TSDlnFDxlZS1FhuJjG8Cux2cndEJ7zWOU6bRclZobJGXVhbG0nu VIQNvCYy6ImzjiRHBRRAyjrfYPS23eHo8i0R38oCxFsOWfhQXtqigEcnSRYtKUprxEOF dhejbQtZnk/IhDPdtcYvRlOB301pG/A+k/WcA7yExPV7ddJWdW0i5w1N/cS5EAvMLxq1 Z+Bg== X-Received: by 10.42.161.69 with SMTP id s5mr2377478icx.70.1399040303786; Fri, 02 May 2014 07:18:23 -0700 (PDT) Received: from [10.0.245.50] (mobile-166-147-100-113.mycingular.net. [166.147.100.113]) by mx.google.com with ESMTPSA id sc2sm6998627igb.5.2014.05.02.07.18.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 07:18:21 -0700 (PDT) X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (11D167) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A1A3C64@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Fri, 2 May 2014 09:18:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3C134FBC-EF0D-4B4E-AACD-1869EFAD34AA@gmail.com> References: <4E1F6AAD24975D4BA5B16804296739439A15D3B1@TK5EX14MBXC286.redmond.corp.microsoft.com> <00db01cf5a82$db1c7f80$91557e80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739439A1971D7@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A14A2@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A3C64@TK5EX14MBXC288.redmond.corp.microsoft.com> To: Mike Jones Archived-At: http://mailarchive.ietf.org/arch/msg/jose/IrMZlmOjD5RMAgaAOpNAfNqWrRc Cc: "jose@ietf.org" Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:18:29 -0000 Thanks for the detailed response and all of your efforts on this draft. =20 I need to backtrack on the statement I made about the WG decision on consens= us for alg none. They both have informed me that there was consensus, not j= ust agreement to keep it in for implementations. Could this be more explici= t in the issue tracker or on the list by the chairs so I have something to p= oint to if it comes up in last call? I am traveling today, so I don't have time to search for links on the equiva= lent for 'thumbprints' in XML. They refer to this as a fingerprint and it w= as implemented in the XML oxygen editor used for certificates. This may hel= p in case folks are interested and have some time to look into it. =20 Thank you, Kathleen=20 Sent from my iPhone > On May 1, 2014, at 1:10 PM, Mike Jones wrote= : >=20 > Yes, I realize that I haven't revised the security considerations yet. I s= tarted to do it and realized that it was a more intricate exercise than I'd o= riginally anticipated, so decided to get the -26 drafts out with the easy st= uff first, for working group review. These mostly address comments by you, S= cott, Hannes Tschofenig (which was actually a comment on JWT, but that appli= ed to JOSE as well), and Antonio Sanso. >=20 > WORKING GROUP: I would appreciate any specific suggestions on additions t= hat you'd like to have made to the security considerations section at http:/= /tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-8. >=20 > I also realize that I still need to write the note to David McGrew. >=20 > Kathleen, can you point us to the XML equivalents of certificate thumbprin= ts that you used? That could be interesting. FYI, I also submitted an indi= vidual -00 JSON thumbprint draft last month at http://tools.ietf.org/html/dr= aft-jones-jose-jwk-thumbprint-00 (because the need for a JSON-based thumbpri= nt came up in practice), but I'm not proposing that we try to jam it into JW= S at this point. It's fine for that to be work after a recharter, should th= e WG want to take it up. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > Sent: Thursday, May 01, 2014 10:47 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >=20 > Hi Mike, >=20 > Thanks for posting the updated draft. At a minimum, the security consider= ations update still needs to be updated. I'd like an okay from Jim, the doc= ument shepherd when he thinks this is all ready in case I am missing any oth= er open issues. The rest is in-line as this seems to summarize all of the i= ssues and there were discussions in other threads that I would prefer to not= see them get lost. >=20 >> On Thu, May 1, 2014 at 3:09 AM, Mike Jones w= rote: >> The algorithm name =E2=80=9CRSA-OAEP-256=E2=80=9D for RSAES OAEP using SH= A-256 and=20 >> MGF1 with >> SHA-256 has been added at >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#sect >> ion-4.3, >> per your request, Kathleen. >>=20 >>=20 >>=20 >>=20 >> -- Mike >>=20 >>=20 >>=20 >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones >> Sent: Friday, April 25, 2014 6:38 PM >>=20 >>=20 >> To: Kathleen Moriarty; Jim Schaad >> Cc: jose@ietf.org; draft-ietf-jose-json-web-algorithms@tools.ietf.org >>=20 >> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>=20 >>=20 >>=20 >> Thanks, Kathleen. Comments are inline, marked =E2=80=9CMike>=E2=80=9D=E2= =80=A6 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Kathleen=20 >> Moriarty >> Sent: Friday, April 25, 2014 2:07 PM >> To: Jim Schaad >> Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org; >> jose@ietf.org >> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>=20 >>=20 >>=20 >> Sorry for the delay in my response. I'll answer in-line below. >>=20 >>=20 >>=20 >> Thanks! >>=20 >>=20 >>=20 >>> On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad wro= te: >>>=20 >>=20 >>=20 >>=20 >>=20 >>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones >>=20 >>> Sent: Thursday, April 17, 2014 10:46 AM >>=20 >>> To: Kathleen Moriarty; jose@ietf.org >>=20 >>> Cc: draft-ietf-jose-json-web-algorithms@tools.ietf.org >>=20 >>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>=20 >>=20 >>=20 >>=20 >>> Thanks for taking the time to do the review, Kathleen. Responses are >>=20 >>> inline, flagged by =E2=80=9CMike>=E2=80=9D. I also pasted your follow-o= n note in and >>=20 >>> responded to it as well. >>=20 >>=20 >>=20 >>=20 >>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>=20 >>> Sent: Thursday, April 17, 2014 7:51 AM >>=20 >>> To: jose@ietf.org >>=20 >>> Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org >>=20 >>> Subject: AD review of draft-ietf-jose-json-web-algorithms >>=20 >>=20 >>=20 >>=20 >>> Hello Mike & JOSE members, >>=20 >>=20 >>=20 >>=20 >>> I am working my way through the requested reviews to progress the=20 >>> JOSE >>=20 >>> drafts and can see a lot of work has been done, thank you. As I read >>=20 >>> through the Algorithms (JWA) draft there are some changes that will >>=20 >>> need to be made to avoid problems during the IESG review. This is a >>=20 >>> pretty big change for the draft, but will help make the review and=20 >>> approval faster. >>=20 >>> Typically, the lists of algorithms are handled through a draft update >>=20 >>> as opposed to creating an IANA registry. A good example is a recent >>=20 >>> update of a draft in the IPSECME working group so you can see the >>=20 >>> structure and the precedence for this model. >>=20 >>=20 >>=20 >>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts >>=20 >>=20 >>=20 >>=20 >>> Mike> So you=E2=80=99re suggesting that future JWA drafts might obsolete= the >>=20 >>> Mike> current >>=20 >>> one, much like draft-ietf-ipsecme-esp-ah-reqts will obsolete RFC=20 >>> 4835, >>=20 >>> which obsoleted RFC 4305, etc.? If so, could work on revising the=20 >>> JWA >>=20 >>> draft accordingly and send proposed changes to the working group. >>=20 >>=20 >>=20 >> KM> I am not sure where Jim's response is, but I have been looking >>=20 >> into this. My initial message came after some conversations with=20 >> Sean. In response to your posts, I reached out to a couple of other=20 >> ADs who may have had concerns and *think* we are okay as long as the=20 >> registries will be used with a designated expert review to add to the=20 >> registry. If a draft is required for an update, that would cause=20 >> problems as opposed to a draft with no registries. Sorry for the confusi= on here. >>=20 >>=20 >>=20 >> Mike> Jim=E2=80=99s response is at >> http://www.ietf.org/mail-archive/web/jose/current/msg04071.html,=20 >> starting with =E2=80=9C[JLS] Kathleen, I don=E2=80=99t know that I agree w= ith this=20 >> statement. There are a number of different places where IANA=20 >> registries are used for the purpose of having lists of algorithms.=E2=80=9D= =20 >> All the registries established already require expert review, as=20 >> described at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorith= ms-25#section-7. >> So it sounds like we should be OK. That=E2=80=99s good. Thanks for work= ing=20 >> the issue. >>=20 >>=20 >>=20 >>=20 >>> Now for other edits and questions: >>=20 >>=20 >>=20 >>=20 >>> Section 3.6 - Can you explain why would this be included? If you are >>=20 >>> not going to sign, I am not sure why one would use JOSE at all. >>=20 >>=20 >>=20 >>=20 >>> Mike> This is included to enable representing content that is >>=20 >>> Mike> optionally >>=20 >>> signed in protocols using JWS. Having this means that whether or not >>=20 >>> the content is signed, it can use a uniform representation, which is >>=20 >>> easy to parse. This is in production use, for instance, to enable >>=20 >>> OAuth authorization request messages that are optionally signed. >>=20 >>> Sometimes content need not be signed at the JWS level because it=E2=80=99= s >>=20 >>> integrity protected by other protocol layers =E2=80=93 in particular, of= ten=20 >>> by >>=20 >>> the use of TLS. Another use case is where signing adds additional >>=20 >>> optional value, but where there=E2=80=99s no harm in using unsigned cont= ent =E2=80=93 >>=20 >>> for instance, while normal OAuth requests are inline and unsigned, a >>=20 >>> registered extension enables request parameters to be passed by >>=20 >>> reference, rather than by value; the object referenced containing the >>=20 >>> parameters is a JWS; the JWS can optionally be signed. The current, >>=20 >>> carefully refined treatment of =E2=80=9Cnone=E2=80=9D is the result of s= ubstantial=20 >>> mailing list discussions and discussions on working group calls. >>=20 >>> While a less parallel treatment of unsigned JWSs was proposed in >>=20 >>> http://trac.tools.ietf.org/wg/jose/trac/ticket/36, this alternative >>=20 >>> syntax was rejected by the working group in favor of the current approac= h. >>=20 >>=20 >>=20 >> KM> I responded to Vladamir on this one and would just like to know if >>=20 >> there is WG consensus behind the decision. Can you point me to=20 >> discussions on this? >>=20 >>=20 >>=20 >> Mike> Brian Campbell did a good job summarizing the consensus in his=20 >> Mike> note >> http://www.ietf.org/mail-archive/web/jose/current/msg04082.html. Jim=20 >> Schaad documented the consensus in his note closing issue #36 at the=20 >> end of http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >>=20 >>=20 >>=20 >> Mike> This was extensively discussed on a thread titled =E2=80=9C[jose] #= 36: >> Algorithm "none" should be removed=E2=80=9D between 7/31/13 and 8/22/13 a= nd=20 >> then also on a follow-up thread named =E2=80=9C[jose] Text about applicat= ions=20 >> and "alg":"none"=E2=80=9D between 9/3/13 and 9/9/13. The latter thread=20= >> resulted from an action items from the preceding interim working group=20= >> call (the agenda for which was published at=20 >> http://www.ietf.org/proceedings/interim/2013/08/19/jose/agenda/agenda-int= erim-2013-jose-5). >>=20 >>=20 >>=20 >> Mike> The text agreed to by the working group that Brian referred to=20 >> Mike> was >> added in draft-ietf-jose-json-web-algorithms-16, published on 9/15/13. =20= >> Jim closed the issue on 10/28/13. >=20 > My read of the threads and issue tracker was that implementations won out t= o close this discussion, but that there was no consensus. There were many i= nvolved in the discussion that provided arguments and support for not includ= ing alg none. I'll support this as a WG decision based on implementations, a= s that's how I read it. I appreciate all of the feedback on actual use of t= his as it will be helpful in case this comes up during last call. >=20 >>=20 >>=20 >>=20 >>> Section 5.2 - The write up of this section seems a bit more >>=20 >>> complicated than necessary. It seems it would have just been simpler >>=20 >>> to state that the sizes vary as required by the algorithms and key >>=20 >>> lengths used rather than providing the differences from one to the next.= >>> Can you simplify this? >>=20 >>=20 >>> After looking through some of the mailing list discussions, it seems >>=20 >>> there was already agreement to slim this and other sections down by >>=20 >>> pointing to the draft-mcgrew-aead-aes-cbc-hmac-sha2 >>=20 >>=20 >>=20 >>=20 >>> http://www.ietf.org/mail-archive/web/jose/current/msg02276.html >>=20 >>=20 >>> Can I get an update as to where that stands, referencing what you can >>=20 >>> from that draft as opposed to duplicating text? Thanks! >>=20 >>=20 >>> Mike> Sure. The key part of the message you cited is =E2=80=9COnce the=20= >>> Mike> McGrew >>=20 >>> Mike> draft >>=20 >>> has been refactored to separate the description of the calculation >>=20 >>> steps (which JOSE is using) from the AEAD representation steps (which >>=20 >>> JOSE is not using), and to include test vector values that show >>=20 >>> results without performing the AEAD representation concatenations, I >>=20 >>> agree that we'll be able to just reference it, rather than=20 >>> duplicating >>=20 >>> it.=E2=80=9D The problem is that the refactoring was never done. The >>=20 >>> algorithm description in >>=20 >>> draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the >>=20 >>> ciphertext C, as described, also includes the IV value as a prefix=20 >>> and >>=20 >>> the authentication tag T as a suffix, rather than treating each of >>=20 >>> those as separate values. The test vectors do the same. Yes, David >>=20 >>> added appendix B saying that the values could be treated as separate, >>=20 >>> but the write-up does no favors to implementers, as both the core >>=20 >>> algorithm description and the test vectors assume they are combined. >>=20 >>> (I personally know that working out how to treat them as separate=20 >>> from >>=20 >>> David=E2=80=99s current draft is a tedious and error-prone exercise, hav= ing >>=20 >>> had to do so to tease them apart for the current JWA write-up.) =20 >>> David >>=20 >>> has been asked about doing the refactoring several times by multiple >>=20 >>> parties, but he=E2=80=99s a busy guy, and I don=E2=80=99t think it=E2=80= =99s ever reached the >>=20 >>> top of his queue. As it is, the JWA description is clear and >>=20 >>> semantically equivalent and implementers have shown that they can >>=20 >>> successfully build it. Finally, we wouldn=E2=80=99t want to take a norm= ative >>=20 >>> dependency upon a draft that appears to have been largely abandoned >>=20 >>> (or at least neglected), as doing so could indefinitely stall=20 >>> publication of RFC versions of the JOSE specs. >>=20 >>=20 >>=20 >>=20 >>> [JLS] I always considered this to be a sufficient refactoring to use >>=20 >>> the mcgrew draft as a basis. I did not have the same type of=20 >>> problems >>=20 >>> with breaking the test vectors apart that you seem to have had. >>=20 >>=20 >>=20 >>=20 >> KM> OK, has anyone reached out to Dave McGrew to discuss? How can we >>=20 >> clear this up? >>=20 >>=20 >>=20 >> Mike> I=E2=80=99d had in-person and phone conversations with him about it= last=20 >> Mike> year, >> but not much happened as a result. >>=20 >>=20 >>=20 >> Mike> I wrote more about your question at >> http://www.ietf.org/mail-archive/web/jose/current/msg04074.html in=20 >> which I pointed out errors and sources of confusion in David=E2=80=99s dr= aft=20 >> that would complicate life for developers and possibly result in=20 >> incorrect implementations; Jim responded at=20 >> http://www.ietf.org/mail-archive/web/jose/current/msg04075.html. I=E2=80= =99ll=20 >> send a note to David pointing these out and offering to produce=20 >> proposed changes for him to incorporate, but unless he either decides=20 >> to devote bandwidth to advancing the draft (it=E2=80=99s already expired o= nce)=20 >> or is willing to delegate it to us to do so, I think we don=E2=80=99t hav= e=20 >> much choice but to continue to have a complete and accurate=20 >> description of the algorithms in the JWA doc, and let his draft=20 >> advance at its own pace. I=E2=80=99ll note that we also don=E2=80=99t ha= ve a=20 >> publication vehicle for the draft to become an RFC, because it=E2=80=99s n= ot in any working group, nor does it have AD sponsorship that I=E2=80=99m aw= are of. >=20 > Thank you, please keep us posted on the status/progress so we know how to m= ove forward. >=20 >>=20 >>=20 >>=20 >>> Security Considerations: While it is true the content is covered in >>=20 >>> other places, this section could benefit from improvement before it >>=20 >>> goes to the SecDir review. The second sentence in the first=20 >>> paragraph >>=20 >>> says the >>=20 >>> following: >>=20 >>=20 >>> Among these issues are >>=20 >>=20 >>> protecting the user's private and symmetric keys, preventing >>=20 >>> various >>=20 >>=20 >>> attacks, and helping the user avoid mistakes such as inadvertently >>=20 >>=20 >>> encrypting a message for the wrong recipient. >>=20 >>=20 >>> It would be helpful if you could expand the text and make it more >>=20 >>> descriptive and applicable to this document. For example, shouldn=E2=80= =99t >>=20 >>> the first section say user=E2=80=99s private asymmetric and symmetric ke= ys? =20 >>> I >>=20 >>> assume that is what was intended with private, but it reads funny to >>=20 >>> me without that. The only =E2=80=98attack=E2=80=99 or caution mentioned= in the >>=20 >>> document is for the application to prevent a user from selecting the >>=20 >>> wrong key. Please include some attacks that developers and >>=20 >>> implementers should be aware and cautioned on, or state that specific >>=20 >>> attacks and considers are detailed in the subsections to follow. >>=20 >>=20 >>=20 >>=20 >>> Mike> OK, I can work on expanding that. There are some other attacks >>=20 >>> mentioned in the other drafts, such as timing attacks, which can >>=20 >>> probably at least be mentioned here. I=E2=80=99ll send draft text to th= e=20 >>> list >>=20 >>> and consult with you before doing anything to the actual drafts. >>=20 >>> Specific suggestions from working group participants would also be=20 >>> highly appreciated. >>=20 >=20 > The Security Considerations section requires updating, let me know when th= is has been done. Thanks! >>=20 >> KM> Great, thank you! >>=20 >>=20 >>> I think that's it for now. Although I do need to look through some >>=20 >>> more of the previous conversations on the mailing list and in the=20 >>> issue tracker. >>=20 >>=20 >>=20 >>=20 >>> I see there are some open discussions, like the one Richard raised >>=20 >>> yesterday that need to be resolved in the document as well before we >>=20 >>> move forward with this one. Thanks for all of your effort on this draft= !! >>=20 >>=20 >>=20 >>=20 >>> Mike> Per my note >>=20 >>> http://www.ietf.org/mail-archive/web/jose/current/msg04061.html, I >>=20 >>> don=E2=80=99t believe that that particular issue is open. It had been >>=20 >>> extensively discussed within the working group multiple times and the >>=20 >>> issue was explicitly closed by the chairs, leaving the status quo in >>=20 >>> place in which there are required algorithms for interoperability reason= s. >>=20 >>=20 >>=20 >>=20 >>> I'm going to add one more question to the review as I had the same >>=20 >>> thought as Scott & Burt in their review of JWA (and also in JWS). =20 >>> Why >>=20 >>> are there no other options in addition to SHA1? The response to=20 >>> Scott >>=20 >>> pointed back to early WG decisions, but I have heard this concern=20 >>> from >>=20 >>> others and have it myself, so I am not sure this one is resolved. =20 >>> I'd like to revisit it. >>=20 >>=20 >>=20 >>=20 >>> http://www.ietf.org/mail-archive/web/jose/current/msg04020.html >>=20 >>=20 >>=20 >>=20 >>> Mike> If adding a new =E2=80=9CRSA-OAEP-256=E2=80=9D algorithm identifie= r for =E2=80=9CRSAES >>=20 >>> Mike> with >>=20 >>> Optimal Asymmetric Encryption Padding using the MGF1 mask generation >>=20 >>> function and the SHA-256 hash function=E2=80=9D would make a number of p= eople >>=20 >>> more comfortable, including you, there=E2=80=99s nothing wrong with doin= g so. >>=20 >>> However, it=E2=80=99s also not clear that it would be of much short-term= >>=20 >>> practical benefit because, at least as of the implementation survey >>=20 >>> done in July 2012, many crypto libraries don=E2=80=99t expose a way to g= et at=20 >>> this algorithm combination. >>=20 >>> However, the same argument could be made about RSASSA-PSS, which we >>=20 >>> did add identifiers for in the end. In short, I don=E2=80=99t think any= one=20 >>> in >>=20 >>> the working group would stridently object if you asked for this >>=20 >>> additional algorithm identifier to be added. Your call=E2=80=A6 >>=20 >>=20 >> KM> I'd say to add it. I'll have a similar comment for the JWS draft >>=20 >> for SHA256 support on thumbprints. >>=20 >>=20 >>=20 >> Mike> OK =E2=80=93 I=E2=80=99ll add it. >=20 > Thanks, and I see Scott's review and okay as well, which is helpful. >>=20 >>=20 >> Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed. =20 >> Mike> I=E2=80=99m >> aware of no SHA-256 certificate thumbprint deployments. I=E2=80=99ll not= e=20 >> that even if SHA-1 were completely broken, that wouldn=E2=80=99t be a sec= urity=20 >> issue because it=E2=80=99s just being used to generate a digest of public= ly=20 >> available certificate information. It=E2=80=99s not being used to crypto= graphically obscure anything. >> (But that=E2=80=99s actually a discussion for another draft. J) >=20 > This is in place for the XML equivalents and should be possible for JSON. = I used this at least 2 years ago in the XML Oxygen editor. I believe this h= as been brought up before in terms of JSON, so I am not the first. But it i= s another draft... I'd like to get through these all soon :-) >=20 >>=20 >>=20 >>=20 >>=20 >>> -- >>=20 >>=20 >>=20 >>=20 >>> Best regards, >>=20 >>=20 >>> Kathleen >>=20 >>=20 >>=20 >>=20 >>> Thanks a >>=20 >>> bunch, >>=20 >>=20 >>> -- Mike >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Kathleen >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> jose mailing list >>=20 >> jose@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >> Thanks=20 >> again, >>=20 >> --=20 >> Mike >=20 > Thanks for your help!! >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Fri May 2 07:54:45 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F401A7011 for ; Fri, 2 May 2014 07:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K10gKNAXkAU6 for ; Fri, 2 May 2014 07:54:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7B54A1A6FF4 for ; Fri, 2 May 2014 07:54:37 -0700 (PDT) Received: from ISOC-REM-MBA2187.local (74.214.48.55) by BY2PR06MB583.namprd06.prod.outlook.com (10.141.221.149) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 2 May 2014 14:54:32 +0000 Message-ID: <5363B1A7.2080404@isoc.org> Date: Fri, 2 May 2014 10:54:31 -0400 From: Karen ODonoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <4E1F6AAD24975D4BA5B16804296739439A15D3B1@TK5EX14MBXC286.redmond.corp.microsoft.com> <00db01cf5a82$db1c7f80$91557e80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739439A1971D7@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A14A2@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A3C64@TK5EX14MBXC288.redmond.corp.microsoft.com> <3C134FBC-EF0D-4B4E-AACD-1869EFAD34AA@gmail.com> In-Reply-To: <3C134FBC-EF0D-4B4E-AACD-1869EFAD34AA@gmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [74.214.48.55] X-ClientProxiedBy: BLUPR08CA016.namprd08.prod.outlook.com (10.141.30.36) To BY2PR06MB583.namprd06.prod.outlook.com (10.141.221.149) X-Forefront-PRVS: 019919A9E4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019001)(979002)(6009001)(428001)(479174003)(377454003)(51444003)(69234005)(52604005)(51704005)(69224002)(164054003)(52084003)(189002)(199002)(51914003)(40764003)(24454002)(41574002)(13464003)(87976001)(4396001)(77982001)(65816999)(42186004)(76482001)(33656001)(46102001)(36756003)(59896001)(20776003)(80022001)(65806001)(65956001)(99396002)(66066001)(54356999)(80976001)(76176999)(19580395003)(19580405001)(83322001)(79102001)(50986999)(80316001)(47776003)(87266999)(74662001)(15975445006)(74502001)(83506001)(15202345003)(31966008)(50466002)(86362001)(85852003)(23676002)(83072002)(81542001)(64126003)(92726001)(81342001)(92566001)(101416001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR06MB583; H:ISOC-REM-MBA2187.local; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: isoc.org does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/jose/OWoiJope54k-Yxszqmf0VL5aE1s Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:54:42 -0000 Kathleen, I will add some text to the tracker to make this clearer. My apologies for the confusion. Thanks for your efforts. I know there is a pile of stuff to plow through... Regards, Karen On 5/2/14 10:18 AM, Kathleen Moriarty wrote: > Thanks for the detailed response and all of your efforts on this draft. > > I need to backtrack on the statement I made about the WG decision on consensus for alg none. They both have informed me that there was consensus, not just agreement to keep it in for implementations. Could this be more explicit in the issue tracker or on the list by the chairs so I have something to point to if it comes up in last call? > > I am traveling today, so I don't have time to search for links on the equivalent for 'thumbprints' in XML. They refer to this as a fingerprint and it was implemented in the XML oxygen editor used for certificates. This may help in case folks are interested and have some time to look into it. > > Thank you, > Kathleen > > Sent from my iPhone > >> On May 1, 2014, at 1:10 PM, Mike Jones wrote: >> >> Yes, I realize that I haven't revised the security considerations yet. I started to do it and realized that it was a more intricate exercise than I'd originally anticipated, so decided to get the -26 drafts out with the easy stuff first, for working group review. These mostly address comments by you, Scott, Hannes Tschofenig (which was actually a comment on JWT, but that applied to JOSE as well), and Antonio Sanso. >> >> WORKING GROUP: I would appreciate any specific suggestions on additions that you'd like to have made to the security considerations section at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-8. >> >> I also realize that I still need to write the note to David McGrew. >> >> Kathleen, can you point us to the XML equivalents of certificate thumbprints that you used? That could be interesting. FYI, I also submitted an individual -00 JSON thumbprint draft last month at http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00 (because the need for a JSON-based thumbprint came up in practice), but I'm not proposing that we try to jam it into JWS at this point. It's fine for that to be work after a recharter, should the WG want to take it up. >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Thursday, May 01, 2014 10:47 AM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >> >> Hi Mike, >> >> Thanks for posting the updated draft. At a minimum, the security considerations update still needs to be updated. I'd like an okay from Jim, the document shepherd when he thinks this is all ready in case I am missing any other open issues. The rest is in-line as this seems to summarize all of the issues and there were discussions in other threads that I would prefer to not see them get lost. >> >>> On Thu, May 1, 2014 at 3:09 AM, Mike Jones wrote: >>> The algorithm name “RSA-OAEP-256” for RSAES OAEP using SHA-256 and >>> MGF1 with >>> SHA-256 has been added at >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#sect >>> ion-4.3, >>> per your request, Kathleen. >>> >>> >>> >>> >>> -- Mike >>> >>> >>> >>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones >>> Sent: Friday, April 25, 2014 6:38 PM >>> >>> >>> To: Kathleen Moriarty; Jim Schaad >>> Cc: jose@ietf.org; draft-ietf-jose-json-web-algorithms@tools.ietf.org >>> >>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>> >>> >>> >>> Thanks, Kathleen. Comments are inline, marked “Mike>”… >>> >>> >>> >>> -----Original Message----- >>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Kathleen >>> Moriarty >>> Sent: Friday, April 25, 2014 2:07 PM >>> To: Jim Schaad >>> Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org; >>> jose@ietf.org >>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>> >>> >>> >>> Sorry for the delay in my response. I'll answer in-line below. >>> >>> >>> >>> Thanks! >>> >>> >>> >>>> On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad wrote: >>>> >>> >>> >>> >>>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones >>>> Sent: Thursday, April 17, 2014 10:46 AM >>>> To: Kathleen Moriarty; jose@ietf.org >>>> Cc: draft-ietf-jose-json-web-algorithms@tools.ietf.org >>>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>> >>> >>> >>>> Thanks for taking the time to do the review, Kathleen. Responses are >>>> inline, flagged by “Mike>”. I also pasted your follow-on note in and >>>> responded to it as well. >>> >>> >>> >>>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>>> Sent: Thursday, April 17, 2014 7:51 AM >>>> To: jose@ietf.org >>>> Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org >>>> Subject: AD review of draft-ietf-jose-json-web-algorithms >>> >>> >>> >>>> Hello Mike & JOSE members, >>> >>> >>> >>>> I am working my way through the requested reviews to progress the >>>> JOSE >>>> drafts and can see a lot of work has been done, thank you. As I read >>>> through the Algorithms (JWA) draft there are some changes that will >>>> need to be made to avoid problems during the IESG review. This is a >>>> pretty big change for the draft, but will help make the review and >>>> approval faster. >>>> Typically, the lists of algorithms are handled through a draft update >>>> as opposed to creating an IANA registry. A good example is a recent >>>> update of a draft in the IPSECME working group so you can see the >>>> structure and the precedence for this model. >>> >>> >>> >>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts >>> >>> >>> >>>> Mike> So you’re suggesting that future JWA drafts might obsolete the >>>> Mike> current >>>> one, much like draft-ietf-ipsecme-esp-ah-reqts will obsolete RFC >>>> 4835, >>>> which obsoleted RFC 4305, etc.? If so, could work on revising the >>>> JWA >>>> draft accordingly and send proposed changes to the working group. >>> >>> >>> KM> I am not sure where Jim's response is, but I have been looking >>> >>> into this. My initial message came after some conversations with >>> Sean. In response to your posts, I reached out to a couple of other >>> ADs who may have had concerns and *think* we are okay as long as the >>> registries will be used with a designated expert review to add to the >>> registry. If a draft is required for an update, that would cause >>> problems as opposed to a draft with no registries. Sorry for the confusion here. >>> >>> >>> >>> Mike> Jim’s response is at >>> http://www.ietf.org/mail-archive/web/jose/current/msg04071.html, >>> starting with “[JLS] Kathleen, I don’t know that I agree with this >>> statement. There are a number of different places where IANA >>> registries are used for the purpose of having lists of algorithms.” >>> All the registries established already require expert review, as >>> described at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-7. >>> So it sounds like we should be OK. That’s good. Thanks for working >>> the issue. >>> >>> >>> >>> >>>> Now for other edits and questions: >>> >>> >>> >>>> Section 3.6 - Can you explain why would this be included? If you are >>>> not going to sign, I am not sure why one would use JOSE at all. >>> >>> >>> >>>> Mike> This is included to enable representing content that is >>>> Mike> optionally >>>> signed in protocols using JWS. Having this means that whether or not >>>> the content is signed, it can use a uniform representation, which is >>>> easy to parse. This is in production use, for instance, to enable >>>> OAuth authorization request messages that are optionally signed. >>>> Sometimes content need not be signed at the JWS level because it’s >>>> integrity protected by other protocol layers – in particular, often >>>> by >>>> the use of TLS. Another use case is where signing adds additional >>>> optional value, but where there’s no harm in using unsigned content – >>>> for instance, while normal OAuth requests are inline and unsigned, a >>>> registered extension enables request parameters to be passed by >>>> reference, rather than by value; the object referenced containing the >>>> parameters is a JWS; the JWS can optionally be signed. The current, >>>> carefully refined treatment of “none” is the result of substantial >>>> mailing list discussions and discussions on working group calls. >>>> While a less parallel treatment of unsigned JWSs was proposed in >>>> http://trac.tools.ietf.org/wg/jose/trac/ticket/36, this alternative >>>> syntax was rejected by the working group in favor of the current approach. >>> >>> >>> KM> I responded to Vladamir on this one and would just like to know if >>> >>> there is WG consensus behind the decision. Can you point me to >>> discussions on this? >>> >>> >>> >>> Mike> Brian Campbell did a good job summarizing the consensus in his >>> Mike> note >>> http://www.ietf.org/mail-archive/web/jose/current/msg04082.html. Jim >>> Schaad documented the consensus in his note closing issue #36 at the >>> end of http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >>> >>> >>> >>> Mike> This was extensively discussed on a thread titled “[jose] #36: >>> Algorithm "none" should be removed” between 7/31/13 and 8/22/13 and >>> then also on a follow-up thread named “[jose] Text about applications >>> and "alg":"none"” between 9/3/13 and 9/9/13. The latter thread >>> resulted from an action items from the preceding interim working group >>> call (the agenda for which was published at >>> http://www.ietf.org/proceedings/interim/2013/08/19/jose/agenda/agenda-interim-2013-jose-5). >>> >>> >>> >>> Mike> The text agreed to by the working group that Brian referred to >>> Mike> was >>> added in draft-ietf-jose-json-web-algorithms-16, published on 9/15/13. >>> Jim closed the issue on 10/28/13. >> My read of the threads and issue tracker was that implementations won out to close this discussion, but that there was no consensus. There were many involved in the discussion that provided arguments and support for not including alg none. I'll support this as a WG decision based on implementations, as that's how I read it. I appreciate all of the feedback on actual use of this as it will be helpful in case this comes up during last call. >> >>> >>> >>>> Section 5.2 - The write up of this section seems a bit more >>>> complicated than necessary. It seems it would have just been simpler >>>> to state that the sizes vary as required by the algorithms and key >>>> lengths used rather than providing the differences from one to the next. >>>> Can you simplify this? >>> >>>> After looking through some of the mailing list discussions, it seems >>>> there was already agreement to slim this and other sections down by >>>> pointing to the draft-mcgrew-aead-aes-cbc-hmac-sha2 >>> >>> >>> >>>> http://www.ietf.org/mail-archive/web/jose/current/msg02276.html >>> >>>> Can I get an update as to where that stands, referencing what you can >>>> from that draft as opposed to duplicating text? Thanks! >>> >>>> Mike> Sure. The key part of the message you cited is “Once the >>>> Mike> McGrew >>>> Mike> draft >>>> has been refactored to separate the description of the calculation >>>> steps (which JOSE is using) from the AEAD representation steps (which >>>> JOSE is not using), and to include test vector values that show >>>> results without performing the AEAD representation concatenations, I >>>> agree that we'll be able to just reference it, rather than >>>> duplicating >>>> it.” The problem is that the refactoring was never done. The >>>> algorithm description in >>>> draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the >>>> ciphertext C, as described, also includes the IV value as a prefix >>>> and >>>> the authentication tag T as a suffix, rather than treating each of >>>> those as separate values. The test vectors do the same. Yes, David >>>> added appendix B saying that the values could be treated as separate, >>>> but the write-up does no favors to implementers, as both the core >>>> algorithm description and the test vectors assume they are combined. >>>> (I personally know that working out how to treat them as separate >>>> from >>>> David’s current draft is a tedious and error-prone exercise, having >>>> had to do so to tease them apart for the current JWA write-up.) >>>> David >>>> has been asked about doing the refactoring several times by multiple >>>> parties, but he’s a busy guy, and I don’t think it’s ever reached the >>>> top of his queue. As it is, the JWA description is clear and >>>> semantically equivalent and implementers have shown that they can >>>> successfully build it. Finally, we wouldn’t want to take a normative >>>> dependency upon a draft that appears to have been largely abandoned >>>> (or at least neglected), as doing so could indefinitely stall >>>> publication of RFC versions of the JOSE specs. >>> >>> >>> >>>> [JLS] I always considered this to be a sufficient refactoring to use >>>> the mcgrew draft as a basis. I did not have the same type of >>>> problems >>>> with breaking the test vectors apart that you seem to have had. >>> >>> >>> >>> KM> OK, has anyone reached out to Dave McGrew to discuss? How can we >>> >>> clear this up? >>> >>> >>> >>> Mike> I’d had in-person and phone conversations with him about it last >>> Mike> year, >>> but not much happened as a result. >>> >>> >>> >>> Mike> I wrote more about your question at >>> http://www.ietf.org/mail-archive/web/jose/current/msg04074.html in >>> which I pointed out errors and sources of confusion in David’s draft >>> that would complicate life for developers and possibly result in >>> incorrect implementations; Jim responded at >>> http://www.ietf.org/mail-archive/web/jose/current/msg04075.html. I’ll >>> send a note to David pointing these out and offering to produce >>> proposed changes for him to incorporate, but unless he either decides >>> to devote bandwidth to advancing the draft (it’s already expired once) >>> or is willing to delegate it to us to do so, I think we don’t have >>> much choice but to continue to have a complete and accurate >>> description of the algorithms in the JWA doc, and let his draft >>> advance at its own pace. I’ll note that we also don’t have a >>> publication vehicle for the draft to become an RFC, because it’s not in any working group, nor does it have AD sponsorship that I’m aware of. >> Thank you, please keep us posted on the status/progress so we know how to move forward. >> >>> >>> >>>> Security Considerations: While it is true the content is covered in >>>> other places, this section could benefit from improvement before it >>>> goes to the SecDir review. The second sentence in the first >>>> paragraph >>>> says the >>>> following: >>> >>>> Among these issues are >>> >>>> protecting the user's private and symmetric keys, preventing >>>> various >>> >>>> attacks, and helping the user avoid mistakes such as inadvertently >>> >>>> encrypting a message for the wrong recipient. >>> >>>> It would be helpful if you could expand the text and make it more >>>> descriptive and applicable to this document. For example, shouldn’t >>>> the first section say user’s private asymmetric and symmetric keys? >>>> I >>>> assume that is what was intended with private, but it reads funny to >>>> me without that. The only ‘attack’ or caution mentioned in the >>>> document is for the application to prevent a user from selecting the >>>> wrong key. Please include some attacks that developers and >>>> implementers should be aware and cautioned on, or state that specific >>>> attacks and considers are detailed in the subsections to follow. >>> >>> >>> >>>> Mike> OK, I can work on expanding that. There are some other attacks >>>> mentioned in the other drafts, such as timing attacks, which can >>>> probably at least be mentioned here. I’ll send draft text to the >>>> list >>>> and consult with you before doing anything to the actual drafts. >>>> Specific suggestions from working group participants would also be >>>> highly appreciated. >> The Security Considerations section requires updating, let me know when this has been done. Thanks! >>> KM> Great, thank you! >>> >>> >>>> I think that's it for now. Although I do need to look through some >>>> more of the previous conversations on the mailing list and in the >>>> issue tracker. >>> >>> >>> >>>> I see there are some open discussions, like the one Richard raised >>>> yesterday that need to be resolved in the document as well before we >>>> move forward with this one. Thanks for all of your effort on this draft!! >>> >>> >>> >>>> Mike> Per my note >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04061.html, I >>>> don’t believe that that particular issue is open. It had been >>>> extensively discussed within the working group multiple times and the >>>> issue was explicitly closed by the chairs, leaving the status quo in >>>> place in which there are required algorithms for interoperability reasons. >>> >>> >>> >>>> I'm going to add one more question to the review as I had the same >>>> thought as Scott & Burt in their review of JWA (and also in JWS). >>>> Why >>>> are there no other options in addition to SHA1? The response to >>>> Scott >>>> pointed back to early WG decisions, but I have heard this concern >>>> from >>>> others and have it myself, so I am not sure this one is resolved. >>>> I'd like to revisit it. >>> >>> >>> >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04020.html >>> >>> >>> >>>> Mike> If adding a new “RSA-OAEP-256” algorithm identifier for “RSAES >>>> Mike> with >>>> Optimal Asymmetric Encryption Padding using the MGF1 mask generation >>>> function and the SHA-256 hash function” would make a number of people >>>> more comfortable, including you, there’s nothing wrong with doing so. >>>> However, it’s also not clear that it would be of much short-term >>>> practical benefit because, at least as of the implementation survey >>>> done in July 2012, many crypto libraries don’t expose a way to get at >>>> this algorithm combination. >>>> However, the same argument could be made about RSASSA-PSS, which we >>>> did add identifiers for in the end. In short, I don’t think anyone >>>> in >>>> the working group would stridently object if you asked for this >>>> additional algorithm identifier to be added. Your call… >>> >>> KM> I'd say to add it. I'll have a similar comment for the JWS draft >>> >>> for SHA256 support on thumbprints. >>> >>> >>> >>> Mike> OK – I’ll add it. >> Thanks, and I see Scott's review and okay as well, which is helpful. >>> >>> Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed. >>> Mike> I’m >>> aware of no SHA-256 certificate thumbprint deployments. I’ll note >>> that even if SHA-1 were completely broken, that wouldn’t be a security >>> issue because it’s just being used to generate a digest of publicly >>> available certificate information. It’s not being used to cryptographically obscure anything. >>> (But that’s actually a discussion for another draft. J) >> This is in place for the XML equivalents and should be possible for JSON. I used this at least 2 years ago in the XML Oxygen editor. I believe this has been brought up before in terms of JSON, so I am not the first. But it is another draft... I'd like to get through these all soon :-) >> >>> >>> >>> >>>> -- >>> >>> >>> >>>> Best regards, >>> >>>> Kathleen >>> >>> >>> >>>> Thanks a >>>> bunch, >>> >>>> -- Mike >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> Best regards, >>> >>> Kathleen >>> >>> >>> >>> _______________________________________________ >>> >>> jose mailing list >>> >>> jose@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> >>> Thanks >>> again, >>> >>> -- >>> Mike >> Thanks for your help!! >> >> -- >> >> Best regards, >> Kathleen > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Fri May 2 08:05:29 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6E51A6FB4 for ; Fri, 2 May 2014 08:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtyE_TRI3CUH for ; Fri, 2 May 2014 08:05:24 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id D49481A6FD1 for ; Fri, 2 May 2014 08:05:23 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hl10so1975886igb.15 for ; Fri, 02 May 2014 08:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7It7Kt7blpHBGl8mGkazTNNAzFqC4cXSbxvzROGyvH4=; b=xue9tm0Q7FkolZdRAXKdNm4lssIUdYLk1f02OI1pfN7WehAb6fQXG11uU7c8cIZ3fb 4DRENROivUU2O5sAbZHcDKvBJttBFDHwlzbTwqRiwTNWWzFr5HwrI5wgLOFivkpJXVxZ R59M31HiuhzrKYHpnlttmwwx6wg1UzSdHeDcI5OH77IiT83Rk9qK8D81Y1shvPm4Eyax KJaRCrVHBjGyouYEdkhIH8MFHvj11fDhUlgc72PLbD7TKGnHjaOluk6OH4Ak58KiT944 908LBCynirIQCc/UWuVxR58NC3LQDmhsFEDpyCzYQ3smLh5+snNQSa0C/B1NGWZNrbIB l6ag== X-Received: by 10.51.17.5 with SMTP id ga5mr5030248igd.2.1399043121407; Fri, 02 May 2014 08:05:21 -0700 (PDT) Received: from [10.0.245.50] (mobile-166-147-100-113.mycingular.net. [166.147.100.113]) by mx.google.com with ESMTPSA id k8sm7378919ige.0.2014.05.02.08.05.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 08:05:19 -0700 (PDT) X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (11D167) In-Reply-To: <5363B1A7.2080404@isoc.org> Date: Fri, 2 May 2014 10:05:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8137EF92-E3D2-454C-AB1F-76B2AF3692B2@gmail.com> References: <4E1F6AAD24975D4BA5B16804296739439A15D3B1@TK5EX14MBXC286.redmond.corp.microsoft.com> <00db01cf5a82$db1c7f80$91557e80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739439A1971D7@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A14A2@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A1A3C64@TK5EX14MBXC288.redmond.corp.microsoft.com> <3C134FBC-EF0D-4B4E-AACD-1869EFAD34AA@gmail.com> <5363B1A7.2080404@isoc.org> To: Karen ODonoghue Archived-At: http://mailarchive.ietf.org/arch/msg/jose/vYsisuYO096U5nzOTCXBVAmIvQQ Cc: "" Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:05:28 -0000 Thank you, Karen. 'They' below should have said the chairs. Thanks, Kathleen=20 Sent from my iPhone > On May 2, 2014, at 9:54 AM, Karen ODonoghue wrote: >=20 > Kathleen, >=20 > I will add some text to the tracker to make this clearer. My apologies for= the confusion. Thanks for your efforts. I know there is a pile of stuff to p= low through... >=20 > Regards, > Karen >=20 >> On 5/2/14 10:18 AM, Kathleen Moriarty wrote: >> Thanks for the detailed response and all of your efforts on this draft. >>=20 >> I need to backtrack on the statement I made about the WG decision on cons= ensus for alg none. They both have informed me that there was consensus, no= t just agreement to keep it in for implementations. Could this be more expl= icit in the issue tracker or on the list by the chairs so I have something t= o point to if it comes up in last call? >>=20 >> I am traveling today, so I don't have time to search for links on the equ= ivalent for 'thumbprints' in XML. They refer to this as a fingerprint and i= t was implemented in the XML oxygen editor used for certificates. This may h= elp in case folks are interested and have some time to look into it. >>=20 >> Thank you, >> Kathleen >>=20 >> Sent from my iPhone >>=20 >>> On May 1, 2014, at 1:10 PM, Mike Jones wro= te: >>>=20 >>> Yes, I realize that I haven't revised the security considerations yet. I= started to do it and realized that it was a more intricate exercise than I'= d originally anticipated, so decided to get the -26 drafts out with the easy= stuff first, for working group review. These mostly address comments by yo= u, Scott, Hannes Tschofenig (which was actually a comment on JWT, but that a= pplied to JOSE as well), and Antonio Sanso. >>>=20 >>> WORKING GROUP: I would appreciate any specific suggestions on additions= that you'd like to have made to the security considerations section at http= ://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-8. >>>=20 >>> I also realize that I still need to write the note to David McGrew. >>>=20 >>> Kathleen, can you point us to the XML equivalents of certificate thumbpr= ints that you used? That could be interesting. FYI, I also submitted an in= dividual -00 JSON thumbprint draft last month at http://tools.ietf.org/html/= draft-jones-jose-jwk-thumbprint-00 (because the need for a JSON-based thumbp= rint came up in practice), but I'm not proposing that we try to jam it into J= WS at this point. It's fine for that to be work after a recharter, should t= he WG want to take it up. >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>> Sent: Thursday, May 01, 2014 10:47 AM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>>=20 >>> Hi Mike, >>>=20 >>> Thanks for posting the updated draft. At a minimum, the security consid= erations update still needs to be updated. I'd like an okay from Jim, the d= ocument shepherd when he thinks this is all ready in case I am missing any o= ther open issues. The rest is in-line as this seems to summarize all of the= issues and there were discussions in other threads that I would prefer to n= ot see them get lost. >>>=20 >>>> On Thu, May 1, 2014 at 3:09 AM, Mike Jones wrote: >>>> The algorithm name =E2=80=9CRSA-OAEP-256=E2=80=9D for RSAES OAEP using S= HA-256 and >>>> MGF1 with >>>> SHA-256 has been added at >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#sect >>>> ion-4.3, >>>> per your request, Kathleen. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- Mike >>>>=20 >>>>=20 >>>>=20 >>>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones >>>> Sent: Friday, April 25, 2014 6:38 PM >>>>=20 >>>>=20 >>>> To: Kathleen Moriarty; Jim Schaad >>>> Cc: jose@ietf.org; draft-ietf-jose-json-web-algorithms@tools.ietf.org >>>>=20 >>>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, Kathleen. Comments are inline, marked =E2=80=9CMike>=E2=80=9D=E2= =80=A6 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Kathleen >>>> Moriarty >>>> Sent: Friday, April 25, 2014 2:07 PM >>>> To: Jim Schaad >>>> Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org; >>>> jose@ietf.org >>>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>>>=20 >>>>=20 >>>>=20 >>>> Sorry for the delay in my response. I'll answer in-line below. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks! >>>>=20 >>>>=20 >>>>=20 >>>>> On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad w= rote: >>>>=20 >>>>=20 >>>>=20 >>>>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones >>>>> Sent: Thursday, April 17, 2014 10:46 AM >>>>> To: Kathleen Moriarty; jose@ietf.org >>>>> Cc: draft-ietf-jose-json-web-algorithms@tools.ietf.org >>>>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>>>=20 >>>>=20 >>>>=20 >>>>> Thanks for taking the time to do the review, Kathleen. Responses are >>>>> inline, flagged by =E2=80=9CMike>=E2=80=9D. I also pasted your follow= -on note in and >>>>> responded to it as well. >>>>=20 >>>>=20 >>>>=20 >>>>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>>>> Sent: Thursday, April 17, 2014 7:51 AM >>>>> To: jose@ietf.org >>>>> Cc: Mike Jones; draft-ietf-jose-json-web-algorithms@tools.ietf.org >>>>> Subject: AD review of draft-ietf-jose-json-web-algorithms >>>>=20 >>>>=20 >>>>=20 >>>>> Hello Mike & JOSE members, >>>>=20 >>>>=20 >>>>=20 >>>>> I am working my way through the requested reviews to progress the >>>>> JOSE >>>>> drafts and can see a lot of work has been done, thank you. As I read >>>>> through the Algorithms (JWA) draft there are some changes that will >>>>> need to be made to avoid problems during the IESG review. This is a >>>>> pretty big change for the draft, but will help make the review and >>>>> approval faster. >>>>> Typically, the lists of algorithms are handled through a draft update >>>>> as opposed to creating an IANA registry. A good example is a recent >>>>> update of a draft in the IPSECME working group so you can see the >>>>> structure and the precedence for this model. >>>>=20 >>>>=20 >>>>=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts >>>>=20 >>>>=20 >>>>=20 >>>>> Mike> So you=E2=80=99re suggesting that future JWA drafts might obsole= te the >>>>> Mike> current >>>>> one, much like draft-ietf-ipsecme-esp-ah-reqts will obsolete RFC >>>>> 4835, >>>>> which obsoleted RFC 4305, etc.? If so, could work on revising the >>>>> JWA >>>>> draft accordingly and send proposed changes to the working group. >>>>=20 >>>>=20 >>>> KM> I am not sure where Jim's response is, but I have been looking >>>>=20 >>>> into this. My initial message came after some conversations with >>>> Sean. In response to your posts, I reached out to a couple of other >>>> ADs who may have had concerns and *think* we are okay as long as the >>>> registries will be used with a designated expert review to add to the >>>> registry. If a draft is required for an update, that would cause >>>> problems as opposed to a draft with no registries. Sorry for the confu= sion here. >>>>=20 >>>>=20 >>>>=20 >>>> Mike> Jim=E2=80=99s response is at >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04071.html, >>>> starting with =E2=80=9C[JLS] Kathleen, I don=E2=80=99t know that I agre= e with this >>>> statement. There are a number of different places where IANA >>>> registries are used for the purpose of having lists of algorithms.=E2=80= =9D >>>> All the registries established already require expert review, as >>>> described at http://tools.ietf.org/html/draft-ietf-jose-json-web-algori= thms-25#section-7. >>>> So it sounds like we should be OK. That=E2=80=99s good. Thanks for wo= rking >>>> the issue. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Now for other edits and questions: >>>>=20 >>>>=20 >>>>=20 >>>>> Section 3.6 - Can you explain why would this be included? If you are >>>>> not going to sign, I am not sure why one would use JOSE at all. >>>>=20 >>>>=20 >>>>=20 >>>>> Mike> This is included to enable representing content that is >>>>> Mike> optionally >>>>> signed in protocols using JWS. Having this means that whether or not >>>>> the content is signed, it can use a uniform representation, which is >>>>> easy to parse. This is in production use, for instance, to enable >>>>> OAuth authorization request messages that are optionally signed. >>>>> Sometimes content need not be signed at the JWS level because it=E2=80= =99s >>>>> integrity protected by other protocol layers =E2=80=93 in particular, o= ften >>>>> by >>>>> the use of TLS. Another use case is where signing adds additional >>>>> optional value, but where there=E2=80=99s no harm in using unsigned co= ntent =E2=80=93 >>>>> for instance, while normal OAuth requests are inline and unsigned, a >>>>> registered extension enables request parameters to be passed by >>>>> reference, rather than by value; the object referenced containing the >>>>> parameters is a JWS; the JWS can optionally be signed. The current, >>>>> carefully refined treatment of =E2=80=9Cnone=E2=80=9D is the result of= substantial >>>>> mailing list discussions and discussions on working group calls. >>>>> While a less parallel treatment of unsigned JWSs was proposed in >>>>> http://trac.tools.ietf.org/wg/jose/trac/ticket/36, this alternative >>>>> syntax was rejected by the working group in favor of the current appro= ach. >>>>=20 >>>>=20 >>>> KM> I responded to Vladamir on this one and would just like to know if >>>>=20 >>>> there is WG consensus behind the decision. Can you point me to >>>> discussions on this? >>>>=20 >>>>=20 >>>>=20 >>>> Mike> Brian Campbell did a good job summarizing the consensus in his >>>> Mike> note >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04082.html. Jim >>>> Schaad documented the consensus in his note closing issue #36 at the >>>> end of http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >>>>=20 >>>>=20 >>>>=20 >>>> Mike> This was extensively discussed on a thread titled =E2=80=9C[jose]= #36: >>>> Algorithm "none" should be removed=E2=80=9D between 7/31/13 and 8/22/13= and >>>> then also on a follow-up thread named =E2=80=9C[jose] Text about applic= ations >>>> and "alg":"none"=E2=80=9D between 9/3/13 and 9/9/13. The latter thread= >>>> resulted from an action items from the preceding interim working group >>>> call (the agenda for which was published at >>>> http://www.ietf.org/proceedings/interim/2013/08/19/jose/agenda/agenda-i= nterim-2013-jose-5). >>>>=20 >>>>=20 >>>>=20 >>>> Mike> The text agreed to by the working group that Brian referred to >>>> Mike> was >>>> added in draft-ietf-jose-json-web-algorithms-16, published on 9/15/13. >>>> Jim closed the issue on 10/28/13. >>> My read of the threads and issue tracker was that implementations won ou= t to close this discussion, but that there was no consensus. There were man= y involved in the discussion that provided arguments and support for not inc= luding alg none. I'll support this as a WG decision based on implementation= s, as that's how I read it. I appreciate all of the feedback on actual use o= f this as it will be helpful in case this comes up during last call. >>>=20 >>>>=20 >>>>=20 >>>>> Section 5.2 - The write up of this section seems a bit more >>>>> complicated than necessary. It seems it would have just been simpler >>>>> to state that the sizes vary as required by the algorithms and key >>>>> lengths used rather than providing the differences from one to the nex= t. >>>>> Can you simplify this? >>>>=20 >>>>> After looking through some of the mailing list discussions, it seems >>>>> there was already agreement to slim this and other sections down by >>>>> pointing to the draft-mcgrew-aead-aes-cbc-hmac-sha2 >>>>=20 >>>>=20 >>>>=20 >>>>> http://www.ietf.org/mail-archive/web/jose/current/msg02276.html >>>>=20 >>>>> Can I get an update as to where that stands, referencing what you can >>>>> from that draft as opposed to duplicating text? Thanks! >>>>=20 >>>>> Mike> Sure. The key part of the message you cited is =E2=80=9COnce th= e >>>>> Mike> McGrew >>>>> Mike> draft >>>>> has been refactored to separate the description of the calculation >>>>> steps (which JOSE is using) from the AEAD representation steps (which >>>>> JOSE is not using), and to include test vector values that show >>>>> results without performing the AEAD representation concatenations, I >>>>> agree that we'll be able to just reference it, rather than >>>>> duplicating >>>>> it.=E2=80=9D The problem is that the refactoring was never done. The= >>>>> algorithm description in >>>>> draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the >>>>> ciphertext C, as described, also includes the IV value as a prefix >>>>> and >>>>> the authentication tag T as a suffix, rather than treating each of >>>>> those as separate values. The test vectors do the same. Yes, David >>>>> added appendix B saying that the values could be treated as separate, >>>>> but the write-up does no favors to implementers, as both the core >>>>> algorithm description and the test vectors assume they are combined. >>>>> (I personally know that working out how to treat them as separate >>>>> from >>>>> David=E2=80=99s current draft is a tedious and error-prone exercise, h= aving >>>>> had to do so to tease them apart for the current JWA write-up.) >>>>> David >>>>> has been asked about doing the refactoring several times by multiple >>>>> parties, but he=E2=80=99s a busy guy, and I don=E2=80=99t think it=E2=80= =99s ever reached the >>>>> top of his queue. As it is, the JWA description is clear and >>>>> semantically equivalent and implementers have shown that they can >>>>> successfully build it. Finally, we wouldn=E2=80=99t want to take a no= rmative >>>>> dependency upon a draft that appears to have been largely abandoned >>>>> (or at least neglected), as doing so could indefinitely stall >>>>> publication of RFC versions of the JOSE specs. >>>>=20 >>>>=20 >>>>=20 >>>>> [JLS] I always considered this to be a sufficient refactoring to use >>>>> the mcgrew draft as a basis. I did not have the same type of >>>>> problems >>>>> with breaking the test vectors apart that you seem to have had. >>>>=20 >>>>=20 >>>>=20 >>>> KM> OK, has anyone reached out to Dave McGrew to discuss? How can we >>>>=20 >>>> clear this up? >>>>=20 >>>>=20 >>>>=20 >>>> Mike> I=E2=80=99d had in-person and phone conversations with him about i= t last >>>> Mike> year, >>>> but not much happened as a result. >>>>=20 >>>>=20 >>>>=20 >>>> Mike> I wrote more about your question at >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04074.html in >>>> which I pointed out errors and sources of confusion in David=E2=80=99s d= raft >>>> that would complicate life for developers and possibly result in >>>> incorrect implementations; Jim responded at >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04075.html. I=E2=80= =99ll >>>> send a note to David pointing these out and offering to produce >>>> proposed changes for him to incorporate, but unless he either decides >>>> to devote bandwidth to advancing the draft (it=E2=80=99s already expire= d once) >>>> or is willing to delegate it to us to do so, I think we don=E2=80=99t h= ave >>>> much choice but to continue to have a complete and accurate >>>> description of the algorithms in the JWA doc, and let his draft >>>> advance at its own pace. I=E2=80=99ll note that we also don=E2=80=99t h= ave a >>>> publication vehicle for the draft to become an RFC, because it=E2=80=99= s not in any working group, nor does it have AD sponsorship that I=E2=80=99m= aware of. >>> Thank you, please keep us posted on the status/progress so we know how t= o move forward. >>>=20 >>>>=20 >>>>=20 >>>>> Security Considerations: While it is true the content is covered in >>>>> other places, this section could benefit from improvement before it >>>>> goes to the SecDir review. The second sentence in the first >>>>> paragraph >>>>> says the >>>>> following: >>>>=20 >>>>> Among these issues are >>>>=20 >>>>> protecting the user's private and symmetric keys, preventing >>>>> various >>>>=20 >>>>> attacks, and helping the user avoid mistakes such as inadvertently >>>>=20 >>>>> encrypting a message for the wrong recipient. >>>>=20 >>>>> It would be helpful if you could expand the text and make it more >>>>> descriptive and applicable to this document. For example, shouldn=E2=80= =99t >>>>> the first section say user=E2=80=99s private asymmetric and symmetric k= eys? >>>>> I >>>>> assume that is what was intended with private, but it reads funny to >>>>> me without that. The only =E2=80=98attack=E2=80=99 or caution mention= ed in the >>>>> document is for the application to prevent a user from selecting the >>>>> wrong key. Please include some attacks that developers and >>>>> implementers should be aware and cautioned on, or state that specific >>>>> attacks and considers are detailed in the subsections to follow. >>>>=20 >>>>=20 >>>>=20 >>>>> Mike> OK, I can work on expanding that. There are some other attacks >>>>> mentioned in the other drafts, such as timing attacks, which can >>>>> probably at least be mentioned here. I=E2=80=99ll send draft text to t= he >>>>> list >>>>> and consult with you before doing anything to the actual drafts. >>>>> Specific suggestions from working group participants would also be >>>>> highly appreciated. >>> The Security Considerations section requires updating, let me know when t= his has been done. Thanks! >>>> KM> Great, thank you! >>>>=20 >>>>=20 >>>>> I think that's it for now. Although I do need to look through some >>>>> more of the previous conversations on the mailing list and in the >>>>> issue tracker. >>>>=20 >>>>=20 >>>>=20 >>>>> I see there are some open discussions, like the one Richard raised >>>>> yesterday that need to be resolved in the document as well before we >>>>> move forward with this one. Thanks for all of your effort on this dra= ft!! >>>>=20 >>>>=20 >>>>=20 >>>>> Mike> Per my note >>>>> http://www.ietf.org/mail-archive/web/jose/current/msg04061.html, I >>>>> don=E2=80=99t believe that that particular issue is open. It had been= >>>>> extensively discussed within the working group multiple times and the >>>>> issue was explicitly closed by the chairs, leaving the status quo in >>>>> place in which there are required algorithms for interoperability reas= ons. >>>>=20 >>>>=20 >>>>=20 >>>>> I'm going to add one more question to the review as I had the same >>>>> thought as Scott & Burt in their review of JWA (and also in JWS). >>>>> Why >>>>> are there no other options in addition to SHA1? The response to >>>>> Scott >>>>> pointed back to early WG decisions, but I have heard this concern >>>>> from >>>>> others and have it myself, so I am not sure this one is resolved. >>>>> I'd like to revisit it. >>>>=20 >>>>=20 >>>>=20 >>>>> http://www.ietf.org/mail-archive/web/jose/current/msg04020.html >>>>=20 >>>>=20 >>>>=20 >>>>> Mike> If adding a new =E2=80=9CRSA-OAEP-256=E2=80=9D algorithm identif= ier for =E2=80=9CRSAES >>>>> Mike> with >>>>> Optimal Asymmetric Encryption Padding using the MGF1 mask generation >>>>> function and the SHA-256 hash function=E2=80=9D would make a number of= people >>>>> more comfortable, including you, there=E2=80=99s nothing wrong with do= ing so. >>>>> However, it=E2=80=99s also not clear that it would be of much short-te= rm >>>>> practical benefit because, at least as of the implementation survey >>>>> done in July 2012, many crypto libraries don=E2=80=99t expose a way to= get at >>>>> this algorithm combination. >>>>> However, the same argument could be made about RSASSA-PSS, which we >>>>> did add identifiers for in the end. In short, I don=E2=80=99t think a= nyone >>>>> in >>>>> the working group would stridently object if you asked for this >>>>> additional algorithm identifier to be added. Your call=E2=80=A6 >>>>=20 >>>> KM> I'd say to add it. I'll have a similar comment for the JWS draft >>>>=20 >>>> for SHA256 support on thumbprints. >>>>=20 >>>>=20 >>>>=20 >>>> Mike> OK =E2=80=93 I=E2=80=99ll add it. >>> Thanks, and I see Scott's review and okay as well, which is helpful. >>>>=20 >>>> Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed. >>>> Mike> I=E2=80=99m >>>> aware of no SHA-256 certificate thumbprint deployments. I=E2=80=99ll n= ote >>>> that even if SHA-1 were completely broken, that wouldn=E2=80=99t be a s= ecurity >>>> issue because it=E2=80=99s just being used to generate a digest of publ= icly >>>> available certificate information. It=E2=80=99s not being used to cryp= tographically obscure anything. >>>> (But that=E2=80=99s actually a discussion for another draft. J) >>> This is in place for the XML equivalents and should be possible for JSON= . I used this at least 2 years ago in the XML Oxygen editor. I believe thi= s has been brought up before in terms of JSON, so I am not the first. But i= t is another draft... I'd like to get through these all soon :-) >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> -- >>>>=20 >>>>=20 >>>>=20 >>>>> Best regards, >>>>=20 >>>>> Kathleen >>>>=20 >>>>=20 >>>>=20 >>>>> Thanks a >>>>> bunch, >>>>=20 >>>>> -- Mike >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Kathleen >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> jose mailing list >>>>=20 >>>> jose@ietf.org >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>=20 >>>>=20 >>>> Thanks >>>> again, >>>>=20 >>>> -- >>>> Mike >>> Thanks for your help!! >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >> _______________________________________________ >> 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 nobody Fri May 2 08:24:59 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154371A6FF4 for ; Fri, 2 May 2014 08:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkxsS0mTptkj for ; Fri, 2 May 2014 08:24:54 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 05B101A6F66 for ; Fri, 2 May 2014 08:24:53 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id m1so2818428oag.0 for ; Fri, 02 May 2014 08:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8LKvtz8wR8qDtlecXT59As3iz1i6ZBk+hKrbGD8Ol6w=; b=M5mA6g7ayZ2JueviuGA86Gan4T3E0U2ab/nimYOGTyq0FLXX1ugsS04+JaxnE3jKQL b9aUkBlToPbATUdINhOOuT7DcvAiqWMoAY7HK4jPAky0UdjQCKRn0n0xXI2CalZlYD5z JmIWnI8Xi+p6bfNxEdg1hFK+wmsbrKvIoCDuAMealOtNSKsVmCHm7qzaJh5dwzZPIK+1 dFPVYyh44R9G1KTU2SmPa5VAZ0Vbsrr/VWSyv1ysxiszg4xFtZhfBaKcAlIU5RyUQznu rFdd0dUxD4kSdvI7dm6vaEQLJBk+Y267VxTLEJOW5xrQQ5yE8klUz81hVrPCYlZYAg95 FIIQ== X-Gm-Message-State: ALoCoQmeaen+mtU+uUkC4fHV1KNEeLUIBcYrAB0tcrbsZd0QTO9vF8Mlc8hriqqPhKMAP809Iglm MIME-Version: 1.0 X-Received: by 10.60.77.35 with SMTP id p3mr17358941oew.46.1399044291703; Fri, 02 May 2014 08:24:51 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Fri, 2 May 2014 08:24:51 -0700 (PDT) In-Reply-To: References: <20140417111031.3c376e9e86469f12ae2f88da05bfa671.79baba1ed9.wbe@email07.europe.secureserver.net> Date: Fri, 2 May 2014 08:24:51 -0700 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=047d7b33d24408472804f86c6298 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/g8_T6_-R7HwgOxeCJ_XqS41Igys Cc: Kathleen Moriarty , "" , Michael Jones , "jose@ietf.org" , Vladimir Dzhuvinov Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:24:56 -0000 --047d7b33d24408472804f86c6298 Content-Type: text/plain; charset=UTF-8 I'm mostly staying out of this. I've had my bite at this apple, and it came back sour. Brian's note on the roughness of consensus is spot on. The security considerations text is good enough that I'm not going to argue things further, but I'm far from convinced that it will result in alg:none actually being deployed securely. On Fri, Apr 25, 2014 at 3:17 PM, Brian Campbell wrote: > Plaintext JWSs haven't been free of controversy but the topic has been > discussed many times and the [rough] consensus of the WG is that the "none" > JWS alg is useful. It is in use by the finalized versions of OpenID > Connect, as Vladimir has alluded to. And it has been fairly wildly deployed > in production use. > The "production use" point has been made a few times. That argument is completely irrelevant to the question of whether a feature leads to security risks. Just because something is in production use doesn't mean it's secure. It just means that whatever flaws it has haven't been exploited enough to get people to quit using it. --Richard > > The "Plaintext JWS Security Considerations" in section 8.5 of JWA [1] > represents the consensus the WG came to, which keeps the "none" alg but > mandates that implementations "MUST NOT accept such objects as valid unless > the application specifies that it is acceptable for a specific object." > > [1] > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-8.5 > > Vladimir > > On Fri, Apr 25, 2014 at 2:51 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Thanks, Vladimir. >> >> Is there consensus in the WG that this is the right thing to do? I'm >> expecting some push-back on this one and want to make sure it has >> consensus behind it. I have heard of a couple of objections already. >> >> On Thu, Apr 17, 2014 at 2:10 PM, Vladimir Dzhuvinov >> wrote: >> >> Thanks, Vladimir. >> >> >> >> How would they be secured then? With the current threat landscape, it >> >> seems odd that we would be putting forth a method that is not secured? >> >> Does this rely on transport for security? >> > >> > Yes, securing the JWS message with TLS for instance, as Mike just >> > pointed >> > out in the his response. >> > >> > JWT-encoded ID tokens in OpenID Connect is one such example, but only >> > when >> > the token is returned from the OAuth 2.0 token endpoint where TLS is >> > mandatory, clients can then register to receive plaintext ID tokens: >> > >> > http://openid.net/specs/openid-connect-core-1_0.html#IDToken >> > >> > >> > There is a section in the JWA spec to instruct developers of the various >> > security >> > considerations regarding use of "none" alg JWS: >> > >> > >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-8.5 >> > >> > >> > Vladimir >> > >> > >> > >> >> On Thu, Apr 17, 2014 at 12:57 PM, Vladimir Dzhuvinov < >> >> vladimir@connect2id.com> wrote: >> >> >> >> > Hi Kathleen, >> >> > >> >> > >> >> > > Section 3.6 - Can you explain why would this be included? If you >> are >> >> > not going to sign, I am not sure why one would use JOSE at all. >> >> > > >> >> > >> >> > Perhaps the most popular application of JWS today is to construct >> JSON >> >> > Web Tokens (JWT), such as the ID tokens in OpenID Connect. The JWT >> spec >> >> > permits plain tokens that don't have a signature and this is enabled >> by >> >> > the special case "none" alg in JWS. >> >> > >> >> > Plaintext JWTs are explained here: >> >> > >> >> > >> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#section-6 >> >> > >> >> > >> >> > Vladimir >> >> > >> >> > >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> 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 > > --047d7b33d24408472804f86c6298 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= 9;m mostly staying out of this. =C2=A0I've had my bite at this apple, a= nd it came back sour. =C2=A0Brian's note on the roughness of consensus = is spot on. =C2=A0The security considerations text is good enough that I= 9;m not going to argue things further, but I'm far from convinced that = it will result in alg:none actually being deployed securely.

On Fri, Apr= 25, 2014 at 3:17 PM, Brian Campbell <bcampbell@pingidentity.com<= /a>> wrote:
Plaintext JWSs haven&#= 39;t been free of controversy but the topic has been discussed many times a= nd the [rough] consensus of the WG is that the "none" JWS alg is = useful. It is in use by the finalized versions of OpenID Connect, as Vladim= ir has alluded to. And it has been fairly wildly deployed in production use= .

The "production use"= point has been made a few times. =C2=A0That argument is completely irrelev= ant to the question of whether a feature leads to security risks. =C2=A0Jus= t because something is in production use doesn't mean it's secure. = =C2=A0It just means that whatever flaws it has haven't been exploited e= nough to get people to quit using it.

--Richard

=C2=A0

The "Plaintext JWS Security Considerations" in section = 8.5 of JWA [1] represents the consensus the WG came to, which keeps the &qu= ot;none" alg but mandates that implementations "MUST NOT accept s= uch objects as valid unless the application specifies that it is acceptable= for a specific object."

[1]
http://tools.ietf.org/html/draft-i= etf-jose-json-web-algorithms-25#section-8.5

Vladimir

On Fri, Apr 25, 2014 at 2:51 PM, Kathleen Moriar= ty <kathleen.moriarty.ietf@gmail.com> wrote:<= br>
Thanks, Vladimir.

Is there consensus in the WG that this is the right thing to do? =C2=A0I= 9;m
expecting some push-back on this one and want to make sure it has
consensus behind it. =C2=A0I have heard of a couple of objections already.<= br>
On Thu, Apr 17, 2014 at 2:10 PM, Vladimir Dzhuvinov
<= vladimir@connect2id.com> wrote:
>> Thanks, Vladimir.
>>
>> How would they be secured then? =C2=A0With the current threat land= scape, it
>> seems odd that we would be putting forth a method that is not secu= red?
>> =C2=A0Does this rely on transport for security?
>
> Yes, securing the JWS message with TLS for instance, as Mike just
> pointed
> out in the his response.
>
> JWT-encoded ID tokens in OpenID Connect is one such example, but only<= br> > when
> the token is returned from the OAuth 2.0 token endpoint where TLS is > mandatory, clients can then register to receive plaintext ID tokens: >
> http://openid.net/specs/openid-connect-core-1_0.html#I= DToken
>
>
> There is a section in the JWA spec to instruct developers of the vario= us
> security
> considerations regarding use of "none" alg JWS:
>
> http://tools.ietf.org/html/draft-ietf= -jose-json-web-algorithms-25#section-8.5
>
>
> Vladimir
>
>
>
>> On Thu, Apr 17, 2014 at 12:57 PM, Vladimir Dzhuvinov <
>> vladi= mir@connect2id.com> wrote:
>>
>> > Hi Kathleen,
>> >
>> >
>> > > Section 3.6 - Can you explain why would this be included= ? =C2=A0If you are
>> > not going to sign, I am not sure why one would use JOSE at al= l.
>> > >
>> >
>> > Perhaps the most popular application of JWS today is to const= ruct JSON
>> > Web Tokens (JWT), such as the ID tokens in OpenID Connect. Th= e JWT spec
>> > permits plain tokens that don't have a signature and this= is enabled by
>> > the special case "none" alg in JWS.
>> >
>> > Plaintext JWTs are explained here:
>> >
>> > http://tools.ietf.org/html/draft-i= etf-oauth-json-web-token-19#section-6
>> >
>> >
>> > Vladimir
>> >
>> >
>>
>>
>> --
>>
>> Best regards,
>> Kathleen



--

Best regards,
Kathleen

_______________________________________________
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


--047d7b33d24408472804f86c6298-- From nobody Sat May 3 06:37:28 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEEF1A00C2 for ; Sat, 3 May 2014 06:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO4jfJUExy7K for ; Sat, 3 May 2014 06:37:24 -0700 (PDT) Received: from na3sys009aog137.obsmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAA11A00BF for ; Sat, 3 May 2014 06:37:24 -0700 (PDT) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKU2TxEeXbeU0U2CMe9bznnNedHATJJu0D@postini.com; Sat, 03 May 2014 06:37:22 PDT Received: by mail-ie0-f174.google.com with SMTP id ar20so6059403iec.5 for ; Sat, 03 May 2014 06:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2f/Bh/jyWZCf0fYO+FwVUqbKOdo6rX+h3skFHpSDWiM=; b=KqY6rqFQvrKf+NIrZTykaL7rdAgFd9/PhisVnMFNS55yilUF8E5GWNYu26lYM+WW5J YiBNjPL/5PdhRv98kPqKcUG/LUMAY8h7L+4N6aLLGRcUuOP4SUJ9bUQn3931I1TrJNi6 i3i0Un/QYGgnKEm5Y7H4ZN9kI0zAxRDOHgLQ5m5fBRQNUPkp/xNgwGdWs50zRwSmYojX /P3EKnLyU7+36ZhUp82aWABE4KePUjb+GMDmon0E59gYJebKrTwi3p6647jzMmq8wUi5 bcZ/JAQM+UZKKIoYpfnBMw3qgByo/YLvp5eMGlQbjYruv8Wd3iYnE+/FDGHfUpgUOIAa n0KA== X-Gm-Message-State: ALoCoQlQcD98J0QBV8lww/lslEl1LD60jIE7asvB+k6Y+d9iijEpHgo4MW6apOXVUwwvebqegYpourB0yuVNNFVTj+GjyGNB1VO8D92+nVdlxv53qirQslUTBFTVfNanekF9qxfbey2U X-Received: by 10.42.136.130 with SMTP id u2mr21852739ict.51.1399124241336; Sat, 03 May 2014 06:37:21 -0700 (PDT) X-Received: by 10.42.136.130 with SMTP id u2mr21852727ict.51.1399124241184; Sat, 03 May 2014 06:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Sat, 3 May 2014 06:36:51 -0700 (PDT) In-Reply-To: <5363C88E.5070209@gmail.com> References: <5363C88E.5070209@gmail.com> From: Brian Campbell Date: Sat, 3 May 2014 07:36:51 -0600 Message-ID: To: Sergey Beryozkin , "jose@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba6e8c0664988004f87eff32 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/vit5EDdrnK291C8lPMivWKqpfHQ Cc: "" Subject: Re: [jose] [OAUTH-WG] [OT] Validation of JWE spec Appendix 1 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 13:37:26 -0000 --90e6ba6e8c0664988004f87eff32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sergey, This question might be more appropriate for the JOSE WG [0] list (which I've cc'd) as JWE is being developed there. Some of the algorithms, RSAES OAEP being one of them, are probabilistic encryption schemes which incorporate some element of randomness to yield a different output even when encrypting the same content multiple times. So the behavior you are observing is to be expected. That means that exactly reproducing the various steps of the examples in the specs will not be possible in some cases. I was recently discussing this off list with Matt Miller, the author of the JOSE Cookbook [1], and my suggestion was to have the cookbook just make note of which examples, or which parts of which examples, can't be easily reproduced due to non-deterministic algorithms. I think that your question here suggests that that idea might well provide utility to users/readers of that document. Hope that helps, Brian [0] http://tools.ietf.org/wg/jose/ [1] http://tools.ietf.org/html/draft-ietf-jose-cookbook-02 On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin wro= te: > Hi, > > I'm starting experimenting with JWE, and the 1st thing I wanted to do was > to quickly test the example at [1]. > > Sorry if it is something that is very obvious and off-topic, but I can't > seem to validate the encryption of the content encryption key: I keep > getting a different output every time the test code runs. > > The code is the one that I wrote by 'scraping' the code from all over the > Web but also I see Jose.4.j [3] produces a different output too. > Is it due to the given key properties specified in [1] or it is actually > indeed expected that production at [2] is reproducible ? > > Cheers, Sergey > > [1] http://tools.ietf.org/html/draft-ietf-jose-json-web- > encryption-26#appendix-A.1 > [2] http://tools.ietf.org/html/draft-ietf-jose-json-web- > encryption-26#appendix-A.1.3 > [3] https://bitbucket.org/b_c/jose4j/wiki/Home > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 [image: Ping Identity logo] Brian Campbell [Enter Title] @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --90e6ba6e8c0664988004f87eff32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sergey,

This question = might be more appropriate for the JOSE WG [0] list (which I've cc'd= ) as JWE is being developed there.

Some of the algo= rithms, RSAES OAEP being one of them, are probabilistic encryption schemes = which incorporate some element of randomness to yield a different output ev= en when encrypting the same content multiple times. So the behavior you are= observing is to be expected.

That means that exactly reproducing the various steps of the exam= ples in the specs will not be possible in some cases. I was recently discus= sing this off list with Matt Miller, the author of the JOSE Cookbook [1], a= nd my suggestion was to have the cookbook just make note of which examples,= or which parts of which examples, can't be easily reproduced due to no= n-deterministic algorithms. I think that your question here suggests that t= hat idea might well provide utility to users/readers of that document.

Hope that helps,
Brian


[0] http://tools.ietf.or= g/wg/jose/
[1] http://tools.ietf.org/html/draft-ietf-jose-= cookbook-02






On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin <sberyozkin@gmail.com= > wrote:
Hi,

I'm starting experimenting with JWE, and the 1st thing I wanted to do w= as to quickly test the example at [1].

Sorry if it is something that is very obvious and off-topic, but I can'= t seem to validate the encryption of the content encryption key: I keep get= ting a different output every time the test code runs.

The code is the one that I wrote by 'scraping' the code from all ov= er the Web but also I see Jose.4.j [3] produces a different output too.
Is it due to the given key properties specified in [1] or it is actually in= deed expected that production at [2] is reproducible ?

Cheers, Sergey

[1] http://tools.ietf.org/html/dra= ft-ietf-jose-json-web-encryption-26#appendix-A.1
[2] http://tools.ietf.org/html/d= raft-ietf-jose-json-web-encryption-26#appendix-A.1.3
[3] https://bitbucket.org/b_c/jose4j/wiki/Home

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
3D"Ping =09
Brian Campbell
[Enter Title]
=09
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"twitter<= /a> 3D"you= 3D"L= 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
3D"Register

--90e6ba6e8c0664988004f87eff32-- From nobody Sat May 3 13:03:48 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D931A1A011D for ; Sat, 3 May 2014 13:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khdt-XYqs9BC for ; Sat, 3 May 2014 13:03:44 -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 291681A011C for ; Sat, 3 May 2014 13:03:43 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.934.12; Sat, 3 May 2014 20:03:32 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0934.000; Sat, 3 May 2014 20:03:31 +0000 From: Antonio Sanso To: Mike Jones Thread-Topic: [jose] RSASSA-PKCS-v1_5 SHA-256 validation example Thread-Index: AQHPTjt3WJ46n0d+20ui8xGQPXp8Gpsrc3GAgAQFmIA= Date: Sat, 3 May 2014 20:03:30 +0000 Message-ID: References: <1D94AAA8-83B4-4BBB-B432-B4965CF00755@adobe.com> <4E1F6AAD24975D4BA5B16804296739439A1A13FE@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A1A13FE@TK5EX14MBXC288.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.47.250] x-forefront-prvs: 0200DDA8BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(189002)(199002)(377454003)(24454002)(54356999)(76176999)(4396001)(86362001)(50986999)(46102001)(21056001)(20776003)(36756003)(83716003)(92726001)(80976001)(82746002)(85852003)(87936001)(2656002)(77982001)(15975445006)(92566001)(101416001)(83072002)(99286001)(76482001)(99396002)(33656001)(79102001)(81542001)(81342001)(31966008)(19580405001)(83322001)(19580395003)(1511001)(74662001)(74502001)(64706001)(66066001)(80022001)(16236675002)(15202345003)(100906001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_F6069EB5B4CF44A1A605CF1D62E5DAF5adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/5WV5IayDqzvTWM2KVGoRXxSOJOg Cc: "jose@ietf.org" Subject: Re: [jose] RSASSA-PKCS-v1_5 SHA-256 validation example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 20:03:47 -0000 --_000_F6069EB5B4CF44A1A605CF1D62E5DAF5adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable thanks a lot Mike regards antonio On May 1, 2014, at 8:54 AM, Mike Jones > wrote: FYI, the -26 draft has been edited to clarify the issue you raised. See ht= tp://tools.ietf.org/html/draft-ietf-jose-json-web-signature-26#appendix-A.2= .2. Thanks for your feedback, -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Antonio Sanso Sent: Tuesday, April 01, 2014 11:19 PM To: jose@ietf.org Subject: [jose] RSASSA-PKCS-v1_5 SHA-256 validation example hi *, IMHO the RSASSA-PKCS-v1_5 SHA-256 validation example n [0] can be a bit bet= ter explained. Indeed it says We pass (n, e), JWS Signature, and the JWS Signing Input to an RSASSA-PKCS-v1_5 signature verifier that has been configured to use the SHA-256 hash function. There is no mention on the fact the JWS Signature should be decoded in orde= r to be verified. IMHO a bit of more wording around this would not harm. WDYT? regards antonio [0] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-25#append= ix-A.2.2 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_F6069EB5B4CF44A1A605CF1D62E5DAF5adobecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0B253F41DAAAA84E903EE5AB8A30AF9E@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable thanks a lot Mike

regards

antonio

On May 1, 2014, at 8:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

FYI, the -26 draft has been edited to clarify the issue yo= u raised.  See http://too= ls.ietf.org/html/draft-ietf-jose-json-web-signature-26#appendix-A.2.2.<= o:p>
 
         &nbs= p;            &= nbsp;           &nbs= p;          Thanks for your fe= edback,
         &nbs= p;             =              &n= bsp;            = ;           -- Mike<= /o:p>
 
From:<= /span> jose [mailto:jose-bounces@ietf.org] On Behalf Of Antonio Sa= nso
Sent: Tuesday, Apr= il 01, 2014 11:19 PM
To: jose@ietf.org
Subject: [jose] RS= ASSA-PKCS-v1_5 SHA-256 validation example
 
hi *,
 
IMHO the RSASSA-PKCS-v1_5 SHA-256 validation example n [0] can be a bi= t better explained.
Indeed it says
 
We p=
ass (n, e), JWS Signature, and the JWS Signing Input to
&nbs=
p;  an RSASSA-PKCS-v1_5 signature verifier that has been configured to=
&nbs=
p;  use the SHA-256 hash function.
 
There is no mention on the fact the JWS Signature should be decoded in orde= r to be verified.
IMHO a bit of more wording around this would not harm.
WDYT?
 
regards
 
antonio
 
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose=

--_000_F6069EB5B4CF44A1A605CF1D62E5DAF5adobecom_-- From nobody Mon May 5 20:40:38 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33A31A06BF for ; Mon, 5 May 2014 20:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmaNkVX-SWH1 for ; Mon, 5 May 2014 20:40:35 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id EE0371A0228 for ; Mon, 5 May 2014 20:40:34 -0700 (PDT) Received: from mail-ig0-f175.google.com ([209.85.213.175]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKU2hZr0YUkFksCxVHRXbaJiSEVihh6iHN@postini.com; Mon, 05 May 2014 20:40:31 PDT Received: by mail-ig0-f175.google.com with SMTP id uq10so3223434igb.2 for ; Mon, 05 May 2014 20:40:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=ZtOlizcXuor+raQR7SMypiNpBhTPE96G7SDGh6qRZks=; b=bGOz7//cI5fOs0m5Sa3+4ufzoQQixO9mtLGhBGvzi3oC/I3YRhExHATWGxL9cbxV5D rEjUqk9OfJbJWzmcBF3sVZuiBhS5/ZgLwf/8DwFbbs9j8pH/XQxyl8Vjr5eJz5W6QIY+ QpSpY5F+nJ1bbjqwSi6UoF6suUwYGxB3/iUvgGN4PjBD7RX1eZn6s7LnC8Let8a37gwc ZhtKWyGBVurxCv0eabh+qw8J+k7ii0jAQIUS8NYXtjIl+C8iwAakUNyr0oE4DDB6HSXj Enti/Gt407p2G4kGvd5VzJ1RLi83y851o7jgroHEN6hAbiSTlhx8tr9odOhZYnMWRrhI 7+ZA== X-Gm-Message-State: ALoCoQnr1uaLHLeuuN2kactWHEgiB6EII/6ZaAHaM1K4Q29WWSyC+RMSZ9Yoq/59ZXsY0+AXyUf3+bR6k7mzA4oanThp0AqxlSjGZSMSTqnrlRyMIk8ke2t3ACO6M2EZqDOrXlTSBJnT X-Received: by 10.50.13.100 with SMTP id g4mr29561583igc.9.1399347630856; Mon, 05 May 2014 20:40:30 -0700 (PDT) X-Received: by 10.50.13.100 with SMTP id g4mr29561561igc.9.1399347630631; Mon, 05 May 2014 20:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Mon, 5 May 2014 20:40:00 -0700 (PDT) From: Brian Campbell Date: Mon, 5 May 2014 20:40:00 -0700 Message-ID: To: "jose@ietf.org" Content-Type: multipart/alternative; boundary=089e013c66147103b804f8b30271 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/GlHPlv5nd3sbQ_BijJBiwM3h2M8 Subject: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 03:40:36 -0000 --089e013c66147103b804f8b30271 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key encryption but, AFAIK, there are no examples using it. I recently added support for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind of confirmation that I've done it correctly (other than self interop). With that in mind, here is a JWE using RSA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to decrypt. The RSA key that was used (in JWK format with both public and private parts) is below the JWE. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj= 1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3Zz= JWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsuc= rzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQE= dRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-E= uU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQw= YpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ct= CKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0= DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} --089e013c66147103b804f8b30271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The latest revision of JWA added a new 'RSA-OAEP-256&#= 39; JWE alg for key encryption but, AFAIK, there are no examples using it. = I recently added support for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind o= f confirmation that I've done it correctly (other than self interop). W= ith that in mind, here is a JWE using RSA-OAEP-256 which I've produced = and I'm hopeful that someone on this WG list will be able to decrypt. T= he RSA key that was used (in JWK format with both public and private parts)= is below the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2Hj= tHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36te= yjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3= o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMR= Kf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W= 251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nO= JP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfe= CGnhWT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cm= bnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10= fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6= fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexM= cb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYe= Itt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d"= :"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-= nLMnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6i= krAHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_Uxmzm= KXYKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI= 6oBk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"= ;7yQmgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxg= FjC9ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2Okb= FAsTMHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVO= vAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saG= GKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM"= ;,"dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H= 7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5= yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJF= buGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwk= bTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTv= dyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVU= c0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ= 2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}<= br>
--089e013c66147103b804f8b30271-- From nobody Tue May 6 02:34:41 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264C01A0188 for ; Tue, 6 May 2014 02:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67laV4p28k-B for ; Tue, 6 May 2014 02:34:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id DB93D1A0157 for ; Tue, 6 May 2014 02:34:36 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 09:34:30 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0934.000; Tue, 6 May 2014 09:34:30 +0000 From: Antonio Sanso To: Brian Campbell Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUA Date: Tue, 6 May 2014 09:34:29 +0000 Message-ID: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.147.117.11] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(189002)(199002)(24454002)(377454003)(101416001)(92566001)(76482001)(92726001)(99286001)(4396001)(99396002)(76176999)(83716003)(86362001)(575784001)(54356999)(21056001)(2656002)(15975445006)(77982001)(87936001)(81542001)(50986999)(81342001)(82746002)(83072002)(36756003)(46102001)(85852003)(31966008)(19580405001)(83322001)(19580395003)(74662001)(74502001)(16236675002)(80022001)(66066001)(64706001)(20776003)(79102001)(33656001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_8B0ED727E1024362B9A34411773E48A6adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/YdMjkElmbJMpUeMJLBikLytCWA4 Cc: "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 09:34:40 -0000 --_000_8B0ED727E1024362B9A34411773E48A6adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, I will give a try and let you know regards antonio On May 6, 2014, at 5:40 AM, Brian Campbell > wrote: The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key encry= ption but, AFAIK, there are no examples using it. I recently added support = for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind = of confirmation that I've done it correctly (other than self interop). With= that in mind, here is a JWE using RSA-OAEP-256 which I've produced and I'm= hopeful that someone on this WG list will be able to decrypt. The RSA key = that was used (in JWK format with both public and private parts) is below t= he JWE. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj= 1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3Zz= JWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsuc= rzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQE= dRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-E= uU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQw= YpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ct= CKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0= DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_8B0ED727E1024362B9A34411773E48A6adobecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5174DB1F1348604894975E6653B71819@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Brian,

I will give a try and let you know

regards

antonio

On May 6, 2014, at 5:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

The latest revision of JWA added a new 'RSA-OAEP-256' JWE = alg for key encryption but, AFAIK, there are no examples using it. I recent= ly added support for it to https://bitbucket.org/b_c/jose= 4j and am looking to get some kind of confirmation that I've done it co= rrectly (other than self interop). With that in mind, here is a JWE using R= SA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to decrypt. The RSA = key that was used (in JWK format with both public and private parts) is bel= ow the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKV= mCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM",&q= uot;dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ= -u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2= zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGt= WZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJ= EIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-= L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG= 5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P= _Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--_000_8B0ED727E1024362B9A34411773E48A6adobecom_-- From nobody Tue May 6 06:25:23 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BA11A015E for ; Tue, 6 May 2014 06:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgFyh0bET_6O for ; Tue, 6 May 2014 06:25:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id DBB161A00ED for ; Tue, 6 May 2014 06:25:18 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 13:25:13 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0934.000; Tue, 6 May 2014 13:25:12 +0000 From: Antonio Sanso To: Brian Campbell Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUAgABAhAA= Date: Tue, 6 May 2014 13:25:12 +0000 Message-ID: <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> In-Reply-To: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.147.117.11] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(377454003)(189002)(199002)(24454002)(46102001)(16236675002)(81342001)(76482001)(33656001)(4396001)(81542001)(92566001)(86362001)(85852003)(83072002)(87936001)(92726001)(101416001)(83716003)(74662001)(2656002)(575784001)(21056001)(77982001)(79102001)(19580395003)(20776003)(83322001)(82746002)(66066001)(80022001)(50986999)(36756003)(54356999)(15975445006)(74502001)(76176999)(99396002)(31966008)(19580405001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_7BAE88303CD74BD5B1E76A09FE34F402adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/tPofCYD1NMdj0Y7Q3YSYhwIMgXA Cc: "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:25:21 -0000 --_000_7BAE88303CD74BD5B1E76A09FE34F402adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, as of this moment, they're on DOUBLE SECRET PROBATION! On May 6, 2014, at 11:34 AM, Antonio Sanso > wrote: Hi Brian, I will give a try and let you know regards antonio On May 6, 2014, at 5:40 AM, Brian Campbell > wrote: The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key encry= ption but, AFAIK, there are no examples using it. I recently added support = for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind = of confirmation that I've done it correctly (other than self interop). With= that in mind, here is a JWE using RSA-OAEP-256 which I've produced and I'm= hopeful that someone on this WG list will be able to decrypt. The RSA key = that was used (in JWK format with both public and private parts) is below t= he JWE. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj= 1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3Zz= JWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsuc= rzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQE= dRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-E= uU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQw= YpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ct= CKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0= DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_7BAE88303CD74BD5B1E76A09FE34F402adobecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <79C3B6326AD4D342B9BA0C616AFB0B0A@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Well, as = of this moment, they're on DOUBLE SECRET PROBATION!

On May 6, 2014, at 11:34 AM, Antonio Sanso <asanso@adobe.com> wrote:

Hi Brian,

I will give a try and let you know

regards

antonio

On May 6, 2014, at 5:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

The latest revision of JWA added a new 'RSA-OAEP-256' JWE = alg for key encryption but, AFAIK, there are no examples using it. I recent= ly added support for it to https://bitbucket.org/b_c/jose= 4j and am looking to get some kind of confirmation that I've done it co= rrectly (other than self interop). With that in mind, here is a JWE using R= SA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to decrypt. The RSA = key that was used (in JWK format with both public and private parts) is bel= ow the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKV= mCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM",&q= uot;dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ= -u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2= zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGt= WZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJ= EIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-= L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG= 5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P= _Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose


--_000_7BAE88303CD74BD5B1E76A09FE34F402adobecom_-- From nobody Tue May 6 06:30:16 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447F91A02A3 for ; Tue, 6 May 2014 06:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYrHcLKiOeEF for ; Tue, 6 May 2014 06:30:12 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2742D1A00ED for ; Tue, 6 May 2014 06:30:09 -0700 (PDT) Received: from mail-ie0-f181.google.com ([209.85.223.181]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKU2jj2I237CnPd6nUWd4bHV92baR4Fc4J@postini.com; Tue, 06 May 2014 06:30:06 PDT Received: by mail-ie0-f181.google.com with SMTP id y20so9734031ier.40 for ; Tue, 06 May 2014 06:29:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tyWEqsoCS16PyNai7qM8is2xV0aR2m1ly0oI0pEwlB0=; b=gO6nHzSiluiqY6g4QBXePtytFIiWKD6a+HE3lxnnqdQiOxdmDXstsvkGQHDWOsp+Cy 748WYH9Ha51A3L6uLM2wypfTr2nCsWH6LrFKvi0yxBxrNghArPl2NGkcXX29T1mVaUuY 2OSNKgiSYVi0bP5UUwc5tcqSfF0zR20YVYGs+ArQ1nerZlH+0vjpeSGoybdjXfEl+jar /yozk50sUjEXSvuBLi/ApEX1cxCqBf9+ecTvExtzqx4QkwgM8ibE/6Gj2MxEKaz8L+8Q Az4vZrKaFOaRaxdUUbvmirCu1YOUcTjVRPHsMGvUq3wGk6rXDKa03YsX27TTBYlNCcy5 TvgA== X-Gm-Message-State: ALoCoQlS1hAFhgaencqi4Jp8trh5jQIt2opXo3SkgaBWckAg0RRUWNRu/xKw2VTYQ4bly5ZAdAeXWy8sUrOTjivTgd/P5mU3typXkOFL3n5qPL/UOmYbhS8ob+tj51zr0TgfCjxMf800 X-Received: by 10.51.17.5 with SMTP id ga5mr32470760igd.2.1399382999705; Tue, 06 May 2014 06:29:59 -0700 (PDT) X-Received: by 10.51.17.5 with SMTP id ga5mr32470746igd.2.1399382999565; Tue, 06 May 2014 06:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Tue, 6 May 2014 06:29:28 -0700 (PDT) In-Reply-To: <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> From: Brian Campbell Date: Tue, 6 May 2014 06:29:28 -0700 Message-ID: To: Antonio Sanso Content-Type: multipart/alternative; boundary=001a1135e1da98206004f8bb3e79 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/JZ4GSjq5g9sg7r0dsIka54lIlGw Cc: "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:30:14 -0000 --001a1135e1da98206004f8bb3e79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From the venerable film Animal House, of course, https://www.youtube.com/watch?v=3DvVXEQ8hjyGI Thanks for checking that Antonio. Hopefully we could get a non Java based implementing to verify it too. On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso wrote: > Well, as of this moment, they're on DOUBLE SECRET PROBATION! > > On May 6, 2014, at 11:34 AM, Antonio Sanso wrote: > > Hi Brian, > > I will give a try and let you know > > regards > > antonio > > On May 6, 2014, at 5:40 AM, Brian Campbell > wrote: > > The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key > encryption but, AFAIK, there are no examples using it. I recently added > support for it to https://bitbucket.org/b_c/jose4j and am looking to get > some kind of confirmation that I've done it correctly (other than self > interop). With that in mind, here is a JWE using RSA-OAEP-256 which I've > produced and I'm hopeful that someone on this WG list will be able to > decrypt. The RSA key that was used (in JWK format with both public and > private parts) is below the JWE. > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtH= OcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyj= l9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-= YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf= 0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W25= 1nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP= 5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCG= nhWT9qyuUSSA > > > {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMC= KZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3B= XzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9= bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqA= kSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB",= "d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nL= MnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikr= AHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKX= YKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6o= Bk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChL= gKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS8= 2EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U= ","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXC= VFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhP= kj1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3= ZzJWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXs= ucrzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZv= QEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh= -EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0Y= QwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1= ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CA= O0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --001a1135e1da98206004f8bb3e79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the venerable film Animal House, of course,= https://www.yout= ube.com/watch?v=3DvVXEQ8hjyGI

Thanks for checking that An= tonio.

Hopefully we could get a non Java based implementing to verify it= too.




On Tue, May 6, 2014 at 6:25 AM, = Antonio Sanso <asanso@adobe.com> wrote:
Well, as of thi= s moment, they're on DOUBLE SECRET PROBATION!

On May 6, 2014, at 11:34 AM, Antonio Sanso <asanso@adobe.com> wrote:

Hi Brian,

I will give a try and let you know

regards

antonio

On May 6, 2014, at 5:40 AM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

The latest revision of JWA added a new 'RSA-OAEP-256&#= 39; JWE alg for key encryption but, AFAIK, there are no examples using it. = I recently added support for it to https://bitb= ucket.org/b_c/jose4j and am looking to get some kind of confirmation th= at I've done it correctly (other than self interop). With that in mind,= here is a JWE using RSA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to decrypt. The = RSA key that was used (in JWK format with both public and private parts) is= below the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKV= mCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM",&q= uot;dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ= -u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2= zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGt= WZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJ= EIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-= L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG= 5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P= _Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose





--
--001a1135e1da98206004f8bb3e79-- From nobody Tue May 6 06:33:08 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3D1A048E for ; Tue, 6 May 2014 06:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.155 X-Spam-Level: * X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmqdKPfPHAUF for ; Tue, 6 May 2014 06:33:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 71FDB1A043B for ; Tue, 6 May 2014 06:33:01 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 13:32:55 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0934.000; Tue, 6 May 2014 13:32:54 +0000 From: Antonio Sanso To: Brian Campbell Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUAgABAhACAAAElAIAAAQQA Date: Tue, 6 May 2014 13:32:54 +0000 Message-ID: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.147.117.11] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(189002)(199002)(52604005)(24454002)(377454003)(101416001)(92566001)(76482001)(18206015023)(92726001)(76176999)(54356999)(4396001)(99396002)(575784001)(86362001)(19617315010)(21056001)(77982001)(87936001)(19618635001)(15198665003)(81542001)(50986999)(83072002)(81342001)(82746002)(36756003)(46102001)(85852003)(2656002)(15975445006)(31966008)(83322001)(19273905006)(19580405001)(19580395003)(74662001)(74502001)(16236675002)(15395725003)(80022001)(66066001)(83716003)(64706001)(15202345003)(79102001)(20776003)(33656001)(9984715005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_C2972F75E43C4E79A248860CFA1F9E6Aadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/7scFclXvPOhTCcRPHxNsu2EBff8 Cc: "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:33:04 -0000 --_000_C2972F75E43C4E79A248860CFA1F9E6Aadobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi Brian, On May 6, 2014, at 3:29 PM, Brian Campbell > wrote: >From the venerable film Animal House, of course, https://www.youtube.com/wa= tch?v=3DvVXEQ8hjyGI Thanks for checking that Antonio. Hopefully we could get a non Java based implementing to verify it too. just for completeness I did *not* use jose4j to verify it=85 (just to be sa= fe) regards antonio On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso > wrote: Well, as of this moment, they're on DOUBLE SECRET PROBATION! On May 6, 2014, at 11:34 AM, Antonio Sanso > wrote: Hi Brian, I will give a try and let you know regards antonio On May 6, 2014, at 5:40 AM, Brian Campbell > wrote: The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key encry= ption but, AFAIK, there are no examples using it. I recently added support = for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind = of confirmation that I've done it correctly (other than self interop). With= that in mind, here is a JWE using RSA-OAEP-256 which I've produced and I'm= hopeful that someone on this WG list will be able to decrypt. The RSA key = that was used (in JWK format with both public and private parts) is below t= he JWE. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj= 1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3Zz= JWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsuc= rzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQE= dRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-E= uU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQw= YpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ct= CKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0= DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- [Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us=85 [twitter logo] [youtube logo] [LinkedIn logo] [Facebook logo] [Google+ logo] [s= lideshare logo] [flipboard logo] = [rss feed icon] [Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19= =9623 July, 2014 | Monterey, CA] --_000_C2972F75E43C4E79A248860CFA1F9E6Aadobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <27F63BCAD34FAC41940D6094FD1C005C@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi Brian,


On May 6, 2014, at 3:29 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

From the venerable film Animal House, of course, https://www.youtube.com/watch?v=3DvVXEQ8hjyGI

Thanks for checking that Antonio.

Hopefully we could get a non Java based implementing to verify it too.

just for completeness I did *not* use jose4j to verify it=85 (just to = be safe)

regards

antonio





On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <asanso@adobe.com<= /a>> wrote:
Well, as of thi= s moment, they're on DOUBLE SECRET PROBATION!


Hi Brian,

I will give a try and let you know

regards

antonio

On May 6, 2014, at 5:40 AM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

The latest revision of JWA added a new 'RSA-OAEP-256' JWE = alg for key encryption but, AFAIK, there are no examples using it. I recent= ly added support for it to https://bitb= ucket.org/b_c/jose4j and am looking to get some kind of confirmation th= at I've done it correctly (other than self interop). With that in mind, her= e is a JWE using RSA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to= decrypt. The RSA key that was used (in JWK format with both public and pri= vate parts) is below the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKV= mCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM",&q= uot;dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ= -u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2= zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGt= WZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJ= EIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-= L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG= 5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P= _Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose





--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061<= /font>
Connect with us=85
3D"= 3D"youtube<= /a> 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register


--_000_C2972F75E43C4E79A248860CFA1F9E6Aadobecom_-- From nobody Tue May 6 07:01:05 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661681A0322 for ; Tue, 6 May 2014 07:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXawwSRizcfD for ; Tue, 6 May 2014 07:01:02 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 25FD11A02EA for ; Tue, 6 May 2014 07:01:02 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKU2jrGtFdevD1ylscfombQ9F6cwWxCdzm@postini.com; Tue, 06 May 2014 07:00:58 PDT Received: by mail-ig0-f176.google.com with SMTP id hl10so6249519igb.9 for ; Tue, 06 May 2014 07:00:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uOfg38qnzc2F6lJ04RMgb/8RYcrjq7pbdMYHZxIRB0I=; b=Ytw5fYjoYPPslRvGWeEG3m+L8fTkIjxQAM3Uh+PrqCmY3lKKMG3jTv6BCHEA7hMB27 njq5nE+W6PQfTW0MYWFWh/2dZ2rythxYolZ8dVTdvDe0QHkf4xfsyPvNBR8Dlhxj+lYV p900i5Rbwg3mf2mETpAHalhSIUBCtBPAHgQWGp73N2zw7DXRPHELaJj7PH1GA1l39P56 wao7T0S1yknjGMmwPLkUdntU8kIZPriLqUrPPHsqF3VWqHGnEkt3gHj/R4hEoq3w77Ie tKwm5+81RROOuD8rWK4YgFc+bs3cgqx4RVADO5+WUmk22Lv1XoqLfVIfL7iRPlcjPFyr STsw== X-Gm-Message-State: ALoCoQnF2NKu2uCi58qAeEMT88juCegfqetaLQ6KtzUkXQaZaw/IfRS0rd1eXt4taiL5eQ8tWVTT599QlOhrUxSGcBHQYi/a8pB+11COSKDWDPN8jsrkSXrzquc0W7kMlhQ8Ys+GMb62 X-Received: by 10.50.153.49 with SMTP id vd17mr32947557igb.40.1399384858076; Tue, 06 May 2014 07:00:58 -0700 (PDT) X-Received: by 10.50.153.49 with SMTP id vd17mr32947514igb.40.1399384857868; Tue, 06 May 2014 07:00:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Tue, 6 May 2014 07:00:27 -0700 (PDT) In-Reply-To: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> From: Brian Campbell Date: Tue, 6 May 2014 07:00:27 -0700 Message-ID: To: Antonio Sanso Content-Type: multipart/alternative; boundary=089e014954be5bde5c04f8bbad40 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/AAP9RyCra_tmcxBfCSht2lx0t8M Cc: "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:01:04 -0000 --089e014954be5bde5c04f8bbad40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But you probable did do something very similar to what I did in jose4j - i.e. just getting a cipher instance with "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"? I think that's the right thing to do (and JWA even implies it) but a check from a different language/platform would help verify that assumption. I don't know if maybe more specifics need to be provided to the cipher via OAEPParameterSpec or something - the JCA APIs can be a bit mysterious at times. On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso wrote: > hi Brian, > > > On May 6, 2014, at 3:29 PM, Brian Campbell > wrote: > > From the venerable film Animal House, of course, > https://www.youtube.com/watch?v=3DvVXEQ8hjyGI > > Thanks for checking that Antonio. > > Hopefully we could get a non Java based implementing to verify it too. > > > just for completeness I did *not* use jose4j to verify it=E2=80=A6 (just= to be > safe) > > regards > > antonio > > > > > > On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso wrote: > >> Well, as of this moment, they're on DOUBLE SECRET PROBATION! >> >> On May 6, 2014, at 11:34 AM, Antonio Sanso wrote: >> >> Hi Brian, >> >> I will give a try and let you know >> >> regards >> >> antonio >> >> On May 6, 2014, at 5:40 AM, Brian Campbell >> wrote: >> >> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key >> encryption but, AFAIK, there are no examples using it. I recently added >> support for it to https://bitbucket.org/b_c/jose4j and am looking to get >> some kind of confirmation that I've done it correctly (other than self >> interop). With that in mind, here is a JWE using RSA-OAEP-256 which I've >> produced and I'm hopeful that someone on this WG list will be able to >> decrypt. The RSA key that was used (in JWK format with both public and >> private parts) is below the JWE. >> >> >> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2Hjt= HOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36tey= jl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o= -YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRK= f0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W2= 51nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJ= P5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeC= GnhWT9qyuUSSA >> >> >> {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tM= CKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3= BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII= 9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLq= AkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB"= ,"d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-n= LMnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ik= rAHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmK= XYKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6= oBk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhCh= LgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS= 82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5= U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurX= CVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3Oh= Pkj1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_= 3ZzJWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOX= sucrzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZ= vQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEI= h-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0= YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc= 1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6C= AO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect > with us=E2=80=A6 [image: twitter logo] [image: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --089e014954be5bde5c04f8bbad40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But you probable did do something very similar to wha= t I did in jose4j - i.e. just getting a cipher instance with "RSA/ECB/= OAEPWithSHA-256AndMGF1Padding"?

I think that's the ri= ght thing to do (and JWA even implies it) but a check from a different lang= uage/platform would help verify that assumption. I don't know if maybe = more specifics need to be provided to the cipher via OAEPParameterSpec or s= omething - the JCA APIs can be a bit mysterious at times.


On Tue,= May 6, 2014 at 6:32 AM, Antonio Sanso <asanso@adobe.com> wro= te:
hi Brian,


On May 6, 2014, at 3:29 PM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

From the venerable film Animal House, of course, https://www.youtube.com/watch?v=3DvVXEQ8hjyGI

Thanks for checking that Antonio.

Hopefully we could get a non Java based implementing to verify it too.

just for completeness I did *not* use jose4j to verify it=E2=80= =A6 (just to be safe)

regards

antonio





On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <asanso@adobe.com<= /a>> wrote:
Well, as of thi= s moment, they're on DOUBLE SECRET PROBATION!


Hi Brian,

I will give a try and let you know

regards

antonio

On May 6, 2014, at 5:40 AM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

The latest revision of JWA added a new 'RSA-OAEP-256&#= 39; JWE alg for key encryption but, AFAIK, there are no examples using it. = I recently added support for it to https://bitb= ucket.org/b_c/jose4j and am looking to get some kind of confirmation th= at I've done it correctly (other than self interop). With that in mind,= here is a JWE using RSA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be= able to decrypt. The RSA key that was used (in JWK format with both public= and private parts) is below the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKV= mCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM",&q= uot;dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ= -u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2= zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGt= WZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJ= EIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-= L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG= 5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P= _Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose





--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"= 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register



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




--
--089e014954be5bde5c04f8bbad40-- From nobody Tue May 6 07:14:59 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9921E1A058E for ; Tue, 6 May 2014 07:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_ADOBE2=2.455, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ESo5ctEVy_t for ; Tue, 6 May 2014 07:14:56 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B72651A032F for ; Tue, 6 May 2014 07:14:55 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so2526252wes.4 for ; Tue, 06 May 2014 07:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=J6VBdvIJ3u/Y/bMl2ghOYlDWwjj92oZAT2lW0szkk3A=; b=RK8Q/OTjosIkhVhmErUUp7aXpcamP/1hKOIDt7s7P0Po2AMjD7TAuWA+0RRQD95m8n +PaOzbn1PK/GnXzh9s+/nmnb7di9pajB4IJzWW8MXw1JzOTbDOMaYoVKzdik58KE2qJt Cq0dKTWxvBwsTWhWKj6JeXEBrYA087fb6H245ErlTwWFpiZZ81irFHbLdPK0quAdnNI5 clc2FKTNlWz+cn8ERKo5Y9d4gLKBm+f5vgSORbhaNpzP4+bZEB5sow0vDqz9cH+hwVM/ rnvUC8qeQibk4fl+M+l8whmWpGO8hWstPVuBsip697veIkeGFir2F5YN+uTF+xXm/dWw w3Uw== X-Received: by 10.194.89.40 with SMTP id bl8mr837098wjb.90.1399385691509; Tue, 06 May 2014 07:14:51 -0700 (PDT) Received: from [192.168.1.99] (48.248.130.77.rev.sfr.net. [77.130.248.48]) by mx.google.com with ESMTPSA id q9sm22247677wjo.3.2014.05.06.07.14.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 07:14:50 -0700 (PDT) Message-ID: <5368EE57.8060008@gmail.com> Date: Tue, 06 May 2014 16:14:47 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Campbell , Antonio Sanso References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/jose/XMWEdYJNwasKo57u54aRIDjMXrw Cc: "jose@ietf.org" Subject: [jose] BouncyCastle? Re: RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:14:57 -0000 https://bugs.openjdk.java.net/browse/JDK-7038158 Anders On 2014-05-06 16:00, Brian Campbell wrote: > But you probable did do something very similar to what I did in jose4j - i.e. just getting a cipher instance with "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"? > > I think that's the right thing to do (and JWA even implies it) but a check from a different language/platform would help verify that assumption. I don't know if maybe more specifics need to be provided to the cipher via OAEPParameterSpec or something - the JCA APIs can be a bit mysterious at times. > > > On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso > wrote: > > hi Brian, > > > On May 6, 2014, at 3:29 PM, Brian Campbell > wrote: > >> From the venerable film Animal House, of course, https://www.youtube.com/watch?v=vVXEQ8hjyGI >> >> Thanks for checking that Antonio. >> >> Hopefully we could get a non Java based implementing to verify it too. > > just for completeness I did *not* use jose4j to verify it… (just to be safe) > > regards > > antonio > >> >> >> >> >> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso > wrote: >> >> Well, as of this moment, they're on DOUBLE SECRET PROBATION! >> >> On May 6, 2014, at 11:34 AM, Antonio Sanso > wrote: >> >>> Hi Brian, >>> >>> I will give a try and let you know >>> >>> regards >>> >>> antonio >>> >>> On May 6, 2014, at 5:40 AM, Brian Campbell > wrote: >>> >>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key encryption but, AFAIK, there are no examples using it. I recently added support for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind of confirmation that I've done it correctly (other than self interop). With that in mind, here is a JWE using RSA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to decrypt. The RSA key that was used (in JWK format with both public and private parts) is below the JWE. >>>> >>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnhWT9qyuUSSA >>>> >>>> {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30G epLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>> >> >> >> >> >> -- >> Ping Identity logo >> Brian Campbell >> Portfolio Architect >> @ bcampbell@pingidentity.com >> phone +1 720.317.2061 >> Connect with us… >> twitter logo youtube logo LinkedIn logo Facebook logo Google+ logo slideshare logo flipboard logo rss feed icon >> >> Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA >> >> > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > -- > Ping Identity logo > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com > phone +1 720.317.2061 > Connect with us… > twitter logo youtube logo LinkedIn logo Facebook logo Google+ logo slideshare logo flipboard logo rss feed icon > > Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Tue May 6 07:21:50 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611CC1A0651 for ; Tue, 6 May 2014 07:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NhxjvUy7xTn for ; Tue, 6 May 2014 07:21:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 91DF91A0347 for ; Tue, 6 May 2014 07:21:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A2AB61F02AE; Tue, 6 May 2014 10:21:40 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 854611F02A7; Tue, 6 May 2014 10:21:40 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 6 May 2014 10:21:39 -0400 From: "Richer, Justin P." To: Brian Campbell Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUAgABAhACAAEQzAIAAAPYAgAAHsoCAAAXtgA== Date: Tue, 6 May 2014 14:21:38 +0000 Message-ID: <7270EE89-048D-4BF1-9B3F-48C902B097FE@mitre.org> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.50.80] Content-Type: multipart/alternative; boundary="_000_7270EE89048D4BF19B3F48C902B097FEmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/IGyyz6aJtrTKmqsSNU7M3IZ84Ss Cc: Antonio Sanso , "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:21:48 -0000 --_000_7270EE89048D4BF19B3F48C902B097FEmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable For what it's worth, this morning I copied Brian's homework and implemented= the RSA-OAEP-256 algorithm in Nimbus-JOSE-JWT (on Java / BouncyCastle) usi= ng the Cipher instance he mentions below. I was able to do the decryption a= nd get out the same clear text as Antonio. So if we're wrong, we're all at least wrong in the exact same way. -- Justin On May 6, 2014, at 10:00 AM, Brian Campbell > wrote: But you probable did do something very similar to what I did in jose4j - i.= e. just getting a cipher instance with "RSA/ECB/OAEPWithSHA-256AndMGF1Paddi= ng"? I think that's the right thing to do (and JWA even implies it) but a check = from a different language/platform would help verify that assumption. I don= 't know if maybe more specifics need to be provided to the cipher via OAEPP= arameterSpec or something - the JCA APIs can be a bit mysterious at times. On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso > wrote: hi Brian, On May 6, 2014, at 3:29 PM, Brian Campbell > wrote: >From the venerable film Animal House, of course, https://www.youtube.com/wa= tch?v=3DvVXEQ8hjyGI Thanks for checking that Antonio. Hopefully we could get a non Java based implementing to verify it too. just for completeness I did *not* use jose4j to verify it=85 (just to be sa= fe) regards antonio On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso > wrote: Well, as of this moment, they're on DOUBLE SECRET PROBATION! On May 6, 2014, at 11:34 AM, Antonio Sanso > wrote: Hi Brian, I will give a try and let you know regards antonio On May 6, 2014, at 5:40 AM, Brian Campbell > wrote: The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key encry= ption but, AFAIK, there are no examples using it. I recently added support = for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind = of confirmation that I've done it correctly (other than self interop). With= that in mind, here is a JWE using RSA-OAEP-256 which I've produced and I'm= hopeful that someone on this WG list will be able to decrypt. The RSA key = that was used (in JWK format with both public and private parts) is below t= he JWE. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj= 1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3Zz= JWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsuc= rzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQE= dRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-E= uU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQw= YpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ct= CKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0= DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"} _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- [Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us=85 [twitter logo] [youtube logo] [LinkedIn logo] [Facebook logo] [Google+ logo] [s= lideshare logo] [flipboard logo] = [rss feed icon] [Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19= =9623 July, 2014 | Monterey, CA] _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- [Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us=85 [twitter logo] [youtube logo] [LinkedIn logo] [Facebook logo] [Google+ logo] [s= lideshare logo] [flipboard logo] = [rss feed icon] [Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19= =9623 July, 2014 | Monterey, CA] _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_7270EE89048D4BF19B3F48C902B097FEmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2BD7FBF5DE5A9F40AF2D0267B529D41D@imc.mitre.org> Content-Transfer-Encoding: quoted-printable For what it's worth, this morning I copied Brian's homework and implemented= the RSA-OAEP-256 algorithm in Nimbus-JOSE-JWT (on Java / BouncyCastle) usi= ng the Cipher instance he mentions below. I was able to do the decryption a= nd get out the same clear text as Antonio.

So if we're wrong, we're all at least wrong in the exact same way.

 -- Justin

On May 6, 2014, at 10:00 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

But you probable did do something very similar to what I did in jose4j= - i.e. just getting a cipher instance with "RSA/ECB/OAEPWithSHA-256An= dMGF1Padding"?

I think that's the right thing to do (and JWA even implies it) but a check = from a different language/platform would help verify that assumption. I don= 't know if maybe more specifics need to be provided to the cipher via OAEPP= arameterSpec or something - the JCA APIs can be a bit mysterious at times.


On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <asanso@adobe.com<= /a>> wrote:
hi Brian,



From the venerable film Animal House, of course, https://www.youtube.com/watch?v=3DvVXEQ8hjyGI

Thanks for checking that Antonio.

Hopefully we could get a non Java based implementing to verify it too.

just for completeness I did *not* use jose4j to verify it=85 (just to = be safe)

regards

antonio





On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <asanso@adobe.com<= /a>> wrote:
Well, as of thi= s moment, they're on DOUBLE SECRET PROBATION!


Hi Brian,

I will give a try and let you know

regards

antonio

On May 6, 2014, at 5:40 AM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

The latest revision of JWA added a new 'RSA-OAEP-256' JWE = alg for key encryption but, AFAIK, there are no examples using it. I recent= ly added support for it to https://bitb= ucket.org/b_c/jose4j and am looking to get some kind of confirmation th= at I've done it correctly (other than self interop). With that in mind, her= e is a JWE using RSA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to= decrypt. The RSA key that was used (in JWK format with both public and pri= vate parts) is below the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOc= XduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9= oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ= 520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0N= DikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251n= TviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5d= BgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnh= WT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKV= mCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM",&q= uot;dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ= -u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2= zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGt= WZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJ= EIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-= L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG= 5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P= _Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose





--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061
Connect with us=85
3D"= 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register



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




--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061<= /font>
Connect with us=85
3D"= 3D"youtube<= /a> 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register

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

--_000_7270EE89048D4BF19B3F48C902B097FEmitreorg_-- From nobody Tue May 6 10:12:06 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F381A03A4; Mon, 5 May 2014 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7PnJac7umrx; Mon, 5 May 2014 10:08:24 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8931A038B; Mon, 5 May 2014 10:08:24 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm4so5939242wib.17 for ; Mon, 05 May 2014 10:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=s9Bmno+YbQdzsrCL5+ZH6Tz5B90U1VSs6iN0VqNzxfc=; b=PN4/tLloiqx/0CefwdPfri4ZvcjuLkCSODd2Fj0JjYs0zKDVeUIz+r7Y+hJWU7Z5km JLztG7qjVtMtrpkIh+/cXlsN8uzyzyhp9PSyJuU7s/msQ8/sGlnvbvgaYUt429k72rgd 2VTGWRtdQOcsnF8zFan38VYJTAACr08xjOTJ0qb6rZQpXUwJ7JmrNKFb+51T3QAQmzMf uOchTGO/ygrHeZE7/r6suVrXRofEK1OUrsIzmCSgHKE8kRtXZ/yFa9jXPm79wdiPPKz3 FJQWNftdwsB9wMMM6s374FO0qg5nehcwqloHUTTB8kQgPN9lsdTS2BeQPPuS9jghNV+n p1WA== X-Received: by 10.194.203.2 with SMTP id km2mr2709870wjc.72.1399309700213; Mon, 05 May 2014 10:08:20 -0700 (PDT) Received: from [192.168.2.7] ([89.100.139.33]) by mx.google.com with ESMTPSA id n5sm18976240wiz.1.2014.05.05.10.08.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 10:08:19 -0700 (PDT) Message-ID: <5367C582.3010705@gmail.com> Date: Mon, 05 May 2014 18:08:18 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian Campbell , "jose@ietf.org" References: <5363C88E.5070209@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/jose/joeIB5_R0F7uuqLlAD3BcgB67wg X-Mailman-Approved-At: Tue, 06 May 2014 10:12:05 -0700 Cc: "" Subject: Re: [jose] [OAUTH-WG] [OT] Validation of JWE spec Appendix 1 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:08:27 -0000 Hi Brian On 03/05/14 14:36, Brian Campbell wrote: > Hi Sergey, > > This question might be more appropriate for the JOSE WG [0] list (which > I've cc'd) as JWE is being developed there. > Sure, I'll be asking at [0] next time... > Some of the algorithms, RSAES OAEP being one of them, are probabilistic > encryption schemes which incorporate some element of randomness to yield > a different output even when encrypting the same content multiple times. > So the behavior you are observing is to be expected. > I was starting blaming myself for the fact I could not get the code producing a match :-) > That means that exactly reproducing the various steps of the examples in > the specs will not be possible in some cases. I was recently discussing > this off list with Matt Miller, the author of the JOSE Cookbook [1], and > my suggestion was to have the cookbook just make note of which examples, > or which parts of which examples, can't be easily reproduced due to > non-deterministic algorithms. I think that your question here suggests > that that idea might well provide utility to users/readers of that document. > +1 Thanks for the help, Sergey > Hope that helps, > Brian > > > [0] http://tools.ietf.org/wg/jose/ > [1] http://tools.ietf.org/html/draft-ietf-jose-cookbook-02 > > > > > > > On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin > wrote: > > Hi, > > I'm starting experimenting with JWE, and the 1st thing I wanted to > do was to quickly test the example at [1]. > > Sorry if it is something that is very obvious and off-topic, but I > can't seem to validate the encryption of the content encryption key: > I keep getting a different output every time the test code runs. > > The code is the one that I wrote by 'scraping' the code from all > over the Web but also I see Jose.4.j [3] produces a different output > too. > Is it due to the given key properties specified in [1] or it is > actually indeed expected that production at [2] is reproducible ? > > Cheers, Sergey > > [1] > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1 > > [2] > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1.3 > > [3] https://bitbucket.org/b_c/__jose4j/wiki/Home > > > _________________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/__listinfo/oauth > > > > > > -- > Ping Identity logo > Brian Campbell > [Enter Title] > @ bcampbell@pingidentity.com > phone +1 720.317.2061 > Connect with us… > twitter logo youtube logo > LinkedIn logo > Facebook logo > Google+ logo > slideshare logo > flipboard logo > rss feed icon > > Register for Cloud Identity Summit 2014 | Modern Identity Revolution | > 19–23 July, 2014 | Monterey, CA > > From nobody Tue May 6 12:32:10 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4281A03E0 for ; Tue, 6 May 2014 12:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Mcm0dkdwNe4 for ; Tue, 6 May 2014 12:32:05 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8707E1A03B5 for ; Tue, 6 May 2014 12:32:04 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 06 May 2014 21:31:59 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Tue, 6 May 2014 21:31:58 +0200 From: To: , Date: Tue, 6 May 2014 21:31:53 +0200 Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: Ac9pM55u+KswQ9wOQJ6mdd8wBDasfwALHRzA Message-ID: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/related; boundary="_004_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/TbD7LfvL4w4nfy447o3YUWw8rgc Cc: jose@ietf.org Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 19:32:08 -0000 --_004_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_ Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_" --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0yNiNhcHBlbmRpeC1BLjIgc3BlY2lmaWVzIGV4YWN0bHkgdGhlc2Ug cGFyYW1ldGVycy4NCg0KICAgKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQogICB8IEpXRSAgIHwgWE1MIEVOQyAgICAg ICAgICAgICAgICB8IEpDQSAgICAgICAgICAgICAgICB8IE9JRCAgICAgICAgIHwNCiAgICstLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tKw0KICAgfCBSU0ExXyB8IGh0dHA6Ly93d3cudzMub3JnLzIwMDEgfCBSU0EvRUNCL1BL Q1MxUGFkZGkgfCAxLjIuODQwLjExMyB8DQogICB8IDUgICAgIHwgLzA0L3htbGVuYyNyc2EtMV81 ICAgICB8IG5nICAgICAgICAgICAgICAgICB8IDU0OS4xLjEuMSAgIHwNCiAgIHwgUlNBLU8gfCBo dHRwOi8vd3d3LnczLm9yZy8yMDAxIHwgUlNBL0VDQi9PQUVQV2l0aFNIIHwgMS4yLjg0MC4xMTMg fA0KICAgfCBBRVAgICB8IC8wNC94bWxlbmMjcnNhLW9hZXAtbWcgfCBBLTFBbmRNR0YxUGFkZGlu ZyAgfCA1NDkuMS4xLjcgICB8DQogICB8ICAgICAgIHwgZjFwICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwNCiAgIHwgUlNBLU8gfCBodHRwOi8v d3d3LnczLm9yZy8yMDA5IHwgUlNBL0VDQi9PQUVQV2l0aFNIIHwgMS4yLjg0MC4xMTMgfA0KICAg fCBBRVAtMiB8IC94bWxlbmMxMSNyc2Etb2FlcCAgICAgfCBBLTI1NkFuZE1HRjFQYWRkaW4gfCA1 NDkuMS4xLjcgICB8DQogICB8IDU2ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8IGcgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwNCg0KQ2hlZXJzDQpBeGVsDQoNClRoZSBjb2Rl IGhlcmUNCmh0dHBzOi8vY29kZS5nb29nbGUuY29tL3AvanNvbmNyeXB0by9zb3VyY2UvYnJvd3Nl L3RydW5rL3NyYy9vcmcvanNvbmNyeXB0by9jcnlwdG8vQ3J5cHRvVXRpbHMuamF2YSM0MTANCmlz IHRoZSBjb2RlIHRoYXQgQ2h1Y2sgYW5kIEkgdXNlZCBzaW5jZSB0aGUgSW5mb3JtYXRpb25DYXJk IGRheXMgYW5kIHRoYXQgd29ya2VkIHRvIHZlcmlmeSB0aGUgZXhhbXBsZXMgZnJvbSB0aGUgYmVn aW5uaW5nIG9mIEpPU0UuDQpUaGUgcGFyYW1ldGVycyBhcmUgdGhlIEJvdW5jeWNhc3RlbCBkZWZh dWx0IHBhcmFtZXRlcnMgKFNIQS0xKQ0KDQoNCkZyb206IGpvc2UgW21haWx0bzpqb3NlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogVHVlc2RheSwg TWF5IDA2LCAyMDE0IDQ6MDAgUE0NClRvOiBBbnRvbmlvIFNhbnNvDQpDYzogam9zZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtqb3NlXSBSU0EtT0FFUC0yNTYgRXhhbXBsZQ0KDQpCdXQgeW91IHBy b2JhYmxlIGRpZCBkbyBzb21ldGhpbmcgdmVyeSBzaW1pbGFyIHRvIHdoYXQgSSBkaWQgaW4gam9z ZTRqIC0gaS5lLiBqdXN0IGdldHRpbmcgYSBjaXBoZXIgaW5zdGFuY2Ugd2l0aCAiUlNBL0VDQi9P QUVQV2l0aFNIQS0yNTZBbmRNR0YxUGFkZGluZyI/DQpJIHRoaW5rIHRoYXQncyB0aGUgcmlnaHQg dGhpbmcgdG8gZG8gKGFuZCBKV0EgZXZlbiBpbXBsaWVzIGl0KSBidXQgYSBjaGVjayBmcm9tIGEg ZGlmZmVyZW50IGxhbmd1YWdlL3BsYXRmb3JtIHdvdWxkIGhlbHAgdmVyaWZ5IHRoYXQgYXNzdW1w dGlvbi4gSSBkb24ndCBrbm93IGlmIG1heWJlIG1vcmUgc3BlY2lmaWNzIG5lZWQgdG8gYmUgcHJv dmlkZWQgdG8gdGhlIGNpcGhlciB2aWEgT0FFUFBhcmFtZXRlclNwZWMgb3Igc29tZXRoaW5nIC0g dGhlIEpDQSBBUElzIGNhbiBiZSBhIGJpdCBteXN0ZXJpb3VzIGF0IHRpbWVzLg0KDQpPbiBUdWUs IE1heSA2LCAyMDE0IGF0IDY6MzIgQU0sIEFudG9uaW8gU2Fuc28gPGFzYW5zb0BhZG9iZS5jb208 bWFpbHRvOmFzYW5zb0BhZG9iZS5jb20+PiB3cm90ZToNCmhpIEJyaWFuLA0KDQoNCk9uIE1heSA2 LCAyMDE0LCBhdCAzOjI5IFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQoNCg0KRnJv bSB0aGUgdmVuZXJhYmxlIGZpbG0gQW5pbWFsIEhvdXNlLCBvZiBjb3Vyc2UsIGh0dHBzOi8vd3d3 LnlvdXR1YmUuY29tL3dhdGNoP3Y9dlZYRVE4aGp5R0kNClRoYW5rcyBmb3IgY2hlY2tpbmcgdGhh dCBBbnRvbmlvLg0KSG9wZWZ1bGx5IHdlIGNvdWxkIGdldCBhIG5vbiBKYXZhIGJhc2VkIGltcGxl bWVudGluZyB0byB2ZXJpZnkgaXQgdG9vLg0KDQpqdXN0IGZvciBjb21wbGV0ZW5lc3MgSSBkaWQg Km5vdCogdXNlIGpvc2U0aiB0byB2ZXJpZnkgaXTigKYgKGp1c3QgdG8gYmUgc2FmZSkNCg0KcmVn YXJkcw0KDQphbnRvbmlvDQoNCg0KDQoNCk9uIFR1ZSwgTWF5IDYsIDIwMTQgYXQgNjoyNSBBTSwg QW50b25pbyBTYW5zbyA8YXNhbnNvQGFkb2JlLmNvbTxtYWlsdG86YXNhbnNvQGFkb2JlLmNvbT4+ IHdyb3RlOg0KV2VsbCwgYXMgb2YgdGhpcyBtb21lbnQsIHRoZXkncmUgb24gRE9VQkxFIFNFQ1JF VCBQUk9CQVRJT04hDQoNCk9uIE1heSA2LCAyMDE0LCBhdCAxMTozNCBBTSwgQW50b25pbyBTYW5z byA8YXNhbnNvQGFkb2JlLmNvbTxtYWlsdG86YXNhbnNvQGFkb2JlLmNvbT4+IHdyb3RlOg0KDQoN CkhpIEJyaWFuLA0KDQpJIHdpbGwgZ2l2ZSBhIHRyeSBhbmQgbGV0IHlvdSBrbm93DQoNCnJlZ2Fy ZHMNCg0KYW50b25pbw0KDQpPbiBNYXkgNiwgMjAxNCwgYXQgNTo0MCBBTSwgQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT4+IHdyb3RlOg0KDQoNClRoZSBsYXRlc3QgcmV2aXNpb24gb2YgSldBIGFkZGVkIGEg bmV3ICdSU0EtT0FFUC0yNTYnIEpXRSBhbGcgZm9yIGtleSBlbmNyeXB0aW9uIGJ1dCwgQUZBSUss IHRoZXJlIGFyZSBubyBleGFtcGxlcyB1c2luZyBpdC4gSSByZWNlbnRseSBhZGRlZCBzdXBwb3J0 IGZvciBpdCB0byBodHRwczovL2JpdGJ1Y2tldC5vcmcvYl9jL2pvc2U0aiBhbmQgYW0gbG9va2lu ZyB0byBnZXQgc29tZSBraW5kIG9mIGNvbmZpcm1hdGlvbiB0aGF0IEkndmUgZG9uZSBpdCBjb3Jy ZWN0bHkgKG90aGVyIHRoYW4gc2VsZiBpbnRlcm9wKS4gV2l0aCB0aGF0IGluIG1pbmQsIGhlcmUg aXMgYSBKV0UgdXNpbmcgUlNBLU9BRVAtMjU2IHdoaWNoIEkndmUgcHJvZHVjZWQgYW5kIEknbSBo b3BlZnVsIHRoYXQgc29tZW9uZSBvbiB0aGlzIFdHIGxpc3Qgd2lsbCBiZSBhYmxlIHRvIGRlY3J5 cHQuIFRoZSBSU0Ega2V5IHRoYXQgd2FzIHVzZWQgKGluIEpXSyBmb3JtYXQgd2l0aCBib3RoIHB1 YmxpYyBhbmQgcHJpdmF0ZSBwYXJ0cykgaXMgYmVsb3cgdGhlIEpXRS4NCg0KZXlKaGJHY2lPaUpT VTBFdFQwRkZVQzB5TlRZaUxDSmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAuT3llZzRoYnEy SGp0SE9jWGR1SzlVaGhJWGVydlB6T1RMQXFLcGhDeWVLNTVjRmdLdEYzMkRoRDI2c2ZuRzZoOWF6 M09ncm40UXdZSmVaa2pKSzM2dGV5amw5b0tJV185SXRQOGNZaE9yaURPT1pGaG81M0JzdHRxajhw YzBVUHJNSjQ0OHlRc2drZ3lxbWZXWlFzM3VfcUNhU0xYcGVnRTNvLVlKNTIwLVh1X0VsUzVwTnlf dmZTTUUxQ2VQNXVuUFFQZjA2WGM2aU1WV3g5LUtfN2x4QzdhY1lJX2ZTU1V3dUZ3LXZ4clZKTVJL ZjBORGlrZG1jb0k1V1c3aDVnTFhTdTRFWnZXOHhIeEFfUW9FRm5TZVlnZzhOUU5PR0xmX1BhQmRk QWRuOGNrX21odEpkZ2ZjMFcyNTFuVHZpTUF3UEFqc0cwRk1uUG94N0dkdHpUZG1BLjNESlNDbUdE ZDlXSS1ESTNzQlJtOFEubmNGSTl2VUVkS2t1aFBSMGgzbk9KUDVkQmdLcmNTNWY5UTdaNThBWlRU ZFRWNTNGbHpKSUh3ZG1lLTF4aXB3RGlmVE9MOHlpN2JldUVFaVhnX0NTencuVW1ObHZyZmVDR25o V1Q5cXl1VVNTQQ0KDQp7Imt0eSI6IlJTQSIsIm4iOiIyY1FKSDFmNnlGOURjR2E4Q21ibmhuNExI THM1TDZrTmIycnhrck5GWkFySkxSYUt2YUMzdE1DS1o4WmdJcE85YlZNUHg1VU1qSm9hZjdwOU81 QlNBcFZxQTJKMTBmVWJkU0lvbUNjRHd2R28wZXlodHkwRElMTFdUTVh6R0VWTTNCWHp1SlFvZURr dVVDWFhjQ3dBNE1zeXlkMk9IVnUtcEIyT3JHdjZmY2pId2pJTnR5M1VvS20wOGxDdkFldkJLSHN1 QS1GRndRSUk5YnljdlJ4NXdScUZVamRNQXlpT21MWUJIQmFKU2kxMWczSFZleE1jYjI5djE0UFNs VnpkR1VNTjhvYm9hLXpjSXlhUHJJaWN6THFBa1NYUU5kRUZIcmpzSkhmRmVOTWZPYmxMTTdpY0tO X3R5V3VqWWVJdHQ0a3FVSWltUG41ZEhqd2djUVlFN3ciLCJlIjoiQVFBQiIsImQiOiJkeVV6M0l0 VmNlWDFUdjFXcXRaTW5LQV8wak41Z1dNY0w3YXlmNUpJU0FsQ3NzR2ZuVXJlMkMxMFRIMFVRamJW TUloLW5MTW5ENUtOSnc5UXo1TVIyOG9HRzkzMkdxN2htX19aZUEzNGwtT0NlNERkcGd3aHB2VlNI T1U5TVMxUmRTVXBtUGF2QWNBX1g2aWtyQUhYWlNhb0hoeHpVZ3JOVHB2QllRTWZKVXZfNDkyZlN0 SXNlUTlyd0FNT3BDV09pV01aT1FtM0tKVlRMTHVuWGRLZl9VeG16bUtYWUtZWldrZTNBV0l6VXFu T2ZxSWpmRFRNdW5GNFVXVTB6S2xoY3NhUU5tWU1WckpHYWpEMWJKZHlfZGJVVTNMRThzeC1iZGtV STZvQmstc0Z0VFRWeVZkUWNldEc5a0NoSjVFblk1UjZ0dF80X3hGRzVreHpUbzZxYVEiLCJwIjoi N3lRbWdFNjBTTDdRclhwQUpoQ2hMZ0tuWFdpNkM4dFZ4MWxBOEZUcHBocExhQ3RLLUhiZ0JWSENw ckMyQ2ZhTTFteEZKWmFoeGdGakM5ZWh1VjhPek1OeUZzOGtla1M4MkVzUUdrc2k4SEpQeHlSMWZV NkFUYTM2b2dQRzBuTmFxbTNFRG1ZeWpvd2hudGdCejJPa2JGQXNUTUhUZG5hLXBaQlJKYTlsbTVV IiwicSI6IjZSNGR6bzlMd0hMTzczRU1RUFFzbXdYalZPdkFTNVc2cmdRLUJDdE1oZWNfUW9zQVhJ VkUzQUd5ZndlcVptNnJ1clhDVkZ5a0RMd0ozMEdlcExROG5UbHplVjZjbHgweDcwc2FHR0tLVm1D c0h1VllXd2dJUnlKVHJ0NFNYMjlOUURaX0ZFNTJObE8zT2hQa2oxRXhTa19wR01xR1JGZDI2Szhn MGpKc1hYTSIsImRwIjoiVkJ5bi1oczBxQjJOY21iOFp5Y1VPZ1d1N2xqbWp6MXVwMVpLVV8zWnpK V1ZEa2VqNy02SDd2Y0otdTFPcWdSeEZ2NHY5Xy1hV1BXbDY4VmxXYmtJa0pieDZ2bml2NnFyclh3 Qlp1NGtsT1B3RVlCT1hzdWNyelhSWU9qcEpwNXlObDJ6UnNsRllRUUMwMGJ3cEF4TkNkZk5MUlpE bFhoQXFDVXhsWXF5dDEwIiwiZHEiOiJNSkZidUd0V1p2UUVkUkppY1MzdUZTWTI1THh4UmM0ZUpK OHhwSUM0NHJUNUV3NE90emYwenJsenpNOTJDdjFIdmhDY09pTks4blJDd2tiVG5KRUloLUV1VTcw SWR0dFlTZmlscVNydWsyeDByOE1zazFxckR0YnlCRjYwQ1RvUktDMnljREtnb2xUeXVhRG5YNHlV N2x5VHZkeUQtTDBZUXdZcG1tRnlfazAiLCJxaSI6InZ5N1hDd1ozanlNR2lrODFUSVpEQU9RS0M4 RlZVYzBURzVLVllmdGk0dGd3elVxRnd0dUI4T2MxY3RDS1JiRTd1WlVQd1poNE9zQ1RMcUl2cUJR ZGFfa2F4T3hvNUVGN2lYajZ5SG1aMnM4UF9aX3UzSkx1aC1vQVRfNmttYkx4NkNBTzBEYnRLdHhw MjRJdmMxaERmcVN3V09SZ04xQU9yU1JDbUUzbnd4ZyJ9DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5v cmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2UNCg0KDQoNCg0KDQotLQ0KW2NpZDp+V1JEMDAwLmpwZ108aHR0cHM6Ly93d3cu cGluZ2lkZW50aXR5LmNvbS8+DQoNCkJyaWFuIENhbXBiZWxsDQpQb3J0Zm9saW8gQXJjaGl0ZWN0 DQpADQoNCmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbT4NCg0KW2NpZDp+V1JEMDAwLmpwZ10NCg0KKzEgNzIwLjMxNy4yMDYxPHRlbDol MkIxJTIwNzIwLjMxNy4yMDYxPg0KDQpDb25uZWN0IHdpdGggdXPigKYNCg0KW2NpZDp+V1JEMDAw LmpwZ108aHR0cHM6Ly90d2l0dGVyLmNvbS9waW5naWRlbnRpdHk+W2NpZDp+V1JEMDAwLmpwZ108 aHR0cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9QaW5nSWRlbnRpdHlUVj5bY2lkOn5XUkQwMDAu anBnXTxodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS8yMTg3MD5bY2lkOn5XUkQwMDAu anBnXTxodHRwczovL3d3dy5mYWNlYm9vay5jb20vcGluZ2lkZW50aXR5cGFnZT5bY2lkOn5XUkQw MDAuanBnXTxodHRwczovL3BsdXMuZ29vZ2xlLmNvbS91LzAvMTE0MjY2OTc3NzM5Mzk3NzA4NTQw PltjaWQ6fldSRDAwMC5qcGddPGh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvUGluZ0lkZW50aXR5 PltjaWQ6fldSRDAwMC5qcGddPGh0dHA6Ly9mbGlwLml0L3ZqQkY3PltjaWQ6fldSRDAwMC5qcGdd PGh0dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20vYmxvZ3MvPg0KDQoNCltjaWQ6fldSRDAwMC5q cGddPGh0dHBzOi8vd3d3LmNsb3VkaWRlbnRpdHlzdW1taXQuY29tLz4NCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBs aXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg0KDQotLQ0KW2NpZDp+V1JEMDAwLmpwZ108 aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS8+DQoNCkJyaWFuIENhbXBiZWxsDQpQb3J0Zm9s aW8gQXJjaGl0ZWN0DQpADQoNCmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCg0KW2NpZDp+V1JEMDAwLmpwZ10NCg0KKzEgNzIwLjMx Ny4yMDYxDQoNCkNvbm5lY3Qgd2l0aCB1c+KApg0KDQpbY2lkOn5XUkQwMDAuanBnXTxodHRwczov L3R3aXR0ZXIuY29tL3BpbmdpZGVudGl0eT5bY2lkOn5XUkQwMDAuanBnXTxodHRwczovL3d3dy55 b3V0dWJlLmNvbS91c2VyL1BpbmdJZGVudGl0eVRWPltjaWQ6fldSRDAwMC5qcGddPGh0dHBzOi8v d3d3LmxpbmtlZGluLmNvbS9jb21wYW55LzIxODcwPltjaWQ6fldSRDAwMC5qcGddPGh0dHBzOi8v d3d3LmZhY2Vib29rLmNvbS9waW5naWRlbnRpdHlwYWdlPltjaWQ6fldSRDAwMC5qcGddPGh0dHBz Oi8vcGx1cy5nb29nbGUuY29tL3UvMC8xMTQyNjY5Nzc3MzkzOTc3MDg1NDA+W2NpZDp+V1JEMDAw LmpwZ108aHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9QaW5nSWRlbnRpdHk+W2NpZDp+V1JEMDAw LmpwZ108aHR0cDovL2ZsaXAuaXQvdmpCRjc+W2NpZDp+V1JEMDAwLmpwZ108aHR0cHM6Ly93d3cu cGluZ2lkZW50aXR5LmNvbS9ibG9ncy8+DQoNCg0KW2NpZDp+V1JEMDAwLmpwZ108aHR0cHM6Ly93 d3cuY2xvdWRpZGVudGl0eXN1bW1pdC5jb20vPg0KDQoNCg== --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD11dGYtOCI+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9z b2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPjwhLS1baWYgIW1zb10+PHN0eWxlPnZcOiog e2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVs dCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVo YXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6TW9uYWNvOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUt bmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgYWxsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMjYjYXBwZW5kaXgtQS4yIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0yNiNh cHBlbmRpeC1BLjI8L2E+IHNwZWNpZmllcyBleGFjdGx5IHRoZXNlIHBhcmFtZXRlcnMuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCArLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLSs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgfCBK V0XCoMKgIHwgWE1MIEVOQ8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IEpDQcKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IE9JRMKgwqDCoMKgwqDCoMKgwqAgfDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCArLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgfCBSU0ExXyB8IDxhIGhyZWY9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEiPmh0dHA6Ly93d3cudzMub3JnLzIwMDE8L2E+IHwgUlNB L0VDQi9QS0NTMVBhZGRpIHwgMS4yLjg0MC4xMTMgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+wqDCoCB8IDXCoMKgwqDCoCB8IC8wNC94bWxlbmMjcnNhLTFfNcKgwqDC oMKgIHwgbmfCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IDU0OS4xLjEuMcKgwqAg fDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCB8IFJTQS1PIHwg PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvMjAwMSI+aHR0cDovL3d3dy53My5vcmcvMjAwMTwv YT4gfCBSU0EvRUNCL09BRVBXaXRoU0ggfCAxLjIuODQwLjExMyB8PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgIHwgQUVQwqDCoCB8IC8wNC94bWxlbmMjcnNhLW9h ZXAtbWcgfCBBLTFBbmRNR0YxUGFkZGluZ8KgIHwgNTQ5LjEuMS43wqDCoCB8PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgIHzCoMKgwqDCoMKgwqAgfCBmMXDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgIHwgUlNBLU8gfCA8YSBocmVmPSJodHRw Oi8vd3d3LnczLm9yZy8yMDA5Ij5odHRwOi8vd3d3LnczLm9yZy8yMDA5PC9hPiB8IFJTQS9FQ0Iv T0FFUFdpdGhTSCB8IDEuMi44NDAuMTEzIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPsKgwqAgfCBBRVAtMiB8IC94bWxlbmMxMSNyc2Etb2FlcMKgwqDCoMKgIHwgQS0y NTZBbmRNR0YxUGFkZGluIHwgNTQ5LjEuMS43wqDCoCB8PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz7CoMKgIHwgNTbCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCBnwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNoZWVy czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5BeGVsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgY29kZSBoZXJlIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YSBo cmVmPSJodHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL2pzb25jcnlwdG8vc291cmNlL2Jyb3dzZS90 cnVuay9zcmMvb3JnL2pzb25jcnlwdG8vY3J5cHRvL0NyeXB0b1V0aWxzLmphdmEjNDEwIj5odHRw czovL2NvZGUuZ29vZ2xlLmNvbS9wL2pzb25jcnlwdG8vc291cmNlL2Jyb3dzZS90cnVuay9zcmMv b3JnL2pzb25jcnlwdG8vY3J5cHRvL0NyeXB0b1V0aWxzLmphdmEjNDEwPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5pcyB0 aGUgY29kZSB0aGF0IENodWNrIGFuZCBJIHVzZWQgc2luY2UgdGhlIEluZm9ybWF0aW9uQ2FyZCBk YXlzIGFuZCB0aGF0IHdvcmtlZCB0byB2ZXJpZnkgdGhlIGV4YW1wbGVzIGZyb20gdGhlIGJlZ2lu bmluZyBvZiBKT1NFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgcGFyYW1ldGVycyBhcmUgdGhlIEJvdW5jeWNhc3RlbCBk ZWZhdWx0IHBhcmFtZXRlcnMgKFNIQS0xKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPiBqb3NlIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBC ZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkg MDYsIDIwMTQgNDowMCBQTTxicj48Yj5Ubzo8L2I+IEFudG9uaW8gU2Fuc288YnI+PGI+Q2M6PC9i PiBqb3NlQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIFJTQS1PQUVQLTI1 NiBFeGFtcGxlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+QnV0IHlvdSBwcm9iYWJsZSBkaWQgZG8gc29tZXRoaW5nIHZlcnkgc2lt aWxhciB0byB3aGF0IEkgZGlkIGluIGpvc2U0aiAtIGkuZS4ganVzdCBnZXR0aW5nIGEgY2lwaGVy IGluc3RhbmNlIHdpdGggJnF1b3Q7UlNBL0VDQi9PQUVQV2l0aFNIQS0yNTZBbmRNR0YxUGFkZGlu ZyZxdW90Oz88bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSB0aGluayB0 aGF0J3MgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIChhbmQgSldBIGV2ZW4gaW1wbGllcyBpdCkgYnV0 IGEgY2hlY2sgZnJvbSBhIGRpZmZlcmVudCBsYW5ndWFnZS9wbGF0Zm9ybSB3b3VsZCBoZWxwIHZl cmlmeSB0aGF0IGFzc3VtcHRpb24uIEkgZG9uJ3Qga25vdyBpZiBtYXliZSBtb3JlIHNwZWNpZmlj cyBuZWVkIHRvIGJlIHByb3ZpZGVkIHRvIHRoZSBjaXBoZXIgdmlhIE9BRVBQYXJhbWV0ZXJTcGVj IG9yIHNvbWV0aGluZyAtIHRoZSBKQ0EgQVBJcyBjYW4gYmUgYSBiaXQgbXlzdGVyaW91cyBhdCB0 aW1lcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPk9uIFR1ZSwgTWF5IDYsIDIwMTQgYXQgNjozMiBBTSwgQW50b25pbyBTYW5zbyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFzYW5zb0BhZG9iZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hc2Fu c29AYWRvYmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+aGkgQnJpYW4sIDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBNYXkg NiwgMjAxNCwgYXQgMzoyOSBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj48YnI+PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+RnJvbSB0aGUgdmVuZXJhYmxl IGZpbG0gQW5pbWFsIEhvdXNlLCBvZiBjb3Vyc2UsIDxhIGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1 YmUuY29tL3dhdGNoP3Y9dlZYRVE4aGp5R0kiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy55 b3V0dWJlLmNvbS93YXRjaD92PXZWWEVROGhqeUdJPC9hPiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5UaGFua3MgZm9y IGNoZWNraW5nIHRoYXQgQW50b25pby4gPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPkhvcGVmdWxseSB3ZSBjb3VsZCBnZXQgYSBub24gSmF2YSBiYXNlZCBpbXBsZW1lbnRp bmcgdG8gdmVyaWZ5IGl0IHRvby48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5qdXN0IGZvciBjb21wbGV0ZW5lc3MgSSBkaWQgKm5vdCogdXNlIGpvc2U0aiB0byB2 ZXJpZnkgaXTigKYgKGp1c3QgdG8gYmUgc2FmZSk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5yZWdhcmRzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiM4ODg4ODgnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Izg4 ODg4OCc+YW50b25pbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxicj48YnI+PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24g VHVlLCBNYXkgNiwgMjAxNCBhdCA2OjI1IEFNLCBBbnRvbmlvIFNhbnNvICZsdDs8YSBocmVmPSJt YWlsdG86YXNhbnNvQGFkb2JlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFzYW5zb0BhZG9iZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiTW9uYWNvIiwi c2VyaWYiJz5XZWxsLCBhcyBvZiB0aGlzIG1vbWVudCwgdGhleSdyZSBvbiBET1VCTEUgU0VDUkVU IFBST0JBVElPTiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPk9uIE1heSA2LCAyMDE0LCBhdCAxMTozNCBBTSwgQW50b25pbyBTYW5zbyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFzYW5zb0BhZG9iZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hc2Fuc29A YWRvYmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxicj48YnI+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGkg QnJpYW4sIDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgd2lsbCBnaXZlIGEgdHJ5 IGFuZCBsZXQgeW91IGtub3c8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5y ZWdhcmRzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YW50b25pbzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gTWF5IDYsIDIwMTQsIGF0IDU6NDAg QU0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJy PjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBsYXRlc3QgcmV2aXNp b24gb2YgSldBIGFkZGVkIGEgbmV3ICdSU0EtT0FFUC0yNTYnIEpXRSBhbGcgZm9yIGtleSBlbmNy eXB0aW9uIGJ1dCwgQUZBSUssIHRoZXJlIGFyZSBubyBleGFtcGxlcyB1c2luZyBpdC4gSSByZWNl bnRseSBhZGRlZCBzdXBwb3J0IGZvciBpdCB0byA8YSBocmVmPSJodHRwczovL2JpdGJ1Y2tldC5v cmcvYl9jL2pvc2U0aiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYml0YnVja2V0Lm9yZy9iX2Mv am9zZTRqPC9hPiBhbmQgYW0gbG9va2luZyB0byBnZXQgc29tZSBraW5kIG9mIGNvbmZpcm1hdGlv biB0aGF0IEkndmUgZG9uZSBpdCBjb3JyZWN0bHkgKG90aGVyIHRoYW4gc2VsZiBpbnRlcm9wKS4g V2l0aCB0aGF0IGluIG1pbmQsIGhlcmUgaXMgYSBKV0UgdXNpbmcgUlNBLU9BRVAtMjU2IHdoaWNo IEkndmUgcHJvZHVjZWQgYW5kIEknbSBob3BlZnVsIHRoYXQgc29tZW9uZSBvbiB0aGlzIFdHIGxp c3Qgd2lsbCBiZSBhYmxlIHRvIGRlY3J5cHQuIFRoZSBSU0Ega2V5IHRoYXQgd2FzIHVzZWQgKGlu IEpXSyBmb3JtYXQgd2l0aCBib3RoIHB1YmxpYyBhbmQgcHJpdmF0ZSBwYXJ0cykgaXMgYmVsb3cg dGhlIEpXRS48YnI+PGJyPmV5SmhiR2NpT2lKU1UwRXRUMEZGVUMweU5UWWlMQ0psYm1NaU9pSkJN VEk0UTBKRExVaFRNalUySW4wLk95ZWc0aGJxMkhqdEhPY1hkdUs5VWhoSVhlcnZQek9UTEFxS3Bo Q3llSzU1Y0ZnS3RGMzJEaEQyNnNmbkc2aDlhejNPZ3JuNFF3WUplWmtqSkszNnRleWpsOW9LSVdf OUl0UDhjWWhPcmlET09aRmhvNTNCc3R0cWo4cGMwVVByTUo0NDh5UXNna2d5cW1mV1pRczN1X3FD YVNMWHBlZ0Uzby1ZSjUyMC1YdV9FbFM1cE55X3ZmU01FMUNlUDV1blBRUGYwNlhjNmlNVld4OS1L XzdseEM3YWNZSV9mU1NVd3VGdy12eHJWSk1SS2YwTkRpa2RtY29JNVdXN2g1Z0xYU3U0RVp2Vzh4 SHhBX1FvRUZuU2VZZ2c4TlFOT0dMZl9QYUJkZEFkbjhja19taHRKZGdmYzBXMjUxblR2aU1Bd1BB anNHMEZNblBveDdHZHR6VGRtQS4zREpTQ21HRGQ5V0ktREkzc0JSbThRLm5jRkk5dlVFZEtrdWhQ UjBoM25PSlA1ZEJnS3JjUzVmOVE3WjU4QVpUVGRUVjUzRmx6SklId2RtZS0xeGlwd0RpZlRPTDh5 aTdiZXVFRWlYZ19DU3p3LlVtTmx2cmZlQ0duaFdUOXF5dVVTU0E8YnI+PGJyPnsmcXVvdDtrdHkm cXVvdDs6JnF1b3Q7UlNBJnF1b3Q7LCZxdW90O24mcXVvdDs6JnF1b3Q7MmNRSkgxZjZ5RjlEY0dh OENtYm5objRMSExzNUw2a05iMnJ4a3JORlpBckpMUmFLdmFDM3RNQ0taOFpnSXBPOWJWTVB4NVVN akpvYWY3cDlPNUJTQXBWcUEySjEwZlViZFNJb21DY0R3dkdvMGV5aHR5MERJTExXVE1YekdFVk0z Qlh6dUpRb2VEa3VVQ1hYY0N3QTRNc3l5ZDJPSFZ1LXBCMk9yR3Y2ZmNqSHdqSU50eTNVb0ttMDhs Q3ZBZXZCS0hzdUEtRkZ3UUlJOWJ5Y3ZSeDV3UnFGVWpkTUF5aU9tTFlCSEJhSlNpMTFnM0hWZXhN Y2IyOXYxNFBTbFZ6ZEdVTU44b2JvYS16Y0l5YVBySWljekxxQWtTWFFOZEVGSHJqc0pIZkZlTk1m T2JsTE03aWNLTl90eVd1alllSXR0NGtxVUlpbVBuNWRIandnY1FZRTd3JnF1b3Q7LCZxdW90O2Um cXVvdDs6JnF1b3Q7QVFBQiZxdW90OywmcXVvdDtkJnF1b3Q7OiZxdW90O2R5VXozSXRWY2VYMVR2 MVdxdFpNbktBXzBqTjVnV01jTDdheWY1SklTQWxDc3NHZm5VcmUyQzEwVEgwVVFqYlZNSWgtbkxN bkQ1S05KdzlRejVNUjI4b0dHOTMyR3E3aG1fX1plQTM0bC1PQ2U0RGRwZ3docHZWU0hPVTlNUzFS ZFNVcG1QYXZBY0FfWDZpa3JBSFhaU2FvSGh4elVnck5UcHZCWVFNZkpVdl80OTJmU3RJc2VROXJ3 QU1PcENXT2lXTVpPUW0zS0pWVExMdW5YZEtmX1V4bXptS1hZS1laV2tlM0FXSXpVcW5PZnFJamZE VE11bkY0VVdVMHpLbGhjc2FRTm1ZTVZySkdhakQxYkpkeV9kYlVVM0xFOHN4LWJka1VJNm9Cay1z RnRUVFZ5VmRRY2V0RzlrQ2hKNUVuWTVSNnR0XzRfeEZHNWt4elRvNnFhUSZxdW90OywmcXVvdDtw JnF1b3Q7OiZxdW90Ozd5UW1nRTYwU0w3UXJYcEFKaENoTGdLblhXaTZDOHRWeDFsQThGVHBwaHBM YUN0Sy1IYmdCVkhDcHJDMkNmYU0xbXhGSlphaHhnRmpDOWVodVY4T3pNTnlGczhrZWtTODJFc1FH a3NpOEhKUHh5UjFmVTZBVGEzNm9nUEcwbk5hcW0zRURtWXlqb3dobnRnQnoyT2tiRkFzVE1IVGRu YS1wWkJSSmE5bG01VSZxdW90OywmcXVvdDtxJnF1b3Q7OiZxdW90OzZSNGR6bzlMd0hMTzczRU1R UFFzbXdYalZPdkFTNVc2cmdRLUJDdE1oZWNfUW9zQVhJVkUzQUd5ZndlcVptNnJ1clhDVkZ5a0RM d0ozMEdlcExROG5UbHplVjZjbHgweDcwc2FHR0tLVm1Dc0h1VllXd2dJUnlKVHJ0NFNYMjlOUURa X0ZFNTJObE8zT2hQa2oxRXhTa19wR01xR1JGZDI2SzhnMGpKc1hYTSZxdW90OywmcXVvdDtkcCZx dW90OzomcXVvdDtWQnluLWhzMHFCMk5jbWI4WnljVU9nV3U3bGptanoxdXAxWktVXzNaekpXVkRr ZWo3LTZIN3ZjSi11MU9xZ1J4RnY0djlfLWFXUFdsNjhWbFdia0lrSmJ4NnZuaXY2cXJyWHdCWnU0 a2xPUHdFWUJPWHN1Y3J6WFJZT2pwSnA1eU5sMnpSc2xGWVFRQzAwYndwQXhOQ2RmTkxSWkRsWGhB cUNVeGxZcXl0MTAmcXVvdDssJnF1b3Q7ZHEmcXVvdDs6JnF1b3Q7TUpGYnVHdFdadlFFZFJKaWNT M3VGU1kyNUx4eFJjNGVKSjh4cElDNDRyVDVFdzRPdHpmMHpybHp6TTkyQ3YxSHZoQ2NPaU5LOG5S Q3drYlRuSkVJaC1FdVU3MElkdHRZU2ZpbHFTcnVrMngwcjhNc2sxcXJEdGJ5QkY2MENUb1JLQzJ5 Y0RLZ29sVHl1YURuWDR5VTdseVR2ZHlELUwwWVF3WXBtbUZ5X2swJnF1b3Q7LCZxdW90O3FpJnF1 b3Q7OiZxdW90O3Z5N1hDd1ozanlNR2lrODFUSVpEQU9RS0M4RlZVYzBURzVLVllmdGk0dGd3elVx Rnd0dUI4T2MxY3RDS1JiRTd1WlVQd1poNE9zQ1RMcUl2cUJRZGFfa2F4T3hvNUVGN2lYajZ5SG1a MnM4UF9aX3UzSkx1aC1vQVRfNmttYkx4NkNBTzBEYnRLdHhwMjRJdmMxaERmcVN3V09SZ04xQU9y U1JDbUUzbnd4ZyZxdW90O308bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+am9zZSBt YWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5qb3NlQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxiciBjbGVhcj1hbGw+PGJyPi0tIDxvOnA+PC9vOnA+PC9w PjxkaXY+PGRpdj48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHBhZGRp bmc9MD48dHIgc3R5bGU9J2hlaWdodDo1OS4yNXB0Jz48dGQgd2lkdGg9NzUgdmFsaWduPXRvcCBz dHlsZT0nd2lkdGg6NTYuMjVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdo dDo1OS4yNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0iaHR0cHM6Ly93d3cucGluZ2lk ZW50aXR5LmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nYm9yZGVyOnNvbGlkIHdp bmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9y ZGVyPTAgd2lkdGg9MTAwIGhlaWdodD0xMDAgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6fldS RDAwMC5qcGciIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIFBpbmcgSWRlbnRpdHkgbG9n byI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCB2YWxpZ249dG9wIHN0eWxlPSdw YWRkaW5nOi43NXB0IC43NXB0IC43NXB0IDcuNXB0O2hlaWdodDo1OS4yNXB0Jz48ZGl2IHN0eWxl PSdtYXJnaW4tYm90dG9tOjUuMjVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiNFNjFEM0MnPkJyaWFuIENhbXBiZWxsPC9zcGFuPjwvYj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlBvcnRmb2xpbyBB cmNoaXRlY3Q8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PHRhYmxlIGNsYXNzPU1zb05vcm1h bFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTA+PHRyPjx0ZCBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLXJpZ2h0OnNvbGlkICNFNjFEM0MgMS4wcHQ7cGFkZGluZzowY20gMy43NXB0IDBjbSAw Y20nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2Vu dGVyJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojRTYxRDNDJz5APC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD48 L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAyLjI1cHQnPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItcmln aHQ6c29saWQgI0U2M0MxRCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSc+PHAgY2xhc3M9 TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0 eWxlPSdib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSc+PGltZyBib3Jk ZXI9MCB3aWR0aD0xMDAgaGVpZ2h0PTEwMCBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNpZDp+V1JE MDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4gcGhvbmUiPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAyLjI1cHQnPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0idGVsOiUyQjElMjA3MjAuMzE3LjIwNjEi IHRhcmdldD0iX2JsYW5rIj4rMSA3MjAuMzE3LjIwNjE8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvdGQ+PC90cj48dHI+PHRkIGNvbHNwYW49MiBzdHlsZT0ncGFkZGluZzoxMS4yNXB0IC43NXB0 IC43NXB0IC43NXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OSc+Q29u bmVjdCB3aXRoIHVz4oCmPG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48dHI+PHRkIGNv bHNwYW49MiBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vcGluZ2lkZW50aXR5IiB0YXJn ZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24gVHdpdHRlciI+PHNwYW4gc3R5bGU9J2JvcmRlcjpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtO3RleHQtZGVjb3JhdGlvbjpub25lJz48 aW1nIGJvcmRlcj0wIHdpZHRoPTEwMCBoZWlnaHQ9MTAwIGlkPSJfeDAwMDBfaTEwMjciIHNyYz0i Y2lkOn5XUkQwMDAuanBnIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiB0d2l0dGVyIGxv Z28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9QaW5n SWRlbnRpdHlUViIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIFlvdVR1YmUiPjxzcGFu IHN0eWxlPSdib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbTt0ZXh0LWRl Y29yYXRpb246bm9uZSc+PGltZyBib3JkZXI9MCB3aWR0aD0xMDAgaGVpZ2h0PTEwMCBpZD0iX3gw MDAwX2kxMDI4IiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNl bmRlci4geW91dHViZSBsb2dvIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmxpbmtl ZGluLmNvbS9jb21wYW55LzIxODcwIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24gTGlu a2VkSW4iPjxzcGFuIHN0eWxlPSdib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBjbTt0ZXh0LWRlY29yYXRpb246bm9uZSc+PGltZyBib3JkZXI9MCB3aWR0aD0xMDAgaGVpZ2h0 PTEwMCBpZD0iX3gwMDAwX2kxMDI5IiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSBy ZW1vdmVkIGJ5IHNlbmRlci4gTGlua2VkSW4gbG9nbyI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRw czovL3d3dy5mYWNlYm9vay5jb20vcGluZ2lkZW50aXR5cGFnZSIgdGFyZ2V0PSJfYmxhbmsiIHRp dGxlPSJQaW5nIG9uIEZhY2Vib29rIj48c3BhbiBzdHlsZT0nYm9yZGVyOnNvbGlkIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9yZGVyPTAg d2lkdGg9MTAwIGhlaWdodD0xMDAgaWQ9Il94MDAwMF9pMTAzMCIgc3JjPSJjaWQ6fldSRDAwMC5q cGciIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIEZhY2Vib29rIGxvZ28iPjwvc3Bhbj48 L2E+PGEgaHJlZj0iaHR0cHM6Ly9wbHVzLmdvb2dsZS5jb20vdS8wLzExNDI2Njk3NzczOTM5Nzcw ODU0MCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIEdvb2dsZSsiPjxzcGFuIHN0eWxl PSdib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbTt0ZXh0LWRlY29yYXRp b246bm9uZSc+PGltZyBib3JkZXI9MCB3aWR0aD0xMDAgaGVpZ2h0PTEwMCBpZD0iX3gwMDAwX2kx MDMxIiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4g R29vZ2xlKyBsb2dvIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2xpZGVzaGFyZS5u ZXQvUGluZ0lkZW50aXR5IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IlBpbmcgb24gU2xpZGVTaGFy ZSI+PHNwYW4gc3R5bGU9J2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNt O3RleHQtZGVjb3JhdGlvbjpub25lJz48aW1nIGJvcmRlcj0wIHdpZHRoPTEwMCBoZWlnaHQ9MTAw IGlkPSJfeDAwMDBfaTEwMzIiIHNyYz0iY2lkOn5XUkQwMDAuanBnIiBhbHQ9IkltYWdlIHJlbW92 ZWQgYnkgc2VuZGVyLiBzbGlkZXNoYXJlIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cDov L2ZsaXAuaXQvdmpCRjciIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBGbGlwYm9hcmQi PjxzcGFuIHN0eWxlPSdib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbTt0 ZXh0LWRlY29yYXRpb246bm9uZSc+PGltZyBib3JkZXI9MCB3aWR0aD0xMDAgaGVpZ2h0PTEwMCBp ZD0iX3gwMDAwX2kxMDMzIiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVk IGJ5IHNlbmRlci4gZmxpcGJvYXJkIGxvZ28iPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93 d3cucGluZ2lkZW50aXR5LmNvbS9ibG9ncy8iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBi bG9ncyI+PHNwYW4gc3R5bGU9J2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGNtO3RleHQtZGVjb3JhdGlvbjpub25lJz48aW1nIGJvcmRlcj0wIHdpZHRoPTEwMCBoZWlnaHQ9 MTAwIGlkPSJfeDAwMDBfaTEwMzQiIHNyYz0iY2lkOn5XUkQwMDAuanBnIiBhbHQ9IkltYWdlIHJl bW92ZWQgYnkgc2VuZGVyLiByc3MgZmVlZCBpY29uIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w PjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPjwvZGl2Pjx0YWJsZSBjbGFzcz1N c29Ob3JtYWxUYWJsZSBib3JkZXI9MSBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9 MzE1IHN0eWxlPSd3aWR0aDoyMzYuMjVwdDtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGVy Om5vbmUnPjx0ciBzdHlsZT0naGVpZ2h0OjYwLjc1cHQnPjx0ZCB3aWR0aD0xNzIgdmFsaWduPXRv cCBzdHlsZT0nd2lkdGg6MTI5LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjExLjI1cHQgMTEuMjVw dCAwY20gMTEuMjVwdDtoZWlnaHQ6NjAuNzVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmNsb3VkaWRlbnRpdHlzdW1taXQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiIHRp dGxlPSJSZWdpc3RlciBmb3IgQ2xvdWQgSWRlbnRpdHkgU3VtbWl0IDIwMTQgfCBNb2Rlcm4gSWRl bnRpdHkgUmV2b2x1dGlvbiB8IDE54oCTMjMgSnVseSwgMjAxNCB8IE1vbnRlcmV5LCBDQSI+PHNw YW4gc3R5bGU9J2NvbG9yOiNDQ0NDQ0M7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9yZGVyPTAgd2lkdGg9MTAwIGhl aWdodD0xMDAgaWQ9Il94MDAwMF9pMTAzNSIgc3JjPSJjaWQ6fldSRDAwMC5qcGciIGFsdD0iSW1h Z2UgcmVtb3ZlZCBieSBzZW5kZXIuIFJlZ2lzdGVyIGZvciBDbG91ZCBJZGVudGl0eSBTdW1taXQg MjAxNCB8IE1vZGVybiBJZGVudGl0eSBSZXZvbHV0aW9uIHwgMTnigJMyMyBKdWx5LCAyMDE0IHwg TW9udGVyZXksIENBIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48L3RhYmxl PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPmpv c2UgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGll dGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxi cj48YnIgY2xlYXI9YWxsPjxicj4tLSA8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHRhYmxlIGNs YXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTA+PHRyIHN0eWxlPSdoZWln aHQ6NTkuMjVwdCc+PHRkIHdpZHRoPTc1IHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjU2LjI1cHQ7 cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDtoZWlnaHQ6NTkuMjVwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9J2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6MGNtO3RleHQtZGVjb3JhdGlvbjpub25lJz48aW1nIGJvcmRlcj0wIHdpZHRoPTEwMCBoZWln aHQ9MTAwIGlkPSJfeDAwMDBfaTEwMzYiIHNyYz0iY2lkOn5XUkQwMDAuanBnIiBhbHQ9IkltYWdl IHJlbW92ZWQgYnkgc2VuZGVyLiBQaW5nIElkZW50aXR5IGxvZ28iPjwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+PC90ZD48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCA3LjVwdDtoZWlnaHQ6NTkuMjVwdCc+PGRpdiBzdHlsZT0nbWFyZ2luLWJvdHRvbTo1LjI1 cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojRTYxRDNDJz5CcmlhbiBDYW1w YmVsbDwvc3Bhbj48L2I+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Qb3J0Zm9saW8gQXJjaGl0ZWN0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBi b3JkZXI9MCBjZWxscGFkZGluZz0wPjx0cj48dGQgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1y aWdodDpzb2xpZCAjRTYxRDNDIDEuMHB0O3BhZGRpbmc6MGNtIDMuNzVwdCAwY20gMGNtJz48cCBj bGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6I0U2MUQzQyc+QDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+PC90ZD48dGQg c3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAwY20gMi4yNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LXJpZ2h0OnNvbGlkICNFNjNDMUQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20nPjxwIGNs YXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bh biBzdHlsZT0nYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20nPjxpbWcg Ym9yZGVyPTAgd2lkdGg9MTAwIGhlaWdodD0xMDAgaWQ9Il94MDAwMF9pMTAzNyIgc3JjPSJjaWQ6 fldSRDAwMC5qcGciIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIHBob25lIj48L3NwYW4+ PG86cD48L286cD48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAwY20gMi4yNXB0 Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPisxIDcyMC4zMTcuMjA2MTwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPTIgc3R5bGU9J3Bh ZGRpbmc6MTEuMjVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiM5OTk5OTknPkNvbm5lY3Qgd2l0aCB1c+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPTIgc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1 cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29t L3BpbmdpZGVudGl0eSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJQaW5nIG9uIFR3aXR0ZXIiPjxz cGFuIHN0eWxlPSdib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbTt0ZXh0 LWRlY29yYXRpb246bm9uZSc+PGltZyBib3JkZXI9MCB3aWR0aD0xMDAgaGVpZ2h0PTEwMCBpZD0i X3gwMDAwX2kxMDM4IiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5 IHNlbmRlci4gdHdpdHRlciBsb2dvIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lnlv dXR1YmUuY29tL3VzZXIvUGluZ0lkZW50aXR5VFYiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGlu ZyBvbiBZb3VUdWJlIj48c3BhbiBzdHlsZT0nYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9yZGVyPTAgd2lkdGg9MTAw IGhlaWdodD0xMDAgaWQ9Il94MDAwMF9pMTAzOSIgc3JjPSJjaWQ6fldSRDAwMC5qcGciIGFsdD0i SW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIHlvdXR1YmUgbG9nbyI+PC9zcGFuPjwvYT48YSBocmVm PSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS8yMTg3MCIgdGFyZ2V0PSJfYmxhbmsi IHRpdGxlPSJQaW5nIG9uIExpbmtlZEluIj48c3BhbiBzdHlsZT0nYm9yZGVyOnNvbGlkIHdpbmRv d3RleHQgMS4wcHQ7cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9yZGVy PTAgd2lkdGg9MTAwIGhlaWdodD0xMDAgaWQ9Il94MDAwMF9pMTA0MCIgc3JjPSJjaWQ6fldSRDAw MC5qcGciIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIExpbmtlZEluIGxvZ28iPjwvc3Bh bj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBhZ2Ui IHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBGYWNlYm9vayI+PHNwYW4gc3R5bGU9J2Jv cmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtO3RleHQtZGVjb3JhdGlvbjpu b25lJz48aW1nIGJvcmRlcj0wIHdpZHRoPTEwMCBoZWlnaHQ9MTAwIGlkPSJfeDAwMDBfaTEwNDEi IHNyYz0iY2lkOn5XUkQwMDAuanBnIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiBGYWNl Ym9vayBsb2dvIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8vcGx1cy5nb29nbGUuY29tL3Uv MC8xMTQyNjY5Nzc3MzkzOTc3MDg1NDAiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUGluZyBvbiBH b29nbGUrIj48c3BhbiBzdHlsZT0nYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9yZGVyPTAgd2lkdGg9MTAwIGhlaWdo dD0xMDAgaWQ9Il94MDAwMF9pMTA0MiIgc3JjPSJjaWQ6fldSRDAwMC5qcGciIGFsdD0iSW1hZ2Ug cmVtb3ZlZCBieSBzZW5kZXIuIEdvb2dsZSsgbG9nbyI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRw Oi8vd3d3LnNsaWRlc2hhcmUubmV0L1BpbmdJZGVudGl0eSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSJQaW5nIG9uIFNsaWRlU2hhcmUiPjxzcGFuIHN0eWxlPSdib3JkZXI6c29saWQgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBjbTt0ZXh0LWRlY29yYXRpb246bm9uZSc+PGltZyBib3JkZXI9MCB3 aWR0aD0xMDAgaGVpZ2h0PTEwMCBpZD0iX3gwMDAwX2kxMDQzIiBzcmM9ImNpZDp+V1JEMDAwLmpw ZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4gc2xpZGVzaGFyZSBsb2dvIj48L3NwYW4+ PC9hPjxhIGhyZWY9Imh0dHA6Ly9mbGlwLml0L3ZqQkY3IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9 IlBpbmcgb24gRmxpcGJvYXJkIj48c3BhbiBzdHlsZT0nYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9yZGVyPTAgd2lk dGg9MTAwIGhlaWdodD0xMDAgaWQ9Il94MDAwMF9pMTA0NCIgc3JjPSJjaWQ6fldSRDAwMC5qcGci IGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIGZsaXBib2FyZCBsb2dvIj48L3NwYW4+PC9h PjxhIGhyZWY9Imh0dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20vYmxvZ3MvIiB0YXJnZXQ9Il9i bGFuayIgdGl0bGU9IlBpbmcgYmxvZ3MiPjxzcGFuIHN0eWxlPSdib3JkZXI6c29saWQgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjBjbTt0ZXh0LWRlY29yYXRpb246bm9uZSc+PGltZyBib3JkZXI9 MCB3aWR0aD0xMDAgaGVpZ2h0PTEwMCBpZD0iX3gwMDAwX2kxMDQ1IiBzcmM9ImNpZDp+V1JEMDAw LmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4gcnNzIGZlZWQgaWNvbiI+PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT48 L2Rpdj48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTEgY2VsbHNwYWNpbmc9MCBj ZWxscGFkZGluZz0wIHdpZHRoPTMxNSBzdHlsZT0nd2lkdGg6MjM2LjI1cHQ7Ym9yZGVyLWNvbGxh cHNlOmNvbGxhcHNlO2JvcmRlcjpub25lJz48dHIgc3R5bGU9J2hlaWdodDo2MC43NXB0Jz48dGQg d2lkdGg9MTcyIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjEyOS4wcHQ7Ym9yZGVyOm5vbmU7cGFk ZGluZzoxMS4yNXB0IDExLjI1cHQgMGNtIDExLjI1cHQ7aGVpZ2h0OjYwLjc1cHQnPjxwIGNsYXNz PU1zb05vcm1hbD48YSBocmVmPSJodHRwczovL3d3dy5jbG91ZGlkZW50aXR5c3VtbWl0LmNvbS8i IHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iUmVnaXN0ZXIgZm9yIENsb3VkIElkZW50aXR5IFN1bW1p dCAyMDE0IHwgTW9kZXJuIElkZW50aXR5IFJldm9sdXRpb24gfCAxOeKAkzIzIEp1bHksIDIwMTQg fCBNb250ZXJleSwgQ0EiPjxzcGFuIHN0eWxlPSdjb2xvcjojQ0NDQ0NDO2JvcmRlcjpzb2xpZCB3 aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtO3RleHQtZGVjb3JhdGlvbjpub25lJz48aW1nIGJv cmRlcj0wIHdpZHRoPTEwMCBoZWlnaHQ9MTAwIGlkPSJfeDAwMDBfaTEwNDYiIHNyYz0iY2lkOn5X UkQwMDAuanBnIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiBSZWdpc3RlciBmb3IgQ2xv dWQgSWRlbnRpdHkgU3VtbWl0IDIwMTQgfCBNb2Rlcm4gSWRlbnRpdHkgUmV2b2x1dGlvbiB8IDE5 4oCTMjMgSnVseSwgMjAxNCB8IE1vbnRlcmV5LCBDQSI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD48L3RkPjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_-- --_004_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Tue, 06 May 2014 19:19:17 GMT"; modification-date="Tue, 06 May 2014 19:19:17 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_CE8995AB5D178F44A2154F5C9A97CAF402631C6038C5HE111541eme_-- From nobody Tue May 6 20:39:33 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDC21A021D for ; Tue, 6 May 2014 20:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.097 X-Spam-Level: X-Spam-Status: No, score=-12.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADOBE2=2.455, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saF9luSgjSlU for ; Tue, 6 May 2014 20:39:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 010F21A0217 for ; Tue, 6 May 2014 20:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9158; q=dns/txt; s=iport; t=1399433964; x=1400643564; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LeO2zERgpfOR0IeOCGcp09mci7gAvVUHrrSKpKK1WE0=; b=aJtwKt1iQarPNOIX8ctdi3l/NQ5p3KARlrmbgs61kn4i4kCiCT1RjLOk PytNyHAUP55//do8GUuxFzBz8LvCXUoqrVaf5BcD4e5wXwF9o8Q+23r14 Sda6CX2QaVWUX1dbUBTOmGxdyKD1zEJ7QDXSwfiaABllMA2rU0SQQr3C0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAHACiqaVOtJA2J/2dsb2JhbABRBgODBk9RB6p4AQEBAQEBBpJShzmBIBZ0giUBAQEEAQEBawoBDgILDgoJFggHCQMCAQIBCQwfEQYBDAEFAgEBiD0IBc5GFwSFUoVtgjQoIxAHEYQuBIRaAoUsiFeGWIE8i2GFXoNTghA X-IronPort-AV: E=Sophos;i="4.97,1000,1389744000"; d="scan'208";a="322915310" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 07 May 2014 03:39:22 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s473dMjV027751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 03:39:22 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.86.245.104) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 May 2014 22:39:22 -0500 Message-ID: <5369AAE7.2060704@cisco.com> Date: Tue, 6 May 2014 21:39:19 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Campbell , Antonio Sanso References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.86.245.104] Archived-At: http://mailarchive.ietf.org/arch/msg/jose/L5BAApECEBPe0fHSe8hXOhb_fN0 Cc: "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 03:39:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Short answer: You are all equally broken -- except from a certain point of view d-: Long answer: The code I have is based on OpenSSL, which is hard-coded to use SHA1 for the hash and mask generation (boo!), which means one has to implement OAEP-SHA256 from scratch (hiss!!). When I implemented it per RFC 3447 and draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I could decrypt provided results. A search through BouncyCastle's code shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further evidence is shown with how [FORGE] can be made to work with Java (search their homepage for "Compatible with Java's RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). Reconciling all of this with draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be very straight-forward. It appears that the JCA identifier is meant to be "MGF1 with SHA1"; that ought to be explicitly noted. The XMLENC reference is arguably incomplete, since "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can probably be addressed by explicitly stating the mask generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 with SHA-256). - --=20 - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [FORGE] Forge < https://github.com/digitalbazaar/forge > On 5/6/14, 8:00 AM, Brian Campbell wrote: > But you probable did do something very similar to what I did in > jose4j - i.e. just getting a cipher instance with=20 > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"? >=20 > I think that's the right thing to do (and JWA even implies it) but > a check from a different language/platform would help verify that=20 > assumption. I don't know if maybe more specifics need to be > provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times. >=20 >=20 > On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso > wrote: >=20 > hi Brian, >=20 >=20 > On May 6, 2014, at 3:29 PM, Brian Campbell=20 > > > wrote: >=20 >> From the venerable film Animal House, of course,=20 >> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI >>=20 >> Thanks for checking that Antonio. >>=20 >> Hopefully we could get a non Java based implementing to verify it >> too. >=20 > just for completeness I did *not* use jose4j to verify it=85 (just > to be safe) >=20 > regards >=20 > antonio >=20 >>=20 >>=20 >>=20 >>=20 >> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso > > wrote: >>=20 >> Well, as of this moment, they're on DOUBLE SECRET PROBATION! >>=20 >> On May 6, 2014, at 11:34 AM, Antonio Sanso > > wrote: >>=20 >>> Hi Brian, >>>=20 >>> I will give a try and let you know >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>> On May 6, 2014, at 5:40 AM, Brian Campbell=20 >>> >> > wrote: >>>=20 >>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg >>>> for key encryption but, AFAIK, there are no examples using >>>> it. I recently added support for it to=20 >>>> https://bitbucket.org/b_c/jose4j and am looking to get some=20 >>>> kind of confirmation that I've done it correctly (other than=20 >>>> self interop). With that in mind, here is a JWE using=20 >>>> RSA-OAEP-256 which I've produced and I'm hopeful that someone >>>> on this WG list will be able to decrypt. The RSA key that was >>>> used (in JWK format with both public and private parts) is >>>> below the JWE. >>>>=20 >>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2H= jtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36t= eyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE= 3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJM= RKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0= W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3n= OJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrf= eCGnhWT9qyuUSSA >>>> >>>> >>>>=20 {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx 0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxF= v4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC= 00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8x= pIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8M= sk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ= 3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqB= Qda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN= 1AOrSRCmE3nwxg"} >>>> _______________________________________________ jose mailing >>>> list jose@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >>=20 >>=20 >>=20 >> -- Ping Identity logo Brian >> Campbell Portfolio Architect @ bcampbell@pingidentity.com >> phone +1 720.317.2061 >> Connect with us=85 twitter logo >> youtube logo=20 >> LinkedIn logo=20 >> Facebook logo=20 >> Google+ logo=20 >> slideshare=20 >> logo flipboard logo=20 >> rss feed icon=20 >> >>=20 >> Register for Cloud Identity Summit 2014 | Modern Identity=20 >> Revolution | 19=9623 July, 2014 | Monterey, CA=20 >> >>=20 >>=20 >=20 >=20 > _______________________________________________ jose mailing list=20 > jose@ietf.org =20 > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 > -- Ping Identity logo Brian > Campbell Portfolio Architect @ bcampbell@pingidentity.com > phone +1 720.317.2061 Connect > with us=85 twitter logo youtube > logo LinkedIn logo=20 > Facebook logo=20 > Google+ logo=20 > slideshare > logo flipboard logo=20 > rss feed icon > >=20 > Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=9623 July, 2014 | Monterey, CA > >=20 >=20 >=20 >=20 > _______________________________________________ jose mailing list=20 > jose@ietf.org https://www.ietf.org/mailman/listinfo/jose >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI 6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D =3DO9Ex -----END PGP SIGNATURE----- From nobody Tue May 6 21:54:31 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09BE1A0451 for ; Tue, 6 May 2014 21:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzJfrWeYGWNA for ; Tue, 6 May 2014 21:54:27 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id B45E91A022B for ; Tue, 6 May 2014 21:54:26 -0700 (PDT) Received: from mail-ig0-f178.google.com ([209.85.213.178]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKU2m8futRMPrm+XDN5SY1M/z+FpdYyL5/@postini.com; Tue, 06 May 2014 21:54:23 PDT Received: by mail-ig0-f178.google.com with SMTP id hl10so624617igb.11 for ; Tue, 06 May 2014 21:54:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IWUrhoLj7nnBHcCyrbkvfkJ3UAqI2jWQSB5LQ+hKV1Q=; b=fq/9sni30fIo0E5feELwzdQfTarN5QlYiPweYjBZ6r4c79GW2cDiJ2TJRXgiOzKLAG ljBHRZ/bcMMpphsX/3lqKsDDeDFvMITTgNvNsc8Zw8NGxBeVdsHurzkBwI9HzljNSxrq +YzEZKj6pBzFMfDPZHvZmaoCfagoUDq9s1oQBwl8JRRJ5HQIQN5VDkBYik1UKbv5AvYm Nc6FGHuJGvrN8f1MdnQX4EgBxtqw9QoX5+ObezXZlWJCFUf+l6eKBS0E+zXzb9jIzhZP 3vCQuo4RuKW6L4hmD7mdxoHAamvqSQG1rAWVxh/BoTKtSErwukcC7STY4OED3NLX3tAe R6Lw== X-Gm-Message-State: ALoCoQmBx/9gHJ7s4vJk3Ke5SttVt0uZlGEManVA8BgevLmtx+aUZu4wcZhFG6lUV1vnNj6537D7DftRLgYUuC7j4D3UZgiwcDFtHHcN3ypu2NauKR2OC2iW3TtQeTgWh2p7MsKvoB+g X-Received: by 10.51.17.5 with SMTP id ga5mr39252421igd.2.1399438462131; Tue, 06 May 2014 21:54:22 -0700 (PDT) X-Received: by 10.51.17.5 with SMTP id ga5mr39252396igd.2.1399438461923; Tue, 06 May 2014 21:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Tue, 6 May 2014 21:53:51 -0700 (PDT) In-Reply-To: <5369AAE7.2060704@cisco.com> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> From: Brian Campbell Date: Tue, 6 May 2014 21:53:51 -0700 Message-ID: To: Matt Miller Content-Type: multipart/alternative; boundary=001a1135e1da688fb604f8c828f7 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/IRE72bTRmgWPA4x42KH-fqyKJwM Cc: Antonio Sanso , "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 04:54:30 -0000 --001a1135e1da688fb604f8c828f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Matt. That is why I was looking for someone to verify using a different platform. Though I was hoping it'd just work. Matt, can you try decrypting this one by chance? Using the same key. I was more explicit with the parameters and, I think, MGF1 should be using SHA-256 now too. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9= _ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYe= PXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2K= ZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3Gq= SPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCm= BOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExC= fE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM= -08tIZ-h5w On Tue, May 6, 2014 at 8:39 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Short answer: > You are all equally broken -- except from a certain point of view d-: > > Long answer: > The code I have is based on OpenSSL, which is hard-coded to use SHA1 > for the hash and mask generation (boo!), which means one has to > implement OAEP-SHA256 from scratch (hiss!!). > > When I implemented it per RFC 3447 and > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I > could decrypt provided results. A search through BouncyCastle's code > shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash > function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1". > Further evidence is shown with how [FORGE] can be made to work with > Java (search their homepage for "Compatible with Java's > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > Reconciling all of this with > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be > very straight-forward. It appears that the JCA identifier is meant to > be "MGF1 with SHA1"; that ought to be explicitly noted. The XMLENC > reference is arguably incomplete, since > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can > probably be addressed by explicitly stating the mask generation > function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 with > SHA-256). > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > [FORGE] Forge < https://github.com/digitalbazaar/forge > > > On 5/6/14, 8:00 AM, Brian Campbell wrote: > > But you probable did do something very similar to what I did in > > jose4j - i.e. just getting a cipher instance with > > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"? > > > > I think that's the right thing to do (and JWA even implies it) but > > a check from a different language/platform would help verify that > > assumption. I don't know if maybe more specifics need to be > > provided to the cipher via OAEPParameterSpec or something - the JCA > > APIs can be a bit mysterious at times. > > > > > > On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso > > wrote: > > > > hi Brian, > > > > > > On May 6, 2014, at 3:29 PM, Brian Campbell > > > > > wrote: > > > >> From the venerable film Animal House, of course, > >> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI > >> > >> Thanks for checking that Antonio. > >> > >> Hopefully we could get a non Java based implementing to verify it > >> too. > > > > just for completeness I did *not* use jose4j to verify it=E2=80=A6 (jus= t > > to be safe) > > > > regards > > > > antonio > > > >> > >> > >> > >> > >> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso >> > wrote: > >> > >> Well, as of this moment, they're on DOUBLE SECRET PROBATION! > >> > >> On May 6, 2014, at 11:34 AM, Antonio Sanso >> > wrote: > >> > >>> Hi Brian, > >>> > >>> I will give a try and let you know > >>> > >>> regards > >>> > >>> antonio > >>> > >>> On May 6, 2014, at 5:40 AM, Brian Campbell > >>> >>> > wrote: > >>> > >>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg > >>>> for key encryption but, AFAIK, there are no examples using > >>>> it. I recently added support for it to > >>>> https://bitbucket.org/b_c/jose4j and am looking to get some > >>>> kind of confirmation that I've done it correctly (other than > >>>> self interop). With that in mind, here is a JWE using > >>>> RSA-OAEP-256 which I've produced and I'm hopeful that someone > >>>> on this WG list will be able to decrypt. The RSA key that was > >>>> used (in JWK format with both public and private parts) is > >>>> below the JWE. > >>>> > >>>> > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtH= OcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyj= l9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-= YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf= 0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W25= 1nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP= 5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCG= nhWT9qyuUSSA > >>>> > >>>> > >>>> > > {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMC= KZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3B= XzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9= bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqA= kSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB",= "d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nL= MnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikr= AHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKX= YKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6o= Bk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChL= gKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS8= 2EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U= ","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXC= VFykDLwJ30GepLQ8nTlzeV6clx > > 0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJ= sXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgR= xFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQ= QC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ= 8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r= 8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XC= wZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIv= qBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWOR= gN1AOrSRCmE3nwxg"} > >>>> _______________________________________________ jose mailing > >>>> list jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose > >>> > >> > >> > >> > >> > >> -- Ping Identity logo Brian > >> Campbell Portfolio Architect @ bcampbell@pingidentity.com > >> phone +1 720.317.2061 > >> Connect with us=E2=80=A6 twitter logo > >> youtube logo > >> LinkedIn logo > >> Facebook logo > >> Google+ logo > >> slideshare > >> logo flipboard logo > >> rss feed icon > >> > >> > >> Register for Cloud Identity Summit 2014 | Modern Identity > >> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA > >> > >> > >> > > > > > > _______________________________________________ jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > -- Ping Identity logo Brian > > Campbell Portfolio Architect @ bcampbell@pingidentity.com > > phone +1 720.317.2061 Connect > > with us=E2=80=A6 twitter logo youtub= e > > logo LinkedIn logo > > Facebook logo > > Google+ logo > > slideshare > > logo flipboard logo > > rss feed icon > > > > > > Register for Cloud Identity Summit 2014 | Modern Identity > > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA > > > > > > > > > > > > _______________________________________________ jose mailing list > > jose@ietf.org https://www.ietf.org/mailman/listinfo/jose > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad > CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI > 6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn > LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX > QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG > xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D > =3DO9Ex > -----END PGP SIGNATURE----- > --001a1135e1da688fb604f8c828f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Matt.

That is why I was looking for so= meone to verify using a different platform. Though I was hoping it'd ju= st work.

Matt, can you try decrypting this one by chance? Usin= g the same key. I was more explicit with the parameters and, I think, MGF1 = should be using SHA-256 now too.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5= cMCjjU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1= PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvS= TFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyx= y3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6= eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzM= L1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nM= UXOgmgWvM-08tIZ-h5w


On Tue, May 6= , 2014 at 8:39 PM, Matt Miller <mamille2@cisco.com> wrote:<= br>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Short answer:
You are all equally broken -- except from a certain point of view d-:

Long answer:
The code I have is based on OpenSSL, which is hard-coded to use SHA1
for the hash and mask generation (boo!), which means one has to
implement OAEP-SHA256 from scratch (hiss!!).

When I implemented it per RFC 3447 and
draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
decrypt the provided results. =C2=A0When I hard-coded MGF1 to use "SHA= 1", I
could decrypt provided results. =C2=A0A search through BouncyCastle's c= ode
shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1"= ;.
Further evidence is shown with how [FORGE] can be made to work with
Java (search their homepage for "Compatible with Java's
RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

Reconciling all of this with
draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be
very straight-forward. =C2=A0It appears that the JCA identifier is meant to=
be "MGF1 with SHA1"; that ought to be explicitly noted. =C2=A0The= XMLENC
reference is arguably incomplete, since
"http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
"http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this= can
probably be addressed by explicitly stating the mask generation
function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 = with
SHA-256).


- --
- - m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.

[FORGE] Forge < https://github.com/digitalbazaar/forge >

On 5/6/14, 8:00 AM, Brian Campbell wrote:
> But you probable did do something very similar to what I did in
> jose4j - i.e. just getting a cipher instance with
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"?
>
> I think that's the right thing to do (and JWA even implies it) but=
> a check from a different language/platform would help verify that
> assumption. I don't know if maybe more specifics need to be
> provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times.
>
>
> On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <asanso@adobe.com
> <mailto:asanso@adobe.com>> wrote:
>
> hi Brian,
>
>
> On May 6, 2014, at 3:29 PM, Brian Campbell
> <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>>
> wrote:
>
>> From the venerable film Animal House, of course,
>> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI
>>
>> Thanks for checking that Antonio.
>>
>> Hopefully we could get a non Java based implementing to verify it<= br> >> too.
>
> just for completeness I did *not* use jose4j to verify it=E2=80=A6 (ju= st
> to be safe)
>
> regards
>
> antonio
>
>>
>>
>>
>>
>> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>> Well, as of this moment, they're on DOUBLE SECRET PROBATION! >>
>> On May 6, 2014, at 11:34 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>>> Hi Brian,
>>>
>>> I will give a try and let you know
>>>
>>> regards
>>>
>>> antonio
>>>
>>> On May 6, 2014, at 5:40 AM, Brian Campbell
>>> <bcampbell@pingidentity.com
>>> <mailto:bcampbell@pingidentity.com>> wrote:
>>>
>>>> The latest revision of JWA added a new 'RSA-OAEP-256&#= 39; JWE alg
>>>> for key encryption but, AFAIK, there are no examples using=
>>>> it. I recently added support for it to
>>>> https://bitbucket.org/b_c/jose4j and am looking to get some
>>>> kind of confirmation that I've done it correctly (othe= r than
>>>> self interop). With that in mind, here is a JWE using
>>>> RSA-OAEP-256 which I've produced and I'm hopeful t= hat someone
>>>> on this WG list will be able to decrypt. The RSA key that = was
>>>> used (in JWK format with both public and private parts) is=
>>>> below the JWE.
>>>>
>>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In= 0.Oyeg4hbq2HjtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4Q= wYJeZkjJK36teyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3= u_qCaSLXpegE3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSS= UwuFw-vxrVJMRKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8= ck_mhtJdgfc0W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vU= EdKkuhPR0h3nOJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_= CSzw.UmNlvrfeCGnhWT9qyuUSSA
>>>>
>>>>
>>>>
{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx
0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVD= kej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXR= YOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":&q= uot;MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiN= K8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4= yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAO= QKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7i= Xj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg&= quot;}
>>>> _______________________________________________ jose maili= ng
>>>> list jose@ietf.org <mailto:jose@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>>
>>
>>
>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>> Campbell Portfolio Architect @ =C2=A0 =C2=A0 =C2=A0 bcampbell@pingiden= tity.com
>> <mailto:bcampbell@pingidentity.com> phone =C2=A0 =C2=A0+1 7= 20.317.2061
>> <tel:%2B1%20720.317.2061> Connect with us=E2=80=A6 twitter l= ogo
>> <https://twitter.com/pingidentity> youtube logo
>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn lo= go
>> <https://www.linkedin.com/company/21870> Facebook logo
>> <https://www.facebook.com/pingidentitypage> Google+ logo<= br> >> <https://plus.google.com/u/0/114266977739397708540>= slideshare
>> logo <http://www.slideshare.net/PingIdentity> flipboard logo >> <http://flip= .it/vjBF7> rss feed icon
>> <https://www.pingidentity.com/blogs/>
>>
>> Register for Cloud Identity Summit 2014 | Modern Identity
>> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA
>> <https://www.cloudidentitysummit.com/>
>>
>>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org &= lt;mailto:jose@ietf.org<= /a>>
>
https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
> -- Ping Identity logo <https://www.pingidentity.com/> Brian
> Campbell Portfolio Architect @ =C2=A0 =C2=A0 =C2=A0 =C2=A0bcampbell@pingiden= tity.com
> <mailto:bcampbell@pingidentity.com> phone =C2=A0 =C2=A0 +1 72= 0.317.2061 Connect
> with us=E2=80=A6 twitter logo <https://twitter.com/pingidentity> youtube=
> logo <https://www.youtube.com/user/PingIdentityTV> LinkedIn l= ogo
> <https://www.linkedin.com/company/21870> Facebook logo
> <https://www.facebook.com/pingidentitypage> Google+ logo
> <https://plus.google.com/u/0/114266977739397708540> sli= deshare
> logo <http://www.slideshare.net/PingIdentity> flipboard logo
> <http://flip.it/= vjBF7> rss feed icon
> <= https://www.pingidentity.com/blogs/>
>
> Register for Cloud Identity Summit 2014 | Modern Identity
> Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA
> <https://www.cloudidentitysummit.com/>
>
>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/jose" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/jose
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad
CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI
6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn
LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX
QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG
xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D
=3DO9Ex
-----END PGP SIGNATURE-----

--001a1135e1da688fb604f8c828f7-- From nobody Tue May 6 22:08:08 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40371A063C for ; Tue, 6 May 2014 22:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJNExpVMSPb4 for ; Tue, 6 May 2014 22:07:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id AECE61A049A for ; Tue, 6 May 2014 22:07:57 -0700 (PDT) Received: from DM2PR03CA008.namprd03.prod.outlook.com (10.141.52.156) by BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 05:07:51 +0000 Received: from BL2FFO11FD058.protection.gbl (2a01:111:f400:7c09::160) by DM2PR03CA008.outlook.office365.com (2a01:111:e400:2414::28) with Microsoft SMTP Server (TLS) id 15.0.934.12 via Frontend Transport; Wed, 7 May 2014 05:07:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD058.mail.protection.outlook.com (10.173.161.186) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Wed, 7 May 2014 05:07:50 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.63]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0181.007; Wed, 7 May 2014 05:07:22 +0000 From: Mike Jones To: Brian Campbell , Matt Miller Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaNzzUST7t/6zekuLw8sjGcxcCJszSweAgABAdgCAAAExAIAAAPYAgAAHsoCAAOTKgIAAFNOAgAADxlY= Date: Wed, 7 May 2014 05:07:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439A1ABC21@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439A1ABC21TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(438001)(199002)(54524002)(189002)(51444003)(377454003)(479174003)(24454002)(51704005)(52604005)(81542001)(26826002)(81156002)(64706001)(50986999)(76176999)(54356999)(19580395003)(2009001)(83322001)(99396002)(76482001)(71186001)(74502001)(81342001)(69596002)(16236675002)(92726001)(97736001)(74662001)(20776003)(6806004)(86612001)(31966008)(15198665003)(68736004)(2656002)(21056001)(19580405001)(80022001)(4396001)(575784001)(86362001)(79102001)(46102001)(77982001)(44976005)(15395725003)(84326002)(92566001)(83072002)(85852003)(55846006)(15975445006)(87936001)(15202345003)(33656001)(84676001)(16297215004)(443494003)(9984715005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB023; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0204F0BDE2 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/6cXcCEsZIm5aMm8tnxWFTzr1b7s Cc: Antonio Sanso , "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 05:08:03 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439A1ABC21TK5EX14MBXC288r_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable What new parameter values did you use? ________________________________ From: Brian Campbell Sent: =FD5/=FD6/=FD2014 9:54 PM To: Matt Miller Cc: Antonio Sanso; jose@ietf.org Subject: Re: [jose] RSA-OAEP-256 Example Thanks Matt. That is why I was looking for someone to verify using a different platform.= Though I was hoping it'd just work. Matt, can you try decrypting this one by chance? Using the same key. I was = more explicit with the parameters and, I think, MGF1 should be using SHA-25= 6 now too. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9= _ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYe= PXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2K= ZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3Gq= SPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCm= BOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExC= fE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM= -08tIZ-h5w On Tue, May 6, 2014 at 8:39 PM, Matt Miller > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Short answer: You are all equally broken -- except from a certain point of view d-: Long answer: The code I have is based on OpenSSL, which is hard-coded to use SHA1 for the hash and mask generation (boo!), which means one has to implement OAEP-SHA256 from scratch (hiss!!). When I implemented it per RFC 3447 and draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I could decrypt provided results. A search through BouncyCastle's code shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further evidence is shown with how [FORGE] can be made to work with Java (search their homepage for "Compatible with Java's RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). Reconciling all of this with draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be very straight-forward. It appears that the JCA identifier is meant to be "MGF1 with SHA1"; that ought to be explicitly noted. The XMLENC reference is arguably incomplete, since "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can probably be addressed by explicitly stating the mask generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 with SHA-256). - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [FORGE] Forge < https://github.com/digitalbazaar/forge > On 5/6/14, 8:00 AM, Brian Campbell wrote: > But you probable did do something very similar to what I did in > jose4j - i.e. just getting a cipher instance with > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"? > > I think that's the right thing to do (and JWA even implies it) but > a check from a different language/platform would help verify that > assumption. I don't know if maybe more specifics need to be > provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times. > > > On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso > >> wrote: > > hi Brian, > > > On May 6, 2014, at 3:29 PM, Brian Campbell > >> > wrote: > >> From the venerable film Animal House, of course, >> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI >> >> Thanks for checking that Antonio. >> >> Hopefully we could get a non Java based implementing to verify it >> too. > > just for completeness I did *not* use jose4j to verify it=85 (just > to be safe) > > regards > > antonio > >> >> >> >> >> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso >> >> wrote: >> >> Well, as of this moment, they're on DOUBLE SECRET PROBATION! >> >> On May 6, 2014, at 11:34 AM, Antonio Sanso >> >> wrote: >> >>> Hi Brian, >>> >>> I will give a try and let you know >>> >>> regards >>> >>> antonio >>> >>> On May 6, 2014, at 5:40 AM, Brian Campbell >>> >>> >>= wrote: >>> >>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg >>>> for key encryption but, AFAIK, there are no examples using >>>> it. I recently added support for it to >>>> https://bitbucket.org/b_c/jose4j and am looking to get some >>>> kind of confirmation that I've done it correctly (other than >>>> self interop). With that in mind, here is a JWE using >>>> RSA-OAEP-256 which I've produced and I'm hopeful that someone >>>> on this WG list will be able to decrypt. The RSA key that was >>>> used (in JWK format with both public and private parts) is >>>> below the JWE. >>>> >>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2H= jtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36t= eyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE= 3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJM= RKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0= W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3n= OJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrf= eCGnhWT9qyuUSSA >>>> >>>> >>>> {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx 0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxF= v4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC= 00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8x= pIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8M= sk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ= 3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqB= Qda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN= 1AOrSRCmE3nwxg"} >>>> _______________________________________________ jose mailing >>>> list jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose >>> >> >> >> >> >> -- Ping Identity logo Brian >> Campbell Portfolio Architect @ bcampbell@pingidentity.com >> > p= hone +1 720.317.2061 >> Connect with us=85 twitter logo >> youtube logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> slideshare >> logo flipboard logo >> rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=9623 July, 2014 | Monterey, CA >> >> >> > > > _______________________________________________ jose mailing list > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > -- Ping Identity logo Brian > Campbell Portfolio Architect @ bcampbell@pingidentity.com > > ph= one +1 720.317.2061 Connect > with us=85 twitter logo youtube > logo LinkedIn logo > Facebook logo > Google+ logo > slideshare > logo flipboard logo > rss feed icon > > > Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=9623 July, 2014 | Monterey, CA > > > > > > _______________________________________________ jose mailing list > jose@ietf.org https://www.ietf.org/mailman/listinfo= /jose > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI 6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D =3DO9Ex -----END PGP SIGNATURE----- --_000_4E1F6AAD24975D4BA5B16804296739439A1ABC21TK5EX14MBXC288r_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
What new para= meter values did you use?

From: Brian Campbell
Sent: =FD5/= =FD6/=FD2014 9:54 PM
To: Matt Miller
Cc: Antonio Sanso; jose@ietf.org
Subject: Re: [= jose] RSA-OAEP-256 Example

Thanks Matt.

That is why I was looking for someone to verify using a different platform.= Though I was hoping it'd just work.

Matt, can you try decrypting this one by chance? Using the same key. I was = more explicit with the parameters and, I think, MGF1 should be using SHA-25= 6 now too.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9= _ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYe= PXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2K= ZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3Gq= SPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCm= BOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExC= fE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM= -08tIZ-h5w


On Tue, May 6, 2014 at 8:39 PM, Matt Miller <mamille2@cisco.= com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Short answer:
You are all equally broken -- except from a certain point of view d-:

Long answer:
The code I have is based on OpenSSL, which is hard-coded to use SHA1
for the hash and mask generation (boo!), which means one has to
implement OAEP-SHA256 from scratch (hiss!!).

When I implemented it per RFC 3447 and
draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
decrypt the provided results.  When I hard-coded MGF1 to use "SHA= 1", I
could decrypt provided results.  A search through BouncyCastle's code<= br> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1"= ;.
Further evidence is shown with how [FORGE] can be made to work with
Java (search their homepage for "Compatible with Java's
RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

Reconciling all of this with
draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be
very straight-forward.  It appears that the JCA identifier is meant to=
be "MGF1 with SHA1"; that ought to be explicitly noted.  The= XMLENC
reference is arguably incomplete, since
"http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
"http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this= can
probably be addressed by explicitly stating the mask generation
function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 = with
SHA-256).


- --
- - m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.

[FORGE] Forge < https://github.com/digitalbazaar/forge >

On 5/6/14, 8:00 AM, Brian Campbell wrote:
> But you probable did do something very similar to what I did in
> jose4j - i.e. just getting a cipher instance with
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"?
>
> I think that's the right thing to do (and JWA even implies it) but
> a check from a different language/platform would help verify that
> assumption. I don't know if maybe more specifics need to be
> provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times.
>
>
> On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <asanso@adobe.com
> <mailto:= asanso@adobe.com>> wrote:
>
> hi Brian,
>
>
> On May 6, 2014, at 3:29 PM, Brian Campbell
> <bc= ampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>>
> wrote:
>
>> From the venerable film Animal House, of course,
>> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI
>>
>> Thanks for checking that Antonio.
>>
>> Hopefully we could get a non Java based implementing to verify it<= br> >> too.
>
> just for completeness I did *not* use jose4j to verify it=85 (just
> to be safe)
>
> regards
>
> antonio
>
>>
>>
>>
>>
>> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>> Well, as of this moment, they're on DOUBLE SECRET PROBATION!
>>
>> On May 6, 2014, at 11:34 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>>> Hi Brian,
>>>
>>> I will give a try and let you know
>>>
>>> regards
>>>
>>> antonio
>>>
>>> On May 6, 2014, at 5:40 AM, Brian Campbell
>>> <bcampbell@pingidentity.com
>>> <mailto:bcampbell@pingidentity.com>> wrote:
>>>
>>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE = alg
>>>> for key encryption but, AFAIK, there are no examples using=
>>>> it. I recently added support for it to
>>>> https://bitbucket.org/b_c/jose4j and am looking to get some
>>>> kind of confirmation that I've done it correctly (other th= an
>>>> self interop). With that in mind, here is a JWE using
>>>> RSA-OAEP-256 which I've produced and I'm hopeful that some= one
>>>> on this WG list will be able to decrypt. The RSA key that = was
>>>> used (in JWK format with both public and private parts) is=
>>>> below the JWE.
>>>>
>>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In= 0.Oyeg4hbq2HjtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4Q= wYJeZkjJK36teyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3= u_qCaSLXpegE3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSS= UwuFw-vxrVJMRKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8= ck_mhtJdgfc0W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vU= EdKkuhPR0h3nOJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_= CSzw.UmNlvrfeCGnhWT9qyuUSSA
>>>>
>>>>
>>>>
{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx
0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVD= kej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXR= YOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":&q= uot;MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiN= K8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4= yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAO= QKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7i= Xj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg&= quot;}
>>>> _______________________________________________ jose maili= ng
>>>> list jo= se@ietf.org <mailto:jose@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>>
>>
>>
>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>> Campbell Portfolio Architect @       bcampbell@pingidentity.com
>> <mailto:bcampbell@pingidentity.com> phone    +1= 720.317.2061
>> <tel:%2B1%20720.317.2061> Connect with us=85 twitter logo >> <https://twitter.com/pingidentity> youtube logo
>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn lo= go
>> <https://www.linkedin.com/company/21870> Facebook logo
>> <https://www.facebook.com/pingidentitypage> Google+ l= ogo
>> <https://plus.google.com/u/0/114266977739397708540>= slideshare
>> logo <http://www.slideshare.net/PingIdentity> flipboard logo >> <http://flip= .it/vjBF7> rss feed icon
>> <https://www.pingidentity.com/blogs/>
>>
>> Register for Cloud Identity Summit 2014 | Modern Identity
>> Revolution | 19=9623 July, 2014 | Monterey, CA
>> <https://www.cloudidentitysummit.com/>
>>
>>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org &= lt;mailto:jose@ietf.org<= /a>>
>
https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
> -- Ping Identity logo <https://www.pingidentity.com/> Brian
> Campbell Portfolio Architect @        bcampbell@pingiden= tity.com
> <mailto:bcampbell@pingidentity.com> phone     +1 720.317.2061 Connect
> with us=85 twitter logo <https://twitter.com/pingidentity> youtube
> logo <https://www.youtube.com/user/PingIdentityTV> LinkedIn l= ogo
> <https://www.linkedin.com/company/21870> Facebook logo
> <https://www.facebook.com/pingidentitypage> Google+ logo > <https://plus.google.com/u/0/114266977739397708540> sli= deshare
> logo <http://www.slideshare.net/PingIdentity> flipboard logo
> <http://flip.it/= vjBF7> rss feed icon
> <= https://www.pingidentity.com/blogs/>
>
> Register for Cloud Identity Summit 2014 | Modern Identity
> Revolution | 19=9623 July, 2014 | Monterey, CA
> <https://www.cloudidentitysummit.com/>
>
>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/jose" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/jose
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad
CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI
6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn
LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX
QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG
xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D
=3DO9Ex
-----END PGP SIGNATURE-----

--_000_4E1F6AAD24975D4BA5B16804296739439A1ABC21TK5EX14MBXC288r_-- From nobody Wed May 7 01:30:35 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163CF1A026F for ; Wed, 7 May 2014 01:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.155 X-Spam-Level: * X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZYljqJG7rbc for ; Wed, 7 May 2014 01:30:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 64D071A0186 for ; Wed, 7 May 2014 01:30:29 -0700 (PDT) Received: from CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) by CO1PR02MB046.namprd02.prod.outlook.com (10.242.163.22) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 7 May 2014 08:30:23 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 08:30:22 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0934.000; Wed, 7 May 2014 08:30:22 +0000 From: Antonio Sanso To: Brian Campbell Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUAgABAhACAAAElAIAAAQQAgAAHpICAAOTKgIAAFNOAgAA8gQA= Date: Wed, 7 May 2014 08:30:21 +0000 Message-ID: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.147.117.11] x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(69234005)(52604005)(51704005)(24454002)(377454003)(479174003)(51444003)(189002)(199002)(86362001)(85852003)(92566001)(15975445006)(83072002)(33656001)(19580395003)(87936001)(4396001)(2656002)(101416001)(19580405001)(575784001)(79102001)(16236675002)(83322001)(15395725003)(82746002)(21056001)(20776003)(76176999)(83716003)(92726001)(54356999)(99396002)(81342001)(80022001)(74662001)(66066001)(76482001)(15198665003)(36756003)(31966008)(77982001)(50986999)(99286001)(64706001)(15202345003)(81542001)(74502001)(46102001)(9984715005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_FEA60D7AA3EA4B7A8F656C2E363A208Cadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/WIwGRVbmK3K0m_UFy_vYkwTHFyA Cc: "jose@ietf.org" , Matt Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 08:30:34 -0000 --_000_FEA60D7AA3EA4B7A8F656C2E363A208Cadobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Brian, just FYI, it looks you have used bouncy castle to produce the new JWE (plea= se correct me if I am wrong). Using the default Java provider gives indeed javax.crypto.BadPaddingException: java.security.DigestException: Length mus= t be at least 32 for SHA-256digests as per [0]. The issue will disappear if the key is decrypted using BouncyCastle and giv= es the same result as the previous JWE regards antonio [0] https://bugs.openjdk.java.net/browse/JDK-7038158 On May 7, 2014, at 6:53 AM, Brian Campbell > wrote: Thanks Matt. That is why I was looking for someone to verify using a different platform.= Though I was hoping it'd just work. Matt, can you try decrypting this one by chance? Using the same key. I was = more explicit with the parameters and, I think, MGF1 should be using SHA-25= 6 now too. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9= _ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYe= PXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2K= ZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3Gq= SPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCm= BOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExC= fE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM= -08tIZ-h5w On Tue, May 6, 2014 at 8:39 PM, Matt Miller > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Short answer: You are all equally broken -- except from a certain point of view d-: Long answer: The code I have is based on OpenSSL, which is hard-coded to use SHA1 for the hash and mask generation (boo!), which means one has to implement OAEP-SHA256 from scratch (hiss!!). When I implemented it per RFC 3447 and draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I could decrypt provided results. A search through BouncyCastle's code shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further evidence is shown with how [FORGE] can be made to work with Java (search their homepage for "Compatible with Java's RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). Reconciling all of this with draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be very straight-forward. It appears that the JCA identifier is meant to be "MGF1 with SHA1"; that ought to be explicitly noted. The XMLENC reference is arguably incomplete, since "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can probably be addressed by explicitly stating the mask generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 with SHA-256). - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [FORGE] Forge < https://github.com/digitalbazaar/forge > On 5/6/14, 8:00 AM, Brian Campbell wrote: > But you probable did do something very similar to what I did in > jose4j - i.e. just getting a cipher instance with > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"? > > I think that's the right thing to do (and JWA even implies it) but > a check from a different language/platform would help verify that > assumption. I don't know if maybe more specifics need to be > provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times. > > > On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso > >> wrote: > > hi Brian, > > > On May 6, 2014, at 3:29 PM, Brian Campbell > >> > wrote: > >> From the venerable film Animal House, of course, >> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI >> >> Thanks for checking that Antonio. >> >> Hopefully we could get a non Java based implementing to verify it >> too. > > just for completeness I did *not* use jose4j to verify it=85 (just > to be safe) > > regards > > antonio > >> >> >> >> >> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso >> >> wrote: >> >> Well, as of this moment, they're on DOUBLE SECRET PROBATION! >> >> On May 6, 2014, at 11:34 AM, Antonio Sanso >> >> wrote: >> >>> Hi Brian, >>> >>> I will give a try and let you know >>> >>> regards >>> >>> antonio >>> >>> On May 6, 2014, at 5:40 AM, Brian Campbell >>> >>> >>= wrote: >>> >>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg >>>> for key encryption but, AFAIK, there are no examples using >>>> it. I recently added support for it to >>>> https://bitbucket.org/b_c/jose4j and am looking to get some >>>> kind of confirmation that I've done it correctly (other than >>>> self interop). With that in mind, here is a JWE using >>>> RSA-OAEP-256 which I've produced and I'm hopeful that someone >>>> on this WG list will be able to decrypt. The RSA key that was >>>> used (in JWK format with both public and private parts) is >>>> below the JWE. >>>> >>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2H= jtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36t= eyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE= 3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJM= RKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0= W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3n= OJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrf= eCGnhWT9qyuUSSA >>>> >>>> >>>> {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx 0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxF= v4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC= 00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8x= pIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8M= sk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ= 3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqB= Qda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN= 1AOrSRCmE3nwxg"} >>>> _______________________________________________ jose mailing >>>> list jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose >>> >> >> >> >> >> -- Ping Identity logo Brian >> Campbell Portfolio Architect @ bcampbell@pingidentity.com >> > p= hone +1 720.317.2061 >> Connect with us=85 twitter logo >> youtube logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> slideshare >> logo flipboard logo >> rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=9623 July, 2014 | Monterey, CA >> >> >> > > > _______________________________________________ jose mailing list > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > -- Ping Identity logo Brian > Campbell Portfolio Architect @ bcampbell@pingidentity.com > > ph= one +1 720.317.2061 Connect > with us=85 twitter logo youtube > logo LinkedIn logo > Facebook logo > Google+ logo > slideshare > logo flipboard logo > rss feed icon > > > Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=9623 July, 2014 | Monterey, CA > > > > > > _______________________________________________ jose mailing list > jose@ietf.org https://www.ietf.org/mailman/listinfo= /jose > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI 6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D =3DO9Ex -----END PGP SIGNATURE----- --_000_FEA60D7AA3EA4B7A8F656C2E363A208Cadobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2DB9D24E24BF224EBEA05B7C2C4211CF@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Brian,

just FYI, it looks you have used bouncy castle to produce the new JWE = (please correct me if I am wrong).

Using the default Java provider gives indeed 

javax.crypto.BadPaddingException: java.security.DigestException: Lengt= h must be at least 32 for SHA-256digests 

as per [0].

The issue will disappear if the key is decrypted using BouncyCastle an= d gives the same result as the previous JWE

regards

antonio


On May 7, 2014, at 6:53 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Matt.

That is why I was looking for someone to verify using a different platform.= Though I was hoping it'd just work.

Matt, can you try decrypting this one by chance? Using the same key. I was = more explicit with the parameters and, I think, MGF1 should be using SHA-25= 6 now too.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9= _ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYe= PXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2K= ZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3Gq= SPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCm= BOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExC= fE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM= -08tIZ-h5w


On Tue, May 6, 2014 at 8:39 PM, Matt Miller <mamille2@cisco.= com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Short answer:
You are all equally broken -- except from a certain point of view d-:

Long answer:
The code I have is based on OpenSSL, which is hard-coded to use SHA1
for the hash and mask generation (boo!), which means one has to
implement OAEP-SHA256 from scratch (hiss!!).

When I implemented it per RFC 3447 and
draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
decrypt the provided results.  When I hard-coded MGF1 to use "SHA= 1", I
could decrypt provided results.  A search through BouncyCastle's code<= br> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1"= ;.
Further evidence is shown with how [FORGE] can be made to work with
Java (search their homepage for "Compatible with Java's
RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

Reconciling all of this with
draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be
very straight-forward.  It appears that the JCA identifier is meant to=
be "MGF1 with SHA1"; that ought to be explicitly noted.  The= XMLENC
reference is arguably incomplete, since
"http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
"http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this= can
probably be addressed by explicitly stating the mask generation
function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 = with
SHA-256).


- --
- - m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.

[FORGE] Forge < https://github.com/digitalbazaar/forge >

On 5/6/14, 8:00 AM, Brian Campbell wrote:
> But you probable did do something very similar to what I did in
> jose4j - i.e. just getting a cipher instance with
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"?
>
> I think that's the right thing to do (and JWA even implies it) but
> a check from a different language/platform would help verify that
> assumption. I don't know if maybe more specifics need to be
> provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times.
>
>
> On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <asanso@adobe.com
> <mailto:= asanso@adobe.com>> wrote:
>
> hi Brian,
>
>
> On May 6, 2014, at 3:29 PM, Brian Campbell
> <bc= ampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>>
> wrote:
>
>> From the venerable film Animal House, of course,
>> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI
>>
>> Thanks for checking that Antonio.
>>
>> Hopefully we could get a non Java based implementing to verify it<= br> >> too.
>
> just for completeness I did *not* use jose4j to verify it=85 (just
> to be safe)
>
> regards
>
> antonio
>
>>
>>
>>
>>
>> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>> Well, as of this moment, they're on DOUBLE SECRET PROBATION!
>>
>> On May 6, 2014, at 11:34 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>>> Hi Brian,
>>>
>>> I will give a try and let you know
>>>
>>> regards
>>>
>>> antonio
>>>
>>> On May 6, 2014, at 5:40 AM, Brian Campbell
>>> <bcampbell@pingidentity.com
>>> <mailto:bcampbell@pingidentity.com>> wrote:
>>>
>>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE = alg
>>>> for key encryption but, AFAIK, there are no examples using=
>>>> it. I recently added support for it to
>>>> https://bitbucket.org/b_c/jose4j and am looking to get some
>>>> kind of confirmation that I've done it correctly (other th= an
>>>> self interop). With that in mind, here is a JWE using
>>>> RSA-OAEP-256 which I've produced and I'm hopeful that some= one
>>>> on this WG list will be able to decrypt. The RSA key that = was
>>>> used (in JWK format with both public and private parts) is=
>>>> below the JWE.
>>>>
>>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In= 0.Oyeg4hbq2HjtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4Q= wYJeZkjJK36teyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3= u_qCaSLXpegE3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSS= UwuFw-vxrVJMRKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8= ck_mhtJdgfc0W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vU= EdKkuhPR0h3nOJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_= CSzw.UmNlvrfeCGnhWT9qyuUSSA
>>>>
>>>>
>>>>
{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx
0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVD= kej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXR= YOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":&q= uot;MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiN= K8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4= yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAO= QKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7i= Xj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg&= quot;}
>>>> _______________________________________________ jose maili= ng
>>>> list jo= se@ietf.org <mailto:jose@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>>
>>
>>
>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>> Campbell Portfolio Architect @       bcampbell@pingidentity.com
>> <mailto:bcampbell@pingidentity.com> phone    +1= 720.317.2061
>> <tel:%2B1%20720.317.2061> Connect with us=85 twitter logo >> <https://twitter.com/pingidentity> youtube logo
>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn lo= go
>> <https://www.linkedin.com/company/21870> Facebook logo
>> <https://www.facebook.com/pingidentitypage> Google+ l= ogo
>> <https://plus.google.com/u/0/114266977739397708540>= slideshare
>> logo <http://www.slideshare.net/PingIdentity> flipboard logo >> <http://flip= .it/vjBF7> rss feed icon
>> <https://www.pingidentity.com/blogs/>
>>
>> Register for Cloud Identity Summit 2014 | Modern Identity
>> Revolution | 19=9623 July, 2014 | Monterey, CA
>> <https://www.cloudidentitysummit.com/>
>>
>>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org &= lt;mailto:jose@ietf.org<= /a>>
>
https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
> -- Ping Identity logo <https://www.pingidentity.com/> Brian
> Campbell Portfolio Architect @        bcampbell@pingiden= tity.com
> <mailto:bcampbell@pingidentity.com> phone     +1 720.317.2061 Connect
> with us=85 twitter logo <https://twitter.com/pingidentity> youtube
> logo <https://www.youtube.com/user/PingIdentityTV> LinkedIn l= ogo
> <https://www.linkedin.com/company/21870> Facebook logo
> <https://www.facebook.com/pingidentitypage> Google+ logo > <https://plus.google.com/u/0/114266977739397708540> sli= deshare
> logo <http://www.slideshare.net/PingIdentity> flipboard logo
> <http://flip.it/= vjBF7> rss feed icon
> <= https://www.pingidentity.com/blogs/>
>
> Register for Cloud Identity Summit 2014 | Modern Identity
> Revolution | 19=9623 July, 2014 | Monterey, CA
> <https://www.cloudidentitysummit.com/>
>
>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/jose" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/jose
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - htt= ps://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad
CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI
6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn
LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX
QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG
xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D
=3DO9Ex
-----END PGP SIGNATURE-----


--_000_FEA60D7AA3EA4B7A8F656C2E363A208Cadobecom_-- From nobody Wed May 7 01:31:31 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF71D1A026F for ; Wed, 7 May 2014 01:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.155 X-Spam-Level: * X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtTYouY7gqMq for ; Wed, 7 May 2014 01:31:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id D1FD41A0186 for ; Wed, 7 May 2014 01:31:26 -0700 (PDT) Received: from CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) by CO1PR02MB189.namprd02.prod.outlook.com (10.242.165.12) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 08:31:21 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 08:31:19 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0934.000; Wed, 7 May 2014 08:31:18 +0000 From: Antonio Sanso To: Mike Jones Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUAgABAhACAAAElAIAAAQQAgAAHpICAAOTKgIAAFNOAgAADxoCAADj+AA== Date: Wed, 7 May 2014 08:31:17 +0000 Message-ID: <2D3ECD6F-3A83-4100-9B3B-9B01A1A2D852@adobe.com> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com>, <4E1F6AAD24975D4BA5B16804296739439A1ABC21@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A1ABC21@TK5EX14MBXC288.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.147.117.11] x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(52604005)(51704005)(24454002)(377454003)(479174003)(51444003)(189002)(199002)(86362001)(85852003)(92566001)(15975445006)(83072002)(33656001)(19580395003)(87936001)(4396001)(2656002)(101416001)(19580405001)(575784001)(79102001)(16236675002)(83322001)(15395725003)(82746002)(21056001)(20776003)(76176999)(83716003)(92726001)(54356999)(99396002)(81342001)(80022001)(74662001)(66066001)(76482001)(15198665003)(1511001)(36756003)(31966008)(77982001)(50986999)(99286001)(64706001)(15202345003)(81542001)(74502001)(46102001)(9984715005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_2D3ECD6F3A8341009B3B9B01A1A2D852adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/RZHDdCnMbHewUXvc9U1DW7EiQLM Cc: Brian Campbell , "jose@ietf.org" , Matt Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 08:31:30 -0000 --_000_2D3ECD6F3A8341009B3B9B01A1A2D852adobecom_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable hi Mike On May 7, 2014, at 7:07 AM, Mike Jones > wrote: What new parameter values did you use? assuming Brian is using Java IMHO he used AlgorithmParameterSpec paramSpec =3D new OAEPParameterSpec("SHA-256", "MGF= 1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); regards antonio ________________________________ From: Brian Campbell Sent: =FD5/=FD6/=FD2014 9:54 PM To: Matt Miller Cc: Antonio Sanso; jose@ietf.org Subject: Re: [jose] RSA-OAEP-256 Example Thanks Matt. That is why I was looking for someone to verify using a different platform.= Though I was hoping it'd just work. Matt, can you try decrypting this one by chance? Using the same key. I was = more explicit with the parameters and, I think, MGF1 should be using SHA-25= 6 now too. eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9= _ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYe= PXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2K= ZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3Gq= SPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCm= BOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExC= fE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM= -08tIZ-h5w On Tue, May 6, 2014 at 8:39 PM, Matt Miller > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Short answer: You are all equally broken -- except from a certain point of view d-: Long answer: The code I have is based on OpenSSL, which is hard-coded to use SHA1 for the hash and mask generation (boo!), which means one has to implement OAEP-SHA256 from scratch (hiss!!). When I implemented it per RFC 3447 and draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I could decrypt provided results. A search through BouncyCastle's code shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further evidence is shown with how [FORGE] can be made to work with Java (search their homepage for "Compatible with Java's RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). Reconciling all of this with draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be very straight-forward. It appears that the JCA identifier is meant to be "MGF1 with SHA1"; that ought to be explicitly noted. The XMLENC reference is arguably incomplete, since "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can probably be addressed by explicitly stating the mask generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 with SHA-256). - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [FORGE] Forge < https://github.com/digitalbazaar/forge > On 5/6/14, 8:00 AM, Brian Campbell wrote: > But you probable did do something very similar to what I did in > jose4j - i.e. just getting a cipher instance with > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"? > > I think that's the right thing to do (and JWA even implies it) but > a check from a different language/platform would help verify that > assumption. I don't know if maybe more specifics need to be > provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times. > > > On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso > >> wrote: > > hi Brian, > > > On May 6, 2014, at 3:29 PM, Brian Campbell > >> > wrote: > >> From the venerable film Animal House, of course, >> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI >> >> Thanks for checking that Antonio. >> >> Hopefully we could get a non Java based implementing to verify it >> too. > > just for completeness I did *not* use jose4j to verify it=85 (just > to be safe) > > regards > > antonio > >> >> >> >> >> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso >> >> wrote: >> >> Well, as of this moment, they're on DOUBLE SECRET PROBATION! >> >> On May 6, 2014, at 11:34 AM, Antonio Sanso >> >> wrote: >> >>> Hi Brian, >>> >>> I will give a try and let you know >>> >>> regards >>> >>> antonio >>> >>> On May 6, 2014, at 5:40 AM, Brian Campbell >>> >>> >>= wrote: >>> >>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg >>>> for key encryption but, AFAIK, there are no examples using >>>> it. I recently added support for it to >>>> https://bitbucket.org/b_c/jose4j and am looking to get some >>>> kind of confirmation that I've done it correctly (other than >>>> self interop). With that in mind, here is a JWE using >>>> RSA-OAEP-256 which I've produced and I'm hopeful that someone >>>> on this WG list will be able to decrypt. The RSA key that was >>>> used (in JWK format with both public and private parts) is >>>> below the JWE. >>>> >>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2H= jtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36t= eyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE= 3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJM= RKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0= W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3n= OJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrf= eCGnhWT9qyuUSSA >>>> >>>> >>>> {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ= 8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXz= uJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9by= cvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkS= XQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d= ":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgK= nXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82E= sQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U",= "q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVF= ykDLwJ30GepLQ8nTlzeV6clx 0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxF= v4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC= 00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8x= pIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8M= sk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ= 3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqB= Qda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN= 1AOrSRCmE3nwxg"} >>>> _______________________________________________ jose mailing >>>> list jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose >>> >> >> >> >> >> -- Ping Identity logo Brian >> Campbell Portfolio Architect @ bcampbell@pingidentity.com >> > p= hone +1 720.317.2061 >> Connect with us=85 twitter logo >> youtube logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> slideshare >> logo flipboard logo >> rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=9623 July, 2014 | Monterey, CA >> >> >> > > > _______________________________________________ jose mailing list > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > -- Ping Identity logo Brian > Campbell Portfolio Architect @ bcampbell@pingidentity.com > > ph= one +1 720.317.2061 Connect > with us=85 twitter logo youtube > logo LinkedIn logo > Facebook logo > Google+ logo > slideshare > logo flipboard logo > rss feed icon > > > Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=9623 July, 2014 | Monterey, CA > > > > > > _______________________________________________ jose mailing list > jose@ietf.org https://www.ietf.org/mailman/listinfo= /jose > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI 6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D =3DO9Ex -----END PGP SIGNATURE----- --_000_2D3ECD6F3A8341009B3B9B01A1A2D852adobecom_ Content-Type: text/html; charset="windows-1256" Content-ID: <43650C14D0BF0E4CB861D86F1FD5CC3C@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi Mike
On May 7, 2014, at 7:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

What new para= meter values did you use?

assuming Brian is using Java IMHO he used

 Alg= orithmParameterSpec paramSpec =3D new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.<= span style=3D"color: #0326cc">SHA256,
  &n= bsp;             PSource.PSpecified.DEFAULT);

regards

antonio


From: Brian Campbell
Sent: =FD5/= =FD6/=FD2014 9:54 PM
To: Matt Miller
Cc: Antonio Sanso; jose@ietf.org
Subject: Re: [= jose] RSA-OAEP-256 Example

Thanks Matt.

That is why I was looking for someone to verify using a different platform.= Though I was hoping it'd just work.

Matt, can you try decrypting this one by chance? Using the same key. I was = more explicit with the parameters and, I think, MGF1 should be using SHA-25= 6 now too.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9= _ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYe= PXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2K= ZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3Gq= SPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCm= BOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExC= fE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM= -08tIZ-h5w


On Tue, May 6, 2014 at 8:39 PM, Matt Miller <mamille2@cisco.= com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Short answer:
You are all equally broken -- except from a certain point of view d-:

Long answer:
The code I have is based on OpenSSL, which is hard-coded to use SHA1
for the hash and mask generation (boo!), which means one has to
implement OAEP-SHA256 from scratch (hiss!!).

When I implemented it per RFC 3447 and
draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
decrypt the provided results.  When I hard-coded MGF1 to use "SHA= 1", I
could decrypt provided results.  A search through BouncyCastle's code<= br> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1"= ;.
Further evidence is shown with how [FORGE] can be made to work with
Java (search their homepage for "Compatible with Java's
RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

Reconciling all of this with
draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be
very straight-forward.  It appears that the JCA identifier is meant to=
be "MGF1 with SHA1"; that ought to be explicitly noted.  The= XMLENC
reference is arguably incomplete, since
"http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
"http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this= can
probably be addressed by explicitly stating the mask generation
function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 = with
SHA-256).


- --
- - m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.

[FORGE] Forge < https://github.com/digitalbazaar/forge >

On 5/6/14, 8:00 AM, Brian Campbell wrote:
> But you probable did do something very similar to what I did in
> jose4j - i.e. just getting a cipher instance with
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"?
>
> I think that's the right thing to do (and JWA even implies it) but
> a check from a different language/platform would help verify that
> assumption. I don't know if maybe more specifics need to be
> provided to the cipher via OAEPParameterSpec or something - the JCA > APIs can be a bit mysterious at times.
>
>
> On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <asanso@adobe.com
> <mailto:= asanso@adobe.com>> wrote:
>
> hi Brian,
>
>
> On May 6, 2014, at 3:29 PM, Brian Campbell
> <bc= ampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>>
> wrote:
>
>> From the venerable film Animal House, of course,
>> https://www.youtube.com/watch?v=3DvVXEQ8hjyGI
>>
>> Thanks for checking that Antonio.
>>
>> Hopefully we could get a non Java based implementing to verify it<= br> >> too.
>
> just for completeness I did *not* use jose4j to verify it=85 (just
> to be safe)
>
> regards
>
> antonio
>
>>
>>
>>
>>
>> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>> Well, as of this moment, they're on DOUBLE SECRET PROBATION!
>>
>> On May 6, 2014, at 11:34 AM, Antonio Sanso <asanso@adobe.com
>> <mailto:asanso@adobe.com>> wrote:
>>
>>> Hi Brian,
>>>
>>> I will give a try and let you know
>>>
>>> regards
>>>
>>> antonio
>>>
>>> On May 6, 2014, at 5:40 AM, Brian Campbell
>>> <bcampbell@pingidentity.com
>>> <mailto:bcampbell@pingidentity.com>> wrote:
>>>
>>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE = alg
>>>> for key encryption but, AFAIK, there are no examples using=
>>>> it. I recently added support for it to
>>>> https://bitbucket.org/b_c/jose4j and am looking to get some
>>>> kind of confirmation that I've done it correctly (other th= an
>>>> self interop). With that in mind, here is a JWE using
>>>> RSA-OAEP-256 which I've produced and I'm hopeful that some= one
>>>> on this WG list will be able to decrypt. The RSA key that = was
>>>> used (in JWK format with both public and private parts) is=
>>>> below the JWE.
>>>>
>>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In= 0.Oyeg4hbq2HjtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4Q= wYJeZkjJK36teyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3= u_qCaSLXpegE3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSS= UwuFw-vxrVJMRKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8= ck_mhtJdgfc0W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vU= EdKkuhPR0h3nOJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_= CSzw.UmNlvrfeCGnhWT9qyuUSSA
>>>>
>>>>
>>>>
{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn= 4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbd= SIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjH= wjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29= v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4= kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":&qu= ot;dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMn= D5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAH= XZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYK= YZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk= -sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQ= mgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9= ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsT= MHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5= W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx
0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsX= XM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVD= kej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXR= YOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":&q= uot;MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiN= K8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4= yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAO= QKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7i= Xj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg&= quot;}
>>>> _______________________________________________ jose maili= ng
>>>> list jo= se@ietf.org <mailto:jose@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>>
>>
>>
>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>> Campbell Portfolio Architect @       bcampbell@pingidentity.com
>> <mailto:bcampbell@pingidentity.com> phone    +1= 720.317.2061
>> <tel:%2B1%20720.317.2061> Connect with us=85 twitter logo >> <https://twitter.com/pingidentity> youtube logo
>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn lo= go
>> <https://www.linkedin.com/company/21870> Facebook logo
>> <https://www.facebook.com/pingidentitypage> Google+ l= ogo
>> <https://plus.google.com/u/0/114266977739397708540>= slideshare
>> logo <http://www.slideshare.net/PingIdentity> flipboard logo >> <http://flip= .it/vjBF7> rss feed icon
>> <https://www.pingidentity.com/blogs/>
>>
>> Register for Cloud Identity Summit 2014 | Modern Identity
>> Revolution | 19=9623 July, 2014 | Monterey, CA
>> <https://www.cloudidentitysummit.com/>
>>
>>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org &= lt;mailto:jose@ietf.org<= /a>>
>
https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
> -- Ping Identity logo <https://www.pingidentity.com/> Brian
> Campbell Portfolio Architect @        bcampbell@pingiden= tity.com
> <mailto:bcampbell@pingidentity.com> phone     +1 720.317.2061 Connect
> with us=85 twitter logo <https://twitter.com/pingidentity> youtube
> logo <https://www.youtube.com/user/PingIdentityTV> LinkedIn l= ogo
> <https://www.linkedin.com/company/21870> Facebook logo
> <https://www.facebook.com/pingidentitypage> Google+ logo > <https://plus.google.com/u/0/114266977739397708540> sli= deshare
> logo <http://www.slideshare.net/PingIdentity> flipboard logo
> <http://flip.it/= vjBF7> rss feed icon
> <= https://www.pingidentity.com/blogs/>
>
> Register for Cloud Identity Summit 2014 | Modern Identity
> Revolution | 19=9623 July, 2014 | Monterey, CA
> <https://www.cloudidentitysummit.com/>
>
>
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/jose" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/jose
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - htt= ps://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad
CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI
6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn
LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX
QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG
xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=3D
=3DO9Ex
-----END PGP SIGNATURE-----


--_000_2D3ECD6F3A8341009B3B9B01A1A2D852adobecom_-- From nobody Wed May 7 02:38:16 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3181A03D1 for ; Wed, 7 May 2014 02:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKKg_RWtDoYv for ; Wed, 7 May 2014 02:38:11 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 53A651A0299 for ; Wed, 7 May 2014 02:38:10 -0700 (PDT) X-Mailbb-Crypt: true Received: from he111467.emea1.cds.t-internal.com (HELO he111467) ([10.206.92.85]) by tcmail91.telekom.de with ESMTP/TLS/RC4-MD5; 07 May 2014 10:52:38 +0200 Received: from TCMAIL91.dmznet.de.t-internal.com ([10.206.242.136]) by he111467 (Totemo SMTP Server) with SMTP ID 887; Wed, 7 May 2014 10:52:35 +0200 (CEST) X-Mailbb-Crypt: true X-Mailbb-SentCrypt: true Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 07 May 2014 10:21:44 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Wed, 7 May 2014 10:21:26 +0200 From: To: , Date: Wed, 7 May 2014 10:21:22 +0200 Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: Ac9psG1x5TvC9zvTQM6tiBbEdtgDdwAHIyog Message-ID: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> In-Reply-To: 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_CE8995AB5D178F44A2154F5C9A97CAF402631C603A59HE111541eme_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/vnBHP5ePd7maQ7S544S84GiFF9U Cc: asanso@adobe.com, jose@ietf.org Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 09:38:15 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C603A59HE111541eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHRoZSBqYXZhIGltcGxlbWVudGF0aW9ucyBpbXBsZW1lbnRlZCB0aGUgc3Bl YyBhbmQgZXZlcnl0aGluZyBpcyBvayBmcm9tIHRoYXQgUE9WLg0KDQpUaGVzZSBpbXBsZW1lbnRh dGlvbnMgYXJlIG5vdCBicm9rZW4uDQoNCg0KDQpPbmUgY291bGQgYXJndWUgdGhhdCB3aGVuIHdl IHJlcGxhY2UgU0hBLTEgYnkgU0hBLTI1NiBpbiBvbmUgcGxhY2UgdGhlbiB3ZSBtaWdodCBjb25z aWRlciB0byByZXBsYWNlIGl0IGluIHRoZSBwYWRkaW5nIHRvby4NCg0KTXkgZmVlbGluZyBpcyB0 aGF0IHVzaW5nIHNoYS0yNTYgZm9yIHRoZSBwYWRkaW5nIGRvZXMgbm90IGdpdmUgdXMgbW9yZSBz ZWN1cml0eS4gWU1NVw0KDQoNCkZyb206IGpvc2UgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMDcs IDIwMTQgNjo1NCBBTQ0KVG86IE1hdHQgTWlsbGVyDQpDYzogQW50b25pbyBTYW5zbzsgam9zZUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBSU0EtT0FFUC0yNTYgRXhhbXBsZQ0KDQpUaGFu a3MgTWF0dC4NCg0KVGhhdCBpcyB3aHkgSSB3YXMgbG9va2luZyBmb3Igc29tZW9uZSB0byB2ZXJp ZnkgdXNpbmcgYSBkaWZmZXJlbnQgcGxhdGZvcm0uIFRob3VnaCBJIHdhcyBob3BpbmcgaXQnZCBq dXN0IHdvcmsuDQpNYXR0LCBjYW4geW91IHRyeSBkZWNyeXB0aW5nIHRoaXMgb25lIGJ5IGNoYW5j ZT8gVXNpbmcgdGhlIHNhbWUga2V5LiBJIHdhcyBtb3JlIGV4cGxpY2l0IHdpdGggdGhlIHBhcmFt ZXRlcnMgYW5kLCBJIHRoaW5rLCBNR0YxIHNob3VsZCBiZSB1c2luZyBTSEEtMjU2IG5vdyB0b28u DQoNCmV5SmhiR2NpT2lKU1UwRXRUMEZGVUMweU5UWWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRN alUySW4wLmZMNUlMNWNNQ2pqVTlHOV9aanNEMlhPMEhJd1RPd2JWd3VsY1pWdzMxX3J4MnFUY0h6 YlloSXZydmJjVkxUZkp6bjh4YlEzVUVMNDQyWmdaMVBjRllLRU5ZZVBYaUV5dll4UE44ZG12al9P ZkxTSkRFcVI2a3Z3T2I2bmdoR3R4ZnpkQl9WUnZGdDJlZWhiQ0EzZ1dwaU9ZSEh2U1RGZEJQR3gy S1pIUWlzTHozb1pSOEVXaVoxd29FcEh5OGE3Rm9RMnp6dURsWkVKUU9VcmgwOWJfRUp4bWNFMmpM NndtRXRnYWJ5eHkzVmdXZzNHcVNQVUlTbEpaVjlIVGh1VkplenprdEpkcG50UkRuQVBVcWpjOEl3 QnlHcE1sZUlRY1B1QlVzZVJSUHJfT3Nyb09KNmVUbDVEdUZDbUJPS2ItZU5OdzV2LUdFY1ZZcjF3 N1g5b1hvQS4wZnJkSXd4OFA4VUF6aDFzOV9QZ09BLlJBeklMSDB4ZnMweXh6TUwxQ3p6R0V4Q2ZF Ml93eldLczBGVnVYZk04UjVINjh5VHFUYnFJcVJDcDJmZUFINUdTdmx1em16dGsyX0NrR05TakF5 b2F3LjRuTVVYT2dtZ1d2TS0wOHRJWi1oNXcNCg0KT24gVHVlLCBNYXkgNiwgMjAxNCBhdCA4OjM5 IFBNLCBNYXR0IE1pbGxlciA8bWFtaWxsZTJAY2lzY28uY29tPG1haWx0bzptYW1pbGxlMkBjaXNj by5jb20+PiB3cm90ZToNCi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCkhhc2g6 IFNIQTUxMg0KDQpTaG9ydCBhbnN3ZXI6DQpZb3UgYXJlIGFsbCBlcXVhbGx5IGJyb2tlbiAtLSBl eGNlcHQgZnJvbSBhIGNlcnRhaW4gcG9pbnQgb2YgdmlldyBkLToNCg0KTG9uZyBhbnN3ZXI6DQpU aGUgY29kZSBJIGhhdmUgaXMgYmFzZWQgb24gT3BlblNTTCwgd2hpY2ggaXMgaGFyZC1jb2RlZCB0 byB1c2UgU0hBMQ0KZm9yIHRoZSBoYXNoIGFuZCBtYXNrIGdlbmVyYXRpb24gKGJvbyEpLCB3aGlj aCBtZWFucyBvbmUgaGFzIHRvDQppbXBsZW1lbnQgT0FFUC1TSEEyNTYgZnJvbSBzY3JhdGNoICho aXNzISEpLg0KDQpXaGVuIEkgaW1wbGVtZW50ZWQgaXQgcGVyIFJGQyAzNDQ3IGFuZA0KZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMjYjc2VjdGlvbi00LjMsIEkgY291bGQgbm90 DQpkZWNyeXB0IHRoZSBwcm92aWRlZCByZXN1bHRzLiAgV2hlbiBJIGhhcmQtY29kZWQgTUdGMSB0 byB1c2UgIlNIQTEiLCBJDQpjb3VsZCBkZWNyeXB0IHByb3ZpZGVkIHJlc3VsdHMuICBBIHNlYXJj aCB0aHJvdWdoIEJvdW5jeUNhc3RsZSdzIGNvZGUNCnNob3dzIHRoYXQgIlJTQS9FQ0IvT0FFUFdp dGhTSEEtMjU2QW5kTUdGMVBhZGRpbmciIHVzZXMgYSBIYXNoDQpmdW5jdGlvbiBvZiBTSEEtMjU2 IGdlbmVyYXRlIHRoZSBsSGFzaCBidXQgaXRzIE1HRjEgdXNlcyBhICJTSEEtMSIuDQpGdXJ0aGVy IGV2aWRlbmNlIGlzIHNob3duIHdpdGggaG93IFtGT1JHRV0gY2FuIGJlIG1hZGUgdG8gd29yayB3 aXRoDQpKYXZhIChzZWFyY2ggdGhlaXIgaG9tZXBhZ2UgZm9yICJDb21wYXRpYmxlIHdpdGggSmF2 YSdzDQpSU0EvRUNCL09BRVBXaXRoU0hBLTI1NkFuZE1HRjFQYWRkaW5nIikuDQoNClJlY29uY2ls aW5nIGFsbCBvZiB0aGlzIHdpdGgNCmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1z I2FwcGVuZGl4LUEuMiBkb2VzIG5vdCBsb29rIHRvIGJlDQp2ZXJ5IHN0cmFpZ2h0LWZvcndhcmQu ICBJdCBhcHBlYXJzIHRoYXQgdGhlIEpDQSBpZGVudGlmaWVyIGlzIG1lYW50IHRvDQpiZSAiTUdG MSB3aXRoIFNIQTEiOyB0aGF0IG91Z2h0IHRvIGJlIGV4cGxpY2l0bHkgbm90ZWQuICBUaGUgWE1M RU5DDQpyZWZlcmVuY2UgaXMgYXJndWFibHkgaW5jb21wbGV0ZSwgc2luY2UNCiJodHRwOi8vd3d3 LnczLm9yZy8yMDA5L3htbGVuYzExI3JzYS1vYWVwIiBkZWZhdWx0cyB0bw0KImh0dHA6Ly93d3cu dzMub3JnLzIwMDkveG1sZW5jMTEjbWdmMXNoYTEiIChNR0YxIHdpdGggU0hBMSk7IHRoaXMgY2Fu DQpwcm9iYWJseSBiZSBhZGRyZXNzZWQgYnkgZXhwbGljaXRseSBzdGF0aW5nIHRoZSBtYXNrIGdl bmVyYXRpb24NCmZ1bmN0aW9uIGlzICJodHRwOi8vd3d3LnczLm9yZy8yMDA5L3htbGVuYzExI21n ZjFzaGEyNTYiIChNR0YxIHdpdGgNClNIQS0yNTYpLg0KDQoNCi0gLS0NCi0gLSBtJm0NCg0KTWF0 dCBNaWxsZXIgPCBtYW1pbGxlMkBjaXNjby5jb208bWFpbHRvOm1hbWlsbGUyQGNpc2NvLmNvbT4g Pg0KQ2lzY28gU3lzdGVtcywgSW5jLg0KDQpbRk9SR0VdIEZvcmdlIDwgaHR0cHM6Ly9naXRodWIu Y29tL2RpZ2l0YWxiYXphYXIvZm9yZ2UgPg0KDQpPbiA1LzYvMTQsIDg6MDAgQU0sIEJyaWFuIENh bXBiZWxsIHdyb3RlOg0KPiBCdXQgeW91IHByb2JhYmxlIGRpZCBkbyBzb21ldGhpbmcgdmVyeSBz aW1pbGFyIHRvIHdoYXQgSSBkaWQgaW4NCj4gam9zZTRqIC0gaS5lLiBqdXN0IGdldHRpbmcgYSBj aXBoZXIgaW5zdGFuY2Ugd2l0aA0KPiAiUlNBL0VDQi9PQUVQV2l0aFNIQS0yNTZBbmRNR0YxUGFk ZGluZyI/DQo+DQo+IEkgdGhpbmsgdGhhdCdzIHRoZSByaWdodCB0aGluZyB0byBkbyAoYW5kIEpX QSBldmVuIGltcGxpZXMgaXQpIGJ1dA0KPiBhIGNoZWNrIGZyb20gYSBkaWZmZXJlbnQgbGFuZ3Vh Z2UvcGxhdGZvcm0gd291bGQgaGVscCB2ZXJpZnkgdGhhdA0KPiBhc3N1bXB0aW9uLiBJIGRvbid0 IGtub3cgaWYgbWF5YmUgbW9yZSBzcGVjaWZpY3MgbmVlZCB0byBiZQ0KPiBwcm92aWRlZCB0byB0 aGUgY2lwaGVyIHZpYSBPQUVQUGFyYW1ldGVyU3BlYyBvciBzb21ldGhpbmcgLSB0aGUgSkNBDQo+ IEFQSXMgY2FuIGJlIGEgYml0IG15c3RlcmlvdXMgYXQgdGltZXMuDQo+DQo+DQo+IE9uIFR1ZSwg TWF5IDYsIDIwMTQgYXQgNjozMiBBTSwgQW50b25pbyBTYW5zbyA8YXNhbnNvQGFkb2JlLmNvbTxt YWlsdG86YXNhbnNvQGFkb2JlLmNvbT4NCj4gPG1haWx0bzphc2Fuc29AYWRvYmUuY29tPG1haWx0 bzphc2Fuc29AYWRvYmUuY29tPj4+IHdyb3RlOg0KPg0KPiBoaSBCcmlhbiwNCj4NCj4NCj4gT24g TWF5IDYsIDIwMTQsIGF0IDM6MjkgUE0sIEJyaWFuIENhbXBiZWxsDQo+IDxiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+IDxtYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPj4+DQo+IHdyb3RlOg0KPg0KPj4gRnJvbSB0aGUgdmVuZXJhYmxlIGZpbG0gQW5pbWFsIEhv dXNlLCBvZiBjb3Vyc2UsDQo+PiBodHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PXZWWEVR OGhqeUdJDQo+Pg0KPj4gVGhhbmtzIGZvciBjaGVja2luZyB0aGF0IEFudG9uaW8uDQo+Pg0KPj4g SG9wZWZ1bGx5IHdlIGNvdWxkIGdldCBhIG5vbiBKYXZhIGJhc2VkIGltcGxlbWVudGluZyB0byB2 ZXJpZnkgaXQNCj4+IHRvby4NCj4NCj4ganVzdCBmb3IgY29tcGxldGVuZXNzIEkgZGlkICpub3Qq IHVzZSBqb3NlNGogdG8gdmVyaWZ5IGl04oCmIChqdXN0DQo+IHRvIGJlIHNhZmUpDQo+DQo+IHJl Z2FyZHMNCj4NCj4gYW50b25pbw0KPg0KPj4NCj4+DQo+Pg0KPj4NCj4+IE9uIFR1ZSwgTWF5IDYs IDIwMTQgYXQgNjoyNSBBTSwgQW50b25pbyBTYW5zbyA8YXNhbnNvQGFkb2JlLmNvbTxtYWlsdG86 YXNhbnNvQGFkb2JlLmNvbT4NCj4+IDxtYWlsdG86YXNhbnNvQGFkb2JlLmNvbTxtYWlsdG86YXNh bnNvQGFkb2JlLmNvbT4+PiB3cm90ZToNCj4+DQo+PiBXZWxsLCBhcyBvZiB0aGlzIG1vbWVudCwg dGhleSdyZSBvbiBET1VCTEUgU0VDUkVUIFBST0JBVElPTiENCj4+DQo+PiBPbiBNYXkgNiwgMjAx NCwgYXQgMTE6MzQgQU0sIEFudG9uaW8gU2Fuc28gPGFzYW5zb0BhZG9iZS5jb208bWFpbHRvOmFz YW5zb0BhZG9iZS5jb20+DQo+PiA8bWFpbHRvOmFzYW5zb0BhZG9iZS5jb208bWFpbHRvOmFzYW5z b0BhZG9iZS5jb20+Pj4gd3JvdGU6DQo+Pg0KPj4+IEhpIEJyaWFuLA0KPj4+DQo+Pj4gSSB3aWxs IGdpdmUgYSB0cnkgYW5kIGxldCB5b3Uga25vdw0KPj4+DQo+Pj4gcmVnYXJkcw0KPj4+DQo+Pj4g YW50b25pbw0KPj4+DQo+Pj4gT24gTWF5IDYsIDIwMTQsIGF0IDU6NDAgQU0sIEJyaWFuIENhbXBi ZWxsDQo+Pj4gPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbT4NCj4+PiA8bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+PiB3cm90ZToNCj4+Pg0KPj4+PiBUaGUg bGF0ZXN0IHJldmlzaW9uIG9mIEpXQSBhZGRlZCBhIG5ldyAnUlNBLU9BRVAtMjU2JyBKV0UgYWxn DQo+Pj4+IGZvciBrZXkgZW5jcnlwdGlvbiBidXQsIEFGQUlLLCB0aGVyZSBhcmUgbm8gZXhhbXBs ZXMgdXNpbmcNCj4+Pj4gaXQuIEkgcmVjZW50bHkgYWRkZWQgc3VwcG9ydCBmb3IgaXQgdG8NCj4+ Pj4gaHR0cHM6Ly9iaXRidWNrZXQub3JnL2JfYy9qb3NlNGogYW5kIGFtIGxvb2tpbmcgdG8gZ2V0 IHNvbWUNCj4+Pj4ga2luZCBvZiBjb25maXJtYXRpb24gdGhhdCBJJ3ZlIGRvbmUgaXQgY29ycmVj dGx5IChvdGhlciB0aGFuDQo+Pj4+IHNlbGYgaW50ZXJvcCkuIFdpdGggdGhhdCBpbiBtaW5kLCBo ZXJlIGlzIGEgSldFIHVzaW5nDQo+Pj4+IFJTQS1PQUVQLTI1NiB3aGljaCBJJ3ZlIHByb2R1Y2Vk IGFuZCBJJ20gaG9wZWZ1bCB0aGF0IHNvbWVvbmUNCj4+Pj4gb24gdGhpcyBXRyBsaXN0IHdpbGwg YmUgYWJsZSB0byBkZWNyeXB0LiBUaGUgUlNBIGtleSB0aGF0IHdhcw0KPj4+PiB1c2VkIChpbiBK V0sgZm9ybWF0IHdpdGggYm90aCBwdWJsaWMgYW5kIHByaXZhdGUgcGFydHMpIGlzDQo+Pj4+IGJl bG93IHRoZSBKV0UuDQo+Pj4+DQo+Pj4+IGV5SmhiR2NpT2lKU1UwRXRUMEZGVUMweU5UWWlMQ0ps Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wLk95ZWc0aGJxMkhqdEhPY1hkdUs5VWhoSVhlcnZQ ek9UTEFxS3BoQ3llSzU1Y0ZnS3RGMzJEaEQyNnNmbkc2aDlhejNPZ3JuNFF3WUplWmtqSkszNnRl eWpsOW9LSVdfOUl0UDhjWWhPcmlET09aRmhvNTNCc3R0cWo4cGMwVVByTUo0NDh5UXNna2d5cW1m V1pRczN1X3FDYVNMWHBlZ0Uzby1ZSjUyMC1YdV9FbFM1cE55X3ZmU01FMUNlUDV1blBRUGYwNlhj NmlNVld4OS1LXzdseEM3YWNZSV9mU1NVd3VGdy12eHJWSk1SS2YwTkRpa2RtY29JNVdXN2g1Z0xY U3U0RVp2Vzh4SHhBX1FvRUZuU2VZZ2c4TlFOT0dMZl9QYUJkZEFkbjhja19taHRKZGdmYzBXMjUx blR2aU1Bd1BBanNHMEZNblBveDdHZHR6VGRtQS4zREpTQ21HRGQ5V0ktREkzc0JSbThRLm5jRkk5 dlVFZEtrdWhQUjBoM25PSlA1ZEJnS3JjUzVmOVE3WjU4QVpUVGRUVjUzRmx6SklId2RtZS0xeGlw d0RpZlRPTDh5aTdiZXVFRWlYZ19DU3p3LlVtTmx2cmZlQ0duaFdUOXF5dVVTU0ENCj4+Pj4NCj4+ Pj4NCj4+Pj4NCnsia3R5IjoiUlNBIiwibiI6IjJjUUpIMWY2eUY5RGNHYThDbWJuaG40TEhMczVM NmtOYjJyeGtyTkZaQXJKTFJhS3ZhQzN0TUNLWjhaZ0lwTzliVk1QeDVVTWpKb2FmN3A5TzVCU0Fw VnFBMkoxMGZVYmRTSW9tQ2NEd3ZHbzBleWh0eTBESUxMV1RNWHpHRVZNM0JYenVKUW9lRGt1VUNY WGNDd0E0TXN5eWQyT0hWdS1wQjJPckd2NmZjakh3aklOdHkzVW9LbTA4bEN2QWV2QktIc3VBLUZG d1FJSTlieWN2Ung1d1JxRlVqZE1BeWlPbUxZQkhCYUpTaTExZzNIVmV4TWNiMjl2MTRQU2xWemRH VU1OOG9ib2EtemNJeWFQcklpY3pMcUFrU1hRTmRFRkhyanNKSGZGZU5NZk9ibExNN2ljS05fdHlX dWpZZUl0dDRrcVVJaW1QbjVkSGp3Z2NRWUU3dyIsImUiOiJBUUFCIiwiZCI6ImR5VXozSXRWY2VY MVR2MVdxdFpNbktBXzBqTjVnV01jTDdheWY1SklTQWxDc3NHZm5VcmUyQzEwVEgwVVFqYlZNSWgt bkxNbkQ1S05KdzlRejVNUjI4b0dHOTMyR3E3aG1fX1plQTM0bC1PQ2U0RGRwZ3docHZWU0hPVTlN UzFSZFNVcG1QYXZBY0FfWDZpa3JBSFhaU2FvSGh4elVnck5UcHZCWVFNZkpVdl80OTJmU3RJc2VR OXJ3QU1PcENXT2lXTVpPUW0zS0pWVExMdW5YZEtmX1V4bXptS1hZS1laV2tlM0FXSXpVcW5PZnFJ amZEVE11bkY0VVdVMHpLbGhjc2FRTm1ZTVZySkdhakQxYkpkeV9kYlVVM0xFOHN4LWJka1VJNm9C ay1zRnRUVFZ5VmRRY2V0RzlrQ2hKNUVuWTVSNnR0XzRfeEZHNWt4elRvNnFhUSIsInAiOiI3eVFt Z0U2MFNMN1FyWHBBSmhDaExnS25YV2k2Qzh0VngxbEE4RlRwcGhwTGFDdEstSGJnQlZIQ3ByQzJD ZmFNMW14RkpaYWh4Z0ZqQzllaHVWOE96TU55RnM4a2VrUzgyRXNRR2tzaThISlB4eVIxZlU2QVRh MzZvZ1BHMG5OYXFtM0VEbVl5am93aG50Z0J6Mk9rYkZBc1RNSFRkbmEtcFpCUkphOWxtNVUiLCJx IjoiNlI0ZHpvOUx3SExPNzNFTVFQUXNtd1hqVk92QVM1VzZyZ1EtQkN0TWhlY19Rb3NBWElWRTNB R3lmd2VxWm02cnVyWENWRnlrREx3SjMwR2VwTFE4blRsemVWNmNseA0KMHg3MHNhR0dLS1ZtQ3NI dVZZV3dnSVJ5SlRydDRTWDI5TlFEWl9GRTUyTmxPM09oUGtqMUV4U2tfcEdNcUdSRmQyNks4ZzBq SnNYWE0iLCJkcCI6IlZCeW4taHMwcUIyTmNtYjhaeWNVT2dXdTdsam1qejF1cDFaS1VfM1p6SldW RGtlajctNkg3dmNKLXUxT3FnUnhGdjR2OV8tYVdQV2w2OFZsV2JrSWtKYng2dm5pdjZxcnJYd0Ja dTRrbE9Qd0VZQk9Yc3VjcnpYUllPanBKcDV5TmwyelJzbEZZUVFDMDBid3BBeE5DZGZOTFJaRGxY aEFxQ1V4bFlxeXQxMCIsImRxIjoiTUpGYnVHdFdadlFFZFJKaWNTM3VGU1kyNUx4eFJjNGVKSjh4 cElDNDRyVDVFdzRPdHpmMHpybHp6TTkyQ3YxSHZoQ2NPaU5LOG5SQ3drYlRuSkVJaC1FdVU3MElk dHRZU2ZpbHFTcnVrMngwcjhNc2sxcXJEdGJ5QkY2MENUb1JLQzJ5Y0RLZ29sVHl1YURuWDR5VTds eVR2ZHlELUwwWVF3WXBtbUZ5X2swIiwicWkiOiJ2eTdYQ3daM2p5TUdpazgxVElaREFPUUtDOEZW VWMwVEc1S1ZZZnRpNHRnd3pVcUZ3dHVCOE9jMWN0Q0tSYkU3dVpVUHdaaDRPc0NUTHFJdnFCUWRh X2theE94bzVFRjdpWGo2eUhtWjJzOFBfWl91M0pMdWgtb0FUXzZrbWJMeDZDQU8wRGJ0S3R4cDI0 SXZjMWhEZnFTd1dPUmdOMUFPclNSQ21FM253eGcifQ0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBqb3NlIG1haWxpbmcNCj4+Pj4gbGlzdCBqb3Nl QGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPiA8bWFpbHRvOmpvc2VAaWV0Zi5vcmc8bWFp bHRvOmpvc2VAaWV0Zi5vcmc+Pg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2UNCj4+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IC0tIFBpbmcgSWRlbnRpdHkgbG9n byA8aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS8+IEJyaWFuDQo+PiBDYW1wYmVsbCBQb3J0 Zm9saW8gQXJjaGl0ZWN0IEAgICAgICAgYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KPj4gPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiBwaG9uZSAgICAr MSA3MjAuMzE3LjIwNjE8dGVsOiUyQjElMjA3MjAuMzE3LjIwNjE+DQo+PiA8dGVsOiUyQjElMjA3 MjAuMzE3LjIwNjE+IENvbm5lY3Qgd2l0aCB1c+KApiB0d2l0dGVyIGxvZ28NCj4+IDxodHRwczov L3R3aXR0ZXIuY29tL3BpbmdpZGVudGl0eT4geW91dHViZSBsb2dvDQo+PiA8aHR0cHM6Ly93d3cu eW91dHViZS5jb20vdXNlci9QaW5nSWRlbnRpdHlUVj4gTGlua2VkSW4gbG9nbw0KPj4gPGh0dHBz Oi8vd3d3LmxpbmtlZGluLmNvbS9jb21wYW55LzIxODcwPiBGYWNlYm9vayBsb2dvDQo+PiA8aHR0 cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBhZ2U+IEdvb2dsZSsgbG9nbw0KPj4g PGh0dHBzOi8vcGx1cy5nb29nbGUuY29tL3UvMC8xMTQyNjY5Nzc3MzkzOTc3MDg1NDA+IHNsaWRl c2hhcmUNCj4+IGxvZ28gPGh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvUGluZ0lkZW50aXR5PiBm bGlwYm9hcmQgbG9nbw0KPj4gPGh0dHA6Ly9mbGlwLml0L3ZqQkY3PiByc3MgZmVlZCBpY29uDQo+ PiA8aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS9ibG9ncy8+DQo+Pg0KPj4gUmVnaXN0ZXIg Zm9yIENsb3VkIElkZW50aXR5IFN1bW1pdCAyMDE0IHwgTW9kZXJuIElkZW50aXR5DQo+PiBSZXZv bHV0aW9uIHwgMTnigJMyMyBKdWx5LCAyMDE0IHwgTW9udGVyZXksIENBDQo+PiA8aHR0cHM6Ly93 d3cuY2xvdWRpZGVudGl0eXN1bW1pdC5jb20vPg0KPj4NCj4+DQo+DQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGpvc2UgbWFpbGluZyBsaXN0DQo+ IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+IDxtYWlsdG86am9zZUBpZXRmLm9y ZzxtYWlsdG86am9zZUBpZXRmLm9yZz4+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZQ0KPg0KPg0KPg0KPg0KPiAtLSBQaW5nIElkZW50aXR5IGxvZ28gPGh0dHBz Oi8vd3d3LnBpbmdpZGVudGl0eS5jb20vPiBCcmlhbg0KPiBDYW1wYmVsbCBQb3J0Zm9saW8gQXJj aGl0ZWN0IEAgICAgICAgIGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbT4NCj4gPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiBwaG9uZSAgICAgKzEgNzIwLjMx Ny4yMDYxPHRlbDolMkIxJTIwNzIwLjMxNy4yMDYxPiBDb25uZWN0DQo+IHdpdGggdXPigKYgdHdp dHRlciBsb2dvIDxodHRwczovL3R3aXR0ZXIuY29tL3BpbmdpZGVudGl0eT4geW91dHViZQ0KPiBs b2dvIDxodHRwczovL3d3dy55b3V0dWJlLmNvbS91c2VyL1BpbmdJZGVudGl0eVRWPiBMaW5rZWRJ biBsb2dvDQo+IDxodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS8yMTg3MD4gRmFjZWJv b2sgbG9nbw0KPiA8aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBhZ2U+IEdv b2dsZSsgbG9nbw0KPiA8aHR0cHM6Ly9wbHVzLmdvb2dsZS5jb20vdS8wLzExNDI2Njk3NzczOTM5 NzcwODU0MD4gc2xpZGVzaGFyZQ0KPiBsb2dvIDxodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L1Bp bmdJZGVudGl0eT4gZmxpcGJvYXJkIGxvZ28NCj4gPGh0dHA6Ly9mbGlwLml0L3ZqQkY3PiByc3Mg ZmVlZCBpY29uDQo+IDxodHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tL2Jsb2dzLz4NCj4NCj4g UmVnaXN0ZXIgZm9yIENsb3VkIElkZW50aXR5IFN1bW1pdCAyMDE0IHwgTW9kZXJuIElkZW50aXR5 DQo+IFJldm9sdXRpb24gfCAxOeKAkzIzIEp1bHksIDIwMTQgfCBNb250ZXJleSwgQ0ENCj4gPGh0 dHBzOi8vd3d3LmNsb3VkaWRlbnRpdHlzdW1taXQuY29tLz4NCj4NCj4NCj4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gam9zZSBtYWlsaW5nIGxp c3QNCj4gam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQo+DQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUt LS0tLQ0KVmVyc2lvbjogR251UEcvTWFjR1BHMiB2Mi4wLjIyIChEYXJ3aW4pDQpDb21tZW50OiBH UEdUb29scyAtIGh0dHBzOi8vZ3BndG9vbHMub3JnDQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRo IFRodW5kZXJiaXJkIC0gaHR0cDovL3d3dy5lbmlnbWFpbC5uZXQvDQoNCmlRRWNCQUVCQ2dBR0JR SlRhYXJuQUFvSkVEV2krUzBXN2NPMVBIWUgvM3NVaWZ3UXY0dlNpM1BPNlY1QXdNYWQNCkN1QmxH WWE0UE9GNzRPM1FHcUtGK2FUSHJCOTdNelNvajJVejhoSkNST0dCcFR4Q1NxeDlDSzNCT0o4aG5H bUkNCjZmcTBGSERlQTdXZUNNa2F4ck5jbFgzV2FiYVlIakI2aFBsRktLK3pCNno3anNyNkYvc2lr bUNKSWJnTkhlUm4NCkxJMklvMDJJM2IyVFVHRHA5MGU0cjVuWmIvVGxPN2pWMmt1d2o4Z3BybGwx ZUJHaUtmWWR0bGhwRGlieTdEUFgNClFRdU5OekdObExtazkwZUFkNEhmUXZMNkNySWJRZ09nbWdz NUQwWlJYWXp4bjVobUFCdU9QQk9OaEdsVEQ3eEcNCnhka3pOckQ0ZnJPQWRMcHJ0YUM4Y2Zhclc2 VVlTVFVPaE5reWZmRGZGYTNTSUV6YUYxSnZuRVZvTWs4SVcrQT0NCj1POUV4DQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0NCg0K --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C603A59HE111541eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2 Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUg dmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD5JIHRoaW5rIHRoYXQgdGhlIGphdmEgaW1wbGVtZW50YXRpb25zIGltcGxlbWVudGVkIHRoZSBz cGVjIGFuZCBldmVyeXRoaW5nIGlzIG9rIGZyb20gdGhhdCBQT1YuPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PlRoZXNlIGltcGxlbWVudGF0aW9ucyBhcmUgbm90IGJyb2tlbi48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pk9uZSBjb3VsZCBhcmd1ZSB0aGF0IHdoZW4gd2UgcmVwbGFj ZSBTSEEtMSBieSBTSEEtMjU2IGluIG9uZSBwbGFjZSB0aGVuIHdlIG1pZ2h0IGNvbnNpZGVyIHRv IHJlcGxhY2UgaXQgaW4gdGhlIHBhZGRpbmcgdG9vLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD5NeSBmZWVsaW5nIGlzIHRoYXQgdXNpbmcgc2hhLTI1NiBmb3IgdGhlIHBhZGRp bmcgZG9lcyBub3QgZ2l2ZSB1cyBtb3JlIHNlY3VyaXR5LiBZTU1XPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZSBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10g PGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj48Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBNYXkgMDcsIDIwMTQgNjo1NCBBTTxicj48Yj5Ubzo8L2I+IE1hdHQgTWlsbGVyPGJyPjxi PkNjOjwvYj4gQW50b25pbyBTYW5zbzsgam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4g UmU6IFtqb3NlXSBSU0EtT0FFUC0yNTYgRXhhbXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPlRoYW5rcyBNYXR0LiA8YnI+PGJy PlRoYXQgaXMgd2h5IEkgd2FzIGxvb2tpbmcgZm9yIHNvbWVvbmUgdG8gdmVyaWZ5IHVzaW5nIGEg ZGlmZmVyZW50IHBsYXRmb3JtLiBUaG91Z2ggSSB3YXMgaG9waW5nIGl0J2QganVzdCB3b3JrLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5NYXR0LCBjYW4geW91IHRyeSBk ZWNyeXB0aW5nIHRoaXMgb25lIGJ5IGNoYW5jZT8gVXNpbmcgdGhlIHNhbWUga2V5LiBJIHdhcyBt b3JlIGV4cGxpY2l0IHdpdGggdGhlIHBhcmFtZXRlcnMgYW5kLCBJIHRoaW5rLCBNR0YxIHNob3Vs ZCBiZSB1c2luZyBTSEEtMjU2IG5vdyB0b28uIDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj5leUpoYkdjaU9pSlNVMEV0VDBGRlVDMHlOVFlpTENKbGJtTWlPaUpCTVRJ NFEwSkRMVWhUTWpVMkluMC5mTDVJTDVjTUNqalU5RzlfWmpzRDJYTzBISXdUT3diVnd1bGNaVncz MV9yeDJxVGNIemJZaEl2cnZiY1ZMVGZKem44eGJRM1VFTDQ0MlpnWjFQY0ZZS0VOWWVQWGlFeXZZ eFBOOGRtdmpfT2ZMU0pERXFSNmt2d09iNm5naEd0eGZ6ZEJfVlJ2RnQyZWVoYkNBM2dXcGlPWUhI dlNURmRCUEd4MktaSFFpc0x6M29aUjhFV2laMXdvRXBIeThhN0ZvUTJ6enVEbFpFSlFPVXJoMDli X0VKeG1jRTJqTDZ3bUV0Z2FieXh5M1ZnV2czR3FTUFVJU2xKWlY5SFRodVZKZXp6a3RKZHBudFJE bkFQVXFqYzhJd0J5R3BNbGVJUWNQdUJVc2VSUlByX09zcm9PSjZlVGw1RHVGQ21CT0tiLWVOTnc1 di1HRWNWWXIxdzdYOW9Yb0EuMGZyZEl3eDhQOFVBemgxczlfUGdPQS5SQXpJTEgweGZzMHl4ek1M MUN6ekdFeENmRTJfd3pXS3MwRlZ1WGZNOFI1SDY4eVRxVGJxSXFSQ3AyZmVBSDVHU3ZsdXptenRr Ml9Da0dOU2pBeW9hdy40bk1VWE9nbWdXdk0tMDh0SVotaDV3PG86cD48L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNw OzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBUdWUsIE1heSA2LCAyMDE0IGF0 IDg6MzkgUE0sIE1hdHQgTWlsbGVyICZsdDs8YSBocmVmPSJtYWlsdG86bWFtaWxsZTJAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWFtaWxsZTJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNT QUdFLS0tLS08YnI+SGFzaDogU0hBNTEyPGJyPjxicj5TaG9ydCBhbnN3ZXI6PGJyPllvdSBhcmUg YWxsIGVxdWFsbHkgYnJva2VuIC0tIGV4Y2VwdCBmcm9tIGEgY2VydGFpbiBwb2ludCBvZiB2aWV3 IGQtOjxicj48YnI+TG9uZyBhbnN3ZXI6PGJyPlRoZSBjb2RlIEkgaGF2ZSBpcyBiYXNlZCBvbiBP cGVuU1NMLCB3aGljaCBpcyBoYXJkLWNvZGVkIHRvIHVzZSBTSEExPGJyPmZvciB0aGUgaGFzaCBh bmQgbWFzayBnZW5lcmF0aW9uIChib28hKSwgd2hpY2ggbWVhbnMgb25lIGhhcyB0bzxicj5pbXBs ZW1lbnQgT0FFUC1TSEEyNTYgZnJvbSBzY3JhdGNoIChoaXNzISEpLjxicj48YnI+V2hlbiBJIGlt cGxlbWVudGVkIGl0IHBlciBSRkMgMzQ0NyBhbmQ8YnI+ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2Vi LWFsZ29yaXRobXMtMjYjc2VjdGlvbi00LjMsIEkgY291bGQgbm90PGJyPmRlY3J5cHQgdGhlIHBy b3ZpZGVkIHJlc3VsdHMuICZuYnNwO1doZW4gSSBoYXJkLWNvZGVkIE1HRjEgdG8gdXNlICZxdW90 O1NIQTEmcXVvdDssIEk8YnI+Y291bGQgZGVjcnlwdCBwcm92aWRlZCByZXN1bHRzLiAmbmJzcDtB IHNlYXJjaCB0aHJvdWdoIEJvdW5jeUNhc3RsZSdzIGNvZGU8YnI+c2hvd3MgdGhhdCAmcXVvdDtS U0EvRUNCL09BRVBXaXRoU0hBLTI1NkFuZE1HRjFQYWRkaW5nJnF1b3Q7IHVzZXMgYSBIYXNoPGJy PmZ1bmN0aW9uIG9mIFNIQS0yNTYgZ2VuZXJhdGUgdGhlIGxIYXNoIGJ1dCBpdHMgTUdGMSB1c2Vz IGEgJnF1b3Q7U0hBLTEmcXVvdDsuPGJyPkZ1cnRoZXIgZXZpZGVuY2UgaXMgc2hvd24gd2l0aCBo b3cgW0ZPUkdFXSBjYW4gYmUgbWFkZSB0byB3b3JrIHdpdGg8YnI+SmF2YSAoc2VhcmNoIHRoZWly IGhvbWVwYWdlIGZvciAmcXVvdDtDb21wYXRpYmxlIHdpdGggSmF2YSdzPGJyPlJTQS9FQ0IvT0FF UFdpdGhTSEEtMjU2QW5kTUdGMVBhZGRpbmcmcXVvdDspLjxicj48YnI+UmVjb25jaWxpbmcgYWxs IG9mIHRoaXMgd2l0aDxicj5kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcyNhcHBl bmRpeC1BLjIgZG9lcyBub3QgbG9vayB0byBiZTxicj52ZXJ5IHN0cmFpZ2h0LWZvcndhcmQuICZu YnNwO0l0IGFwcGVhcnMgdGhhdCB0aGUgSkNBIGlkZW50aWZpZXIgaXMgbWVhbnQgdG88YnI+YmUg JnF1b3Q7TUdGMSB3aXRoIFNIQTEmcXVvdDs7IHRoYXQgb3VnaHQgdG8gYmUgZXhwbGljaXRseSBu b3RlZC4gJm5ic3A7VGhlIFhNTEVOQzxicj5yZWZlcmVuY2UgaXMgYXJndWFibHkgaW5jb21wbGV0 ZSwgc2luY2U8YnI+JnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvMjAwOS94bWxlbmMx MSNyc2Etb2FlcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cudzMub3JnLzIwMDkveG1sZW5j MTEjcnNhLW9hZXA8L2E+JnF1b3Q7IGRlZmF1bHRzIHRvPGJyPiZxdW90OzxhIGhyZWY9Imh0dHA6 Ly93d3cudzMub3JnLzIwMDkveG1sZW5jMTEjbWdmMXNoYTEiIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vd3d3LnczLm9yZy8yMDA5L3htbGVuYzExI21nZjFzaGExPC9hPiZxdW90OyAoTUdGMSB3aXRo IFNIQTEpOyB0aGlzIGNhbjxicj5wcm9iYWJseSBiZSBhZGRyZXNzZWQgYnkgZXhwbGljaXRseSBz dGF0aW5nIHRoZSBtYXNrIGdlbmVyYXRpb248YnI+ZnVuY3Rpb24gaXMgJnF1b3Q7PGEgaHJlZj0i aHR0cDovL3d3dy53My5vcmcvMjAwOS94bWxlbmMxMSNtZ2Yxc2hhMjU2IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3d3dy53My5vcmcvMjAwOS94bWxlbmMxMSNtZ2Yxc2hhMjU2PC9hPiZxdW90OyAo TUdGMSB3aXRoPGJyPlNIQS0yNTYpLjxicj48YnI+PGJyPi0gLS08YnI+LSAtIG0mYW1wO208YnI+ PGJyPk1hdHQgTWlsbGVyICZsdDsgPGEgaHJlZj0ibWFpbHRvOm1hbWlsbGUyQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hbWlsbGUyQGNpc2NvLmNvbTwvYT4gJmd0Ozxicj5DaXNjbyBTeXN0 ZW1zLCBJbmMuPGJyPjxicj5bRk9SR0VdIEZvcmdlICZsdDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL2RpZ2l0YWxiYXphYXIvZm9yZ2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1 Yi5jb20vZGlnaXRhbGJhemFhci9mb3JnZTwvYT4gJmd0OzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxicj5PbiA1LzYvMTQsIDg6MDAgQU0sIEJyaWFuIENhbXBiZWxsIHdy b3RlOjxicj4mZ3Q7IEJ1dCB5b3UgcHJvYmFibGUgZGlkIGRvIHNvbWV0aGluZyB2ZXJ5IHNpbWls YXIgdG8gd2hhdCBJIGRpZCBpbjxicj4mZ3Q7IGpvc2U0aiAtIGkuZS4ganVzdCBnZXR0aW5nIGEg Y2lwaGVyIGluc3RhbmNlIHdpdGg8YnI+Jmd0OyAmcXVvdDtSU0EvRUNCL09BRVBXaXRoU0hBLTI1 NkFuZE1HRjFQYWRkaW5nJnF1b3Q7Pzxicj4mZ3Q7PGJyPiZndDsgSSB0aGluayB0aGF0J3MgdGhl IHJpZ2h0IHRoaW5nIHRvIGRvIChhbmQgSldBIGV2ZW4gaW1wbGllcyBpdCkgYnV0PGJyPiZndDsg YSBjaGVjayBmcm9tIGEgZGlmZmVyZW50IGxhbmd1YWdlL3BsYXRmb3JtIHdvdWxkIGhlbHAgdmVy aWZ5IHRoYXQ8YnI+Jmd0OyBhc3N1bXB0aW9uLiBJIGRvbid0IGtub3cgaWYgbWF5YmUgbW9yZSBz cGVjaWZpY3MgbmVlZCB0byBiZTxicj4mZ3Q7IHByb3ZpZGVkIHRvIHRoZSBjaXBoZXIgdmlhIE9B RVBQYXJhbWV0ZXJTcGVjIG9yIHNvbWV0aGluZyAtIHRoZSBKQ0E8YnI+Jmd0OyBBUElzIGNhbiBi ZSBhIGJpdCBteXN0ZXJpb3VzIGF0IHRpbWVzLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBPbiBU dWUsIE1heSA2LCAyMDE0IGF0IDY6MzIgQU0sIEFudG9uaW8gU2Fuc28gJmx0OzxhIGhyZWY9Im1h aWx0bzphc2Fuc29AYWRvYmUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXNhbnNvQGFkb2JlLmNvbTwv YT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmFzYW5zb0BhZG9iZS5jb20iIHRhcmdldD0iX2JsYW5rIj5h c2Fuc29AYWRvYmUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4mZ3Q7PGJyPiZndDsgaGkgQnJp YW4sPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IE9uIE1heSA2LCAyMDE0LCBhdCAzOjI5IFBNLCBC cmlhbiBDYW1wYmVsbDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0i X2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPiZndDsgd3JvdGU6PGJyPiZndDs8YnI+Jmd0OyZndDsgRnJvbSB0aGUg dmVuZXJhYmxlIGZpbG0gQW5pbWFsIEhvdXNlLCBvZiBjb3Vyc2UsPGJyPiZndDsmZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9dlZYRVE4aGp5R0kiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PXZWWEVROGhqeUdJPC9hPjxi cj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBUaGFua3MgZm9yIGNoZWNraW5nIHRoYXQgQW50b25pby48 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgSG9wZWZ1bGx5IHdlIGNvdWxkIGdldCBhIG5vbiBKYXZh IGJhc2VkIGltcGxlbWVudGluZyB0byB2ZXJpZnkgaXQ8YnI+Jmd0OyZndDsgdG9vLjxicj4mZ3Q7 PGJyPiZndDsganVzdCBmb3IgY29tcGxldGVuZXNzIEkgZGlkICpub3QqIHVzZSBqb3NlNGogdG8g dmVyaWZ5IGl04oCmIChqdXN0PGJyPiZndDsgdG8gYmUgc2FmZSk8YnI+Jmd0Ozxicj4mZ3Q7IHJl Z2FyZHM8YnI+Jmd0Ozxicj4mZ3Q7IGFudG9uaW88YnI+Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBPbiBUdWUsIE1heSA2LCAy MDE0IGF0IDY6MjUgQU0sIEFudG9uaW8gU2Fuc28gJmx0OzxhIGhyZWY9Im1haWx0bzphc2Fuc29A YWRvYmUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXNhbnNvQGFkb2JlLmNvbTwvYT48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzphc2Fuc29AYWRvYmUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXNhbnNvQGFk b2JlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgV2VsbCwg YXMgb2YgdGhpcyBtb21lbnQsIHRoZXkncmUgb24gRE9VQkxFIFNFQ1JFVCBQUk9CQVRJT04hPGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IE9uIE1heSA2LCAyMDE0LCBhdCAxMTozNCBBTSwgQW50b25p byBTYW5zbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFzYW5zb0BhZG9iZS5jb20iIHRhcmdldD0iX2Js YW5rIj5hc2Fuc29AYWRvYmUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPiZndDsmZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFzYW5zb0Bh ZG9iZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hc2Fuc29AYWRvYmUuY29tPC9hPiZndDsmZ3Q7IHdy b3RlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgSGkgQnJpYW4sPGJyPiZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsgSSB3aWxsIGdpdmUgYSB0cnkgYW5kIGxldCB5b3Uga25vdzxicj4m Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IHJlZ2FyZHM8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyBhbnRvbmlvPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgT24gTWF5 IDYsIDIwMTQsIGF0IDU6NDAgQU0sIEJyaWFuIENhbXBiZWxsPGJyPiZndDsmZ3Q7Jmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7IFRoZSBsYXRlc3QgcmV2aXNpb24gb2YgSldBIGFkZGVkIGEgbmV3ICdS U0EtT0FFUC0yNTYnIEpXRSBhbGc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBmb3Iga2V5IGVuY3J5cHRp b24gYnV0LCBBRkFJSywgdGhlcmUgYXJlIG5vIGV4YW1wbGVzIHVzaW5nPGJyPiZndDsmZ3Q7Jmd0 OyZndDsgaXQuIEkgcmVjZW50bHkgYWRkZWQgc3VwcG9ydCBmb3IgaXQgdG88YnI+Jmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2JpdGJ1Y2tldC5vcmcvYl9jL2pvc2U0aiIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vYml0YnVja2V0Lm9yZy9iX2Mvam9zZTRqPC9hPiBhbmQgYW0gbG9v a2luZyB0byBnZXQgc29tZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGtpbmQgb2YgY29uZmlybWF0aW9u IHRoYXQgSSd2ZSBkb25lIGl0IGNvcnJlY3RseSAob3RoZXIgdGhhbjxicj4mZ3Q7Jmd0OyZndDsm Z3Q7IHNlbGYgaW50ZXJvcCkuIFdpdGggdGhhdCBpbiBtaW5kLCBoZXJlIGlzIGEgSldFIHVzaW5n PGJyPiZndDsmZ3Q7Jmd0OyZndDsgUlNBLU9BRVAtMjU2IHdoaWNoIEkndmUgcHJvZHVjZWQgYW5k IEknbSBob3BlZnVsIHRoYXQgc29tZW9uZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IG9uIHRoaXMgV0cg bGlzdCB3aWxsIGJlIGFibGUgdG8gZGVjcnlwdC4gVGhlIFJTQSBrZXkgdGhhdCB3YXM8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyB1c2VkIChpbiBKV0sgZm9ybWF0IHdpdGggYm90aCBwdWJsaWMgYW5kIHBy aXZhdGUgcGFydHMpIGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsgYmVsb3cgdGhlIEpXRS48YnI+Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGV5SmhiR2NpT2lKU1UwRXRUMEZGVUMw eU5UWWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wLk95ZWc0aGJxMkhqdEhPY1hkdUs5 VWhoSVhlcnZQek9UTEFxS3BoQ3llSzU1Y0ZnS3RGMzJEaEQyNnNmbkc2aDlhejNPZ3JuNFF3WUpl WmtqSkszNnRleWpsOW9LSVdfOUl0UDhjWWhPcmlET09aRmhvNTNCc3R0cWo4cGMwVVByTUo0NDh5 UXNna2d5cW1mV1pRczN1X3FDYVNMWHBlZ0Uzby1ZSjUyMC1YdV9FbFM1cE55X3ZmU01FMUNlUDV1 blBRUGYwNlhjNmlNVld4OS1LXzdseEM3YWNZSV9mU1NVd3VGdy12eHJWSk1SS2YwTkRpa2RtY29J NVdXN2g1Z0xYU3U0RVp2Vzh4SHhBX1FvRUZuU2VZZ2c4TlFOT0dMZl9QYUJkZEFkbjhja19taHRK ZGdmYzBXMjUxblR2aU1Bd1BBanNHMEZNblBveDdHZHR6VGRtQS4zREpTQ21HRGQ5V0ktREkzc0JS bThRLm5jRkk5dlVFZEtrdWhQUjBoM25PSlA1ZEJnS3JjUzVmOVE3WjU4QVpUVGRUVjUzRmx6SklI d2RtZS0xeGlwd0RpZlRPTDh5aTdiZXVFRWlYZ19DU3p3LlVtTmx2cmZlQ0duaFdUOXF5dVVTU0E8 YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZn dDs8YnI+eyZxdW90O2t0eSZxdW90OzomcXVvdDtSU0EmcXVvdDssJnF1b3Q7biZxdW90OzomcXVv dDsyY1FKSDFmNnlGOURjR2E4Q21ibmhuNExITHM1TDZrTmIycnhrck5GWkFySkxSYUt2YUMzdE1D S1o4WmdJcE85YlZNUHg1VU1qSm9hZjdwOU81QlNBcFZxQTJKMTBmVWJkU0lvbUNjRHd2R28wZXlo dHkwRElMTFdUTVh6R0VWTTNCWHp1SlFvZURrdVVDWFhjQ3dBNE1zeXlkMk9IVnUtcEIyT3JHdjZm Y2pId2pJTnR5M1VvS20wOGxDdkFldkJLSHN1QS1GRndRSUk5YnljdlJ4NXdScUZVamRNQXlpT21M WUJIQmFKU2kxMWczSFZleE1jYjI5djE0UFNsVnpkR1VNTjhvYm9hLXpjSXlhUHJJaWN6THFBa1NY UU5kRUZIcmpzSkhmRmVOTWZPYmxMTTdpY0tOX3R5V3VqWWVJdHQ0a3FVSWltUG41ZEhqd2djUVlF N3cmcXVvdDssJnF1b3Q7ZSZxdW90OzomcXVvdDtBUUFCJnF1b3Q7LCZxdW90O2QmcXVvdDs6JnF1 b3Q7ZHlVejNJdFZjZVgxVHYxV3F0Wk1uS0FfMGpONWdXTWNMN2F5ZjVKSVNBbENzc0dmblVyZTJD MTBUSDBVUWpiVk1JaC1uTE1uRDVLTkp3OVF6NU1SMjhvR0c5MzJHcTdobV9fWmVBMzRsLU9DZTRE ZHBnd2hwdlZTSE9VOU1TMVJkU1VwbVBhdkFjQV9YNmlrckFIWFpTYW9IaHh6VWdyTlRwdkJZUU1m SlV2XzQ5MmZTdElzZVE5cndBTU9wQ1dPaVdNWk9RbTNLSlZUTEx1blhkS2ZfVXhtem1LWFlLWVpX a2UzQVdJelVxbk9mcUlqZkRUTXVuRjRVV1UwektsaGNzYVFObVlNVnJKR2FqRDFiSmR5X2RiVVUz TEU4c3gtYmRrVUk2b0JrLXNGdFRUVnlWZFFjZXRHOWtDaEo1RW5ZNVI2dHRfNF94Rkc1a3h6VG82 cWFRJnF1b3Q7LCZxdW90O3AmcXVvdDs6JnF1b3Q7N3lRbWdFNjBTTDdRclhwQUpoQ2hMZ0tuWFdp NkM4dFZ4MWxBOEZUcHBocExhQ3RLLUhiZ0JWSENwckMyQ2ZhTTFteEZKWmFoeGdGakM5ZWh1VjhP ek1OeUZzOGtla1M4MkVzUUdrc2k4SEpQeHlSMWZVNkFUYTM2b2dQRzBuTmFxbTNFRG1ZeWpvd2hu dGdCejJPa2JGQXNUTUhUZG5hLXBaQlJKYTlsbTVVJnF1b3Q7LCZxdW90O3EmcXVvdDs6JnF1b3Q7 NlI0ZHpvOUx3SExPNzNFTVFQUXNtd1hqVk92QVM1VzZyZ1EtQkN0TWhlY19Rb3NBWElWRTNBR3lm d2VxWm02cnVyWENWRnlrREx3SjMwR2VwTFE4blRsemVWNmNseDxicj4weDcwc2FHR0tLVm1Dc0h1 VllXd2dJUnlKVHJ0NFNYMjlOUURaX0ZFNTJObE8zT2hQa2oxRXhTa19wR01xR1JGZDI2SzhnMGpK c1hYTSZxdW90OywmcXVvdDtkcCZxdW90OzomcXVvdDtWQnluLWhzMHFCMk5jbWI4WnljVU9nV3U3 bGptanoxdXAxWktVXzNaekpXVkRrZWo3LTZIN3ZjSi11MU9xZ1J4RnY0djlfLWFXUFdsNjhWbFdi a0lrSmJ4NnZuaXY2cXJyWHdCWnU0a2xPUHdFWUJPWHN1Y3J6WFJZT2pwSnA1eU5sMnpSc2xGWVFR QzAwYndwQXhOQ2RmTkxSWkRsWGhBcUNVeGxZcXl0MTAmcXVvdDssJnF1b3Q7ZHEmcXVvdDs6JnF1 b3Q7TUpGYnVHdFdadlFFZFJKaWNTM3VGU1kyNUx4eFJjNGVKSjh4cElDNDRyVDVFdzRPdHpmMHpy bHp6TTkyQ3YxSHZoQ2NPaU5LOG5SQ3drYlRuSkVJaC1FdVU3MElkdHRZU2ZpbHFTcnVrMngwcjhN c2sxcXJEdGJ5QkY2MENUb1JLQzJ5Y0RLZ29sVHl1YURuWDR5VTdseVR2ZHlELUwwWVF3WXBtbUZ5 X2swJnF1b3Q7LCZxdW90O3FpJnF1b3Q7OiZxdW90O3Z5N1hDd1ozanlNR2lrODFUSVpEQU9RS0M4 RlZVYzBURzVLVllmdGk0dGd3elVxRnd0dUI4T2MxY3RDS1JiRTd1WlVQd1poNE9zQ1RMcUl2cUJR ZGFfa2F4T3hvNUVGN2lYajZ5SG1aMnM4UF9aX3UzSkx1aC1vQVRfNmttYkx4NkNBTzBEYnRLdHhw MjRJdmMxaERmcVN3V09SZ04xQU9yU1JDbUUzbnd4ZyZxdW90O308YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBqb3NlIG1h aWxpbmc8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsmZ3Q7 Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ am9zZUBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9z ZTwvYT48YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IC0tIFBpbmcgSWRlbnRpdHkgbG9nbyAmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5waW5naWRlbnRpdHkuY29tLzwvYT4mZ3Q7IEJyaWFuPG86cD48L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsgQ2FtcGJlbGwgUG9ydGZvbGlvIEFyY2hpdGVjdCBA ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgcGhvbmUgJm5ic3A7ICZuYnNw OzxhIGhyZWY9InRlbDolMkIxJTIwNzIwLjMxNy4yMDYxIiB0YXJnZXQ9Il9ibGFuayI+KzEgNzIw LjMxNy4yMDYxPC9hPjxicj4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0idGVsOiUyQjElMjA3MjAuMzE3 LjIwNjEiPnRlbDolMkIxJTIwNzIwLjMxNy4yMDYxPC9hPiZndDsgQ29ubmVjdCB3aXRoIHVz4oCm IHR3aXR0ZXIgbG9nbzxicj4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNv bS9waW5naWRlbnRpdHkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3R3aXR0ZXIuY29tL3Bpbmdp ZGVudGl0eTwvYT4mZ3Q7IHlvdXR1YmUgbG9nbzxicj4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0 cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9QaW5nSWRlbnRpdHlUViIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvUGluZ0lkZW50aXR5VFY8L2E+Jmd0OyBMaW5r ZWRJbiBsb2dvPGJyPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5j b20vY29tcGFueS8yMTg3MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmxpbmtlZGluLmNv bS9jb21wYW55LzIxODcwPC9hPiZndDsgRmFjZWJvb2sgbG9nbzxicj4mZ3Q7Jmd0OyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBhZ2UiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5mYWNlYm9vay5jb20vcGluZ2lkZW50aXR5cGFnZTwvYT4mZ3Q7 IEdvb2dsZSsgbG9nbzxicj4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9wbHVzLmdvb2ds ZS5jb20vdS8wLzExNDI2Njk3NzczOTM5NzcwODU0MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v cGx1cy5nb29nbGUuY29tL3UvMC8xMTQyNjY5Nzc3MzkzOTc3MDg1NDA8L2E+Jmd0OyBzbGlkZXNo YXJlPGJyPiZndDsmZ3Q7IGxvZ28gJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuc2xpZGVzaGFyZS5u ZXQvUGluZ0lkZW50aXR5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5zbGlkZXNoYXJlLm5l dC9QaW5nSWRlbnRpdHk8L2E+Jmd0OyBmbGlwYm9hcmQgbG9nbzxicj4mZ3Q7Jmd0OyAmbHQ7PGEg aHJlZj0iaHR0cDovL2ZsaXAuaXQvdmpCRjciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZmxpcC5p dC92akJGNzwvYT4mZ3Q7IHJzcyBmZWVkIGljb248YnI+Jmd0OyZndDsgJmx0OzxhIGhyZWY9Imh0 dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20vYmxvZ3MvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cucGluZ2lkZW50aXR5LmNvbS9ibG9ncy88L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFJlZ2lzdGVyIGZvciBDbG91 ZCBJZGVudGl0eSBTdW1taXQgMjAxNCB8IE1vZGVybiBJZGVudGl0eTxicj4mZ3Q7Jmd0OyBSZXZv bHV0aW9uIHwgMTnigJMyMyBKdWx5LCAyMDE0IHwgTW9udGVyZXksIENBPG86cD48L286cD48L3A+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3d3 dy5jbG91ZGlkZW50aXR5c3VtbWl0LmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5j bG91ZGlkZW50aXR5c3VtbWl0LmNvbS88L2E+Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBqb3NlIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpq b3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT4gJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vam9zZTwvYT48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxi cj4mZ3Q7IC0tIFBpbmcgSWRlbnRpdHkgbG9nbyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cucGlu Z2lkZW50aXR5LmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5waW5naWRlbnRpdHku Y29tLzwvYT4mZ3Q7IEJyaWFuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jmd0OyBDYW1wYmVsbCBQb3J0Zm9saW8gQXJjaGl0ZWN0IEAgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+PG86cD48L286cD48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTwvYT4mZ3Q7IHBob25lICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0idGVsOiUyQjEl MjA3MjAuMzE3LjIwNjEiIHRhcmdldD0iX2JsYW5rIj4rMSA3MjAuMzE3LjIwNjE8L2E+IENvbm5l Y3Q8YnI+Jmd0OyB3aXRoIHVz4oCmIHR3aXR0ZXIgbG9nbyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90 d2l0dGVyLmNvbS9waW5naWRlbnRpdHkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3R3aXR0ZXIu Y29tL3BpbmdpZGVudGl0eTwvYT4mZ3Q7IHlvdXR1YmU8YnI+Jmd0OyBsb2dvICZsdDs8YSBocmVm PSJodHRwczovL3d3dy55b3V0dWJlLmNvbS91c2VyL1BpbmdJZGVudGl0eVRWIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9QaW5nSWRlbnRpdHlUVjwvYT4mZ3Q7 IExpbmtlZEluIGxvZ288YnI+Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cubGlua2VkaW4u Y29tL2NvbXBhbnkvMjE4NzAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5saW5rZWRpbi5j b20vY29tcGFueS8yMTg3MDwvYT4mZ3Q7IEZhY2Vib29rIGxvZ288YnI+Jmd0OyAmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3BpbmdpZGVudGl0eXBhZ2UiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5mYWNlYm9vay5jb20vcGluZ2lkZW50aXR5cGFnZTwvYT4mZ3Q7IEdv b2dsZSsgbG9nbzxicj4mZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3BsdXMuZ29vZ2xlLmNvbS91 LzAvMTE0MjY2OTc3NzM5Mzk3NzA4NTQwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9wbHVzLmdv b2dsZS5jb20vdS8wLzExNDI2Njk3NzczOTM5NzcwODU0MDwvYT4mZ3Q7IHNsaWRlc2hhcmU8YnI+ Jmd0OyBsb2dvICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L1BpbmdJZGVu dGl0eSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvUGluZ0lkZW50 aXR5PC9hPiZndDsgZmxpcGJvYXJkIGxvZ288YnI+Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cDovL2Zs aXAuaXQvdmpCRjciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZmxpcC5pdC92akJGNzwvYT4mZ3Q7 IHJzcyBmZWVkIGljb248YnI+Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cucGluZ2lkZW50 aXR5LmNvbS9ibG9ncy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5waW5naWRlbnRpdHku Y29tL2Jsb2dzLzwvYT4mZ3Q7PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jmd0Ozxicj4mZ3Q7IFJlZ2lzdGVyIGZvciBDbG91ZCBJZGVudGl0eSBTdW1taXQgMjAxNCB8IE1v ZGVybiBJZGVudGl0eTxicj4mZ3Q7IFJldm9sdXRpb24gfCAxOeKAkzIzIEp1bHksIDIwMTQgfCBN b250ZXJleSwgQ0E8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyAm bHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuY2xvdWRpZGVudGl0eXN1bW1pdC5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuY2xvdWRpZGVudGl0eXN1bW1pdC5jb20vPC9hPiZndDs8bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBqb3NlIG1haWxpbmcgbGlzdDxicj4m Z3Q7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+am9zZUBp ZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9qb3NlPC9hPjxicj4mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPGJyPlZlcnNpb246IEdudVBHL01hY0dQ RzIgdjIuMC4yMiAoRGFyd2luKTxicj5Db21tZW50OiBHUEdUb29scyAtIDxhIGhyZWY9Imh0dHBz Oi8vZ3BndG9vbHMub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9ncGd0b29scy5vcmc8L2E+ PGJyPkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggVGh1bmRlcmJpcmQgLSA8YSBocmVmPSJodHRw Oi8vd3d3LmVuaWdtYWlsLm5ldC8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmVuaWdtYWls Lm5ldC88L2E+PGJyPjxicj5pUUVjQkFFQkNnQUdCUUpUYWFybkFBb0pFRFdpK1MwVzdjTzFQSFlI LzNzVWlmd1F2NHZTaTNQTzZWNUF3TWFkPGJyPkN1QmxHWWE0UE9GNzRPM1FHcUtGK2FUSHJCOTdN elNvajJVejhoSkNST0dCcFR4Q1NxeDlDSzNCT0o4aG5HbUk8YnI+NmZxMEZIRGVBN1dlQ01rYXhy TmNsWDNXYWJhWUhqQjZoUGxGS0srekI2ejdqc3I2Ri9zaWttQ0pJYmdOSGVSbjxicj5MSTJJbzAy STNiMlRVR0RwOTBlNHI1blpiL1RsTzdqVjJrdXdqOGdwcmxsMWVCR2lLZllkdGxocERpYnk3RFBY PGJyPlFRdU5OekdObExtazkwZUFkNEhmUXZMNkNySWJRZ09nbWdzNUQwWlJYWXp4bjVobUFCdU9Q Qk9OaEdsVEQ3eEc8YnI+eGRrek5yRDRmck9BZExwcnRhQzhjZmFyVzZVWVNUVU9oTmt5ZmZEZkZh M1NJRXphRjFKdm5FVm9NazhJVytBPTxicj49TzlFeDxicj4tLS0tLUVORCBQR1AgU0lHTkFUVVJF LS0tLS08bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C603A59HE111541eme_-- From nobody Wed May 7 05:22:38 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7963B1A0639 for ; Wed, 7 May 2014 05:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6adpK1EqZ1Rj for ; Wed, 7 May 2014 05:22:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 258971A02B2 for ; Wed, 7 May 2014 05:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3333; q=dns/txt; s=iport; t=1399465351; x=1400674951; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FBpabtv9twW4iMcnwHrGRudN0NqNomf6jCoHz/3UgBQ=; b=Cz5In6GnSFS2TIlwegsslU8zfD/otbd9dmlinOic6X+gbEFoRojEj/to 00SIL238Mza4aj7codp1aJh9Pb8DRvBaZ8esAxZ/czNqgtwfpxnyc1i50 KXYQhI0vLiWNLKFMYU9/EQY8E01H1gJvj9/R31/adtDpT/0SXmUmdfghN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAEwkalOtJV2c/2dsb2JhbABagwZPWIJnqBoBAQEGmg4BgRoWdIIlAQEBBCNWEAsOCgICBR4DAgIPAjURBg0BBQIBAYg9DalipUAXgSqELIVtglwzB4J0gUsEigiPL5J7g1OCEA X-IronPort-AV: E=Sophos;i="4.97,1003,1389744000"; d="scan'208";a="41737425" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 07 May 2014 12:22:30 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s47CMUEJ004336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 12:22:30 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.89.2.182) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 May 2014 07:22:30 -0500 Message-ID: <536A2585.10906@cisco.com> Date: Wed, 7 May 2014 06:22:29 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Campbell References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.2.182] Archived-At: http://mailarchive.ietf.org/arch/msg/jose/TYYlWna3WMNzrJXT9QLubNQlw4k Cc: Antonio Sanso , "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 12:22:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Looks like I'm on double secret probation again (-: It's working as expected for my code. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 5/6/14, 10:53 PM, Brian Campbell wrote: > Thanks Matt. > > That is why I was looking for someone to verify using a different > platform. Though I was hoping it'd just work. > > Matt, can you try decrypting this one by chance? Using the same > key. I was more explicit with the parameters and, I think, MGF1 > should be using SHA-256 now too. > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > wrote: > > Short answer: You are all equally broken -- except from a certain > point of view d-: > > Long answer: The code I have is based on OpenSSL, which is > hard-coded to use SHA1 for the hash and mask generation (boo!), > which means one has to implement OAEP-SHA256 from scratch > (hiss!!). > > When I implemented it per RFC 3447 and > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > decrypt the provided results. When I hard-coded MGF1 to use > "SHA1", I could decrypt provided results. A search through > BouncyCastle's code shows that > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > evidence is shown with how [FORGE] can be made to work with Java > (search their homepage for "Compatible with Java's > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > Reconciling all of this with > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to > be very straight-forward. It appears that the JCA identifier is > meant to be "MGF1 with SHA1"; that ought to be explicitly noted. > The XMLENC reference is arguably incomplete, since > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this > can probably be addressed by explicitly stating the mask > generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > (MGF1 with SHA-256). > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaiWFAAoJEDWi+S0W7cO1008H/27io3RSL9QCvipxXFL4rmLu BqP3ZhUYwlbbzz0tA09iPE91EoanY6mKgCK0O0PJrUCIGl97M8fzZt9lwtv2jzCk W0uhE03M8mClIcMzubmIUFWntsM0ItyvFgHAlroIPbMX4gWMnEI+4qidITV/rQuL 3u/WXtpcafVWMfzlTZfqP5sws8iYXyicSQqtrZ4YXGNqVw5uSogOnt93QgY7Deyb UZJkVa6Ax2K844Smz4YEySwMLO91MeW27EHmFu6L1Kyer/NOedvdbMGIxsHKUJ+o /lXQWUF5ZqhB/Zsg25VtGYL1CVp00lHDlBq+riiyrtbcNNdquHvXngV3pVAnt2s= =/ujW -----END PGP SIGNATURE----- From nobody Wed May 7 05:35:15 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF23E1A02B2 for ; Wed, 7 May 2014 05:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55a3ypVrm1tg for ; Wed, 7 May 2014 05:35:13 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2D90E1A0227 for ; Wed, 7 May 2014 05:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4420; q=dns/txt; s=iport; t=1399466109; x=1400675709; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XsDSA0Q22V+6t7gOt3apsDT/zUd4ZX7RVWsfBSvmam8=; b=HWX54kQRpC7io4dD02Yr/FlGsjo8n5V3FVXEarbtpq87wUO67Ww6UZiu O+uKu3LvR8fESv02MhPGmKA+un+iRXf7MhZocuoXGHyZoIU/DHcBdgj2d qnM3gxgWJCg2IeTBrltV5AvYwrhmRVwYlyoHLQ6Z3Gimwv8RPxoXTF/r7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAMcnalOtJA2B/2dsb2JhbABagwZPWIJnqBoBAQeaDgGBGhZ0giUBAQEDASMPAUUBEAsRBAEBAQICBRYIAwICCQMCAQIBNAkIBgEMAQUCAQGINQgNqW6lQheBKoQshW2CXDMHBoJugUsBA4oIjy+Se4NTghA X-IronPort-AV: E=Sophos;i="4.97,1003,1389744000"; d="scan'208";a="41746842" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP; 07 May 2014 12:35:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s47CZ7b5004422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 12:35:07 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.89.2.182) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 May 2014 07:35:07 -0500 Message-ID: <536A287B.4030905@cisco.com> Date: Wed, 7 May 2014 06:35:07 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: , References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.89.2.182] Archived-At: http://mailarchive.ietf.org/arch/msg/jose/p5PMeEEEhGY1Co_h9t3F9XhnRUE Cc: asanso@adobe.com, jose@ietf.org Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 12:35:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de wrote: > I think that the java implementations implemented the spec and > everything is ok from that POV. > > These implementations are not broken. The JOSE Java implementations did not implement the spec, though. draft-ietf-jose-json-web-algorithms § 4.3 clearly states the hash and mask generation functions are to use the same algorithm -- SHA-1 (and MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with SHA-256) in the case of "RSA-OAEP-256". > > > > One could argue that when we replace SHA-1 by SHA-256 in one place > then we might consider to replace it in the padding too. That is exactly what draft-ietf-jose-json-web-algorithms specified. > > My feeling is that using sha-256 for the padding does not give us > more security. YMMW > That is a separate debate, I think. The prevailing opinion (at least around the IETF) is "don't mix the algorithms". - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > > > > > *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Brian > Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller > *Cc:* Antonio Sanso; jose@ietf.org *Subject:* Re: [jose] > RSA-OAEP-256 Example > > > > Thanks Matt. > > That is why I was looking for someone to verify using a different > platform. Though I was hoping it'd just work. > > Matt, can you try decrypting this one by chance? Using the same > key. I was more explicit with the parameters and, I think, MGF1 > should be using SHA-256 now too. > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w > > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > wrote: > > Short answer: You are all equally broken -- except from a certain > point of view d-: > > Long answer: The code I have is based on OpenSSL, which is > hard-coded to use SHA1 for the hash and mask generation (boo!), > which means one has to implement OAEP-SHA256 from scratch > (hiss!!). > > When I implemented it per RFC 3447 and > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > decrypt the provided results. When I hard-coded MGF1 to use > "SHA1", I could decrypt provided results. A search through > BouncyCastle's code shows that > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > evidence is shown with how [FORGE] can be made to work with Java > (search their homepage for "Compatible with Java's > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > Reconciling all of this with > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to > be very straight-forward. It appears that the JCA identifier is > meant to be "MGF1 with SHA1"; that ought to be explicitly noted. > The XMLENC reference is arguably incomplete, since > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this > can probably be addressed by explicitly stating the mask > generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > (MGF1 with SHA-256). > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6 oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y= =zfUl -----END PGP SIGNATURE----- From nobody Wed May 7 05:50:14 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08F41A06D0; Wed, 7 May 2014 04:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIqmOlCuS2M0; Wed, 7 May 2014 04:16:10 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 564911A06D1; Wed, 7 May 2014 04:16:10 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1114377wib.13 for ; Wed, 07 May 2014 04:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WpuzyB99vtnnitTFFUWDDnBbOh0lJsakZCavfucn0SM=; b=qbQf6s1KS9TZt/WOHgF4C/MXf2PkhFBpI7syf5hMWEJJ9cx9e+HFVcNLqyj/62f7lu LPW/vXILLHgGmb78gwAeAO80Y9I301Ra4TXT+PY5k/KDO6p4XAxmspGItzQXx3pxHolM rzlP3B81w3UxT+YeTYDSDRrUgyD5sTmWXydaDXhWr/c7+3ffbIv4SHmqcgo43namhgTl kpIIBoDu2gJkY1r7kXEqQsa4FO8DfLseDwoRC3RyvqfNeeA3dwysPDVRXl38Bf/xnbce Sx4JyQJdYJDDT5eS4zZDixa531TuJoZZKjhofMQGSkDDzbfdZjXh3csfWLyRZz8dee45 OcsQ== X-Received: by 10.180.93.226 with SMTP id cx2mr7331662wib.16.1399461365680; Wed, 07 May 2014 04:16:05 -0700 (PDT) Received: from [192.168.2.7] ([89.100.139.33]) by mx.google.com with ESMTPSA id xm20sm30944489wib.19.2014.05.07.04.16.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 04:16:04 -0700 (PDT) Message-ID: <536A15F3.7050203@gmail.com> Date: Wed, 07 May 2014 12:16:03 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian Campbell , "jose@ietf.org" References: <5363C88E.5070209@gmail.com> <5367C582.3010705@gmail.com> In-Reply-To: <5367C582.3010705@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Gc9NcNNPQeIsFZG37KXHgD8LWlQ X-Mailman-Approved-At: Wed, 07 May 2014 05:50:10 -0700 Cc: "" Subject: Re: [jose] [OAUTH-WG] [OT] Validation of JWE spec Appendix 1 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 11:16:12 -0000 Sorry for the noise, wanted to point out to the fact Section A.1.8 explicitly mentions "Note that since the RSAES OAEP computation includes random values, the encryption results above will not be completely reproducible". I wish I read that section first :-) Thanks all, Sergey On 05/05/14 18:08, Sergey Beryozkin wrote: > Hi Brian > On 03/05/14 14:36, Brian Campbell wrote: >> Hi Sergey, >> >> This question might be more appropriate for the JOSE WG [0] list (which >> I've cc'd) as JWE is being developed there. >> > Sure, I'll be asking at [0] next time... >> Some of the algorithms, RSAES OAEP being one of them, are probabilistic >> encryption schemes which incorporate some element of randomness to yield >> a different output even when encrypting the same content multiple times. >> So the behavior you are observing is to be expected. >> > I was starting blaming myself for the fact I could not get the code > producing a match :-) >> That means that exactly reproducing the various steps of the examples in >> the specs will not be possible in some cases. I was recently discussing >> this off list with Matt Miller, the author of the JOSE Cookbook [1], and >> my suggestion was to have the cookbook just make note of which examples, >> or which parts of which examples, can't be easily reproduced due to >> non-deterministic algorithms. I think that your question here suggests >> that that idea might well provide utility to users/readers of that >> document. >> > +1 > > Thanks for the help, > Sergey > >> Hope that helps, >> Brian >> >> >> [0] http://tools.ietf.org/wg/jose/ >> [1] http://tools.ietf.org/html/draft-ietf-jose-cookbook-02 >> >> >> >> >> >> >> On Fri, May 2, 2014 at 10:32 AM, Sergey Beryozkin > > wrote: >> >> Hi, >> >> I'm starting experimenting with JWE, and the 1st thing I wanted to >> do was to quickly test the example at [1]. >> >> Sorry if it is something that is very obvious and off-topic, but I >> can't seem to validate the encryption of the content encryption key: >> I keep getting a different output every time the test code runs. >> >> The code is the one that I wrote by 'scraping' the code from all >> over the Web but also I see Jose.4.j [3] produces a different output >> too. >> Is it due to the given key properties specified in [1] or it is >> actually indeed expected that production at [2] is reproducible ? >> >> Cheers, Sergey >> >> [1] >> >> http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1 >> >> >> >> >> [2] >> >> http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-26#appendix-A.1.3 >> >> >> >> >> [3] https://bitbucket.org/b_c/__jose4j/wiki/Home >> >> >> _________________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/__listinfo/oauth >> >> >> >> >> >> -- >> Ping Identity logo >> Brian Campbell >> [Enter Title] >> @ bcampbell@pingidentity.com >> phone +1 720.317.2061 >> Connect with us… >> twitter logo youtube logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> slideshare logo >> flipboard logo >> rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity Revolution | >> 19–23 July, 2014 | Monterey, CA >> >> > > From nobody Wed May 7 06:29:58 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291741A02F3 for ; Wed, 7 May 2014 06:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rvf1MAwf9fG for ; Wed, 7 May 2014 06:29:54 -0700 (PDT) Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD331A02E7 for ; Wed, 7 May 2014 06:29:54 -0700 (PDT) Received: from mail-ig0-f178.google.com ([209.85.213.178]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKU2o1TatzB6bZW7ph8T40NS3p1MX9vghN@postini.com; Wed, 07 May 2014 06:29:50 PDT Received: by mail-ig0-f178.google.com with SMTP id hl10so1076374igb.5 for ; Wed, 07 May 2014 06:29:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=r5SpYD7mjnDkV6mZO0J88331mFsc7QXonebFZ+Gep3U=; b=NDalm0slzv13ERptxSe3q7HF9U0Hr61pmBIo0a97klVPnMH5N9QW3mWnrwlWWc8Mhf Cuz6hwo381Z4IIunwTQefgUy+iql3Ec6lIOA5Kju951G2UX+e8d38Xetg0v9zruq9pX4 n/o6OEnlbtqcUYrE+zsE6Ko9f4NPDQR0nK8nNFQMwJroYT2+qhzeWsDcTO2fd1271CMb Lte9SNqfuC76WTZKd1TAz49gddnAhpiKXE39ea1oTM7lA2QNZmbeboxqhA1M52uf1w+l iBh2IC+lHm0h4UC1yR0sm4pfVKG/oKYXPkUH9poI4AvSh2Kh9oGp68VV8Sq+aPdNK/TI 75TQ== X-Gm-Message-State: ALoCoQkqcFBYQ8q6Obja4i92CzDdSJTG3XrZbnYZrdFAXyDS/N8TplMZcVz2VH8muEkosaW1DSMb73i0RGK2A5+FauYt7F65lpfYPQD7wjoOe97pE445kQxxDw7+wbFZyEQdkhl4YNZv X-Received: by 10.50.13.100 with SMTP id g4mr43991153igc.9.1399469389376; Wed, 07 May 2014 06:29:49 -0700 (PDT) X-Received: by 10.50.13.100 with SMTP id g4mr43991133igc.9.1399469389239; Wed, 07 May 2014 06:29:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Wed, 7 May 2014 06:29:18 -0700 (PDT) In-Reply-To: <536A287B.4030905@cisco.com> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> From: Brian Campbell Date: Wed, 7 May 2014 06:29:18 -0700 Message-ID: To: Matt Miller Content-Type: multipart/alternative; boundary=089e013c6614d1f17704f8cf5b16 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/bHqqGKDvprDDDlcouGTVPK4Zfm0 Cc: Antonio Sanso , "jose@ietf.org" , Axel Nennker Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:29:57 -0000 --089e013c6614d1f17704f8cf5b16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks again Matt for checking my homework. As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" transformation to get a cipher instance but then also initialized it with the OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT), which is what gets MGF to use SHA2 as well. I did run into the issue that Antonio pointed out [0]. Thanks BTW, I didn't really see the applicability of it when you sent it yesterday but having the reference was very helpful later. FWIW, I didn't use Bouncy Castle but rather the default Sun/Oracle provider with Java 8, which seems to have fixed that issue between 7 & 8. I'm not sure how to articulate all that in the JWA's Key Management Algorithm Identifier Cross-Reference [1] as "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" is correct but not sufficient. And as Matt pointed out, the XMLENC cross-ref probably isn't quite right either= . I also agree with Matt that my first attempt at this as well as the other Java based implementations yesterday were not properly implementing the spec, which is pretty clear about "RSAES OAEP using SHA-256 and MGF1 with SHA-256" [2]. And that MGF1 with SHA-256 vs SHA-1 for RSAES OAEP using SHA-256 is a separate debate but, as JWA is written now, it's MGF1 with SHA-256. Given that this RSA-OAEP-256 was added at the request of the AD, it's likely to be a short debate. [0] https://bugs.openjdk.java.net/browse/JDK-7038158 [1] http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.ap= pendix.A.1 [2] tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryption= RSAOAEP On Wed, May 7, 2014 at 5:35 AM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de wrote: > > I think that the java implementations implemented the spec and > > everything is ok from that POV. > > > > These implementations are not broken. > > The JOSE Java implementations did not implement the spec, though. > draft-ietf-jose-json-web-algorithms =C2=A7 4.3 clearly states the hash an= d > mask generation functions are to use the same algorithm -- SHA-1 (and > MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with > SHA-256) in the case of "RSA-OAEP-256". > > > > > > > > > One could argue that when we replace SHA-1 by SHA-256 in one place > > then we might consider to replace it in the padding too. > > That is exactly what draft-ietf-jose-json-web-algorithms specified. > > > > > My feeling is that using sha-256 for the padding does not give us > > more security. YMMW > > > > That is a separate debate, I think. The prevailing opinion (at least > around the IETF) is "don't mix the algorithms". > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > > > > > > > > > *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Brian > > Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller > > *Cc:* Antonio Sanso; jose@ietf.org *Subject:* Re: [jose] > > RSA-OAEP-256 Example > > > > > > > > Thanks Matt. > > > > That is why I was looking for someone to verify using a different > > platform. Though I was hoping it'd just work. > > > > Matt, can you try decrypting this one by chance? Using the same > > key. I was more explicit with the parameters and, I think, MGF1 > > should be using SHA-256 now too. > > > > > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9= G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKEN= YePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx= 2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3= GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuF= CmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGE= xCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgW= vM-08tIZ-h5w > > > > > > > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > > wrote: > > > > Short answer: You are all equally broken -- except from a certain > > point of view d-: > > > > Long answer: The code I have is based on OpenSSL, which is > > hard-coded to use SHA1 for the hash and mask generation (boo!), > > which means one has to implement OAEP-SHA256 from scratch > > (hiss!!). > > > > When I implemented it per RFC 3447 and > > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > > decrypt the provided results. When I hard-coded MGF1 to use > > "SHA1", I could decrypt provided results. A search through > > BouncyCastle's code shows that > > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of > > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > > evidence is shown with how [FORGE] can be made to work with Java > > (search their homepage for "Compatible with Java's > > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > > > Reconciling all of this with > > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to > > be very straight-forward. It appears that the JCA identifier is > > meant to be "MGF1 with SHA1"; that ought to be explicitly noted. > > The XMLENC reference is arguably incomplete, since > > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this > > can probably be addressed by explicitly stating the mask > > generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > > (MGF1 with SHA-256). > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P > KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6 > oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY > NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my > uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds > VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y=3D > =3DzfUl > -----END PGP SIGNATURE----- > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --089e013c6614d1f17704f8cf5b16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks again Matt for checking my homework.
<= br>
As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMG= F1Padding" transformation to get a cipher instance but then also initi= alized it with the OAEPParameterSpec("SHA-256", "MGF1",= MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT), which is what gets = MGF to use SHA2 as well.

I did run into the issue that Antonio pointed out [0]. Thank= s BTW, I didn't really see the applicability of it when you sent it yes= terday but having the reference was very helpful later. FWIW, I didn't = use Bouncy Castle but rather the default Sun/Oracle provider with Java 8, w= hich seems to have fixed that issue between 7 & 8.

I'm not sure how to articulate all that in the JWA's Key Manage= ment Algorithm Identifier Cross-Reference [1] as "RSA/ECB/OAEPWithSHA-= 256AndMGF1Padding" is correct but not sufficient. And as Matt pointed = out, the XMLENC cross-ref probably isn't quite right either.

I also agree with Matt that my first attempt at this as well= as the other Java based implementations yesterday were not properly implem= enting the spec, which is pretty clear about "RSAES OAEP using SHA-256= and MGF1 with SHA-256" [2]. And that MGF1 with SHA-256 vs SHA-1 for R= SAES OAEP using SHA-256 is a separate debate but, as JWA is written now, it= 's MGF1 with SHA-256.=C2=A0 Given that this RSA-OAEP-256 was added at t= he request of the AD, it's likely to be a short debate.


[0] ht= tps://bugs.openjdk.java.net/browse/JDK-7038158
[1] http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#= rfc.appendix.A.1
[2] tools.ietf.org/id/draft-ietf-jose-json-web-a= lgorithms-26.html#KeyEncryptionRSAOAEP


=C2=A0


On Wed, May 7, 2014 at 5:35 AM, Matt Mil= ler <mamille2@cisco.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de wrote:
> I think that the java implementations implemented the spec and
> everything is ok from that POV.
>
> These implementations are not broken.

The JOSE Java implementations did not implement the spec, though.
draft-ietf-jose-json-web-algorithms =C2=A7 4.3 clearly states the hash and<= br> mask generation functions are to use the same algorithm -- SHA-1 (and
MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1= with
SHA-256) in the case of "RSA-OAEP-256".

>
>
>
> One could argue that when we replace SHA-1 by SHA-256 in one place
> then we might consider to replace it in the padding too.

That is exactly what draft-ietf-jose-json-web-algorithms specified.

>
> My feeling is that using sha-256 for the padding does not give us
> more security. YMMW
>

That is a separate debate, I think. =C2=A0The prevailing opinion (at = least
around the IETF) is "don't mix the algorithms".
> *From:*jose [mailto:jos= e-bounces@ietf.org] *On Behalf Of *Brian
> Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller
> *Cc:* Antonio Sanso; jose@ietf.org *Subject:* Re: [jose]
> <mailto:mamille2@cisco.com>> wrote:
>
> Short answer: You are all equally broken -- except from a certain
> point of view d-:
>
> Long answer: The code I have is based on OpenSSL, which is
> hard-coded to use SHA1 for the hash and mask generation (boo!),
> which means one has to implement OAEP-SHA256 from scratch
> (hiss!!).
>
> When I implemented it per RFC 3447 and
> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
> decrypt the provided results. =C2=A0When I hard-coded MGF1 to use
> "SHA1", I could decrypt provided results. =C2=A0A search thr= ough
> BouncyCastle's code shows that
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function= of
> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Furt= her
> evidence is shown with how [FORGE] can be made to work with Java
> (search their homepage for "Compatible with Java's
> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").
>
> Reconciling all of this with
> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to
> be very straight-forward. =C2=A0It appears that the JCA identifier is<= br> > meant to be "MGF1 with SHA1"; that ought to be explicitly no= ted.
> The XMLENC reference is arguably incomplete, since
> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1);= this
> can probably be addressed by explicitly stating the mask
> generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256<= /a>"
> (MGF1 with SHA-256).
>
>
>
>
>
iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P
KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6
oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY
NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my
uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds
VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y=3D
=3DzfUl
-----END PGP SIGNATURE-----



--
--089e013c6614d1f17704f8cf5b16-- From nobody Wed May 7 07:12:49 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888811A0874 for ; Wed, 7 May 2014 07:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWlDRERkv9-j for ; Wed, 7 May 2014 07:12:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A48881A0772 for ; Wed, 7 May 2014 07:12:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5DC511F067D; Wed, 7 May 2014 10:12:39 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4731D1F06A4; Wed, 7 May 2014 10:12:39 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Wed, 7 May 2014 10:12:38 -0400 From: "Richer, Justin P." To: Brian Campbell Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaaXt6y9pFg73WUeWYaQCNSAO4Zs00HCAgAA5+gCAAEbmgIAADyMAgAAMIwA= Date: Wed, 7 May 2014 14:12:38 +0000 Message-ID: <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.10.111] Content-Type: multipart/alternative; boundary="_000_04474579887847FB821845B6EE618C6Fmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/4Bv4WXB4i5nWjISw4h7dc878jEc Cc: Antonio Sanso , Axel Nennker , "jose@ietf.org" , Matt Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:12:47 -0000 --_000_04474579887847FB821845B6EE618C6Fmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I've updated the Nimbus library to use the different hash, and the new toke= n works under BouncyCastle in Java7. I did hit the bug mentioned [0] when r= unning with the Sun provider. Also important, the old token doesn't work an= ymore. -- Justin On May 7, 2014, at 9:29 AM, Brian Campbell > wrote: Thanks again Matt for checking my homework. As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" tra= nsformation to get a cipher instance but then also initialized it with the = OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpe= cified.DEFAULT), which is what gets MGF to use SHA2 as well. I did run into the issue that Antonio pointed out [0]. Thanks BTW, I didn't= really see the applicability of it when you sent it yesterday but having t= he reference was very helpful later. FWIW, I didn't use Bouncy Castle but r= ather the default Sun/Oracle provider with Java 8, which seems to have fixe= d that issue between 7 & 8. I'm not sure how to articulate all that in the JWA's Key Management Algorit= hm Identifier Cross-Reference [1] as "RSA/ECB/OAEPWithSHA-256AndMGF1Padding= " is correct but not sufficient. And as Matt pointed out, the XMLENC cross-= ref probably isn't quite right either. I also agree with Matt that my first attempt at this as well as the other J= ava based implementations yesterday were not properly implementing the spec= , which is pretty clear about "RSAES OAEP using SHA-256 and MGF1 with SHA-2= 56" [2]. And that MGF1 with SHA-256 vs SHA-1 for RSAES OAEP using SHA-256 i= s a separate debate but, as JWA is written now, it's MGF1 with SHA-256. Gi= ven that this RSA-OAEP-256 was added at the request of the AD, it's likely = to be a short debate. [0] https://bugs.openjdk.java.net/browse/JDK-7038158 [1] http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rf= c.appendix.A.1 [2] tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryp= tionRSAOAEP On Wed, May 7, 2014 at 5:35 AM, Matt Miller > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de= wrote: > I think that the java implementations implemented the spec and > everything is ok from that POV. > > These implementations are not broken. The JOSE Java implementations did not implement the spec, though. draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash and mask generation functions are to use the same algorithm -- SHA-1 (and MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with SHA-256) in the case of "RSA-OAEP-256". > > > > One could argue that when we replace SHA-1 by SHA-256 in one place > then we might consider to replace it in the padding too. That is exactly what draft-ietf-jose-json-web-algorithms specified. > > My feeling is that using sha-256 for the padding does not give us > more security. YMMW > That is a separate debate, I think. The prevailing opinion (at least around the IETF) is "don't mix the algorithms". - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > > > > > *From:*jose [mailto:jose-bounces@ietf.org] = *On Behalf Of *Brian > Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller > *Cc:* Antonio Sanso; jose@ietf.org *Subject:* Re: [= jose] > RSA-OAEP-256 Example > > > > Thanks Matt. > > That is why I was looking for someone to verify using a different > platform. Though I was hoping it'd just work. > > Matt, can you try decrypting this one by chance? Using the same > key. I was more explicit with the parameters and, I think, MGF1 > should be using SHA-256 now too. > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9= G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKEN= YePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx= 2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3= GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuF= CmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGE= xCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgW= vM-08tIZ-h5w > > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > >> wrote: > > Short answer: You are all equally broken -- except from a certain > point of view d-: > > Long answer: The code I have is based on OpenSSL, which is > hard-coded to use SHA1 for the hash and mask generation (boo!), > which means one has to implement OAEP-SHA256 from scratch > (hiss!!). > > When I implemented it per RFC 3447 and > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > decrypt the provided results. When I hard-coded MGF1 to use > "SHA1", I could decrypt provided results. A search through > BouncyCastle's code shows that > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > evidence is shown with how [FORGE] can be made to work with Java > (search their homepage for "Compatible with Java's > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > Reconciling all of this with > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to > be very straight-forward. It appears that the JCA identifier is > meant to be "MGF1 with SHA1"; that ought to be explicitly noted. > The XMLENC reference is arguably incomplete, since > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this > can probably be addressed by explicitly stating the mask > generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > (MGF1 with SHA-256). > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6 oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y=3D =3DzfUl -----END PGP SIGNATURE----- -- [Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us=85 [twitter logo] [youtube logo] [LinkedIn logo] [Facebook logo] [Google+ logo] [s= lideshare logo] [flipboard logo] = [rss feed icon] [Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19= =9623 July, 2014 | Monterey, CA] _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_04474579887847FB821845B6EE618C6Fmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9715E13787E5CB4082B26C88D85B427B@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I've updated the Nimbus library to use the different hash, and the new toke= n works under BouncyCastle in Java7. I did hit the bug mentioned [0] w= hen running with the Sun provider. Also important, the old token doesn't wo= rk anymore. 

 -- Justin

On May 7, 2014, at 9:29 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks again Matt for checking my homework.

As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMGF1Padding= " transformation to get a cipher instance but then also initialized it= with the OAEPParameterSpec("SHA-256", "MGF1", MGF1Para= meterSpec.SHA256, PSource.PSpecified.DEFAULT), which is what gets MGF to use SHA2 as well.

I did run into the issue that Antonio pointed out [0]. Thanks BTW, I d= idn't really see the applicability of it when you sent it yesterday but hav= ing the reference was very helpful later. FWIW, I didn't use Bouncy Castle = but rather the default Sun/Oracle provider with Java 8, which seems to have fixed that issue between 7 &= 8.

I'm not sure how to articulate all that in the JWA's Key Management Algorit= hm Identifier Cross-Reference [1] as "RSA/ECB/OAEPWithSHA-256AndMGF1Pa= dding" is correct but not sufficient. And as Matt pointed out, the XML= ENC cross-ref probably isn't quite right either.

I also agree with Matt that my first attempt at this as well as the ot= her Java based implementations yesterday were not properly implementing the= spec, which is pretty clear about "RSAES OAEP using SHA-256 and MGF1 = with SHA-256" [2]. And that MGF1 with SHA-256 vs SHA-1 for RSAES OAEP using SHA-256 is a separate debate but, as= JWA is written now, it's MGF1 with SHA-256.  Given that this RSA-OAEP= -256 was added at the request of the AD, it's likely to be a short debate.<= br>

[0] https://bu= gs.openjdk.java.net/browse/JDK-7038158
[1] http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.ap= pendix.A.1
[2] tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryption= RSAOAEP


 


On Wed, May 7, 2014 at 5:35 AM, Matt Miller <mamille2@cisco.= com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de wrote:
> I think that the java implementations implemented the spec and
> everything is ok from that POV.
>
> These implementations are not broken.

The JOSE Java implementations did not implement the spec, though.
draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash and
mask generation functions are to use the same algorithm -- SHA-1 (and
MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1= with
SHA-256) in the case of "RSA-OAEP-256".

>
>
>
> One could argue that when we replace SHA-1 by SHA-256 in one place
> then we might consider to replace it in the padding too.

That is exactly what draft-ietf-jose-json-web-algorithms specified.

>
> My feeling is that using sha-256 for the padding does not give us
> more security. YMMW
>

That is a separate debate, I think.  The prevailing opinion (at least<= br> around the IETF) is "don't mix the algorithms".
> *From:*jose [mailto:jose-boun= ces@ietf.org] *On Behalf Of *Brian
> Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller
> *Cc:* Antonio Sanso; jose@ietf.org *Subject:* Re: [jose]
> <mailto:mam= ille2@cisco.com>> wrote:
>
> Short answer: You are all equally broken -- except from a certain
> point of view d-:
>
> Long answer: The code I have is based on OpenSSL, which is
> hard-coded to use SHA1 for the hash and mask generation (boo!),
> which means one has to implement OAEP-SHA256 from scratch
> (hiss!!).
>
> When I implemented it per RFC 3447 and
> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
> decrypt the provided results.  When I hard-coded MGF1 to use
> "SHA1", I could decrypt provided results.  A search thr= ough
> BouncyCastle's code shows that
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function= of
> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Furt= her
> evidence is shown with how [FORGE] can be made to work with Java
> (search their homepage for "Compatible with Java's
> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").
>
> Reconciling all of this with
> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to
> be very straight-forward.  It appears that the JCA identifier is<= br> > meant to be "MGF1 with SHA1"; that ought to be explicitly no= ted.
> The XMLENC reference is arguably incomplete, since
> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1);= this
> can probably be addressed by explicitly stating the mask
> generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256<= /a>"
> (MGF1 with SHA-256).
>
>
>
>
>
iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P
KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6
oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY
NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my
uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds
VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y=3D<= br> =3DzfUl
-----END PGP SIGNATURE-----



--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061<= /font>
Connect with us=85
3D"= 3D"youtube<= /a> 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register

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

--_000_04474579887847FB821845B6EE618C6Fmitreorg_-- From nobody Wed May 7 07:23:57 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E29C1A00DF for ; Wed, 7 May 2014 07:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56yMhih6k1T1 for ; Wed, 7 May 2014 07:23:49 -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 50A381A0061 for ; Wed, 7 May 2014 07:23:49 -0700 (PDT) Received: from CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) by CO1PR02MB240.namprd02.prod.outlook.com (10.242.165.155) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 14:23:37 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 14:23:35 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0934.000; Wed, 7 May 2014 14:23:35 +0000 From: Antonio Sanso To: "Richer, Justin P." Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUAgABAhACAAAElAIAAAQQAgAAHpICAAOTKgIAAFNOAgAA5+wCAAEblgIAADyQAgAAMGwCAAAMegA== Date: Wed, 7 May 2014 14:23:34 +0000 Message-ID: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> In-Reply-To: <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.147.117.11] x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(377454003)(189002)(43784003)(199002)(479174003)(51704005)(24454002)(74662001)(80022001)(76482001)(15198665003)(66066001)(99396002)(81342001)(81542001)(46102001)(74502001)(50986999)(99286001)(77982001)(31966008)(36756003)(64706001)(19618635001)(15202345003)(16297215004)(4396001)(87936001)(2656002)(101416001)(92566001)(85852003)(18206015023)(86362001)(33656001)(19580395003)(15975445006)(83072002)(19580405001)(21056001)(82746002)(19273905006)(92726001)(76176999)(54356999)(83716003)(20776003)(79102001)(575784001)(19617315010)(83322001)(15395725003)(16236675002)(9984715005)(19621445023); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; Content-Type: multipart/alternative; boundary="_000_C4F202FB5B5E4A6FBB00870C01A60005adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/gmUS4vht3P0LLnSLNVVaH3_f7pk Cc: Brian Campbell , Axel Nennker , "jose@ietf.org" , Matt Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:23:55 -0000 --_000_C4F202FB5B5E4A6FBB00870C01A60005adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On May 7, 2014, at 4:12 PM, Richer, Justin P. > wrote: I've updated the Nimbus library to use the different hash, and the new toke= n works under BouncyCastle in Java7. I did hit the bug mentioned [0] when r= unning with the Sun provider. I suppose you are using Java 8 so... regards antonio Also important, the old token doesn't work anymore. -- Justin On May 7, 2014, at 9:29 AM, Brian Campbell > wrote: Thanks again Matt for checking my homework. As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" tra= nsformation to get a cipher instance but then also initialized it with the = OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpe= cified.DEFAULT), which is what gets MGF to use SHA2 as well. I did run into the issue that Antonio pointed out [0]. Thanks BTW, I didn't= really see the applicability of it when you sent it yesterday but having t= he reference was very helpful later. FWIW, I didn't use Bouncy Castle but r= ather the default Sun/Oracle provider with Java 8, which seems to have fixe= d that issue between 7 & 8. I'm not sure how to articulate all that in the JWA's Key Management Algorit= hm Identifier Cross-Reference [1] as "RSA/ECB/OAEPWithSHA-256AndMGF1Padding= " is correct but not sufficient. And as Matt pointed out, the XMLENC cross-= ref probably isn't quite right either. I also agree with Matt that my first attempt at this as well as the other J= ava based implementations yesterday were not properly implementing the spec= , which is pretty clear about "RSAES OAEP using SHA-256 and MGF1 with SHA-2= 56" [2]. And that MGF1 with SHA-256 vs SHA-1 for RSAES OAEP using SHA-256 i= s a separate debate but, as JWA is written now, it's MGF1 with SHA-256. Gi= ven that this RSA-OAEP-256 was added at the request of the AD, it's likely = to be a short debate. [0] https://bugs.openjdk.java.net/browse/JDK-7038158 [1] http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rf= c.appendix.A.1 [2] tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryp= tionRSAOAEP On Wed, May 7, 2014 at 5:35 AM, Matt Miller > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de= wrote: > I think that the java implementations implemented the spec and > everything is ok from that POV. > > These implementations are not broken. The JOSE Java implementations did not implement the spec, though. draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash and mask generation functions are to use the same algorithm -- SHA-1 (and MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with SHA-256) in the case of "RSA-OAEP-256". > > > > One could argue that when we replace SHA-1 by SHA-256 in one place > then we might consider to replace it in the padding too. That is exactly what draft-ietf-jose-json-web-algorithms specified. > > My feeling is that using sha-256 for the padding does not give us > more security. YMMW > That is a separate debate, I think. The prevailing opinion (at least around the IETF) is "don't mix the algorithms". - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > > > > > *From:*jose [mailto:jose-bounces@ietf.org] = *On Behalf Of *Brian > Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller > *Cc:* Antonio Sanso; jose@ietf.org *Subject:* Re: [= jose] > RSA-OAEP-256 Example > > > > Thanks Matt. > > That is why I was looking for someone to verify using a different > platform. Though I was hoping it'd just work. > > Matt, can you try decrypting this one by chance? Using the same > key. I was more explicit with the parameters and, I think, MGF1 > should be using SHA-256 now too. > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9= G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKEN= YePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx= 2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3= GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuF= CmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGE= xCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgW= vM-08tIZ-h5w > > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > >> wrote: > > Short answer: You are all equally broken -- except from a certain > point of view d-: > > Long answer: The code I have is based on OpenSSL, which is > hard-coded to use SHA1 for the hash and mask generation (boo!), > which means one has to implement OAEP-SHA256 from scratch > (hiss!!). > > When I implemented it per RFC 3447 and > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > decrypt the provided results. When I hard-coded MGF1 to use > "SHA1", I could decrypt provided results. A search through > BouncyCastle's code shows that > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > evidence is shown with how [FORGE] can be made to work with Java > (search their homepage for "Compatible with Java's > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > Reconciling all of this with > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to > be very straight-forward. It appears that the JCA identifier is > meant to be "MGF1 with SHA1"; that ought to be explicitly noted. > The XMLENC reference is arguably incomplete, since > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this > can probably be addressed by explicitly stating the mask > generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > (MGF1 with SHA-256). > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6 oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y=3D =3DzfUl -----END PGP SIGNATURE----- -- [Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us=85 [twitter logo] [youtube logo] [LinkedIn logo] [Facebook logo] [Google+ logo] [s= lideshare logo] [flipboard logo] = [rss feed icon] [Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19= =9623 July, 2014 | Monterey, CA] _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_C4F202FB5B5E4A6FBB00870C01A60005adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4C478624B37A264F93079DE7C6CED29E@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On May 7, 2014, at 4:12 PM, Richer, Justin P. <jricher@mitre.org> wrote:

I've updated the Nimbus library to use the different hash, and the new toke= n works under BouncyCastle in Java7. I did hit the bug mentioned [0] w= hen running with the Sun provider.

I suppose you are using Java 8 so...

regards

antonio

Also important, the old token doesn't work anymore. 

 -- Justin

On May 7, 2014, at 9:29 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks again Matt for checking my homework.

As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMGF1Padding= " transformation to get a cipher instance but then also initialized it= with the OAEPParameterSpec("SHA-256", "MGF1", MGF1Para= meterSpec.SHA256, PSource.PSpecified.DEFAULT), which is what gets MGF to use SHA2 as well.

I did run into the issue that Antonio pointed out [0]. Thanks BTW, I d= idn't really see the applicability of it when you sent it yesterday but hav= ing the reference was very helpful later. FWIW, I didn't use Bouncy Castle = but rather the default Sun/Oracle provider with Java 8, which seems to have fixed that issue between 7 &= 8.

I'm not sure how to articulate all that in the JWA's Key Management Algorit= hm Identifier Cross-Reference [1] as "RSA/ECB/OAEPWithSHA-256AndMGF1Pa= dding" is correct but not sufficient. And as Matt pointed out, the XML= ENC cross-ref probably isn't quite right either.

I also agree with Matt that my first attempt at this as well as the ot= her Java based implementations yesterday were not properly implementing the= spec, which is pretty clear about "RSAES OAEP using SHA-256 and MGF1 = with SHA-256" [2]. And that MGF1 with SHA-256 vs SHA-1 for RSAES OAEP using SHA-256 is a separate debate but, as= JWA is written now, it's MGF1 with SHA-256.  Given that this RSA-OAEP= -256 was added at the request of the AD, it's likely to be a short debate.<= br>

[0] https://bu= gs.openjdk.java.net/browse/JDK-7038158
[1] http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.ap= pendix.A.1
[2] tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryption= RSAOAEP


 


On Wed, May 7, 2014 at 5:35 AM, Matt Miller <mamille2@cisco.= com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de wrote:
> I think that the java implementations implemented the spec and
> everything is ok from that POV.
>
> These implementations are not broken.

The JOSE Java implementations did not implement the spec, though.
draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash and
mask generation functions are to use the same algorithm -- SHA-1 (and
MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1= with
SHA-256) in the case of "RSA-OAEP-256".

>
>
>
> One could argue that when we replace SHA-1 by SHA-256 in one place
> then we might consider to replace it in the padding too.

That is exactly what draft-ietf-jose-json-web-algorithms specified.

>
> My feeling is that using sha-256 for the padding does not give us
> more security. YMMW
>

That is a separate debate, I think.  The prevailing opinion (at least<= br> around the IETF) is "don't mix the algorithms".
> *From:*jose [mailto:jose-boun= ces@ietf.org] *On Behalf Of *Brian
> Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller
> *Cc:* Antonio Sanso; jose@ietf.org *Subject:* Re: [jose]
> <mailto:mam= ille2@cisco.com>> wrote:
>
> Short answer: You are all equally broken -- except from a certain
> point of view d-:
>
> Long answer: The code I have is based on OpenSSL, which is
> hard-coded to use SHA1 for the hash and mask generation (boo!),
> which means one has to implement OAEP-SHA256 from scratch
> (hiss!!).
>
> When I implemented it per RFC 3447 and
> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
> decrypt the provided results.  When I hard-coded MGF1 to use
> "SHA1", I could decrypt provided results.  A search thr= ough
> BouncyCastle's code shows that
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function= of
> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Furt= her
> evidence is shown with how [FORGE] can be made to work with Java
> (search their homepage for "Compatible with Java's
> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").
>
> Reconciling all of this with
> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to
> be very straight-forward.  It appears that the JCA identifier is<= br> > meant to be "MGF1 with SHA1"; that ought to be explicitly no= ted.
> The XMLENC reference is arguably incomplete, since
> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1);= this
> can probably be addressed by explicitly stating the mask
> generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256<= /a>"
> (MGF1 with SHA-256).
>
>
>
>
>
iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P
KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6
oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY
NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my
uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds
VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y=3D<= br> =3DzfUl
-----END PGP SIGNATURE-----



--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061<= /font>
Connect with us=85
3D"= 3D"youtube<= /a> 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register

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


--_000_C4F202FB5B5E4A6FBB00870C01A60005adobecom_-- From nobody Wed May 7 07:31:08 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6DD1A0779 for ; Wed, 7 May 2014 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0z5vUCEkrbK for ; Wed, 7 May 2014 07:31:02 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id BA11C1A0780 for ; Wed, 7 May 2014 07:31:01 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 07 May 2014 16:30:55 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Wed, 7 May 2014 16:30:55 +0200 From: To: , Date: Wed, 7 May 2014 16:30:49 +0200 Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaN0j6y9pFg73WUeWYaQCNSAO4ZszSwUAgABAhACAAAElAIAAAQQAgAAHpICAAOTKgIAAFNOAgAA5+wCAAEblgIAADyQAgAAMGwCAAAMegIAAAFgA Message-ID: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> In-Reply-To: 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_CE8995AB5D178F44A2154F5C9A97CAF402631C603DFAHE111541eme_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/9clbT1W8bEOiYRhx9-y2Nnr78uQ Cc: bcampbell@pingidentity.com, jose@ietf.org, mamille2@cisco.com Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:31:06 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C603DFAHE111541eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" mean that SHA-256 must be used f= or padding too? I did not read it so. Did somebody manage to use JCA correctly with one algorithm specifier like = RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256? Axel A.2. Key Management Algorithm Identifier Cross-Reference This section contains a table cross-referencing the JWE alg (algorithm) val= ues defined in this specification with the equivalent identifiers used by o= ther standards and software packages. JWE XML ENC JCA OID RSA1_5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 RSA/ECB/PKCS1Padding 1.2.840.113549.1.1.1 RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p RSA/ECB/OAEPWithSHA-1AndMGF1Padding 1.2.840.113549.1.1.7 RSA-OAEP-256 http://www.w3.org/2009/xmlenc11#rsa-oaep RSA/ECB/OAEPWithSHA-256AndMGF1Padding 1.2.840.113549.1.1.7 -----Original Message----- From: Antonio Sanso [mailto:asanso@adobe.com] Sent: Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian Campbell; Matt Miller; jose@ietf.org; Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de> wrote: > I think that the java implementations implemented the spec and > everything is ok from that POV. > > These implementations are not broken. The JOSE Java implementations did not implement the spec, though. draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash and mas= k generation functions are to use the same algorithm -- SHA-1 (and MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with SHA-256) in the case of "RSA-OAEP-256". > > > > One could argue that when we replace SHA-1 by SHA-256 in one place > then we might consider to replace it in the padding too. That is exactly what draft-ietf-jose-json-web-algorithms specified. > > My feeling is that using sha-256 for the padding does not give us more > security. YMMW > That is a separate debate, I think. The prevailing opinion (at least aroun= d the IETF) is "don't mix the algorithms". -- - m&m Matt Miller < mamille2@cisco.com> > Cisco Systems, Inc. > > > > > *From:*jose > [mailto:jose-bounces@ietf.org] *On > Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM > *To:* Matt Miller > *Cc:* Antonio Sanso; jose@ietf.org> *Subject:* > Re: [jose] > RSA-OAEP-256 Example > > > > Thanks Matt. > > That is why I was looking for someone to verify using a different > platform. Though I was hoping it'd just work. > > Matt, can you try decrypting this one by chance? Using the same key. I > was more explicit with the parameters and, I think, MGF1 should be > using SHA-256 now too. > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj > jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ > 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi > OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j > L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu > BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9 > _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G > Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w > > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > > > >>> wrote: > > Short answer: You are all equally broken -- except from a certain > point of view d-: > > Long answer: The code I have is based on OpenSSL, which is hard-coded > to use SHA1 for the hash and mask generation (boo!), which means one > has to implement OAEP-SHA256 from scratch (hiss!!). > > When I implemented it per RFC 3447 and > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I > could decrypt provided results. A search through BouncyCastle's code > shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash > function of > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > evidence is shown with how [FORGE] can be made to work with Java > (search their homepage for "Compatible with Java's > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > Reconciling all of this with > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be > very straight-forward. It appears that the JCA identifier is meant to > be "MGF1 with SHA1"; that ought to be explicitly noted. > The XMLENC reference is arguably incomplete, since > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can > probably be addressed by explicitly stating the mask generation > function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > (MGF1 with SHA-256). > > > > > --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C603DFAHE111541eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does “R= SA/ECB/OAEPWithSHA-1AndMGF1Padding” mean that SHA-256 must be used fo= r padding too?

I did not read it so.<= o:p>

Did somebody manage to use JCA correc= tly with one algorithm specifier like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWi= thSHA-256?

 

Axel

A.2. <= a href=3D"http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.h= tml#EncAlgXref" id=3DEncAlgXref>Key Management Algorithm Identifier Cross-R= eference

This section contai= ns a table cross-referencing the JWE alg (algorithm) values de= fined in this specification with the equivalent identifiers used by other s= tandards and software packages.

<= /tr>=

http://= www.w3.org/2009/xmlenc11#rsa-oaep

JWE

XML ENC=

JCA

= OID

RSA1_5

<= /td>

= http://www.w3.org/2001/04/xmlenc#rsa-1_5

=

RSA/ECB/PKCS1Padding<= o:p>

1.2.840.113549.1.1.1=

RSA-OAEP

=

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

RSA/ECB/OAEPWithSHA-1AndMG= F1Padding

1.2.840.11= 3549.1.1.7

= RSA-OAEP-256

RSA/ECB/OAEPWithSHA-256AndMGF1Padding

1.2.840.113549.1.1.7

<= o:p> 

 

-----Original Message-----
From: Antonio Sanso [mailto:a= sanso@adobe.com]
Sent: Wednesday, May 07, 2014 4:24 PM
To: Richer, J= ustin P.
Cc: Brian Campbell; Matt Miller; jose@ietf.org; Nennker, AxelSubject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example<= /p>

 

On = 5/7/14, 2:21 AM, Axe= l.Nennker@telekom.de<mailto:Axel.Nennker@telekom.de> wrote= :

> I think that the java implemen= tations implemented the spec and

>= ; everything is ok from that POV.

>= ; 

> These implementations ar= e not broken.

 

The JOSE Java implementations did not implement the s= pec, though.

draft-ietf-jose-json-web= -algorithms =A7 4.3 clearly states the hash and mask generation functions a= re to use the same algorithm -- SHA-1 (and

MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (an= d MGF1 with

SHA-256) in the case of &= quot;RSA-OAEP-256".

 <= /o:p>

> 

> 

> 

> One could argue that when we replace SHA= -1 by SHA-256 in one place

> then= we might consider to replace it in the padding too.

 

That is exactl= y what draft-ietf-jose-json-web-algorithms specified.

 

>&nbs= p;

> My feeling is that using sha-256 f= or the padding does not give us more

> security. YMMW

> <= /o:p>

 

That is a separate debate, I think.=A0 The prevailing opinion (at least = around the IETF) is "don't mix the algorithms".

 

&nbs= p;

--

- m&m

 

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

 =

> 

> 

> 

> 

&= gt; *From:*jose

> [mailto:jose-bounces@ietf.org<mai= lto:jose-bounces@ietf.org>] *On

> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:= 54 AM

> *To:* Matt Miller

> *Cc:* Antonio Sanso; jose@ietf.org<mailto:jose@ietf.org> *Subj= ect:*

> Re: [jose]

=

> RSA-OAEP-256 Example

> 

>&nbs= p;

> 

> Thanks Matt.

>=  

> That is why I was looking for = someone to verify using a different

= > platform. Though I was hoping it'd just work.

> 

> Matt,= can you try decrypting this one by chance? Using the same key. I

> was more explicit with the parameters an= d, I think, MGF1 should be

> usin= g SHA-256 now too.

> 

> 

> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL= 5cMCj

> jU9G9_ZjsD2XO0HIwTOwbVwulc= ZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ

> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eeh= bCA3gWpi

> OYHHvSTFdBPGx2KZHQisLz3= oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j

> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwB= yGpMleIQcPu

> BUseRRPr_OsroOJ6eTl5= DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9

> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yT= qTbqIqRCp2feAH5G

> Svluzmztk2_CkGN= SjAyoaw.4nMUXOgmgWvM-08tIZ-h5w

> 

> 

> 

>=  

> On Tue, May 6, 2014 at 8:39 PM= , Matt Miller

> <mamille2@cisco.com<mailto:mamille2@cisco= .com>

> <mailto:mamille2@cisco.com<mailto:m= amille2@cisco.com>>> wrote:

> 

> Short answ= er: You are all equally broken -- except from a certain

> point of view d-:

> 

> Long answer: Th= e code I have is based on OpenSSL, which is hard-coded

> to use SHA1 for the hash and mask generation (boo!)= , which means one

> has to implem= ent OAEP-SHA256 from scratch (hiss!!).

> 

> When I implemented = it per RFC 3447 and

> draft-ietf-= jose-json-web-algorithms-26#section-4.3, I could not

> decrypt the provided results.=A0 When I hard-coded MG= F1 to use "SHA1", I

> c= ould decrypt provided results.=A0 A search through BouncyCastle's code

> shows that "RSA/ECB/OAEPWithSH= A-256AndMGF1Padding" uses a Hash

> function of

> SHA-256 gener= ate the lHash but its MGF1 uses a "SHA-1". Further

> evidence is shown with how [FORGE] can be mad= e to work with Java

> (search the= ir homepage for "Compatible with Java's

> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

<= p class=3DMsoPlainText>> 

>= ; Reconciling all of this with

> d= raft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be

> very straight-forward.=A0 It appears t= hat the JCA identifier is meant to

&= gt; be "MGF1 with SHA1"; that ought to be explicitly noted.<= /o:p>

> The XMLENC reference is arguably inco= mplete, since

> "http://www.w3.org/2009/xmlenc11#rsa-oaep&qu= ot; defaults to

> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can

&= gt; probably be addressed by explicitly stating the mask generation

> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"

> (MGF1 with SHA-256).

> 

= > 

> 

<= p class=3DMsoPlainText>> 

>= ; 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402631C603DFAHE111541eme_-- From nobody Fri May 9 06:33:39 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A971A02A6 for ; Fri, 9 May 2014 06:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.076 X-Spam-Level: *** X-Spam-Status: No, score=3.076 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8C7vKnege4x for ; Fri, 9 May 2014 06:33:33 -0700 (PDT) Received: from psmtp.com (na3sys009aob139.obsmtp.com [74.125.149.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5B43C1A0085 for ; Fri, 9 May 2014 06:33:33 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob139.postini.com ([74.125.148.12]) with SMTP ID DSNKU2zZKMK1W8axFGuNI1BoQnqg9ooquc5G@postini.com; Fri, 09 May 2014 06:33:28 PDT Received: by mail-ig0-f177.google.com with SMTP id l13so1118689iga.16 for ; Fri, 09 May 2014 06:33:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=K8RBqEP5CkAXX3h1CoHh1XZiRBe69k8aEBr2kpBvEkM=; b=aXrpe1Go4ZN53ES0HGQbPEWgPYVH611sezipeIhKzdPpjWU6DMOgYQrCEuGLpGMy4J 5f2Uzf3JMlAsZxHnoSAB8WIxbcEW1t3voC2CrUNR7Pj0LYNQ3HjDw1lPTYFVDrMS4gGd vsw4gQDrJ5brZ6T7b4w2P19XjujdrybBaXhHcLMXemLpiEyRk2tURLUpKSSnsEIRYtn9 0SFRlY3Gj08FkOnxRb+EymKtKhsFOMasSUrVWAKIOGMs7vdMc+0ek17JZDGFM2/FwYQh AvePs5SSWAHDLGY4OrFOB62DXvpGgtknOULxcgVOYWqJXCPdidXqpAJkO92tCDgckMav U4oQ== X-Gm-Message-State: ALoCoQnoGbFidJ9T+WyXN6f5E1FBHRGOYO8QUd2DnqUdKVYLygw/cKdOztHXRE/2oMb275Z1JyFcv6uZb8nyp40BLeFkJWJ6142/cswWHmc5LjupTuI65qVcDXzwJma0GvlDV/624UWY X-Received: by 10.51.17.5 with SMTP id ga5mr9490951igd.2.1399642405572; Fri, 09 May 2014 06:33:25 -0700 (PDT) X-Received: by 10.51.17.5 with SMTP id ga5mr9490931igd.2.1399642405421; Fri, 09 May 2014 06:33:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Fri, 9 May 2014 06:32:55 -0700 (PDT) In-Reply-To: References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> From: Brian Campbell Date: Fri, 9 May 2014 07:32:55 -0600 Message-ID: To: Axel Nennker Content-Type: multipart/alternative; boundary=001a1135e1da635bd404f8f7a47d Archived-At: http://mailarchive.ietf.org/arch/msg/jose/07Y6uCHHYn12txBDr_Dy_Jmq4Z0 Cc: Antonio Sanso , Justin Richer , "jose@ietf.org" , Matthew Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 13:33:36 -0000 --001a1135e1da635bd404f8f7a47d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-4= .3is pretty clear about which parameters and hash functions to use in which OAEP alg. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-= A.2that you refer to Axel probably needs to be updated because just listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't completely correct (well, maybe it is correct but a bit more is also needed). In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initialize it with an OAEPParameterSpec that indicates that SHA-256 is to be used for MGF1 too. That looks something like this (or this is how I did it anyway): Cipher cipher =3D Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec); The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant with what's specified in the OAEPParameterSpec but I've not been able to figure out any other way to make it work. I don't know exactly how to say that in the Key Management Algorithm Identifier Cross-Reference but that's apparently what needs to be done. On Wed, May 7, 2014 at 8:30 AM, wrote: > Does =E2=80=9CRSA/ECB/OAEPWithSHA-1AndMGF1Padding=E2=80=9D mean that SHA-= 256 must be used > for padding too? > > I did not read it so. > > Did somebody manage to use JCA correctly with one algorithm specifier lik= e > RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256? > > > > Axel > A.2. Key > Management Algorithm Identifier Cross-Reference > > This section contains a table cross-referencing the JWE alg (algorithm) > values defined in this specification with the equivalent identifiers used > by other standards and software packages. > > *JWE* > > *XML ENC* > > *JCA* > > *OID* > > RSA1_5 > > http://www.w3.org/2001/04/xmlenc#rsa-1_5 > > RSA/ECB/PKCS1Padding > > 1.2.840.113549.1.1.1 > > RSA-OAEP > > http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p > > RSA/ECB/OAEPWithSHA-1AndMGF1Padding > > 1.2.840.113549.1.1.7 > > RSA-OAEP-256 > > http://www.w3.org/2009/xmlenc11#rsa-oaep > > RSA/ECB/OAEPWithSHA-256AndMGF1Padding > > 1.2.840.113549.1.1.7 > > > > > > -----Original Message----- > From: Antonio Sanso [mailto:asanso@adobe.com] > Sent: Wednesday, May 07, 2014 4:24 PM > To: Richer, Justin P. > Cc: Brian Campbell; Matt Miller; jose@ietf.org; Nennker, Axel > Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example > > > > On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de > wrote: > > > I think that the java implementations implemented the spec and > > > everything is ok from that POV. > > > > > > These implementations are not broken. > > > > The JOSE Java implementations did not implement the spec, though. > > draft-ietf-jose-json-web-algorithms =C2=A7 4.3 clearly states the hash an= d mask > generation functions are to use the same algorithm -- SHA-1 (and > > MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with > > SHA-256) in the case of "RSA-OAEP-256". > > > > > > > > > > > > > > One could argue that when we replace SHA-1 by SHA-256 in one place > > > then we might consider to replace it in the padding too. > > > > That is exactly what draft-ietf-jose-json-web-algorithms specified. > > > > > > > > My feeling is that using sha-256 for the padding does not give us more > > > security. YMMW > > > > > > > That is a separate debate, I think. The prevailing opinion (at least > around the IETF) is "don't mix the algorithms". > > > > > > -- > > - m&m > > > > Matt Miller < mamille2@cisco.com > Cisco > Systems, Inc. > > > > > > > > > > > > > > > > > *From:*jose > > > [mailto:jose-bounces@ietf.org] > *On > > > Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM > > > *To:* Matt Miller > > > *Cc:* Antonio Sanso; jose@ietf.org *Subject:* > > > Re: [jose] > > > RSA-OAEP-256 Example > > > > > > > > > > > > Thanks Matt. > > > > > > That is why I was looking for someone to verify using a different > > > platform. Though I was hoping it'd just work. > > > > > > Matt, can you try decrypting this one by chance? Using the same key. I > > > was more explicit with the parameters and, I think, MGF1 should be > > > using SHA-256 now too. > > > > > > > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj > > > jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ > > > 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi > > > OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j > > > L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu > > > BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9 > > > _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G > > > Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w > > > > > > > > > > > > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > > > > > > >>> > wrote: > > > > > > Short answer: You are all equally broken -- except from a certain > > > point of view d-: > > > > > > Long answer: The code I have is based on OpenSSL, which is hard-coded > > > to use SHA1 for the hash and mask generation (boo!), which means one > > > has to implement OAEP-SHA256 from scratch (hiss!!). > > > > > > When I implemented it per RFC 3447 and > > > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > > > decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I > > > could decrypt provided results. A search through BouncyCastle's code > > > shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash > > > function of > > > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > > > evidence is shown with how [FORGE] can be made to work with Java > > > (search their homepage for "Compatible with Java's > > > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > > > > > Reconciling all of this with > > > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be > > > very straight-forward. It appears that the JCA identifier is meant to > > > be "MGF1 with SHA1"; that ought to be explicitly noted. > > > The XMLENC reference is arguably incomplete, since > > > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > > > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can > > > probably be addressed by explicitly stating the mask generation > > > function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > > > (MGF1 with SHA-256). > > > > > > > > > > > > > > > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --001a1135e1da635bd404f8f7a47d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://tools.ietf.org/html/= draft-ietf-jose-json-web-algorithms-26#section-4.3 is pretty clear abou= t which parameters and hash functions to use in which OAEP alg.

http://tools.ietf.org/html/draft-ietf-jose-json-web-alg= orithms-26#appendix-A.2 that you refer to Axel probably needs to be upd= ated because just listing RSA/ECB/OAEPWithSHA-256AndMGF= 1Padding for RSA-OAPE-265 isn't completely correct (well, maybe it is c= orrect but a bit more is also needed).

In order to do RSA-OAPE-2= 65 correctly using the JCA APIs, one gets a Cipher with RSA/ECB/OAEPWithSHA= -256AndMGF1Padding and then also initialize it with an OAEPParameterSpec th= at indicates that
SHA-256 is to be used for MGF1 too.= That looks something like this (or this = is how I did it anyway):
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0 Cipher cipher =3D C= ipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
=C2=A0=C2=A0 OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA= -256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.= DEFAULT);
=C2=A0=C2=A0 cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec= );


= The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant = with what's specified in the OAEPParameterSpec but I've not been ab= le to figure out any other way to make it work. I don't know exa= ctly how to say that in the Key Management Algorithm Identifier Cross-Refer= ence but that's apparently what needs to be done.





On Wed, May 7, 2014 at 8:30 AM, <Axel.Nennker@telekom.de&= gt; wrote:

Does =E2=80=9CRSA/ECB/OAEPWithSHA-1AndMGF1Padding=E2=80=9D m= ean that SHA-256 must be used for padding too?

I did not read it so.

Did somebody manage to use JCA= correctly with one algorithm specifier like RSA/ECB/OAEPWithSHA-1AndMGF1Pa= ddingWithSHA-256?

=C2=A0

Axel

A.2. Key Management Algorithm Identifier Cross-Reference

This section contains a table cross-referencing the JWE alg= (algorithm) values defined in this specification with the equivalent ident= ifiers used by other standards and software packages.

OID

=

JWE

XML ENC

JCA<= /b>

RSA1_5

h= ttp://www.w3.org/2001/04/xmlenc#rsa-1_5

RSA/ECB/PKCS1Padding

1.2.840.113549.1.1.1<= /p>

RSA-OAEP

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

RSA/ECB/OAEPWithSHA-1AndMGF1Padding<= /u>

1.2.840.113549.1.1.7<= /p>

RSA-OAEP-256<= /span>

h= ttp://www.w3.org/2009/xmlenc11#rsa-oaep

RSA/ECB/OAEPWithSHA-256AndMGF1Padding

1.2.840.113549.1.1.7<= /p>

=C2=A0

=C2=A0=

-----Original Message-----
From: Antonio Sanso [mailto:asanso@adobe.com]
Sent: Wednesday, May 07, 2014 4:24 PM
To: Richer, Justin P.
Cc: Brian= Campbell; Matt Miller; = jose@ietf.org; Nennker, Axel
Subject: ***CAUTION_Invalid_Signature**= * Re: [jose] RSA-OAEP-256 Example

=C2=A0

On 5/7/14, 2:21 AM, Axel.Nenn= ker@telekom.de<mailto:Axel.Nennker@telekom.de> wrote:

> I think that the java implementations implemented the spec and <= /u>

> everything is ok from that POV.

&= gt;=C2=A0

> These implementations are not broken.=

=C2=A0

The JOSE Java implementations did not impleme= nt the spec, though.

draft-ietf-jose-json-web-algorithm= s =C2=A7 4.3 clearly states the hash and mask generation functions are to u= se the same algorithm -- SHA-1 (and

MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and M= GF1 with

SHA-256) in the case of "RSA-OAEP-256&quo= t;.

=C2=A0

>=C2=A0=

>=C2=A0

>=C2=A0

> One coul= d argue that when we replace SHA-1 by SHA-256 in one place

> then we might consider to replace it in the padding too.

=C2=A0

That is exactly what draft-ietf-jose-json-web= -algorithms specified.

=C2=A0

><= u>=C2=A0

> My feeling is that using sha-256 for the pad= ding does not give us more

> security. YMMW

>=C2=A0

<= u>=C2=A0

That is a separate debate, I think.=C2=A0 The pre= vailing opinion (at least around the IETF) is "don't mix the algor= ithms".

=C2=A0

=C2=A0

--

- m&m

=C2=A0

Matt Mi= ller < ma= mille2@cisco.com<mailto:mamille2@cisco.com> > Cisco Sys= tems, Inc.

=C2=A0

>=C2=A0

>=C2= =A0

>=C2=A0

>=C2=A0

> *From:*jose

> [mailto:jose-bounces@ietf.org&l= t;mailto:jose-bounces@ietf.org>] *On

> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07= , 2014 6:54 AM

> *To:* Matt Miller

> *Cc:* Antonio Sanso; jose@ietf.org<mailto:jose@ietf.org> *Subject= :*

> Re: [jose]

> RSA-OAEP-256 Ex= ample

>=C2=A0

>=C2=A0<= u>

>=C2=A0

> Thanks Matt.=

>=C2=A0

> That is why I was looking for someone to verify using a different <= u>

> platform. Though I was hoping it'd just work.<= u>

>=C2=A0

> Matt, can you try d= ecrypting this one by chance? Using the same key. I

> was more explicit with the parameters and, I think, MGF1 should be =

> using SHA-256 now too.

>=C2=A0

>=C2=A0

> eyJhbGciOiJSU0= EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj

> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442= ZgZ

> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghG= txfzdB_VRvFt2eehbCA3gWpi

> OYHHvSTFdBPGx2KZHQisLz3oZ= R8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j

> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQ= cPu

> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7= X9oXoA.0frdIwx8P8UAzh1s9

> _PgOA.RAzILH0xfs0yxzML1Cz= zGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G

> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w

&= gt;=C2=A0

>=C2=A0

>=C2= =A0

>=C2=A0

> On Tue, May 6, 2014 at= 8:39 PM, Matt Miller

> <= mamille2@cisco.com<mailto:mamille2@cisco.com>

> <mailto:mamille2@cisco.com<mailto:mamille2@c= isco.com>>> wrote:

>=C2=A0

> Short answer: You are all equally br= oken -- except from a certain

> point of view d-:

>=C2=A0

> Long answer: The cod= e I have is based on OpenSSL, which is hard-coded

> to use SHA1 for the hash and mask generation (boo!), which means on= e

> has to implement OAEP-SHA256 from scratch (hiss= !!).

>=C2=A0

> When I impleme= nted it per RFC 3447 and

> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not =

> decrypt the provided results.=C2=A0 When I hard-code= d MGF1 to use "SHA1", I

> could decrypt p= rovided results.=C2=A0 A search through BouncyCastle's code <= /u>

> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a= Hash

> function of

> SHA-25= 6 generate the lHash but its MGF1 uses a "SHA-1". Further =

> evidence is shown with how [FORGE] can be made to work with Java

> (search their homepage for "Compatible with Ja= va's

> RSA/ECB/OAEPWithSHA-256AndMGF1Padding&qu= ot;).

>=C2=A0

> Reconciling all of this with<= u>

> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not= look to be

> very straight-forward.=C2=A0 It appea= rs that the JCA identifier is meant to

> be "MGF1 with SHA1"; that ought to be explicitly noted.

> The XMLENC reference is arguably incomplete, since =

> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults t= o

> "http://ww= w.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can=

> probably be addressed by explicitly stating the mask generation =

> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256&quo= t;

> (MGF1 with SHA-256).

>=C2=A0

>=C2=A0

>=C2=A0

><= /u>=C2=A0

>=C2=A0

=



--
--001a1135e1da635bd404f8f7a47d-- From nobody Fri May 9 06:43:24 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB621A02AC for ; Fri, 9 May 2014 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLMVRjRHNPKj for ; Fri, 9 May 2014 06:43:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 655CD1A02A2 for ; Fri, 9 May 2014 06:43:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DDD862260083; Fri, 9 May 2014 09:43:13 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C102C1F050D; Fri, 9 May 2014 09:43:13 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Fri, 9 May 2014 09:43:13 -0400 From: "Richer, Justin P." To: Brian Campbell Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaaXt6y9pFg73WUeWYaQCNSAO4Zs00HCAgAA5+gCAAEbmgIAADyMAgAAMIwCAAtakQIAARdKA Date: Fri, 9 May 2014 13:43:13 +0000 Message-ID: <534AC72E-F7C4-4EAA-B1D7-194CAFC08961@mitre.org> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.11.201] Content-Type: multipart/alternative; boundary="_000_534AC72EF7C44EAAB1D7194CAFC08961mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/_EJYrA4cDN9_r9UQb05AFIL27Dg Cc: Antonio Sanso , "jose@ietf.org" , Axel Nennker , Matthew Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 13:43:23 -0000 --_000_534AC72EF7C44EAAB1D7194CAFC08961mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I've found that it seems to work if you use NOPADDING, too: AlgorithmParameters algp =3D AlgorithmParametersHelper.getInstance("OAEP", = provider); AlgorithmParameterSpec paramSpec =3D new OAEPParameterSpec("SHA-256", "MGF1= ", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); algp.init(paramSpec); Cipher cipher =3D CipherHelper.getInstance("RSA/ECB/NOPADDING", provider); cipher.init(Cipher.DECRYPT_MODE, priv, algp); (Note that all the AlgorithmParametersHelper does in our code is install th= e right provider if given.) -- Justin On May 9, 2014, at 9:32 AM, Brian Campbell > wrote: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-4= .3 is pretty clear about which parameters and hash functions to use in whic= h OAEP alg. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-= A.2 that you refer to Axel probably needs to be updated because just listin= g RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't completely c= orrect (well, maybe it is correct but a bit more is also needed). In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a Cipher= with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initialize it wit= h an OAEPParameterSpec that indicates that SHA-256 is to be used for MGF1 too. That looks something like this (or this= is how I did it anyway): Cipher cipher =3D Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padd= ing"); OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA-256", "MGF1", = MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec); The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant with what'= s specified in the OAEPParameterSpec but I've not been able to figure out a= ny other way to make it work. I don't know exactly how to say that in the K= ey Management Algorithm Identifier Cross-Reference but that's apparently wh= at needs to be done. On Wed, May 7, 2014 at 8:30 AM, > wrote: Does =93RSA/ECB/OAEPWithSHA-1AndMGF1Padding=94 mean that SHA-256 must be us= ed for padding too? I did not read it so. Did somebody manage to use JCA correctly with one algorithm specifier like = RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256? Axel A.2. Key Management Algorithm Identifier Cross-Reference This section contains a table cross-referencing the JWE alg (algorithm) val= ues defined in this specification with the equivalent identifiers used by o= ther standards and software packages. JWE XML ENC JCA OID RSA1_5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 RSA/ECB/PKCS1Padding 1.2.840.113549.1.1.1 RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p RSA/ECB/OAEPWithSHA-1AndMGF1Padding 1.2.840.113549.1.1.7 RSA-OAEP-256 http://www.w3.org/2009/xmlenc11#rsa-oaep RSA/ECB/OAEPWithSHA-256AndMGF1Padding 1.2.840.113549.1.1.7 -----Original Message----- From: Antonio Sanso [mailto:asanso@adobe.com] Sent: Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian Campbell; Matt Miller; jose@ietf.org; Nennk= er, Axel Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example On 5/7/14, 2:21 AM, Axel.Nennker@telekom.de> wrote: > I think that the java implementations implemented the spec and > everything is ok from that POV. > > These implementations are not broken. The JOSE Java implementations did not implement the spec, though. draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash and mas= k generation functions are to use the same algorithm -- SHA-1 (and MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with SHA-256) in the case of "RSA-OAEP-256". > > > > One could argue that when we replace SHA-1 by SHA-256 in one place > then we might consider to replace it in the padding too. That is exactly what draft-ietf-jose-json-web-algorithms specified. > > My feeling is that using sha-256 for the padding does not give us more > security. YMMW > That is a separate debate, I think. The prevailing opinion (at least aroun= d the IETF) is "don't mix the algorithms". -- - m&m Matt Miller < mamille2@cisco.com> > Cisco Systems, Inc. > > > > > *From:*jose > [mailto:jose-bounces@ietf.org] *On > Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM > *To:* Matt Miller > *Cc:* Antonio Sanso; jose@ietf.org> *Subject:* > Re: [jose] > RSA-OAEP-256 Example > > > > Thanks Matt. > > That is why I was looking for someone to verify using a different > platform. Though I was hoping it'd just work. > > Matt, can you try decrypting this one by chance? Using the same key. I > was more explicit with the parameters and, I think, MGF1 should be > using SHA-256 now too. > > > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj > jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ > 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi > OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j > L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu > BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9 > _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G > Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w > > > > > On Tue, May 6, 2014 at 8:39 PM, Matt Miller > > > >>> wrote: > > Short answer: You are all equally broken -- except from a certain > point of view d-: > > Long answer: The code I have is based on OpenSSL, which is hard-coded > to use SHA1 for the hash and mask generation (boo!), which means one > has to implement OAEP-SHA256 from scratch (hiss!!). > > When I implemented it per RFC 3447 and > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not > decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I > could decrypt provided results. A search through BouncyCastle's code > shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash > function of > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further > evidence is shown with how [FORGE] can be made to work with Java > (search their homepage for "Compatible with Java's > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). > > Reconciling all of this with > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be > very straight-forward. It appears that the JCA identifier is meant to > be "MGF1 with SHA1"; that ought to be explicitly noted. > The XMLENC reference is arguably incomplete, since > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can > probably be addressed by explicitly stating the mask generation > function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" > (MGF1 with SHA-256). > > > > > -- [Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [phone] +1 720.317.2061 Connect with us=85 [twitter logo] [youtube logo] [LinkedIn logo] [Facebook logo] [Google+ logo] [s= lideshare logo] [flipboard logo] = [rss feed icon] [Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19= =9623 July, 2014 | Monterey, CA] --_000_534AC72EF7C44EAAB1D7194CAFC08961mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8D453B723FF15041BE8589A93A216674@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I've found that it seems to work if you use NOPADDING, too:

AlgorithmParameters = algp =3D AlgorithmParametersHelper.getInstance("OAEP", provider);
AlgorithmParameterSp= ec paramSpec =3D new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.<= span style=3D"color: #0326cc">SHA256, PSource.PSpecified.DEFAULT);
algp.init(paramSpec)= ;
Cipher cipher =3D Ci= pherHelper.getInstance("RSA/ECB/NOPADDI= NG", provider);
cipher.init(Cipher.<= span style=3D"color: #0326cc">DECRYPT_MODE, priv, algp);


(Note that all the AlgorithmParametersHelper does in our code is insta= ll the right provider if given.)

-- Justin

On May 9, 2014, at 9:32 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-algorithms-26#section-4.3 is pretty clear about which parameters and= hash functions to use in which OAEP alg.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-26#appendix-A.2 that you refer to Axel probably needs to be updated= because just listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't completely cor= rect (well, maybe it is correct but a bit more is also needed).

In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a Cipher w= ith RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initialize it with = an OAEPParameterSpec that indicates that
SHA-256 is to be used for MGF1 too. That looks something like this (or this is how I did it anyway):
      
   Cipher cipher =3D Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1P= adding");
   OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA= -256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.= DEFAULT);
   cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec);


The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant wit= h what's specified in the OAEPParameterSpec but I've not been able to figur= e out any other way to make it work. I don't know exactly how to say that in the Key Management Algorithm= Identifier Cross-Reference but that's apparently what needs to be done.




On Wed, May 7, 2014 at 8:30 AM, <Axel.Nen= nker@telekom.de> wrote:

Does =93RSA/ECB/OAEPWithSHA-1AndMGF1Padding=94 mean that SHA-256 must be= used for padding too?

I did not read it so.

Did somebody manage to use JCA correctly with one algorithm specifier li= ke RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?

 

Axel

A.2. Key Management Algorithm Identifier Cross-Reference

This section contains a table cross-referencing the JWE alg= (algorithm) values defined in this specification with the equivalent ident= ifiers used by other standards and software packages.

JWE<= /b>

XML = ENC

JCA<= /b>

OID<= /b>

RSA1_5

http://www.w3.org/2001/04/xmlenc#rsa-1_5

RSA/ECB/PKCS1Padding

1.2.840.113549.1.1.1

RSA-OAEP<= /u>

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

RSA/ECB/OAEPWithSHA-1AndMGF1Padding

1.2.840.113549.1.1.7

RSA-OAEP-256=

http://www.w3.org/2009/xmlenc11#rsa-oaep

RSA/ECB/OAEPWithSHA-256AndMGF1Padding

1.2.840.113549.1.1.7

 

 

-----Original Message-----
From: Antonio Sanso [mailto:asanso@adobe.com]
Sent: Wednesday, May 07, 2014 4:24 PM
To: Richer, Justin P.
Cc: Brian Campbell; Matt Miller; jose@ietf.org; Nennker, Axel
Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example

 

On 5/7/14, 2:21 AM, Axel.Nennker@telekom.= de<mailto:Axel.Nennker@telekom.de> wrote:

> I think that the java implementations implemented the spec and <= /u>

> everything is ok from that POV.

> 

> These implementations are not broken.

 

The JOSE Java implementations did not implement the spec, though.=

draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash and = mask generation functions are to use the same algorithm -- SHA-1 (and

MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and M= GF1 with

SHA-256) in the case of "RSA-OAEP-256".

 

> 

> 

> 

> One could argue that when we replace SHA-1 by SHA-256 in one place =

> then we might consider to replace it in the padding too.<= /u>

 

That is exactly what draft-ietf-jose-json-web-algorithms specified.

 

> 

> My feeling is that using sha-256 for the padding does not give us m= ore

> security. YMMW

> 

 

That is a separate debate, I think.  The prevailing opinion (at lea= st around the IETF) is "don't mix the algorithms".<= /p>

 

 

--

- m&m

 

Matt Miller < mamille2@cisco.com<= ;mailto:mamille2@cisco.com> > Cisco Systems, Inc.

 

> 

> 

> 

> 

> *From:*jose

> [mailto:jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>] *On

> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM <= u>

> *To:* Matt Miller

> *Cc:* Antonio Sanso; jose@ietf.org<mail= to:jose@ietf.org> *Subject:*

> Re: [jose]

> RSA-OAEP-256 Example

> 

> 

> 

> Thanks Matt.

> 

> That is why I was looking for someone to verify using a different <= u>

> platform. Though I was hoping it'd just work.

> 

> Matt, can you try decrypting this one by chance? Using the same key= . I

> was more explicit with the parameters and, I think, MGF1 should be =

> using SHA-256 now too.

> 

> 

> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5c= MCj

> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442= ZgZ

> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3g= Wpi

> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmc= E2j

> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQ= cPu

> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh= 1s9

> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feA= H5G

> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w

> 

> 

> 

> 

> On Tue, May 6, 2014 at 8:39 PM, Matt Miller

> <= mamille2@cisco.com<mailto:mamille2@cisco.com>

> <= mailto:mamille2@cisco.com<mailto:mamille2@cisco.com>>&g= t; wrote:

> 

> Short answer: You are all equally broken -- except from a certain <= u>

> point of view d-:

> 

> Long answer: The code I have is based on OpenSSL, which is hard-cod= ed

> to use SHA1 for the hash and mask generation (boo!), which means on= e

> has to implement OAEP-SHA256 from scratch (hiss!!).

> 

> When I implemented it per RFC 3447 and

> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not =

> decrypt the provided results.  When I hard-coded MGF1 to use &= quot;SHA1", I

> could decrypt provided results.  A search through BouncyCastle= 's code

> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a= Hash

> function of

> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". F= urther

> evidence is shown with how [FORGE] can be made to work with Java

> (search their homepage for "Compatible with Java's <= /u>

> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

> 

> Reconciling all of this with

> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to b= e

> very straight-forward.  It appears that the JCA identifier is = meant to

> be "MGF1 with SHA1"; that ought to be explicitly noted.

> The XMLENC reference is arguably incomplete, since

> "http://ww= w.w3.org/2009/xmlenc11#rsa-oaep" defaults to

> "http://ww= w.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can

> probably be addressed by explicitly stating the mask generation =

> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"

> (MGF1 with SHA-256).

> 

> 

> 

> 

> 




--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061<= /font>
Connect with us=85
3D"= 3D"youtube<= /a> 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register


--_000_534AC72EF7C44EAAB1D7194CAFC08961mitreorg_-- From nobody Fri May 9 09:31:52 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77F01A02D3 for ; Fri, 9 May 2014 09:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJn2FYlbkqFd for ; Fri, 9 May 2014 09:31:48 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6861A0090 for ; Fri, 9 May 2014 09:31:46 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKU20C5923f3ARrx8pM5/c20Z0sJsbqaL4@postini.com; Fri, 09 May 2014 09:31:41 PDT Received: by mail-ie0-f172.google.com with SMTP id as1so4346720iec.3 for ; Fri, 09 May 2014 09:31:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F0+AQI6/rk1QGWQ8QsNli+CFfxdn9ypBe9r7Oh0Ndmk=; b=BIn/C5Lkgdg4wpDtHutMSz+mMd0iE/7C6E4MDGHbkb2IWMb9APnz+3i39IEjlxzHba j+ZIVz8wZkJMOmSQ4yM41gHUGxCZ6VhTfRQScd9Fkg0tOMSqddXsLfQxcA9FPeMFSXdo fc8UFX5jUBxr7HjVsv4LfjmwoPeMyXDRIb1ksKQQHrSQoEnQY0qx0AUG0xsPEsgN4W7e eS1UX+hR3fj9/HoWlc6sLQJA1aQFhNF+ELiGfCvRQtXu9ABD9gEZk6HR1DhwiH/Bjhmb jCyTlPiq/3OT/SC7E62OZJDuw3px5ako9S4r0bTMMncXsBXYq7F3whfgscH68d9vQo8r sXUg== X-Gm-Message-State: ALoCoQkDyyKyvlj7zV1TdK6jh9BI+sHtECl8atInIt/kG7kKaJpFAvEb8RopS1X+TygdRb68BjNQ3rGeu34+CaLbzHBddbHaTVShe2coaQKklaLrLf6dwSMVmVC6HYa3H30rExSP8yP4 X-Received: by 10.50.13.100 with SMTP id g4mr11156702igc.9.1399653095427; Fri, 09 May 2014 09:31:35 -0700 (PDT) X-Received: by 10.50.13.100 with SMTP id g4mr11156676igc.9.1399653095281; Fri, 09 May 2014 09:31:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Fri, 9 May 2014 09:31:05 -0700 (PDT) In-Reply-To: <534AC72E-F7C4-4EAA-B1D7-194CAFC08961@mitre.org> References: <8B0ED727-E102-4362-B9A3-4411773E48A6@adobe.com> <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> <534AC72E-F7C4-4EAA-B1D7-194CAFC08961@mitre.org> From: Brian Campbell Date: Fri, 9 May 2014 10:31:05 -0600 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=089e013c66148dc1dd04f8fa21a0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/rkLOw2r2dFSjRiuikMxbK9ikLAU Cc: Antonio Sanso , "jose@ietf.org" , Axel Nennker , Matthew Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 16:31:51 -0000 --089e013c66148dc1dd04f8fa21a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So while OAEPWithSHA-256AndMGF1Padding is a little redundant with the OAEPParameterSpec, I'd say NOPADDING seems a little contradictory. But what do I know? I'm still not sure how to concisely explain it in the appendix. On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P. wrote= : > I've found that it seems to work if you use NOPADDING, too: > > AlgorithmParameters algp =3D AlgorithmParametersHelper.getInstance("OAEP= ", > provider); > AlgorithmParameterSpec paramSpec =3D new OAEPParameterSpec("SHA-256", "MG= F1", > MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); > algp.init(paramSpec); > Cipher cipher =3D CipherHelper.getInstance("RSA/ECB/NOPADDING", provider)= ; > cipher.init(Cipher.DECRYPT_MODE, priv, algp); > > > (Note that all the AlgorithmParametersHelper does in our code is install > the right provider if given.) > > -- Justin > > On May 9, 2014, at 9:32 AM, Brian Campbell > wrote: > > > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section= -4.3is pretty clear about which parameters and hash functions to use in whi= ch > OAEP alg. > > > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendi= x-A.2that you refer to Axel probably needs to be updated because just listi= ng RSA/ECB/OAEPWithSHA-256AndMGF1Padding > for RSA-OAPE-265 isn't completely correct (well, maybe it is correct but = a > bit more is also needed). > > In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a > Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initializ= e > it with an OAEPParameterSpec that indicates that > SHA-256 is to be used for MGF1 too. That looks something like this (or > this is how I did it anyway): > > Cipher cipher =3D > Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); > OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA-256", "MGF1"= , > MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); > cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec); > > The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant with > what's specified in the OAEPParameterSpec but I've not been able to figur= e > out any other way to make it work. I don't know exactly how to say that > in the Key Management Algorithm Identifier Cross-Reference but that's > apparently what needs to be done. > > > > > > On Wed, May 7, 2014 at 8:30 AM, wrote: > >> Does =E2=80=9CRSA/ECB/OAEPWithSHA-1AndMGF1Padding=E2=80=9D mean that SH= A-256 must be >> used for padding too? >> >> I did not read it so. >> >> Did somebody manage to use JCA correctly with one algorithm specifier >> like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256? >> >> >> >> Axel >> A.2. Key >> Management Algorithm Identifier Cross-Reference >> >> This section contains a table cross-referencing the JWE alg (algorithm) >> values defined in this specification with the equivalent identifiers use= d >> by other standards and software packages. >> >> *JWE* >> >> *XML ENC* >> >> *JCA* >> >> *OID* >> >> RSA1_5 >> >> http://www.w3.org/2001/04/xmlenc#rsa-1_5 >> >> RSA/ECB/PKCS1Padding >> >> 1.2.840.113549.1.1.1 >> >> RSA-OAEP >> >> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p >> >> RSA/ECB/OAEPWithSHA-1AndMGF1Padding >> >> 1.2.840.113549.1.1.7 >> >> RSA-OAEP-256 >> >> http://www.w3.org/2009/xmlenc11#rsa-oaep >> >> RSA/ECB/OAEPWithSHA-256AndMGF1Padding >> >> 1.2.840.113549.1.1.7 >> >> >> >> >> >> -----Original Message----- >> From: Antonio Sanso [mailto:asanso@adobe.com] >> Sent: Wednesday, May 07, 2014 4:24 PM >> To: Richer, Justin P. >> Cc: Brian Campbell; Matt Miller; jose@ietf.org; Nennker, Axel >> Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example >> >> >> >> On 5/7/14, 2:21 AM, >> Axel.Nennker@telekom.de wrote: >> >> > I think that the java implementations implemented the spec and >> >> > everything is ok from that POV. >> >> > >> >> > These implementations are not broken. >> >> >> >> The JOSE Java implementations did not implement the spec, though. >> >> draft-ietf-jose-json-web-algorithms =C2=A7 4.3 clearly states the hash a= nd >> mask generation functions are to use the same algorithm -- SHA-1 (and >> >> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with >> >> SHA-256) in the case of "RSA-OAEP-256". >> >> >> >> > >> >> > >> >> > >> >> > One could argue that when we replace SHA-1 by SHA-256 in one place >> >> > then we might consider to replace it in the padding too. >> >> >> >> That is exactly what draft-ietf-jose-json-web-algorithms specified. >> >> >> >> > >> >> > My feeling is that using sha-256 for the padding does not give us more >> >> > security. YMMW >> >> > >> >> >> >> That is a separate debate, I think. The prevailing opinion (at least >> around the IETF) is "don't mix the algorithms". >> >> >> >> >> >> -- >> >> - m&m >> >> >> >> Matt Miller < mamille2@cisco.com > Cisco >> Systems, Inc. >> >> >> >> > >> >> > >> >> > >> >> > >> >> > *From:*jose >> >> > [mailto:jose-bounces@ietf.org] >> *On >> >> > Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM >> >> > *To:* Matt Miller >> >> > *Cc:* Antonio Sanso; jose@ietf.org *Subject:* >> >> > Re: [jose] >> >> > RSA-OAEP-256 Example >> >> > >> >> > >> >> > >> >> > Thanks Matt. >> >> > >> >> > That is why I was looking for someone to verify using a different >> >> > platform. Though I was hoping it'd just work. >> >> > >> >> > Matt, can you try decrypting this one by chance? Using the same key. I >> >> > was more explicit with the parameters and, I think, MGF1 should be >> >> > using SHA-256 now too. >> >> > >> >> > >> >> > eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj >> >> > jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ >> >> > 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi >> >> > OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j >> >> > L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu >> >> > BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9 >> >> > _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G >> >> > Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w >> >> > >> >> > >> >> > >> >> > >> >> > On Tue, May 6, 2014 at 8:39 PM, Matt Miller >> >> > >> >> > >>> >> wrote: >> >> > >> >> > Short answer: You are all equally broken -- except from a certain >> >> > point of view d-: >> >> > >> >> > Long answer: The code I have is based on OpenSSL, which is hard-coded >> >> > to use SHA1 for the hash and mask generation (boo!), which means one >> >> > has to implement OAEP-SHA256 from scratch (hiss!!). >> >> > >> >> > When I implemented it per RFC 3447 and >> >> > draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not >> >> > decrypt the provided results. When I hard-coded MGF1 to use "SHA1", I >> >> > could decrypt provided results. A search through BouncyCastle's code >> >> > shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash >> >> > function of >> >> > SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further >> >> > evidence is shown with how [FORGE] can be made to work with Java >> >> > (search their homepage for "Compatible with Java's >> >> > RSA/ECB/OAEPWithSHA-256AndMGF1Padding"). >> >> > >> >> > Reconciling all of this with >> >> > draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be >> >> > very straight-forward. It appears that the JCA identifier is meant to >> >> > be "MGF1 with SHA1"; that ought to be explicitly noted. >> >> > The XMLENC reference is arguably incomplete, since >> >> > "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to >> >> > "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can >> >> > probably be addressed by explicitly stating the mask generation >> >> > function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" >> >> > (MGF1 with SHA-256). >> >> > >> >> > >> >> > >> >> > >> >> > >> > > > > -- > [image: Ping Identity logo] > Brian Campbell > Portfolio Architect > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect > with us=E2=80=A6 [image: twitter logo] [image: > youtube logo] [image: > LinkedIn logo] [image: Facebook > logo] [image: Google+ logo] [image: > slideshare logo] [image: > flipboard logo] [image: rss feed icon] > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] > > > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --089e013c66148dc1dd04f8fa21a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So while OAEPWithSHA-256AndMGF1Padding is a little re= dundant with the OAEPParameterSpec, I'd say NOPADDING seems a little co= ntradictory. But what do I know?

I'm still not sure how to= concisely explain it in the appendix.


On Fri,= May 9, 2014 at 7:43 AM, Richer, Justin P. <jricher@mitre.org> wrote:
I've found that it seems to work if you use NOPADDING, too:

AlgorithmParameters algp =3D AlgorithmParamete= rsHelper.getInstance("OAEP",= provider);
AlgorithmParameterSpec paramSpec =3D new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);
algp.init(paramSpec);
Cipher cipher =3D CipherHelper.getInstance("RSA/ECB/NOPADDING", provider);=
cipher.init(Cipher.DECRYPT_MODE, priv, algp);


(Note that all the AlgorithmParametersHelper does in our code is insta= ll the right provider if given.)

-- Justin

On May 9, 2014, at 9:32 AM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

http://tools.ietf.org/html/draf= t-ietf-jose-json-web-algorithms-26#section-4.3 is pretty clear about wh= ich parameters and hash functions to use in which OAEP alg.

http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-26#appendix-A.2 that you refer to Axel probably n= eeds to be updated because just listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't completely= correct (well, maybe it is correct but a bit more is also needed).

In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a Cipher w= ith RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initialize it with = an OAEPParameterSpec that indicates that
SHA-256 is to be used for MGF1 too. That looks something like this (or this is how I did it anyway):
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0 Cipher cipher =3D Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1P= adding");
=C2=A0=C2=A0 OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA= -256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.= DEFAULT);
=C2=A0=C2=A0 cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec);


The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant wit= h what's specified in the OAEPParameterSpec but I've not been able = to figure out any other way to make it work. I don't know exactly how to say that in the Key Management Algor= ithm Identifier Cross-Reference but that's apparently what needs to be = done.





On Wed, May 7, 2014 at 8:30 AM, <Axel.Nen= nker@telekom.de> wrote:

Does =E2=80=9CRSA/ECB/OAEPWithSHA-1AndMGF1Padding=E2=80=9D mean that SHA= -256 must be used for padding too?

I did not read it so.

Did somebody manage to use JCA correctly with one algorithm specifier li= ke RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?

=C2=A0

Axel

A.2. Key Management Algorithm Identifier Cross-Reference

This section contains a table cross-referencing the JWE alg= (algorithm) values defined in this specification with the equivalent ident= ifiers used by other standards and software packages.

JWE<= /b>

XML = ENC

JCA<= /b>

OID<= /b>

RSA1_5

http://www.w3.org/2001/04/xmlenc#rsa-1_5

RSA/ECB/PKCS1Padding

1.2.840.113549.1.1.1

RSA-OAEP<= /u>

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

RSA/ECB/OAEPWithSHA-1AndMGF1Padding

1.2.840.113549.1.1.7

RSA-OAEP-256=

http://www.w3.org/2009/xmlenc11#rsa-oaep

RSA/ECB/OAEPWithSHA-256AndMGF1Padding

1.2.840.113549.1.1.7

=C2=A0

=C2=A0

-----Original Message-----
From: Antonio Sanso [mailto:asanso@adobe.com]
Sent: Wednesday, May 07, 2014 4:24 PM
To: Richer, Justin P.
Cc: Brian Campbell; Matt Miller; jose@ietf.org; Nennker, Axel
Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example

=C2=A0

On 5/7/14, 2:21 AM, Axel.Nennker@telekom.= de<mailto:Axel.Nennker@telekom.de> wrote:

> I think that the java implementations implemented the spec and <= /u>

> everything is ok from that POV.

>=C2=A0

> These implementations are not broken.

=C2=A0

The JOSE Java implementations did not implement the spec, though.=

draft-ietf-jose-json-web-algorithms =C2=A7 4.3 clearly states the hash a= nd mask generation functions are to use the same algorithm -- SHA-1 (and=

MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and M= GF1 with

SHA-256) in the case of "RSA-OAEP-256".

=C2=A0

>=C2=A0

>=C2=A0

>=C2=A0

> One could argue that when we replace SHA-1 by SHA-256 in one place =

> then we might consider to replace it in the padding too.<= /u>

=C2=A0

That is exactly what draft-ietf-jose-json-web-algorithms specified.

=C2=A0

>=C2=A0

> My feeling is that using sha-256 for the padding does not give us m= ore

> security. YMMW

>=C2=A0

=C2=A0

That is a separate debate, I think.=C2=A0 The prevailing opinion (at lea= st around the IETF) is "don't mix the algorithms".<= /u>

=C2=A0

=C2=A0

--

- m&m

=C2=A0

Matt Miller < mamille2@cisco.com<= ;mailto:mamille2@cisco.com> > Cisco Systems, Inc.

=C2=A0

>=C2=A0

>=C2=A0

>=C2=A0

>=C2=A0

> *From:*jose

> [mailto:jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>] *On

> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM <= u>

> *To:* Matt Miller

> *Cc:* Antonio Sanso; jose@ietf.org<mail= to:jose@ietf.org> *Subject:*

> Re: [jose]

> RSA-OAEP-256 Example

>=C2=A0

>=C2=A0

>=C2=A0

> Thanks Matt.

>=C2=A0

> That is why I was looking for someone to verify using a different <= u>

> platform. Though I was hoping it'd just work.

>=C2=A0

> Matt, can you try decrypting this one by chance? Using the same key= . I

> was more explicit with the parameters and, I think, MGF1 should be =

> using SHA-256 now too.

>=C2=A0

>=C2=A0

> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5c= MCj

> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442= ZgZ

> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3g= Wpi

> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmc= E2j

> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQ= cPu

> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh= 1s9

> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feA= H5G

> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w

>=C2=A0

>=C2=A0

>=C2=A0

>=C2=A0

> On Tue, May 6, 2014 at 8:39 PM, Matt Miller

> <= mamille2@cisco.com<mailto:mamille2@cisco.com>

> <= mailto:mamille2@cisco.com<mailto:mamille2@cisco.com>>&g= t; wrote:

>=C2=A0

> Short answer: You are all equally broken -- except from a certain <= u>

> point of view d-:

>=C2=A0

> Long answer: The code I have is based on OpenSSL, which is hard-cod= ed

> to use SHA1 for the hash and mask generation (boo!), which means on= e

> has to implement OAEP-SHA256 from scratch (hiss!!).

>=C2=A0

> When I implemented it per RFC 3447 and

> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not =

> decrypt the provided results.=C2=A0 When I hard-coded MGF1 to use &= quot;SHA1", I

> could decrypt provided results.=C2=A0 A search through BouncyCastle= 's code

> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a= Hash

> function of

> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". F= urther

> evidence is shown with how [FORGE] can be made to work with Java

> (search their homepage for "Compatible with Java's =

> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

>=C2=A0

> Reconciling all of this with

> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to b= e

> very straight-forward.=C2=A0 It appears that the JCA identifier is = meant to

> be "MGF1 with SHA1"; that ought to be explicitly noted.

> The XMLENC reference is arguably incomplete, since

> "http://ww= w.w3.org/2009/xmlenc11#rsa-oaep" defaults to

> "http://ww= w.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can

> probably be addressed by explicitly stating the mask generation =

> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"

> (MGF1 with SHA-256).

>=C2=A0

>=C2=A0

>=C2=A0

>=C2=A0

>=C2=A0




--
Brian Campbell
= Portfolio Architect
@ bcampbell@pingidentity.com<= /font>
3D"phone" +1 720.317.2061
Connect with us=E2=80=A6
3D"= 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss=
3D"Register





--
--089e013c66148dc1dd04f8fa21a0-- From nobody Fri May 9 09:38:29 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB661A02E5 for ; Fri, 9 May 2014 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.697 X-Spam-Level: X-Spam-Status: No, score=-12.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5SXVvCOhM3u for ; Fri, 9 May 2014 09:38:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C9EBD1A02E1 for ; Fri, 9 May 2014 09:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13382; q=dns/txt; s=iport; t=1399653500; x=1400863100; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sCB89Lof7ht9LcM7G8DXXVy6VUAcxalHCt/NNyfs3jY=; b=a4FAp3vMYzSH44BL/oj3oOyzCwqOdk8Xh7ECZwsgBKI84QpjWPgxluxX CrMivp6jxPKLDOXd0WMcKYlQrAsLm5ZN5vMmL0NADp/ji6Qp80J8HyxLb XyE89COF0DoYAfheUR9j8iT3TiCuSaJKxCBf7Tv1yAAqj+ENw453c8cBg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYHAMADbVOtJV2a/2dsb2JhbABQBgODBk9RB6soAQEBAQEHklyHPAGBGBZ0giUBAQEEAQEBLwE7CgEMAgILDgMEAQEBCRYIBwkDAgECAQkMHwkIBg0BBQIBAYg9CAXRERcEhVKFbYI0KCMQBwYLhC8EhFoChTKIXIJlg3iBPItlhWGDVU4BAQGBPw X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="323505551" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 09 May 2014 16:38:19 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s49GcJm7014116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 16:38:19 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 May 2014 11:38:18 -0500 Message-ID: <536D047A.5030402@cisco.com> Date: Fri, 9 May 2014 10:38:18 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Campbell , "Richer, Justin P." References: <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> <534AC72E-F7C4-4EAA-B1D7-194CAFC08961@mitre.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Gw-LJyLQJc2LzUeHu9t-6VcaUVc Cc: Antonio Sanso , Axel Nennker , "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 16:38:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 As I said originally, I don't think there's a straight-forward fix here. It seems to me that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" gets the closest to the intent here. I agree that "RSA/ECB/NOPADDING" is contradictory -- yes, you can get the Java code to the JOSE-specified configuration starting with that identifier string, but it's rather misleading without knowing the paramspec. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 5/9/14, 10:31 AM, Brian Campbell wrote: > So while OAEPWithSHA-256AndMGF1Padding is a little redundant with > the OAEPParameterSpec, I'd say NOPADDING seems a little > contradictory. But what do I know? > > I'm still not sure how to concisely explain it in the appendix. > > > On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P. > > wrote: > > I've found that it seems to work if you use NOPADDING, too: > > AlgorithmParameters algp = > AlgorithmParametersHelper.getInstance("OAEP", provider); > AlgorithmParameterSpec paramSpec = new > OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, > PSource.PSpecified.DEFAULT); algp.init(paramSpec); Cipher cipher = > CipherHelper.getInstance("RSA/ECB/NOPADDING", provider); > cipher.init(Cipher.DECRYPT_MODE, priv, algp); > > > (Note that all the AlgorithmParametersHelper does in our code is > install the right provider if given.) > > -- Justin > > On May 9, 2014, at 9:32 AM, Brian Campbell > > > wrote: > >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-4.3 >> >> is pretty clear about which parameters and hash functions to use >> in which OAEP alg. >> >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-A.2 >> >> that you refer to Axel probably needs to be updated because just >> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 >> isn't completely correct (well, maybe it is correct but a bit >> more is also needed). >> >> In order to do RSA-OAPE-265 correctly using the JCA APIs, one >> gets a Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then >> also initialize it with an OAEPParameterSpec that indicates that >> SHA-256 is to be used for MGF1 too.That looks something like >> this (or this is how I did it anyway): >> >> Cipher cipher = >> Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); >> OAEPParameterSpec oaepSpec = new OAEPParameterSpec("SHA-256", >> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); >> cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec); >> >> The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant >> with what's specified in the OAEPParameterSpec but I've not been >> able to figure out any other way to make it work. I don't know >> exactly how to say that in the Key Management Algorithm >> Identifier Cross-Reference but that's apparently what needs to be >> done. >> >> >> >> >> >> On Wed, May 7, 2014 at 8:30 AM, > > wrote: >> >> Does RSA/ECB/OAEPWithSHA-1AndMGF1Padding mean that SHA-256 must >> be used for padding too?____ >> >> I did not read it so.____ >> >> Did somebody manage to use JCA correctly with one algorithm >> specifier like >> RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?____ >> >> __ __ >> >> Axel____ >> >> >> A.2. >> >> >> Key Management Algorithm Identifier Cross-Reference >> ____ >> >> >> This section contains a table cross-referencing the JWE alg >> (algorithm) values defined in this specification with the >> equivalent identifiers used by other standards and software >> packages. ____ >> >> *JWE**____* >> >> >> >> *XML ENC**____* >> >> >> >> *JCA**____* >> >> >> >> *OID**____* >> >> RSA1_5____ >> >> >> >> http://www.w3.org/2001/04/xmlenc#rsa-1_5____ >> >> >> >> RSA/ECB/PKCS1Padding____ >> >> >> >> 1.2.840.113549.1.1.1____ >> >> RSA-OAEP____ >> >> >> >> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p____ >> >> >> >> RSA/ECB/OAEPWithSHA-1AndMGF1Padding____ >> >> >> >> 1.2.840.113549.1.1.7____ >> >> RSA-OAEP-256____ >> >> >> >> http://www.w3.org/2009/xmlenc11#rsa-oaep____ >> >> >> >> RSA/ECB/OAEPWithSHA-256AndMGF1Padding____ >> >> >> >> 1.2.840.113549.1.1.7____ >> >> __ __ >> >> __ __ >> >> -----Original Message----- From: Antonio Sanso >> [mailto:asanso@adobe.com ] Sent: >> Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian >> Campbell; Matt Miller; jose@ietf.org ; >> Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re: >> [jose] RSA-OAEP-256 Example >> >> __ __ >> >> On 5/7/14, 2:21 AM, >> Axel.Nennker@telekom.de> > >> >> wrote:____ >> >>> I think that the java implementations implemented the spec >> and ____ >> >>> everything is ok from that POV.____ >> >>> __ __ >> >>> These implementations are not broken.____ >> >> __ __ >> >> The JOSE Java implementations did not implement the spec, >> though.____ >> >> draft-ietf-jose-json-web-algorithms 4.3 clearly states the hash >> and mask generation functions are to use the same algorithm -- >> SHA-1 (and____ >> >> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 >> with____ >> >> SHA-256) in the case of "RSA-OAEP-256".____ >> >> __ __ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> One could argue that when we replace SHA-1 by SHA-256 in one >> place ____ >> >>> then we might consider to replace it in the padding too.____ >> >> __ __ >> >> That is exactly what draft-ietf-jose-json-web-algorithms >> specified.____ >> >> __ __ >> >>> __ __ >> >>> My feeling is that using sha-256 for the padding does not >> give us more ____ >> >>> security. YMMW____ >> >>> __ __ >> >> __ __ >> >> That is a separate debate, I think. The prevailing opinion (at >> least around the IETF) is "don't mix the algorithms".____ >> >> __ __ >> >> __ __ >> >> --____ >> >> - m&m____ >> >> __ __ >> >> Matt Miller < mamille2@cisco.com> > > Cisco >> Systems, Inc.____ >> >> __ __ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> *From:*jose ____ >> >>> [mailto:jose-bounces@ietf.org >> ] >> >> *On ____ >> >>> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 >> 6:54 AM ____ >> >>> *To:* Matt Miller____ >> >>> *Cc:* Antonio Sanso; jose@ietf.org> > *Subject:* ____ >> >>> Re: [jose]____ >> >>> RSA-OAEP-256 Example____ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> Thanks Matt.____ >> >>> __ __ >> >>> That is why I was looking for someone to verify using a >> different ____ >> >>> platform. Though I was hoping it'd just work.____ >> >>> __ __ >> >>> Matt, can you try decrypting this one by chance? Using the >> same key. I ____ >> >>> was more explicit with the parameters and, I think, MGF1 >> should be ____ >> >>> using SHA-256 now too.____ >> >>> __ __ >> >>> __ __ >> >>> >> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj____ >> >> >> > >> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ____ >> >> >> > >> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi____ >> >> >> > >> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j____ >> >> >> > >> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu____ >> >> >> > >> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9____ >> >> >> > >> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G____ >> >> >> > Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w____ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> On Tue, May 6, 2014 at 8:39 PM, Matt Miller ____ >> >>> > >____ >> >>> > >>> >> wrote:____ >> >>> __ __ >> >>> Short answer: You are all equally broken -- except from a >> certain ____ >> >>> point of view d-:____ >> >>> __ __ >> >>> Long answer: The code I have is based on OpenSSL, which is >> hard-coded ____ >> >>> to use SHA1 for the hash and mask generation (boo!), which >> means one ____ >> >>> has to implement OAEP-SHA256 from scratch (hiss!!).____ >> >>> __ __ >> >>> When I implemented it per RFC 3447 and ____ >> >>> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could >> not ____ >> >>> decrypt the provided results. When I hard-coded MGF1 to use >> "SHA1", I ____ >> >>> could decrypt provided results. A search through >> BouncyCastle's code ____ >> >>> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a >> Hash ____ >> >>> function of____ >> >>> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". >> Further ____ >> >>> evidence is shown with how [FORGE] can be made to work with >> Java ____ >> >>> (search their homepage for "Compatible with Java's ____ >> >>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").____ >> >>> __ __ >> >>> Reconciling all of this with____ >> >>> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not >> look to be ____ >> >>> very straight-forward. It appears that the JCA identifier >> is meant to ____ >> >>> be "MGF1 with SHA1"; that ought to be explicitly noted.____ >> >>> The XMLENC reference is arguably incomplete, since ____ >> >>> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to ____ >> >>> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); >> this can ____ >> >>> probably be addressed by explicitly stating the mask >> generation ____ >> >>> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"____ >> >>> (MGF1 with SHA-256).____ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >>> __ __ >> >> >> >> >> -- Ping Identity logo Brian >> Campbell Portfolio Architect @ bcampbell@pingidentity.com >> phone +1 720.317.2061 >> Connect with us twitter logo >> youtube logo >> LinkedIn logo >> Facebook logo >> Google+ logo >> slideshare >> logo flipboard logo >> rss feed icon >> >> >> Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 1923 July, 2014 | Monterey, CA >> >> >> > > > > > -- Ping Identity logo Brian > Campbell Portfolio Architect @ bcampbell@pingidentity.com > phone +1 720.317.2061 Connect > with us twitter logo youtube > logo LinkedIn logo > Facebook logo > Google+ logo > slideshare > logo flipboard logo > rss feed icon > > > Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 1923 July, 2014 | Monterey, CA > > > > > > _______________________________________________ jose mailing list > jose@ietf.org https://www.ietf.org/mailman/listinfo/jose > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTbQR6AAoJEDWi+S0W7cO14kgH/3RsEgO+jMpMOmHKLxB695iK DHO5wvJKXE/WI5WLlhEpK86TVcghdL7RJWxBXMw5Rz8+p27HLrr0mrBWw7PYBzCL 31fHFpd/OdsI8iaSnVeLXuG/fiPNBmPagYQ0iN/FMgVDI+Ra61dUT1Cq0yyFWFVj 1n1qzkjDhKhw9OkazcKWxp2fXvjhwaxtI/WrchBBPg5bJt0JA4MvlMhvoQHu5+gL d2Qox1TO0j3XltTkvtliorDku1aHCFfNaqLwvDxfu89H+ayvqMHTzgi274y9JmGi YvN1zzITnYkvpaeGC978sqLvg1j5Zh4VvO+3zquFeVJvu4801hrMyzzeSyeRpdc= =2XGV -----END PGP SIGNATURE----- From nobody Sat May 10 14:17:34 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5AE1A00D7 for ; Sat, 10 May 2014 14:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0mJfOfd8oX8 for ; Sat, 10 May 2014 14:17:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EDBEE1A001B for ; Sat, 10 May 2014 14:17:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6C5DE22600F7; Sat, 10 May 2014 17:17:22 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4D9181F036B; Sat, 10 May 2014 17:17:22 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Sat, 10 May 2014 17:17:21 -0400 From: "Richer, Justin P." To: Matt Miller Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaaXt6y9pFg73WUeWYaQCNSAO4Zs00HCAgAA5+gCAAEbmgIAADyMAgAAMIwCAAtakQIAARdKAgAAu24CAAAIEAIAB4FAA Date: Sat, 10 May 2014 21:17:21 +0000 Message-ID: <07A5F5E2-9EFC-4653-BE49-ED24C455FB63@mitre.org> References: <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> <534AC72E-F7C4-4EAA-B1D7-194CAFC08961@mitre.org> <536D047A.5030402@cisco.com> In-Reply-To: <536D047A.5030402@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.50.140] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0C035140CBEE6B4E853CCAC2C141AB6A@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/AMk-iQSJE3yAqIkORvJP8LpkqW4 Cc: Antonio Sanso , Brian Campbell , Axel Nennker , "jose@ietf.org" Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 21:17:32 -0000 The fact is that there's no way to get this kind of signature *without* the= param spec, since it overrides the padding definition defined by the strin= g itself. So there's not actually a single string of any kind in JCE that w= ill do the right thing, and the appendix ought to have both pieces in it. -- Justin On May 9, 2014, at 12:38 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > As I said originally, I don't think there's a straight-forward fix > here. It seems to me that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" > gets the closest to the intent here. >=20 > I agree that "RSA/ECB/NOPADDING" is contradictory -- yes, you can get > the Java code to the JOSE-specified configuration starting with that > identifier string, but it's rather misleading without knowing the > paramspec. >=20 >=20 > - --=20 > - - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > On 5/9/14, 10:31 AM, Brian Campbell wrote: >> So while OAEPWithSHA-256AndMGF1Padding is a little redundant with >> the OAEPParameterSpec, I'd say NOPADDING seems a little >> contradictory. But what do I know? >>=20 >> I'm still not sure how to concisely explain it in the appendix. >>=20 >>=20 >> On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P. >> > wrote: >>=20 >> I've found that it seems to work if you use NOPADDING, too: >>=20 >> AlgorithmParameters algp =3D=20 >> AlgorithmParametersHelper.getInstance("OAEP", provider);=20 >> AlgorithmParameterSpec paramSpec =3D new >> OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, >> PSource.PSpecified.DEFAULT); algp.init(paramSpec); Cipher cipher =3D >> CipherHelper.getInstance("RSA/ECB/NOPADDING", provider);=20 >> cipher.init(Cipher.DECRYPT_MODE, priv, algp); >>=20 >>=20 >> (Note that all the AlgorithmParametersHelper does in our code is=20 >> install the right provider if given.) >>=20 >> -- Justin >>=20 >> On May 9, 2014, at 9:32 AM, Brian Campbell=20 >> > >> wrote: >>=20 >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#secti= on-4.3 >>>=20 >>>=20 > is pretty clear about which parameters and hash functions to use >>> in which OAEP alg. >>>=20 >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appen= dix-A.2 >>>=20 >>>=20 > that you refer to Axel probably needs to be updated because just >>> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265=20 >>> isn't completely correct (well, maybe it is correct but a bit >>> more is also needed). >>>=20 >>> In order to do RSA-OAPE-265 correctly using the JCA APIs, one >>> gets a Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then >>> also initialize it with an OAEPParameterSpec that indicates that=20 >>> SHA-256 is to be used for MGF1 too.That looks something like >>> this (or this is how I did it anyway): >>>=20 >>> Cipher cipher =3D=20 >>> Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");=20 >>> OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA-256",=20 >>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);=20 >>> cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec); >>>=20 >>> The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant=20 >>> with what's specified in the OAEPParameterSpec but I've not been=20 >>> able to figure out any other way to make it work. I don't know=20 >>> exactly how to say that in the Key Management Algorithm >>> Identifier Cross-Reference but that's apparently what needs to be >>> done. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, May 7, 2014 at 8:30 AM, >> > wrote: >>>=20 >>> Does =93RSA/ECB/OAEPWithSHA-1AndMGF1Padding=94 mean that SHA-256 must >>> be used for padding too?____ >>>=20 >>> I did not read it so.____ >>>=20 >>> Did somebody manage to use JCA correctly with one algorithm=20 >>> specifier like >>> RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?____ >>>=20 >>> __ __ >>>=20 >>> Axel____ >>>=20 >>>=20 >>> A.2.=20 >>> >>>=20 >>>=20 > Key Management Algorithm Identifier Cross-Reference >>> ____ >>>=20 >>>=20 >>>=20 > This section contains a table cross-referencing the JWE alg >>> (algorithm) values defined in this specification with the=20 >>> equivalent identifiers used by other standards and software=20 >>> packages. ____ >>>=20 >>> *JWE**____* >>>=20 >>>=20 >>>=20 >>> *XML ENC**____* >>>=20 >>>=20 >>>=20 >>> *JCA**____* >>>=20 >>>=20 >>>=20 >>> *OID**____* >>>=20 >>> RSA1_5____ >>>=20 >>>=20 >>>=20 >>> http://www.w3.org/2001/04/xmlenc#rsa-1_5____ >>>=20 >>>=20 >>>=20 >>> RSA/ECB/PKCS1Padding____ >>>=20 >>>=20 >>>=20 >>> 1.2.840.113549.1.1.1____ >>>=20 >>> RSA-OAEP____ >>>=20 >>>=20 >>>=20 >>> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p____ >>>=20 >>>=20 >>>=20 >>> RSA/ECB/OAEPWithSHA-1AndMGF1Padding____ >>>=20 >>>=20 >>>=20 >>> 1.2.840.113549.1.1.7____ >>>=20 >>> RSA-OAEP-256____ >>>=20 >>>=20 >>>=20 >>> http://www.w3.org/2009/xmlenc11#rsa-oaep____ >>>=20 >>>=20 >>>=20 >>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding____ >>>=20 >>>=20 >>>=20 >>> 1.2.840.113549.1.1.7____ >>>=20 >>> __ __ >>>=20 >>> __ __ >>>=20 >>> -----Original Message----- From: Antonio Sanso >>> [mailto:asanso@adobe.com ] Sent: >>> Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian >>> Campbell; Matt Miller; jose@ietf.org ; >>> Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re: >>> [jose] RSA-OAEP-256 Example >>>=20 >>> __ __ >>>=20 >>> On 5/7/14, 2:21 AM,=20 >>> Axel.Nennker@telekom.de>> > >>>=20 >>>=20 > wrote:____ >>>=20 >>>> I think that the java implementations implemented the spec >>> and ____ >>>=20 >>>> everything is ok from that POV.____ >>>=20 >>>> __ __ >>>=20 >>>> These implementations are not broken.____ >>>=20 >>> __ __ >>>=20 >>> The JOSE Java implementations did not implement the spec,=20 >>> though.____ >>>=20 >>> draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash >>> and mask generation functions are to use the same algorithm -- >>> SHA-1 (and____ >>>=20 >>> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 >>> with____ >>>=20 >>> SHA-256) in the case of "RSA-OAEP-256".____ >>>=20 >>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> One could argue that when we replace SHA-1 by SHA-256 in one >>> place ____ >>>=20 >>>> then we might consider to replace it in the padding too.____ >>>=20 >>> __ __ >>>=20 >>> That is exactly what draft-ietf-jose-json-web-algorithms=20 >>> specified.____ >>>=20 >>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> My feeling is that using sha-256 for the padding does not >>> give us more ____ >>>=20 >>>> security. YMMW____ >>>=20 >>>> __ __ >>>=20 >>> __ __ >>>=20 >>> That is a separate debate, I think. The prevailing opinion (at >>> least around the IETF) is "don't mix the algorithms".____ >>>=20 >>> __ __ >>>=20 >>> __ __ >>>=20 >>> --____ >>>=20 >>> - m&m____ >>>=20 >>> __ __ >>>=20 >>> Matt Miller < mamille2@cisco.com>> > > Cisco >>> Systems, Inc.____ >>>=20 >>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> *From:*jose ____ >>>=20 >>>> [mailto:jose-bounces@ietf.org >>> ] >>>=20 >>>=20 > *On ____ >>>=20 >>>> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 >>> 6:54 AM ____ >>>=20 >>>> *To:* Matt Miller____ >>>=20 >>>> *Cc:* Antonio Sanso; jose@ietf.org>> > *Subject:* ____ >>>=20 >>>> Re: [jose]____ >>>=20 >>>> RSA-OAEP-256 Example____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> Thanks Matt.____ >>>=20 >>>> __ __ >>>=20 >>>> That is why I was looking for someone to verify using a >>> different ____ >>>=20 >>>> platform. Though I was hoping it'd just work.____ >>>=20 >>>> __ __ >>>=20 >>>> Matt, can you try decrypting this one by chance? Using the >>> same key. I ____ >>>=20 >>>> was more explicit with the parameters and, I think, MGF1 >>> should be ____ >>>=20 >>>> using SHA-256 now too.____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>>=20 >>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj_= ___ >>>=20 >>>=20 >>>=20 >>=20 >>> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ_= ___ >>>=20 >>>=20 >>>=20 >>=20 >>> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi_= ___ >>>=20 >>>=20 >>>=20 >>=20 >>> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j_= ___ >>>=20 >>>=20 >>>=20 >>=20 >>> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu_= ___ >>>=20 >>>=20 >>>=20 >>=20 >>> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_= ___ >>>=20 >>>=20 >>>=20 >>=20 >>> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G_= ___ >>>=20 >>>=20 >>>=20 >> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> On Tue, May 6, 2014 at 8:39 PM, Matt Miller ____ >>>=20 >>>> >> >____ >>>=20 >>>> >> >>>=20 >>> wrote:____ >>>=20 >>>> __ __ >>>=20 >>>> Short answer: You are all equally broken -- except from a >>> certain ____ >>>=20 >>>> point of view d-:____ >>>=20 >>>> __ __ >>>=20 >>>> Long answer: The code I have is based on OpenSSL, which is >>> hard-coded ____ >>>=20 >>>> to use SHA1 for the hash and mask generation (boo!), which >>> means one ____ >>>=20 >>>> has to implement OAEP-SHA256 from scratch (hiss!!).____ >>>=20 >>>> __ __ >>>=20 >>>> When I implemented it per RFC 3447 and ____ >>>=20 >>>> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could >>> not ____ >>>=20 >>>> decrypt the provided results. When I hard-coded MGF1 to use >>> "SHA1", I ____ >>>=20 >>>> could decrypt provided results. A search through >>> BouncyCastle's code ____ >>>=20 >>>> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a >>> Hash ____ >>>=20 >>>> function of____ >>>=20 >>>> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". >>> Further ____ >>>=20 >>>> evidence is shown with how [FORGE] can be made to work with >>> Java ____ >>>=20 >>>> (search their homepage for "Compatible with Java's ____ >>>=20 >>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").____ >>>=20 >>>> __ __ >>>=20 >>>> Reconciling all of this with____ >>>=20 >>>> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not >>> look to be ____ >>>=20 >>>> very straight-forward. It appears that the JCA identifier >>> is meant to ____ >>>=20 >>>> be "MGF1 with SHA1"; that ought to be explicitly noted.____ >>>=20 >>>> The XMLENC reference is arguably incomplete, since ____ >>>=20 >>>> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to ____ >>>=20 >>>> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); >>> this can ____ >>>=20 >>>> probably be addressed by explicitly stating the mask >>> generation ____ >>>=20 >>>> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"____ >>>=20 >>>> (MGF1 with SHA-256).____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>=20 >>>=20 >>>=20 >>> -- Ping Identity logo Brian >>> Campbell Portfolio Architect @ bcampbell@pingidentity.com >>> phone +1 720.317.2061 >>> Connect with us=85 twitter logo >>> youtube logo=20 >>> LinkedIn logo=20 >>> Facebook logo=20 >>> Google+ logo=20 >>> slideshare=20 >>> logo flipboard logo=20 >>> rss feed icon=20 >>> >>>=20 >>> Register for Cloud Identity Summit 2014 | Modern Identity=20 >>> Revolution | 19=9623 July, 2014 | Monterey, CA=20 >>> >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> -- Ping Identity logo Brian >> Campbell Portfolio Architect @ bcampbell@pingidentity.com >> phone +1 720.317.2061 Connect >> with us=85 twitter logo youtube >> logo LinkedIn logo=20 >> Facebook logo=20 >> Google+ logo=20 >> slideshare >> logo flipboard logo=20 >> rss feed icon >> >>=20 >> Register for Cloud Identity Summit 2014 | Modern Identity >> Revolution | 19=9623 July, 2014 | Monterey, CA >> >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ jose mailing list=20 >> jose@ietf.org https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBCgAGBQJTbQR6AAoJEDWi+S0W7cO14kgH/3RsEgO+jMpMOmHKLxB695iK > DHO5wvJKXE/WI5WLlhEpK86TVcghdL7RJWxBXMw5Rz8+p27HLrr0mrBWw7PYBzCL > 31fHFpd/OdsI8iaSnVeLXuG/fiPNBmPagYQ0iN/FMgVDI+Ra61dUT1Cq0yyFWFVj > 1n1qzkjDhKhw9OkazcKWxp2fXvjhwaxtI/WrchBBPg5bJt0JA4MvlMhvoQHu5+gL > d2Qox1TO0j3XltTkvtliorDku1aHCFfNaqLwvDxfu89H+ayvqMHTzgi274y9JmGi > YvN1zzITnYkvpaeGC978sqLvg1j5Zh4VvO+3zquFeVJvu4801hrMyzzeSyeRpdc=3D > =3D2XGV > -----END PGP SIGNATURE----- From nobody Sat May 10 14:31:06 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790541A00E8 for ; Sat, 10 May 2014 14:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nZstYC7RFHW for ; Sat, 10 May 2014 14:30:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0666.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::666]) by ietfa.amsl.com (Postfix) with ESMTP id 7B31E1A00DE for ; Sat, 10 May 2014 14:30:59 -0700 (PDT) Received: from CH1PR03CA011.namprd03.prod.outlook.com (10.255.156.156) by BN1PR03MB024.namprd03.prod.outlook.com (10.255.224.42) with Microsoft SMTP Server (TLS) id 15.0.944.11; Sat, 10 May 2014 21:30:30 +0000 Received: from BN1AFFO11FD056.protection.gbl (10.255.156.132) by CH1PR03CA011.outlook.office365.com (10.255.156.156) with Microsoft SMTP Server (TLS) id 15.0.944.11 via Frontend Transport; Sat, 10 May 2014 21:30:30 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD056.mail.protection.outlook.com (10.58.53.71) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Sat, 10 May 2014 21:30:30 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.125]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0181.007; Sat, 10 May 2014 21:30:05 +0000 From: Mike Jones To: "Richer, Justin P." , Matt Miller Thread-Topic: [jose] RSA-OAEP-256 Example Thread-Index: AQHPaNzzUST7t/6zekuLw8sjGcxcCJszSweAgABAdgCAAAExAIAAAPYAgAAHsoCAAOTKgIAAFNOAgAA5+wCAAEbmgIAADyMAgAAMHACAAAMOAIAAAgaAgAMUfYCAAALggIAALueAgAACBACAAeBMgIAAA0dQ Date: Sat, 10 May 2014 21:30:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD164DA@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> <534AC72E-F7C4-4EAA-B1D7-194CAFC08961@mitre.org> <536D047A.5030402@cisco.com> <07A5F5E2-9EFC-4653-BE49-ED24C455FB63@mitre.org> In-Reply-To: <07A5F5E2-9EFC-4653-BE49-ED24C455FB63@mitre.org> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(51704005)(24454002)(199002)(189002)(13464003)(51444003)(479174003)(377454003)(54524002)(33656001)(86612001)(15395725003)(86362001)(92566001)(92726001)(83072002)(55846006)(575784001)(15202345003)(46102001)(26826002)(74662001)(76482001)(77982001)(50466002)(81342001)(81542001)(20776003)(47776003)(21056001)(64706001)(31966008)(23756003)(85852003)(19580395003)(4396001)(15975445006)(66066001)(80022001)(85806002)(6806004)(68736004)(76176999)(97736001)(54356999)(69596002)(19580405001)(44976005)(50986999)(83322001)(99396002)(2009001)(81156002)(15198665003)(87936001)(79102001)(74502001)(84676001)(2656002)(443494003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB024; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02070414A1 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/ZGN9_O_ua7pJdarUGfCnqiTpWRM Cc: Antonio Sanso , "jose@ietf.org" , Axel Nennker , Brian Campbell Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 21:31:04 -0000 I plan to just put both strings in the table the next time edits are made. = Are there other strings or OIDS in the tables that also should be updated,= based on people's implementation experiences? -- Mike -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Saturday, May 10, 2014 2:17 PM To: Matt Miller Cc: Antonio Sanso; Brian Campbell; Axel Nennker; jose@ietf.org Subject: Re: [jose] RSA-OAEP-256 Example The fact is that there's no way to get this kind of signature *without* the= param spec, since it overrides the padding definition defined by the strin= g itself. So there's not actually a single string of any kind in JCE that w= ill do the right thing, and the appendix ought to have both pieces in it. -- Justin On May 9, 2014, at 12:38 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > As I said originally, I don't think there's a straight-forward fix=20 > here. It seems to me that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" > gets the closest to the intent here. >=20 > I agree that "RSA/ECB/NOPADDING" is contradictory -- yes, you can get=20 > the Java code to the JOSE-specified configuration starting with that=20 > identifier string, but it's rather misleading without knowing the=20 > paramspec. >=20 >=20 > - -- > - - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > On 5/9/14, 10:31 AM, Brian Campbell wrote: >> So while OAEPWithSHA-256AndMGF1Padding is a little redundant with the=20 >> OAEPParameterSpec, I'd say NOPADDING seems a little contradictory.=20 >> But what do I know? >>=20 >> I'm still not sure how to concisely explain it in the appendix. >>=20 >>=20 >> On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P. >> > wrote: >>=20 >> I've found that it seems to work if you use NOPADDING, too: >>=20 >> AlgorithmParameters algp =3D >> AlgorithmParametersHelper.getInstance("OAEP", provider);=20 >> AlgorithmParameterSpec paramSpec =3D new OAEPParameterSpec("SHA-256",=20 >> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);=20 >> algp.init(paramSpec); Cipher cipher =3D=20 >> CipherHelper.getInstance("RSA/ECB/NOPADDING", provider);=20 >> cipher.init(Cipher.DECRYPT_MODE, priv, algp); >>=20 >>=20 >> (Note that all the AlgorithmParametersHelper does in our code is=20 >> install the right provider if given.) >>=20 >> -- Justin >>=20 >> On May 9, 2014, at 9:32 AM, Brian Campbell=20 >> > >> wrote: >>=20 >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#se >>> ction-4.3 >>>=20 >>>=20 > is pretty clear about which parameters and hash functions to use >>> in which OAEP alg. >>>=20 >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#ap >>> pendix-A.2 >>>=20 >>>=20 > that you refer to Axel probably needs to be updated because just >>> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't=20 >>> completely correct (well, maybe it is correct but a bit more is also=20 >>> needed). >>>=20 >>> In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a=20 >>> Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also=20 >>> initialize it with an OAEPParameterSpec that indicates that >>> SHA-256 is to be used for MGF1 too.That looks something like this=20 >>> (or this is how I did it anyway): >>>=20 >>> Cipher cipher =3D >>> Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); >>> OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA-256",=20 >>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);=20 >>> cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec); >>>=20 >>> The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant=20 >>> with what's specified in the OAEPParameterSpec but I've not been=20 >>> able to figure out any other way to make it work. I don't know=20 >>> exactly how to say that in the Key Management Algorithm Identifier=20 >>> Cross-Reference but that's apparently what needs to be done. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, May 7, 2014 at 8:30 AM, >> > wrote: >>>=20 >>> Does "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" mean that SHA-256 must be=20 >>> used for padding too?____ >>>=20 >>> I did not read it so.____ >>>=20 >>> Did somebody manage to use JCA correctly with one algorithm=20 >>> specifier like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?____ >>>=20 >>> __ __ >>>=20 >>> Axel____ >>>=20 >>>=20 >>> A.2.=20 >>> >> l#rfc.appendix.A.2> >>>=20 >>>=20 > Key Management Algorithm Identifier Cross-Reference >>> >> l#EncAlgXref>____ >>>=20 >>>=20 >>>=20 > This section contains a table cross-referencing the JWE alg >>> (algorithm) values defined in this specification with the equivalent=20 >>> identifiers used by other standards and software packages. ____ >>>=20 >>> *JWE**____* >>>=20 >>>=20 >>>=20 >>> *XML ENC**____* >>>=20 >>>=20 >>>=20 >>> *JCA**____* >>>=20 >>>=20 >>>=20 >>> *OID**____* >>>=20 >>> RSA1_5____ >>>=20 >>>=20 >>>=20 >>> http://www.w3.org/2001/04/xmlenc#rsa-1_5____ >>>=20 >>>=20 >>>=20 >>> RSA/ECB/PKCS1Padding____ >>>=20 >>>=20 >>>=20 >>> 1.2.840.113549.1.1.1____ >>>=20 >>> RSA-OAEP____ >>>=20 >>>=20 >>>=20 >>> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p____ >>>=20 >>>=20 >>>=20 >>> RSA/ECB/OAEPWithSHA-1AndMGF1Padding____ >>>=20 >>>=20 >>>=20 >>> 1.2.840.113549.1.1.7____ >>>=20 >>> RSA-OAEP-256____ >>>=20 >>>=20 >>>=20 >>> http://www.w3.org/2009/xmlenc11#rsa-oaep____ >>>=20 >>>=20 >>>=20 >>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding____ >>>=20 >>>=20 >>>=20 >>> 1.2.840.113549.1.1.7____ >>>=20 >>> __ __ >>>=20 >>> __ __ >>>=20 >>> -----Original Message----- From: Antonio Sanso=20 >>> [mailto:asanso@adobe.com ] Sent: >>> Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian=20 >>> Campbell; Matt Miller; jose@ietf.org ;=20 >>> Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re: >>> [jose] RSA-OAEP-256 Example >>>=20 >>> __ __ >>>=20 >>> On 5/7/14, 2:21 AM, >>> Axel.Nennker@telekom.de>> > >>>=20 >>>=20 > wrote:____ >>>=20 >>>> I think that the java implementations implemented the spec >>> and ____ >>>=20 >>>> everything is ok from that POV.____ >>>=20 >>>> __ __ >>>=20 >>>> These implementations are not broken.____ >>>=20 >>> __ __ >>>=20 >>> The JOSE Java implementations did not implement the spec,=20 >>> though.____ >>>=20 >>> draft-ietf-jose-json-web-algorithms =A7 4.3 clearly states the hash=20 >>> and mask generation functions are to use the same algorithm -- >>> SHA-1 (and____ >>>=20 >>> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1=20 >>> with____ >>>=20 >>> SHA-256) in the case of "RSA-OAEP-256".____ >>>=20 >>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> One could argue that when we replace SHA-1 by SHA-256 in one >>> place ____ >>>=20 >>>> then we might consider to replace it in the padding too.____ >>>=20 >>> __ __ >>>=20 >>> That is exactly what draft-ietf-jose-json-web-algorithms >>> specified.____ >>>=20 >>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> My feeling is that using sha-256 for the padding does not >>> give us more ____ >>>=20 >>>> security. YMMW____ >>>=20 >>>> __ __ >>>=20 >>> __ __ >>>=20 >>> That is a separate debate, I think. The prevailing opinion (at=20 >>> least around the IETF) is "don't mix the algorithms".____ >>>=20 >>> __ __ >>>=20 >>> __ __ >>>=20 >>> --____ >>>=20 >>> - m&m____ >>>=20 >>> __ __ >>>=20 >>> Matt Miller < mamille2@cisco.com>> > > Cisco=20 >>> Systems, Inc.____ >>>=20 >>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> *From:*jose ____ >>>=20 >>>> [mailto:jose-bounces@ietf.org >>> ] >>>=20 >>>=20 > *On ____ >>>=20 >>>> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 >>> 6:54 AM ____ >>>=20 >>>> *To:* Matt Miller____ >>>=20 >>>> *Cc:* Antonio Sanso; jose@ietf.org>> > *Subject:* ____ >>>=20 >>>> Re: [jose]____ >>>=20 >>>> RSA-OAEP-256 Example____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> Thanks Matt.____ >>>=20 >>>> __ __ >>>=20 >>>> That is why I was looking for someone to verify using a >>> different ____ >>>=20 >>>> platform. Though I was hoping it'd just work.____ >>>=20 >>>> __ __ >>>=20 >>>> Matt, can you try decrypting this one by chance? Using the >>> same key. I ____ >>>=20 >>>> was more explicit with the parameters and, I think, MGF1 >>> should be ____ >>>=20 >>>> using SHA-256 now too.____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>>=20 >>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cM >>> Cj____ >>>=20 >>>=20 >>>=20 >>=20 >>> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442Z >>> gZ____ >>>=20 >>>=20 >>>=20 >>=20 >>> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gW >>> pi____ >>>=20 >>>=20 >>>=20 >>=20 >>> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE >>> 2j____ >>>=20 >>>=20 >>>=20 >>=20 >>> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQc >>> Pu____ >>>=20 >>>=20 >>>=20 >>=20 >>> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1 >>> s9____ >>>=20 >>>=20 >>>=20 >>=20 >>> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH >>> 5G____ >>>=20 >>>=20 >>>=20 >> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> On Tue, May 6, 2014 at 8:39 PM, Matt Miller ____ >>>=20 >>>> >> >____ >>>=20 >>>> >> >>> >>> wrote:____ >>>=20 >>>> __ __ >>>=20 >>>> Short answer: You are all equally broken -- except from a >>> certain ____ >>>=20 >>>> point of view d-:____ >>>=20 >>>> __ __ >>>=20 >>>> Long answer: The code I have is based on OpenSSL, which is >>> hard-coded ____ >>>=20 >>>> to use SHA1 for the hash and mask generation (boo!), which >>> means one ____ >>>=20 >>>> has to implement OAEP-SHA256 from scratch (hiss!!).____ >>>=20 >>>> __ __ >>>=20 >>>> When I implemented it per RFC 3447 and ____ >>>=20 >>>> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could >>> not ____ >>>=20 >>>> decrypt the provided results. When I hard-coded MGF1 to use >>> "SHA1", I ____ >>>=20 >>>> could decrypt provided results. A search through >>> BouncyCastle's code ____ >>>=20 >>>> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a >>> Hash ____ >>>=20 >>>> function of____ >>>=20 >>>> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". >>> Further ____ >>>=20 >>>> evidence is shown with how [FORGE] can be made to work with >>> Java ____ >>>=20 >>>> (search their homepage for "Compatible with Java's ____ >>>=20 >>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").____ >>>=20 >>>> __ __ >>>=20 >>>> Reconciling all of this with____ >>>=20 >>>> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not >>> look to be ____ >>>=20 >>>> very straight-forward. It appears that the JCA identifier >>> is meant to ____ >>>=20 >>>> be "MGF1 with SHA1"; that ought to be explicitly noted.____ >>>=20 >>>> The XMLENC reference is arguably incomplete, since ____ >>>=20 >>>> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to ____ >>>=20 >>>> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); >>> this can ____ >>>=20 >>>> probably be addressed by explicitly stating the mask >>> generation ____ >>>=20 >>>> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"____ >>>=20 >>>> (MGF1 with SHA-256).____ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>> __ __ >>>=20 >>>=20 >>>=20 >>>=20 >>> -- Ping Identity logo Brian >>> Campbell Portfolio Architect @ bcampbell@pingidentity.com >>> phone +1 720.317.2061 >>> Connect with us. twitter logo=20 >>> youtube logo=20 >>> LinkedIn logo=20 >>> Facebook logo=20 >>> Google+ logo=20 >>> slideshare logo=20 >>> flipboard logo=20 >>> rss feed icon=20 >>> >>>=20 >>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution=20 >>> | 19-23 July, 2014 | Monterey, CA=20 >>> >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> -- Ping Identity logo Brian >> Campbell Portfolio Architect @ bcampbell@pingidentity.com >> phone +1 720.317.2061 Connect >> with us. twitter logo youtube logo=20 >> LinkedIn logo=20 >> Facebook logo=20 >> Google+ logo=20 >> slideshare logo=20 >> flipboard logo=20 >> rss feed icon=20 >> >>=20 >> Register for Cloud Identity Summit 2014 | Modern Identity Revolution=20 >> | 19-23 July, 2014 | Monterey, CA=20 >> >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ jose mailing list=20 >> jose@ietf.org https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBCgAGBQJTbQR6AAoJEDWi+S0W7cO14kgH/3RsEgO+jMpMOmHKLxB695iK > DHO5wvJKXE/WI5WLlhEpK86TVcghdL7RJWxBXMw5Rz8+p27HLrr0mrBWw7PYBzCL > 31fHFpd/OdsI8iaSnVeLXuG/fiPNBmPagYQ0iN/FMgVDI+Ra61dUT1Cq0yyFWFVj > 1n1qzkjDhKhw9OkazcKWxp2fXvjhwaxtI/WrchBBPg5bJt0JA4MvlMhvoQHu5+gL > d2Qox1TO0j3XltTkvtliorDku1aHCFfNaqLwvDxfu89H+ayvqMHTzgi274y9JmGi > YvN1zzITnYkvpaeGC978sqLvg1j5Zh4VvO+3zquFeVJvu4801hrMyzzeSyeRpdc=3D > =3D2XGV > -----END PGP SIGNATURE----- _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Sun May 11 07:43:04 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D131A024E for ; Sun, 11 May 2014 07:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psU9U9qizLjb for ; Sun, 11 May 2014 07:42:51 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 98EA11A0225 for ; Sun, 11 May 2014 07:42:50 -0700 (PDT) Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKU2+MZMmQxKUu77wJNh4s9DvuUt5ehxGM@postini.com; Sun, 11 May 2014 07:42:45 PDT Received: by mail-ig0-f180.google.com with SMTP id c1so2900918igq.1 for ; Sun, 11 May 2014 07:42:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0zdw0XseO6TcTGLaujynPT3qojWWcmJhJTsvLXt4KGU=; b=ZX1e+CqJsoxhPvTdQAtkXXq62sPnzF7BR9ws5xk4xRY3UWjpzZ9Ukve5tdgfVzfZzh HsZjiBApAAI9FF4NW1w6RZIadge4Az9XIAZCt8IgLWjrkGeSs2NM3ywejnBGc/uFvYze qQMtbcySpbUYAwuEZNOlKQYskQvHIQSdZRcvQNBcLikFZdhDSM0P9kuUgBGxspwQWixj mSlX46Qkjc97EQePTi32eROo9aIgBJVOnQlDuUkPJB++07GcKKGyAdS9u1KWjQHdseBI 8yW4udnZSC+6xPQ0hb64iN3CwbtjFCrCTFb3FrCD7dz7WbIG3Zo5h18Z0RCYFHzLPpY0 TMmw== X-Gm-Message-State: ALoCoQlFS9fsqSMCIk3vHNx/fUlXbg2m5kAMfbiOhSUMevVWzXnke3IwYIHAqej2QZmzzgRedPtCWKpk74FhQOkAgK1UQovgIK8s/muJ6IIxGXMQyG0cEx4FFxJnQA3vW7OqlTqrwWC6 X-Received: by 10.50.79.226 with SMTP id m2mr33203659igx.11.1399819364683; Sun, 11 May 2014 07:42:44 -0700 (PDT) X-Received: by 10.50.79.226 with SMTP id m2mr33203627igx.11.1399819364529; Sun, 11 May 2014 07:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.201 with HTTP; Sun, 11 May 2014 07:42:14 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD164DA@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <7BAE8830-3CD7-4BD5-B1E7-6A09FE34F402@adobe.com> <5369AAE7.2060704@cisco.com> <536A287B.4030905@cisco.com> <04474579-8878-47FB-8218-45B6EE618C6F@mitre.org> <534AC72E-F7C4-4EAA-B1D7-194CAFC08961@mitre.org> <536D047A.5030402@cisco.com> <07A5F5E2-9EFC-4653-BE49-ED24C455FB63@mitre.org> <4E1F6AAD24975D4BA5B16804296739439AD164DA@TK5EX14MBXC292.redmond.corp.microsoft.com> From: Brian Campbell Date: Sun, 11 May 2014 08:42:14 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e01160752f90ba704f920d75f Archived-At: http://mailarchive.ietf.org/arch/msg/jose/JSH-iRIg1vDbEu3BaSIOwF6mre4 Cc: Antonio Sanso , "jose@ietf.org" , "Richer, Justin P." , Axel Nennker , Matt Miller Subject: Re: [jose] RSA-OAEP-256 Example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 14:42:56 -0000 --089e01160752f90ba704f920d75f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, I've got a few potential updates to the table based on my experience building https://bitbucket.org/b_c/jose4j "AESWrap" is the JCA string/transform for A128KW, A192KW and A256KW. For ECDH-ES, the java algorithm for the key agreement part is "ECDH". AFAIK, there is nothing in the JCA that does the KDF so that part needs to be written 'from scratch' using a SHA-256 message digest. Dunno how much of that you want to try and capture in the table, maybe just "ECDH" is good. The AES key wrap part of the ECDH-ES+AxxxKW ones use same "AESWrap" as the AxxxKW above. A128GCMKW, A192GCMKW and A256GCMKW, which aren't currently in appendix A.2 all use the same JCA algorithm as their AxxxGCM content encryption counterparts: "AES/GCM/NoPadding" "PBKDF2WithHmacSHA256", "PBKDF2WithHmacSHA384" and "PBKDF2WithHmacSHA512" would be the SecretKeyFactory JCA algorithms for the PBKDF2 part of PBES2-HS256+A128KW, PBES2-HS384+A192KW and PBES2-HS512+A256KW respectively. But they aren't widely implemented (only in the Java 8 provider, I think, most providers only seem to have PBKDF2WithHmacSHA1) so I ended up writing my own PBKDF2 using the corresponding HMAC-SHA2 Mac. The encryption part is the same as the AxxxKW. On Sat, May 10, 2014 at 3:30 PM, Mike Jones wr= ote: > I plan to just put both strings in the table the next time edits are made= . > Are there other strings or OIDS in the tables that also should be update= d, > based on people's implementation experiences? > > -- Mike > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richer, Justin P. > Sent: Saturday, May 10, 2014 2:17 PM > To: Matt Miller > Cc: Antonio Sanso; Brian Campbell; Axel Nennker; jose@ietf.org > Subject: Re: [jose] RSA-OAEP-256 Example > > The fact is that there's no way to get this kind of signature *without* > the param spec, since it overrides the padding definition defined by the > string itself. So there's not actually a single string of any kind in JCE > that will do the right thing, and the appendix ought to have both pieces = in > it. > > -- Justin > > On May 9, 2014, at 12:38 PM, Matt Miller wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > As I said originally, I don't think there's a straight-forward fix > > here. It seems to me that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" > > gets the closest to the intent here. > > > > I agree that "RSA/ECB/NOPADDING" is contradictory -- yes, you can get > > the Java code to the JOSE-specified configuration starting with that > > identifier string, but it's rather misleading without knowing the > > paramspec. > > > > > > - -- > > - - m&m > > > > Matt Miller < mamille2@cisco.com > > > Cisco Systems, Inc. > > > > On 5/9/14, 10:31 AM, Brian Campbell wrote: > >> So while OAEPWithSHA-256AndMGF1Padding is a little redundant with the > >> OAEPParameterSpec, I'd say NOPADDING seems a little contradictory. > >> But what do I know? > >> > >> I'm still not sure how to concisely explain it in the appendix. > >> > >> > >> On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P. > >> > wrote: > >> > >> I've found that it seems to work if you use NOPADDING, too: > >> > >> AlgorithmParameters algp =3D > >> AlgorithmParametersHelper.getInstance("OAEP", provider); > >> AlgorithmParameterSpec paramSpec =3D new OAEPParameterSpec("SHA-256", > >> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); > >> algp.init(paramSpec); Cipher cipher =3D > >> CipherHelper.getInstance("RSA/ECB/NOPADDING", provider); > >> cipher.init(Cipher.DECRYPT_MODE, priv, algp); > >> > >> > >> (Note that all the AlgorithmParametersHelper does in our code is > >> install the right provider if given.) > >> > >> -- Justin > >> > >> On May 9, 2014, at 9:32 AM, Brian Campbell > >> > > >> wrote: > >> > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#se > >>> ction-4.3 > >>> > >>> > > is pretty clear about which parameters and hash functions to use > >>> in which OAEP alg. > >>> > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#ap > >>> pendix-A.2 > >>> > >>> > > that you refer to Axel probably needs to be updated because just > >>> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't > >>> completely correct (well, maybe it is correct but a bit more is also > >>> needed). > >>> > >>> In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a > >>> Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also > >>> initialize it with an OAEPParameterSpec that indicates that > >>> SHA-256 is to be used for MGF1 too.That looks something like this > >>> (or this is how I did it anyway): > >>> > >>> Cipher cipher =3D > >>> Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); > >>> OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA-256", > >>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); > >>> cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec); > >>> > >>> The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant > >>> with what's specified in the OAEPParameterSpec but I've not been > >>> able to figure out any other way to make it work. I don't know > >>> exactly how to say that in the Key Management Algorithm Identifier > >>> Cross-Reference but that's apparently what needs to be done. > >>> > >>> > >>> > >>> > >>> > >>> On Wed, May 7, 2014 at 8:30 AM, >>> > wrote: > >>> > >>> Does "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" mean that SHA-256 must be > >>> used for padding too?____ > >>> > >>> I did not read it so.____ > >>> > >>> Did somebody manage to use JCA correctly with one algorithm > >>> specifier like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?____ > >>> > >>> __ __ > >>> > >>> Axel____ > >>> > >>> > >>> A.2. > >>> >>> l#rfc.appendix.A.2> > >>> > >>> > > Key Management Algorithm Identifier Cross-Reference > >>> >>> l#EncAlgXref>____ > >>> > >>> > >>> > > This section contains a table cross-referencing the JWE alg > >>> (algorithm) values defined in this specification with the equivalent > >>> identifiers used by other standards and software packages. ____ > >>> > >>> *JWE**____* > >>> > >>> > >>> > >>> *XML ENC**____* > >>> > >>> > >>> > >>> *JCA**____* > >>> > >>> > >>> > >>> *OID**____* > >>> > >>> RSA1_5____ > >>> > >>> > >>> > >>> http://www.w3.org/2001/04/xmlenc#rsa-1_5____ > >>> > >>> > >>> > >>> RSA/ECB/PKCS1Padding____ > >>> > >>> > >>> > >>> 1.2.840.113549.1.1.1____ > >>> > >>> RSA-OAEP____ > >>> > >>> > >>> > >>> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p____ > >>> > >>> > >>> > >>> RSA/ECB/OAEPWithSHA-1AndMGF1Padding____ > >>> > >>> > >>> > >>> 1.2.840.113549.1.1.7____ > >>> > >>> RSA-OAEP-256____ > >>> > >>> > >>> > >>> http://www.w3.org/2009/xmlenc11#rsa-oaep____ > >>> > >>> > >>> > >>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding____ > >>> > >>> > >>> > >>> 1.2.840.113549.1.1.7____ > >>> > >>> __ __ > >>> > >>> __ __ > >>> > >>> -----Original Message----- From: Antonio Sanso > >>> [mailto:asanso@adobe.com ] Sent: > >>> Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian > >>> Campbell; Matt Miller; jose@ietf.org ; > >>> Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re: > >>> [jose] RSA-OAEP-256 Example > >>> > >>> __ __ > >>> > >>> On 5/7/14, 2:21 AM, > >>> Axel.Nennker@telekom.de >>> > > >>> > >>> > > wrote:____ > >>> > >>>> I think that the java implementations implemented the spec > >>> and ____ > >>> > >>>> everything is ok from that POV.____ > >>> > >>>> __ __ > >>> > >>>> These implementations are not broken.____ > >>> > >>> __ __ > >>> > >>> The JOSE Java implementations did not implement the spec, > >>> though.____ > >>> > >>> draft-ietf-jose-json-web-algorithms =C2=A7 4.3 clearly states the has= h > >>> and mask generation functions are to use the same algorithm -- > >>> SHA-1 (and____ > >>> > >>> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 > >>> with____ > >>> > >>> SHA-256) in the case of "RSA-OAEP-256".____ > >>> > >>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> One could argue that when we replace SHA-1 by SHA-256 in one > >>> place ____ > >>> > >>>> then we might consider to replace it in the padding too.____ > >>> > >>> __ __ > >>> > >>> That is exactly what draft-ietf-jose-json-web-algorithms > >>> specified.____ > >>> > >>> __ __ > >>> > >>>> __ __ > >>> > >>>> My feeling is that using sha-256 for the padding does not > >>> give us more ____ > >>> > >>>> security. YMMW____ > >>> > >>>> __ __ > >>> > >>> __ __ > >>> > >>> That is a separate debate, I think. The prevailing opinion (at > >>> least around the IETF) is "don't mix the algorithms".____ > >>> > >>> __ __ > >>> > >>> __ __ > >>> > >>> --____ > >>> > >>> - m&m____ > >>> > >>> __ __ > >>> > >>> Matt Miller < mamille2@cisco.com >>> > > Cisco > >>> Systems, Inc.____ > >>> > >>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> *From:*jose ____ > >>> > >>>> [mailto:jose-bounces@ietf.org > >>> ] > >>> > >>> > > *On ____ > >>> > >>>> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 > >>> 6:54 AM ____ > >>> > >>>> *To:* Matt Miller____ > >>> > >>>> *Cc:* Antonio Sanso; jose@ietf.org >>> > *Subject:* ____ > >>> > >>>> Re: [jose]____ > >>> > >>>> RSA-OAEP-256 Example____ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> Thanks Matt.____ > >>> > >>>> __ __ > >>> > >>>> That is why I was looking for someone to verify using a > >>> different ____ > >>> > >>>> platform. Though I was hoping it'd just work.____ > >>> > >>>> __ __ > >>> > >>>> Matt, can you try decrypting this one by chance? Using the > >>> same key. I ____ > >>> > >>>> was more explicit with the parameters and, I think, MGF1 > >>> should be ____ > >>> > >>>> using SHA-256 now too.____ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> > >>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cM > >>> Cj____ > >>> > >>> > >>> > >> > >>> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442Z > >>> gZ____ > >>> > >>> > >>> > >> > >>> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gW > >>> pi____ > >>> > >>> > >>> > >> > >>> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE > >>> 2j____ > >>> > >>> > >>> > >> > >>> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQc > >>> Pu____ > >>> > >>> > >>> > >> > >>> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1 > >>> s9____ > >>> > >>> > >>> > >> > >>> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH > >>> 5G____ > >>> > >>> > >>> > >> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w____ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> On Tue, May 6, 2014 at 8:39 PM, Matt Miller ____ > >>> > >>>> >>> >____ > >>> > >>>> >>> >>> > >>> wrote:____ > >>> > >>>> __ __ > >>> > >>>> Short answer: You are all equally broken -- except from a > >>> certain ____ > >>> > >>>> point of view d-:____ > >>> > >>>> __ __ > >>> > >>>> Long answer: The code I have is based on OpenSSL, which is > >>> hard-coded ____ > >>> > >>>> to use SHA1 for the hash and mask generation (boo!), which > >>> means one ____ > >>> > >>>> has to implement OAEP-SHA256 from scratch (hiss!!).____ > >>> > >>>> __ __ > >>> > >>>> When I implemented it per RFC 3447 and ____ > >>> > >>>> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could > >>> not ____ > >>> > >>>> decrypt the provided results. When I hard-coded MGF1 to use > >>> "SHA1", I ____ > >>> > >>>> could decrypt provided results. A search through > >>> BouncyCastle's code ____ > >>> > >>>> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a > >>> Hash ____ > >>> > >>>> function of____ > >>> > >>>> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". > >>> Further ____ > >>> > >>>> evidence is shown with how [FORGE] can be made to work with > >>> Java ____ > >>> > >>>> (search their homepage for "Compatible with Java's ____ > >>> > >>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").____ > >>> > >>>> __ __ > >>> > >>>> Reconciling all of this with____ > >>> > >>>> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not > >>> look to be ____ > >>> > >>>> very straight-forward. It appears that the JCA identifier > >>> is meant to ____ > >>> > >>>> be "MGF1 with SHA1"; that ought to be explicitly noted.____ > >>> > >>>> The XMLENC reference is arguably incomplete, since ____ > >>> > >>>> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to ____ > >>> > >>>> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); > >>> this can ____ > >>> > >>>> probably be addressed by explicitly stating the mask > >>> generation ____ > >>> > >>>> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"____ > >>> > >>>> (MGF1 with SHA-256).____ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>>> __ __ > >>> > >>> > >>> > >>> > >>> -- Ping Identity logo Brian > >>> Campbell Portfolio Architect @ bcampbell@pingidentity.com > >>> phone +1 720.317.2061 > >>> Connect with us. twitter logo > >>> youtube logo > >>> LinkedIn logo > >>> Facebook logo > >>> Google+ logo > >>> slideshare logo > >>> flipboard logo > >>> rss feed icon > >>> > >>> > >>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution > >>> | 19-23 July, 2014 | Monterey, CA > >>> > >>> > >>> > >> > >> > >> > >> > >> -- Ping Identity logo Brian > >> Campbell Portfolio Architect @ bcampbell@pingidentity.com > >> phone +1 720.317.2061 Connect > >> with us. twitter logo youtube logo > >> LinkedIn logo > >> Facebook logo > >> Google+ logo > >> slideshare logo > >> flipboard logo > >> rss feed icon > >> > >> > >> Register for Cloud Identity Summit 2014 | Modern Identity Revolution > >> | 19-23 July, 2014 | Monterey, CA > >> > >> > >> > >> > >> > >> _______________________________________________ jose mailing list > >> jose@ietf.org https://www.ietf.org/mailman/listinfo/jose > >> > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > Comment: GPGTools - https://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQEcBAEBCgAGBQJTbQR6AAoJEDWi+S0W7cO14kgH/3RsEgO+jMpMOmHKLxB695iK > > DHO5wvJKXE/WI5WLlhEpK86TVcghdL7RJWxBXMw5Rz8+p27HLrr0mrBWw7PYBzCL > > 31fHFpd/OdsI8iaSnVeLXuG/fiPNBmPagYQ0iN/FMgVDI+Ra61dUT1Cq0yyFWFVj > > 1n1qzkjDhKhw9OkazcKWxp2fXvjhwaxtI/WrchBBPg5bJt0JA4MvlMhvoQHu5+gL > > d2Qox1TO0j3XltTkvtliorDku1aHCFfNaqLwvDxfu89H+ayvqMHTzgi274y9JmGi > > YvN1zzITnYkvpaeGC978sqLvg1j5Zh4VvO+3zquFeVJvu4801hrMyzzeSyeRpdc=3D > > =3D2XGV > > -----END PGP SIGNATURE----- > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 [image: Ping Identity logo] Brian Campbell Portfolio Architect @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 Connect with us=E2=80=A6 [image: twitter logo] = [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] [image: Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19=E2=80=9323 July, 2014 | Monterey, CA] --089e01160752f90ba704f920d75f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, I've got a few potential updates to the tab= le based on my experience building https://bitbucket.org/b_c/jose4j=C2=A0

"AESWrap"= is the JCA string/transform for A128KW, A192KW and A256KW.

For ECDH-ES, the java algorithm for the key agreement part is &qu= ot;ECDH". AFAIK, there is nothing in the JCA that does the KDF so that= part needs to be written 'from scratch' using a SHA-256 message di= gest. Dunno how much of that you want to try and capture in the table, mayb= e just "ECDH" is good. The AES key wrap part of the ECDH-ES+AxxxK= W ones use same "AESWrap" as the AxxxKW above.

A128GCMKW, A192GCMKW and = A256GCMKW, which aren't currently in appendix A.2 all use the sa= me JCA algorithm as their AxxxGCM content encryption counterparts: "AE= S/GCM/NoPadding"

"PBKDF2WithHmacSHA256", "PBKDF2WithHmacSHA384" and = "PBKDF2WithHmacSHA512" would be the SecretKeyFactory JCA algorith= ms for the PBKDF2 part of PBES2-HS256+A128KW, PBES2-HS384+A192KW and PBES2-= HS512+A256KW respectively.=C2=A0 But they aren't widely implemented (on= ly in the Java 8 provider, I think, most providers only seem to have PBKDF2= WithHmacSHA1) so I ended up writing my own PBKDF2 using the corresponding H= MAC-SHA2 Mac.=C2=A0 The encryption part is the same as the AxxxKW.


=C2=A0


=C2=A0



On Sat, May 10, 2014 at 3:30 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
I plan to just put both strings in the table= the next time edits are made. =C2=A0Are there other strings or OIDS in the= tables that also should be updated, based on people's implementation e= xperiences?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Richer, Justin P.
Sent: Saturday, May 10, 2014 2:17 PM
To: Matt Miller
Cc: Antonio Sanso; Brian Campbell; Axel Nennker; jose@ietf.org
Subject: Re: [jose] RSA-OAEP-256 Example

The fact is that there's no way to get thi= s kind of signature *without* the param spec, since it overrides the paddin= g definition defined by the string itself. So there's not actually a si= ngle string of any kind in JCE that will do the right thing, and the append= ix ought to have both pieces in it.

=C2=A0-- Justin

On May 9, 2014, at 12:38 PM, Matt Miller <mamille2@cisco.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> As I said originally, I don't think there's a straight-forward= fix
> here. =C2=A0It seems to me that "RSA/ECB/OAEPWithSHA-256AndMGF1Pa= dding"
> gets the closest to the intent here.
>
> I agree that "RSA/ECB/NOPADDING" is contradictory -- yes, yo= u can get
> the Java code to the JOSE-specified configuration starting with that > identifier string, but it's rather misleading without knowing the<= br> > paramspec.
>
>
> - --
> - - m&m
>
> Matt Miller < mamille2@cisco.= com >
> Cisco Systems, Inc.
>
> On 5/9/14, 10:31 AM, Brian Campbell wrote:
>> So while OAEPWithSHA-256AndMGF1Padding is a little redundant with = the
>> OAEPParameterSpec, I'd say NOPADDING seems a little contradict= ory.
>> But what do I know?
>>
>> I'm still not sure how to concisely explain it in the appendix= .
>>
>>
>> On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P.
>> <jricher@mitre.org <= ;mailto:jricher@mitre.org>> = wrote:
>>
>> I've found that it seems to work if you use NOPADDING, too: >>
>> AlgorithmParameters algp =3D
>> AlgorithmParametersHelper.getInstance("OAEP", provider);=
>> AlgorithmParameterSpec paramSpec =3D new OAEPParameterSpec("S= HA-256",
>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEF= AULT);
>> algp.init(paramSpec); Cipher cipher =3D
>> CipherHelper.getInstance("RSA/ECB/NOPADDING", provider);=
>> cipher.init(Cipher.DECRYPT_MODE, priv, algp);
>>
>>
>> (Note that all the AlgorithmParametersHelper does in our code is >> install the right provider if given.)
>>
>> -- Justin
>>
>> On May 9, 2014, at 9:32 AM, Brian Campbell
>> <bcampbell@pingid= entity.com <mailto:bca= mpbell@pingidentity.com>>
>> wrote:
>>
>>> http://tools.ietf.org/html/draft-ietf-= jose-json-web-algorithms-26#se
>>> ction-4.3
>>>
>>>
> is pretty clear about which parameters and hash functions to use
>>> in which OAEP alg.
>>>
>>> http://tools.ietf.org/html/draft-ietf-= jose-json-web-algorithms-26#ap
>>> pendix-A.2
>>>
>>>
> that you refer to Axel probably needs to be updated because just
>>> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265= isn't
>>> completely correct (well, maybe it is correct but a bit more i= s also
>>> needed).
>>>
>>> In order to do RSA-OAPE-265 correctly using the JCA APIs, one = gets a
>>> Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then als= o
>>> initialize it with an OAEPParameterSpec that indicates that >>> SHA-256 is to be used for MGF1 too.That looks something like t= his
>>> (or this is how I did it anyway):
>>>
>>> Cipher cipher =3D
>>> Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding= ");
>>> OAEPParameterSpec oaepSpec =3D new OAEPParameterSpec("SHA= -256",
>>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified= .DEFAULT);
>>> cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec);
>>>
>>> The "...WithSHA-256AndMGF1Padding" part seems somewh= at redundant
>>> with what's specified in the OAEPParameterSpec but I'v= e not been
>>> able to figure out any other way to make it work. I don't = know
>>> exactly how to say that in the Key Management Algorithm Identi= fier
>>> Cross-Reference but that's apparently what needs to be don= e.
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 7, 2014 at 8:30 AM, <Axel.Nennker@telekom.de
>>> <mailto:Axel.Nen= nker@telekom.de>> wrote:
>>>
>>> Does "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" mean that= SHA-256 must be
>>> used for padding too?____
>>>
>>> I did not read it so.____
>>>
>>> Did somebody manage to use JCA correctly with one algorithm >>> specifier like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?= ____
>>>
>>> __ __
>>>
>>> Axel____
>>>
>>>
>>> A.2.
>>> <http://tools.ietf.org/id/draft-ietf= -jose-json-web-algorithms-26.htm
>>> l#rfc.appendix.A.2>
>>>
>>>
> Key Management Algorithm Identifier Cross-Reference
>>> <http://tools.ietf.org/id/draft-ietf= -jose-json-web-algorithms-26.htm
>>> l#EncAlgXref>____
>>>
>>>
>>>
> This section contains a table cross-referencing the JWE alg
>>> (algorithm) values defined in this specification with the equi= valent
>>> identifiers used by other standards and software packages. ___= _
>>>
>>> *JWE**____*
>>>
>>>
>>>
>>> *XML ENC**____*
>>>
>>>
>>>
>>> *JCA**____*
>>>
>>>
>>>
>>> *OID**____*
>>>
>>> RSA1_5____
>>>
>>>
>>>
>>> http://www.w3.org/2001/04/xmlenc#rsa-1_5____
>>>
>>>
>>>
>>> RSA/ECB/PKCS1Padding____
>>>
>>>
>>>
>>> 1.2.840.113549.1.1.1____
>>>
>>> RSA-OAEP____
>>>
>>>
>>>
>>> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p____=
>>>
>>>
>>>
>>> RSA/ECB/OAEPWithSHA-1AndMGF1Padding____
>>>
>>>
>>>
>>> 1.2.840.113549.1.1.7____
>>>
>>> RSA-OAEP-256____
>>>
>>>
>>>
>>> http://www.w3.org/2009/xmlenc11#rsa-oaep____
>>>
>>>
>>>
>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding____
>>>
>>>
>>>
>>> 1.2.840.113549.1.1.7____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> -----Original Message----- From: Antonio Sanso
>>> [mailto:asanso@adobe.com <mailto:asanso@adobe.com>]= Sent:
>>> Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Bria= n
>>> Campbell; Matt Miller; jose@i= etf.org <mailto:jose@ietf.org&g= t;;
>>> Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re:
>>> [jose] RSA-OAEP-256 Example
>>>
>>> __ __
>>>
>>> On 5/7/14, 2:21 AM,
>>> Axel.Nennker@teleko= m.de<mailto:Axel.Nennker@= telekom.de
>>> <mailto:Axel.Nen= nker@telekom.de%3= cmailto:Axel.Nennker@telekom.de>>
>>>
>>>
> wrote:____
>>>
>>>> I think that the java implementations implemented the spec=
>>> and ____
>>>
>>>> everything is ok from that POV.____
>>>
>>>> __ __
>>>
>>>> These implementations are not broken.____
>>>
>>> __ __
>>>
>>> The JOSE Java implementations did not implement the spec,
>>> though.____
>>>
>>> draft-ietf-jose-json-web-algorithms =C2=A7 4.3 clearly states = the hash
>>> and mask generation functions are to use the same algorithm --=
>>> SHA-1 (and____
>>>
>>> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-= 256 (and MGF1
>>> with____
>>>
>>> SHA-256) in the case of "RSA-OAEP-256".____
>>>
>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> One could argue that when we replace SHA-1 by SHA-256 in o= ne
>>> place ____
>>>
>>>> then we might consider to replace it in the padding too.__= __
>>>
>>> __ __
>>>
>>> That is exactly what draft-ietf-jose-json-web-algorithms
>>> specified.____
>>>
>>> __ __
>>>
>>>> __ __
>>>
>>>> My feeling is that using sha-256 for the padding does not<= br> >>> give us more ____
>>>
>>>> security. YMMW____
>>>
>>>> __ __
>>>
>>> __ __
>>>
>>> That is a separate debate, I think. =C2=A0The prevailing opini= on (at
>>> least around the IETF) is "don't mix the algorithms&q= uot;.____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> --____
>>>
>>> - m&m____
>>>
>>> __ __
>>>
>>> Matt Miller < mamille= 2@cisco.com<mailto:mamille2@ci= sco.com
>>> <mailto:mamille2@cisc= o.com%3cmailto:mamille= 2@cisco.com>> > Cisco
>>> Systems, Inc.____
>>>
>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> *From:*jose ____
>>>
>>>> [mailto:jose-boun= ces@ietf.org<mailto:jose-bo= unces@ietf.org>
>>> <mailto:jose-bounc= es@ietf.org%3cmailt= o:jose-bounces@ietf.org%3e>]
>>>
>>>
> *On ____
>>>
>>>> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014<= br> >>> 6:54 AM ____
>>>
>>>> *To:* Matt Miller____
>>>
>>>> *Cc:* Antonio Sanso; jose= @ietf.org<mailto:jose@ietf.org<= br> >>> <mailto:jose@ietf.org%= 3cmailto:jose@ietf.org>&= gt; *Subject:* ____
>>>
>>>> Re: [jose]____
>>>
>>>> RSA-OAEP-256 Example____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> Thanks Matt.____
>>>
>>>> __ __
>>>
>>>> That is why I was looking for someone to verify using a >>> different ____
>>>
>>>> platform. Though I was hoping it'd just work.____
>>>
>>>> __ __
>>>
>>>> Matt, can you try decrypting this one by chance? Using the=
>>> same key. I ____
>>>
>>>> was more explicit with the parameters and, I think, MGF1 >>> should be ____
>>>
>>>> using SHA-256 now too.____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>>
>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL= 5IL5cM
>>> Cj____
>>>
>>>
>>>
>>
>>> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3U= EL442Z
>>> gZ____
>>>
>>>
>>>
>>
>>> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eeh= bCA3gW
>>> pi____
>>>
>>>
>>>
>>
>>> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_= EJxmcE
>>> 2j____
>>>
>>>
>>>
>>
>>> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGp= MleIQc
>>> Pu____
>>>
>>>
>>>
>>
>>> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P= 8UAzh1
>>> s9____
>>>
>>>
>>>
>>
>>> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRC= p2feAH
>>> 5G____
>>>
>>>
>>>
>> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> On Tue, May 6, 2014 at 8:39 PM, Matt Miller ____
>>>
>>>> <mamille2@cisco.c= om<mailto:mamille2@cisco.com
>>> <mailto:
mamille2@cisc= o.com%3cmailto:mamille= 2@cisco.com>>____
>>>
>>>> <mailto:mamille2@= cisco.com<mailto:mamille2@cisc= o.com
>>> <mailto:mamille2@cisc= o.com%3cmailto:mamille= 2@cisco.com>>>>
>>> wrote:____
>>>
>>>> __ __
>>>
>>>> Short answer: You are all equally broken -- except from a<= br> >>> certain ____
>>>
>>>> point of view d-:____
>>>
>>>> __ __
>>>
>>>> Long answer: The code I have is based on OpenSSL, which is=
>>> hard-coded ____
>>>
>>>> to use SHA1 for the hash and mask generation (boo!), which=
>>> means one ____
>>>
>>>> has to implement OAEP-SHA256 from scratch (hiss!!).____ >>>
>>>> __ __
>>>
>>>> When I implemented it per RFC 3447 and ____
>>>
>>>> draft-ietf-jose-json-web-algorithms-26#section-4.3, I coul= d
>>> not ____
>>>
>>>> decrypt the provided results. =C2=A0When I hard-coded MGF1= to use
>>> "SHA1", I ____
>>>
>>>> could decrypt provided results. =C2=A0A search through
>>> BouncyCastle's code ____
>>>
>>>> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding&quo= t; uses a
>>> Hash ____
>>>
>>>> function of____
>>>
>>>> SHA-256 generate the lHash but its MGF1 uses a "SHA-1= ".
>>> Further ____
>>>
>>>> evidence is shown with how [FORGE] can be made to work wit= h
>>> Java ____
>>>
>>>> (search their homepage for "Compatible with Java'= s ____
>>>
>>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").____
>>>
>>>> __ __
>>>
>>>> Reconciling all of this with____
>>>
>>>> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not<= br> >>> look to be ____
>>>
>>>> very straight-forward. =C2=A0It appears that the JCA ident= ifier
>>> is meant to ____
>>>
>>>> be "MGF1 with SHA1"; that ought to be explicitly= noted.____
>>>
>>>> The XMLENC reference is arguably incomplete, since ____ >>>
>>>> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defau= lts to ____
>>>
>>>> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1= with SHA1);
>>> this can ____
>>>
>>>> probably be addressed by explicitly stating the mask
>>> generation ____
>>>
>>>> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256= "____
>>>
>>>> (MGF1 with SHA-256).____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>
>>>
>>>
>>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>>> Campbell Portfolio Architect @ =C2=A0 =C2=A0 =C2=A0bcampbell@pingidentity.com
>>> <mailto:bcamp= bell@pingidentity.com> phone =C2=A0 +1 720.317.2061
>>> <tel:%2B1%20720.317.2061> Connect with us. t= witter logo
>>> <https://twitter.com/pingidentity> youtube logo<= br> >>> <https://www.youtube.com/user/PingIdentityTV> LinkedI= n logo
>>> <https://www.linkedin.com/company/21870> Facebook logo >>> <https://www.facebook.com/pingidentitypage> Google+ log= o
>>> <https://plus.google.com/u/0/114266977739397708540= > slideshare logo
>>> <http://www.slideshare.net/PingIdentity> flipboard logo >>> <http://= flip.it/vjBF7> rss feed icon
>>> <https://www.pingidentity.com/blogs/>
>>>
>>> Register for Cloud Identity Summit 2014 | Modern Identity Revo= lution
>>> | 19-23 July, 2014 | Monterey, CA
>>> <https://www.cloudidentitysummit.com/>
>>>
>>>
>>
>>
>>
>>
>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>> Campbell Portfolio Architect @ =C2=A0 =C2=A0 =C2=A0 bcampbell@pingidentity.com
>> <mailto:bcampbell= @pingidentity.com> phone =C2=A0 =C2=A0+1 720.317.2061 Connect
>> with us. twitter logo <https://twitter.com/pingidentity> youtu= be logo
>> <https://www.youtube.com/user/PingIdentityTV= > LinkedIn logo
>> <https://www.linkedin.com/company/21870> Facebook logo
>> <https://www.facebook.com/pingidentitypage> Google+ logo<= br> >> <https://plus.google.com/u/0/114266977739397708540>= slideshare logo
>> <http://www.slideshare.net/PingIdentity> flipboard logo
>> <http://flip= .it/vjBF7> rss feed icon
>> <https://www.pingidentity.com/blogs/>
>>
>> Register for Cloud Identity Summit 2014 | Modern Identity Revoluti= on
>> | 19-23 July, 2014 | Monterey, CA
>> <https://www.cloudidentitysummi= t.com/>
>>
>>
>>
>>
>> _______________________________________________ jose mailing list<= br> >> jose@ietf.org https://www.ietf.= org/mailman/listinfo/jose
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTbQR6AAoJEDWi+S0W7cO14kgH/3RsEgO+jMpMOmHKLxB695iK
> DHO5wvJKXE/WI5WLlhEpK86TVcghdL7RJWxBXMw5Rz8+p27HLrr0mrBWw7PYBzCL
> 31fHFpd/OdsI8iaSnVeLXuG/fiPNBmPagYQ0iN/FMgVDI+Ra61dUT1Cq0yyFWFVj
> 1n1qzkjDhKhw9OkazcKWxp2fXvjhwaxtI/WrchBBPg5bJt0JA4MvlMhvoQHu5+gL
> d2Qox1TO0j3XltTkvtliorDku1aHCFfNaqLwvDxfu89H+ayvqMHTzgi274y9JmGi
> YvN1zzITnYkvpaeGC978sqLvg1j5Zh4VvO+3zquFeVJvu4801hrMyzzeSyeRpdc=3D
> =3D2XGV
> -----END PGP SIGNATURE-----

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



--
--089e01160752f90ba704f920d75f-- From nobody Wed May 14 11:19:43 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1A11A0178 for ; Wed, 14 May 2014 11:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Moke3BixYsPN for ; Wed, 14 May 2014 11:19:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id D9EC91A012F for ; Wed, 14 May 2014 11:19:34 -0700 (PDT) Received: from BY2PR03CA034.namprd03.prod.outlook.com (10.242.234.155) by BY2PR03MB255.namprd03.prod.outlook.com (10.242.37.22) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 18:19:26 +0000 Received: from BN1AFFO11FD053.protection.gbl (2a01:111:f400:7c10::124) by BY2PR03CA034.outlook.office365.com (2a01:111:e400:2c2c::27) with Microsoft SMTP Server (TLS) id 15.0.944.11 via Frontend Transport; Wed, 14 May 2014 18:19:25 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD053.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.0.939.9 via Frontend Transport; Wed, 14 May 2014 18:19:25 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.113]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0181.007; Wed, 14 May 2014 18:18:55 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JWT and JOSE have won a Special European Identity Award Thread-Index: Ac9voPf+mMeygFbPSlS6hXyIq5bS6A== Date: Wed, 14 May 2014 18:18:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD229C5@TK5EX14MBXC293.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.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD229C5TK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(51914003)(189002)(199002)(2656002)(87936001)(84326002)(54356999)(74662001)(76482001)(92726001)(19300405004)(21056001)(44976005)(19580395003)(86612001)(86362001)(46102001)(55846006)(77982001)(85852003)(97736001)(83072002)(4396001)(92566001)(20776003)(71186001)(80022001)(64706001)(15202345003)(6806004)(79102001)(19625215002)(81342001)(16297215004)(31966008)(68736004)(66066001)(74502001)(84676001)(81156002)(512954002)(26826002)(33656001)(81542001)(69596002)(50986999)(16236675002)(2009001)(83322001)(99396002)(15975445006)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB255; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0211965D06 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/KR2fcGHbX5CfnLjq9PWWV5bd-ig Subject: [jose] JWT and JOSE have won a Special European Identity Award X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 18:19:39 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD229C5TK5EX14MBXC293r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE= ) specifications were granted a Special European Identity Award for Best In= novation for Security in the API Economy. I was honored to accept the awar= d, along with Nat Sakimura and John Bradley, on behalf of the contributors = to and implementers of these specifications at the European Identity and Cl= oud Conference. It's great to see this recognition for the impact that these specs are havi= ng by making it easy to use simple JSON-based security tokens and other Web= -friendly cryptographically protected data structures. Special thanks are = due to all of you have built and deployed implementations and provided feed= back on the specs throughout their development; they significantly benefitt= ed from your active involvement! These specifications are: * JSON Web Token (JWT) * JSON Web Signature (JWS) * JSON Web Encryption (JWE) * JSON Web Key (JWK) * JSON Web Algorithms (JWA) The authors are: * John Bradley * Joe Hildebrand * Michael B. Jones * Nat Sakimura Dirk Balfanz, Yaron Goland, John Panzer, and Eric = Rescorla also deserve thanks for their significant co= ntributions to creating these specifications. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1223 and as= @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD229C5TK5EX14MBXC293r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Today the JSON Web Token (JWT) and JSON Object Signi= ng and Encryption (JOSE) specifications were granted a Special European Ide= ntity Award for Best Innovation for Security in the API Economy.  I wa= s honored to accept the award, along with Nat Sakimura and John Bradley, on behalf of the contributors to and implem= enters of these specifications at the European Identity and Cloud Conf= erence.

 

It’s great to see this recognition for the imp= act that these specs are having by making it easy to use simple JSON-based = security tokens and other Web-friendly cryptographically protected data str= uctures.  Special thanks are due to all of you have built and deployed implementations and provided feedback on th= e specs throughout their development; they significantly benefitted from yo= ur active involvement!

 

These specifications are:

·        JSON Web Token (JWT)

·        JSON Web Signature (JWS)

·        JSON Web Encryption (JWE)