From nobody Sun Mar 1 21:47:42 2015 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 4E6681A0AF8 for ; Sun, 1 Mar 2015 21:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH0YgZP8Z7L1 for ; Sun, 1 Mar 2015 21:47:39 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8240B1A07BE for ; Sun, 1 Mar 2015 21:47:39 -0800 (PST) Received: from Philemon (unknown [50.109.252.111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 0489E2C9EB; Sun, 1 Mar 2015 21:47:35 -0800 (PST) From: "Jim Schaad" To: Date: Sun, 1 Mar 2015 21:46:35 -0800 Message-ID: <04ed01d054ac$4419bd30$cc4d3790$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04EE_01D05469.35F82AE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBS2aGJ7H1FFkuwRSCUm0oRqFiJ6w== Content-Language: en-us Archived-At: Cc: jose@ietf.org Subject: [jose] draft-ietf-jose-jwk-thumbprint-03 Comments 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, 02 Mar 2015 05:47:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04EE_01D05469.35F82AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Couple more comments: 1. Think about expanding the abstract. Remember this is text that is expected to be read in isolation from the rest of the document. 2. You missed a couple of uses of "REQUIRED members" in the last edit pass. 3. This statement from section 4 "Use of escaped characters in the input JWK representation SHOULD be avoided. Does not agree with the statement from section 3.3 "Characters in member names and member values MUST be represented without being escaped." While I assume that the statement in section 4 is to apply to values, it does not say so. 4. Section 7 needs to be moved. It must come before the IANA considerations section. Given the content you might consider putting the text into the introduction. Jim ------=_NextPart_000_04EE_01D05469.35F82AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Couple = more comments:

 

1.       =  Think about expanding the abstract.  = Remember this is text that is expected to be read in isolation from the = rest of the document.

2.       You = missed a couple of uses of “REQUIRED members” in the last = edit pass.

3.       =
This =
statement from section 4
   “Use of escaped = characters in the input JWK representation SHOULD be avoided.
Does not = agree with the statement from section 3.3
    = “Characters in member names and member values MUST be represented = without being escaped.”
While I = assume that the statement in section 4 is to apply to values, it does = not say so.

4.       = Section 7 needs to be moved.  It must come = before the IANA considerations section.  Given the content you = might consider putting the text into the introduction.

 

Jim

 

------=_NextPart_000_04EE_01D05469.35F82AE0-- From nobody Sun Mar 1 21:50:56 2015 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 3FEEF1A0302 for ; Sun, 1 Mar 2015 21:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_4jcHg732da for ; Sun, 1 Mar 2015 21:50:53 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0E41A0029 for ; Sun, 1 Mar 2015 21:50:53 -0800 (PST) Received: from Philemon (unknown [50.109.252.111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 4A1A32C9F7 for ; Sun, 1 Mar 2015 21:50:52 -0800 (PST) From: "Jim Schaad" To: Date: Sun, 1 Mar 2015 21:49:57 -0800 Message-ID: <04f201d054ac$b80c5b30$28251190$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F3_01D05469.A9EA53B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBUrLRKCXeykxkCSp+WORV/D3QbUg== Content-Language: en-us Archived-At: Subject: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - Round 2 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, 02 Mar 2015 05:50:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F3_01D05469.A9EA53B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The chairs are issuing a one week working group last call on the document draft-ietf-jose-jwk-thumbprint to see where we stand. The chairs believe that the document has addressed all of the issues raised during the previous last call except for the question of changing the serialization format of the string to be hashed to compute the thumbprint value. The previous discussion on the serialization did not reach a consensus either to keep or change serialization string method. Given this the decision to keep the previous one is a conservative decision. If people want to re-litigate this issue and try to come to a consensus this is the time to do it. Starting the shepherd report raised the question of the correct track for this document. It is currently standards track. Given that it is only defining an algorithm, it might be reasonable to change it to informational. We would like to get peoples opinion this question. If there is no big mail storm, then I would expect that we will progress the document to the IESG after the last call finishes. Last call will finish on March 9th. Jim ------=_NextPart_000_04F3_01D05469.A9EA53B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = chairs are issuing a one week working group last call on the document = draft-ietf-jose-jwk-thumbprint to see where we stand.  The chairs = believe that the document has addressed all of the issues raised during = the previous last call except for the question of changing the = serialization format of the string to be hashed to compute the = thumbprint value.

 

The = previous discussion on the serialization did not reach a consensus = either to keep or change serialization string method.  Given this = the decision to keep the previous one is a conservative = decision.   If people want to re-litigate this issue and try = to come to a consensus this is the time to do it.

 

Starting the shepherd report raised the question of = the correct track for this document.  It is currently standards = track.  Given that it is only defining an algorithm, it might be = reasonable to change it to informational.  We would like to get = peoples opinion this question.

 

If = there is no big mail storm, then I would expect that we will progress = the document to the IESG after the last call finishes.

 

Last call = will finish on March 9th.

 

Jim

 

------=_NextPart_000_04F3_01D05469.A9EA53B0-- From nobody Sun Mar 1 22:50:22 2015 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 E70ED1A007D for ; Sun, 1 Mar 2015 22:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z0q4zpYm0Fv for ; Sun, 1 Mar 2015 22:50:19 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B961A1A30 for ; Sun, 1 Mar 2015 22:50:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8BDCCBED5; Mon, 2 Mar 2015 06:50:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dl4KXUimkkP; Mon, 2 Mar 2015 06:50:05 +0000 (GMT) Received: from [192.168.1.112] (147.red-80-28-131.adsl.static.ccgg.telefonica.net [80.28.131.147]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 58DD4BEA1; Mon, 2 Mar 2015 06:50:05 +0000 (GMT) Message-ID: <54F4081C.8000202@cs.tcd.ie> Date: Mon, 02 Mar 2015 06:50:04 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jim Schaad , jose@ietf.org References: <04f201d054ac$b80c5b30$28251190$@augustcellars.com> In-Reply-To: <04f201d054ac$b80c5b30$28251190$@augustcellars.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - Round 2 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, 02 Mar 2015 06:50:21 -0000 On 02/03/15 05:49, Jim Schaad wrote: > The previous discussion on the serialization did not reach a consensus > either to keep or change serialization string method. Given this the > decision to keep the previous one is a conservative decision. If people > want to re-litigate this issue and try to come to a consensus this is the > time to do it. Other hashed-public-key things all use SPKI as the input. Doing something different is IMO a bad plan for zero benefit. The benefit of doing the same as others is that one can use the same value to refer to the same key in different contexts. With the current approach, one cannot. S. From nobody Mon Mar 2 00:41:18 2015 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 9E61D1A6FF7 for ; Mon, 2 Mar 2015 00:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqG85sAbcian for ; Mon, 2 Mar 2015 00:41:16 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D0D1A6FF6 for ; Mon, 2 Mar 2015 00:41:15 -0800 (PST) Received: from Philemon (unknown [50.109.252.111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 5A6072C9BB; Mon, 2 Mar 2015 00:41:15 -0800 (PST) From: "Jim Schaad" To: "'Stephen Farrell'" , References: <04f201d054ac$b80c5b30$28251190$@augustcellars.com> <54F4081C.8000202@cs.tcd.ie> In-Reply-To: <54F4081C.8000202@cs.tcd.ie> Date: Mon, 2 Mar 2015 00:40:21 -0800 Message-ID: <050d01d054c4$85524930$8ff6db90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdh2vvSqBWApABxWhqI00dgmIxMAKW2kHPndnC+GA= Content-Language: en-us Archived-At: Subject: Re: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - Round 2 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, 02 Mar 2015 08:41:17 -0000 Going forward, the argument that SPKI is not easily obtainable is not = going to be a valid argument in browsers. The new WebCrypto API = supplies that need. So this is just an argument about current browsers = (well current IE) and non- browser platforms Jim > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Sunday, March 01, 2015 10:50 PM > To: Jim Schaad; jose@ietf.org > Subject: Re: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - = Round 2 >=20 >=20 >=20 > On 02/03/15 05:49, Jim Schaad wrote: > > The previous discussion on the serialization did not reach a = consensus > > either to keep or change serialization string method. Given this = the > > decision to keep the previous one is a conservative decision. If = people > > want to re-litigate this issue and try to come to a consensus this = is > > the time to do it. >=20 > Other hashed-public-key things all use SPKI as the input. Doing = something > different is IMO a bad plan for zero benefit. The benefit of doing the = same as > others is that one can use the same value to refer to the same key in > different contexts. With the current approach, one cannot. >=20 > S. From nobody Tue Mar 3 02:43:23 2015 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 810721A1B67 for ; Tue, 3 Mar 2015 02:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfz4MK9k2A-V for ; Tue, 3 Mar 2015 02:43:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0D71A1B53 for ; Tue, 3 Mar 2015 02:43:19 -0800 (PST) Received: from BN3PR0301CA0065.namprd03.prod.outlook.com (25.160.152.161) by DM2PR03MB334.namprd03.prod.outlook.com (10.141.54.19) with Microsoft SMTP Server (TLS) id 15.1.106.11; Tue, 3 Mar 2015 10:42:56 +0000 Received: from BY2FFO11FD029.protection.gbl (2a01:111:f400:7c0c::199) by BN3PR0301CA0065.outlook.office365.com (2a01:111:e400:401e::33) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Tue, 3 Mar 2015 10:42:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD029.mail.protection.outlook.com (10.1.14.212) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Tue, 3 Mar 2015 10:42:56 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0224.003; Tue, 3 Mar 2015 10:42:24 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Key Managed JSON Web Signature (KMJWS) specification Thread-Index: AdBVnrlYeSkbpnXYQGWf+2U9DVU+8w== Date: Tue, 3 Mar 2015 10:42:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2E74771TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; 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; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(209900001)(189002)(199003)(110136001)(33656002)(84326002)(50986999)(104016003)(107886001)(2351001)(229853001)(16236675004)(2930100002)(2656002)(16297215004)(86612001)(87936001)(86362001)(19580395003)(6806004)(85806002)(19625215002)(2920100001)(66066001)(46102003)(19617315012)(15975445007)(102836002)(92566002)(55846006)(106466001)(62966003)(2501003)(54356999)(2900100001)(19300405004)(450100001)(77156002)(512954002)(1720100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB334; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB334; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:DM2PR03MB334; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB334; X-Forefront-PRVS: 0504F29D72 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2015 10:42:56.1686 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB334 Archived-At: Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 03 Mar 2015 10:43:22 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2E74771TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I took a little time today and wrote a short draft specifying a JWS-like ob= ject that uses key management for the MAC key used to integrity protect the= payload. We had considered doing this in JOSE issue #2 but didn't do so at the time because of lac= k of demand. However, I wanted to get this down now to demonstrate that it= is easy to do and specify a way to do it, should demand develop in the fut= ure - possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones= -jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/dra= ft-jones-jose-key-managed-json-web-signature-00.html. This spec reuses key management functionality already present in the JWE sp= ec and MAC = functionality already present in the JWS spec. The result is essentially a JWS with an= Encrypted Key value added, and a new "mac" Header Parameter value represen= ting the MAC algorithm used. (Like JWE, the key management algorithm is ca= rried in the "alg" Header Parameter value.) I also wrote this now as possible input into our thinking on options for cr= eating a CBOR JOSE mapping. If there a= re CBOR use cases needing managed MAC keys, this could help us reason about= ways to structure the solution. Yes, the spec name and abbreviation are far from catchy. Better naming ide= as would be great. Feedback welcomed. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1344 and as= @selfissued. --_000_4E1F6AAD24975D4BA5B1680429673943A2E74771TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I took a little time today and wrote a short draft s= pecifying a JWS-like object that uses key management for the MAC key used t= o integrity protect the payload.  We had considered doing this in JOSE issue #2<= /a> but didn’t do so at the time because of lack of demand.  How= ever, I wanted to get this down now to demonstrate that it is easy to do an= d specify a way to do it, should demand develop in the future – possibly after the JOSE working group has been closed.  See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-= 00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signatur= e-00.html.

 

This spec reuses key management functionality alread= y present in the = JWE spec and MAC functionality already present in the J= WS spec.  The result is essentially a JWS with an Encrypted Key va= lue added, and a new “mac” Header Parameter value representing the MAC algorithm used.  (Like JWE, the key management algorithm is carri= ed in the “alg” Header Parameter value.)

 

I also wrote this now as possible input into our thi= nking on options for creating a CBOR JOSE mapping. = If there are CBOR use cases needing managed MAC keys, this could help us r= eason about ways to structure the solution.

 

Yes, the spec name and abbreviation are far from cat= chy.  Better naming ideas would be great.

 

Feedback welcomed.

 

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

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943A2E74771TK5EX14MBXC292r_-- From nobody Tue Mar 3 03:03:39 2015 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 A17E71A1A04 for ; Tue, 3 Mar 2015 03:03:38 -0800 (PST) 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 yQvGDBPPYd7O for ; Tue, 3 Mar 2015 03:03:37 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB8E1A03A0 for ; Tue, 3 Mar 2015 03:03:36 -0800 (PST) Received: by wgha1 with SMTP id a1so39201874wgh.12 for ; Tue, 03 Mar 2015 03:03:35 -0800 (PST) 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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yFZv+yD1mLQ4SerpWUtfJPISRmn3wjnKwicaSKlX6bY=; b=r7UWMd/5Lf+yDYP02Hclhc5B/C1In+Cq5OSsOg1Zw9TEbNhKYY8VZM/vbrQWSumzoF OiDW5aEnkPvm3v3pZAlYJp7XaQcKlQtzdlGwxxIy6mMwFklzSLcZCejgdHnkO+hLlPDv ABywu59n5l5cZoAFfBQ6YiBtxAbo7Jb3IGcPGqpcZCeFBeTi/rYhp/2d2ZrHaCo4BbKt 2CF4neykm/A3gkz/wrWKJPhWMCE6wpwGi6ahWxsR5ykUXoMFk6TajMy5aiiCnVYkaEQ5 Khcb/J/Oiu0r3Zm3CHMB1pOit8iJheXmf1KhBjRycbMZwyUrNGO2vJuYu5IbweDcRhiO EFgQ== X-Received: by 10.180.82.40 with SMTP id f8mr1729699wiy.60.1425380615419; Tue, 03 Mar 2015 03:03:35 -0800 (PST) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id n6sm823394wjy.8.2015.03.03.03.03.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 03:03:34 -0800 (PST) Message-ID: <54F594FB.6040809@gmail.com> Date: Tue, 03 Mar 2015 12:03:23 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mike Jones , "jose@ietf.org" References: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 03 Mar 2015 11:03:38 -0000 On 2015-03-03 11:42, Mike Jones wrote: > > I took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload. We had considered doing this in JOSE issue #2 but didn’t do so at the time because of lack of demand. However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future – possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html. > > This spec reuses key management functionality already present in the JWE spec and MAC functionality already present in the JWS spec . The result is essentially a JWS with an Encrypted Key value added, and a new “mac” Header Parameter value representing the MAC algorithm used. (Like JWE, the key management algorithm is carried in the “alg” Header Parameter value.) > I guess I'm stupid but I don't understand what this scheme brings to the table over what for example RSA signatures already provide. A short rationale for us imbeciles would be nice to have :-) Anders > I also wrote this now as possible input into our thinking on options for creating a CBOR JOSE mapping. If there are CBOR use cases needing managed MAC keys, this could help us reason about ways to structure the solution. > > Yes, the spec name and abbreviation are far from catchy. Better naming ideas would be great. > > Feedback welcomed. > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=1344 and as @selfissued. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Tue Mar 3 15:51:50 2015 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 3FB1D1A7011 for ; Tue, 3 Mar 2015 15:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpdYUn7GIrh4 for ; Tue, 3 Mar 2015 15:51:46 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46AB1A3BA2 for ; Tue, 3 Mar 2015 15:51:46 -0800 (PST) Received: by obcva2 with SMTP id va2so3408172obc.6 for ; Tue, 03 Mar 2015 15:51:46 -0800 (PST) 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; bh=QuUosMHFxFRwpwqtkJf/3xB9kwOuv6NH8H7ULnUqHt4=; b=JHE87Qu+p4+qvESWa8LPZQspaZXNVIgfTMlTBRSwdTDMnV6x/UUpC4C6YYdrmX6wEj HTa4FFdDk0iOJgpXFFkNw4EBH72cQnJtibyeJSnKjiuRSLNRLjk9A7LysPVOKx4xV5zS la26tBlghsOqzLl5XQBzyWjg4qGYnvXvzCWSsh0396T4FZf9qD9qmaF2wontMbI0/riL tkzwXwuLsj3AOGw3Lgl/TzhNQ3TDALIfx9Dob12iwtMSfGulexNu86pomc0oaCjOmWcT UoSQQL2diVzmxnYNWvTW0S+1tdxKgErcPsSe+Ke2eIZaa7x+BhDLuxStCWvTjDaSCU75 Hh4A== MIME-Version: 1.0 X-Received: by 10.202.180.87 with SMTP id d84mr1089063oif.0.1425426705856; Tue, 03 Mar 2015 15:51:45 -0800 (PST) Received: by 10.60.157.193 with HTTP; Tue, 3 Mar 2015 15:51:45 -0800 (PST) In-Reply-To: <54F4081C.8000202@cs.tcd.ie> References: <04f201d054ac$b80c5b30$28251190$@augustcellars.com> <54F4081C.8000202@cs.tcd.ie> Date: Wed, 4 Mar 2015 08:51:45 +0900 Message-ID: From: Nat Sakimura To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113cc7e074bfc605106b04f0 Archived-At: Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - Round 2 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, 03 Mar 2015 23:51:49 -0000 --001a113cc7e074bfc605106b04f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephen asks why JWK Thumbprint should do something other than hash a SPKI key representation. Here are a few reasons: 1. The whole premise of JOSE was to create easy to use crypto data formats and algorithms that are based on JSON. Saying =E2=80=9CSPKI exists =E2=80= =93 everyone should use it=E2=80=9D is like saying =E2=80=9CCMS exists =E2=80=93 everyon= e should use it, or perhaps XMLDSIG exists =E2=80=93 everyone should use it=E2=80=9D. It does = not seem consistent or helpful to developers for JOSE to effectively say =E2=80=9CYo= u can use JSON-based structures for everything except key hashes and for those, you have to use a binary structure (based on ASN.1).=E2=80=9D 2. The point of the draft is to create thumbprints of keys that are already represented in JWK format. Requiring a format conversion to ASN.1, which most developers consider to be unapproachable, will result both in more code and less adoption. (If the keys are already in X.509 certs, by all means, hash the SPKI value because it=E2=80=99s easy. JWK Thumbprint i= s similarly easy for JWK keys.) Stephen also states =E2=80=9CThe benefit of doing the same as others is tha= t one can use the same value to refer to the same key in different contexts=E2=80= =9D. That sounds great on the face of it, but it is not clear that there=E2=80= =99s much/any benefit to this in practice. A key is typically deployed for a particular application context or among applications running over a TLS connection. Key reuse across different applications contexts is arguably a security concern and not something likely to occur much in practice. Each application defines what key format it uses (X.509/SPKI, XML, JWK, etc.) and how to create key identifiers for those keys. Letting the application choose a JSON-based way to create key identifiers is both logical and good for adoption of usable crypto. I also took a look at some adoption data as background information. - Browser support for WebCrypto is still iffy. See http://caniuse.com/#feat=3Dcryptography. - Notably, all the Android Browsers before Android L (5.0) do not support WebCrypto, and there are tons of them out there. They will be there for years. - There are many enterprise deployments of IE below 10, which are not going to be upgraded anytime soon. - PHP started supporting SPKI in ver. 5.6, which was released Aug. 28, 2014. Its deployment is very small as you can expect - 0.7%. Server platforms do not do major version upgrades frequently. See http://w3techs.com/technologies/details/pl-php/5/all. - Python seems to have been supporting SPKI for sometime as a NetscapeSPKI object. - So does Ruby. - I am not sure if the same is true for Perl. A cursory search didn=E2=80= =99t turn up any useful data. In closing, the point of JOSE (and the point of the JWK Thumbprint spec) is to enable widespread adoption of usable crypto with the development tools people actually have NOW. That seems to be reason enough to have this draft progress now towards RFC status. Best, Nat 2015-03-02 15:50 GMT+09:00 Stephen Farrell : > > > On 02/03/15 05:49, Jim Schaad wrote: > > The previous discussion on the serialization did not reach a consensus > > either to keep or change serialization string method. Given this the > > decision to keep the previous one is a conservative decision. If peop= le > > want to re-litigate this issue and try to come to a consensus this is t= he > > time to do it. > > Other hashed-public-key things all use SPKI as the input. Doing > something different is IMO a bad plan for zero benefit. The benefit > of doing the same as others is that one can use the same value to > refer to the same key in different contexts. With the current > approach, one cannot. > > S. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113cc7e074bfc605106b04f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Stephen asks why JWK Thumbprint should do something other than hash a SPKI= key representation.=C2=A0 Here are a few reasons:


1.=C2=A0 The whole p= remise of JOSE was to create easy to use crypto data formats and algorithms= that are based on JSON.=C2=A0 Saying =E2=80=9CSPKI exists =E2=80=93 everyo= ne should use it=E2=80=9D is like saying =E2=80=9CCMS exists =E2=80=93 ever= yone should use it, or perhaps XMLDSIG exists =E2=80=93 everyone should use= it=E2=80=9D.=C2=A0 It does not seem consistent or helpful to developers fo= r JOSE to effectively say =E2=80=9CYou can use JSON-based structures for ev= erything except key hashes and for those, you have to use a binary structur= e (based on ASN.1).=E2=80=9D


2.=C2=A0 The point of the draft is to crea= te thumbprints of keys that are already represented in JWK format.=C2=A0 Re= quiring a format conversion to ASN.1, which most developers consider to be = unapproachable, will result both in more code and less adoption. =C2=A0(If = the keys are already in X.509 certs, by all means, hash the SPKI value beca= use it=E2=80=99s easy.=C2=A0 JWK Thumbprint is similarly easy for JWK keys.= )


Stephen also states =E2=80=9CThe benefit of doing the same as others = is that one can use the same value to refer to the same key in different co= ntexts=E2=80=9D.=C2=A0 That sounds great on the face of it, but it is not c= lear that there=E2=80=99s much/any benefit to this in practice.=C2=A0 A key= is typically deployed for a particular application context or among applic= ations running over a TLS connection.=C2=A0 Key reuse across different appl= ications contexts is arguably a security concern and not something likely t= o occur much in practice.


Each application defines what key format it u= ses (X.509/SPKI, XML, JWK, etc.) and how to create key identifiers for thos= e keys.=C2=A0 Letting the application choose a JSON-based way to create key= identifiers is both logical and good for adoption of usable crypto.=


I = also took a look at some adoption data as background information.

  • Notably, all the Android Browser= s before Android L (5.0) do not support WebCrypto, and there are tons of th= em out there.=C2=A0 They will be there for years.

  • There are many enterprise deployments of IE below 10, which are not go= ing to be upgraded anytime soon.

  • PHP started supporting SPKI in ver.= 5.6, which was released Aug. 28, 2014. Its deployment is very small as you= can expect - 0.7%.=C2=A0 Server platforms do not do major version upgrades= frequently.=C2=A0 See http://w3techs.com/technologies/details= /pl-php/5/all.

  • Pyth= on seems to have been supporting SPKI for sometime as a NetscapeSPKI object= .

  • So does Ruby.

  • I am not sure if the = same is true for Perl. A cursory search didn=E2=80=99t turn up any useful d= ata.


In closing, the point of JOSE (and the point of the JWK = Thumbprint spec) is to enable widespread adoption of usable crypto with the= development tools people actually have NOW.=C2=A0 That seems to be reason = enough to have this draft progress now towards RFC status.
Best,

Nat

2015-03-02 15:50 GMT+09:00 Stephen Farrell <steph= en.farrell@cs.tcd.ie>:


On 02/03/15 05:49, Jim Schaad wrote:
> The previous discussion on the serialization did not reach a consensus=
> either to keep or change serialization string method.=C2=A0 Given this= the
> decision to keep the previous one is a conservative decision.=C2=A0 = =C2=A0If people
> want to re-litigate this issue and try to come to a consensus this is = the
> time to do it.

Other hashed-public-key things all use SPKI as the input. Doing
something different is IMO a bad plan for zero benefit. The benefit
of doing the same as others is that one can use the same value to
refer to the same key in different contexts. With the current
approach, one cannot.

S.

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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--001a113cc7e074bfc605106b04f0-- From nobody Tue Mar 3 18:14:46 2015 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 CAAC31A88B0; Tue, 3 Mar 2015 18:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SSJeq0tEJ3yS; Tue, 3 Mar 2015 18:14:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF971A8ACD; Tue, 3 Mar 2015 18:14:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304021440.20625.89150.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 18:14:40 -0800 Archived-At: Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-jwk-thumbprint-04.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 02:14:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF. Title : JSON Web Key (JWK) Thumbprint Authors : Michael B. Jones Nat Sakimura Filename : draft-ietf-jose-jwk-thumbprint-04.txt Pages : 12 Date : 2015-03-03 Abstract: This specification defines a means of computing a thumbprint value (a.k.a. digest) of a key represented as a JSON Web Key (JWK). This value can be used for identifying or selecting the key that is the subject of the thumbprint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-jwk-thumbprint/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-jwk-thumbprint-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 3 18:19:34 2015 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 C868D1A8BAF for ; Tue, 3 Mar 2015 18:19:33 -0800 (PST) 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 rzsRf22rsF4T for ; Tue, 3 Mar 2015 18:19:32 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F3C1A8AF2 for ; Tue, 3 Mar 2015 18:19:31 -0800 (PST) Received: from BY2PR03CA012.namprd03.prod.outlook.com (10.255.93.29) by DM2PR03MB430.namprd03.prod.outlook.com (10.141.85.14) with Microsoft SMTP Server (TLS) id 15.1.93.12; Wed, 4 Mar 2015 02:19:30 +0000 Received: from BL2FFO11OLC004.protection.gbl (10.255.93.4) by BY2PR03CA012.outlook.office365.com (10.255.93.29) with Microsoft SMTP Server (TLS) id 15.1.99.14 via Frontend Transport; Wed, 4 Mar 2015 02:19:29 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11OLC004.mail.protection.outlook.com (10.173.161.188) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 4 Mar 2015 02:19:29 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0224.003; Wed, 4 Mar 2015 02:19:15 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JWK Thumbprint -04 draft incorporating feedback during second WGLC Thread-Index: AdBWIZvjSh9gKPFVQMGJ3MOzaUMR2Q== Date: Wed, 4 Mar 2015 02:19:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E76B43@TK5EX14MBXC292.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.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2E76B43TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; 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; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(209900001)(2501003)(66066001)(19625215002)(512954002)(107886001)(33656002)(2351001)(46102003)(55846006)(62966003)(50986999)(450100001)(1720100001)(54356999)(110136001)(229853001)(106466001)(77156002)(2920100001)(2930100002)(102836002)(15975445007)(2900100001)(86612001)(19300405004)(86362001)(104016003)(92566002)(16236675004)(16297215004)(19580395003)(84326002)(2656002)(85806002)(87936001)(6806004)(19617315012)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB430; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB430; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:DM2PR03MB430; X-Forefront-PRVS: 0505147DDB X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB430; X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2015 02:19:29.3675 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB430 Archived-At: Subject: [jose] JWK Thumbprint -04 draft incorporating feedback during second WGLC 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, 04 Mar 2015 02:19:33 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2E76B43TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The latest JWK Thumbprint draft addresses review comments on the -03 draft = by Jim Schaad, which resulted in several clarifications and some correction= s to the case of RFC 2119 keywords. The specification is available at: * http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-04 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-ietf-jose-jwk-thumbprint-04.ht= ml -- Nat and = Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1348 and = as @selfissued. --_000_4E1F6AAD24975D4BA5B1680429673943A2E76B43TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The latest JWK Thumbprint draft addresses review com= ments on the -03 draft by Jim Schaad, which resulted in several clarificati= ons and some corrections to the case of RFC 2119 keywords.

The specification is available at:

·         http://tools.ietf.org/html/draft-ietf-jose-jwk= -thumbprint-04

 

An HTML formatted version is also available at:=

·         http://self-issued.info/docs/draft-ietf= -jose-jwk-thumbprint-04.html

 

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

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943A2E76B43TK5EX14MBXC292r_-- From nobody Tue Mar 3 18:27:04 2015 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 4B89E1A1BEC for ; Tue, 3 Mar 2015 18:27:02 -0800 (PST) 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 Df5UTH0Gaxjj for ; Tue, 3 Mar 2015 18:26:59 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0C81A1EED for ; Tue, 3 Mar 2015 18:26:59 -0800 (PST) Received: from BY2PR03CA067.namprd03.prod.outlook.com (10.141.249.40) by BY1PR0301MB0872.namprd03.prod.outlook.com (25.160.194.142) with Microsoft SMTP Server (TLS) id 15.1.99.14; Wed, 4 Mar 2015 02:26:58 +0000 Received: from BY2FFO11FD038.protection.gbl (2a01:111:f400:7c0c::197) by BY2PR03CA067.outlook.office365.com (2a01:111:e400:2c5d::40) with Microsoft SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Wed, 4 Mar 2015 02:26:58 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 4 Mar 2015 02:26:57 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0224.003; Wed, 4 Mar 2015 02:26:24 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-jose-jwk-thumbprint@tools.ietf.org" Thread-Topic: [jose] draft-ietf-jose-jwk-thumbprint-03 Comments Thread-Index: AdBS2aGJ7H1FFkuwRSCUm0oRqFiJ6wDSBpJg Date: Wed, 4 Mar 2015 02:26:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E76BC2@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <04ed01d054ac$4419bd30$cc4d3790$@augustcellars.com> In-Reply-To: <04ed01d054ac$4419bd30$cc4d3790$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2E76BC2TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; 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; augustcellars.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(43784003)(199003)(377454003)(87936001)(512954002)(230783001)(19580395003)(6806004)(84326002)(19580405001)(62966003)(86362001)(46102003)(92566002)(77156002)(106466001)(2950100001)(2920100001)(33656002)(2900100001)(15975445007)(19300405004)(102836002)(66066001)(76176999)(50986999)(54356999)(104016003)(55846006)(85806002)(2656002)(16236675004)(19625215002)(2501003)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0872; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0872; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BY1PR0301MB0872; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0872; X-Forefront-PRVS: 0505147DDB X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2015 02:26:57.4912 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0872 Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-jwk-thumbprint-03 Comments 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, 04 Mar 2015 02:27:02 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2E76BC2TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These comments were addressed in the -04 draft. Replies are inline below. Thanks again for your consistent attention to detail! From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Sunday, March 01, 2015 9:47 PM To: draft-ietf-jose-jwk-thumbprint@tools.ietf.org Cc: jose@ietf.org Subject: [jose] draft-ietf-jose-jwk-thumbprint-03 Comments Couple more comments: 1. Think about expanding the abstract. Remember this is text that i= s expected to be read in isolation from the rest of the document. Done. It now also says that the value can be used for identifying or selec= ting the key. 2. You missed a couple of uses of "REQUIRED members" in the last edit= pass. Thanks. You prompted us to do a full RFC 2119 review. I think we got it a= ll, but let us know if we missed anything. 3. This statement from section 4 "Use of escaped characters in the input JWK representation SHOULD be avo= ided. Does not agree with the statement from section 3.3 "Characters in member names and member values MUST be represented witho= ut being escaped." While I assume that the statement in section 4 is to apply to values, it do= es not say so. This is now (hopefully) clarified through the following language: Use of escaped characters in JWKs for which JWK Thumbpr= ints will be computed should be avoided. (Use of escaped characters in the hash input JWKs deriv= ed from these original JWKs is prohibited.) 4. Section 7 needs to be moved. It must come before the IANA conside= rations section. Given the content you might consider putting the text int= o the introduction. It's now before the IANA considerations section. We thought about putting = it in the introduction, but it would triple the size of the introduction an= d delay getting to the meat of the specification. Jim Thanks agai= n, -- Nat & Mi= ke --_000_4E1F6AAD24975D4BA5B1680429673943A2E76BC2TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These comments were ad= dressed in the -04 draft.  Replies are inline below.=

 

Thanks again for your = consistent attention to detail!

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Sunday, March 01, 2015 9:47 PM
To: draft-ietf-jose-jwk-thumbprint@tools.ietf.org
Cc: jose@ietf.org
Subject: [jose] draft-ietf-jose-jwk-thumbprint-03 Comments

 

Couple more comments:

 

1.     &= nbsp;  Think about expanding the abstract.  Rem= ember this is text that is expected to be read in isolation from the rest o= f the document.

 

Done.  It now als= o says that the value can be used for identifying or selecting the key.

 

2.     &= nbsp; You missed a couple of uses of “REQUIRED memb= ers” in the last edit pass.

 

Thanks.  You prom= pted us to do a full RFC 2119 review.  I think we got it all, but let = us know if we missed anything.

 

=
3.    &nb=
sp;  This statement from s=
ection 4
   “Use of escaped characters in the inp= ut JWK representation SHOULD be avoided.
Does not agree wit= h the statement from section 3.3
    “Charac= ters in member names and member values MUST be represented without being es= caped.”
While I assume that the statement in section = 4 is to apply to values, it does not say so.
 
This is now (hopefully) clarified through t=
he following language:
 
       &=
nbsp;            Use=
 of escaped characters in JWKs for which JWK Thumbprints will be computed s=
hould be avoided.
       &=
nbsp;            (Us=
e of escaped characters in the hash input JWKs derived from these original =
JWKs is prohibited.)
 

4.     &= nbsp; Section 7 needs to be moved.  It must come bef= ore the IANA considerations section.  Given the content you might cons= ider putting the text into the introduction.

 

It’s now before = the IANA considerations section.  We thought about putting it in the i= ntroduction, but it would triple the size of the introduction and delay get= ting to the meat of the specification.

 

Jim

 

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

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Nat & Mike<= o:p>

 

--_000_4E1F6AAD24975D4BA5B1680429673943A2E76BC2TK5EX14MBXC292r_-- From nobody Wed Mar 4 00:08:15 2015 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 234751A0A85 for ; Wed, 4 Mar 2015 00:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjRc_TPLjuvM for ; Wed, 4 Mar 2015 00:08:11 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5CE1A06E9 for ; Wed, 4 Mar 2015 00:08:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 80DBBBEED; Wed, 4 Mar 2015 08:08:07 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avsBkHvlglah; Wed, 4 Mar 2015 08:08:07 +0000 (GMT) Received: from webmail.scss.tcd.ie (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21965BEDC; Wed, 4 Mar 2015 08:08:07 +0000 (GMT) Received: from 81.57.243.48 (SquirrelMail authenticated user sfarrel6) by webmail.scss.tcd.ie with HTTP; Wed, 4 Mar 2015 08:08:07 -0000 Message-ID: <22b90ca0ffd3bd18b95852838b380c98.squirrel@webmail.scss.tcd.ie> In-Reply-To: References: <04f201d054ac$b80c5b30$28251190$@augustcellars.com> <54F4081C.8000202@cs.tcd.ie> Date: Wed, 4 Mar 2015 08:08:07 -0000 From: stephen.farrell@cs.tcd.ie To: "Nat Sakimura" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Jim Schaad , "jose@ietf.org" , Stephen Farrell Subject: Re: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - Round 2 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, 04 Mar 2015 08:08:14 -0000 Hi Nat, Nat Sakimura wrote: > Stephen asks why JWK Thumbprint should do something other than hash a SPKI > key representation. Here are a few reasons: > > 1. The whole premise of JOSE was to create easy to use crypto data > formats > and algorithms that are based on JSON. Sorry, but that's bogus. SPKI is easy to use and simple on pretty much all web development platforms. Claiming that this is ASN.1 and therefore bad is just not a valid argument since there is no requirement for any decoding and there is no complex encoding at all. > Saying “SPKI exists – everyone > should use it” is like saying “CMS exists – everyone should use it, > or > perhaps XMLDSIG exists – everyone should use it”. It does not seem > consistent or helpful to developers for JOSE to effectively say “You can > use JSON-based structures for everything except key hashes and for those, > you have to use a binary structure (based on ASN.1).” > > 2. The point of the draft is to create thumbprints of keys that are > already represented in JWK format. Requiring a format conversion to > ASN.1, > which most developers consider to be unapproachable, Same bogus argument, sorry. Using ASN.1 as a scare tactic is just not credible here, once one looks at the facts. > will result both in > more code and less adoption. (If the keys are already in X.509 certs, by > all means, hash the SPKI value because it’s easy. JWK Thumbprint is > similarly easy for JWK keys.) Nonsense. SPKI is trivial to generate from any form of public key. > Stephen also states “The benefit of doing the same as others is that one > can use the same value to refer to the same key in different contexts”. > That sounds great on the face of it, but it is not clear that there’s > much/any benefit to this in practice. A key is typically deployed for a > particular application context or among applications running over a TLS > connection. Key reuse across different applications contexts is arguably > a > security concern and not something likely to occur much in practice. Please demonstrate such a concern. Vague arm-waving isn't useful. Using the same input bits for the same key would help e.g. to ensure weak keys like the old debian ones would be more easily spotted in signature applications, so there are security benefits to consistency here. (That's a modest, benefit for sure though.) > > Each application defines what key format it uses (X.509/SPKI, XML, JWK, > etc.) and how to create key identifiers for those keys. Letting the > application choose a JSON-based way to create key identifiers is both > logical and good for adoption of usable crypto. > > I also took a look at some adoption data as background information. > > > - > > Browser support for WebCrypto is still iffy. See > http://caniuse.com/#feat=cryptography. WebCrypto makes SPKI access the obvious thing to do. Other platforms require a line of code or so to create the SPKI bits as a hash input, and that's true in JS or any other dev environment I've used. > > > - > > Notably, all the Android Browsers before Android L (5.0) do not support > WebCrypto, and there are tons of them out there. They will be there > for > years. > - > > There are many enterprise deployments of IE below 10, which are not > going to be upgraded anytime soon. > > > - > > PHP started supporting SPKI in ver. 5.6, which was released Aug. 28, > 2014. Its deployment is very small as you can expect - 0.7%. Server > platforms do not do major version upgrades frequently. See > http://w3techs.com/technologies/details/pl-php/5/all. > - > > Python seems to have been supporting SPKI for sometime as a > NetscapeSPKI > object. > - > > So does Ruby. > > > - > > I am not sure if the same is true for Perl. A cursory search didn’t > turn > up any useful data. And precisely zero of all of the above support the current draft's approach. > > > In closing, the point of JOSE (and the point of the JWK Thumbprint spec) > is > to enable widespread adoption of usable crypto with the development tools > people actually have NOW. That seems to be reason enough to have this > draft progress now towards RFC status. You have IMO only used bogus ASN.1-is-bad arguments to back up your usability claim. I don't really feel that strongly about the WG doing the wrong thing here (i.e. wrong-thing==current I-D) but we should decide based on valid arguments. S. PS: In case it's not clear - this is all me arguing as an individual and nothing to do with IESG evaluation of the draft when it gets there. > > Best, > > Nat > > 2015-03-02 15:50 GMT+09:00 Stephen Farrell : > >> >> >> On 02/03/15 05:49, Jim Schaad wrote: >> > The previous discussion on the serialization did not reach a consensus >> > either to keep or change serialization string method. Given this the >> > decision to keep the previous one is a conservative decision. If >> people >> > want to re-litigate this issue and try to come to a consensus this is >> the >> > time to do it. >> >> Other hashed-public-key things all use SPKI as the input. Doing >> something different is IMO a bad plan for zero benefit. The benefit >> of doing the same as others is that one can use the same value to >> refer to the same key in different contexts. With the current >> approach, one cannot. >> >> S. >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > From nobody Thu Mar 5 03:58:53 2015 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 4D8C61B29B8 for ; Thu, 5 Mar 2015 03:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8dmn5fiQbRj for ; Thu, 5 Mar 2015 03:58:50 -0800 (PST) Received: from lvs-smtpgate3.nz.fh-koeln.de (lvs-smtpgate3.nz.fh-koeln.de [139.6.1.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3734C1A1B4C for ; Thu, 5 Mar 2015 03:58:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.11,346,1422918000"; d="asc'?scan'208";a="18860659" Received: from aftr-37-201-195-74.unity-media.net (HELO mac-01.local) ([37.201.195.74]) by smtp.intranet.fh-koeln.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Mar 2015 12:58:48 +0100 Message-ID: <54F8466B.8060007@fh-koeln.de> Date: Thu, 05 Mar 2015 13:04:59 +0100 From: "Prof. Dr.-Ing. Luigi Lo Iacono" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "jose@ietf.org" Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9MV0N2Hp2OFOWa3SbKxCPsOS0QHpIDWfN" Archived-At: Subject: [jose] Java-based JOSE implementation X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: luigi.lo_iacono@fh-koeln.de List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:58:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9MV0N2Hp2OFOWa3SbKxCPsOS0QHpIDWfN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, we developed an own JOSE implementation in Java, mainly because we missed the JSON serialisation in almost all of the available libs. You can grasp it here: http://jw-asterisk.realsoasecurity.de/ We are still doing some polishing, that is why the sources are still lacking. Stay tuned, though, updates will follow soon... The documentation and especially the unit tests should help in taking the first steps. Let us know what you think about it... BR, Luigi. --9MV0N2Hp2OFOWa3SbKxCPsOS0QHpIDWfN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU+EZwAAoJEFL6uArWI9sNKt0QAIAl656mm2OgMAj6YJaTuGzq A4CzQQRJtrdYUJG6SFoPbh+ums6XlgE7mGG/u+zbBEiboQw3QUNpjj4vNvtMucyh lPvhzl/rv65YqDai1ugXw27GVaLdiIezL7nEail2MYCo8xlBf0E9Xp9S6/D+77an sLymyqfQNrde0hci1nrVNGD7iTff7MvUHlKj3a45RemvuyXUECHqHtjJ5XA3reDP tWnhFrnHmi1mdKVr8nJ0QdeBXXc8aJmV5Jufa2T0RsLCSq8bg6K3zw6hpfyvXpJN gG91a5DErT/F2eDeHrLE+E63/LKH/dipezQ7+4Jl00b06rMu3I/ltBlnHYO8LDPB pOFWc0F0n0Z0iZdRW35/kh3h09vk1cZS/BFAZ6ts5k8ZlS3lF8worOz75GhQi+5i 3ts7O9gbpJdPmjOYRgf1KwROLcNRXBti6IDbgP1fycYJpJqn8kxLHpce6g7y3uqX Y5DzhcAR3GKZ+PfPqxcHbafZ1upjpuv74jzADROPtqVmTfkP5kg0p5v2pm9hu7Ct 14taY9qIoG0Xgbtu8Pn2WVJMi5iUGWLhSvkKHmeAdh4zOTjxaNgDPIDwVXIm+GaG N/cjH5UgRJiwvtP+a6PgMzNj1VoZUsvkwpco1IPihfy3dpT4lxlQUn87yZevqlE7 AaIcLBRSTqzOn2JOb0JM =Tt8l -----END PGP SIGNATURE----- --9MV0N2Hp2OFOWa3SbKxCPsOS0QHpIDWfN-- From nobody Fri Mar 6 11:19:32 2015 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 DC97B1A1BD9 for ; Fri, 6 Mar 2015 11:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZfZpyAbaiW9j for ; Fri, 6 Mar 2015 11:19:26 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0F71A1BCC for ; Fri, 6 Mar 2015 11:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2908; q=dns/txt; s=iport; t=1425669566; x=1426879166; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=H5WbA8oEqx/1XbWHMmBoxMLNoWMwFK2091cllPWJOeY=; b=VjXMdyQrP+l12S+IQdTaTfMKHOPQ/FHER/BA1fdT8+stZ4gQXiU7qQgi h/soHG8aU/ss5uDDaWJP0TYZ35lXwNrCFmJLG1UOhRKsM2Y/0oZ52SPeI wu1b+2yXnRGz331+CThrlbC3QOCwP9fipA44ICDsfqbApQJTKUme2+BMg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DnDQAF/flU/49dJa1cgwaBMIMGuGqDSIhEgR5NAQEBAQEBfIQWIxFXASICJgIEMBUSBIhCo3qPSJo+AQEBAQYBAQEBAQEcgSGOFoM9L4EUBYV4ig+JTYp6iHUjg26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,354,1422921600"; d="scan'208";a="401531908" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 06 Mar 2015 19:19:25 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t26JJPVI004044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Mar 2015 19:19:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 13:19:25 -0600 From: "Joe Hildebrand (jhildebr)" To: "jose@ietf.org" Thread-Topic: COSE: what would change? Thread-Index: AQHQWEJ1QLnkI9RDkEaFuLpGIA6Fwg== Date: Fri, 6 Mar 2015 19:19:25 +0000 Message-ID: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [jose] COSE: what would change? 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, 06 Mar 2015 19:19:31 -0000 SW4gdGFsa2luZyB3aXRoIHNldmVyYWwgZm9sa3MgYWJvdXQgQ09TRSwgaXQgYXBwZWFycyB0aGF0 IHRoZXJlIGFyZSBkaWZmZXJpbmcgdmlld3Mgb24gaG93IG11Y2ggdG8gY2hhbmdlIGluIHRoZSBK T1NFL0NPU0UgdHJhbnNsYXRpb24uICBJIHdvdWxkIGxpa2UgdG8gZXhwbG9yZSB0aGUgcG9pbnRz IG9mIGFncmVlbWVudCBhbmQgZGlzYWdyZWVtZW50IGEgbGl0dGxlLg0KIA0KDQpJdCBzZWVtcyBs aWtlIG1vc3QgcGVvcGxlIGFncmVlIHRoYXQgbWFpbnRhaW5pbmcgc2lnbmF0dXJlIGNvbXBhdGli aWxpdHkgaXMgYSBub24tZ29hbDsgSSBhZ3JlZSB0aGF0IGlzIHRoZSBvbmx5IHdheSBmb3IgdXMg dG8gaGF2ZSBhIGNoYW5jZSBhdCBzdWNjZXNzLg0KDQogDQpJIHRoaW5rIHdlJ3JlIGFsc28gbGlr ZWx5IHRvIGdldCBhZ3JlZW1lbnQgdGhhdCB3ZSBzaG91bGQgZG8gb3VyIGJlc3QgdG8gdXNlIENC T1IgaWRpb21zIGluIENPU0UgKHN1Y2ggYXMgbWl4ZWQtdHlwZSBrZXlzIGZvciBtYXBzKSBvbmNl IHRoZXkgYXJlIGV4cGxhaW5lZCB0byB0aGUgZ3JvdXAgaW4gZW5vdWdoIGRldGFpbCBmb3IgZXZl cnlvbmUgdG8gdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWxzLg0KDQpGaW5hbGx5LCBJIHRoaW5rIG9u ZSBvZiB0aGUgcmVhc29ucyBwZW9wbGUgYXJlIGludGVyZXN0ZWQgaW4gQ09TRSBpcyBhIGNoYW5j ZSB0byBvcHRpbWl6ZSBmb3IgYSBkaWZmZXJlbnQgc2V0IG9mIHVzZSBjYXNlcyB0aGFuIHdlIGhh ZCBmb3IgSk9TRS4NCg0KIA0KVGhlIG1haW4gc291cmNlIG9mIGRpc2FncmVlbWVudCBzZWVtcyB0 byBiZSB3aGF0IHdlIHdvdWxkIGNoYW5nZSBpbiBDT1NFIG9mIHRoZSB0aGluZ3Mgc29tZSBtaWdo dCBoYXZlIHdhbnRlZCB0byBkb25lIGRpZmZlcmVudGx5IGluIEpPU0UuICBJJ20gc3ltcGF0aGV0 aWMgdG8gYm90aCB0aGUgZ3JvdXAgdGhhdCB3YW50cyB0byBjcmFuayBzb21ldGhpbmcgb3V0IHF1 aWNrbHkgd2l0aG91dCByZS1saXRpZ2F0aW5nIHRoZSBwYXN0LCBhcyB3ZWxsIGFzIHRvIHRoZSBn cm91cCB0aGF0IHdhbnRzIHRvIHJlLW9wdGltaXplIGFzIG1hbnkgdGhpbmdzIGFzIHBvc3NpYmxl IGdpdmVuIHRoZSByZW1vdmFsIG9mIHRoZSBwcmVzc3VyZSBvZiBleGlzdGluZyBjb2RlYmFzZXMg dGhhdCB3ZSBoYWQgd2l0aCBKT1NFLg0KDQogDQpBbiBhcHByb2FjaCB0aGF0IG1pZ2h0IHdvcmsg Zm9yIHRoaXMgd291bGQgYmUgdG8gc2V0IGEgYmFyIGZvciBjaGFuZ2VzIGFsb25nIHRoZSBsaW5l cyBvZiAic2lnbmlmaWNhbnQgaW1wcm92ZW1lbnQgaW4gc2VjdXJpdHksIHBlcmZvcm1hbmNlICh3 aXJlIHNpemUsIGNvZGUgc2l6ZSwgQ1BVLCBwb3dlciwgZXRjLiksIG9yIGRlcGxveWFiaWxpdHki IHdvdWxkIGJlIHJlcXVpcmVkIHRvIGp1c3RpZnkgYSBjaGFuZ2UuICBUbyBzZWUgaWYgdGhhdCBh cHByb2FjaCB3b3VsZCB3b3JrLCBpdCB3b3VsZCBiZSBuaWNlIHRvIHNlZSBhIGxpc3Qgb2YgdGhp bmdzIHRoYXQgZm9sa3Mgd291bGQgd2FudCB0byBjaGFuZ2UsIGFuZCB0byBnZXQgZWFybHkgYWdy ZWVtZW50IG9uIGEgY291cGxlIG9mIHRob3NlIGNoYW5nZXMgYXMgYmVpbmcgYWJvdmUgdGhlIGJh ciB0aGF0IHdlIHNldCwgc28gdGhhdCB3ZSBoYXZlIHNvbWUgcHJlY2VkZW50IHRvIHJlYXNvbiBm cm9tLiANCg0KIA0KVG8gdGhhdCBlbmQsIEkgcHJvcG9zZSB0aGF0IHRob3NlIHRoYXQgd2FudCBj aGFuZ2VzIHByb2R1Y2UgYSBsaXN0LCBwZXJoYXBzIGFubm90YXRlZCB3aXRoIHdoZXRoZXIgdGhl IGNoYW5nZSBpcyBzZWVuIGFzIGltcGVyYXRpdmUgb3IgbWVyZWx5IG5pY2UtdG8taGF2ZS4gIFRo ZSBmb2xrcyB0aGF0IHdhbnQgYSBxdWljayBvdXRjb21lIHdvdWxkIHRoZW4gc2VsZWN0IHNldmVy YWwgY2hhbmdlcyB0aGV5IHNlZSBhcyBiZWluZyBkZWZpbml0ZWx5IGFib3ZlIHRoZSBsaW5lLiAg TXkgaG9wZSBpcyB0aGF0IHRoaXMgZXhlcmNpc2Ugd291bGQgYnVpbGQgdHJ1c3QgdGhhdCB3ZSBh bGwgd2FudCBzb21ldGhpbmcgc2ltaWxhcjogYSBoaWdoIHF1YWxpdHkgcHJvdG9jb2wgc3RhbmRh cmRpemVkIGluIGFzIHNob3J0IGEgdGltZSBhcyBwb3NzaWJsZS4NCg0KDQotLSANCkpvZSBIaWxk ZWJyYW5kDQoNCg0KDQo= From nobody Fri Mar 6 11:46:10 2015 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 25E831A6F33 for ; Fri, 6 Mar 2015 11:46:10 -0800 (PST) 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 vuV-xGufn1E7 for ; Fri, 6 Mar 2015 11:46:08 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96EC1A6EED for ; Fri, 6 Mar 2015 11:46:07 -0800 (PST) Received: from CH1PR03CA004.namprd03.prod.outlook.com (10.255.156.149) by BY2PR03MB608.namprd03.prod.outlook.com (10.255.93.39) with Microsoft SMTP Server (TLS) id 15.1.99.14; Fri, 6 Mar 2015 19:46:05 +0000 Received: from BL2FFO11OLC004.protection.gbl (10.255.156.132) by CH1PR03CA004.outlook.office365.com (10.255.156.149) with Microsoft SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Fri, 6 Mar 2015 19:46:05 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11OLC004.mail.protection.outlook.com (10.173.161.188) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Fri, 6 Mar 2015 19:46:04 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.148]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0224.002; Fri, 6 Mar 2015 19:43:31 +0000 From: Mike Jones To: "Joe Hildebrand (jhildebr)" , "jose@ietf.org" Thread-Topic: COSE: what would change? Thread-Index: AQHQWEJ1QLnkI9RDkEaFuLpGIA6Fwp0P2fEQ Date: Fri, 6 Mar 2015 19:43:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E82259@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> In-Reply-To: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; 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; cisco.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(438002)(52314003)(52604005)(13464003)(51444003)(189002)(377454003)(199003)(2501003)(19580405001)(104016003)(86362001)(55846006)(62966003)(97756001)(46406003)(50466002)(86612001)(85806002)(77156002)(33656002)(76176999)(107886001)(15975445007)(54356999)(102836002)(50986999)(106466001)(19580395003)(2920100001)(46102003)(2950100001)(23726002)(2656002)(87936001)(106116001)(92566002)(561944003)(2900100001)(47776003)(6806004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB608; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB608; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BY2PR03MB608; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB608; X-Forefront-PRVS: 05079D8470 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2015 19:46:04.5805 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]; Helo=[mail.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB608 Archived-At: Subject: Re: [jose] COSE: what would change? 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, 06 Mar 2015 19:46:10 -0000 Thanks for writing this, Joe. I know that people from the IoT and other co= mmunities are already itching for a CBOR JOSE encoding and we'll do everyon= e a service by providing one in a timely fashion. I think your proposal to set a high, well-understood and agreed upon bar fo= r any changes to the decisions made in JOSE is the key to having this compl= ete in a reasonable period of time. In my view, if we open most decisions = to be re-debated, our timeline is far more likely to look like the JOSE tim= eline (in which we had the WOES BoF in July 2011 and are only nearing havin= g RFCs now over 3.5 years later) than the quick turnaround achievable by bu= ilding on past work that I think we would all like. Getting down to specifics, looking at the two COSE submissions to date, htt= ps://tools.ietf.org/html/draft-bormann-jose-cose-00 and http://tools.ietf.o= rg/html/draft-schaad-cose-00, I think Carsten's submission is more effectiv= e at leveraging our existing decisions than Jim's does so I'd personally wa= nt to use that as a starting point, but there are some things I find valuab= le in Jim's draft as well. For instance, I think that we should consider u= sing arrays rather than maps at the top level, as Jim suggests, as it may k= eep the code simpler and the representations more compact. I'll note that = this is actually parallel to the JOSE Compact Serializations, which used da= ta structures with fixed numbers of elements in fixed positions at the top = level, rather than JSON objects, as was done in the JSON Serializations. I'll also add that I personally think we should only define one serializati= on for the CBOR encoding. I would justify this departure from JOSE as bein= g in the name of "keeping simple things simple" - something I think should = also be part of our criteria when making our decisions. (If people do need= a URL-safe representation of a COSE object, it would be fine for them to b= ase64url encode the whole thing, for transmission purposes - a suggestion t= hat Joe made to me in person in Honolulu.) Anyway, I'm glad to see this discussion and look forward to us hopefully co= mpleting a COSE standard within a year from now! -- Mike -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Joe Hildebrand (jhil= debr) Sent: Friday, March 06, 2015 11:19 AM To: jose@ietf.org Subject: [jose] COSE: what would change? In talking with several folks about COSE, it appears that there are differi= ng views on how much to change in the JOSE/COSE translation. I would like = to explore the points of agreement and disagreement a little. =20 It seems like most people agree that maintaining signature compatibility is= a non-goal; I agree that is the only way for us to have a chance at succes= s. =20 I think we're also likely to get agreement that we should do our best to us= e CBOR idioms in COSE (such as mixed-type keys for maps) once they are expl= ained to the group in enough detail for everyone to understand the proposal= s. Finally, I think one of the reasons people are interested in COSE is a chan= ce to optimize for a different set of use cases than we had for JOSE. =20 The main source of disagreement seems to be what we would change in COSE of= the things some might have wanted to done differently in JOSE. I'm sympat= hetic to both the group that wants to crank something out quickly without r= e-litigating the past, as well as to the group that wants to re-optimize as= many things as possible given the removal of the pressure of existing code= bases that we had with JOSE. =20 An approach that might work for this would be to set a bar for changes alon= g the lines of "significant improvement in security, performance (wire size= , code size, CPU, power, etc.), or deployability" would be required to just= ify a change. To see if that approach would work, it would be nice to see = a list of things that folks would want to change, and to get early agreemen= t on a couple of those changes as being above the bar that we set, so that = we have some precedent to reason from.=20 =20 To that end, I propose that those that want changes produce a list, perhaps= annotated with whether the change is seen as imperative or merely nice-to-= have. The folks that want a quick outcome would then select several change= s they see as being definitely above the line. My hope is that this exerci= se would build trust that we all want something similar: a high quality pro= tocol standardized in as short a time as possible. --=20 Joe Hildebrand _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Tue Mar 10 02:15:06 2015 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 CE50A1A8033 for ; Tue, 10 Mar 2015 02:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II3eXmJEj8PW for ; Tue, 10 Mar 2015 02:15:01 -0700 (PDT) Received: from p3plsmtpa08-10.prod.phx3.secureserver.net (p3plsmtpa08-10.prod.phx3.secureserver.net [173.201.193.111]) by ietfa.amsl.com (Postfix) with ESMTP id 45BBF1A8025 for ; Tue, 10 Mar 2015 02:15:01 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.115]) by p3plsmtpa08-10.prod.phx3.secureserver.net with id 1lEz1q0032Vi9sD01lF06d; Tue, 10 Mar 2015 02:15:00 -0700 Message-ID: <54FEB612.7030707@connect2id.com> Date: Tue, 10 Mar 2015 11:14:58 +0200 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: jose@ietf.org References: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> <4E1F6AAD24975D4BA5B1680429673943A2E82259@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E82259@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] COSE: what would change? 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, 10 Mar 2015 09:15:04 -0000 Arrays would be good. Perhaps even bit fields? We recently had a use case where we had to constrain the size of JWTs and we successfully compressed an array of various constant claims into a base64 encoded bit field, giving us significant space saving. Vladimir On 6.03.2015 21:43, Mike Jones wrote: > Thanks for writing this, Joe. I know that people from the IoT and other communities are already itching for a CBOR JOSE encoding and we'll do everyone a service by providing one in a timely fashion. > > I think your proposal to set a high, well-understood and agreed upon bar for any changes to the decisions made in JOSE is the key to having this complete in a reasonable period of time. In my view, if we open most decisions to be re-debated, our timeline is far more likely to look like the JOSE timeline (in which we had the WOES BoF in July 2011 and are only nearing having RFCs now over 3.5 years later) than the quick turnaround achievable by building on past work that I think we would all like. > > Getting down to specifics, looking at the two COSE submissions to date, https://tools.ietf.org/html/draft-bormann-jose-cose-00 and http://tools.ietf.org/html/draft-schaad-cose-00, I think Carsten's submission is more effective at leveraging our existing decisions than Jim's does so I'd personally want to use that as a starting point, but there are some things I find valuable in Jim's draft as well. For instance, I think that we should consider using arrays rather than maps at the top level, as Jim suggests, as it may keep the code simpler and the representations more compact. I'll note that this is actually parallel to the JOSE Compact Serializations, which used data structures with fixed numbers of elements in fixed positions at the top level, rather than JSON objects, as was done in the JSON Serializations. > > I'll also add that I personally think we should only define one serialization for the CBOR encoding. I would justify this departure from JOSE as being in the name of "keeping simple things simple" - something I think should also be part of our criteria when making our decisions. (If people do need a URL-safe representation of a COSE object, it would be fine for them to base64url encode the whole thing, for transmission purposes - a suggestion that Joe made to me in person in Honolulu.) > > Anyway, I'm glad to see this discussion and look forward to us hopefully completing a COSE standard within a year from now! > > -- Mike > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Joe Hildebrand (jhildebr) > Sent: Friday, March 06, 2015 11:19 AM > To: jose@ietf.org > Subject: [jose] COSE: what would change? > > In talking with several folks about COSE, it appears that there are differing views on how much to change in the JOSE/COSE translation. I would like to explore the points of agreement and disagreement a little. > > > It seems like most people agree that maintaining signature compatibility is a non-goal; I agree that is the only way for us to have a chance at success. > > > I think we're also likely to get agreement that we should do our best to use CBOR idioms in COSE (such as mixed-type keys for maps) once they are explained to the group in enough detail for everyone to understand the proposals. > > Finally, I think one of the reasons people are interested in COSE is a chance to optimize for a different set of use cases than we had for JOSE. > > > The main source of disagreement seems to be what we would change in COSE of the things some might have wanted to done differently in JOSE. I'm sympathetic to both the group that wants to crank something out quickly without re-litigating the past, as well as to the group that wants to re-optimize as many things as possible given the removal of the pressure of existing codebases that we had with JOSE. > > > An approach that might work for this would be to set a bar for changes along the lines of "significant improvement in security, performance (wire size, code size, CPU, power, etc.), or deployability" would be required to justify a change. To see if that approach would work, it would be nice to see a list of things that folks would want to change, and to get early agreement on a couple of those changes as being above the bar that we set, so that we have some precedent to reason from. > > > To that end, I propose that those that want changes produce a list, perhaps annotated with whether the change is seen as imperative or merely nice-to-have. The folks that want a quick outcome would then select several changes they see as being definitely above the line. My hope is that this exercise would build trust that we all want something similar: a high quality protocol standardized in as short a time as possible. > > -- Vladimir Dzhuvinov :: vladimir@connect2id.com From nobody Tue Mar 10 22:17:34 2015 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 828391A0121 for ; Tue, 10 Mar 2015 22:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCBksi4sLena for ; Tue, 10 Mar 2015 22:17:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EBC1A02BE for ; Tue, 10 Mar 2015 22:17:27 -0700 (PDT) Received: from CH1PR03CA004.namprd03.prod.outlook.com (10.255.156.149) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.1.99.9; Wed, 11 Mar 2015 05:17:06 +0000 Received: from BN1BFFO11FD046.protection.gbl (10.255.156.132) by CH1PR03CA004.outlook.office365.com (10.255.156.149) with Microsoft SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Wed, 11 Mar 2015 05:17:06 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD046.mail.protection.outlook.com (10.58.145.1) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Wed, 11 Mar 2015 05:17:06 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.148]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0224.003; Wed, 11 Mar 2015 05:16:58 +0000 From: Mike Jones To: Stephen Farrell Thread-Topic: My quest to learn how to create SubjectPublicKeyInfo values from scratch Thread-Index: AdBbunvjG3Fobl38T+ib6QLqsv0XzA== Date: Wed, 11 Mar 2015 05:16:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/mixed; boundary="_005_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; 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; cs.tcd.ie; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(438002)(189002)(199003)(66066001)(102836002)(2930100002)(19617315012)(86612001)(6806004)(86362001)(54356999)(99936001)(19580395003)(50986999)(77156002)(46102003)(15975445007)(2900100001)(104016003)(84326002)(4610100001)(62966003)(5260100001)(4810100001)(5890100001)(19625215002)(33656002)(16236675004)(15395725005)(87936001)(110136001)(229853001)(2656002)(2920100001)(512954002)(568964001)(85806002)(16297215004)(3380100001)(575784001)(19300405004)(19273905006)(55846006)(92566002)(106466001)(16503001)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB078; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB078; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001009)(5005006); SRVR:SN2PR03MB078; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB078; X-Forefront-PRVS: 0512CC5201 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2015 05:17:06.1118 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]; Helo=[mail.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB078 Archived-At: Cc: "jose@ietf.org" , Nat Sakimura Subject: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 05:17:33 -0000 --_005_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_" --_000_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've always loved learning new things, so I decided yesterday to try to lea= rn first-hand how to write code that emitted X.509 SubjectPublicKeyInfo (SP= KI) values from scratch. By "from scratch", I mean using development tools= without built-in X.509 or ASN.1 support. I took this on because of Stephen's suggestion http://www.ietf.org/mail-arc= hive/web/jose/current/msg04954.html that people could just hash the SPKI va= lues to create a key thumbprint. Given I'd helped create the JSON-based ha= sh input described in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbp= rint-03, I wanted to give his alternative suggestion a fair shake (and lear= n some new things along the way). This admittedly stream-of-consciousness = and overly long message describes my expedition to date... Thus far, I've spent 5 hours trying to learn to do this. I spent about the= first two hours searching for examples of creating the bytes of X.509 cert= ificates or SubjectPublicKeyInfo values without using ASN.1 and/or X.509 li= braries. I failed. Next, I tried to read the authoritative reference for what's in the SPKI fi= eld - the X.509 spec. Unfortunately, http://www.itu.int/rec/T-REC-X.509/en= told me "This text was produced through a joint activity with ISO and IEC.= According to the agreement with our partners, this document is only availa= ble through payment." Since most developers would stop at that point, I di= d too. After that, I changed tacks and tried to find examples of sample certificat= es with commentary on what all the values mean - the kind of info developer= s would want when coding this. I had better luck with that. After about a= nother hour of Web searching, I found this really useful example: http://to= ols.ietf.org/html/rfc7250#appendix-A. I also found this one: http://www.je= nsign.com/JavaScience/dotnet/JKeyNet/index.html. Going through them byte-b= y-byte enabled me to reverse engineer some of the ASN.1 and X.509 construct= s used. Things I learned by looking at these 1024-bit RSA public key representation= s included: * ASN.1 uses byte-aligned Tag-Length-Value encodings. * The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER are resp= ectively 0x30, 0x06, 0x05, 0x03, and 0x02. * These Length values are encoded as follows: o 159 - 0x81 0x9f o 9 - 0x09 o 0 - 0x00 * The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 0x= 48 0x86 0xf7 0x0d 0x01 0x01 0x01. * The OID is followed by an ASN.1 NULL - 0x05 0x00. * The RSA Key is represented as an encapsulated bit field. * There is an apparently unused zero byte (the 22nd byte of the SPKI= field in the RFC 7250 example) as the first byte of this bit field. * The rest of the bit field contains concatenated representations of= the modulus and the exponent as ASN.1 INTEGERs. * The 1024 bit modulus is represented in 129 bytes, with the first b= yte being zero. This brought me up to hour four. Next, I went looking for a 2048 bit cert = to learn from (especially since JWA requires 2048+ bit RSA keys). I found = http://fm4dd.com/openssl/certexamples.htm and chose 2048b-rsa-example-cert.= der, from which I also learned: * These length values are encoded as follows: o 290 - 0x82 0x01 0x22 o 257 - 0x82 0x01 0x01 * From this, I deduced (possibly incorrectly :)) that if the high bi= t of the first length byte is 0, the remaining 7 bits represent the length,= but if the high bit of the first length byte is 1, the remaining 7 bits re= present the number of bytes used to represent the actual length. (Hence th= e use of 0x81 for representing values in the range 128-255 and the use of 0= x82 for representing values in the range 256-32767.) * Length values are represented in big-endian byte order. * The 2048 bit key representation also starts with an apparently unu= sed zero byte. * The 2048 bit modulus is represented by 257 bytes, with the first b= yte being zero. Things I haven't yet learned that I'd need to know to really write this cod= e: * How are the OIDs in the table at http://tools.ietf.org/html/draft-= ietf-jose-json-web-algorithms-40#appendix-A represented as ASN.1 OID values= ? * Are multiple OIDs sometimes present before the ASN.1 NULL, and if = so, which algorithms require which sets of OIDs in what order? * Is there always the apparently unused zero byte in the key represe= ntation or if not, when is it present and absent? * Is there always a leading zero byte in the RSA modulus or if not, = when is it present and absent? * How are elliptic curve keys represented? This brought me up to about the fifth hour of my investigation, and I decid= ed to stop and write up my findings to date. Highlighted versions of the e= xample certificate from RFC 7250 and the SPKI value from fm4dd.com are atta= ched, should any of you want to follow along with my reverse engineering. = Tags are yellow. Lengths are green. OIDs are purple. The apparently unus= ed byte is red. Key values are blue. I readily admit that I could have easily missed something while searching. = If someone can point me to self-contained descriptions of this information= , I'd love to see them! =3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D 1. I think it would be a fine thing to do to write an RFC describing the m= apping between key values and their SPKI representations. This could take = the form of a cookbook with entries like "For a 2048 bit RSA key using RSAS= SA with SHA-256, emit these bytes, filling in slots A and B in the template= with the 256 bites of the mantissa and the 3 bytes of the exponent". Base= d on my searching, I don't think this information exists anywhere in a self= -contained form accessible to developers (but I could be wrong, of course).= I'm not going to personally do it, but if any of you want go for it, have= at it! 2. If my experience is representative, telling developers to just hash the= SPKI representation of a JWK won't be very effective unless they already h= ave X.509 support. Most will probably give up well before the 5 hours that= I've invested to get this this partial understanding of what I'd need to k= now. If my experience is representative, draft-ietf-jose-jwk-thumbprint wi= ll be much easier to implement for these developers. Trying to live in the shoes of developers, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve always loved learning new things, so I de= cided yesterday to try to learn first-hand how to write code that emitted X= .509 SubjectPublicKeyInfo (SPKI) values from scratch.  By “from = scratch”, I mean using development tools without built-in X.509 or ASN.1 support.

 

I took this on because of Stephen’s suggestion= http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that pe= ople could just hash the SPKI values to create a key thumbprint.  Give= n I’d helped create the JSON-based hash input described in ht= tp://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I wanted to= give his alternative suggestion a fair shake (and learn some new things al= ong the way).  This admittedly stream-of-consciousness and overly long message describes my expedition to date…<= /p>

 

Thus far, I’ve spent 5 hours trying to learn t= o do this.  I spent about the first two hours searching for examples o= f creating the bytes of X.509 certificates or SubjectPublicKeyInfo values w= ithout using ASN.1 and/or X.509 libraries.  I failed.

 

Next, I tried to read the authoritative reference fo= r what’s in the SPKI field – the X.509 spec.  Unfortunatel= y, http://www.itu.int/rec/T-= REC-X.509/en told me “This text was pr= oduced through a joint activity with ISO and IEC. According to the agreement with our partners, this document is only available through p= ayment.”  Since most developers would stop at that point,= I did too.

 

After that, I changed tacks and tried to find exampl= es of sample certificates with commentary on what all the values mean ̵= 1; the kind of info developers would want when coding this.  I had bet= ter luck with that.  After about another hour of Web searching, I found this really useful example: http://tools.ietf.org/html/rfc7250#appendix-A.  I also found this = one: http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html.  Goi= ng through them byte-by-byte enabled me to reverse engineer some of the ASN= .1 and X.509 constructs used.

 

Things I learned by looking at these 1024-bit RSA pu= blic key representations included:

·        ASN.1 uses byte-aligned Tag-Length-Value enc= odings.

·        The tags for SEQUENCE, OID, NULL, BIT STRING= , and INTEGER are respectively 0x30, 0x06, 0x05, 0x03, and 0x02.=

·        These Length values are encoded as follows:<= o:p>

o   159 – 0x81 0x9f

o   9 – 0x09

o   0 – 0x00

·        The OID 1.2.840.113549.1.1.1 is encoded in 9= bytes as 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01.

·        The OID is followed by an ASN.1 NULL - 0x05 = 0x00.

·        The RSA Key is represented as an encapsulate= d bit field.

·        There is an apparently unused zero byte (the= 22nd byte of the SPKI field in the RFC 7250 example) as the fir= st byte of this bit field.

·        The rest of the bit field contains concatena= ted representations of the modulus and the exponent as ASN.1 INTEGERs.=

·        The 1024 bit modulus is represented in 129 b= ytes, with the first byte being zero.

 

This brought me up to hour four.  Next, I went = looking for a 2048 bit cert to learn from (especially since JWA requires 20= 48+ bit RSA keys).  I found http://fm4dd.com/open= ssl/certexamples.htm and chose 2048b-rsa-example-cert.der, from which I= also learned:

·        These length values are encoded as follows:<= o:p>

o   290 – 0x82 0x01 0x22

o   257 – 0x82 0x01 0x01

·        From this, I deduced (possibly incorrectly <= span style=3D"font-family:Wingdings"> J) that if the high bit of the first length byte is 0, the remaining= 7 bits represent the length, but if the high bit of the first length byte = is 1, the remaining 7 bits represent the number of bytes used to represent = the actual length.  (Hence the use of 0x81 for representing values in the range 128-255 and the use of 0x82 f= or representing values in the range 256-32767.)

·        Length values are represented in big-endian = byte order.

·        The 2048 bit key representation also starts = with an apparently unused zero byte.

·        The 2048 bit modulus is represented by 257 b= ytes, with the first byte being zero.

 

Things I haven’t yet learned that I’d ne= ed to know to really write this code:

·        How are the OIDs in the table at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A represented as ASN.1 OID values?

·        Are multiple OIDs sometimes present before t= he ASN.1 NULL, and if so, which algorithms require which sets of OIDs in wh= at order?

·        Is there always the apparently unused zero b= yte in the key representation or if not, when is it present and absent?

·        Is there always a leading zero byte in the R= SA modulus or if not, when is it present and absent?

·        How are elliptic curve keys represented?

 

This brought me up to about the fifth hour of my inv= estigation, and I decided to stop and write up my findings to date.  H= ighlighted versions of the example certificate from RFC 7250 and the SPKI v= alue from fm4dd.com are attached, should any of you want to follow along with my reverse engineering.  Tags ar= e yellow.  Lengths are green.  OIDs are purple.&nbs= p; The apparently unused byte is red.  Key valu= es are blue.

 

I readily admit that I could have easily missed some= thing while searching.  If someone can point me to self-contained desc= riptions of this information, I’d love to see them!

 

=3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D

 

1.  I think it would be a fine thing to do to w= rite an RFC describing the mapping between key values and their SPKI repres= entations.  This could take the form of a cookbook with entries like &= #8220;For a 2048 bit RSA key using RSASSA with SHA-256, emit these bytes, filling in slots A and B in the template with the 256 bi= tes of the mantissa and the 3 bytes of the exponent”.  Based on = my searching, I don’t think this information exists anywhere in a sel= f-contained form accessible to developers (but I could be wrong, of course).  I’m not going to personally do it,= but if any of you want go for it, have at it!

 

2.  If my experience is representative, telling= developers to just hash the SPKI representation of a JWK won’t be ve= ry effective unless they already have X.509 support.  Most will probab= ly give up well before the 5 hours that I’ve invested to get this this partial understanding of what I’d need to know.&nbs= p; If my experience is representative, draft-ietf-jose-jwk-thumbprint will = be much easier to implement for these developers.

 

        &nbs= p;            &= nbsp;        Trying to live in the shoes= of developers,

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_-- --_005_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="RFC 7520 Appendix A.docx" Content-Description: RFC 7520 Appendix A.docx Content-Disposition: attachment; filename="RFC 7520 Appendix A.docx"; size=16226; creation-date="Tue, 10 Mar 2015 23:32:47 GMT"; modification-date="Tue, 10 Mar 2015 23:50:37 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQBouJUzWAEAABkFAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANSUQVPCMBCF7874Hzq52wAKOA6FizjDwYvieA7p ps2QJp3sqvDvjVSkVSiXXjxmM3nvm923mcw2hYnewaN2NmH9uMcisNKl2mYJe1k+XN2yCEnYVBhn IWFbQDabXl5MnsAICo8w1yVGQcViwnKi8o5zlDkUAmNXgg03yvlCUDj6jJdCrkUGfNDrjbiva7Bp QzNapAnzizT4L7dlcD6v7ZTSEu6dfCvA0hELToELgqDwGVDCdseq2I8DKOPHGa67ZEAgCt3FA8a+ 0oYw7hJBOUtLsTK1VvyU2iAGJyAKLb1DpyiWruDVGL7aP25OmCNtDeCrpnyuFEiq9+D3VRtH/wTH kbydz0QFVZvGjqTNftSlfR7C7Y226wPBd9LJOYOxBlK7zcmpMNwrOR4Mw5JWEX50adiM+YbAW3Ey vsN/xnvTJe8HrJ7/bFytuB80b3xo008AAAD//wMAUEsDBBQABgAIAAAAIQCZoyRt3AoAAJSbAAAR AAAAd29yZC9kb2N1bWVudC54bWzsXWtv47gV/V6g/4FQP3QXk4fkt411FjOOk3onzaaxp0WxXRSU RNlqZFGlpDieTv97Ly8lxY7jjLKZ5mHRQWhZpimRPPfcBynyhx9v5gG5ZiL2edg3rAPTICx0uOuH 077xaXKy3zFInNDQpQEPWd9Ystj48ej3v/th0XO5k85ZmBAoIox7i8jpG7MkiXqHh7EzY3MaH8x9 R/CYe8mBw+eH3PN8hx0uuHAPa6Zl4lEkuMPiGK43oOE1jY2suPlmaTxiIVzL42JOk/iAi+nhnIqr NNqH0iOa+LYf+MkSyjZbeTG8b6Qi7GU3tF/ckPxJT91Q9pb/QmzU4p7rql8eZy2AVzwULIB74GE8 86PbavzW0qCKs/yWrh+qxPU8yPMtIquxcb2iymX64FjQBXTFbYEbxd3TGK760TxQ7SD797ZX75Zo mQ9VJusRWURxD2VuYf2a+Z3MqR8Wxfy2plltXJCIp+D7VPA0Km4n8p9W2ii8KsqSgvmIOzNbKHmr VYsfVcCG6I5nNGIGmTu90TTkgtoB3NHCahCJSOMIyMLm7lK+R2TRA7JxL/uGCa92Z1A38lMXIHqm 2T1pmB+s4uQx82gaJJvZL1YyY8kXAt/GyTJgUOQ1DfrGOR9H1JGIPpRfCpVHnPAwiSEPjR0f+mHA U+EzQc7ZQl539j6MN8860EarGbHA+HN+pZqpLhF/HsiS8er5uYCG0/wcC2W+w+xe4D3K7gkyYMOs tcKrvOlFLzn6G08T0Bp7hCWEBgdk7TVGhSHcmEwEda7WvlMffrmgU0as1q+yJRLVHphG2Id5W2z2 +uVa8+T5qgISm/MrqfKggUUClfddaCEJ2ZDOQeL+eco/QHsrIOZ5h6Fb5FTI020sqWGbIM6WEROB H14Rge0rRm4TWcGPEy6WYCQhoYkce2uA/L/Iq8MDLi+HnCJZ8+Qk55r8bM4097FPmmeSRlbA1E+3 U5KUx8uTAWnXmuZd6SzaBuv5fC3wVJqFOkmzsheDMgA5iQSLmbhmxtEqNX2S7UMu6YJcpHbgO+Qj W8bED8nkbHx4DMlt5p/SkBEwYRt3G0iL1nbRkrpOs/tW5smbJ+ftVY5Hc0hxPI3AC3L9m/33SpB3 zKCy0ayyB/HbNa++bRUWPS9wBzMqFUB2NAEN1TdsNgXvJrMln5mPv3UV/TBOxITdbGPpP/39Ynh5 Njr/SHI/J+E8iA98lngYB5gl4PMJz5FKyyD/CIixIidEsnRxidzYBHP7+RTYt26wLZiIWUQFTVDH Q53RIXqxWm6YLWbhIuUWyTc2W95n3Ejer+nlXexp0AGrsp8rjVtj35Jfv+maJ0fgVg5v6DwCf36Y BSXXOjZXmTumA59q7cpmkUEF3TyZz3S/q6eb58HmeVbueCrkH3LwTsB5ZopG9kgyY2TGbkjM/p3C QAcj8YwvQunlnfjTVDDSJS6LHeHbLCZUs02uobfHC3K22Rm8jFP7X8xJVBAAYgCj0OMwBiZSJ5EA AUPSdxkCyWEi8WFMCywuEtFlwKl7oCFTHjKagavBwFngzMR3C9MapnVMG5g2MW1h2sa0g2lXS1R5 idoZEoauf7ePL/X22FSDJgfNzJ/OAviX40U4gjCHobcwoco/rJBeB+L5gqGgYrzxFUrLRm8tWRDw xdc6Sw7amDf19QGbV1i97XDbasHvvb0+mwqmXM5F78EKQ5d1rD1i3nS9Nb7SHfc88zK0sN0dD91t YTNdLWYyJvzM05+eJGZmS/fZa+izR+g0c91l09rshbRZSUNf2Y41Kg2RTkumjc7emtBVOk6zwV6l JOEVR0U3KlQeJ1snUUE450sBH68tQWS6mKJ9a2bpGqo0L7wQL5R2Ke/vbuja5o7bidqPxrkDb8pO rGtyeWN2IsQ+1vpMmxmrYVpnSXF630MxpLdkZZQym7ZGAWE8AAaL0MbQTvyrIGfBcAbaQ/BUnoWp temr6LDSZp8eSXipBwU3XLOypFmMJHR07OXNCZtZWzODtF/8Qn7x44XN0h33GnyOMqZybovIoJTj asfD2Do/pExrviXHo0x9HvI7YHqa9Ds8jGd2uhJAECCH1GYyrWPI3MbzXQiMmTdtPOM25LFV11DT UMsf1VFLPWx7yo0QmAP5RULKlNAxEV62J4/tmkwZQrClwus4XuNgTgsBV/c01DTUykINJtpKqDXV yIxiL4RXDY9rK7Br4XmAF+SvIyhbjoaahlpZqMFsbgk1BakuMlYHU4rga2PqKsAplYrq1UFl6tga ahpqZaEGjwxIqFHFZ6giG0pFojWmwGfieQ/z2EqZqlRDra+hVhZqXQU1ptgLIcUUjBSwkM/UJIgm nm9gTjXDpmVqVtNQKws1y1SshgByMK0hpLp43LSlZaZYrYuqs9GSZyw877U01DTUSkPNUlBDf7OD StNDSLWUNYawc9BKq6Fb0FVQw/OUaqhpqJWGWg2hpjgsAxnymYmwa6Ld1saUIZPZeL5Rl9wGdtta 7F3PHdnluSNPDeFadYSa60jodKlMHTyuK8BhaiG8VNgWRgiKPE5NQ02zWmlWayDU6qgQVeSshQ5B B1Wqi+rSUSkCTo0iePhtvaGhpqFWGmpNZaspywxBRpU1hsdNVJR1BFYbOU/5nmpcAdSuVqB6DDRb P/JrA1NWC6GmOMz0pHJUwdsGwquJTAbmP5w39aQIPQPpGZfQ3zp0v+PPqOjnHV6FmJV0TWCCJjwE pzVurnG3r4tRpalFVhvVqolBjjuKs9IRja/DQzdPZdaOy1fm7BWrAd+7ROO4WKLxwxIWZBxnK3xq zi3PuVqoqiFUE1gF12WwzR9ziS2F5YHlcL+D/fZu189NcZOUCwabP2nBKi9Yu/FMBzyEeZomcxqG f4zJ+/H5gZWhSJBf1tAAe6ht7qIEezLCjmuhM+Owz5tg3j6WsH+czmFXPPhFhfZXuq35WrMB/Rbt hs4NNMsb2hPu1++JHwQpLJUMCyLHuEJysWzyHqHx3brq3YC2b5a0M4Rxd311y9RLZBdDHNrNKZri vp3rvt48OyMmP3teDFtpkjMWTpMZKNpj3IUgkhsKa96soKGlFr9+UqpxU0HcAHWY8A/Lpbyzmt0e HIyHf/k0PB8MyX80IKoJCLXNAqm9s+oSEBoSFTc2AAFqtw0CmECOgDM/f/hpOJiQ0fHwfDI6GQ0v yV9pkDLynUVqpNMwiWXVm40useTf95pKqkklkj2yl6KS/NPFx8GY/AEmUoqYwmZ9YqlNV9xto5Iw gelC6lV7Z2YwOf90dqZJo5JoyClCvmdo+K+GQiWhYKk9vcA3aVgIhQ+jCRlPLkfnp3sE9mOkUZwG GD3WzkoRGqtQGAwM0mxnOPBV2hlZaAd2EOebd1WSNWrKWwHWqOXeCiGj88nwdMVLMWsNYvuJ9kwq yRtWU+0ZKT3aLMgB1sYdjLSazXpbA6SSAFk1QnMrlBBth2owaJek0sbFKjEgFDQnPIIT9IzRaswY lVKSzcO2IKR3LCeP+uGUcK/kpOx7Az4xc5ILkc9y6xsmvNqdQV3OB7x/4ls0HX+GLxd9w6rVGiZO HITjJgxQyMdmF71o+mcqS0x4BOcbKouQiyPcfrR5kvD57eeAeSvfzhh1GUxRbIOvBQV5nMNk1+Lj NE3wY3Y5hwfSN4vVRpryJ3gXLndOhe/CN4Efsgs/cWZ9o97Cb0FkVL2PZJvY3F3iAfwkncPGzEf/ AwAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnht bOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2Fb gRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt 3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyK cCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUC HWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9 A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8b c/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDX ahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BU tb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG //rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI 0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH 8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6 gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeR HOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4 QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/ gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+d t/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G 9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpD iK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJ C9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrg eIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWv S91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEK VFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf 4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7 Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqn IRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuW QaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK 0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H 0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2 ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQU AAYACAAAACEAX5ARw3EDAADLCAAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFbbbts4EH1fYP9B0PM6 kmwnaYU4xdZZ76aI26JKP4CSaJsIbxhSVtyv75AUoxpxg6DF+sXknLnfqKt3j4InewqGKblIi7M8 TahsVMvkdpF+vV9N3qSJsUS2hCtJF+mBmvTd9Z9/XPWlodYim0lQhTSlaBbpzlpdZplpdlQQc6Y0 lQhuFAhi8QrbTBB46PSkUUITy2rGmT1k0zy/SAc1apF2IMtBxUSwBpRRG+tESrXZsIYOf1ECXmM3 SN6ophNUWm8xA8rRByXNjmkTtYlf1YYh7qKS/UtB7AWPfH2Rv8Q5hNsraJ8kXuOeE9CgGmoMFkjw EK4gTD6pKebPFD2l+gxTnQXbmVOF4kXuT6Pnhj+TP1HtUMU7VgOBUGZsAOeFaMrbrVRAao5N1Rfz 9Bo76ptSIulLTaHBImE7TvM0c0BLN6Tj9p7UlVUaWfYE7V9GuNkRII2lUGnSYMRLJS0oHvla9VHZ JXYcYEKCwtB/TnU4VaGXUUISgR4F6tCfa9XSFKEO2LOgf5o0J+C9xNh8DKcNKZw9YC3F0Dit7IHT FTpfsW/0b9l+6Ixl2PG+S3/Dg5ccoNJZ/oSTen/QdEWJ7TBN/5MxX4kVZ3rNABTcyhbr/LvGslhE V05cZK2Jhy9K2ViGHH+Xb5azkAvH9ipkOl1eFidlprPl29UpZHaB0D+nkMt5cXM+tMOxB29X8/y9 t4PRDDGI0q2Uz3B9FU6uMRIRmmpJRA2MJGu3dLC9RFnDw3smI15TXLr0R6Tq6ghOJgEwgnC+wsmJ gJ82UbbM6Bu68Wr5msB21DtwwEkqTumHJ11ugin8C6rTwVoPRIeCR3PFfD7oY9LeMRHppqurKCVx cfwAdbL9tAenMBvT05cW3xs/OHdEbmNdqZx8rRwr9geHyr1JdE20xgWBLPW2WKScbXe2cM1u8dbi 2+Qv9XY6YFOP4c1h/kIaFxlyDwfHEI7INRxG2izSZiMNN2/gm4+080g7H2kXkYZvY1/ucDqBM/mA KygeHX2jOFc9bf+LxEX6jBSSYHZEU6yr26Q4Iqr0hGG1mmRf0kfcubRlFp98zVpBHnEF59MLJz5w c3JQnT3idZhj1kfUpCWWoLgv1ZEwlg6/HY59cRu+YdiO1UHU4+I+C45zZmxFNe54qwBD9mv1L695 /Aq5/g4AAP//AwBQSwMEFAAGAAgAAAAhAHMObQeCAQAAUAMAABQAAAB3b3JkL3dlYlNldHRpbmdz LnhtbJRTy27CMBC8V+o/RL6DE4pQiQhICFFVqqqqjw9wHIdYtb2WbZLC13dJePVxgJPXuzPj3Z1k MvvSKqqF8xJMRpJ+TCJhOBTSrDLy8b7s3ZPIB2YKpsCIjGyEJ7Pp7c2kSRuRv4kQEOkjVDE+1Twj VQg2pdTzSmjm+2CFwWIJTrOAV7eimrnPte1x0JYFmUslw4YO4nhE9jLuEhUoS8nFAvhaCxNaPnVC oSIYX0nrD2rNJWoNuMI64MJ7nEerTk8zaY4yyfCPkJbcgYcy9HEY2nVEd1JIT+I20opEmqePKwOO 5Qo32CRDMsX1FbL2+zNqUllkZDyOk7vhOBm19RyKzULWWKuZQmsI3aFxeU+iDMfsID7mX+Wq+rfw DvaAP6HnEALoX3nsaV643TvhxDFoPEGg32YEPw8MLOM4SBtzUIB+sXWArhF11t11zPxHR9dx3fns 11Bpa0Q7dBdOJ93ZegM2SC23Yglu7qDxwrUmMKWgeXl+wAuCz/6D6TcAAAD//wMAUEsDBBQABgAI AAAAIQA98saZ9gkAAFlJAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzcXFtT47gSfj9V 5z+4/M6QGwmhNrPFMMsOVcwsO0Dts+MoxIVt+dgOGebXb6slK45txS1s5uHMwySRpf76pq8VUPPb 7z+i0HlhaRbweOEOPwxch8U+XwXx08J9fLg+OXedLPfilRfymC3cV5a5v3/8739+211k+WvIMgcE xNnFLvEX7ibPk4vT08zfsMjLPkSBn/KMr/MPPo9O+Xod+Ox0x9PV6WgwHOC7JOU+yzJAu/LiFy9z lbioLo0nLAasNU8jL88+8PTpNPLS521yAtITLw+WQRjkryB7MC3E8IW7TeMLpdCJVkgsuZAKqZdi RVqzogFXrvzM/W3E4hwRT1MWgg48zjZBsjfjrdLAxE2h0ssxI16isJi3S4aTGp42mRKDz6m3g1Ds BdbENThjJRdFofSDiO8+qlWJw8ExY1REhAitA0WFQ8xCk8gLYi3mba4pOxf2Q5f8/jPl20SrkwTd pN3Ez1qW2JYWmg2muPPKpmVWAmpb937jJcx1Iv/i5inmqbcMQaPdcOKIjHQ/AlWsuP+Zrb1tmGfi Y3qXqo/qE75c8zjPnN2Fl/lB8AAUAlKiAAR+uYyzwIUnzMvyyyzwGh9uxKzGJ36Wl6R9ClaBeyoQ s58g88ULF+5oVIxcCQ0OxkIvfirGWHzyeF/WZOHqoSXIXbheenJ/KYSdopnFa8nc5MB4+ISqJJ4P Ow9wvHXOgISAxQROGIjojmbAaPLD961wrrfNuQJBAQBWFgsfKx4HbgKmupeMDU/Z+pb7z2x1n8OD hYtYMPh4c5cGPAUaXbjzucCEwXsWBV+C1YqJAqHGHuNNsGL/bFj8mLHVfvzva6RnJdHn2zgH9acz zIIwW/3xw2eJoEkQHXsiwt/EAuAwCEcJBxXaBntt5EAFFQf/V0AOZQwbUTbMEyXNQf2PAqHV285A I2FR2QCUa6XruLuISXcRZ91FYPJ288WsuxZwkOkaEZkbpaykBzXnvky+sh/G8yMpK1bUsqh1RS1p WlfUcqR1RS0lWlfUMqB1RS3grStq8W1dUQvn0RW+h8RVzaIxeoO0sR+CPIQ62cJ0w45Up0qNc+el 3lPqJRtHFNaq2sfI8n67zGmqIp2+nSzv85SL42aLR6A6i637Zk7+I0o2XhbAqbwNqKPrH8TRx/kz DeD42gJ1JpOvZhMeTBpL2F3o+WzDwxVLnQf2Q0bUYv037tzLU0arch3Dehs8bXIHToWi5LaCTQ1O N3tCyr8NMvTB0Wo+NZjSJpwUw6khL83Cv7JVsI0K1xBOI1PJ5xZhrkCgisddNBEhqu+uVitEACgm yHJhbwLKJ+gvi4u9fBFjiv6yFL1RPkF/WbjeKB/z43h8rZnmM/xYxSFtr5n13r3iIU/X27DYA630 MLPewRqCZoL1JtbySSQxs97BB/TpXPo+fHOj5Kl1LPY8aoFiHQ6JgpuNbot1UCq0N7SwyDpAFayR BVY3rrUAsibd7+wlED8Eti0GyNL6rNm6nccGD0AJIp2h/97yvP0MPTJwHhXlJoYfl2TMoaGNDTuP iqbySdY7ixh3K3wWQN0qoAVQt1JoAWTID/OZR9dEOkj34miBZU3Luoph2pGZeWbNzBrIrgT0VDcJ 5y/D7jXnQr1uElCsA1SvmwQU6+hUapmumwSs3uomActQNcwxKnOqjVHWdbMMpE8CBIv6IW8CUD/k TQDqh7wJQN3Jux2kP/ImYFlzg+bUMnkTgHCKzVd9DVQmbwKQNTdItlM/MyrqHko5/uW2B/ImoFgH qE7eBBTr6JjIm4CFU2wyoYKlqY6A1Q95E4D6IW8CUD/kTQDqh7wJQP2QNwGoO3m3g/RH3gQsa27Q nFombwKQNT1ooDJ5E4Bwig03NJI37vp3J28CinWA6uRNQLGOToVQ9SGVgGUdoAqWJm8CFk6xSQaF hcltY1Q/5E2wqB/yJgD1Q94EoH7ImwDUnbzbQfojbwKWNTdoTi2TNwHImh40UJm8CUDW3NBI3rgZ 3528CSjWAaqTNwHFOjoVQtU8R8CyDlAFS5M3AQvzpTN5E4BwyluBbCzqh7wJFvVD3gSgfsibANSd vNtB+iNvApY1N2hOLZM3AciaHjRQmbwJQNbc0EjeuEfenbwJKNYBqpM3AcU6OhVC1eRNwLIOUAVL Ux0Bqx/yJgBhYnYmbwIQTnkDEO4imzD1Q94Ei/ohbwJQd/JuB+mPvAlY1tygObVM3gQga3rQQGXy JgBZc4O4Zwv3RcnXU4eGJKDeMyhuNZABR4YgUQGVgd/ZmqXQVcjab4d0BCwstEA0pAfVxE+cPzu0 i91jQ4KQoYJlGHC80v2Kt3RKjQjj2ZFOgoe/rpwvsgGmtg5T6vDmDXQPlduFsD1JNA6BnvlrAi07 SXGzXEiDBiHR16VagLAn9AYaglRbj1gs+nxgIjZVqWH8va1ChfeAiAtboLRwZcwIu4rK4os2H9XO tfSgOekv0WtUA4fGqudivBB3tfFS6cZ9k0YxR3Vq7HWG9q4M7o8q0QP4Nzu/GsvltaauJYO2VfDc UHZ1yY+X0MSVyRvZynuq90vNwk/1SbIlDH/vJd6qhrD8VjTHSXi+zcWT25ewUA9v+8smMeFj6L/D l4OOu4V7xbdpALfLv7GdiGzRbbdwH4IIGn1h2PnOIw+viGG3XW2JD52EZSkY56X8/yrD11LT3USq m/0sNd3hGGiKKprzwodQeT50yh1JQdUIoe+mYRtENSEN3RKoaj0LVNfE/mwt5x3c3YUhs9656BA4 ojN2EBzdOw5OkZ6rKwhNe9LLupeuWUPYystQZgG8uYlFIu9U157c5KsfnhQFz69YGH71MGdynpin hmydy6fDAZ6MKqKWPM95ZF6fYuMAatIkANxaVkZ+FEaY/R1voyVLVRuCkarEiaLGJdAvgePSgZpr QXskE6qnzbod5LC/zcA12KBZpdIDeqrmr3rojJw9e1Vor3EfoFVNJGjMLPnATHr/Z6SyLzZQ81Lh qVqGfNFP0Jtkt3fZtq3+98UF+yJJRVm6vlYhLQbFX1sAEgKdITdbePag1O9d8vD19i4VNQ3+TkHO VnXPwATnYEaTh8qHgYNUrIjfZ/b7eE6Va+Bm7E6H18JVgtAEWyccCtt8OJWeNE0Yno/VwcM0YzSb nB+XMZ5OVVk0yZicnQ+OyzibzFs0nU6GLZrOxqMWTc9HkxZNwWEtmsJJB1rbMTdM5g4H83mLrsPh HMrNcSkjULdlyng2aVN3Mj1DdUXpUdmiTnCQJOr0pk9m0PgOAuGBOIw19+3/6qPYOxy+jhWupn1c K2BVquhcyCqoMupk5mgl2PTXnJp/baieUvZaY3EcbCJu84nC5D3zKai5wnzjRa9qNV9KbayoWj2w 6pBu/qo2v54MPqlZta9qb9jFe+OKd9nHfwEAAP//AwBQSwMEFAAGAAgAAAAhAEQVyeBNAQAAgQIA ABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIySUUvDMBSF3wX/Q8l7m7RlIqHtQGUP4kBwovgWkrstrElDEtft35u2s7bog4/JOffLObctlidV R0ewTja6RGlCUASaN0LqXYleN6v4FkXOMy1Y3Wgo0RkcWlbXVwU3lDcWnm1jwHoJLgok7Sg3Jdp7 byjGju9BMZcEhw7itrGK+XC0O2wYP7Ad4IyQG6zAM8E8wx0wNiMRXZCCj0jzaeseIDiGGhRo73Ca pPjH68Eq9+dAr0ycSvqzCZ0ucadswQdxdJ+cHI1t2yZt3scI+VP8vn566avGUne74oCqQnDKLTDf 2GotDxA9hvW5Ak+uuxXWzPl12PZWgrg7z5y/1W7AwlF236rKCzw9hvf6esOjIKIQmA71vpW3/P5h s0JVRtJFTPI4JZssp3lGCfnogs3muwLDhbrE+zdxQebEb0DVJ57/NNUXAAAA//8DAFBLAwQUAAYA CAAAACEAE9yLl28JAABoRgAADwAAAHdvcmQvc3R5bGVzLnhtbNxbS3PbNhC+d6b/gcN7oqclyxMl 4zh14xnHcSJ7eqYoyOKEJFSSiu38+i4WIEWRArEw6RzaQyWCwH77wreQg3334SkKnZ8sSQMez93B 277rsNjnqyB+mLv3d5dvTl0nzbx45YU8ZnP3maXuh/d//vHu8SzNnkOWOiAgTs8if+5usmx71uul /oZFXvqWb1kML9c8ibwMHpOHXuQlP3bbNz6Ptl4WLIMwyJ57w35/4ioxCUUKX68Dn33i/i5icYbr ewkLQSKP002wTXNpjxRpjzxZbRPuszQFo6NQyou8IC7EDMY1QVHgJzzl6+wtGNOTGvWEKFg+6OO3 KHSdyD+7eoh54i1DcN7jYOy+B8+tuP+Jrb1dmKXiMblN1KN6wo9LHmep83jmpX4Q3IFLQUAUgKzP 53EauPCGeWl2ngbe0ZcbMevoGz/NStI+BqvA7QnE9BfI/OmFc3c4zEcuhAYHY6EXP+RjLH5zvyhr MneLoSXInbte8mZxLoT10Mz8s2Tu9sB4eEJVtp4PwQAcb50xSArIEYETBiIHh1PIF/nwfSf86u0y rkBQAICVxcJjxeOQK5A5C5nA8Jatr7n/g60WGbyYu4gFg/dXt0nAE0jSuTubCUwYXLAo+BysVkzs FzV2H2+CFftnw+L7lK32498uMfmVRJ/v4gzUn0wxC8J09deTz7YibUF07IkI34gFkDgQjhIOKrQL 9trIgQoqDv6bQw5kDI+ibJgndriD+jcCodW71kBDYVHZAJRrpeuovYhxexEn7UVg8rbzxbS9FsDr bSMic6OUlfSgZtyXyVf2w2jWkLJiRS2LjCtqSWNcUcsR44paShhX1DLAuKIWcOOKWnyNK2rhbFzh e0hc1SwaoTdIG/suyEIm1jcS0KAl1alS49x6ifeQeNuNIwprVe0mslzslhlNVaTTl5PlIkt4/GD0 CFRnsXVfzMl/RduNlwZwSjK4ftjS9Xfi1OP8nQQrI9SJTL6aTXgwOVrCbkPPZxserlji3LEnGVGL 9TfcWchThlG5lmG9Dh42mbPYYMk1gk00Ttd7Qsq/DlL0QeNmmmhMMQknxXCiyUu98C9sFeyi3DWE 08hE8rlFmCsQqGKzi8YiRPXdZbRCBIBigiwX9iagfIL+srjYyxcxpugvS9EL5RP0l4XrhfIxP5rj a800n+BHq0PaXlPrvXvBQ56sd2G+B4z0MLXewQUEzQTrTVzIJ5HE1HoHH9Cnc+778MuNkqfWsdjz qAWKdTgkCm42ui3WQanQ3sDCIusAVbCGFljtuNYCyJp0v7OfgfibmG0xQJYuzprG7TzSeABKEOkM /W3HM/MZeqjhPCrKVQx/LkmZQ0MbaXYeFU3lk6x3FjFuV/gsgNpVQAugdqXQAkiTH/ozT1ET6SDt i6MFljUtF1UM047MzFNrZi6A7EpAR3WTcP7S7F59LtTrJgHFOkD1uklAsY5OpZYVdZOA1VndJGBp qoY+RmVOtTHKum6WgYqTAMGibsibANQNeROAuiFvAlB78jaDdEfeBCxrbig4tUzeBCCcYvNTvwAq kzcByJobJNupvxnldQ+lNP+47YC8CSjWAaqTNwHFOjo68iZg4RSbTKhgFVRHwOqGvAlA3ZA3Aagb 8iYAdUPeBKBuyJsA1J68zSDdkTcBy5obCk4tkzcByJoeCqAyeROAcIoNNxwlb9z1r07eBBTrANXJ m4BiHZ0KoRaHVAKWdYAqWAV5E7Bwik0yKCxMbhujuiFvgkXdkDcBqBvyJgB1Q94EoPbkbQbpjrwJ WNbcUHBqmbwJQNb0UACVyZsAZM0NR8kbN+OrkzcBxTpAdfImoFhHp0KoBc8RsKwDVMEqyJuAhfnS mrwJQDjlpUA2FnVD3gSLuiFvAlA35E0Aak/eZpDuyJuAZc0NBaeWyZsAZE0PBVCZvAlA1txwlLxx j7w6eRNQrANUJ28CinV0KoRakDcByzpAFayC6ghY3ZA3AQgTszV5E4BwyguAcBfZhKkb8iZY1A15 E4Dak7cZpDvyJmBZc0PBqWXyJgBZ00MBVCZvApA1N4h7tnBflHw9daBJAuo9g/xWAxlwqAkSFVAZ +J2tWQJNVsx8O6QlYG6hBaImPagmfuT8h0O72D3SJAgZKliGAccr3c94S6fUiDCaNnQS3H29cD7L BpjaOkypw5s30D1UbhfC9iTROAR6Zs9baNnZ5jfLhTRoEBJ9XaoFCFvkrqAhSLX1iMWizwcmYlOV GsZ/t1Wo8B0QcaEBqhCujBliV1FZfN7mo9q5lh40J30VvUY1cGis+pGP5+IuNl4i3bhv0sjnqE6N vc7Q3pXC/VElug//TU8vRnJ5ralryaApEDw3kF1d8vEcmrhSeSNbeU/1fqlZ+FSfJFvC8N+9xFfV EJZdi+Y4Cc93mXhz/TPM1cPb/rJJTPgY+u/w46Djbu5e8F0SwO3yG/YoIpt3283duyCCvkcYdr7z yMMrYthtV1vip4dDGOel/P9Fip+lpruxVDf9VWq6wzHQFFXU54UPofJ86JRrSEHVCFHcTcM2iGpC arolUNV6Fqiuif3ZWs47uLsLQ3q9M9Eh0KAzdhA07h0Hp0jP1RWEpj3p5aKX7riGsJWXocwC+HIV i0SG5lHMKrnJV0+eFAXvL1gYfvEwZzK+1U8N2TqTbwd9PBlVRC15lvFIvz7BxgHU5JgAcGtZGfko jND7O95FS5ZA51+Dz2+4OFHUuAT6JXBcOrDgWtAeyYTqab1uBzns71JwDTZoVqn0gJ6q+ateOkNn z14V2ju6D9CqYySozSz5Qk96/zNS2RcbqHmJ8FQtQz4Xb9CbZLe32bZG//vign2epKIsXV6qkOaD ousbSAh0htw08OxBqd+75O7L9W0iaho0umdsVfcMTHAOZhzzUPkwcJCKFfH7zH4dz6lyDdyM3enw mbtKEJpgji2HwjYbTKQndRMGpyN18NDNGE7Hp80yRpOJKos6GeOT036zjJPxzKDpZDwwaDodDQ2a ng7HBk3BYQZN4aQDre2YGzpzB/3ZzKDrYDCDctMsZQjqGqaMpmOTuuPJCaorSo/KFnWCgyRRp7fi ZAaN7yAQXojD2PG+/d99FHuFw1dT4Tq2j2sFrEoVrQtZBVVGncwcRoJNfs+p+feG6iFhzzUWx8Fj xK0/Uei8pz8FHa8wNzzvVa3mS6mNFVWrB1Yd0vU/1WaX4/5HNav2U+0Fu3hvXP4tff8fAAAA//8D AFBLAwQUAAYACAAAACEAyuVY+e8BAACuBQAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbLST3Y7aMBCF 7yv1HSLfL3FC9odow2pFi9SbXlTbBzCOQ6z6J/IYsrx9J3bIXgAqtGqQonDGPpr5dOb55V2rZC8c SGsqks0oSYThtpZmW5Gfb+u7J5KAZ6ZmyhpRkYMA8rL8/Om5LxtrPCR430CpeUVa77syTYG3QjOY 2U4YLDbWaebxr9ummrlfu+6OW90xLzdSSX9Ic0ofyGjjrnGxTSO5+GL5Tgvjw/3UCYWO1kArOzi6 9de49dbVnbNcAODMWkU/zaSZbLLixEhL7izYxs9wmDR2lA5WeD2j4Usrkmheftsa69hGIbs+K8hy BJf0pWEaxRVTcuNkKHTMWBAZ1vZMVYTmdE3v8T38Cjof3iQdHHjLHAg/HaRRbpiW6nBUoZcAsdBJ z9ujvmdODg3FEsgtFnawoRX5SvHJ12sSlawiBQqvq0nJsan4ZOOZ+aRgcrCx4BOOZIvggwr6jLdC n2mMzgmJN6kFJN9Fn/ywmpkLRHL6gCTukcdAZn4TERd8A8EbiOSv0/w4yQpHeXwqjvN/EFn8mUj0 uZ7Iyu6cFG5gcoHGIxJYhHwMNIqbaGhbC2fOBKSR76I+n46zLObj5P+XBdO4JuwChyENMRVDOm7b k79Lxeme0GLKyQeJsBW4Xf+yJ+PCwPI3AAAA//8DAFBLAwQUAAYACAAAACEAIMSRJe4BAAD1AwAA EAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACc U8tu2zAQvBfoPwi6x7SdxE2MNYPCQZFD2xiwkpxZamUTpUiCZIS4X9+lFMt021N12peGw5kl3L21 uujQB2XNqpxNpmWBRtpamd2qfKq+XNyURYjC1EJbg6vygKG84x8/wMZbhz4qDAVBmLAq9zG6JWNB 7rEVYUJtQ53G+lZESv2O2aZREu+tfG3RRDafThcM3yKaGusLNwKWA+Kyi/8LWluZ+IXn6uCIMIcK W6dFRP490dGT2sYW2FiFykahK9Uin91QfcxgI3YY+AzYEMCL9XXgl7efgA0hrPfCCxlJQj6fLy6B ZQX47JxWUkRSl39T0ttgm1g89joUCQBYPgKkzRblq1fxwKfA8hS+KpOoEL8hIm5e7Lxw+8CvE8Ex g60UGtekAG+EDgjsVIAHFMndjVDEGLq47FBG64ugfpG/87L4IQIm3VZlJ7wSJpJ+aWxI+li7ED2v VNSETb0h78N8LI/VVVKRZik4H0zFgQM1ztn1J4THhu4W/0F2lpPtOQxUMzpZOJ7xB+ratk6YQ+bP 2npnfe8a2fneTvr/DE+usvdpkd6FPS9my/Ci4n7rhCTL5otr8ue0FlkLtrQ9WJPPR8BTAR7IBK/T qfSv2WF9nPm7kRbteXjFfHY1mdLXb9axRusxPi/+GwAA//8DAFBLAQItABQABgAIAAAAIQAJJIeC gQEAAI4FAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAAugMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAGi4lTNYAQAAGQUAABwAAAAAAAAAAAAAAAAA3gYAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1s LnJlbHNQSwECLQAUAAYACAAAACEAmaMkbdwKAACUmwAAEQAAAAAAAAAAAAAAAAB4CQAAd29yZC9k b2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAACDFAAA d29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAF+QEcNxAwAAywgAABEAAAAAAAAA AAAAAAAAXhsAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHMObQeCAQAAUAMAABQA AAAAAAAAAAAAAAAA/h4AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAD3yxpn2 CQAAWUkAABoAAAAAAAAAAAAAAAAAsiAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1sUEsBAi0A FAAGAAgAAAAhAEQVyeBNAQAAgQIAABEAAAAAAAAAAAAAAAAA4CoAAGRvY1Byb3BzL2NvcmUueG1s UEsBAi0AFAAGAAgAAAAhABPci5dvCQAAaEYAAA8AAAAAAAAAAAAAAAAAZC0AAHdvcmQvc3R5bGVz LnhtbFBLAQItABQABgAIAAAAIQDK5Vj57wEAAK4FAAASAAAAAAAAAAAAAAAAAAA3AAB3b3JkL2Zv bnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAIMSRJe4BAAD1AwAAEAAAAAAAAAAAAAAAAAAfOQAA ZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAkDAABDPAAAAAA= --_005_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="2048b-rsa-example-cert.spki.docx" Content-Description: 2048b-rsa-example-cert.spki.docx Content-Disposition: attachment; filename="2048b-rsa-example-cert.spki.docx"; size=14625; creation-date="Wed, 11 Mar 2015 00:57:25 GMT"; modification-date="Wed, 11 Mar 2015 02:29:03 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQBYNKCHWAEAAHAEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyUwU4CMRCG7ya+w6Z3t4AIxrBwERMOXhTjubTT 3YZtu+mMCm9vBZFFYPWwlyadpvN//Wemo8nKlsk7BDTeZaybdlgCTnplXJ6xl/nD1S1LkIRTovQO MrYGZJPx5cXoCUpB8RIWpsIkZnGYsYKouuMcZQFWYOorcPFE+2AFxW3IeSXkUuTAe53OgId6DjY+ yJnMVMbCTF2zZL6uovLfub3WRsK9l28WHJ2Q4AhE8WUYc4qQA2VsF0kjJ+OnEYZtIlC0Bvb6my3f rN0mht4ZBmtk8Og1pdJbvnXg6+XDQ3M50roEfDVUTLUGSXULfh81cXTPcJwo9T/KsVHem7GFbJIf tCmvvaO5WJS1cvyEmiBu2oQoYnOH0rjl3obvTte2r9S2rHGOEEsuIRCshK1iKdOC7O7Ko1dxQKYr guDE2Tbut4n9AYvno2GqBXf+8YN/YvwJAAD//wMAUEsDBBQABgAIAAAAIQDPwzahdwcAAA5SAAAR AAAAd29yZC9kb2N1bWVudC54bWzsXNtu20YQfS/Qfxjw3dbyTgqRC4qXNA8tjLh9LmiKlgjzBpK2 4n59z1CUIkpy4qZNLEs0bIviZfYys2fOzC733S+fspQe46pOinwiyZdCojiPilmSzyfSn38EF5ZE dRPmszAt8ngiPcW19MvVzz+9W45nRfSQxXlDEJHX42UZTaRF05Tj0aiOFnEW1pdZElVFXdw1l1GR jYq7uySKR8uimo0UIYv2qKyKKK5rlOeG+WNYS524bF9aUcY5yrorqixs6suimo+ysLp/KC8gvQyb 5DZJk+YJsoWxFlNMpIcqH3cVuthUiB8ZryrUfayfqPZacaDc1ZNe1wNtiaMqTlGHIq8XSfm5Gd8q DU1crKv0+KVGPGbp+r5lKWt75W2a/BIdeFW4hCo+C9wTd6AzZquHsnTVD6zfz1rdlSiLLzWm0wiL 2NThJVXol7muSRYm+UbMt3XNdudiRPwX+35fFQ/lpjpl8t+kfcjvN7J4YP6LmgmjHXnbTav/lYC9 oXuzCMtYoiwaf5jnRRXepqjRUtaILVK6AljcFrMn/ixpOQbYzD5OJCFsXTUcXVqf8uK78CFt9q9c 8ylT1oRjtsLK66qVddM8pTGefgzTiXSdQtt/xJ8aacQXq9U9VVDkTY17wjpK0OVu8VAlcUW/x0su d+Hk9f7ZCN2xfWMrsP57XZIiVkXUf7ssuS19dW7UlYvPro6LpzKu0iS/p2qczCZS9WHWNniR1E1R PQFy2xZVkNN2yzXgRwhNGKo2XV3p2tFr669rqV1bX6WRy3Fz1VndXabNZit8AUbXdTqK4qqJP4VZ mcb15aLJ3qFLmiv+D9Xh/6Zf2m/lOZrGjs67wfDqtst6UoRm3V5UdXjR6fCC9Xk5i6tdPX5VcyuD PvmRziP+a0Z8zl0h2p8N1H+tK3xd9n1nffubwX/gWjJfpPhr1o4hC+fgyCEDNYMfoznbSofqfdiX XVmzrB7s/1BkP1D9pzhNi+V27RkfVNHDAbTruBqy7mnUlcOJcV2GERhJWcV1XD3G0hUdd/0PKGJe xXG+qwdLISGTohx3a05QG8OweA16/dJhIbxhQHzPMOeAHg4PCGEMivjBijjoJ4R92np47djpwIA4 wPvayMohyyDN6umDCeFe8HCQMXcMcc22tjImp8OY9yz4Wb78dtQOnQcmCY/pWvvb0//An//nPNyB 8fiMg9IHRRyFgxoCyu+amH75gFCHAXEMA2IV2Ytg0MYP1kYVz3azLGIAp+MApyHtuD0riSDg+9Om PTLOQUwLTj1kenkE8/xM0OlEMNFT2EvVPhvAHGHC/6DChdPT9hCvfP+B90y8cmqp/tuiuOdFXDdN WPGcGa+RwBq05TgPM8zY/PW+mIbRPXvkozO6A5z64ODpqJy8M4TWLffz2abdx9hMgFe3lubb5tKO MEmzi8/s04SgqUZuQJ5Muk+qSopNvktiyicdv6e9wd1tT3Hvduez7u6NmIKJZJ1OgU+KR65Ftk2u QaZFpk1Tm2SLAovNwtNo6sBoBstYL4jbW/xwapbhmWT7JBTSMfFukLAp0NggbJU0lw3CFIwfmkKO AH4MlnE2liGrZCtkqqQLMk0KYBwaWTY5bs8I9kjM24DEZxbRCDhJmD3gErMaBjlTcvoz74OfPGU/ abjkAu9s8nRyWvW7Drke6Q55gEiDFIN0mXydtCmJb53yHBIGWwvD3wZcXFkOOQG5Lsk2iYAUnVSN bDBseEWHibUGwAhIB8uSyZj2IHLAjFPGDDAlb0q2R1OV7cNzOcbyEWOZbA2gUqBYoE+wGM8nbWBQ 0tkwKBXq10hVmEfZQA6foy4DMbhKqkvBlKm27XDshWNrwIzzsQxXJ1+QPCXTp8AjrXUoCL3VgLmF DZKBsKznQ94ozb6Cb0QMCffYb87gEk/ZJcomKSb7PYSLIMoGjAA5Bo8suESZ6bUCBMTKMYMsHay6 Z+iDZZyyZcDX6Rap4Mo++T5ZMucikYg0LA6zDBAkoAX8JCIwLCvtZxoGyzhly0CIbU5JdmkKZ6iR xtlGrCrm5COSMqBPPiYyXExbcLylD0mZ8yFLzI9NdiKIqHxMWCBHo3PcrSNXbZCNiBvc2iAX8xfI Ww+YcT6W4WM2S23VjwBL8JwFXAkDCexD43SdhasIsFzOzljDtNb5WAaAwWjjDmTpOAyH43DJBKXQ mXlgUoMnP9tXTX1w1cEyzscyEJIgFYc5TxBMMyADUAHjCDg2AX4gu2shh4fAHEaDSy+ITfqL/D6u 9gE4ubeaQL6//Kb/G8njI+2iCmYSol30oPfTEntZltdezrju9hN67f9MlgEe2f4RL13aJ078bZk3 AlP8RqXAe5UHU2N1HDXXG/vi3bVe4INu8NDupmPzG94BbIktuxRFa9eoLnCsWzhu122W899CLqcp SpzXVrdUnIXg24TCq1pvi6Ypss+X0/hudVXmq4s4xBZLE8nEpA++3hVFs/V1/tC0X7vioiLl3ce6 rU34kbYW2JXxfZXwklLsOhZfJ02EWqpGexX4uOqNdg+a1ZZsOLfeyPHqHwAAAP//AwBQSwMEFAAG AAgAAAAhADDdQymoBgAApBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0 b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BH UpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0 vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12K MU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDD UsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpBzwCw 74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn 8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80Qt irUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+e P0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybO iy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6K HPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1j fFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQj J5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4 ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AH EKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMRFb68TrgTv4MpG2NiSg0UdadWxzT5 u8LNKFRuy+HiCjeUyhdfP66Q+20t2Zuwe1XlzPaJQr0Id7I8d7kI6NtfnbfwJNkjkBDzW9S74vyu OHv/+eK8KJ8vviTPqjAUaN2L2EbbtN3xwq57TBkbqCkjN6RpvCXsPUEfBvU6c+IkxSksjeBRZzIw cHChwGYNElx9RFU0iHAKTXvd00RCmZEOJUq5hMOiGa6krfHQ+Ct71GzqQ4itHBKrXR7Y4RU9nJ81 CjJGqtAcaHNGK5rAWZmtXMmIgm6vw6yuhTozt7oRzRRFh1uhsjaxOZSDyQvVYLCwJjQ1CFohsPIq nPk1azjsYEYCbXfro9wtxgsX6SIZ4YBkPtJ6z/uobpyUx8qcIloPGwz64HiK1UrcWprsG3A7i5PK 7BoL2OXeexMv5RE88xJQO5mOLCknJ0vQUdtrNZebHvJx2vbGcE6GxzgFr0vdR2IWwmWTr4QN+1OT 2WT5zJutXDE3Cepw9WHtPqewUwdSIdUWlpENDTOVhQBLNCcr/3ITzHpRClRUo7NJsbIGwfCvSQF2 dF1LxmPiq7KzSyPadvY1K6V8oogYRMERGrGJ2Mfgfh2qoE9AJVx3mIqgX+BuTlvbTLnFOUu68o2Y wdlxzNIIZ+VWp2ieyRZuClIhg3kriQe6VcpulDu/KiblL0iVchj/z1TR+wncPqwE2gM+XA0LjHSm tD0uVMShCqUR9fsCGgdTOyBa4H4XpiGo4ILa/BfkUP+3OWdpmLSGQ6TapyESFPYjFQlC9qAsmeg7 hVg927ssSZYRMhFVElemVuwROSRsqGvgqt7bPRRBqJtqkpUBgzsZf+57lkGjUDc55XxzKlmx99oc +Kc7H5vMoJRbh01Dk9u/ELFoD2a7ql1vlud7b1kRPTFrsxp5VgCz0lbQytL+NUU451ZrK9acxsvN XDjw4rzGMFg0RCncISH9B/Y/Knxmv3boDXXI96G2Ivh4oYlB2EBUX7KNB9IF0g6OoHGygzaYNClr 2qx10lbLN+sL7nQLvieMrSU7i7/PaeyiOXPZObl4kcbOLOzY2o4tNDV49mSKwtA4P8gYx5jPZOUv WXx0Dxy9Bd8MJkxJE0zwnUpg6KEHJg8g+S1Hs3TjLwAAAP//AwBQSwMEFAAGAAgAAAAhACW3LQeX AwAAGQkAABEAAAB3b3JkL3NldHRpbmdzLnhtbLRW227jNhB9L9B/MPRcR5JvyQpxFqljt7uIu0WV /QBKGstEeANJWfF+fYekGG8aNwi66JPJOTOHc5evPz5xNjqANlSKZZJfZMkIRC0bKtpl8vVhM75K RsYS0RAmBSyTI5jk483PP133hQFrUc2MkEKYgtfLZG+tKtLU1HvgxFxIBQLBndScWLzqNuVEP3Zq XEuuiKUVZdQe00mWLZKBRi6TTotioBhzWmtp5M46k0LudrSG4Sda6Pe8GyzvZN1xENa/mGpg6IMU Zk+ViWz8v7JhiPtIcngriANnUa/Ps7c0h3B7qZtni/e45wyUljUYgwXiLITLCRXPNPnsFdFzqi8w 1Wl4O3VUaJ5n/nTy3LBX9meqHap4TytNdCgzNoDzgtfFp1ZITSqGTdXns+QGO+qblHzUFwp0jUXC dsyyJHUABiN3pSUWEDYKGPP9WTMgSNYXrSYcO2uZBIm3aWBHOmYfSFVaqVDpQNDny8lAWe+JJrUF XSpSI9tKCqsli3qN/EPaFXapxiQGJ0LPOnfCqQz9jxaCcIwiSIee3soGnGedpq8S9a+JdgbeS8yH j+H8QxLnVdMGMDQGpT0y2KDzJf0Gt6L53BlLcUp8Z/+AB285AMK9/AWn++GoYAPEdpim/+kxX4kN o2pLtZb6k2iwN370sTQW0ZUTl19j4uEvKW0sQ5Zlk+nqwybkwqm9B8lX+ezq6pzNdIF063PIYj27 W+TnkMt8lt1enkM+zKeL2/k5ZD3P1+tbh2CcQ3S8cAvqT31zHU6uZUY8tNuK8EpTMtq6FYZWvKj0 469URLwCXOHwPVJ2VQTH4wAYThjb4ExFwA8aLxpq1B3sPC3bEt2eeAcNfVaK8/v5mcvtA9C/admp 8FqviQqtEJ/LZ7OBjwp7T3mUm64qo5XANfQd1Inmy0E7wvSUnr6w+PXyI3VPRBsrDmL8tXSq2DlM l+4LB1uiFK4OVKnafJkw2u5t7sbA4q3BL52/VO1kwCYew5vD/IXULjLUHg5OIRxRazicZNMom55k uMeD3uwkm0fZ/CRbRBl+aftij3OrcYk+4nKKRyffScZkD83vUbhMXolCEsyeKMC6uh2LwyMLLxiW rhkdCnjCDQ4NtfgHQtGGkye30CcLZz5oM3KUnX2h6zCnrF5IRw2xBM19qV4Y+xb/hy990UBNsR3L I69OK/0iOM6osSUo3P5WagzZL9xfPPPpP83N3wAAAP//AwBQSwMEFAAGAAgAAAAhABegFk4CAQAA rAEAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbIzQwUoDMRAG4LvgOyy5t9mVIrJ0tyBS8SKC+gBp dnYbzGTCTGqsT2/aqiBeesskmY+Zf7n6QF+9A4uj0KlmXqsKgqXBhalTry/r2Y2qJJkwGE8BOrUH Uav+8mKZ2wybZ0ip/JSqKEFatJ3aphRbrcVuAY3MKUIojyMxmlRKnjQaftvFmSWMJrmN8y7t9VVd X6tvhs9RaBydhTuyO4SQjv2awReRgmxdlB8tn6Nl4iEyWRAp+6A/eWhc+GWaxT8InWUSGtO8LKNP E+kDVdqb+nhCryq07cMUiM3GlwRzs1B9iY9icug+YU18y5QFWB+ujfeUnx7vS6H/ZNx/AQAA//8D AFBLAwQUAAYACAAAACEAh5Ac0qQIAABRQQAAGgAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1s zFzfc9s4Dn6/mfsfNHpPbSdpvM2su5NNN9vMdHe7dTL3TMt0zIkk6vQjbvavPxCUaFmyLCBSZ+7J EUXiAwjgA+MQ+fmX71Hovcg0Uzpe+LN3U9+TcaDXKn5a+I8Pd2c/+V6Wi3gtQh3Lhf8qM/+Xj//+ 18+76yx/DWXmgYA4u94lwcLf5nlyPZlkwVZGInsXqSDVmd7k7wIdTfRmowI52el0PTmfzqb4U5Lq QGYZoN2K+EVkfikuakvTiYwBa6PTSOTZO50+TSKRPhfJGUhPRK5WKlT5K8ieXlVi9MIv0vi6VOjM KWSWXFuFyo9qRdqy4giuXflJB0Uk4xwRJ6kMQQcdZ1uV7M14qzQwcVup9HLKiJcorObtktllC8+Z TPHBp1TswBV7gS1xRzZjbRdFod0H49+9V5sSZ9NTxpQeMSKcDhQVDjErTSKhYifmbVtT31zIhyHx /Xuqi8Spk6hh0u7jZyfLpCVDs+kVZl7dtIwloJW6y61IpO9FwfX9U6xTsQpBo93s0jMR6X8Eqljr 4JPciCLMM/OYfk3Lx/IJP+50nGfe7lpkgVIPQCEgJVIg8PNNnCkf3kiR5TeZEkdfbs2so2+CLK9J +1WtlT8xiNk/IPNFhAv//LwauTUaHIyFIn6qxmR89risa7Lw3dAK5C58kZ4tb4ywCZpZfdbMTQ6M hydUJREBZB7giE0ugYSAxQxOqIx3z+fAaPbhW2E2VxS5LkFQAIDVxcJjY8eBm4Cplpax4a3cfNHB s1wvc3ix8BELBh/vv6ZKp0CjC//DB4MJg0sZqc9qvZamQJRjj/FWreV/tjJ+zOR6P/73HdJzKTHQ RZyD+ldzjIIwW//2PZCJoUkQHQvj4T/NAuAwcEcNBxUq1F4bO9BAxcH/VpAz68OjKFspTEnzUP+T QGh1MRjo3FhUNwDlsnS9GC7icriI98NFYPAO24v5cC3gIDPUIzY2alFJd2quAxt89X24+HAiZM2K VhT1rmgFTe+KVoz0rmiFRO+KVgT0rmg5vHdFy7+9K1ruPLkiEEhczSi6wN0gJfaDykOokz1MNxtI dWWp8b6KVDylItl6prA21T5FlstildNURTp9O1ku81Sb42bPjkB1Nqn7Zk7+LUq2IlNwKu8DGrj1 D+bo4/2eKji+9kC9t8HXsgkPJkdL2NdQBHKrw7VMvQf53XqUsf5P7S3tKaNXuYFu/aKetrkHp0JT cnvBrjo2vXsnrPwvKsM9OFnNrzpM6RNO8uFVR1x2C/9DrlURVVtDOI1cWT5nuLkBgSqe3qJL46J2 dvVaYRxAMcGWC74JKJ+gvy0ufPnGxxT9bSl6o3yC/rZwvVE+xsdp/7KZ5hN8reKR0mvOzt1bHep0 U4RVDvTSw5ydwQ6CZgI7iZ18EknM2Rl8QJ/eTRDAb26UOGX7Ys+jDBS2OywKJhvdFrZTGrQ3Y1jE dlAD65yBNYxrGUBs0v0mX5T5EphbDJCl3VmzN50vOnYAShDpDP13ofP+M/R5B+dRUe5j+Lokkx4N 7aIj86hoZTzZesfw8bDCxwAaVgEZQMNKIQOoIz66zzyuJtJBhhdHBhabll0Vw7AjM/OczcwOiFcC RqqbhPNXR/Z2x0K7bhJQ2A5q100CCts7jVrm6iYBa7S6ScDqqBrdPqpzKscodt2sA7mTAMGiccib ADQOeROAxiFvAtBw8u4HGY+8CVhsbnCcWidvAhBO4fyq74Dq5E0AYnODZbvyO6Oq7qGU07/cjkDe BBS2g9rkTUBhe6eLvAlYOIUTCQ0sR3UErHHImwA0DnkTgMYhbwLQOORNABqHvAlAw8m7H2Q88iZg sbnBcWqdvAlAbHpwQHXyJgDhFA43HCVvzPofTt4EFLaD2uRNQGF7p0Go7pBKwGI7qIHlyJuAhVM4 wVBiYXBzjBqHvAkWjUPeBKBxyJsANA55E4CGk3c/yHjkTcBic4Pj1Dp5E4DY9OCA6uRNAGJzw1Hy xmT84eRNQGE7qE3eBBS2dxqE6niOgMV2UAPLkTcBC+NlMHkTgHDKW4E4Fo1D3gSLxiFvAtA45E0A Gk7e/SDjkTcBi80NjlPr5E0AYtODA6qTNwGIzQ1HyRtz5IeTNwGF7aA2eRNQ2N5pEKojbwIW20EN LEd1BKxxyJsAhIE5mLwJQDjlDUCYRRw3jUPeBIvGIW8C0HDy7gcZj7wJWGxucJxaJ28CEJseHFCd vAlAbG4w92zhvij5euqsIwio9wyqWw1kwPMOJ1EBSwO/yY1MoatQ9t8OGQhYWchA7AgPqom/av3s 0S52X3QECBlKrUKl8Ur3K97SqTUiXMxPdBI8/HXrfbYNMK11GFKHN2+ge6jeLoTtSaZxCPTMXxNo 2Umqm+VGGjQImb6usgUIe0LvoSGobOsxi02fD0zEpqpyGP9uW6LCz4CIC9tQwRawAuiIOgFVXnh3 d5DwunsTuONWPCqyb8mo1Cxvx+/PUHbewR3Nk3rn5ib4CZ3xpvjJPfJwivVqW0FozkKV+jQEl61C 22IGP9zHa7BwV3ZnWWeuvwsrCt7fyjD8Q2BDWq6T7qmh3OT27WyKFbAhaqXzXEfd61O8II6aHBMA 4VBXxj4aI7rjJC6ilUzL6+adIWkqB3aiHYakvevaEQrUne7W7SBdXILAdX4V4z3+ZqjiG3vFH3Va CWix+8t0zLVSCNoDn6txJ/AWcqYvbg4PYQgDLeAmOhBjOp3PLqc3Jal09Sji317LDsVL93C8Q7Hs hoSPgzbPhX8LLdM6NJ3fu2ts4awN2RDfd2lWaflPrUsTx2Dzoaf0VIAcEElQZBCf2A3Z5K3DXex2 jbff5YZ/jtIRWnLUW32e6nYLWvz/saEuqj9DgUiNna002785FtTdm9bNfb0x/OH9xdXNe7vB5WYF 5vr5Psqn07s7E3jYH4znPuiEdiagokU12/yTAuB0GGxHW5X82cf/AQAA//8DAFBLAwQUAAYACAAA ACEAKiQEt08BAACBAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAjJJfS8MwFMXfBb9DyXuXtGX+CW0HKnsQB4ITxbeQ3G1hTRqSuLpvb9pu tUUffEzOub+cc9t88aWq6ADWyVoXKJkRFIHmtZB6W6DX9TK+QZHzTAtW1RoKdASHFuXlRc4N5bWF Z1sbsF6CiwJJO8pNgXbeG4qx4ztQzM2CQwdxU1vFfDjaLTaM79kWcErIFVbgmWCe4RYYm4GITkjB B6T5tFUHEBxDBQq0dziZJfjH68Eq9+dAp4ycSvqjCZ1OccdswXtxcH85ORibppk1WRcj5E/w++rp pasaS93uigMqc8Ept8B8bcuV3EP0GNbncjy6bldYMedXYdsbCeLuOHH+VtsBCwfZfqsyy/H4GN7r 6vWPgohCYNrXOytv2f3DeonKlCTzmGRxkqwJofNrSshHG2wy3xboL9Qp3j+JKU1vp8QzoOwST3+a 8hsAAP//AwBQSwMEFAAGAAgAAAAhACyk3FEdCAAAYD4AAA8AAAB3b3JkL3N0eWxlcy54bWzMW9tu 2zgQfV9g/0HQe+pbEm+CukWaNpsAvaR1gn2WJTomIoleSW6Sfv0OhxItS5Y1E6nAPsW6cM4M5/AM 7XDevn+OQuenSFKp4pk7ejN0HRH7KpDxw8y9v7s6+st10syLAy9UsZi5LyJ137/784+3T+dp9hKK 1AEDcXoe+TN3lWXr88Eg9Vci8tI3ai1ieLhUSeRlcJk8DCIvedysj3wVrb1MLmQos5fBeDg8dXMz CcWKWi6lLz4qfxOJOMPxg0SEYFHF6Uqu08LaE8Xak0qCdaJ8kaYQdBQae5EnY2tmdFwzFEk/Uala Zm8gmIHxaKBNwfDRED9FoetE/vnNQ6wSbxHC5D2Njt13MHOB8j+KpbcJs1RfJrdJfplf4Z8rFWep 83Tupb6UdzClYCCSYOv6Ik6lC0+El2YXqfT2Plzpt/Y+8dOsZO2DDKQ70IjpL7D50wtn7nhc3LnU HuzcC734obgn4qP7edmTmWtvLcDuzPWSo/mFNjbAMIu/pXDXO8HDFbqy9nxIBuB4y0wAKYAjGieU moPjKfDFXPzY6Hn1NpnKQdAAgJXNwmVlxoErwJy5ITA8FcvPyn8UwTyDBzMXseDm/c1tIlUCJJ25 Z2caE27ORSSvZRAIvV7ye/fxSgbin5WI71MRbO9/v0Ly5xZ9tYkzcP90iiwI0+DTsy/WmrZgOvZ0 hr/qAUAcSEcJBx3ayK035kYFFW/+W0COTA73oqyEp1e4g/4fBMKoN52BxjqicgBol+XrpLuJ4+4m TrqbQPJ2m4tpdy9A17tmxHCjxEp6UjPlG/KV52FydoCyekSNRa0jaqRpHVHjSOuIGiVaR9QY0Dqi lvDWEbX8to6opfPgCN9D4aqyaIKzQVrYdzILhR5/UIBGHaUuLzXOrZd4D4m3Xjm6sFbdPiSW880i o7mKcvp6sZxniYofWmcEqrNeuq/W5E/ReuWlEnZJLVM/7jj1d3rX4/ydyKAV6sSQrxYTbkz2lrDb 0PPFSoWBSJw78Wwyyhj/VTlzs8toda5jWj/Lh1XmzFdYclvBThsmvXkmjP3PMsU5OLiYThtCaTNO yuFpAy+bjX8RgdxExdQQdiOnRs8Zaa5AoIuHp+hYp6i+ulqj0AmghGDKBT8EtE/w3xQXvn2dY4r/ phS90j7Bf1O4Xmkf+XE4v2yl+QhfWh3S8pqy1+6lClWy3ITFGmiVhyl7BVsIWgjsRWztk0Riyl7B O/LpXPg+fHOj8JSdi62OMlDY6TAouNjosbCTUpG9ESMidoIqWGMGVjetZQCxRfeH+Cn1b2LcYoAq bfearct50jADUIJIe+jvG5W176HHDZpHRbmJ4eeSVDg0tEnDyqOi5Xwy9Y6R426FjwHUrQIygLqV QgZQAz+a9zy2JtJBuhdHBhZblm0VQ9qRlXnKVmYLxCsBPdVNwv6rYfU2c6FeNwko7ATV6yYBhZ2d Si2zdZOA1VvdJGA1VI3mHJU1lRMUu26WgexOgBBRP+JNAOpHvAlA/Yg3Aai7eLeD9CfeBCy2NlhN LYs3AQhf4XzVt0Bl8SYAsbXBqF3+m1FR99DK4S+3PYg3AYWdoLp4E1DY2WkSbwIWvsJhQgXLSh0B qx/xJgD1I94EoH7EmwDUj3gTgPoRbwJQd/FuB+lPvAlYbG2wmloWbwIQWx4sUFm8CUD4Ckcb9oo3 rvrfLt4EFHaC6uJNQGFnpyKodpNKwGInqIJlxZuAha9wyJBjIbk5QfUj3oSI+hFvAlA/4k0A6ke8 CUDdxbsdpD/xJmCxtcFqalm8CUBsebBAZfEmALG1Ya9442L87eJNQGEnqC7eBBR2diqCanWOgMVO UAXLijcBC/nSWbwJQPjKa4E4EfUj3oSI+hFvAlA/4k0A6i7e7SD9iTcBi60NVlPL4k0AYsuDBSqL NwGIrQ17xRvXyG8XbwIKO0F18SagsLNTEVQr3gQsdoIqWFbqCFj9iDcBCInZWbwJQPjKK4BwFXHS 1I94EyLqR7wJQN3Fux2kP/EmYLG1wWpqWbwJQGx5sEBl8SYAsbVBn7OF86Lk46mjBhJQzxkUpxrI gOOGJFEB8wB/iKVIoMlKtJ8O6QhYRMhAbKAHNcQPSj06tIPdkwaCkKHkIpQKj3S/4CmdUiPCZHqg k+Du26VzbRpgauOQUrsnb6B7qNwuhO1JunEI/Mxe1tCysy5Olmtr0CCk+7ryFiBskbuBhqC8rUcP 1n0+8CI2VeW38f+2OSp8BkQcWIfyV4DlQ0fUAaj8wLs9g4TH3avADafi0ZFtS0bhZn46fruHMu/t nNE86HemT4If8BlPih+cIwdfMVmtOwjNWehSm4eQskVoWszgw00cQITQJIj/NTPJDJ49YwqeX4ow /OJhQ1qm1s2vhmKZmaejIVbAiqmFyjIVNY9P8IA4erLPANCh7Iy51EE08yTeRAuRQIfXgTn/qnTl wE60XUqas64NVKDOdLNvO8vFLhA4zi9jPMdfpSo+MUf80aeFBy1233THXG0JQXvgY3HfGryENdPG m91NGMJAR6xmB2IMh9PR8fAiF5WmHkVkUd6heGwv9nco5t2Q8GenzXPmXkILqwq9VCcOWzhLtwzF t12axbL8VerSxHsw+dBTeoggO0Lib1LgJ3ZDVnVrdxabU+NsZ7mSn71yhJHszVZbpprTghH/PybU svoaCkSi46wts+2TfaRunrRm7Wvl8NnJ5PTixExwPlm+Pn6+ZflweHWliYf9wbjvg75nGwI6uine 1s3SoOlws862YvGn7/4DAAD//wMAUEsDBBQABgAIAAAAIQC6QBm8EQIAALcGAAASAAAAd29yZC9m b250VGFibGUueG1stJTbjtowEIbvK+07RL5f4oTsgWjDakuL1JteVNsHMMYBa32IPIYsb99xHLIX gEq2apCiMGP/mvn0zzw9v2uV7IUDaU1FsgkliTDcrqXZVOT36/L2kSTgmVkzZY2oyEEAeZ7ffHlq y9oaDwneN1BqXpGt902ZpsC3QjOY2EYYTNbWaebxr9ukmrm3XXPLrW6YlyuppD+kOaX3pJdx16jY upZcfLN8p4Xx3f3UCYWK1sBWNnBUa69Ra61bN85yAYA9axX1NJNmkMmKEyEtubNgaz/BZtJYURqk 8HpGuy+tSKJ5+WNjrGMrhezarCDzHlzSloZpDC6Ykisnu0TDjAWRYW7PVEVoTpf0Dt/hV9BpeJM0 KPAtcyD8cJDGcM20VIdjFFoJEBON9Hx7jO+Zk6GgmAK5wcQOVrQi3yk++XJJYiSrSIGBl8UQybGo +GT9mekQQedgYZ1OdySbdToYQZ3+VldnGq1zQuJVagHJT9Emv6xm5gKRnN4jiTvkEchMRxFxnW5H cASR/GXoHztZYCsPj8Wx/w8is78TiTrXE1mgoa1icAHFV0Qx+6Q5tF0LZ864o5bvYn3GGhn2fWKN 5TlrXAFirDUWduekcMEcF1g8oBUii2CLYpQtRrMIKM6ZYtpb4P+agmncF+wChzAWcTzCmIxbGJ8b j1NX0GIYmA8S3XrANfMvC6PfHDD/AwAA//8DAFBLAwQUAAYACAAAACEAPf4KlOwBAADzAwAAEAAI AWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu 2zAMvQ/YPxi+N3LSri0CWcWQYuhhWwPEbc+aTCfCZEmQ2KDZ14+yG0fZdppPfCRFPT0+87u33hR7 CFE7W5fzWVUWYJVrtd3W5VPz5eK2LCJK20rjLNTlAWJ5Jz5+4OvgPATUEAsaYWNd7hD9krGodtDL OKOypUrnQi+RYNgy13Vawb1Trz1YZIuqumbwhmBbaC/8NLAcJy73+L9DW6cSv/jcHDwRFryB3huJ IL4nOmbWOuw5m7K8cShNo3sQl9eUnxBfyy1EMedsDPiLCy3hT5ecjSFf7WSQCklCcXtDhzPMP3tv tJJI4opvWgUXXYfF4yBDkc5zlrdwkmYD6jVoPIiKsxzyr9oSkxvOxoCYBbkN0u+iWCR6E+IbJQ2s 6P2ikyYCZ6cEfwCZdruWmvjyPS73oNCFIupftN1FWfyQEZJqdbmXQUuLpF5qG8EQGx8xiEajodlU G/EQ5m15rK+ShtRLwXljSo4cqHDObrghPnb0NvwH2XlOduAwUs3oZOF0xx9TV6730h6y9axc8C4M S6NtvpeT/D/jk2/cfbLRu7DnycwKLxp3Gy9V8k61oKWdXJGV+Ia8Ay2t+TjwlOAPtIRg0q101m6h Pfb8XUg+ex7/YTG/mlX0DcY65sge088lfgMAAP//AwBQSwECLQAUAAYACAAAACEACSSHgoEBAACO BQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAe kRq38wAAAE4CAAALAAAAAAAAAAAAAAAAALoDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY NKCHWAEAAHAEAAAcAAAAAAAAAAAAAAAAAN4GAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAM/DNqF3BwAADlIAABEAAAAAAAAAAAAAAAAAeAkAAHdvcmQvZG9jdW1l bnQueG1sUEsBAi0AFAAGAAgAAAAhADDdQymoBgAApBsAABUAAAAAAAAAAAAAAAAAHhEAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAlty0HlwMAABkJAAARAAAAAAAAAAAAAAAA APkXAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQAXoBZOAgEAAKwBAAAUAAAAAAAA AAAAAAAAAL8bAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCHkBzSpAgAAFFB AAAaAAAAAAAAAAAAAAAAAPMcAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAI AAAAIQAqJAS3TwEAAIECAAARAAAAAAAAAAAAAAAAAM8lAABkb2NQcm9wcy9jb3JlLnhtbFBLAQIt ABQABgAIAAAAIQAspNxRHQgAAGA+AAAPAAAAAAAAAAAAAAAAAFUoAAB3b3JkL3N0eWxlcy54bWxQ SwECLQAUAAYACAAAACEAukAZvBECAAC3BgAAEgAAAAAAAAAAAAAAAACfMAAAd29yZC9mb250VGFi bGUueG1sUEsBAi0AFAAGAAgAAAAhAD3+CpTsAQAA8wMAABAAAAAAAAAAAAAAAAAA4DIAAGRvY1By b3BzL2FwcC54bWxQSwUGAAAAAAwADAAJAwAAAjYAAAAA --_005_4E1F6AAD24975D4BA5B1680429673943A2F496F5TK5EX14MBXC292r_-- From nobody Wed Mar 11 02:03:09 2015 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 AB4DE1AC427 for ; Wed, 11 Mar 2015 02:03:08 -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 8-TZ6RbPRjNN for ; Wed, 11 Mar 2015 02:03:03 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35651A1AB1 for ; Wed, 11 Mar 2015 02:03:02 -0700 (PDT) Received: by wggx12 with SMTP id x12so7538917wgg.13 for ; Wed, 11 Mar 2015 02:03:01 -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=7rO29oQrLVcHVIgXupRAt/2OO+DtOsGOTY0KozuEMWc=; b=hvyyeFymMZs3gSX3Ja6cYIvgEKQu5yVY6dFbN2MwfigbQxJBqQn/kB+RDyHPEZe/00 jGCEfxJ1c2YqVkhyY6TDLxDAuVs7odIBXBkklhji/0IoYHRc6KLKCt3Q9gZfKztpfLKo 9xmdDINIVh82R2I6zDrrxRx/4ceFdaTdzkz7JqQ/2HRCPZEyBy45mSc66lKgMkhIJ/6B V5l60zHaP7bQwznmuwre8W0AgFVuOixbvqN12JsnKqm/eccBw+D7dGy6g9i3IzkjSsO6 8O2KRprMNAt3jsqIQwryXjG0T2HQIO4XqdWdC1iwTHMLP2wRiDPJtFyh1S48jpFVr2vq tMYQ== X-Received: by 10.180.75.108 with SMTP id b12mr75718081wiw.44.1426064581551; Wed, 11 Mar 2015 02:03:01 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id w4sm5151374wib.19.2015.03.11.02.03.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 02:03:00 -0700 (PDT) Message-ID: <550004B3.70402@gmail.com> Date: Wed, 11 Mar 2015 10:02:43 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 09:03:08 -0000 On 2015-03-11 06:16, Mike Jones wrote: Hi Mike, I did approximately the same journey as you did when I created JCS for JavaScript. It wasn't easy. A bare-bones ASN.1 encoder is needed + tables holding OIDs for EC keys. The encodeRSAPublicKey and encodeECPublicKey methods in https://code.google.com/p/openkeystore/source/browse/javascript/trunk/src/crypto/KeySerialization.js use decoded JWK values to generate SPKIs. Since this list is crowded by die-hard ANS.1 experts, you may end-up with lots of feedback :-) BTW, I noted (unfortunately very late) that Java and .NET use different formats for EC signatures. None of the documents give any hint about what they produce. A signature is a signature...well not really. Cheers, Anders > I’ve always loved learning new things, so I decided yesterday to try to learn first-hand how to write code that emitted X.509 SubjectPublicKeyInfo (SPKI) values from scratch. By “from scratch”, I mean using development tools without built-in X.509 or ASN.1 support. > > I took this on because of Stephen’s suggestion http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that people could just hash the SPKI values to create a key thumbprint. Given I’d helped create the JSON-based hash input described in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I wanted to give his alternative suggestion a fair shake (and learn some new things along the way). This admittedly stream-of-consciousness and overly long message describes my expedition to date… > > Thus far, I’ve spent 5 hours trying to learn to do this. I spent about the first two hours searching for examples of creating the bytes of X.509 certificates or SubjectPublicKeyInfo values without using ASN.1 and/or X.509 libraries. I failed. > > Next, I tried to read the authoritative reference for what’s in the SPKI field – the X.509 spec. Unfortunately, http://www.itu.int/rec/T-REC-X.509/en told me “This text was produced through a joint activity with ISO and IEC. According to the agreement with our partners, this document is only available through payment.” Since most developers would stop at that point, I did too. > > After that, I changed tacks and tried to find examples of sample certificates with commentary on what all the values mean – the kind of info developers would want when coding this. I had better luck with that. After about another hour of Web searching, I found this really useful example: http://tools.ietf.org/html/rfc7250#appendix-A. I also found this one: http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. Going through them byte-by-byte enabled me to reverse engineer some of the ASN.1 and X.509 constructs used. > > Things I learned by looking at these 1024-bit RSA public key representations included: > > ·ASN.1 uses byte-aligned Tag-Length-Value encodings. > > ·The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER are respectively 0x30, 0x06, 0x05, 0x03, and 0x02. > > ·These Length values are encoded as follows: > > o159 – 0x81 0x9f > > o9 – 0x09 > > o0 – 0x00 > > ·The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. > > ·The OID is followed by an ASN.1 NULL - 0x05 0x00. > > ·The RSA Key is represented as an encapsulated bit field. > > ·There is an apparently unused zero byte (the 22^nd byte of the SPKI field in the RFC 7250 example) as the first byte of this bit field. > > ·The rest of the bit field contains concatenated representations of the modulus and the exponent as ASN.1 INTEGERs. > > ·The 1024 bit modulus is represented in 129 bytes, with the first byte being zero. > > This brought me up to hour four. Next, I went looking for a 2048 bit cert to learn from (especially since JWA requires 2048+ bit RSA keys). I found http://fm4dd.com/openssl/certexamples.htm and chose 2048b-rsa-example-cert.der, from which I also learned: > > ·These length values are encoded as follows: > > o290 – 0x82 0x01 0x22 > > o257 – 0x82 0x01 0x01 > > ·From this, I deduced (possibly incorrectly J) that if the high bit of the first length byte is 0, the remaining 7 bits represent the length, but if the high bit of the first length byte is 1, the remaining 7 bits represent the number of bytes used to represent the actual length. (Hence the use of 0x81 for representing values in the range 128-255 and the use of 0x82 for representing values in the range 256-32767.) > > ·Length values are represented in big-endian byte order. > > ·The 2048 bit key representation also starts with an apparently unused zero byte. > > ·The 2048 bit modulus is represented by 257 bytes, with the first byte being zero. > > Things I haven’t yet learned that I’d need to know to really write this code: > > ·How are the OIDs in the table at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A represented as ASN.1 OID values? > > ·Are multiple OIDs sometimes present before the ASN.1 NULL, and if so, which algorithms require which sets of OIDs in what order? > > ·Is there always the apparently unused zero byte in the key representation or if not, when is it present and absent? > > ·Is there always a leading zero byte in the RSA modulus or if not, when is it present and absent? > > ·How are elliptic curve keys represented? > > This brought me up to about the fifth hour of my investigation, and I decided to stop and write up my findings to date. Highlighted versions of the example certificate from RFC 7250 and the SPKI value from fm4dd.com are attached, should any of you want to follow along with my reverse engineering. Tags are yellow. Lengths are green. OIDs are purple. The apparently unused byte is red. Key values are blue. > > I readily admit that I could have easily missed something while searching. If someone can point me to self-contained descriptions of this information, I’d love to see them! > > ==== CONCLUSIONS ==== > > 1. I think it would be a fine thing to do to write an RFC describing the mapping between key values and their SPKI representations. This could take the form of a cookbook with entries like “For a 2048 bit RSA key using RSASSA with SHA-256, emit these bytes, filling in slots A and B in the template with the 256 bites of the mantissa and the 3 bytes of the exponent”. Based on my searching, I don’t think this information exists anywhere in a self-contained form accessible to developers (but I could be wrong, of course). I’m not going to personally do it, but if any of you want go for it, have at it! > > 2. If my experience is representative, telling developers to just hash the SPKI representation of a JWK won’t be very effective unless they already have X.509 support. Most will probably give up well before the 5 hours that I’ve invested to get this this partial understanding of what I’d need to know. If my experience is representative, draft-ietf-jose-jwk-thumbprint will be much easier to implement for these developers. > > Trying to live in the shoes of developers, > > -- Mike > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Wed Mar 11 05:23:05 2015 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 44CC91A878B for ; Wed, 11 Mar 2015 05:23:04 -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_31=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 K7EAE1pKfVSF for ; Wed, 11 Mar 2015 05:22:57 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D1C1A8725 for ; Wed, 11 Mar 2015 05:22:57 -0700 (PDT) Received: by lbvp9 with SMTP id p9so8383274lbv.8 for ; Wed, 11 Mar 2015 05:22:55 -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=/H8ptOdXl7U/0+gnaTBlKCh5WaBclbHg3x+kXb+yA08=; b=eucOD0KxxV1X3ZBMNgC8urnz2IkesSrYfE506QMwwVXLs8DBxL4tNcum/nduEbTwP3 Ktbx/oxCKIBpDzIJTgDbo0uDASyHTn6FX5m/+c+nZmAqP8uwj3Xctc6AVrPiFclPSHIF dTT8WaOqvKBarEdyS9qgol+8OjCnue3O3T/mNbsMwGXwL/Bz9VrNuykT5Nq57gM0nAwb Ung/s1YALo3ZYqygVa3+CDiNE8qn8xoPc4Hh1PXM2Eh16GIY4/SB1t2udFiWOY16TBB4 K068FBwGjgGt3Gob9aT5uHtbXjT6qYMpnEFlSFcgFoDIftQ4ytVykWkhxHkfxl9FhFc3 +ykw== X-Gm-Message-State: ALoCoQnPH0n14F1n31pt8O7FNBGbg6QhR22d2/dAx4gOnVe4DaRRAob0wiJchfDUZTKxU7CS5IkW MIME-Version: 1.0 X-Received: by 10.152.1.1 with SMTP id 1mr33920136lai.63.1426076575382; Wed, 11 Mar 2015 05:22:55 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Wed, 11 Mar 2015 05:22:55 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> Date: Wed, 11 Mar 2015 05:22:55 -0700 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e013c6af0b2dc260511025315 Archived-At: Cc: Nat Sakimura , "jose@ietf.org" , Stephen Farrell Subject: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 12:23:04 -0000 --089e013c6af0b2dc260511025315 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Mike, Thanks for the narrative. I think you might not be thinking quite as lazily as some hackers :) The lazy hacker can cover 99+% of cases with the following few lines of JS, which could easily be encoded in an appendix: -----BEGIN----- RSA_1024_PREFIX =3D "30819F300D06092A864886F70D010101050003818D00308189028181"; RSA_2048_PREFIX =3D "30820122300D06092A864886F70D01010105000382010F003082010A02820101"; RSA_SUFFIX =3D "0203010001"; function SPKI_hex(jwk) { if (jwk.kty !=3D "RSA" || jwk.e !=3D "AQAB") { throw "Can't encode this"; } if (jwk.n.length =3D=3D 171) { return RSA_1024_PREFIX + b64_to_hex(jwk.n) + RSA_SUFFIX; } else if (jwk.n.length =3D=3D 342) { return RSA_2048_PREFIX + b64_to_hex(jwk.n) + RSA_SUFFIX; } throw "Can't encode this"; } -----END----- This is pretty much the encoding design philosophy embraced by PKCS#1 itself: https://tools.ietf.org/html/rfc3447#section-9.2 Also, if you want to analyze ASN.1 structs very quickly: http://lapo.it/asn1js/ I have no love for ASN.1, but it's not really any more rocket science than other binary encodings. --Richard On Tue, Mar 10, 2015 at 10:16 PM, Mike Jones wrote: > I=E2=80=99ve always loved learning new things, so I decided yesterday to= try to > learn first-hand how to write code that emitted X.509 SubjectPublicKeyInf= o > (SPKI) values from scratch. By =E2=80=9Cfrom scratch=E2=80=9D, I mean us= ing development > tools without built-in X.509 or ASN.1 support. > > > > I took this on because of Stephen=E2=80=99s suggestion > http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that > people could just hash the SPKI values to create a key thumbprint. Given > I=E2=80=99d helped create the JSON-based hash input described in > http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I wanted to > give his alternative suggestion a fair shake (and learn some new things > along the way). This admittedly stream-of-consciousness and overly long > message describes my expedition to date=E2=80=A6 > > > > Thus far, I=E2=80=99ve spent 5 hours trying to learn to do this. I spent= about > the first two hours searching for examples of creating the bytes of X.509 > certificates or SubjectPublicKeyInfo values without using ASN.1 and/or > X.509 libraries. I failed. > > > > Next, I tried to read the authoritative reference for what=E2=80=99s in t= he SPKI > field =E2=80=93 the X.509 spec. Unfortunately, > http://www.itu.int/rec/T-REC-X.509/en told me =E2=80=9CThis text was prod= uced > through a joint activity with ISO and IEC. According to the agreement wit= h > our partners, this document is only available through payment.=E2=80=9D = Since > most developers would stop at that point, I did too. > > > > After that, I changed tacks and tried to find examples of sample > certificates with commentary on what all the values mean =E2=80=93 the ki= nd of info > developers would want when coding this. I had better luck with that. > After about another hour of Web searching, I found this really useful > example: http://tools.ietf.org/html/rfc7250#appendix-A. I also found > this one: http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. > Going through them byte-by-byte enabled me to reverse engineer some of th= e > ASN.1 and X.509 constructs used. > > > > Things I learned by looking at these 1024-bit RSA public key > representations included: > > =C2=B7 ASN.1 uses byte-aligned Tag-Length-Value encodings. > > =C2=B7 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER a= re > respectively 0x30, 0x06, 0x05, 0x03, and 0x02. > > =C2=B7 These Length values are encoded as follows: > > o 159 =E2=80=93 0x81 0x9f > > o 9 =E2=80=93 0x09 > > o 0 =E2=80=93 0x00 > > =C2=B7 The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a = 0x86 > 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. > > =C2=B7 The OID is followed by an ASN.1 NULL - 0x05 0x00. > > =C2=B7 The RSA Key is represented as an encapsulated bit field. > > =C2=B7 There is an apparently unused zero byte (the 22nd byte of t= he > SPKI field in the RFC 7250 example) as the first byte of this bit field. > > =C2=B7 The rest of the bit field contains concatenated representat= ions > of the modulus and the exponent as ASN.1 INTEGERs. > > =C2=B7 The 1024 bit modulus is represented in 129 bytes, with the = first > byte being zero. > > > > This brought me up to hour four. Next, I went looking for a 2048 bit cer= t > to learn from (especially since JWA requires 2048+ bit RSA keys). I foun= d > http://fm4dd.com/openssl/certexamples.htm and chose > 2048b-rsa-example-cert.der, from which I also learned: > > =C2=B7 These length values are encoded as follows: > > o 290 =E2=80=93 0x82 0x01 0x22 > > o 257 =E2=80=93 0x82 0x01 0x01 > > =C2=B7 From this, I deduced (possibly incorrectly J) that if the h= igh > bit of the first length byte is 0, the remaining 7 bits represent the > length, but if the high bit of the first length byte is 1, the remaining = 7 > bits represent the number of bytes used to represent the actual length. > (Hence the use of 0x81 for representing values in the range 128-255 and t= he > use of 0x82 for representing values in the range 256-32767.) > > =C2=B7 Length values are represented in big-endian byte order. > > =C2=B7 The 2048 bit key representation also starts with an apparen= tly > unused zero byte. > > =C2=B7 The 2048 bit modulus is represented by 257 bytes, with the = first > byte being zero. > > > > Things I haven=E2=80=99t yet learned that I=E2=80=99d need to know to rea= lly write this > code: > > =C2=B7 How are the OIDs in the table at > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendi= x-A > represented as ASN.1 OID values? > > =C2=B7 Are multiple OIDs sometimes present before the ASN.1 NULL, = and > if so, which algorithms require which sets of OIDs in what order? > > =C2=B7 Is there always the apparently unused zero byte in the key > representation or if not, when is it present and absent? > > =C2=B7 Is there always a leading zero byte in the RSA modulus or i= f > not, when is it present and absent? > > =C2=B7 How are elliptic curve keys represented? > > > > This brought me up to about the fifth hour of my investigation, and I > decided to stop and write up my findings to date. Highlighted versions o= f > the example certificate from RFC 7250 and the SPKI value from fm4dd.com > are attached, should any of you want to follow along with my reverse > engineering. Tags are yellow. Lengths are green. OIDs are purple. The > apparently unused byte is red. Key values are blue. > > > > I readily admit that I could have easily missed something while > searching. If someone can point me to self-contained descriptions of thi= s > information, I=E2=80=99d love to see them! > > > > =3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D > > > > 1. I think it would be a fine thing to do to write an RFC describing the > mapping between key values and their SPKI representations. This could ta= ke > the form of a cookbook with entries like =E2=80=9CFor a 2048 bit RSA key = using > RSASSA with SHA-256, emit these bytes, filling in slots A and B in the > template with the 256 bites of the mantissa and the 3 bytes of the > exponent=E2=80=9D. Based on my searching, I don=E2=80=99t think this inf= ormation exists > anywhere in a self-contained form accessible to developers (but I could b= e > wrong, of course). I=E2=80=99m not going to personally do it, but if any= of you > want go for it, have at it! > > > > 2. If my experience is representative, telling developers to just hash > the SPKI representation of a JWK won=E2=80=99t be very effective unless t= hey > already have X.509 support. Most will probably give up well before the 5 > hours that I=E2=80=99ve invested to get this this partial understanding o= f what I=E2=80=99d > need to know. If my experience is representative, > draft-ietf-jose-jwk-thumbprint will be much easier to implement for these > developers. > > > > Trying to live in the shoes of developers, > > -- Mike > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e013c6af0b2dc260511025315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Mike,

Thanks for the narrative.= =C2=A0 I think you might not be thinking quite as lazily as some hackers :)= =C2=A0 The lazy hacker can cover 99+% of cases with the following few lines= of JS, which could easily be encoded in an appendix:

---= --BEGIN-----
RSA_1024_PREFIX =3D "30819F300D06092A864886F70D0= 10101050003818D00308189028181";
RSA_2048_PREFIX =3D "308201223= 00D06092A864886F70D01010105000382010F003082010A02820101";
RSA_SUFFI= X=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "0203010001";

function= SPKI_hex(jwk) {
=C2=A0 if (jwk.kty !=3D "RSA" || jwk.e !=3D &= quot;AQAB") {
=C2=A0=C2=A0=C2=A0 throw "Can't encode this&= quot;;
=C2=A0 }
=C2=A0 if (jwk.n.length =3D=3D 171) {
=C2=A0=C2=A0= =C2=A0 return RSA_1024_PREFIX + b64_to_hex(jwk.n) + RSA_SUFFIX;
=C2=A0 }= else if (jwk.n.length =3D=3D 342) {
=C2=A0=C2=A0=C2=A0 return RSA_2048_= PREFIX + b64_to_hex(jwk.n) + RSA_SUFFIX;
=C2=A0 }
=C2=A0 throw "= Can't encode this";
}
-----END-----

<= /div>
This is pretty much the encoding design philosophy embraced by PK= CS#1 itself:
https://tools.ietf.org/html/rfc3447#section-9= .2

Also, if you want to analyze ASN.1 structs very quickly:
<= a href=3D"http://lapo.it/asn1js/" target=3D"_blank">http://lapo.it/asn1js/<= /a>

I have no love for ASN.1, but it's not really any= more rocket science than other binary encodings.=C2=A0

--Richard


On Tue, Mar 10, 2015 at 10:16 PM, Mik= e Jones <Michael.Jones@microsoft.com>= wrote:

I=E2=80=99ve always loved learning new things, so I = decided yesterday to try to learn first-hand how to write code that emitted= X.509 SubjectPublicKeyInfo (SPKI) values from scratch.=C2=A0 By =E2=80=9Cf= rom scratch=E2=80=9D, I mean using development tools without built-in X.509 or ASN.1 support.

=C2=A0

I took this on because of Stephen=E2=80=99s suggesti= on http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that pe= ople could just hash the SPKI values to create a key thumbprint.=C2=A0 Give= n I=E2=80=99d helped create the JSON-based hash input described in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-0= 3, I wanted to give his alternative suggestion a fair shake (and learn = some new things along the way).=C2=A0 This admittedly stream-of-consciousne= ss and overly long message describes my expedition to date=E2=80=A6=

=C2=A0

Thus far, I=E2=80=99ve spent 5 hours trying to learn= to do this.=C2=A0 I spent about the first two hours searching for examples= of creating the bytes of X.509 certificates or SubjectPublicKeyInfo values= without using ASN.1 and/or X.509 libraries.=C2=A0 I failed.

=C2=A0

Next, I tried to read the authoritative reference fo= r what=E2=80=99s in the SPKI field =E2=80=93 the X.509 spec.=C2=A0 Unfortun= ately, http://= www.itu.int/rec/T-REC-X.509/en told me =E2=80=9CThis text was produced through a joint activity with ISO and IEC. Accor= ding to the agreement with our partners, this document is only available through p= ayment.=E2=80=9D=C2=A0 Since most developers would stop at that poin= t, I did too.

=C2=A0

After that, I changed tacks and tried to find exampl= es of sample certificates with commentary on what all the values mean =E2= =80=93 the kind of info developers would want when coding this.=C2=A0 I had= better luck with that.=C2=A0 After about another hour of Web searching, I found this really useful example: http://tools.ietf.org/html/rfc7250#appendix-A.=C2=A0 I also found this = one: http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html.=C2=A0 Goi= ng through them byte-by-byte enabled me to reverse engineer some of the ASN= .1 and X.509 constructs used.

=C2=A0

Things I learned by looking at these 1024-bit RSA pu= blic key representations included:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ASN.1 uses byte-aligned Tag-Length-Value encodi= ngs.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The tags for SEQUENCE, OID, NULL, BIT STRING, a= nd INTEGER are respectively 0x30, 0x06, 0x05, 0x03, and 0x02.=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 These Length values are encoded as follows:<= /u>

o=C2=A0=C2=A0 159 =E2=80=93 0x81 0x9f

o=C2=A0=C2=A0 9 =E2=80=93 0x09

o=C2=A0=C2=A0 0 =E2=80=93 0x00

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The OID 1.2.840.113549.1.1.1 is encoded in 9 by= tes as 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The OID is followed by an ASN.1 NULL - 0x05 0x0= 0.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The RSA Key is represented as an encapsulated b= it field.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 There is an apparently unused zero byte (the 22= nd byte of the SPKI field in the RFC 7250 example) as the first = byte of this bit field.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The rest of the bit field contains concatenated= representations of the modulus and the exponent as ASN.1 INTEGERs.<= u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The 1024 bit modulus is represented in 129 byte= s, with the first byte being zero.

=C2=A0

This brought me up to hour four.=C2=A0 Next, I went = looking for a 2048 bit cert to learn from (especially since JWA requires 20= 48+ bit RSA keys).=C2=A0 I found htt= p://fm4dd.com/openssl/certexamples.htm and chose 2048b-rsa-example-cert= .der, from which I also learned:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 These length values are encoded as follows:<= /u>

o=C2=A0=C2=A0 290 =E2=80=93 0x82 0x01 0x22

o=C2=A0=C2=A0 257 =E2=80=93 0x82 0x01 0x01

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 From this, I deduced (possibly incorrectly J) that if the high bit of the first length byte is 0, the remaining= 7 bits represent the length, but if the high bit of the first length byte = is 1, the remaining 7 bits represent the number of bytes used to represent = the actual length.=C2=A0 (Hence the use of 0x81 for representing values in the range 128-255 and the use of 0x82 f= or representing values in the range 256-32767.)

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Length values are represented in big-endian byt= e order.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The 2048 bit key representation also starts wit= h an apparently unused zero byte.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The 2048 bit modulus is represented by 257 byte= s, with the first byte being zero.

=C2=A0

Things I haven=E2=80=99t yet learned that I=E2=80=99= d need to know to really write this code:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 How are the OIDs in the table at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A represented as ASN.1 OID values?

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Are multiple OIDs sometimes present before the = ASN.1 NULL, and if so, which algorithms require which sets of OIDs in what = order?

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Is there always the apparently unused zero byte= in the key representation or if not, when is it present and absent?=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Is there always a leading zero byte in the RSA = modulus or if not, when is it present and absent?

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 How are elliptic curve keys represented?=

=C2=A0

This brought me up to about the fifth hour of my inv= estigation, and I decided to stop and write up my findings to date.=C2=A0 H= ighlighted versions of the example certificate from RFC 7250 and the SPKI v= alue from fm4dd.com are = attached, should any of you want to follow along with my reverse engineering.=C2=A0 Tags ar= e yellow.=C2=A0 Lengths are green.=C2=A0 OIDs are purple.=C2=A0 The apparently unus= ed byte is red.=C2=A0 Key values are blue.

=C2=A0

I readily admit that I could have easily missed some= thing while searching.=C2=A0 If someone can point me to self-contained desc= riptions of this information, I=E2=80=99d love to see them!

=C2=A0

=3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D<= /p>

=C2=A0

1.=C2=A0 I think it would be a fine thing to do to w= rite an RFC describing the mapping between key values and their SPKI repres= entations.=C2=A0 This could take the form of a cookbook with entries like = =E2=80=9CFor a 2048 bit RSA key using RSASSA with SHA-256, emit these bytes, filling in slots A and B in the template with the 256 bi= tes of the mantissa and the 3 bytes of the exponent=E2=80=9D.=C2=A0 Based o= n my searching, I don=E2=80=99t think this information exists anywhere in a= self-contained form accessible to developers (but I could be wrong, of course).=C2=A0 I=E2=80=99m not going to personally do i= t, but if any of you want go for it, have at it!

=C2=A0

2.=C2=A0 If my experience is representative, telling= developers to just hash the SPKI representation of a JWK won=E2=80=99t be = very effective unless they already have X.509 support.=C2=A0 Most will prob= ably give up well before the 5 hours that I=E2=80=99ve invested to get this this partial understanding of what I=E2=80=99d need to know.= =C2=A0 If my experience is representative, draft-ietf-jose-jwk-thumbprint w= ill be much easier to implement for these developers.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Trying to live in the shoe= s of developers,

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

=C2=A0


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


--089e013c6af0b2dc260511025315-- From nobody Wed Mar 11 05:42:29 2015 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 1709E1A8799 for ; Wed, 11 Mar 2015 05:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eZGEITS4Dkv for ; Wed, 11 Mar 2015 05:42:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23071A8725 for ; Wed, 11 Mar 2015 05:42:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5808BEBF; Wed, 11 Mar 2015 12:42:23 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akK39NWOsvwT; Wed, 11 Mar 2015 12:42:23 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A09A1BEA1; Wed, 11 Mar 2015 12:42:23 +0000 (GMT) Message-ID: <55003830.8000705@cs.tcd.ie> Date: Wed, 11 Mar 2015 12:42:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Nat Sakimura , "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 12:42:28 -0000 Hi Mike, Simplest is [0] as used in public key pinning for web servers. (That should pop out as an RFC any time now btw.) I really doubt any claim that that there's some magic needed to make this work as those two lines of script show. But given you wanted to learn, and not just get stuff done, it's a pity you didn't start from RFC5280, [1] and RFCs 3279 [2] and 5480. [3] Lots of pages there it's true, but actually only very few need to be read if one only cares about SPKI. Or, maybe just search for the thing you're after [4] and you'll see a bunch of fine information, including howto in the search is even better. [5] Or, if you want code examples those are there too. [6] I have to admit to being more than surprised that 5 hours of effort didn't throw up any of that. But if, after that, you're still desperate, then you could look at code I wrote, (you would need to be desperate to try learn from my crappy code:-) [7] being an example of doing this for RSA in about a dozen JS LOC without any ASN.1 support using the Stanford JS library, and [8] being openssl 'C' code. Or the netinf code [9] implements RFC6920 [10] with implementations of what you need in other languages like php, python and ruby as well, even clojure if you want to be fancy:-) Anyway, it took me ~20 minutes to find all those again, and I guess it might take a while to read everything and find the bits you want, but from my POV if someone is developing a generic library for this kind of thing, they really should understand all this already, (or I don't want them writing crypto code on which I depend) or else if all that's needed a quick bit of code for say a client that emits a key id, then the stackoverflow approach of copying from examples should be fine. Either way, there is IMO not even a scintilla of credibility to any claim that this is super complex or anything like it. I think I'd summarise the real argument against SPKI here as being: "I want to do what I thought of first." And of course since that's not a very good argument, further discussion seems to dive into even worse argument, such as this being too difficult, taking hours or being nasty-old-ASN.1 etc. Cheers, S. [0] https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#appendix-A [1] https://tools.ietf.org/html/rfc5280 [2] https://tools.ietf.org/html/rfc3279 [3] https://tools.ietf.org/html/rfc5480 [4] https://www.google.ie/search?q=subjectpublickeyinfo&sa=G&gbv=1&sei=aC4AVdP1OcHP7gaO9oHoBw [5] https://www.google.ie/search?q=subjectpublickeyinfo+howto&btnG=Search&gbv=1 [6] https://www.google.ie/search?q=sha256+spki+code&btnG=Search&gbv=1 [7] http://sourceforge.net/p/hoba/code/ci/master/tree/js/hoba-gen-key.js#l60 [8] http://sourceforge.net/p/hoba/code/ci/master/tree/lib/hoba-crypt.cc#l74 [9] http://sourceforge.net/p/netinf/code/ci/default/tree/ [10] http://tools.ietf.org/html/rfc6920 On 11/03/15 05:16, Mike Jones wrote: > I've always loved learning new things, so I decided yesterday to try > to learn first-hand how to write code that emitted X.509 > SubjectPublicKeyInfo (SPKI) values from scratch. By "from scratch", > I mean using development tools without built-in X.509 or ASN.1 > support. > > I took this on because of Stephen's suggestion > http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that > people could just hash the SPKI values to create a key thumbprint. > Given I'd helped create the JSON-based hash input described in > http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I > wanted to give his alternative suggestion a fair shake (and learn > some new things along the way). This admittedly > stream-of-consciousness and overly long message describes my > expedition to date... > > Thus far, I've spent 5 hours trying to learn to do this. I spent > about the first two hours searching for examples of creating the > bytes of X.509 certificates or SubjectPublicKeyInfo values without > using ASN.1 and/or X.509 libraries. I failed. > > Next, I tried to read the authoritative reference for what's in the > SPKI field - the X.509 spec. Unfortunately, > http://www.itu.int/rec/T-REC-X.509/en told me "This text was produced > through a joint activity with ISO and IEC. According to the agreement > with our partners, this document is only available through payment." > Since most developers would stop at that point, I did too. > > After that, I changed tacks and tried to find examples of sample > certificates with commentary on what all the values mean - the kind > of info developers would want when coding this. I had better luck > with that. After about another hour of Web searching, I found this > really useful example: http://tools.ietf.org/html/rfc7250#appendix-A. > I also found this one: > http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. Going > through them byte-by-byte enabled me to reverse engineer some of the > ASN.1 and X.509 constructs used. > > Things I learned by looking at these 1024-bit RSA public key > representations included: > > * ASN.1 uses byte-aligned Tag-Length-Value encodings. > > * The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER > are respectively 0x30, 0x06, 0x05, 0x03, and 0x02. > > * These Length values are encoded as follows: > > o 159 - 0x81 0x9f > > o 9 - 0x09 > > o 0 - 0x00 > > * The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a > 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. > > * The OID is followed by an ASN.1 NULL - 0x05 0x00. > > * The RSA Key is represented as an encapsulated bit field. > > * There is an apparently unused zero byte (the 22nd byte of > the SPKI field in the RFC 7250 example) as the first byte of this bit > field. > > * The rest of the bit field contains concatenated > representations of the modulus and the exponent as ASN.1 INTEGERs. > > * The 1024 bit modulus is represented in 129 bytes, with the > first byte being zero. > > This brought me up to hour four. Next, I went looking for a 2048 bit > cert to learn from (especially since JWA requires 2048+ bit RSA > keys). I found http://fm4dd.com/openssl/certexamples.htm and chose > 2048b-rsa-example-cert.der, from which I also learned: > > * These length values are encoded as follows: > > o 290 - 0x82 0x01 0x22 > > o 257 - 0x82 0x01 0x01 > > * From this, I deduced (possibly incorrectly :)) that if the > high bit of the first length byte is 0, the remaining 7 bits > represent the length, but if the high bit of the first length byte is > 1, the remaining 7 bits represent the number of bytes used to > represent the actual length. (Hence the use of 0x81 for representing > values in the range 128-255 and the use of 0x82 for representing > values in the range 256-32767.) > > * Length values are represented in big-endian byte order. > > * The 2048 bit key representation also starts with an > apparently unused zero byte. > > * The 2048 bit modulus is represented by 257 bytes, with the > first byte being zero. > > Things I haven't yet learned that I'd need to know to really write > this code: > > * How are the OIDs in the table at > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A > represented as ASN.1 OID values? > > * Are multiple OIDs sometimes present before the ASN.1 NULL, > and if so, which algorithms require which sets of OIDs in what > order? > > * Is there always the apparently unused zero byte in the key > representation or if not, when is it present and absent? > > * Is there always a leading zero byte in the RSA modulus or if > not, when is it present and absent? > > * How are elliptic curve keys represented? > > This brought me up to about the fifth hour of my investigation, and I > decided to stop and write up my findings to date. Highlighted > versions of the example certificate from RFC 7250 and the SPKI value > from fm4dd.com are attached, should any of you want to follow along > with my reverse engineering. Tags are yellow. Lengths are green. > OIDs are purple. The apparently unused byte is red. Key values are > blue. > > I readily admit that I could have easily missed something while > searching. If someone can point me to self-contained descriptions of > this information, I'd love to see them! > > ==== CONCLUSIONS ==== > > 1. I think it would be a fine thing to do to write an RFC describing > the mapping between key values and their SPKI representations. This > could take the form of a cookbook with entries like "For a 2048 bit > RSA key using RSASSA with SHA-256, emit these bytes, filling in slots > A and B in the template with the 256 bites of the mantissa and the 3 > bytes of the exponent". Based on my searching, I don't think this > information exists anywhere in a self-contained form accessible to > developers (but I could be wrong, of course). I'm not going to > personally do it, but if any of you want go for it, have at it! > > 2. If my experience is representative, telling developers to just > hash the SPKI representation of a JWK won't be very effective unless > they already have X.509 support. Most will probably give up well > before the 5 hours that I've invested to get this this partial > understanding of what I'd need to know. If my experience is > representative, draft-ietf-jose-jwk-thumbprint will be much easier to > implement for these developers. > > Trying to live in the shoes of developers, -- Mike > > > > > _______________________________________________ jose mailing list > jose@ietf.org https://www.ietf.org/mailman/listinfo/jose > From nobody Wed Mar 11 05:54:52 2015 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 B56891A883E for ; Wed, 11 Mar 2015 05:54:51 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXyFTenHsX0W for ; Wed, 11 Mar 2015 05:54:44 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191B31A8824 for ; Wed, 11 Mar 2015 05:54:43 -0700 (PDT) Received: by qgdq107 with SMTP id q107so9551546qgd.6 for ; Wed, 11 Mar 2015 05:54:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-type; bh=DJSNDMrIhR2tT/fHfzL4qrUyrApv3nHdMykKmoJjeJM=; b=am6BS4CrjazXGIXB4ZpBEuleMrRFvxw6MzJ+fz00hEGNPIBJiarje1dXAJM+fHUBLp EVKfK9RH5Cbgp0ZEe8fw4O1PG7LIuOsExnoXxy+pS4EO6HoGz1lL8dxoXzpH6MMTZk3N JjwgG9xeC8/vPdsp/HagI8i9EHrmkJ46pOQOTyyM6QgJ5mduM/Bibppcawe2kRaVOTXd 8WKslvbKt5IF8oRvNJrfH4yzSU34/BeuVVFzHGs9MXFQAzGkqVE0jnpiHHi+CyJ2IJlK Nvw9ZWyOTjvnFzaUDRizkhKDRa6ASx+4jSHLM4diibrjvQjL9eOuOnkZ2S7Y/KKbObzu JlBw== X-Gm-Message-State: ALoCoQndOqwbo+lFf2p/QJ7nvPsDSRyakfO+h4Ig5gnAg40DwUc0ZEOUKKJutIA3sVhIJZCHU94H X-Received: by 10.140.150.15 with SMTP id 15mr48611855qhw.46.1426078483245; Wed, 11 Mar 2015 05:54:43 -0700 (PDT) Received: from [192.168.2.27] (pool-96-241-148-223.washdc.fios.verizon.net. [96.241.148.223]) by mx.google.com with ESMTPSA id f102sm2497192qki.1.2015.03.11.05.54.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 05:54:42 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Wed, 11 Mar 2015 08:54:38 -0400 From: Carl Wallace To: Mike Jones , Stephen Farrell Message-ID: Thread-Topic: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3508908882_18364217" Archived-At: Cc: Nat Sakimura , "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 12:54:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3508908882_18364217 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Inline=E2=80=A6 From: Mike Jones Date: Wednesday, March 11, 2015 at 1:16 AM Things I haven=E2=80=99t yet learned that I=E2=80=99d need to know to really write this code: > =C2=B7 How are the OIDs in the table at > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendi= x-A > represented as ASN.1 OID values? OID encoding is a pain (but there are some free tools/source to help in thi= s regard). Fortunately for you, as Richard implicitly noted, you don=E2=80=99t need the OIDs you reference when encoding a subject public key info. If you want to encode them for some other purpose, this site from your employer has a decent description of the OID encoding process: https://msdn.microsoft.com/en-us/library/bb540809(v=3Dvs.85).aspx > =C2=B7 Are multiple OIDs sometimes present before the ASN.1 NULL, and i= f so, > which algorithms require which sets of OIDs in what order? Multiple OIDs are never present before the ASN.1 NULL here (nor is are the parameters represented as ASN.1 NULL for other algorithms). The structure is AlgorithmIdentifier as defined below. If multiple OIDs were permitted th= e algorithm field would be SEQUENCE or SET but it=E2=80=99s not. AlgorithmIdentifier ::=3D SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } > =C2=B7 Is there always the apparently unused zero byte in the key > representation or if not, when is it present and absent? The leading zero is present for any integer value with the high bit set, which is the case for RSA keys being encoded here. > =C2=B7 Is there always a leading zero byte in the RSA modulus or if not= , when > is it present and absent? See above, except in this case the high bit is not set so no leading zero. > =C2=B7 How are elliptic curve keys represented? RFC 5912 is a fairly comprehensive resource for the structures you=E2=80=99ll nee= d, including public key and parameter structures for different algorithms. --B_3508908882_18364217 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Inline…

<= /div>
From: Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, March 11, 2015 at 1:16 AM<= /div>
<snip>
Things I haven’t yet learned that I&#= 8217;d need to know to really write this code:
=

=C2=B7        How are the OIDs in the table at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A represented as ASN.1 OID values?


OID encoding is a pain (but there are some free tool= s/source to help in this regard). Fortunately for you, as Richard implicitly= noted, you don’t need the OIDs you reference when encoding a subject = public key info. If you want to encode them for some other purpose, this sit= e from your employer has a decent description of the OID encoding process:&n= bsp;https://msdn.microsoft.com/en-us/library/bb540809(v=3Dvs.85).aspx
<= div>
=

=C2=B7      &nb= sp; Are multiple OIDs sometimes present befo= re the ASN.1 NULL, and if so, which algorithms require which sets of OIDs in= what order?


Mu= ltiple OIDs are never present before the ASN.1 NULL here (nor is are the par= ameters represented as ASN.1 NULL for other algorithms).  The structure= is AlgorithmIdentifier as defined below. If multiple OIDs were permitted th= e algorithm field would be SEQUENCE or SET but it’s not.
   AlgorithmIdentifi=
er  ::=3D  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }
<= pre class=3D"newpage" style=3D"font-size: 1em; margin-top: 0px; margin-bottom: 0= px; page-break-before: always; widows: 1;">

=C2=B7        Is there always the apparently unused ze= ro byte in the key representation or if not, when is it present and absent?<= /p>


The leading zer= o is present for any integer value with the high bit set, which is the case = for RSA keys being encoded here.  

<= o:p>

=C2=B7        Is there always a leading zero byte in t= he RSA modulus or if not, when is it present and absent?


See above, except in this case the= high bit is not set so no leading zero.

=

=C2=B7        How are elliptic curve keys represented?=


RFC 5912 is a = fairly comprehensive resource for the structures you’ll need, includin= g public key and parameter structures for different algorithms.  
=

--B_3508908882_18364217-- From nobody Wed Mar 11 06:08:03 2015 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 823C01A8AB6 for ; Wed, 11 Mar 2015 06:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYPOPsKm_70k for ; Wed, 11 Mar 2015 06:07:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137481A8A9B for ; Wed, 11 Mar 2015 06:07:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D778FBEBF; Wed, 11 Mar 2015 13:07:53 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA8-EqFi_A8b; Wed, 11 Mar 2015 13:07:53 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B65ECBEAF; Wed, 11 Mar 2015 13:07:53 +0000 (GMT) Message-ID: <55003E2A.6000502@cs.tcd.ie> Date: Wed, 11 Mar 2015 13:07:54 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Barnes , Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "jose@ietf.org" , Nat Sakimura Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 13:08:02 -0000 On 11/03/15 12:22, Richard Barnes wrote: > I have no love for ASN.1, but it's not really any more rocket science than > other binary encodings. That, and of course in this case if SPKI is used, there is no decoding requirement at all. It's decoding complex structures (like certs) that's the real PITA with ASN.1 defined things in my experience, esp when you get errors in hard-to-handle bits of code generated by compilers. None of that is at all relevant here. S. PS: Interesting that both of our hacky bits of JS code are almost identical even though mine has nothing to do with JOSE:-) From nobody Wed Mar 11 06:49:11 2015 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 B85B51AC7E8 for ; Wed, 11 Mar 2015 06:49:09 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obr0AlxE5_0U for ; Wed, 11 Mar 2015 06:49:07 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3B31AC449 for ; Wed, 11 Mar 2015 06:49:06 -0700 (PDT) Received: by oiav63 with SMTP id v63so7730174oia.9 for ; Wed, 11 Mar 2015 06:49:06 -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; bh=HF9xYiPAapDD4+53/lIupnmi1jfnXfL/45bQ/E87TJk=; b=VtdVENY8Jy5Hz8gTTfdiNJlQkSEy3+60EoyuNXOvRLBvEzIMzFrsNgJHkLPhs4vgaV 1c6szQuWgFs4Kr6ZA0+Gc7klSSCBqD9l1DPJEVrGLGlF+ykrOKTpC5WVScJ0XMx5i+3B EptAJpDrQ1IoirEQifctHV19gjMqw22mZ0RA4is9j8LR7sa5eB+ou2heSZoHV5woNkFp vz5OVKMCokhFPEaATEsW1k1CA/9PZbt6nxttcWEWc4BLhkRdyf0EJvhGYPWM30q7O/7B GpI5ggrzHaUXeT5Cm9cinGYgRcoRtFE/BiJznA0FzjZjEGMv4QApMSyWarX2Cyhef6S3 SFGw== MIME-Version: 1.0 X-Received: by 10.182.24.133 with SMTP id u5mr30026334obf.27.1426081746168; Wed, 11 Mar 2015 06:49:06 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Wed, 11 Mar 2015 06:49:06 -0700 (PDT) In-Reply-To: <54FEB612.7030707@connect2id.com> References: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> <4E1F6AAD24975D4BA5B1680429673943A2E82259@TK5EX14MBXC292.redmond.corp.microsoft.com> <54FEB612.7030707@connect2id.com> Date: Wed, 11 Mar 2015 22:49:06 +0900 Message-ID: From: Nat Sakimura To: Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary=001a11c30864e6b574051103878b Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] COSE: what would change? 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, 11 Mar 2015 13:49:09 -0000 --001a11c30864e6b574051103878b Content-Type: text/plain; charset=UTF-8 We have something similar as well... 2015-03-10 18:14 GMT+09:00 Vladimir Dzhuvinov : > Arrays would be good. Perhaps even bit fields? > > We recently had a use case where we had to constrain the size of JWTs > and we successfully compressed an array of various constant claims into > a base64 encoded bit field, giving us significant space saving. > > Vladimir > > On 6.03.2015 21:43, Mike Jones wrote: > > Thanks for writing this, Joe. I know that people from the IoT and other > communities are already itching for a CBOR JOSE encoding and we'll do > everyone a service by providing one in a timely fashion. > > > > I think your proposal to set a high, well-understood and agreed upon bar > for any changes to the decisions made in JOSE is the key to having this > complete in a reasonable period of time. In my view, if we open most > decisions to be re-debated, our timeline is far more likely to look like > the JOSE timeline (in which we had the WOES BoF in July 2011 and are only > nearing having RFCs now over 3.5 years later) than the quick turnaround > achievable by building on past work that I think we would all like. > > > > Getting down to specifics, looking at the two COSE submissions to date, > https://tools.ietf.org/html/draft-bormann-jose-cose-00 and > http://tools.ietf.org/html/draft-schaad-cose-00, I think Carsten's > submission is more effective at leveraging our existing decisions than > Jim's does so I'd personally want to use that as a starting point, but > there are some things I find valuable in Jim's draft as well. For > instance, I think that we should consider using arrays rather than maps at > the top level, as Jim suggests, as it may keep the code simpler and the > representations more compact. I'll note that this is actually parallel to > the JOSE Compact Serializations, which used data structures with fixed > numbers of elements in fixed positions at the top level, rather than JSON > objects, as was done in the JSON Serializations. > > > > I'll also add that I personally think we should only define one > serialization for the CBOR encoding. I would justify this departure from > JOSE as being in the name of "keeping simple things simple" - something I > think should also be part of our criteria when making our decisions. (If > people do need a URL-safe representation of a COSE object, it would be fine > for them to base64url encode the whole thing, for transmission purposes - a > suggestion that Joe made to me in person in Honolulu.) > > > > Anyway, I'm glad to see this discussion and look forward to us hopefully > completing a COSE standard within a year from now! > > > > -- Mike > > > > -----Original Message----- > > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Joe Hildebrand > (jhildebr) > > Sent: Friday, March 06, 2015 11:19 AM > > To: jose@ietf.org > > Subject: [jose] COSE: what would change? > > > > In talking with several folks about COSE, it appears that there are > differing views on how much to change in the JOSE/COSE translation. I > would like to explore the points of agreement and disagreement a little. > > > > > > It seems like most people agree that maintaining signature compatibility > is a non-goal; I agree that is the only way for us to have a chance at > success. > > > > > > I think we're also likely to get agreement that we should do our best to > use CBOR idioms in COSE (such as mixed-type keys for maps) once they are > explained to the group in enough detail for everyone to understand the > proposals. > > > > Finally, I think one of the reasons people are interested in COSE is a > chance to optimize for a different set of use cases than we had for JOSE. > > > > > > The main source of disagreement seems to be what we would change in COSE > of the things some might have wanted to done differently in JOSE. I'm > sympathetic to both the group that wants to crank something out quickly > without re-litigating the past, as well as to the group that wants to > re-optimize as many things as possible given the removal of the pressure of > existing codebases that we had with JOSE. > > > > > > An approach that might work for this would be to set a bar for changes > along the lines of "significant improvement in security, performance (wire > size, code size, CPU, power, etc.), or deployability" would be required to > justify a change. To see if that approach would work, it would be nice to > see a list of things that folks would want to change, and to get early > agreement on a couple of those changes as being above the bar that we set, > so that we have some precedent to reason from. > > > > > > To that end, I propose that those that want changes produce a list, > perhaps annotated with whether the change is seen as imperative or merely > nice-to-have. The folks that want a quick outcome would then select > several changes they see as being definitely above the line. My hope is > that this exercise would build trust that we all want something similar: a > high quality protocol standardized in as short a time as possible. > > > > > > -- > Vladimir Dzhuvinov :: vladimir@connect2id.com > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c30864e6b574051103878b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have something similar as well...=C2=A0

2015-03-10 18:14 GMT+09:00 = Vladimir Dzhuvinov <vladimir@connect2id.com>:
Arrays would be good. Perhaps even bit fields?
We recently had a use case where we had to constrain the size of JWTs
and we successfully compressed an array of various constant claims into
a base64 encoded bit field, giving us=C2=A0 significant space saving.

Vladimir

On 6.03.2015 21:43, Mike Jones wrote:
> Thanks for writing this, Joe.=C2=A0 I know that people from the IoT an= d other communities are already itching for a CBOR JOSE encoding and we'= ;ll do everyone a service by providing one in a timely fashion.
>
> I think your proposal to set a high, well-understood and agreed upon b= ar for any changes to the decisions made in JOSE is the key to having this = complete in a reasonable period of time.=C2=A0 In my view, if we open most = decisions to be re-debated, our timeline is far more likely to look like th= e JOSE timeline (in which we had the WOES BoF in July 2011 and are only nea= ring having RFCs now over 3.5 years later) than the quick turnaround achiev= able by building on past work that I think we would all like.
>
> Getting down to specifics, looking at the two COSE submissions to date= , https://tools.ietf.org/html/draft-bormann-jose-cose-00 and = http://tools.ietf.org/html/draft-schaad-cose-00, I think Carsten'= ;s submission is more effective at leveraging our existing decisions than J= im's does so I'd personally want to use that as a starting point, b= ut there are some things I find valuable in Jim's draft as well.=C2=A0 = For instance, I think that we should consider using arrays rather than maps= at the top level, as Jim suggests, as it may keep the code simpler and the= representations more compact.=C2=A0 I'll note that this is actually pa= rallel to the JOSE Compact Serializations, which used data structures with = fixed numbers of elements in fixed positions at the top level, rather than = JSON objects, as was done in the JSON Serializations.
>
> I'll also add that I personally think we should only define one se= rialization for the CBOR encoding.=C2=A0 I would justify this departure fro= m JOSE as being in the name of "keeping simple things simple" - s= omething I think should also be part of our criteria when making our decisi= ons.=C2=A0 (If people do need a URL-safe representation of a COSE object, i= t would be fine for them to base64url encode the whole thing, for transmiss= ion purposes - a suggestion that Joe made to me in person in Honolulu.)
>
> Anyway, I'm glad to see this discussion and look forward to us hop= efully completing a COSE standard within a year from now!
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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-bounc= es@ietf.org] On Behalf Of Joe Hildebrand (jhildebr)
> Sent: Friday, March 06, 2015 11:19 AM
> To: jose@ietf.org
> Subject: [jose] COSE: what would change?
>
> In talking with several folks about COSE, it appears that there are di= ffering views on how much to change in the JOSE/COSE translation.=C2=A0 I w= ould like to explore the points of agreement and disagreement a little.
>
>
> It seems like most people agree that maintaining signature compatibili= ty is a non-goal; I agree that is the only way for us to have a chance at s= uccess.
>
>
> I think we're also likely to get agreement that we should do our b= est to use CBOR idioms in COSE (such as mixed-type keys for maps) once they= are explained to the group in enough detail for everyone to understand the= proposals.
>
> Finally, I think one of the reasons people are interested in COSE is a= chance to optimize for a different set of use cases than we had for JOSE.<= br> >
>
> The main source of disagreement seems to be what we would change in CO= SE of the things some might have wanted to done differently in JOSE.=C2=A0 = I'm sympathetic to both the group that wants to crank something out qui= ckly without re-litigating the past, as well as to the group that wants to = re-optimize as many things as possible given the removal of the pressure of= existing codebases that we had with JOSE.
>
>
> An approach that might work for this would be to set a bar for changes= along the lines of "significant improvement in security, performance = (wire size, code size, CPU, power, etc.), or deployability" would be r= equired to justify a change.=C2=A0 To see if that approach would work, it w= ould be nice to see a list of things that folks would want to change, and t= o get early agreement on a couple of those changes as being above the bar t= hat we set, so that we have some precedent to reason from.
>
>
> To that end, I propose that those that want changes produce a list, pe= rhaps annotated with whether the change is seen as imperative or merely nic= e-to-have.=C2=A0 The folks that want a quick outcome would then select seve= ral changes they see as being definitely above the line.=C2=A0 My hope is t= hat this exercise would build trust that we all want something similar: a h= igh quality protocol standardized in as short a time as possible.
>
>

--
Vladimir Dzhuvinov :: vladimir@connect2id.com

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



--
=
Nat Sakimura (=3Dnat)
Chairman, OpenID F= oundation
http://= nat.sakimura.org/
@_nat_en
--001a11c30864e6b574051103878b-- From nobody Wed Mar 11 07:13:11 2015 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 49A2C1ACDB8 for ; Wed, 11 Mar 2015 07:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aau18IuEczfn for ; Wed, 11 Mar 2015 07:13:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D641ACDB9 for ; Wed, 11 Mar 2015 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2BED1bZ012785; Wed, 11 Mar 2015 15:13:01 +0100 (CET) Received: from alma.local (p5DCCC330.dip0.t-ipconnect.de [93.204.195.48]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3l2FcY2b4Vz2l1Y; Wed, 11 Mar 2015 15:13:01 +0100 (CET) Message-ID: <55004D6B.2080903@tzi.org> Date: Wed, 11 Mar 2015 15:12:59 +0100 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nat Sakimura References: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> <4E1F6AAD24975D4BA5B1680429673943A2E82259@TK5EX14MBXC292.redmond.corp.microsoft.com> <54FEB612.7030707@connect2id.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "jose@ietf.org" , Vladimir Dzhuvinov Subject: Re: [jose] COSE: what would change? 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, 11 Mar 2015 14:13:10 -0000 Nat Sakimura wrote: > We have something similar as well... > > 2015-03-10 18:14 GMT+09:00 Vladimir Dzhuvinov >: > > Arrays would be good. Perhaps even bit fields? Do you guys have some examples that we could look at? (CDDL just got support for bit fields, by the way; the current draft only has it for byte strings, the tool already also supports specifying them for uints.) GrĂĽĂźe, Carsten From nobody Wed Mar 11 09:23:47 2015 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 4D19B1ACDA3 for ; Wed, 11 Mar 2015 09:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-akUZOD3G5T for ; Wed, 11 Mar 2015 09:23:44 -0700 (PDT) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) by ietfa.amsl.com (Postfix) with ESMTP id C41921ACDA2 for ; Wed, 11 Mar 2015 09:23:33 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.115]) by p3plsmtpa07-02.prod.phx3.secureserver.net with id 2GPX1q0092Vi9sD01GPYnK; Wed, 11 Mar 2015 09:23:33 -0700 Message-ID: <55006C02.5060404@connect2id.com> Date: Wed, 11 Mar 2015 18:23:30 +0200 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Carsten Bormann , Nat Sakimura References: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> <4E1F6AAD24975D4BA5B1680429673943A2E82259@TK5EX14MBXC292.redmond.corp.microsoft.com> <54FEB612.7030707@connect2id.com> <55004D6B.2080903@tzi.org> In-Reply-To: <55004D6B.2080903@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] COSE: what would change? 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, 11 Mar 2015 16:23:46 -0000 This is the class that we use to compress JSON string arrays: https://gist.github.com/anonymous/ee61ff43d3fe76d8d7e0 For example the array ["apple","pear","orange","mango","fig"] to ["!Jg"] For that you would need a compression table like this: 0 : apple 1 : pear 2 : orange 3 : mango 4 : fig 5 : ... where the most frequent words should be at the top, and rarely used words at the bottom. Cheers, Vladimir On 11.03.2015 16:12, Carsten Bormann wrote: > Nat Sakimura wrote: >> We have something similar as well...=20 >> >> 2015-03-10 18:14 GMT+09:00 Vladimir Dzhuvinov > >: >> >> Arrays would be good. Perhaps even bit fields? > Do you guys have some examples that we could look at? > > (CDDL just got support for bit fields, by the way; the current draft > only has it for byte strings, the tool already also supports specifying= > them for uints.) > > Gr=C3=BC=C3=9Fe, Carsten --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com From nobody Wed Mar 11 09:38:51 2015 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 D46AD1A1A8E for ; Wed, 11 Mar 2015 09:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvjmL5hjoXW6 for ; Wed, 11 Mar 2015 09:38:47 -0700 (PDT) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0FD1A1A8A for ; Wed, 11 Mar 2015 09:38:47 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.115]) by p3plsmtpa07-07.prod.phx3.secureserver.net with id 2Gel1q00P2Vi9sD01GemSZ; Wed, 11 Mar 2015 09:38:47 -0700 Message-ID: <55006F95.5090807@connect2id.com> Date: Wed, 11 Mar 2015 18:38:45 +0200 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: jose@ietf.org References: <54F8466B.8060007@fh-koeln.de> In-Reply-To: <54F8466B.8060007@fh-koeln.de> Content-Type: multipart/alternative; boundary="------------020209050900050208000007" Archived-At: Subject: Re: [jose] Java-based JOSE implementation 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, 11 Mar 2015 16:38:49 -0000 This is a multi-part message in MIME format. --------------020209050900050208000007 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Thanks for sharing this. I see that you support JSON and compact serialisation, but what is flattened serialisation? Thanks, Vladimir On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: > Dear all, > > we developed an own JOSE implementation in Java, mainly because we > missed the JSON serialisation in almost all of the available libs. You > can grasp it here: > > http://jw-asterisk.realsoasecurity.de/ > > We are still doing some polishing, that is why the sources are still > lacking. Stay tuned, though, updates will follow soon... > > The documentation and especially the unit tests should help in taking > the first steps. > > Let us know what you think about it... > > BR, Luigi. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- Vladimir Dzhuvinov :: vladimir@connect2id.com --------------020209050900050208000007 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Thanks for sharing this.

I see that you support JSON and compact serialisation, but what is flattened serialisation?

Thanks,

Vladimir

On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
Dear all,

we developed an own JOSE implementation in Java, mainly because we
missed the JSON serialisation in almost all of the available libs. You
can grasp it here:

http://jw-asterisk.realsoasecurity.de/

We are still doing some polishing, that is why the sources are still
lacking. Stay tuned, though, updates will follow soon...

The documentation and especially the unit tests should help in taking
the first steps.

Let us know what you think about it...

BR, Luigi.



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

-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------020209050900050208000007-- From nobody Wed Mar 11 09:47:46 2015 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 8820F1A1A82 for ; Wed, 11 Mar 2015 09:47: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, 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 ib3QuW3hob3E for ; Wed, 11 Mar 2015 09:47:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42CE1A0181 for ; Wed, 11 Mar 2015 09:47:40 -0700 (PDT) Received: from BY2PR03CA052.namprd03.prod.outlook.com (10.141.249.25) by DM2PR0301MB0622.namprd03.prod.outlook.com (25.160.95.26) with Microsoft SMTP Server (TLS) id 15.1.112.16; Wed, 11 Mar 2015 16:47:18 +0000 Received: from BL2FFO11FD050.protection.gbl (2a01:111:f400:7c09::196) by BY2PR03CA052.outlook.office365.com (2a01:111:e400:2c5d::25) with Microsoft SMTP Server (TLS) id 15.1.112.16 via Frontend Transport; Wed, 11 Mar 2015 16:47:18 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD050.mail.protection.outlook.com (10.173.161.212) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Wed, 11 Mar 2015 16:47:18 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.148]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0224.003; Wed, 11 Mar 2015 16:46:49 +0000 From: Mike Jones To: Carl Wallace , Stephen Farrell Thread-Topic: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch Thread-Index: AQHQW/qIG3Fobl38T+ib6QLqsv0XzJ0Xekkg Date: Wed, 11 Mar 2015 16:46:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2F4A754@TK5EX14MBXC292.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/mixed; boundary="_005_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; 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; redhoundsoftware.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51914003)(199003)(189002)(15975445007)(102836002)(3380100001)(2900100001)(86362001)(104016003)(33656002)(5260100001)(55846006)(66066001)(2950100001)(2920100001)(19625215002)(4610100001)(92566002)(2656002)(87936001)(50986999)(16236675004)(106466001)(54356999)(4810100001)(86612001)(99936001)(512874002)(84326002)(77156002)(85806002)(568964001)(6806004)(62966003)(5890100001)(76176999)(19300405004)(106116001)(46102003)(19580395003)(16503001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0622; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0622; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR0301MB0622; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0622; X-Forefront-PRVS: 0512CC5201 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2015 16:47:18.6367 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]; Helo=[mail.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0622 Archived-At: Cc: Nat Sakimura , "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 16:47:44 -0000 --_005_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_" --_000_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY29tbWVudGFyeSwgQ2FybC4gIEkgd2FzIGd1ZXNzaW5nIHRoYXQgaW50 ZWdlcnMgd2l0aCB0aGUgaGlnaCBiaXQgc2V0IHdlcmUgcHJlZml4ZWQgYnkgYSB6ZXJvIGJ5dGUs IGFzIHlvdSBzYWlkLiAgVGhhdOKAmXMgZGlmZmVyZW50IHRoYW4gdGhlIHplcm8gYnl0ZSAodGhl IDIybmQgYnl0ZSBpbiB0aGUgYXR0YWNoZWQgUkZDIDcyNTAgZXhhbXBsZSkgdGhhdCBjb21lcyBi ZWZvcmUgdGhlIEFTTi4xIElOVEVHRVIgdGFnIGFuZCBsZW5ndGggZm9yIHRoZSBtb2R1bHVzLCB3 aGljaCBJIGZpbmQgdG8gYmUgbW9yZSBteXN0ZXJpb3VzLiAgU2VlIGJlbG934oCmDQoNCg0KPiDC tyAgICAgICAgSXMgdGhlcmUgYWx3YXlzIHRoZSBhcHBhcmVudGx5IHVudXNlZCB6ZXJvIGJ5dGUg aW4gdGhlIGtleSByZXByZXNlbnRhdGlvbiBvciBpZiBub3QsIHdoZW4gaXMgaXQgcHJlc2VudCBh bmQgYWJzZW50Pw0KDQo+IFRoZSBsZWFkaW5nIHplcm8gaXMgcHJlc2VudCBmb3IgYW55IGludGVn ZXIgdmFsdWUgd2l0aCB0aGUgaGlnaCBiaXQgc2V0LCB3aGljaCBpcyB0aGUgY2FzZSBmb3IgUlNB IGtleXMgYmVpbmcgZW5jb2RlZCBoZXJlLg0KDQpUaGlzIGlzbuKAmXQgYSBsZWFkaW5nIHplcm8g b2YgYW4gaW50ZWdlciDigJMgaXTigJlzIGEgemVybyBpbiB0aGUgZmlyc3QgYnl0ZSBvZiB0aGUg Yml0IGZpZWxkIHRoYXQgaG9sZHMgdGhlIGtleSB2YWx1ZSwgd2hpY2ggaXMgZm9sbG93ZWQgYnkg dHdvIEFTTi4xLWVuY29kZWQgaW50ZWdlcnMgZm9yIHRoZSBtb2R1bHVzIGFuZCBleHBvbmVudC4g IERvZXMgYW55b25lIGtub3cgd2h5IHRoaXMgemVybyBpcyBoZXJlPyAgQW5kIHdoZXRoZXIgaXQg aXMgYWx3YXlzIHRoZXJlPw0KDQoNCj4gwrcgICAgICAgIElzIHRoZXJlIGFsd2F5cyBhIGxlYWRp bmcgemVybyBieXRlIGluIHRoZSBSU0EgbW9kdWx1cyBvciBpZiBub3QsIHdoZW4gaXMgaXQgcHJl c2VudCBhbmQgYWJzZW50Pw0KDQo+IFNlZSBhYm92ZSwgZXhjZXB0IGluIHRoaXMgY2FzZSB0aGUg aGlnaCBiaXQgaXMgbm90IHNldCBzbyBubyBsZWFkaW5nIHplcm8uDQoNCkFzIEkgc3VybWlzZWQg 4oCTIHRoYW5rcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQo= --_000_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgY29tbWVu dGFyeSwgQ2FybC4mbmJzcDsgSSB3YXMgZ3Vlc3NpbmcgdGhhdCBpbnRlZ2VycyB3aXRoIHRoZSBo aWdoIGJpdCBzZXQgd2VyZSBwcmVmaXhlZCBieSBhIHplcm8gYnl0ZSwgYXMgeW91IHNhaWQuJm5i c3A7IFRoYXTigJlzIGRpZmZlcmVudCB0aGFuIHRoZSB6ZXJvIGJ5dGUgKHRoZSAyMjxzdXA+bmQ8 L3N1cD4gYnl0ZSBpbiB0aGUgYXR0YWNoZWQgUkZDDQogNzI1MCBleGFtcGxlKSB0aGF0IGNvbWVz IGJlZm9yZSB0aGUgQVNOLjEgSU5URUdFUiB0YWcgYW5kIGxlbmd0aCBmb3IgdGhlIG1vZHVsdXMs IHdoaWNoIEkgZmluZCB0byBiZSBtb3JlIG15c3RlcmlvdXMuICZuYnNwO1NlZSBiZWxvd+KApjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRE RiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFG NDk3RCI+Jmd0Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SXMgdGhlcmUgYWx3YXlzIHRoZSBh cHBhcmVudGx5IHVudXNlZCB6ZXJvIGJ5dGUgaW4gdGhlIGtleSByZXByZXNlbnRhdGlvbiBvciBp ZiBub3QsIHdoZW4gaXMgaXQgcHJlc2VudCBhbmQgYWJzZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jmd0 OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoZSBs ZWFkaW5nIHplcm8gaXMgcHJlc2VudCBmb3IgYW55IGludGVnZXIgdmFsdWUgd2l0aCB0aGUgaGln aCBiaXQgc2V0LCB3aGljaCBpcyB0aGUgY2FzZSBmb3IgUlNBIGtleXMgYmVpbmcgZW5jb2RlZCBo ZXJlLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBpc27igJl0IGEgbGVhZGluZyB6ZXJvIG9mIGFu IGludGVnZXIg4oCTIGl04oCZcyBhIHplcm8gaW4gdGhlIGZpcnN0IGJ5dGUgb2YgdGhlIGJpdCBm aWVsZCB0aGF0IGhvbGRzIHRoZSBrZXkgdmFsdWUsIHdoaWNoIGlzIGZvbGxvd2VkIGJ5IHR3byBB U04uMS1lbmNvZGVkIGludGVnZXJzIGZvciB0aGUgbW9kdWx1cyBhbmQgZXhwb25lbnQuJm5ic3A7 IERvZXMgYW55b25lIGtub3cNCiB3aHkgdGhpcyB6ZXJvIGlzIGhlcmU/Jm5ic3A7IEFuZCB3aGV0 aGVyIGl0IGlzIGFsd2F5cyB0aGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdp bi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SXMg dGhlcmUgYWx3YXlzIGEgbGVhZGluZyB6ZXJvIGJ5dGUgaW4gdGhlIFJTQSBtb2R1bHVzIG9yIGlm IG5vdCwgd2hlbiBpcyBpdCBwcmVzZW50IGFuZCBhYnNlbnQ/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4mZ3Q7 IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+U2VlIGFi b3ZlLCBleGNlcHQgaW4gdGhpcyBjYXNlIHRoZSBoaWdoIGJpdCBpcyBub3Qgc2V0IHNvIG5vIGxl YWRpbmcgemVyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgSSBzdXJtaXNlZCDigJMgdGhhbmtzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_-- --_005_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="RFC 7520 Appendix A.docx" Content-Description: RFC 7520 Appendix A.docx Content-Disposition: attachment; filename="RFC 7520 Appendix A.docx"; size=16226; creation-date="Tue, 10 Mar 2015 23:32:47 GMT"; modification-date="Tue, 10 Mar 2015 23:50:37 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQBouJUzWAEAABkFAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANSUQVPCMBCF7874Hzq52wAKOA6FizjDwYvieA7p ps2QJp3sqvDvjVSkVSiXXjxmM3nvm923mcw2hYnewaN2NmH9uMcisNKl2mYJe1k+XN2yCEnYVBhn IWFbQDabXl5MnsAICo8w1yVGQcViwnKi8o5zlDkUAmNXgg03yvlCUDj6jJdCrkUGfNDrjbiva7Bp QzNapAnzizT4L7dlcD6v7ZTSEu6dfCvA0hELToELgqDwGVDCdseq2I8DKOPHGa67ZEAgCt3FA8a+ 0oYw7hJBOUtLsTK1VvyU2iAGJyAKLb1DpyiWruDVGL7aP25OmCNtDeCrpnyuFEiq9+D3VRtH/wTH kbydz0QFVZvGjqTNftSlfR7C7Y226wPBd9LJOYOxBlK7zcmpMNwrOR4Mw5JWEX50adiM+YbAW3Ey vsN/xnvTJe8HrJ7/bFytuB80b3xo008AAAD//wMAUEsDBBQABgAIAAAAIQCZoyRt3AoAAJSbAAAR AAAAd29yZC9kb2N1bWVudC54bWzsXWtv47gV/V6g/4FQP3QXk4fkt411FjOOk3onzaaxp0WxXRSU RNlqZFGlpDieTv97Ly8lxY7jjLKZ5mHRQWhZpimRPPfcBynyhx9v5gG5ZiL2edg3rAPTICx0uOuH 077xaXKy3zFInNDQpQEPWd9Ystj48ej3v/th0XO5k85ZmBAoIox7i8jpG7MkiXqHh7EzY3MaH8x9 R/CYe8mBw+eH3PN8hx0uuHAPa6Zl4lEkuMPiGK43oOE1jY2suPlmaTxiIVzL42JOk/iAi+nhnIqr NNqH0iOa+LYf+MkSyjZbeTG8b6Qi7GU3tF/ckPxJT91Q9pb/QmzU4p7rql8eZy2AVzwULIB74GE8 86PbavzW0qCKs/yWrh+qxPU8yPMtIquxcb2iymX64FjQBXTFbYEbxd3TGK760TxQ7SD797ZX75Zo mQ9VJusRWURxD2VuYf2a+Z3MqR8Wxfy2plltXJCIp+D7VPA0Km4n8p9W2ii8KsqSgvmIOzNbKHmr VYsfVcCG6I5nNGIGmTu90TTkgtoB3NHCahCJSOMIyMLm7lK+R2TRA7JxL/uGCa92Z1A38lMXIHqm 2T1pmB+s4uQx82gaJJvZL1YyY8kXAt/GyTJgUOQ1DfrGOR9H1JGIPpRfCpVHnPAwiSEPjR0f+mHA U+EzQc7ZQl539j6MN8860EarGbHA+HN+pZqpLhF/HsiS8er5uYCG0/wcC2W+w+xe4D3K7gkyYMOs tcKrvOlFLzn6G08T0Bp7hCWEBgdk7TVGhSHcmEwEda7WvlMffrmgU0as1q+yJRLVHphG2Id5W2z2 +uVa8+T5qgISm/MrqfKggUUClfddaCEJ2ZDOQeL+eco/QHsrIOZ5h6Fb5FTI020sqWGbIM6WEROB H14Rge0rRm4TWcGPEy6WYCQhoYkce2uA/L/Iq8MDLi+HnCJZ8+Qk55r8bM4097FPmmeSRlbA1E+3 U5KUx8uTAWnXmuZd6SzaBuv5fC3wVJqFOkmzsheDMgA5iQSLmbhmxtEqNX2S7UMu6YJcpHbgO+Qj W8bED8nkbHx4DMlt5p/SkBEwYRt3G0iL1nbRkrpOs/tW5smbJ+ftVY5Hc0hxPI3AC3L9m/33SpB3 zKCy0ayyB/HbNa++bRUWPS9wBzMqFUB2NAEN1TdsNgXvJrMln5mPv3UV/TBOxITdbGPpP/39Ynh5 Njr/SHI/J+E8iA98lngYB5gl4PMJz5FKyyD/CIixIidEsnRxidzYBHP7+RTYt26wLZiIWUQFTVDH Q53RIXqxWm6YLWbhIuUWyTc2W95n3Ejer+nlXexp0AGrsp8rjVtj35Jfv+maJ0fgVg5v6DwCf36Y BSXXOjZXmTumA59q7cpmkUEF3TyZz3S/q6eb58HmeVbueCrkH3LwTsB5ZopG9kgyY2TGbkjM/p3C QAcj8YwvQunlnfjTVDDSJS6LHeHbLCZUs02uobfHC3K22Rm8jFP7X8xJVBAAYgCj0OMwBiZSJ5EA AUPSdxkCyWEi8WFMCywuEtFlwKl7oCFTHjKagavBwFngzMR3C9MapnVMG5g2MW1h2sa0g2lXS1R5 idoZEoauf7ePL/X22FSDJgfNzJ/OAviX40U4gjCHobcwoco/rJBeB+L5gqGgYrzxFUrLRm8tWRDw xdc6Sw7amDf19QGbV1i97XDbasHvvb0+mwqmXM5F78EKQ5d1rD1i3nS9Nb7SHfc88zK0sN0dD91t YTNdLWYyJvzM05+eJGZmS/fZa+izR+g0c91l09rshbRZSUNf2Y41Kg2RTkumjc7emtBVOk6zwV6l JOEVR0U3KlQeJ1snUUE450sBH68tQWS6mKJ9a2bpGqo0L7wQL5R2Ke/vbuja5o7bidqPxrkDb8pO rGtyeWN2IsQ+1vpMmxmrYVpnSXF630MxpLdkZZQym7ZGAWE8AAaL0MbQTvyrIGfBcAbaQ/BUnoWp temr6LDSZp8eSXipBwU3XLOypFmMJHR07OXNCZtZWzODtF/8Qn7x44XN0h33GnyOMqZybovIoJTj asfD2Do/pExrviXHo0x9HvI7YHqa9Ds8jGd2uhJAECCH1GYyrWPI3MbzXQiMmTdtPOM25LFV11DT UMsf1VFLPWx7yo0QmAP5RULKlNAxEV62J4/tmkwZQrClwus4XuNgTgsBV/c01DTUykINJtpKqDXV yIxiL4RXDY9rK7Br4XmAF+SvIyhbjoaahlpZqMFsbgk1BakuMlYHU4rga2PqKsAplYrq1UFl6tga ahpqZaEGjwxIqFHFZ6giG0pFojWmwGfieQ/z2EqZqlRDra+hVhZqXQU1ptgLIcUUjBSwkM/UJIgm nm9gTjXDpmVqVtNQKws1y1SshgByMK0hpLp43LSlZaZYrYuqs9GSZyw877U01DTUSkPNUlBDf7OD StNDSLWUNYawc9BKq6Fb0FVQw/OUaqhpqJWGWg2hpjgsAxnymYmwa6Ld1saUIZPZeL5Rl9wGdtta 7F3PHdnluSNPDeFadYSa60jodKlMHTyuK8BhaiG8VNgWRgiKPE5NQ02zWmlWayDU6qgQVeSshQ5B B1Wqi+rSUSkCTo0iePhtvaGhpqFWGmpNZaspywxBRpU1hsdNVJR1BFYbOU/5nmpcAdSuVqB6DDRb P/JrA1NWC6GmOMz0pHJUwdsGwquJTAbmP5w39aQIPQPpGZfQ3zp0v+PPqOjnHV6FmJV0TWCCJjwE pzVurnG3r4tRpalFVhvVqolBjjuKs9IRja/DQzdPZdaOy1fm7BWrAd+7ROO4WKLxwxIWZBxnK3xq zi3PuVqoqiFUE1gF12WwzR9ziS2F5YHlcL+D/fZu189NcZOUCwabP2nBKi9Yu/FMBzyEeZomcxqG f4zJ+/H5gZWhSJBf1tAAe6ht7qIEezLCjmuhM+Owz5tg3j6WsH+czmFXPPhFhfZXuq35WrMB/Rbt hs4NNMsb2hPu1++JHwQpLJUMCyLHuEJysWzyHqHx3brq3YC2b5a0M4Rxd311y9RLZBdDHNrNKZri vp3rvt48OyMmP3teDFtpkjMWTpMZKNpj3IUgkhsKa96soKGlFr9+UqpxU0HcAHWY8A/Lpbyzmt0e HIyHf/k0PB8MyX80IKoJCLXNAqm9s+oSEBoSFTc2AAFqtw0CmECOgDM/f/hpOJiQ0fHwfDI6GQ0v yV9pkDLynUVqpNMwiWXVm40useTf95pKqkklkj2yl6KS/NPFx8GY/AEmUoqYwmZ9YqlNV9xto5Iw gelC6lV7Z2YwOf90dqZJo5JoyClCvmdo+K+GQiWhYKk9vcA3aVgIhQ+jCRlPLkfnp3sE9mOkUZwG GD3WzkoRGqtQGAwM0mxnOPBV2hlZaAd2EOebd1WSNWrKWwHWqOXeCiGj88nwdMVLMWsNYvuJ9kwq yRtWU+0ZKT3aLMgB1sYdjLSazXpbA6SSAFk1QnMrlBBth2owaJek0sbFKjEgFDQnPIIT9IzRaswY lVKSzcO2IKR3LCeP+uGUcK/kpOx7Az4xc5ILkc9y6xsmvNqdQV3OB7x/4ls0HX+GLxd9w6rVGiZO HITjJgxQyMdmF71o+mcqS0x4BOcbKouQiyPcfrR5kvD57eeAeSvfzhh1GUxRbIOvBQV5nMNk1+Lj NE3wY3Y5hwfSN4vVRpryJ3gXLndOhe/CN4Efsgs/cWZ9o97Cb0FkVL2PZJvY3F3iAfwkncPGzEf/ AwAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnht bOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2Fb gRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt 3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyK cCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUC HWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9 A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8b c/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDX ahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BU tb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG //rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI 0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH 8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6 gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeR HOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4 QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/ gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+d t/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G 9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpD iK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJ C9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrg eIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWv S91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEK VFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf 4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7 Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqn IRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuW QaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK 0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H 0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2 ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQU AAYACAAAACEAX5ARw3EDAADLCAAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFbbbts4EH1fYP9B0PM6 kmwnaYU4xdZZ76aI26JKP4CSaJsIbxhSVtyv75AUoxpxg6DF+sXknLnfqKt3j4InewqGKblIi7M8 TahsVMvkdpF+vV9N3qSJsUS2hCtJF+mBmvTd9Z9/XPWlodYim0lQhTSlaBbpzlpdZplpdlQQc6Y0 lQhuFAhi8QrbTBB46PSkUUITy2rGmT1k0zy/SAc1apF2IMtBxUSwBpRRG+tESrXZsIYOf1ECXmM3 SN6ophNUWm8xA8rRByXNjmkTtYlf1YYh7qKS/UtB7AWPfH2Rv8Q5hNsraJ8kXuOeE9CgGmoMFkjw EK4gTD6pKebPFD2l+gxTnQXbmVOF4kXuT6Pnhj+TP1HtUMU7VgOBUGZsAOeFaMrbrVRAao5N1Rfz 9Bo76ptSIulLTaHBImE7TvM0c0BLN6Tj9p7UlVUaWfYE7V9GuNkRII2lUGnSYMRLJS0oHvla9VHZ JXYcYEKCwtB/TnU4VaGXUUISgR4F6tCfa9XSFKEO2LOgf5o0J+C9xNh8DKcNKZw9YC3F0Dit7IHT FTpfsW/0b9l+6Ixl2PG+S3/Dg5ccoNJZ/oSTen/QdEWJ7TBN/5MxX4kVZ3rNABTcyhbr/LvGslhE V05cZK2Jhy9K2ViGHH+Xb5azkAvH9ipkOl1eFidlprPl29UpZHaB0D+nkMt5cXM+tMOxB29X8/y9 t4PRDDGI0q2Uz3B9FU6uMRIRmmpJRA2MJGu3dLC9RFnDw3smI15TXLr0R6Tq6ghOJgEwgnC+wsmJ gJ82UbbM6Bu68Wr5msB21DtwwEkqTumHJ11ugin8C6rTwVoPRIeCR3PFfD7oY9LeMRHppqurKCVx cfwAdbL9tAenMBvT05cW3xs/OHdEbmNdqZx8rRwr9geHyr1JdE20xgWBLPW2WKScbXe2cM1u8dbi 2+Qv9XY6YFOP4c1h/kIaFxlyDwfHEI7INRxG2izSZiMNN2/gm4+080g7H2kXkYZvY1/ucDqBM/mA KygeHX2jOFc9bf+LxEX6jBSSYHZEU6yr26Q4Iqr0hGG1mmRf0kfcubRlFp98zVpBHnEF59MLJz5w c3JQnT3idZhj1kfUpCWWoLgv1ZEwlg6/HY59cRu+YdiO1UHU4+I+C45zZmxFNe54qwBD9mv1L695 /Aq5/g4AAP//AwBQSwMEFAAGAAgAAAAhAHMObQeCAQAAUAMAABQAAAB3b3JkL3dlYlNldHRpbmdz LnhtbJRTy27CMBC8V+o/RL6DE4pQiQhICFFVqqqqjw9wHIdYtb2WbZLC13dJePVxgJPXuzPj3Z1k MvvSKqqF8xJMRpJ+TCJhOBTSrDLy8b7s3ZPIB2YKpsCIjGyEJ7Pp7c2kSRuRv4kQEOkjVDE+1Twj VQg2pdTzSmjm+2CFwWIJTrOAV7eimrnPte1x0JYFmUslw4YO4nhE9jLuEhUoS8nFAvhaCxNaPnVC oSIYX0nrD2rNJWoNuMI64MJ7nEerTk8zaY4yyfCPkJbcgYcy9HEY2nVEd1JIT+I20opEmqePKwOO 5Qo32CRDMsX1FbL2+zNqUllkZDyOk7vhOBm19RyKzULWWKuZQmsI3aFxeU+iDMfsID7mX+Wq+rfw DvaAP6HnEALoX3nsaV643TvhxDFoPEGg32YEPw8MLOM4SBtzUIB+sXWArhF11t11zPxHR9dx3fns 11Bpa0Q7dBdOJ93ZegM2SC23Yglu7qDxwrUmMKWgeXl+wAuCz/6D6TcAAAD//wMAUEsDBBQABgAI AAAAIQA98saZ9gkAAFlJAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzcXFtT47gSfj9V 5z+4/M6QGwmhNrPFMMsOVcwsO0Dts+MoxIVt+dgOGebXb6slK45txS1s5uHMwySRpf76pq8VUPPb 7z+i0HlhaRbweOEOPwxch8U+XwXx08J9fLg+OXedLPfilRfymC3cV5a5v3/8739+211k+WvIMgcE xNnFLvEX7ibPk4vT08zfsMjLPkSBn/KMr/MPPo9O+Xod+Ox0x9PV6WgwHOC7JOU+yzJAu/LiFy9z lbioLo0nLAasNU8jL88+8PTpNPLS521yAtITLw+WQRjkryB7MC3E8IW7TeMLpdCJVkgsuZAKqZdi RVqzogFXrvzM/W3E4hwRT1MWgg48zjZBsjfjrdLAxE2h0ssxI16isJi3S4aTGp42mRKDz6m3g1Ds BdbENThjJRdFofSDiO8+qlWJw8ExY1REhAitA0WFQ8xCk8gLYi3mba4pOxf2Q5f8/jPl20SrkwTd pN3Ez1qW2JYWmg2muPPKpmVWAmpb937jJcx1Iv/i5inmqbcMQaPdcOKIjHQ/AlWsuP+Zrb1tmGfi Y3qXqo/qE75c8zjPnN2Fl/lB8AAUAlKiAAR+uYyzwIUnzMvyyyzwGh9uxKzGJ36Wl6R9ClaBeyoQ s58g88ULF+5oVIxcCQ0OxkIvfirGWHzyeF/WZOHqoSXIXbheenJ/KYSdopnFa8nc5MB4+ISqJJ4P Ow9wvHXOgISAxQROGIjojmbAaPLD961wrrfNuQJBAQBWFgsfKx4HbgKmupeMDU/Z+pb7z2x1n8OD hYtYMPh4c5cGPAUaXbjzucCEwXsWBV+C1YqJAqHGHuNNsGL/bFj8mLHVfvzva6RnJdHn2zgH9acz zIIwW/3xw2eJoEkQHXsiwt/EAuAwCEcJBxXaBntt5EAFFQf/V0AOZQwbUTbMEyXNQf2PAqHV285A I2FR2QCUa6XruLuISXcRZ91FYPJ288WsuxZwkOkaEZkbpaykBzXnvky+sh/G8yMpK1bUsqh1RS1p WlfUcqR1RS0lWlfUMqB1RS3grStq8W1dUQvn0RW+h8RVzaIxeoO0sR+CPIQ62cJ0w45Up0qNc+el 3lPqJRtHFNaq2sfI8n67zGmqIp2+nSzv85SL42aLR6A6i637Zk7+I0o2XhbAqbwNqKPrH8TRx/kz DeD42gJ1JpOvZhMeTBpL2F3o+WzDwxVLnQf2Q0bUYv037tzLU0arch3Dehs8bXIHToWi5LaCTQ1O N3tCyr8NMvTB0Wo+NZjSJpwUw6khL83Cv7JVsI0K1xBOI1PJ5xZhrkCgisddNBEhqu+uVitEACgm yHJhbwLKJ+gvi4u9fBFjiv6yFL1RPkF/WbjeKB/z43h8rZnmM/xYxSFtr5n13r3iIU/X27DYA630 MLPewRqCZoL1JtbySSQxs97BB/TpXPo+fHOj5Kl1LPY8aoFiHQ6JgpuNbot1UCq0N7SwyDpAFayR BVY3rrUAsibd7+wlED8Eti0GyNL6rNm6nccGD0AJIp2h/97yvP0MPTJwHhXlJoYfl2TMoaGNDTuP iqbySdY7ixh3K3wWQN0qoAVQt1JoAWTID/OZR9dEOkj34miBZU3Luoph2pGZeWbNzBrIrgT0VDcJ 5y/D7jXnQr1uElCsA1SvmwQU6+hUapmumwSs3uomActQNcwxKnOqjVHWdbMMpE8CBIv6IW8CUD/k TQDqh7wJQN3Jux2kP/ImYFlzg+bUMnkTgHCKzVd9DVQmbwKQNTdItlM/MyrqHko5/uW2B/ImoFgH qE7eBBTr6JjIm4CFU2wyoYKlqY6A1Q95E4D6IW8CUD/kTQDqh7wJQP2QNwGoO3m3g/RH3gQsa27Q nFombwKQNT1ooDJ5E4Bwig03NJI37vp3J28CinWA6uRNQLGOToVQ9SGVgGUdoAqWJm8CFk6xSQaF hcltY1Q/5E2wqB/yJgD1Q94EoH7ImwDUnbzbQfojbwKWNTdoTi2TNwHImh40UJm8CUDW3NBI3rgZ 3528CSjWAaqTNwHFOjoVQtU8R8CyDlAFS5M3AQvzpTN5E4BwyluBbCzqh7wJFvVD3gSgfsibANSd vNtB+iNvApY1N2hOLZM3AciaHjRQmbwJQNbc0EjeuEfenbwJKNYBqpM3AcU6OhVC1eRNwLIOUAVL Ux0Bqx/yJgBhYnYmbwIQTnkDEO4imzD1Q94Ei/ohbwJQd/JuB+mPvAlY1tygObVM3gQga3rQQGXy JgBZc4O4Zwv3RcnXU4eGJKDeMyhuNZABR4YgUQGVgd/ZmqXQVcjab4d0BCwstEA0pAfVxE+cPzu0 i91jQ4KQoYJlGHC80v2Kt3RKjQjj2ZFOgoe/rpwvsgGmtg5T6vDmDXQPlduFsD1JNA6BnvlrAi07 SXGzXEiDBiHR16VagLAn9AYaglRbj1gs+nxgIjZVqWH8va1ChfeAiAtboLRwZcwIu4rK4os2H9XO tfSgOekv0WtUA4fGqudivBB3tfFS6cZ9k0YxR3Vq7HWG9q4M7o8q0QP4Nzu/GsvltaauJYO2VfDc UHZ1yY+X0MSVyRvZynuq90vNwk/1SbIlDH/vJd6qhrD8VjTHSXi+zcWT25ewUA9v+8smMeFj6L/D l4OOu4V7xbdpALfLv7GdiGzRbbdwH4IIGn1h2PnOIw+viGG3XW2JD52EZSkY56X8/yrD11LT3USq m/0sNd3hGGiKKprzwodQeT50yh1JQdUIoe+mYRtENSEN3RKoaj0LVNfE/mwt5x3c3YUhs9656BA4 ojN2EBzdOw5OkZ6rKwhNe9LLupeuWUPYystQZgG8uYlFIu9U157c5KsfnhQFz69YGH71MGdynpin hmydy6fDAZ6MKqKWPM95ZF6fYuMAatIkANxaVkZ+FEaY/R1voyVLVRuCkarEiaLGJdAvgePSgZpr QXskE6qnzbod5LC/zcA12KBZpdIDeqrmr3rojJw9e1Vor3EfoFVNJGjMLPnATHr/Z6SyLzZQ81Lh qVqGfNFP0Jtkt3fZtq3+98UF+yJJRVm6vlYhLQbFX1sAEgKdITdbePag1O9d8vD19i4VNQ3+TkHO VnXPwATnYEaTh8qHgYNUrIjfZ/b7eE6Va+Bm7E6H18JVgtAEWyccCtt8OJWeNE0Yno/VwcM0YzSb nB+XMZ5OVVk0yZicnQ+OyzibzFs0nU6GLZrOxqMWTc9HkxZNwWEtmsJJB1rbMTdM5g4H83mLrsPh HMrNcSkjULdlyng2aVN3Mj1DdUXpUdmiTnCQJOr0pk9m0PgOAuGBOIw19+3/6qPYOxy+jhWupn1c K2BVquhcyCqoMupk5mgl2PTXnJp/baieUvZaY3EcbCJu84nC5D3zKai5wnzjRa9qNV9KbayoWj2w 6pBu/qo2v54MPqlZta9qb9jFe+OKd9nHfwEAAP//AwBQSwMEFAAGAAgAAAAhAEQVyeBNAQAAgQIA ABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIySUUvDMBSF3wX/Q8l7m7RlIqHtQGUP4kBwovgWkrstrElDEtft35u2s7bog4/JOffLObctlidV R0ewTja6RGlCUASaN0LqXYleN6v4FkXOMy1Y3Wgo0RkcWlbXVwU3lDcWnm1jwHoJLgok7Sg3Jdp7 byjGju9BMZcEhw7itrGK+XC0O2wYP7Ad4IyQG6zAM8E8wx0wNiMRXZCCj0jzaeseIDiGGhRo73Ca pPjH68Eq9+dAr0ycSvqzCZ0ucadswQdxdJ+cHI1t2yZt3scI+VP8vn566avGUne74oCqQnDKLTDf 2GotDxA9hvW5Ak+uuxXWzPl12PZWgrg7z5y/1W7AwlF236rKCzw9hvf6esOjIKIQmA71vpW3/P5h s0JVRtJFTPI4JZssp3lGCfnogs3muwLDhbrE+zdxQebEb0DVJ57/NNUXAAAA//8DAFBLAwQUAAYA CAAAACEAE9yLl28JAABoRgAADwAAAHdvcmQvc3R5bGVzLnhtbNxbS3PbNhC+d6b/gcN7oqclyxMl 4zh14xnHcSJ7eqYoyOKEJFSSiu38+i4WIEWRArEw6RzaQyWCwH77wreQg3334SkKnZ8sSQMez93B 277rsNjnqyB+mLv3d5dvTl0nzbx45YU8ZnP3maXuh/d//vHu8SzNnkOWOiAgTs8if+5usmx71uul /oZFXvqWb1kML9c8ibwMHpOHXuQlP3bbNz6Ptl4WLIMwyJ57w35/4ioxCUUKX68Dn33i/i5icYbr ewkLQSKP002wTXNpjxRpjzxZbRPuszQFo6NQyou8IC7EDMY1QVHgJzzl6+wtGNOTGvWEKFg+6OO3 KHSdyD+7eoh54i1DcN7jYOy+B8+tuP+Jrb1dmKXiMblN1KN6wo9LHmep83jmpX4Q3IFLQUAUgKzP 53EauPCGeWl2ngbe0ZcbMevoGz/NStI+BqvA7QnE9BfI/OmFc3c4zEcuhAYHY6EXP+RjLH5zvyhr MneLoSXInbte8mZxLoT10Mz8s2Tu9sB4eEJVtp4PwQAcb50xSArIEYETBiIHh1PIF/nwfSf86u0y rkBQAICVxcJjxeOQK5A5C5nA8Jatr7n/g60WGbyYu4gFg/dXt0nAE0jSuTubCUwYXLAo+BysVkzs FzV2H2+CFftnw+L7lK32498uMfmVRJ/v4gzUn0wxC8J09deTz7YibUF07IkI34gFkDgQjhIOKrQL 9trIgQoqDv6bQw5kDI+ibJgndriD+jcCodW71kBDYVHZAJRrpeuovYhxexEn7UVg8rbzxbS9FsDr bSMic6OUlfSgZtyXyVf2w2jWkLJiRS2LjCtqSWNcUcsR44paShhX1DLAuKIWcOOKWnyNK2rhbFzh e0hc1SwaoTdIG/suyEIm1jcS0KAl1alS49x6ifeQeNuNIwprVe0mslzslhlNVaTTl5PlIkt4/GD0 CFRnsXVfzMl/RduNlwZwSjK4ftjS9Xfi1OP8nQQrI9SJTL6aTXgwOVrCbkPPZxserlji3LEnGVGL 9TfcWchThlG5lmG9Dh42mbPYYMk1gk00Ttd7Qsq/DlL0QeNmmmhMMQknxXCiyUu98C9sFeyi3DWE 08hE8rlFmCsQqGKzi8YiRPXdZbRCBIBigiwX9iagfIL+srjYyxcxpugvS9EL5RP0l4XrhfIxP5rj a800n+BHq0PaXlPrvXvBQ56sd2G+B4z0MLXewQUEzQTrTVzIJ5HE1HoHH9Cnc+778MuNkqfWsdjz qAWKdTgkCm42ui3WQanQ3sDCIusAVbCGFljtuNYCyJp0v7OfgfibmG0xQJYuzprG7TzSeABKEOkM /W3HM/MZeqjhPCrKVQx/LkmZQ0MbaXYeFU3lk6x3FjFuV/gsgNpVQAugdqXQAkiTH/ozT1ET6SDt i6MFljUtF1UM047MzFNrZi6A7EpAR3WTcP7S7F59LtTrJgHFOkD1uklAsY5OpZYVdZOA1VndJGBp qoY+RmVOtTHKum6WgYqTAMGibsibANQNeROAuiFvAlB78jaDdEfeBCxrbig4tUzeBCCcYvNTvwAq kzcByJobJNupvxnldQ+lNP+47YC8CSjWAaqTNwHFOjo68iZg4RSbTKhgFVRHwOqGvAlA3ZA3Aagb 8iYAdUPeBKBuyJsA1J68zSDdkTcBy5obCk4tkzcByJoeCqAyeROAcIoNNxwlb9z1r07eBBTrANXJ m4BiHZ0KoRaHVAKWdYAqWAV5E7Bwik0yKCxMbhujuiFvgkXdkDcBqBvyJgB1Q94EoPbkbQbpjrwJ WNbcUHBqmbwJQNb0UACVyZsAZM0NR8kbN+OrkzcBxTpAdfImoFhHp0KoBc8RsKwDVMEqyJuAhfnS mrwJQDjlpUA2FnVD3gSLuiFvAlA35E0Aak/eZpDuyJuAZc0NBaeWyZsAZE0PBVCZvAlA1txwlLxx j7w6eRNQrANUJ28CinV0KoRakDcByzpAFayC6ghY3ZA3AQgTszV5E4BwyguAcBfZhKkb8iZY1A15 E4Dak7cZpDvyJmBZc0PBqWXyJgBZ00MBVCZvApA1N4h7tnBflHw9daBJAuo9g/xWAxlwqAkSFVAZ +J2tWQJNVsx8O6QlYG6hBaImPagmfuT8h0O72D3SJAgZKliGAccr3c94S6fUiDCaNnQS3H29cD7L BpjaOkypw5s30D1UbhfC9iTROAR6Zs9baNnZ5jfLhTRoEBJ9XaoFCFvkrqAhSLX1iMWizwcmYlOV GsZ/t1Wo8B0QcaEBqhCujBliV1FZfN7mo9q5lh40J30VvUY1cGis+pGP5+IuNl4i3bhv0sjnqE6N vc7Q3pXC/VElug//TU8vRnJ5ralryaApEDw3kF1d8vEcmrhSeSNbeU/1fqlZ+FSfJFvC8N+9xFfV EJZdi+Y4Cc93mXhz/TPM1cPb/rJJTPgY+u/w46Djbu5e8F0SwO3yG/YoIpt3283duyCCvkcYdr7z yMMrYthtV1vip4dDGOel/P9Fip+lpruxVDf9VWq6wzHQFFXU54UPofJ86JRrSEHVCFHcTcM2iGpC arolUNV6Fqiuif3ZWs47uLsLQ3q9M9Eh0KAzdhA07h0Hp0jP1RWEpj3p5aKX7riGsJWXocwC+HIV i0SG5lHMKrnJV0+eFAXvL1gYfvEwZzK+1U8N2TqTbwd9PBlVRC15lvFIvz7BxgHU5JgAcGtZGfko jND7O95FS5ZA51+Dz2+4OFHUuAT6JXBcOrDgWtAeyYTqab1uBzns71JwDTZoVqn0gJ6q+ateOkNn z14V2ju6D9CqYySozSz5Qk96/zNS2RcbqHmJ8FQtQz4Xb9CbZLe32bZG//vign2epKIsXV6qkOaD ousbSAh0htw08OxBqd+75O7L9W0iaho0umdsVfcMTHAOZhzzUPkwcJCKFfH7zH4dz6lyDdyM3enw mbtKEJpgji2HwjYbTKQndRMGpyN18NDNGE7Hp80yRpOJKos6GeOT036zjJPxzKDpZDwwaDodDQ2a ng7HBk3BYQZN4aQDre2YGzpzB/3ZzKDrYDCDctMsZQjqGqaMpmOTuuPJCaorSo/KFnWCgyRRp7fi ZAaN7yAQXojD2PG+/d99FHuFw1dT4Tq2j2sFrEoVrQtZBVVGncwcRoJNfs+p+feG6iFhzzUWx8Fj xK0/Uei8pz8FHa8wNzzvVa3mS6mNFVWrB1Yd0vU/1WaX4/5HNav2U+0Fu3hvXP4tff8fAAAA//8D AFBLAwQUAAYACAAAACEAyuVY+e8BAACuBQAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbLST3Y7aMBCF 7yv1HSLfL3FC9odow2pFi9SbXlTbBzCOQ6z6J/IYsrx9J3bIXgAqtGqQonDGPpr5dOb55V2rZC8c SGsqks0oSYThtpZmW5Gfb+u7J5KAZ6ZmyhpRkYMA8rL8/Om5LxtrPCR430CpeUVa77syTYG3QjOY 2U4YLDbWaebxr9ummrlfu+6OW90xLzdSSX9Ic0ofyGjjrnGxTSO5+GL5Tgvjw/3UCYWO1kArOzi6 9de49dbVnbNcAODMWkU/zaSZbLLixEhL7izYxs9wmDR2lA5WeD2j4Usrkmheftsa69hGIbs+K8hy BJf0pWEaxRVTcuNkKHTMWBAZ1vZMVYTmdE3v8T38Cjof3iQdHHjLHAg/HaRRbpiW6nBUoZcAsdBJ z9ujvmdODg3FEsgtFnawoRX5SvHJ12sSlawiBQqvq0nJsan4ZOOZ+aRgcrCx4BOOZIvggwr6jLdC n2mMzgmJN6kFJN9Fn/ywmpkLRHL6gCTukcdAZn4TERd8A8EbiOSv0/w4yQpHeXwqjvN/EFn8mUj0 uZ7Iyu6cFG5gcoHGIxJYhHwMNIqbaGhbC2fOBKSR76I+n46zLObj5P+XBdO4JuwChyENMRVDOm7b k79Lxeme0GLKyQeJsBW4Xf+yJ+PCwPI3AAAA//8DAFBLAwQUAAYACAAAACEAIMSRJe4BAAD1AwAA EAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACc U8tu2zAQvBfoPwi6x7SdxE2MNYPCQZFD2xiwkpxZamUTpUiCZIS4X9+lFMt021N12peGw5kl3L21 uujQB2XNqpxNpmWBRtpamd2qfKq+XNyURYjC1EJbg6vygKG84x8/wMZbhz4qDAVBmLAq9zG6JWNB 7rEVYUJtQ53G+lZESv2O2aZREu+tfG3RRDafThcM3yKaGusLNwKWA+Kyi/8LWluZ+IXn6uCIMIcK W6dFRP490dGT2sYW2FiFykahK9Uin91QfcxgI3YY+AzYEMCL9XXgl7efgA0hrPfCCxlJQj6fLy6B ZQX47JxWUkRSl39T0ttgm1g89joUCQBYPgKkzRblq1fxwKfA8hS+KpOoEL8hIm5e7Lxw+8CvE8Ex g60UGtekAG+EDgjsVIAHFMndjVDEGLq47FBG64ugfpG/87L4IQIm3VZlJ7wSJpJ+aWxI+li7ED2v VNSETb0h78N8LI/VVVKRZik4H0zFgQM1ztn1J4THhu4W/0F2lpPtOQxUMzpZOJ7xB+ratk6YQ+bP 2npnfe8a2fneTvr/DE+usvdpkd6FPS9my/Ci4n7rhCTL5otr8ue0FlkLtrQ9WJPPR8BTAR7IBK/T qfSv2WF9nPm7kRbteXjFfHY1mdLXb9axRusxPi/+GwAA//8DAFBLAQItABQABgAIAAAAIQAJJIeC gQEAAI4FAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAAugMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAGi4lTNYAQAAGQUAABwAAAAAAAAAAAAAAAAA3gYAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1s LnJlbHNQSwECLQAUAAYACAAAACEAmaMkbdwKAACUmwAAEQAAAAAAAAAAAAAAAAB4CQAAd29yZC9k b2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAACDFAAA d29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAF+QEcNxAwAAywgAABEAAAAAAAAA AAAAAAAAXhsAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHMObQeCAQAAUAMAABQA AAAAAAAAAAAAAAAA/h4AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAD3yxpn2 CQAAWUkAABoAAAAAAAAAAAAAAAAAsiAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1sUEsBAi0A FAAGAAgAAAAhAEQVyeBNAQAAgQIAABEAAAAAAAAAAAAAAAAA4CoAAGRvY1Byb3BzL2NvcmUueG1s UEsBAi0AFAAGAAgAAAAhABPci5dvCQAAaEYAAA8AAAAAAAAAAAAAAAAAZC0AAHdvcmQvc3R5bGVz LnhtbFBLAQItABQABgAIAAAAIQDK5Vj57wEAAK4FAAASAAAAAAAAAAAAAAAAAAA3AAB3b3JkL2Zv bnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAIMSRJe4BAAD1AwAAEAAAAAAAAAAAAAAAAAAfOQAA ZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAkDAABDPAAAAAA= --_005_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="RFC 7250 Appendix A.docx" Content-Description: RFC 7250 Appendix A.docx Content-Disposition: attachment; filename="RFC 7250 Appendix A.docx"; size=16226; creation-date="Tue, 10 Mar 2015 23:32:47 GMT"; modification-date="Tue, 10 Mar 2015 23:50:37 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQBouJUzWAEAABkFAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANSUQVPCMBCF7874Hzq52wAKOA6FizjDwYvieA7p ps2QJp3sqvDvjVSkVSiXXjxmM3nvm923mcw2hYnewaN2NmH9uMcisNKl2mYJe1k+XN2yCEnYVBhn IWFbQDabXl5MnsAICo8w1yVGQcViwnKi8o5zlDkUAmNXgg03yvlCUDj6jJdCrkUGfNDrjbiva7Bp QzNapAnzizT4L7dlcD6v7ZTSEu6dfCvA0hELToELgqDwGVDCdseq2I8DKOPHGa67ZEAgCt3FA8a+ 0oYw7hJBOUtLsTK1VvyU2iAGJyAKLb1DpyiWruDVGL7aP25OmCNtDeCrpnyuFEiq9+D3VRtH/wTH kbydz0QFVZvGjqTNftSlfR7C7Y226wPBd9LJOYOxBlK7zcmpMNwrOR4Mw5JWEX50adiM+YbAW3Ey vsN/xnvTJe8HrJ7/bFytuB80b3xo008AAAD//wMAUEsDBBQABgAIAAAAIQCZoyRt3AoAAJSbAAAR AAAAd29yZC9kb2N1bWVudC54bWzsXWtv47gV/V6g/4FQP3QXk4fkt411FjOOk3onzaaxp0WxXRSU RNlqZFGlpDieTv97Ly8lxY7jjLKZ5mHRQWhZpimRPPfcBynyhx9v5gG5ZiL2edg3rAPTICx0uOuH 077xaXKy3zFInNDQpQEPWd9Ystj48ej3v/th0XO5k85ZmBAoIox7i8jpG7MkiXqHh7EzY3MaH8x9 R/CYe8mBw+eH3PN8hx0uuHAPa6Zl4lEkuMPiGK43oOE1jY2suPlmaTxiIVzL42JOk/iAi+nhnIqr NNqH0iOa+LYf+MkSyjZbeTG8b6Qi7GU3tF/ckPxJT91Q9pb/QmzU4p7rql8eZy2AVzwULIB74GE8 86PbavzW0qCKs/yWrh+qxPU8yPMtIquxcb2iymX64FjQBXTFbYEbxd3TGK760TxQ7SD797ZX75Zo mQ9VJusRWURxD2VuYf2a+Z3MqR8Wxfy2plltXJCIp+D7VPA0Km4n8p9W2ii8KsqSgvmIOzNbKHmr VYsfVcCG6I5nNGIGmTu90TTkgtoB3NHCahCJSOMIyMLm7lK+R2TRA7JxL/uGCa92Z1A38lMXIHqm 2T1pmB+s4uQx82gaJJvZL1YyY8kXAt/GyTJgUOQ1DfrGOR9H1JGIPpRfCpVHnPAwiSEPjR0f+mHA U+EzQc7ZQl539j6MN8860EarGbHA+HN+pZqpLhF/HsiS8er5uYCG0/wcC2W+w+xe4D3K7gkyYMOs tcKrvOlFLzn6G08T0Bp7hCWEBgdk7TVGhSHcmEwEda7WvlMffrmgU0as1q+yJRLVHphG2Id5W2z2 +uVa8+T5qgISm/MrqfKggUUClfddaCEJ2ZDOQeL+eco/QHsrIOZ5h6Fb5FTI020sqWGbIM6WEROB H14Rge0rRm4TWcGPEy6WYCQhoYkce2uA/L/Iq8MDLi+HnCJZ8+Qk55r8bM4097FPmmeSRlbA1E+3 U5KUx8uTAWnXmuZd6SzaBuv5fC3wVJqFOkmzsheDMgA5iQSLmbhmxtEqNX2S7UMu6YJcpHbgO+Qj W8bED8nkbHx4DMlt5p/SkBEwYRt3G0iL1nbRkrpOs/tW5smbJ+ftVY5Hc0hxPI3AC3L9m/33SpB3 zKCy0ayyB/HbNa++bRUWPS9wBzMqFUB2NAEN1TdsNgXvJrMln5mPv3UV/TBOxITdbGPpP/39Ynh5 Njr/SHI/J+E8iA98lngYB5gl4PMJz5FKyyD/CIixIidEsnRxidzYBHP7+RTYt26wLZiIWUQFTVDH Q53RIXqxWm6YLWbhIuUWyTc2W95n3Ejer+nlXexp0AGrsp8rjVtj35Jfv+maJ0fgVg5v6DwCf36Y BSXXOjZXmTumA59q7cpmkUEF3TyZz3S/q6eb58HmeVbueCrkH3LwTsB5ZopG9kgyY2TGbkjM/p3C QAcj8YwvQunlnfjTVDDSJS6LHeHbLCZUs02uobfHC3K22Rm8jFP7X8xJVBAAYgCj0OMwBiZSJ5EA AUPSdxkCyWEi8WFMCywuEtFlwKl7oCFTHjKagavBwFngzMR3C9MapnVMG5g2MW1h2sa0g2lXS1R5 idoZEoauf7ePL/X22FSDJgfNzJ/OAviX40U4gjCHobcwoco/rJBeB+L5gqGgYrzxFUrLRm8tWRDw xdc6Sw7amDf19QGbV1i97XDbasHvvb0+mwqmXM5F78EKQ5d1rD1i3nS9Nb7SHfc88zK0sN0dD91t YTNdLWYyJvzM05+eJGZmS/fZa+izR+g0c91l09rshbRZSUNf2Y41Kg2RTkumjc7emtBVOk6zwV6l JOEVR0U3KlQeJ1snUUE450sBH68tQWS6mKJ9a2bpGqo0L7wQL5R2Ke/vbuja5o7bidqPxrkDb8pO rGtyeWN2IsQ+1vpMmxmrYVpnSXF630MxpLdkZZQym7ZGAWE8AAaL0MbQTvyrIGfBcAbaQ/BUnoWp temr6LDSZp8eSXipBwU3XLOypFmMJHR07OXNCZtZWzODtF/8Qn7x44XN0h33GnyOMqZybovIoJTj asfD2Do/pExrviXHo0x9HvI7YHqa9Ds8jGd2uhJAECCH1GYyrWPI3MbzXQiMmTdtPOM25LFV11DT UMsf1VFLPWx7yo0QmAP5RULKlNAxEV62J4/tmkwZQrClwus4XuNgTgsBV/c01DTUykINJtpKqDXV yIxiL4RXDY9rK7Br4XmAF+SvIyhbjoaahlpZqMFsbgk1BakuMlYHU4rga2PqKsAplYrq1UFl6tga ahpqZaEGjwxIqFHFZ6giG0pFojWmwGfieQ/z2EqZqlRDra+hVhZqXQU1ptgLIcUUjBSwkM/UJIgm nm9gTjXDpmVqVtNQKws1y1SshgByMK0hpLp43LSlZaZYrYuqs9GSZyw877U01DTUSkPNUlBDf7OD StNDSLWUNYawc9BKq6Fb0FVQw/OUaqhpqJWGWg2hpjgsAxnymYmwa6Ld1saUIZPZeL5Rl9wGdtta 7F3PHdnluSNPDeFadYSa60jodKlMHTyuK8BhaiG8VNgWRgiKPE5NQ02zWmlWayDU6qgQVeSshQ5B B1Wqi+rSUSkCTo0iePhtvaGhpqFWGmpNZaspywxBRpU1hsdNVJR1BFYbOU/5nmpcAdSuVqB6DDRb P/JrA1NWC6GmOMz0pHJUwdsGwquJTAbmP5w39aQIPQPpGZfQ3zp0v+PPqOjnHV6FmJV0TWCCJjwE pzVurnG3r4tRpalFVhvVqolBjjuKs9IRja/DQzdPZdaOy1fm7BWrAd+7ROO4WKLxwxIWZBxnK3xq zi3PuVqoqiFUE1gF12WwzR9ziS2F5YHlcL+D/fZu189NcZOUCwabP2nBKi9Yu/FMBzyEeZomcxqG f4zJ+/H5gZWhSJBf1tAAe6ht7qIEezLCjmuhM+Owz5tg3j6WsH+czmFXPPhFhfZXuq35WrMB/Rbt hs4NNMsb2hPu1++JHwQpLJUMCyLHuEJysWzyHqHx3brq3YC2b5a0M4Rxd311y9RLZBdDHNrNKZri vp3rvt48OyMmP3teDFtpkjMWTpMZKNpj3IUgkhsKa96soKGlFr9+UqpxU0HcAHWY8A/Lpbyzmt0e HIyHf/k0PB8MyX80IKoJCLXNAqm9s+oSEBoSFTc2AAFqtw0CmECOgDM/f/hpOJiQ0fHwfDI6GQ0v yV9pkDLynUVqpNMwiWXVm40useTf95pKqkklkj2yl6KS/NPFx8GY/AEmUoqYwmZ9YqlNV9xto5Iw gelC6lV7Z2YwOf90dqZJo5JoyClCvmdo+K+GQiWhYKk9vcA3aVgIhQ+jCRlPLkfnp3sE9mOkUZwG GD3WzkoRGqtQGAwM0mxnOPBV2hlZaAd2EOebd1WSNWrKWwHWqOXeCiGj88nwdMVLMWsNYvuJ9kwq yRtWU+0ZKT3aLMgB1sYdjLSazXpbA6SSAFk1QnMrlBBth2owaJek0sbFKjEgFDQnPIIT9IzRaswY lVKSzcO2IKR3LCeP+uGUcK/kpOx7Az4xc5ILkc9y6xsmvNqdQV3OB7x/4ls0HX+GLxd9w6rVGiZO HITjJgxQyMdmF71o+mcqS0x4BOcbKouQiyPcfrR5kvD57eeAeSvfzhh1GUxRbIOvBQV5nMNk1+Lj NE3wY3Y5hwfSN4vVRpryJ3gXLndOhe/CN4Efsgs/cWZ9o97Cb0FkVL2PZJvY3F3iAfwkncPGzEf/ AwAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnht bOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2Fb gRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt 3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyK cCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUC HWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9 A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8b c/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDX ahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BU tb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG //rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI 0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH 8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6 gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeR HOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4 QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/ gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+d t/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G 9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpD iK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJ C9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrg eIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWv S91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEK VFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf 4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7 Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqn IRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuW QaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK 0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H 0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2 ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQU AAYACAAAACEAX5ARw3EDAADLCAAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFbbbts4EH1fYP9B0PM6 kmwnaYU4xdZZ76aI26JKP4CSaJsIbxhSVtyv75AUoxpxg6DF+sXknLnfqKt3j4InewqGKblIi7M8 TahsVMvkdpF+vV9N3qSJsUS2hCtJF+mBmvTd9Z9/XPWlodYim0lQhTSlaBbpzlpdZplpdlQQc6Y0 lQhuFAhi8QrbTBB46PSkUUITy2rGmT1k0zy/SAc1apF2IMtBxUSwBpRRG+tESrXZsIYOf1ECXmM3 SN6ophNUWm8xA8rRByXNjmkTtYlf1YYh7qKS/UtB7AWPfH2Rv8Q5hNsraJ8kXuOeE9CgGmoMFkjw EK4gTD6pKebPFD2l+gxTnQXbmVOF4kXuT6Pnhj+TP1HtUMU7VgOBUGZsAOeFaMrbrVRAao5N1Rfz 9Bo76ptSIulLTaHBImE7TvM0c0BLN6Tj9p7UlVUaWfYE7V9GuNkRII2lUGnSYMRLJS0oHvla9VHZ JXYcYEKCwtB/TnU4VaGXUUISgR4F6tCfa9XSFKEO2LOgf5o0J+C9xNh8DKcNKZw9YC3F0Dit7IHT FTpfsW/0b9l+6Ixl2PG+S3/Dg5ccoNJZ/oSTen/QdEWJ7TBN/5MxX4kVZ3rNABTcyhbr/LvGslhE V05cZK2Jhy9K2ViGHH+Xb5azkAvH9ipkOl1eFidlprPl29UpZHaB0D+nkMt5cXM+tMOxB29X8/y9 t4PRDDGI0q2Uz3B9FU6uMRIRmmpJRA2MJGu3dLC9RFnDw3smI15TXLr0R6Tq6ghOJgEwgnC+wsmJ gJ82UbbM6Bu68Wr5msB21DtwwEkqTumHJ11ugin8C6rTwVoPRIeCR3PFfD7oY9LeMRHppqurKCVx cfwAdbL9tAenMBvT05cW3xs/OHdEbmNdqZx8rRwr9geHyr1JdE20xgWBLPW2WKScbXe2cM1u8dbi 2+Qv9XY6YFOP4c1h/kIaFxlyDwfHEI7INRxG2izSZiMNN2/gm4+080g7H2kXkYZvY1/ucDqBM/mA KygeHX2jOFc9bf+LxEX6jBSSYHZEU6yr26Q4Iqr0hGG1mmRf0kfcubRlFp98zVpBHnEF59MLJz5w c3JQnT3idZhj1kfUpCWWoLgv1ZEwlg6/HY59cRu+YdiO1UHU4+I+C45zZmxFNe54qwBD9mv1L695 /Aq5/g4AAP//AwBQSwMEFAAGAAgAAAAhAHMObQeCAQAAUAMAABQAAAB3b3JkL3dlYlNldHRpbmdz LnhtbJRTy27CMBC8V+o/RL6DE4pQiQhICFFVqqqqjw9wHIdYtb2WbZLC13dJePVxgJPXuzPj3Z1k MvvSKqqF8xJMRpJ+TCJhOBTSrDLy8b7s3ZPIB2YKpsCIjGyEJ7Pp7c2kSRuRv4kQEOkjVDE+1Twj VQg2pdTzSmjm+2CFwWIJTrOAV7eimrnPte1x0JYFmUslw4YO4nhE9jLuEhUoS8nFAvhaCxNaPnVC oSIYX0nrD2rNJWoNuMI64MJ7nEerTk8zaY4yyfCPkJbcgYcy9HEY2nVEd1JIT+I20opEmqePKwOO 5Qo32CRDMsX1FbL2+zNqUllkZDyOk7vhOBm19RyKzULWWKuZQmsI3aFxeU+iDMfsID7mX+Wq+rfw DvaAP6HnEALoX3nsaV643TvhxDFoPEGg32YEPw8MLOM4SBtzUIB+sXWArhF11t11zPxHR9dx3fns 11Bpa0Q7dBdOJ93ZegM2SC23Yglu7qDxwrUmMKWgeXl+wAuCz/6D6TcAAAD//wMAUEsDBBQABgAI AAAAIQA98saZ9gkAAFlJAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzcXFtT47gSfj9V 5z+4/M6QGwmhNrPFMMsOVcwsO0Dts+MoxIVt+dgOGebXb6slK45txS1s5uHMwySRpf76pq8VUPPb 7z+i0HlhaRbweOEOPwxch8U+XwXx08J9fLg+OXedLPfilRfymC3cV5a5v3/8739+211k+WvIMgcE xNnFLvEX7ibPk4vT08zfsMjLPkSBn/KMr/MPPo9O+Xod+Ox0x9PV6WgwHOC7JOU+yzJAu/LiFy9z lbioLo0nLAasNU8jL88+8PTpNPLS521yAtITLw+WQRjkryB7MC3E8IW7TeMLpdCJVkgsuZAKqZdi RVqzogFXrvzM/W3E4hwRT1MWgg48zjZBsjfjrdLAxE2h0ssxI16isJi3S4aTGp42mRKDz6m3g1Ds BdbENThjJRdFofSDiO8+qlWJw8ExY1REhAitA0WFQ8xCk8gLYi3mba4pOxf2Q5f8/jPl20SrkwTd pN3Ez1qW2JYWmg2muPPKpmVWAmpb937jJcx1Iv/i5inmqbcMQaPdcOKIjHQ/AlWsuP+Zrb1tmGfi Y3qXqo/qE75c8zjPnN2Fl/lB8AAUAlKiAAR+uYyzwIUnzMvyyyzwGh9uxKzGJ36Wl6R9ClaBeyoQ s58g88ULF+5oVIxcCQ0OxkIvfirGWHzyeF/WZOHqoSXIXbheenJ/KYSdopnFa8nc5MB4+ISqJJ4P Ow9wvHXOgISAxQROGIjojmbAaPLD961wrrfNuQJBAQBWFgsfKx4HbgKmupeMDU/Z+pb7z2x1n8OD hYtYMPh4c5cGPAUaXbjzucCEwXsWBV+C1YqJAqHGHuNNsGL/bFj8mLHVfvzva6RnJdHn2zgH9acz zIIwW/3xw2eJoEkQHXsiwt/EAuAwCEcJBxXaBntt5EAFFQf/V0AOZQwbUTbMEyXNQf2PAqHV285A I2FR2QCUa6XruLuISXcRZ91FYPJ288WsuxZwkOkaEZkbpaykBzXnvky+sh/G8yMpK1bUsqh1RS1p WlfUcqR1RS0lWlfUMqB1RS3grStq8W1dUQvn0RW+h8RVzaIxeoO0sR+CPIQ62cJ0w45Up0qNc+el 3lPqJRtHFNaq2sfI8n67zGmqIp2+nSzv85SL42aLR6A6i637Zk7+I0o2XhbAqbwNqKPrH8TRx/kz DeD42gJ1JpOvZhMeTBpL2F3o+WzDwxVLnQf2Q0bUYv037tzLU0arch3Dehs8bXIHToWi5LaCTQ1O N3tCyr8NMvTB0Wo+NZjSJpwUw6khL83Cv7JVsI0K1xBOI1PJ5xZhrkCgisddNBEhqu+uVitEACgm yHJhbwLKJ+gvi4u9fBFjiv6yFL1RPkF/WbjeKB/z43h8rZnmM/xYxSFtr5n13r3iIU/X27DYA630 MLPewRqCZoL1JtbySSQxs97BB/TpXPo+fHOj5Kl1LPY8aoFiHQ6JgpuNbot1UCq0N7SwyDpAFayR BVY3rrUAsibd7+wlED8Eti0GyNL6rNm6nccGD0AJIp2h/97yvP0MPTJwHhXlJoYfl2TMoaGNDTuP iqbySdY7ixh3K3wWQN0qoAVQt1JoAWTID/OZR9dEOkj34miBZU3Luoph2pGZeWbNzBrIrgT0VDcJ 5y/D7jXnQr1uElCsA1SvmwQU6+hUapmumwSs3uomActQNcwxKnOqjVHWdbMMpE8CBIv6IW8CUD/k TQDqh7wJQN3Jux2kP/ImYFlzg+bUMnkTgHCKzVd9DVQmbwKQNTdItlM/MyrqHko5/uW2B/ImoFgH qE7eBBTr6JjIm4CFU2wyoYKlqY6A1Q95E4D6IW8CUD/kTQDqh7wJQP2QNwGoO3m3g/RH3gQsa27Q nFombwKQNT1ooDJ5E4Bwig03NJI37vp3J28CinWA6uRNQLGOToVQ9SGVgGUdoAqWJm8CFk6xSQaF hcltY1Q/5E2wqB/yJgD1Q94EoH7ImwDUnbzbQfojbwKWNTdoTi2TNwHImh40UJm8CUDW3NBI3rgZ 3528CSjWAaqTNwHFOjoVQtU8R8CyDlAFS5M3AQvzpTN5E4BwyluBbCzqh7wJFvVD3gSgfsibANSd vNtB+iNvApY1N2hOLZM3AciaHjRQmbwJQNbc0EjeuEfenbwJKNYBqpM3AcU6OhVC1eRNwLIOUAVL Ux0Bqx/yJgBhYnYmbwIQTnkDEO4imzD1Q94Ei/ohbwJQd/JuB+mPvAlY1tygObVM3gQga3rQQGXy JgBZc4O4Zwv3RcnXU4eGJKDeMyhuNZABR4YgUQGVgd/ZmqXQVcjab4d0BCwstEA0pAfVxE+cPzu0 i91jQ4KQoYJlGHC80v2Kt3RKjQjj2ZFOgoe/rpwvsgGmtg5T6vDmDXQPlduFsD1JNA6BnvlrAi07 SXGzXEiDBiHR16VagLAn9AYaglRbj1gs+nxgIjZVqWH8va1ChfeAiAtboLRwZcwIu4rK4os2H9XO tfSgOekv0WtUA4fGqudivBB3tfFS6cZ9k0YxR3Vq7HWG9q4M7o8q0QP4Nzu/GsvltaauJYO2VfDc UHZ1yY+X0MSVyRvZynuq90vNwk/1SbIlDH/vJd6qhrD8VjTHSXi+zcWT25ewUA9v+8smMeFj6L/D l4OOu4V7xbdpALfLv7GdiGzRbbdwH4IIGn1h2PnOIw+viGG3XW2JD52EZSkY56X8/yrD11LT3USq m/0sNd3hGGiKKprzwodQeT50yh1JQdUIoe+mYRtENSEN3RKoaj0LVNfE/mwt5x3c3YUhs9656BA4 ojN2EBzdOw5OkZ6rKwhNe9LLupeuWUPYystQZgG8uYlFIu9U157c5KsfnhQFz69YGH71MGdynpin hmydy6fDAZ6MKqKWPM95ZF6fYuMAatIkANxaVkZ+FEaY/R1voyVLVRuCkarEiaLGJdAvgePSgZpr QXskE6qnzbod5LC/zcA12KBZpdIDeqrmr3rojJw9e1Vor3EfoFVNJGjMLPnATHr/Z6SyLzZQ81Lh qVqGfNFP0Jtkt3fZtq3+98UF+yJJRVm6vlYhLQbFX1sAEgKdITdbePag1O9d8vD19i4VNQ3+TkHO VnXPwATnYEaTh8qHgYNUrIjfZ/b7eE6Va+Bm7E6H18JVgtAEWyccCtt8OJWeNE0Yno/VwcM0YzSb nB+XMZ5OVVk0yZicnQ+OyzibzFs0nU6GLZrOxqMWTc9HkxZNwWEtmsJJB1rbMTdM5g4H83mLrsPh HMrNcSkjULdlyng2aVN3Mj1DdUXpUdmiTnCQJOr0pk9m0PgOAuGBOIw19+3/6qPYOxy+jhWupn1c K2BVquhcyCqoMupk5mgl2PTXnJp/baieUvZaY3EcbCJu84nC5D3zKai5wnzjRa9qNV9KbayoWj2w 6pBu/qo2v54MPqlZta9qb9jFe+OKd9nHfwEAAP//AwBQSwMEFAAGAAgAAAAhAEQVyeBNAQAAgQIA ABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIySUUvDMBSF3wX/Q8l7m7RlIqHtQGUP4kBwovgWkrstrElDEtft35u2s7bog4/JOffLObctlidV R0ewTja6RGlCUASaN0LqXYleN6v4FkXOMy1Y3Wgo0RkcWlbXVwU3lDcWnm1jwHoJLgok7Sg3Jdp7 byjGju9BMZcEhw7itrGK+XC0O2wYP7Ad4IyQG6zAM8E8wx0wNiMRXZCCj0jzaeseIDiGGhRo73Ca pPjH68Eq9+dAr0ycSvqzCZ0ucadswQdxdJ+cHI1t2yZt3scI+VP8vn566avGUne74oCqQnDKLTDf 2GotDxA9hvW5Ak+uuxXWzPl12PZWgrg7z5y/1W7AwlF236rKCzw9hvf6esOjIKIQmA71vpW3/P5h s0JVRtJFTPI4JZssp3lGCfnogs3muwLDhbrE+zdxQebEb0DVJ57/NNUXAAAA//8DAFBLAwQUAAYA CAAAACEAE9yLl28JAABoRgAADwAAAHdvcmQvc3R5bGVzLnhtbNxbS3PbNhC+d6b/gcN7oqclyxMl 4zh14xnHcSJ7eqYoyOKEJFSSiu38+i4WIEWRArEw6RzaQyWCwH77wreQg3334SkKnZ8sSQMez93B 277rsNjnqyB+mLv3d5dvTl0nzbx45YU8ZnP3maXuh/d//vHu8SzNnkOWOiAgTs8if+5usmx71uul /oZFXvqWb1kML9c8ibwMHpOHXuQlP3bbNz6Ptl4WLIMwyJ57w35/4ioxCUUKX68Dn33i/i5icYbr ewkLQSKP002wTXNpjxRpjzxZbRPuszQFo6NQyou8IC7EDMY1QVHgJzzl6+wtGNOTGvWEKFg+6OO3 KHSdyD+7eoh54i1DcN7jYOy+B8+tuP+Jrb1dmKXiMblN1KN6wo9LHmep83jmpX4Q3IFLQUAUgKzP 53EauPCGeWl2ngbe0ZcbMevoGz/NStI+BqvA7QnE9BfI/OmFc3c4zEcuhAYHY6EXP+RjLH5zvyhr MneLoSXInbte8mZxLoT10Mz8s2Tu9sB4eEJVtp4PwQAcb50xSArIEYETBiIHh1PIF/nwfSf86u0y rkBQAICVxcJjxeOQK5A5C5nA8Jatr7n/g60WGbyYu4gFg/dXt0nAE0jSuTubCUwYXLAo+BysVkzs FzV2H2+CFftnw+L7lK32498uMfmVRJ/v4gzUn0wxC8J09deTz7YibUF07IkI34gFkDgQjhIOKrQL 9trIgQoqDv6bQw5kDI+ibJgndriD+jcCodW71kBDYVHZAJRrpeuovYhxexEn7UVg8rbzxbS9FsDr bSMic6OUlfSgZtyXyVf2w2jWkLJiRS2LjCtqSWNcUcsR44paShhX1DLAuKIWcOOKWnyNK2rhbFzh e0hc1SwaoTdIG/suyEIm1jcS0KAl1alS49x6ifeQeNuNIwprVe0mslzslhlNVaTTl5PlIkt4/GD0 CFRnsXVfzMl/RduNlwZwSjK4ftjS9Xfi1OP8nQQrI9SJTL6aTXgwOVrCbkPPZxserlji3LEnGVGL 9TfcWchThlG5lmG9Dh42mbPYYMk1gk00Ttd7Qsq/DlL0QeNmmmhMMQknxXCiyUu98C9sFeyi3DWE 08hE8rlFmCsQqGKzi8YiRPXdZbRCBIBigiwX9iagfIL+srjYyxcxpugvS9EL5RP0l4XrhfIxP5rj a800n+BHq0PaXlPrvXvBQ56sd2G+B4z0MLXewQUEzQTrTVzIJ5HE1HoHH9Cnc+778MuNkqfWsdjz qAWKdTgkCm42ui3WQanQ3sDCIusAVbCGFljtuNYCyJp0v7OfgfibmG0xQJYuzprG7TzSeABKEOkM /W3HM/MZeqjhPCrKVQx/LkmZQ0MbaXYeFU3lk6x3FjFuV/gsgNpVQAugdqXQAkiTH/ozT1ET6SDt i6MFljUtF1UM047MzFNrZi6A7EpAR3WTcP7S7F59LtTrJgHFOkD1uklAsY5OpZYVdZOA1VndJGBp qoY+RmVOtTHKum6WgYqTAMGibsibANQNeROAuiFvAlB78jaDdEfeBCxrbig4tUzeBCCcYvNTvwAq kzcByJobJNupvxnldQ+lNP+47YC8CSjWAaqTNwHFOjo68iZg4RSbTKhgFVRHwOqGvAlA3ZA3Aagb 8iYAdUPeBKBuyJsA1J68zSDdkTcBy5obCk4tkzcByJoeCqAyeROAcIoNNxwlb9z1r07eBBTrANXJ m4BiHZ0KoRaHVAKWdYAqWAV5E7Bwik0yKCxMbhujuiFvgkXdkDcBqBvyJgB1Q94EoPbkbQbpjrwJ WNbcUHBqmbwJQNb0UACVyZsAZM0NR8kbN+OrkzcBxTpAdfImoFhHp0KoBc8RsKwDVMEqyJuAhfnS mrwJQDjlpUA2FnVD3gSLuiFvAlA35E0Aak/eZpDuyJuAZc0NBaeWyZsAZE0PBVCZvAlA1txwlLxx j7w6eRNQrANUJ28CinV0KoRakDcByzpAFayC6ghY3ZA3AQgTszV5E4BwyguAcBfZhKkb8iZY1A15 E4Dak7cZpDvyJmBZc0PBqWXyJgBZ00MBVCZvApA1N4h7tnBflHw9daBJAuo9g/xWAxlwqAkSFVAZ +J2tWQJNVsx8O6QlYG6hBaImPagmfuT8h0O72D3SJAgZKliGAccr3c94S6fUiDCaNnQS3H29cD7L BpjaOkypw5s30D1UbhfC9iTROAR6Zs9baNnZ5jfLhTRoEBJ9XaoFCFvkrqAhSLX1iMWizwcmYlOV GsZ/t1Wo8B0QcaEBqhCujBliV1FZfN7mo9q5lh40J30VvUY1cGis+pGP5+IuNl4i3bhv0sjnqE6N vc7Q3pXC/VElug//TU8vRnJ5ralryaApEDw3kF1d8vEcmrhSeSNbeU/1fqlZ+FSfJFvC8N+9xFfV EJZdi+Y4Cc93mXhz/TPM1cPb/rJJTPgY+u/w46Djbu5e8F0SwO3yG/YoIpt3283duyCCvkcYdr7z yMMrYthtV1vip4dDGOel/P9Fip+lpruxVDf9VWq6wzHQFFXU54UPofJ86JRrSEHVCFHcTcM2iGpC arolUNV6Fqiuif3ZWs47uLsLQ3q9M9Eh0KAzdhA07h0Hp0jP1RWEpj3p5aKX7riGsJWXocwC+HIV i0SG5lHMKrnJV0+eFAXvL1gYfvEwZzK+1U8N2TqTbwd9PBlVRC15lvFIvz7BxgHU5JgAcGtZGfko jND7O95FS5ZA51+Dz2+4OFHUuAT6JXBcOrDgWtAeyYTqab1uBzns71JwDTZoVqn0gJ6q+ateOkNn z14V2ju6D9CqYySozSz5Qk96/zNS2RcbqHmJ8FQtQz4Xb9CbZLe32bZG//vign2epKIsXV6qkOaD ousbSAh0htw08OxBqd+75O7L9W0iaho0umdsVfcMTHAOZhzzUPkwcJCKFfH7zH4dz6lyDdyM3enw mbtKEJpgji2HwjYbTKQndRMGpyN18NDNGE7Hp80yRpOJKos6GeOT036zjJPxzKDpZDwwaDodDQ2a ng7HBk3BYQZN4aQDre2YGzpzB/3ZzKDrYDCDctMsZQjqGqaMpmOTuuPJCaorSo/KFnWCgyRRp7fi ZAaN7yAQXojD2PG+/d99FHuFw1dT4Tq2j2sFrEoVrQtZBVVGncwcRoJNfs+p+feG6iFhzzUWx8Fj xK0/Uei8pz8FHa8wNzzvVa3mS6mNFVWrB1Yd0vU/1WaX4/5HNav2U+0Fu3hvXP4tff8fAAAA//8D AFBLAwQUAAYACAAAACEAyuVY+e8BAACuBQAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbLST3Y7aMBCF 7yv1HSLfL3FC9odow2pFi9SbXlTbBzCOQ6z6J/IYsrx9J3bIXgAqtGqQonDGPpr5dOb55V2rZC8c SGsqks0oSYThtpZmW5Gfb+u7J5KAZ6ZmyhpRkYMA8rL8/Om5LxtrPCR430CpeUVa77syTYG3QjOY 2U4YLDbWaebxr9ummrlfu+6OW90xLzdSSX9Ic0ofyGjjrnGxTSO5+GL5Tgvjw/3UCYWO1kArOzi6 9de49dbVnbNcAODMWkU/zaSZbLLixEhL7izYxs9wmDR2lA5WeD2j4Usrkmheftsa69hGIbs+K8hy BJf0pWEaxRVTcuNkKHTMWBAZ1vZMVYTmdE3v8T38Cjof3iQdHHjLHAg/HaRRbpiW6nBUoZcAsdBJ z9ujvmdODg3FEsgtFnawoRX5SvHJ12sSlawiBQqvq0nJsan4ZOOZ+aRgcrCx4BOOZIvggwr6jLdC n2mMzgmJN6kFJN9Fn/ywmpkLRHL6gCTukcdAZn4TERd8A8EbiOSv0/w4yQpHeXwqjvN/EFn8mUj0 uZ7Iyu6cFG5gcoHGIxJYhHwMNIqbaGhbC2fOBKSR76I+n46zLObj5P+XBdO4JuwChyENMRVDOm7b k79Lxeme0GLKyQeJsBW4Xf+yJ+PCwPI3AAAA//8DAFBLAwQUAAYACAAAACEAIMSRJe4BAAD1AwAA EAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACc U8tu2zAQvBfoPwi6x7SdxE2MNYPCQZFD2xiwkpxZamUTpUiCZIS4X9+lFMt021N12peGw5kl3L21 uujQB2XNqpxNpmWBRtpamd2qfKq+XNyURYjC1EJbg6vygKG84x8/wMZbhz4qDAVBmLAq9zG6JWNB 7rEVYUJtQ53G+lZESv2O2aZREu+tfG3RRDafThcM3yKaGusLNwKWA+Kyi/8LWluZ+IXn6uCIMIcK W6dFRP490dGT2sYW2FiFykahK9Uin91QfcxgI3YY+AzYEMCL9XXgl7efgA0hrPfCCxlJQj6fLy6B ZQX47JxWUkRSl39T0ttgm1g89joUCQBYPgKkzRblq1fxwKfA8hS+KpOoEL8hIm5e7Lxw+8CvE8Ex g60UGtekAG+EDgjsVIAHFMndjVDEGLq47FBG64ugfpG/87L4IQIm3VZlJ7wSJpJ+aWxI+li7ED2v VNSETb0h78N8LI/VVVKRZik4H0zFgQM1ztn1J4THhu4W/0F2lpPtOQxUMzpZOJ7xB+ratk6YQ+bP 2npnfe8a2fneTvr/DE+usvdpkd6FPS9my/Ci4n7rhCTL5otr8ue0FlkLtrQ9WJPPR8BTAR7IBK/T qfSv2WF9nPm7kRbteXjFfHY1mdLXb9axRusxPi/+GwAA//8DAFBLAQItABQABgAIAAAAIQAJJIeC gQEAAI4FAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAAugMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAGi4lTNYAQAAGQUAABwAAAAAAAAAAAAAAAAA3gYAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1s LnJlbHNQSwECLQAUAAYACAAAACEAmaMkbdwKAACUmwAAEQAAAAAAAAAAAAAAAAB4CQAAd29yZC9k b2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAACDFAAA d29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAF+QEcNxAwAAywgAABEAAAAAAAAA AAAAAAAAXhsAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHMObQeCAQAAUAMAABQA AAAAAAAAAAAAAAAA/h4AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAD3yxpn2 CQAAWUkAABoAAAAAAAAAAAAAAAAAsiAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1sUEsBAi0A FAAGAAgAAAAhAEQVyeBNAQAAgQIAABEAAAAAAAAAAAAAAAAA4CoAAGRvY1Byb3BzL2NvcmUueG1s UEsBAi0AFAAGAAgAAAAhABPci5dvCQAAaEYAAA8AAAAAAAAAAAAAAAAAZC0AAHdvcmQvc3R5bGVz LnhtbFBLAQItABQABgAIAAAAIQDK5Vj57wEAAK4FAAASAAAAAAAAAAAAAAAAAAA3AAB3b3JkL2Zv bnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAIMSRJe4BAAD1AwAAEAAAAAAAAAAAAAAAAAAfOQAA ZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAkDAABDPAAAAAA= --_005_4E1F6AAD24975D4BA5B1680429673943A2F4A754TK5EX14MBXC292r_-- From nobody Wed Mar 11 10:24:11 2015 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 DC5AB1A016C for ; Wed, 11 Mar 2015 10:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy3dzf3-Rxvq for ; Wed, 11 Mar 2015 10:24:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376481A0077 for ; Wed, 11 Mar 2015 10:24:07 -0700 (PDT) Received: from [192.168.10.133] ([208.85.208.52]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MYfJW-1Z0yMK1luk-00VSpz; Wed, 11 Mar 2015 18:23:39 +0100 Message-ID: <55007A17.9000808@gmx.net> Date: Wed, 11 Mar 2015 18:23:35 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Jones , Stephen Farrell References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oFEiMM2Snn8ih00aG0MSVIlENXrhN8Pd9" X-Provags-ID: V03:K0:gMyvnqJ2BAC+a1wPuVCx+aFxBHe0rBgH6EIYkjgllaKfs9osFic oz9SWiJ5/6OUdrbEunNXjZlewhYlZuazh2QX1ZYd+dnI80sgH0dnOXkJtDAv9AmrnR5vbAl VfVpbDGtw70vSPK0BBzX/uhv5W6KQk/4VNl9lm9tfXQ8pJdJf7ouvK74oyx4K/gw+KqR7iH SCoNCmIzECoO2ud3V/phA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Nat Sakimura , "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 17:24:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oFEiMM2Snn8ih00aG0MSVIlENXrhN8Pd9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mike, I did this in the context of the work on the raw public key document for TLS. Using an ASN.1 parser makes sense since the SubjectPublicKeyInfo is not just a blog but an ASN.1 structure that looks differently depending on the type of keys encoding (ECC vs. RSA). My code was done as part of the TLS stack itself it is not as usable as a command line tool. You referenced https://tools.ietf.org/html/rfc7250#appendix-A and this was created by extracing the SubjectPublicKeyInfo field from a self-signed certificate that was created with the OpenSSL tools. Ciao Hannes On 03/11/2015 06:16 AM, Mike Jones wrote: > I=92ve always loved learning new things, so I decided yesterday to try = to > learn first-hand how to write code that emitted X.509 > SubjectPublicKeyInfo (SPKI) values from scratch. By =93from scratch=94= , I > mean using development tools without built-in X.509 or ASN.1 support. >=20 > =20 >=20 > I took this on because of Stephen=92s suggestion > http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that > people could just hash the SPKI values to create a key thumbprint.=20 > Given I=92d helped create the JSON-based hash input described in > http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I wanted > to give his alternative suggestion a fair shake (and learn some new > things along the way). This admittedly stream-of-consciousness and > overly long message describes my expedition to date=85 >=20 > =20 >=20 > Thus far, I=92ve spent 5 hours trying to learn to do this. I spent abo= ut > the first two hours searching for examples of creating the bytes of > X.509 certificates or SubjectPublicKeyInfo values without using ASN.1 > and/or X.509 libraries. I failed. >=20 > =20 >=20 > Next, I tried to read the authoritative reference for what=92s in the S= PKI > field =96 the X.509 spec. Unfortunately, > http://www.itu.int/rec/T-REC-X.509/en told me =93This text was produced= > through a joint activity with ISO and IEC. According to the agreement > with our partners, this document is only available through payment.=94 = > Since most developers would stop at that point, I did too. >=20 > =20 >=20 > After that, I changed tacks and tried to find examples of sample > certificates with commentary on what all the values mean =96 the kind o= f > info developers would want when coding this. I had better luck with > that. After about another hour of Web searching, I found this really > useful example: http://tools.ietf.org/html/rfc7250#appendix-A. I also > found this one: > http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. Going > through them byte-by-byte enabled me to reverse engineer some of the > ASN.1 and X.509 constructs used. >=20 > =20 >=20 > Things I learned by looking at these 1024-bit RSA public key > representations included: >=20 > =B7 ASN.1 uses byte-aligned Tag-Length-Value encodings. >=20 > =B7 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER ar= e > respectively 0x30, 0x06, 0x05, 0x03, and 0x02. >=20 > =B7 These Length values are encoded as follows: >=20 > o 159 =96 0x81 0x9f >=20 > o 9 =96 0x09 >=20 > o 0 =96 0x00 >=20 > =B7 The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a 0= x86 > 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. >=20 > =B7 The OID is followed by an ASN.1 NULL - 0x05 0x00. >=20 > =B7 The RSA Key is represented as an encapsulated bit field. >=20 > =B7 There is an apparently unused zero byte (the 22^nd byte of t= he > SPKI field in the RFC 7250 example) as the first byte of this bit field= =2E >=20 > =B7 The rest of the bit field contains concatenated representati= ons > of the modulus and the exponent as ASN.1 INTEGERs. >=20 > =B7 The 1024 bit modulus is represented in 129 bytes, with the > first byte being zero. >=20 > =20 >=20 > This brought me up to hour four. Next, I went looking for a 2048 bit > cert to learn from (especially since JWA requires 2048+ bit RSA keys). = > I found http://fm4dd.com/openssl/certexamples.htm and chose > 2048b-rsa-example-cert.der, from which I also learned: >=20 > =B7 These length values are encoded as follows: >=20 > o 290 =96 0x82 0x01 0x22 >=20 > o 257 =96 0x82 0x01 0x01 >=20 > =B7 From this, I deduced (possibly incorrectly J) that if the hi= gh > bit of the first length byte is 0, the remaining 7 bits represent the > length, but if the high bit of the first length byte is 1, the remainin= g > 7 bits represent the number of bytes used to represent the actual > length. (Hence the use of 0x81 for representing values in the range > 128-255 and the use of 0x82 for representing values in the range 256-32= 767.) >=20 > =B7 Length values are represented in big-endian byte order. >=20 > =B7 The 2048 bit key representation also starts with an apparent= ly > unused zero byte. >=20 > =B7 The 2048 bit modulus is represented by 257 bytes, with the > first byte being zero. >=20 > =20 >=20 > Things I haven=92t yet learned that I=92d need to know to really write = this > code: >=20 > =B7 How are the OIDs in the table at > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appen= dix-A > represented as ASN.1 OID values? >=20 > =B7 Are multiple OIDs sometimes present before the ASN.1 NULL, a= nd > if so, which algorithms require which sets of OIDs in what order? >=20 > =B7 Is there always the apparently unused zero byte in the key > representation or if not, when is it present and absent? >=20 > =B7 Is there always a leading zero byte in the RSA modulus or if= > not, when is it present and absent? >=20 > =B7 How are elliptic curve keys represented? >=20 > =20 >=20 > This brought me up to about the fifth hour of my investigation, and I > decided to stop and write up my findings to date. Highlighted versions= > of the example certificate from RFC 7250 and the SPKI value from > fm4dd.com are attached, should any of you want to follow along with my > reverse engineering. Tags are yellow. Lengths are green. OIDs are > purple. The apparently unused byte is red. Key values are blue. >=20 > =20 >=20 > I readily admit that I could have easily missed something while > searching. If someone can point me to self-contained descriptions of > this information, I=92d love to see them! >=20 > =20 >=20 > =3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D >=20 > =20 >=20 > 1. I think it would be a fine thing to do to write an RFC describing > the mapping between key values and their SPKI representations. This > could take the form of a cookbook with entries like =93For a 2048 bit R= SA > key using RSASSA with SHA-256, emit these bytes, filling in slots A and= > B in the template with the 256 bites of the mantissa and the 3 bytes of= > the exponent=94. Based on my searching, I don=92t think this informati= on > exists anywhere in a self-contained form accessible to developers (but = I > could be wrong, of course). I=92m not going to personally do it, but i= f > any of you want go for it, have at it! >=20 > =20 >=20 > 2. If my experience is representative, telling developers to just hash= > the SPKI representation of a JWK won=92t be very effective unless they > already have X.509 support. Most will probably give up well before the= > 5 hours that I=92ve invested to get this this partial understanding of > what I=92d need to know. If my experience is representative, > draft-ietf-jose-jwk-thumbprint will be much easier to implement for > these developers. >=20 > =20 >=20 > Trying to live in the shoes of developers= , >=20 > -- Mike >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 --oFEiMM2Snn8ih00aG0MSVIlENXrhN8Pd9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVAHoXAAoJEGhJURNOOiAtRP8IAJ88QYeKc+FuCuDQ63YvYSeV jnPeUH0wphQXU0yawywljGUeDDLGjjtkJIh0qAilT3xQdOwW77Mis8puSEnBOvmP bZazTulFgYLS9NGpsLkcSvhfuUggoEo3ekt4ljo3oGmog8baJmysehEetk8eOH1t nJTQg4wYThb2c928YVkmR8EfBPZWXYGUNHRKubZc9Em4cbGPyeLzZFM7HwQ/WLpB RYK/CamTtAEcRBF6M16zvb76b7XVelnBpxx5gx062qxJhYxLyw/oVTpdC1vExfwr 8JMc2lH5dt3jWMgoxZlI8hX72rmiS+iG1s7F9r/7dqSXSQTupjMRlw5EoLAUJ20= =U5f6 -----END PGP SIGNATURE----- --oFEiMM2Snn8ih00aG0MSVIlENXrhN8Pd9-- From nobody Wed Mar 11 11:06:36 2015 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 D5D7F1A1BDF for ; Wed, 11 Mar 2015 11:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxB18wArqBoT for ; Wed, 11 Mar 2015 11:06:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD34C1A1BAC for ; Wed, 11 Mar 2015 11:06:14 -0700 (PDT) Received: from [192.168.10.133] ([208.85.208.52]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lcj9b-1ZFZlY19hX-00k804; Wed, 11 Mar 2015 19:06:07 +0100 Message-ID: <55008407.1080804@gmx.net> Date: Wed, 11 Mar 2015 19:05:59 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Jones , Stephen Farrell References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> <55007A17.9000808@gmx.net> In-Reply-To: <55007A17.9000808@gmx.net> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4R2FqDWCKWqoRnUrrxVGax1Q3tMJB3iN7" X-Provags-ID: V03:K0:elapUpw1j2W1otnKdHHt8M/HDXw2yN/eyH8vTolDDHzNpuVIIFl jy27v5GyBUTqjEF3uewuS2JCE2jswNW/noEtNafdXUoA9Sx6frB/83CrVi1LkDMMc5VtEwK 4MGtbM4CZ8sVNsP42F+uNHB6CU/3oBXDDUs6UMDrH3LosgYentTyJYu1EEQ2qMcxUfhe7pu kij9xhSPgDAv4V+VfWS7w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Manuel.Pegourie-Gonnard@arm.com, "jose@ietf.org" , Nat Sakimura Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 18:06:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4R2FqDWCKWqoRnUrrxVGax1Q3tMJB3iN7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Just adding a bit more info after a chat with my co-worker Manuel (on CC)= =2E If you use the OpenSSL tools then you can generate the SubjectPublicKeyInfo structure with the following commands: > openssl ecparam -genkey -name prime256v1 -out ec.key && openssl ec -in ec.key -pubout -outform der -out ec.pub > dumpasn1 ec.pub 0 89: SEQUENCE { 2 19: SEQUENCE { 4 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 13 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) : } 23 66: BIT STRING : 04 58 74 31 8E DB 77 7C D3 AA 13 E0 81 D2 2C 0F : F1 CA 15 89 5B 50 F5 E2 5F AF 45 DC 3D 29 17 64 : B2 0F 1A BE DE A3 77 70 CB D2 0F B5 6B 5F 11 92 : C6 38 BE 6A F6 0B 2F 80 B7 AE 7E 4A 0A 33 C4 14 : AC : } Ciao Hannes On 03/11/2015 06:23 PM, Hannes Tschofenig wrote: > Mike, >=20 > I did this in the context of the work on the raw public key document fo= r > TLS. >=20 > Using an ASN.1 parser makes sense since the SubjectPublicKeyInfo is not= > just a blog but an ASN.1 structure that looks differently depending on > the type of keys encoding (ECC vs. RSA). >=20 > My code was done as part of the TLS stack itself it is not as usable as= > a command line tool. >=20 > You referenced https://tools.ietf.org/html/rfc7250#appendix-A and this > was created by extracing the SubjectPublicKeyInfo field from a > self-signed certificate that was created with the OpenSSL tools. >=20 > Ciao > Hannes >=20 >=20 > On 03/11/2015 06:16 AM, Mike Jones wrote: >> I=92ve always loved learning new things, so I decided yesterday to try= to >> learn first-hand how to write code that emitted X.509 >> SubjectPublicKeyInfo (SPKI) values from scratch. By =93from scratch=94= , I >> mean using development tools without built-in X.509 or ASN.1 support. >> >> =20 >> >> I took this on because of Stephen=92s suggestion >> http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that >> people could just hash the SPKI values to create a key thumbprint.=20 >> Given I=92d helped create the JSON-based hash input described in >> http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I wanted= >> to give his alternative suggestion a fair shake (and learn some new >> things along the way). This admittedly stream-of-consciousness and >> overly long message describes my expedition to date=85 >> >> =20 >> >> Thus far, I=92ve spent 5 hours trying to learn to do this. I spent ab= out >> the first two hours searching for examples of creating the bytes of >> X.509 certificates or SubjectPublicKeyInfo values without using ASN.1 >> and/or X.509 libraries. I failed. >> >> =20 >> >> Next, I tried to read the authoritative reference for what=92s in the = SPKI >> field =96 the X.509 spec. Unfortunately, >> http://www.itu.int/rec/T-REC-X.509/en told me =93This text was produce= d >> through a joint activity with ISO and IEC. According to the agreement >> with our partners, this document is only available through payment.=94= =20 >> Since most developers would stop at that point, I did too. >> >> =20 >> >> After that, I changed tacks and tried to find examples of sample >> certificates with commentary on what all the values mean =96 the kind = of >> info developers would want when coding this. I had better luck with >> that. After about another hour of Web searching, I found this really >> useful example: http://tools.ietf.org/html/rfc7250#appendix-A. I also= >> found this one: >> http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. Going >> through them byte-by-byte enabled me to reverse engineer some of the >> ASN.1 and X.509 constructs used. >> >> =20 >> >> Things I learned by looking at these 1024-bit RSA public key >> representations included: >> >> =B7 ASN.1 uses byte-aligned Tag-Length-Value encodings. >> >> =B7 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER a= re >> respectively 0x30, 0x06, 0x05, 0x03, and 0x02. >> >> =B7 These Length values are encoded as follows: >> >> o 159 =96 0x81 0x9f >> >> o 9 =96 0x09 >> >> o 0 =96 0x00 >> >> =B7 The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a = 0x86 >> 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. >> >> =B7 The OID is followed by an ASN.1 NULL - 0x05 0x00. >> >> =B7 The RSA Key is represented as an encapsulated bit field. >> >> =B7 There is an apparently unused zero byte (the 22^nd byte of = the >> SPKI field in the RFC 7250 example) as the first byte of this bit fiel= d. >> >> =B7 The rest of the bit field contains concatenated representat= ions >> of the modulus and the exponent as ASN.1 INTEGERs. >> >> =B7 The 1024 bit modulus is represented in 129 bytes, with the >> first byte being zero. >> >> =20 >> >> This brought me up to hour four. Next, I went looking for a 2048 bit >> cert to learn from (especially since JWA requires 2048+ bit RSA keys).= =20 >> I found http://fm4dd.com/openssl/certexamples.htm and chose >> 2048b-rsa-example-cert.der, from which I also learned: >> >> =B7 These length values are encoded as follows: >> >> o 290 =96 0x82 0x01 0x22 >> >> o 257 =96 0x82 0x01 0x01 >> >> =B7 From this, I deduced (possibly incorrectly J) that if the h= igh >> bit of the first length byte is 0, the remaining 7 bits represent the >> length, but if the high bit of the first length byte is 1, the remaini= ng >> 7 bits represent the number of bytes used to represent the actual >> length. (Hence the use of 0x81 for representing values in the range >> 128-255 and the use of 0x82 for representing values in the range 256-3= 2767.) >> >> =B7 Length values are represented in big-endian byte order. >> >> =B7 The 2048 bit key representation also starts with an apparen= tly >> unused zero byte. >> >> =B7 The 2048 bit modulus is represented by 257 bytes, with the >> first byte being zero. >> >> =20 >> >> Things I haven=92t yet learned that I=92d need to know to really write= this >> code: >> >> =B7 How are the OIDs in the table at >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appe= ndix-A >> represented as ASN.1 OID values? >> >> =B7 Are multiple OIDs sometimes present before the ASN.1 NULL, = and >> if so, which algorithms require which sets of OIDs in what order? >> >> =B7 Is there always the apparently unused zero byte in the key >> representation or if not, when is it present and absent? >> >> =B7 Is there always a leading zero byte in the RSA modulus or i= f >> not, when is it present and absent? >> >> =B7 How are elliptic curve keys represented? >> >> =20 >> >> This brought me up to about the fifth hour of my investigation, and I >> decided to stop and write up my findings to date. Highlighted version= s >> of the example certificate from RFC 7250 and the SPKI value from >> fm4dd.com are attached, should any of you want to follow along with my= >> reverse engineering. Tags are yellow. Lengths are green. OIDs are >> purple. The apparently unused byte is red. Key values are blue. >> >> =20 >> >> I readily admit that I could have easily missed something while >> searching. If someone can point me to self-contained descriptions of >> this information, I=92d love to see them! >> >> =20 >> >> =3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D >> >> =20 >> >> 1. I think it would be a fine thing to do to write an RFC describing >> the mapping between key values and their SPKI representations. This >> could take the form of a cookbook with entries like =93For a 2048 bit = RSA >> key using RSASSA with SHA-256, emit these bytes, filling in slots A an= d >> B in the template with the 256 bites of the mantissa and the 3 bytes o= f >> the exponent=94. Based on my searching, I don=92t think this informat= ion >> exists anywhere in a self-contained form accessible to developers (but= I >> could be wrong, of course). I=92m not going to personally do it, but = if >> any of you want go for it, have at it! >> >> =20 >> >> 2. If my experience is representative, telling developers to just has= h >> the SPKI representation of a JWK won=92t be very effective unless they= >> already have X.509 support. Most will probably give up well before th= e >> 5 hours that I=92ve invested to get this this partial understanding of= >> what I=92d need to know. If my experience is representative, >> draft-ietf-jose-jwk-thumbprint will be much easier to implement for >> these developers. >> >> =20 >> >> Trying to live in the shoes of developer= s, >> >> -- Mike >> >> =20 >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 --4R2FqDWCKWqoRnUrrxVGax1Q3tMJB3iN7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVAIQHAAoJEGhJURNOOiAtQv8H/R5T12DHUel5dbq75Po0QzxH mhyGvEh3fBjjvK9dTn1BDTGwwxjFoeAGw/V4LRbH9Wh2VkLIo1Q49SlqB2AkVfrU nLFHSjLAbOu7CzERHPGTVnU/TVOzThOdvX69Pdd8QMC4jYPQ7ZMiXYpUuCgVvrRT pn4gg2fzJrmN6eNzHTMVnaEG0NN3VTQmGl6YGkJ7rCbrYQ1lO3gzI5BDu01dPFWq zXOwZjwaX3iymPwdebWDQxEqRQJXmD4q9tRijGYWuT/osqs2SWXTP77Lh+NiBp04 AWCOhq3Aoxj5aNFxzhOQKES7VttaYjkFuDoncr0XSdSN/B8KGp7byzSG77t4lf4= =3/Bk -----END PGP SIGNATURE----- --4R2FqDWCKWqoRnUrrxVGax1Q3tMJB3iN7-- From nobody Wed Mar 11 11:17:01 2015 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 641201A1DBE for ; Wed, 11 Mar 2015 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgTXLze7MYwT for ; Wed, 11 Mar 2015 11:16:47 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792081A1BE3 for ; Wed, 11 Mar 2015 11:16:47 -0700 (PDT) Received: by qgdz107 with SMTP id z107so12156061qgd.3 for ; Wed, 11 Mar 2015 11:16:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=e5K8QW+bcLHBeLPirIQvswcz31j1YwrYeT78b9XvDJE=; b=CuXlgCwJe8ZBbsmSMnv6Osa1dqkoSWtRiqO/yOf/geAjgV/ie3OqKYEwiBecqBk7QG FhIemh8vIYPf6Bh2jIaZuYvCGxrssGwny6CHgkl+W1bwjuglBliiIDpYyMYTcqZOqEfx NiWYrkD8f1geHsKP1bmhFiKyM0Xz76AqFORAotlWdlnd1DDtT19L7k7qmsfJh1aGDret ZFiLoiYkMMWxAKVQ00x+It+3vJdBFhNGYfx8a6fVodTd2k7ne0imQxt3Cnk9kx64IHjw 7cNHH9OkAWz6XCLSLCDzzXqYvJZddVhsLGj2uGJ5/Uif4cVGDj57tqLgoxhvZGXk55zB CVtA== X-Gm-Message-State: ALoCoQm+oZmKNUqVMco05D1qZwHbXDaUAiXE140K4mhNPsGs7/QHBitehiZwXToYNETwucRBwAHk X-Received: by 10.55.33.193 with SMTP id f62mr9866661qki.1.1426097806387; Wed, 11 Mar 2015 11:16:46 -0700 (PDT) Received: from [192.168.8.100] ([181.202.7.165]) by mx.google.com with ESMTPSA id r136sm3063965qha.0.2015.03.11.11.16.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Mar 2015 11:16:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_551586B8-971C-491D-8B78-308358AC4857"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <55008407.1080804@gmx.net> Date: Wed, 11 Mar 2015 15:16:40 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> <55007A17.9000808@gmx.net> <55008407.1080804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Nat Sakimura , Michael Jones , Manuel.Pegourie-Gonnard@arm.com, "jose@ietf.org" , Stephen Farrell Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 18:16:54 -0000 --Apple-Mail=_551586B8-971C-491D-8B78-308358AC4857 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 How do you generate it from a raw key in JWK based on "crv", "kty" , "x" = and "y" ? > On Mar 11, 2015, at 3:05 PM, Hannes Tschofenig = wrote: >=20 > Just adding a bit more info after a chat with my co-worker Manuel (on = CC). >=20 > If you use the OpenSSL tools then you can generate the > SubjectPublicKeyInfo structure with the following commands: >=20 >> openssl ecparam -genkey -name prime256v1 -out ec.key && openssl ec = -in > ec.key -pubout -outform der -out ec.pub >=20 >> dumpasn1 ec.pub >=20 > 0 89: SEQUENCE { > 2 19: SEQUENCE { > 4 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) > 13 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) > : } > 23 66: BIT STRING > : 04 58 74 31 8E DB 77 7C D3 AA 13 E0 81 D2 2C 0F > : F1 CA 15 89 5B 50 F5 E2 5F AF 45 DC 3D 29 17 64 > : B2 0F 1A BE DE A3 77 70 CB D2 0F B5 6B 5F 11 92 > : C6 38 BE 6A F6 0B 2F 80 B7 AE 7E 4A 0A 33 C4 14 > : AC > : } >=20 > Ciao > Hannes >=20 > On 03/11/2015 06:23 PM, Hannes Tschofenig wrote: >> Mike, >>=20 >> I did this in the context of the work on the raw public key document = for >> TLS. >>=20 >> Using an ASN.1 parser makes sense since the SubjectPublicKeyInfo is = not >> just a blog but an ASN.1 structure that looks differently depending = on >> the type of keys encoding (ECC vs. RSA). >>=20 >> My code was done as part of the TLS stack itself it is not as usable = as >> a command line tool. >>=20 >> You referenced https://tools.ietf.org/html/rfc7250#appendix-A and = this >> was created by extracing the SubjectPublicKeyInfo field from a >> self-signed certificate that was created with the OpenSSL tools. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On 03/11/2015 06:16 AM, Mike Jones wrote: >>> I=92ve always loved learning new things, so I decided yesterday to = try to >>> learn first-hand how to write code that emitted X.509 >>> SubjectPublicKeyInfo (SPKI) values from scratch. By =93from = scratch=94, I >>> mean using development tools without built-in X.509 or ASN.1 = support. >>>=20 >>>=20 >>>=20 >>> I took this on because of Stephen=92s suggestion >>> http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that >>> people could just hash the SPKI values to create a key thumbprint.=20= >>> Given I=92d helped create the JSON-based hash input described in >>> http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I = wanted >>> to give his alternative suggestion a fair shake (and learn some new >>> things along the way). This admittedly stream-of-consciousness and >>> overly long message describes my expedition to date=85 >>>=20 >>>=20 >>>=20 >>> Thus far, I=92ve spent 5 hours trying to learn to do this. I spent = about >>> the first two hours searching for examples of creating the bytes of >>> X.509 certificates or SubjectPublicKeyInfo values without using = ASN.1 >>> and/or X.509 libraries. I failed. >>>=20 >>>=20 >>>=20 >>> Next, I tried to read the authoritative reference for what=92s in = the SPKI >>> field =96 the X.509 spec. Unfortunately, >>> http://www.itu.int/rec/T-REC-X.509/en told me =93This text was = produced >>> through a joint activity with ISO and IEC. According to the = agreement >>> with our partners, this document is only available through payment.=94= =20 >>> Since most developers would stop at that point, I did too. >>>=20 >>>=20 >>>=20 >>> After that, I changed tacks and tried to find examples of sample >>> certificates with commentary on what all the values mean =96 the = kind of >>> info developers would want when coding this. I had better luck with >>> that. After about another hour of Web searching, I found this = really >>> useful example: http://tools.ietf.org/html/rfc7250#appendix-A. I = also >>> found this one: >>> http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. Going >>> through them byte-by-byte enabled me to reverse engineer some of the >>> ASN.1 and X.509 constructs used. >>>=20 >>>=20 >>>=20 >>> Things I learned by looking at these 1024-bit RSA public key >>> representations included: >>>=20 >>> =B7 ASN.1 uses byte-aligned Tag-Length-Value encodings. >>>=20 >>> =B7 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER = are >>> respectively 0x30, 0x06, 0x05, 0x03, and 0x02. >>>=20 >>> =B7 These Length values are encoded as follows: >>>=20 >>> o 159 =96 0x81 0x9f >>>=20 >>> o 9 =96 0x09 >>>=20 >>> o 0 =96 0x00 >>>=20 >>> =B7 The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as = 0x2a 0x86 >>> 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. >>>=20 >>> =B7 The OID is followed by an ASN.1 NULL - 0x05 0x00. >>>=20 >>> =B7 The RSA Key is represented as an encapsulated bit field. >>>=20 >>> =B7 There is an apparently unused zero byte (the 22^nd byte = of the >>> SPKI field in the RFC 7250 example) as the first byte of this bit = field. >>>=20 >>> =B7 The rest of the bit field contains concatenated = representations >>> of the modulus and the exponent as ASN.1 INTEGERs. >>>=20 >>> =B7 The 1024 bit modulus is represented in 129 bytes, with = the >>> first byte being zero. >>>=20 >>>=20 >>>=20 >>> This brought me up to hour four. Next, I went looking for a 2048 = bit >>> cert to learn from (especially since JWA requires 2048+ bit RSA = keys).=20 >>> I found http://fm4dd.com/openssl/certexamples.htm and chose >>> 2048b-rsa-example-cert.der, from which I also learned: >>>=20 >>> =B7 These length values are encoded as follows: >>>=20 >>> o 290 =96 0x82 0x01 0x22 >>>=20 >>> o 257 =96 0x82 0x01 0x01 >>>=20 >>> =B7 =46rom this, I deduced (possibly incorrectly J) that if = the high >>> bit of the first length byte is 0, the remaining 7 bits represent = the >>> length, but if the high bit of the first length byte is 1, the = remaining >>> 7 bits represent the number of bytes used to represent the actual >>> length. (Hence the use of 0x81 for representing values in the range >>> 128-255 and the use of 0x82 for representing values in the range = 256-32767.) >>>=20 >>> =B7 Length values are represented in big-endian byte order. >>>=20 >>> =B7 The 2048 bit key representation also starts with an = apparently >>> unused zero byte. >>>=20 >>> =B7 The 2048 bit modulus is represented by 257 bytes, with = the >>> first byte being zero. >>>=20 >>>=20 >>>=20 >>> Things I haven=92t yet learned that I=92d need to know to really = write this >>> code: >>>=20 >>> =B7 How are the OIDs in the table at >>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix= -A >>> represented as ASN.1 OID values? >>>=20 >>> =B7 Are multiple OIDs sometimes present before the ASN.1 = NULL, and >>> if so, which algorithms require which sets of OIDs in what order? >>>=20 >>> =B7 Is there always the apparently unused zero byte in the = key >>> representation or if not, when is it present and absent? >>>=20 >>> =B7 Is there always a leading zero byte in the RSA modulus or = if >>> not, when is it present and absent? >>>=20 >>> =B7 How are elliptic curve keys represented? >>>=20 >>>=20 >>>=20 >>> This brought me up to about the fifth hour of my investigation, and = I >>> decided to stop and write up my findings to date. Highlighted = versions >>> of the example certificate from RFC 7250 and the SPKI value from >>> fm4dd.com are attached, should any of you want to follow along with = my >>> reverse engineering. Tags are yellow. Lengths are green. OIDs are >>> purple. The apparently unused byte is red. Key values are blue. >>>=20 >>>=20 >>>=20 >>> I readily admit that I could have easily missed something while >>> searching. If someone can point me to self-contained descriptions = of >>> this information, I=92d love to see them! >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D >>>=20 >>>=20 >>>=20 >>> 1. I think it would be a fine thing to do to write an RFC = describing >>> the mapping between key values and their SPKI representations. This >>> could take the form of a cookbook with entries like =93For a 2048 = bit RSA >>> key using RSASSA with SHA-256, emit these bytes, filling in slots A = and >>> B in the template with the 256 bites of the mantissa and the 3 bytes = of >>> the exponent=94. Based on my searching, I don=92t think this = information >>> exists anywhere in a self-contained form accessible to developers = (but I >>> could be wrong, of course). I=92m not going to personally do it, = but if >>> any of you want go for it, have at it! >>>=20 >>>=20 >>>=20 >>> 2. If my experience is representative, telling developers to just = hash >>> the SPKI representation of a JWK won=92t be very effective unless = they >>> already have X.509 support. Most will probably give up well before = the >>> 5 hours that I=92ve invested to get this this partial understanding = of >>> what I=92d need to know. If my experience is representative, >>> draft-ietf-jose-jwk-thumbprint will be much easier to implement for >>> these developers. >>>=20 >>>=20 >>>=20 >>> Trying to live in the shoes of = developers, >>>=20 >>> -- Mike >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_551586B8-971C-491D-8B78-308358AC4857 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTExODE2NDFaMCMGCSqGSIb3DQEJBDEWBBQKwNGcH7z5F1/W4iGnaZW4 Ft33LzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB0GbfKG45+D7IT/irzsAObhhT57qMkxwyM6q/mHr8Fr70c8ZuIzrU+ uqJQYpDWTCKU6TBbImvxoVWkG0ePHvmGHzBDIrrj2tKY1KRnBMXVDIZSibrtGupuJHsEd2RittuU iaLwWoJ0/D08MKkb2TBb7bHCwErMf1I1ABtDQH2adbFHQFpA6BP+wL2QgREVG9nqV+FCN8mdjMLz doovYgopQadE5uKwa7d/ZbjOrkQST8iQRlXzSfrgwEcGkUWRjo0kojS5Wqtc9el6Of/lf6+doyX8 NvxPdhRE87Ebc+W7jXbouvOxO0ppT80OIo2a6hRX2kHbtEfQUyaudfoK7BmMAAAAAAAA --Apple-Mail=_551586B8-971C-491D-8B78-308358AC4857-- From nobody Wed Mar 11 11:26:26 2015 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 153DE1A1BB3 for ; Wed, 11 Mar 2015 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1hZ6dDlIHln for ; Wed, 11 Mar 2015 11:26:21 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7B91A1BA7 for ; Wed, 11 Mar 2015 11:26:20 -0700 (PDT) Received: by labhs14 with SMTP id hs14so10246796lab.5 for ; Wed, 11 Mar 2015 11:26:18 -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=dJhi42qwFui0MzMHfsA6+oxAARRAva9bZTGZULgdNXw=; b=QqV0XKG9OJ7K1SBbWhsXeOMSu3vqIjeKSZjZsjCEpUzpam4fDF09ZBgjyX61O8ypWP joOgqHKM8EUvYKgNVkv+D/MjWeVqA0Swpmu1DsI1vMJVbuUryyF2poflwx2fomdhpyhu ZzmSnl0cSdMAhhLbZ8rNJ4/e+hT1vfCmHxwThjOy0C8W/QMcs5hXZbgwNF+FO2MmgQVL r3/cCP2fns8HWlOqskg4qft4VSBrtHBBl8jmbmMcgcPvmzx8fZ1ErYQVJ9kyU7MJuChm 4vxoF4LyxHTtJmO8SaXxJfD0EJflkMipNZLrMIILYFJjaGl47KnBKOYREJrRdBZhGVmi kTgw== X-Gm-Message-State: ALoCoQnhMhLjfTrGqWetcZKiwQl7evuWZ6rI2GnZCxuUzlUmuGK8PDZZgWc0Ko8WSmTCfxbqjGsP MIME-Version: 1.0 X-Received: by 10.152.1.1 with SMTP id 1mr35164048lai.63.1426098378653; Wed, 11 Mar 2015 11:26:18 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Wed, 11 Mar 2015 11:26:18 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> <55007A17.9000808@gmx.net> <55008407.1080804@gmx.net> Date: Wed, 11 Mar 2015 11:26:18 -0700 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=089e013c6af0465ce605110767ec Archived-At: Cc: Nat Sakimura , Manuel.Pegourie-Gonnard@arm.com, Michael Jones , "jose@ietf.org" , Hannes Tschofenig , Stephen Farrell Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 11 Mar 2015 18:26:25 -0000 --089e013c6af0465ce605110767ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You could do a similar template thing to what I posted above, but with different values. On Wed, Mar 11, 2015 at 11:16 AM, John Bradley wrote: > How do you generate it from a raw key in JWK based on "crv", "kty" , "x" > and "y" ? > > > > > On Mar 11, 2015, at 3:05 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > > > Just adding a bit more info after a chat with my co-worker Manuel (on > CC). > > > > If you use the OpenSSL tools then you can generate the > > SubjectPublicKeyInfo structure with the following commands: > > > >> openssl ecparam -genkey -name prime256v1 -out ec.key && openssl ec -in > > ec.key -pubout -outform der -out ec.pub > > > >> dumpasn1 ec.pub > > > > 0 89: SEQUENCE { > > 2 19: SEQUENCE { > > 4 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) > > 13 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) > > : } > > 23 66: BIT STRING > > : 04 58 74 31 8E DB 77 7C D3 AA 13 E0 81 D2 2C 0F > > : F1 CA 15 89 5B 50 F5 E2 5F AF 45 DC 3D 29 17 64 > > : B2 0F 1A BE DE A3 77 70 CB D2 0F B5 6B 5F 11 92 > > : C6 38 BE 6A F6 0B 2F 80 B7 AE 7E 4A 0A 33 C4 14 > > : AC > > : } > > > > Ciao > > Hannes > > > > On 03/11/2015 06:23 PM, Hannes Tschofenig wrote: > >> Mike, > >> > >> I did this in the context of the work on the raw public key document f= or > >> TLS. > >> > >> Using an ASN.1 parser makes sense since the SubjectPublicKeyInfo is no= t > >> just a blog but an ASN.1 structure that looks differently depending on > >> the type of keys encoding (ECC vs. RSA). > >> > >> My code was done as part of the TLS stack itself it is not as usable a= s > >> a command line tool. > >> > >> You referenced https://tools.ietf.org/html/rfc7250#appendix-A and this > >> was created by extracing the SubjectPublicKeyInfo field from a > >> self-signed certificate that was created with the OpenSSL tools. > >> > >> Ciao > >> Hannes > >> > >> > >> On 03/11/2015 06:16 AM, Mike Jones wrote: > >>> I=E2=80=99ve always loved learning new things, so I decided yesterday= to try to > >>> learn first-hand how to write code that emitted X.509 > >>> SubjectPublicKeyInfo (SPKI) values from scratch. By =E2=80=9Cfrom sc= ratch=E2=80=9D, I > >>> mean using development tools without built-in X.509 or ASN.1 support. > >>> > >>> > >>> > >>> I took this on because of Stephen=E2=80=99s suggestion > >>> http://www.ietf.org/mail-archive/web/jose/current/msg04954.html that > >>> people could just hash the SPKI values to create a key thumbprint. > >>> Given I=E2=80=99d helped create the JSON-based hash input described i= n > >>> http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03, I wante= d > >>> to give his alternative suggestion a fair shake (and learn some new > >>> things along the way). This admittedly stream-of-consciousness and > >>> overly long message describes my expedition to date=E2=80=A6 > >>> > >>> > >>> > >>> Thus far, I=E2=80=99ve spent 5 hours trying to learn to do this. I s= pent about > >>> the first two hours searching for examples of creating the bytes of > >>> X.509 certificates or SubjectPublicKeyInfo values without using ASN.1 > >>> and/or X.509 libraries. I failed. > >>> > >>> > >>> > >>> Next, I tried to read the authoritative reference for what=E2=80=99s = in the > SPKI > >>> field =E2=80=93 the X.509 spec. Unfortunately, > >>> http://www.itu.int/rec/T-REC-X.509/en told me =E2=80=9CThis text was = produced > >>> through a joint activity with ISO and IEC. According to the agreement > >>> with our partners, this document is only available through payment.= =E2=80=9D > >>> Since most developers would stop at that point, I did too. > >>> > >>> > >>> > >>> After that, I changed tacks and tried to find examples of sample > >>> certificates with commentary on what all the values mean =E2=80=93 th= e kind of > >>> info developers would want when coding this. I had better luck with > >>> that. After about another hour of Web searching, I found this really > >>> useful example: http://tools.ietf.org/html/rfc7250#appendix-A. I als= o > >>> found this one: > >>> http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html. Going > >>> through them byte-by-byte enabled me to reverse engineer some of the > >>> ASN.1 and X.509 constructs used. > >>> > >>> > >>> > >>> Things I learned by looking at these 1024-bit RSA public key > >>> representations included: > >>> > >>> =C2=B7 ASN.1 uses byte-aligned Tag-Length-Value encodings. > >>> > >>> =C2=B7 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEG= ER are > >>> respectively 0x30, 0x06, 0x05, 0x03, and 0x02. > >>> > >>> =C2=B7 These Length values are encoded as follows: > >>> > >>> o 159 =E2=80=93 0x81 0x9f > >>> > >>> o 9 =E2=80=93 0x09 > >>> > >>> o 0 =E2=80=93 0x00 > >>> > >>> =C2=B7 The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0= x2a > 0x86 > >>> 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. > >>> > >>> =C2=B7 The OID is followed by an ASN.1 NULL - 0x05 0x00. > >>> > >>> =C2=B7 The RSA Key is represented as an encapsulated bit field= . > >>> > >>> =C2=B7 There is an apparently unused zero byte (the 22^nd byte= of the > >>> SPKI field in the RFC 7250 example) as the first byte of this bit > field. > >>> > >>> =C2=B7 The rest of the bit field contains concatenated > representations > >>> of the modulus and the exponent as ASN.1 INTEGERs. > >>> > >>> =C2=B7 The 1024 bit modulus is represented in 129 bytes, with = the > >>> first byte being zero. > >>> > >>> > >>> > >>> This brought me up to hour four. Next, I went looking for a 2048 bit > >>> cert to learn from (especially since JWA requires 2048+ bit RSA keys)= . > >>> I found http://fm4dd.com/openssl/certexamples.htm and chose > >>> 2048b-rsa-example-cert.der, from which I also learned: > >>> > >>> =C2=B7 These length values are encoded as follows: > >>> > >>> o 290 =E2=80=93 0x82 0x01 0x22 > >>> > >>> o 257 =E2=80=93 0x82 0x01 0x01 > >>> > >>> =C2=B7 From this, I deduced (possibly incorrectly J) that if t= he high > >>> bit of the first length byte is 0, the remaining 7 bits represent the > >>> length, but if the high bit of the first length byte is 1, the > remaining > >>> 7 bits represent the number of bytes used to represent the actual > >>> length. (Hence the use of 0x81 for representing values in the range > >>> 128-255 and the use of 0x82 for representing values in the range > 256-32767.) > >>> > >>> =C2=B7 Length values are represented in big-endian byte order. > >>> > >>> =C2=B7 The 2048 bit key representation also starts with an app= arently > >>> unused zero byte. > >>> > >>> =C2=B7 The 2048 bit modulus is represented by 257 bytes, with = the > >>> first byte being zero. > >>> > >>> > >>> > >>> Things I haven=E2=80=99t yet learned that I=E2=80=99d need to know to= really write this > >>> code: > >>> > >>> =C2=B7 How are the OIDs in the table at > >>> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendi= x-A > >>> represented as ASN.1 OID values? > >>> > >>> =C2=B7 Are multiple OIDs sometimes present before the ASN.1 NU= LL, and > >>> if so, which algorithms require which sets of OIDs in what order? > >>> > >>> =C2=B7 Is there always the apparently unused zero byte in the = key > >>> representation or if not, when is it present and absent? > >>> > >>> =C2=B7 Is there always a leading zero byte in the RSA modulus = or if > >>> not, when is it present and absent? > >>> > >>> =C2=B7 How are elliptic curve keys represented? > >>> > >>> > >>> > >>> This brought me up to about the fifth hour of my investigation, and I > >>> decided to stop and write up my findings to date. Highlighted versio= ns > >>> of the example certificate from RFC 7250 and the SPKI value from > >>> fm4dd.com are attached, should any of you want to follow along with m= y > >>> reverse engineering. Tags are yellow. Lengths are green. OIDs are > >>> purple. The apparently unused byte is red. Key values are blue. > >>> > >>> > >>> > >>> I readily admit that I could have easily missed something while > >>> searching. If someone can point me to self-contained descriptions of > >>> this information, I=E2=80=99d love to see them! > >>> > >>> > >>> > >>> =3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D > >>> > >>> > >>> > >>> 1. I think it would be a fine thing to do to write an RFC describing > >>> the mapping between key values and their SPKI representations. This > >>> could take the form of a cookbook with entries like =E2=80=9CFor a 20= 48 bit RSA > >>> key using RSASSA with SHA-256, emit these bytes, filling in slots A a= nd > >>> B in the template with the 256 bites of the mantissa and the 3 bytes = of > >>> the exponent=E2=80=9D. Based on my searching, I don=E2=80=99t think = this information > >>> exists anywhere in a self-contained form accessible to developers (bu= t > I > >>> could be wrong, of course). I=E2=80=99m not going to personally do i= t, but if > >>> any of you want go for it, have at it! > >>> > >>> > >>> > >>> 2. If my experience is representative, telling developers to just ha= sh > >>> the SPKI representation of a JWK won=E2=80=99t be very effective unle= ss they > >>> already have X.509 support. Most will probably give up well before t= he > >>> 5 hours that I=E2=80=99ve invested to get this this partial understan= ding of > >>> what I=E2=80=99d need to know. If my experience is representative, > >>> draft-ietf-jose-jwk-thumbprint will be much easier to implement for > >>> these developers. > >>> > >>> > >>> > >>> Trying to live in the shoes of developer= s, > >>> > >>> -- Mike > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >>> > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > >> > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e013c6af0465ce605110767ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You could do a similar template thing to what I posted abo= ve, but with different values.

On Wed, Mar 11, 2015 at 11:16 AM, John Bradley <ve7= jtb@ve7jtb.com> wrote:
How = do you generate it from a raw key in JWK based on "crv", "kt= y" , "x" and "y" ?



> On Mar 11, 2015, at 3:05 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Just adding a bit more info after a chat with my co-worker Manuel (on = CC).
>
> If you use the OpenSSL tools then you can generate the
> SubjectPublicKeyInfo structure with the following commands:
>
>> openssl ecparam -genkey -name prime256v1 -out ec.key && op= enssl ec -in
> ec.key -pubout -outform der -out ec.pub
>
>> dumpasn1 ec.pub
>
>=C2=A0 0=C2=A0 89: SEQUENCE {
>=C2=A0 2=C2=A0 19:=C2=A0 =C2=A0SEQUENCE {
>=C2=A0 4=C2=A0 =C2=A07:=C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER ecPublicKe= y (1 2 840 10045 2 1)
> 13=C2=A0 =C2=A08:=C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER prime256v1 (1 2= 840 10045 3 1 7)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0}
> 23=C2=A0 66:=C2=A0 =C2=A0BIT STRING
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A004 58 74 31 8E DB 77 7C= D3 AA 13 E0 81 D2 2C 0F
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0F1 CA 15 89 5B 50 F5 E2= 5F AF 45 DC 3D 29 17 64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0B2 0F 1A BE DE A3 77 70= CB D2 0F B5 6B 5F 11 92
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0C6 38 BE 6A F6 0B 2F 80= B7 AE 7E 4A 0A 33 C4 14
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0AC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0}
>
> Ciao
> Hannes
>
> On 03/11/2015 06:23 PM, Hannes Tschofenig wrote:
>> Mike,
>>
>> I did this in the context of the work on the raw public key docume= nt for
>> TLS.
>>
>> Using an ASN.1 parser makes sense since the SubjectPublicKeyInfo i= s not
>> just a blog but an ASN.1 structure that looks differently dependin= g on
>> the type of keys encoding (ECC vs. RSA).
>>
>> My code was done as part of the TLS stack itself it is not as usab= le as
>> a command line tool.
>>
>> You referenced https://tools.ietf.org/html/rfc7250#appendix-A and this
>> was created by extracing the SubjectPublicKeyInfo field from a
>> self-signed certificate that was created with the OpenSSL tools. >>
>> Ciao
>> Hannes
>>
>>
>> On 03/11/2015 06:16 AM, Mike Jones wrote:
>>> I=E2=80=99ve always loved learning new things, so I decided ye= sterday to try to
>>> learn first-hand how to write code that emitted X.509
>>> SubjectPublicKeyInfo (SPKI) values from scratch.=C2=A0 By =E2= =80=9Cfrom scratch=E2=80=9D, I
>>> mean using development tools without built-in X.509 or ASN.1 s= upport.
>>>
>>>
>>>
>>> I took this on because of Stephen=E2=80=99s suggestion
>>>
http://www.ietf.org/mail-archive/web/jose/c= urrent/msg04954.html that
>>> people could just hash the SPKI values to create a key thumbpr= int.
>>> Given I=E2=80=99d helped create the JSON-based hash input desc= ribed in
>>> http://tools.ietf.org/html/draft-ietf-jose-jwk= -thumbprint-03, I wanted
>>> to give his alternative suggestion a fair shake (and learn som= e new
>>> things along the way).=C2=A0 This admittedly stream-of-conscio= usness and
>>> overly long message describes my expedition to date=E2=80=A6 >>>
>>>
>>>
>>> Thus far, I=E2=80=99ve spent 5 hours trying to learn to do thi= s.=C2=A0 I spent about
>>> the first two hours searching for examples of creating the byt= es of
>>> X.509 certificates or SubjectPublicKeyInfo values without usin= g ASN.1
>>> and/or X.509 libraries.=C2=A0 I failed.
>>>
>>>
>>>
>>> Next, I tried to read the authoritative reference for what=E2= =80=99s in the SPKI
>>> field =E2=80=93 the X.509 spec.=C2=A0 Unfortunately,
>>> http://www.itu.int/rec/T-REC-X.509/en told me =E2=80=9CThis text = was produced
>>> through a joint activity with ISO and IEC. According to the ag= reement
>>> with our partners, this document is only available through pay= ment.=E2=80=9D
>>> Since most developers would stop at that point, I did too.
>>>
>>>
>>>
>>> After that, I changed tacks and tried to find examples of samp= le
>>> certificates with commentary on what all the values mean =E2= =80=93 the kind of
>>> info developers would want when coding this.=C2=A0 I had bette= r luck with
>>> that.=C2=A0 After about another hour of Web searching, I found= this really
>>> useful example: http://tools.ietf.org/html/rfc7250#appendix-A= .=C2=A0 I also
>>> found this one:
>>> http://www.jensign.com/JavaScience/dotnet/JKey= Net/index.html.=C2=A0 Going
>>> through them byte-by-byte enabled me to reverse engineer some = of the
>>> ASN.1 and X.509 constructs used.
>>>
>>>
>>>
>>> Things I learned by looking at these 1024-bit RSA public key >>> representations included:
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 ASN.1 uses byte-aligned Tag-= Length-Value encodings.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The tags for SEQUENCE, OID, = NULL, BIT STRING, and INTEGER are
>>> respectively 0x30, 0x06, 0x05, 0x03, and 0x02.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 These Length values are enco= ded as follows:
>>>
>>> o=C2=A0 =C2=A0159 =E2=80=93 0x81 0x9f
>>>
>>> o=C2=A0 =C2=A09 =E2=80=93 0x09
>>>
>>> o=C2=A0 =C2=A00 =E2=80=93 0x00
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The OID 1.2.840.113549.1.1.1= is encoded in 9 bytes as 0x2a 0x86
>>> 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The OID is followed by an AS= N.1 NULL - 0x05 0x00.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The RSA Key is represented a= s an encapsulated bit field.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 There is an apparently unuse= d zero byte (the 22^nd byte of the
>>> SPKI field in the RFC 7250 example) as the first byte of this = bit field.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The rest of the bit field co= ntains concatenated representations
>>> of the modulus and the exponent as ASN.1 INTEGERs.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The 1024 bit modulus is repr= esented in 129 bytes, with the
>>> first byte being zero.
>>>
>>>
>>>
>>> This brought me up to hour four.=C2=A0 Next, I went looking fo= r a 2048 bit
>>> cert to learn from (especially since JWA requires 2048+ bit RS= A keys).
>>> I found http://fm4dd.com/openssl/certexamples.htm and chose >>> 2048b-rsa-example-cert.der, from which I also learned:
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 These length values are enco= ded as follows:
>>>
>>> o=C2=A0 =C2=A0290 =E2=80=93 0x82 0x01 0x22
>>>
>>> o=C2=A0 =C2=A0257 =E2=80=93 0x82 0x01 0x01
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 From this, I deduced (possib= ly incorrectly J) that if the high
>>> bit of the first length byte is 0, the remaining 7 bits repres= ent the
>>> length, but if the high bit of the first length byte is 1, the= remaining
>>> 7 bits represent the number of bytes used to represent the act= ual
>>> length.=C2=A0 (Hence the use of 0x81 for representing values i= n the range
>>> 128-255 and the use of 0x82 for representing values in the ran= ge 256-32767.)
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 Length values are represente= d in big-endian byte order.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The 2048 bit key representat= ion also starts with an apparently
>>> unused zero byte.
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 The 2048 bit modulus is repr= esented by 257 bytes, with the
>>> first byte being zero.
>>>
>>>
>>>
>>> Things I haven=E2=80=99t yet learned that I=E2=80=99d need to = know to really write this
>>> code:
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 How are the OIDs in the tabl= e at
>>> http://tools.ietf.org/html/dra= ft-ietf-jose-json-web-algorithms-40#appendix-A
>>> represented as ASN.1 OID values?
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 Are multiple OIDs sometimes = present before the ASN.1 NULL, and
>>> if so, which algorithms require which sets of OIDs in what ord= er?
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is there always the apparent= ly unused zero byte in the key
>>> representation or if not, when is it present and absent?
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is there always a leading ze= ro byte in the RSA modulus or if
>>> not, when is it present and absent?
>>>
>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 How are elliptic curve keys = represented?
>>>
>>>
>>>
>>> This brought me up to about the fifth hour of my investigation= , and I
>>> decided to stop and write up my findings to date.=C2=A0 Highli= ghted versions
>>> of the example certificate from RFC 7250 and the SPKI value fr= om
>>> fm4dd.com a= re attached, should any of you want to follow along with my
>>> reverse engineering.=C2=A0 Tags are yellow.=C2=A0 Lengths are = green.=C2=A0 OIDs are
>>> purple.=C2=A0 The apparently unused byte is red.=C2=A0 Key val= ues are blue.
>>>
>>>
>>>
>>> I readily admit that I could have easily missed something whil= e
>>> searching.=C2=A0 If someone can point me to self-contained des= criptions of
>>> this information, I=E2=80=99d love to see them!
>>>
>>>
>>>
>>> =3D=3D=3D=3D CONCLUSIONS =3D=3D=3D=3D
>>>
>>>
>>>
>>> 1.=C2=A0 I think it would be a fine thing to do to write an RF= C describing
>>> the mapping between key values and their SPKI representations.= =C2=A0 This
>>> could take the form of a cookbook with entries like =E2=80=9CF= or a 2048 bit RSA
>>> key using RSASSA with SHA-256, emit these bytes, filling in sl= ots A and
>>> B in the template with the 256 bites of the mantissa and the 3= bytes of
>>> the exponent=E2=80=9D.=C2=A0 Based on my searching, I don=E2= =80=99t think this information
>>> exists anywhere in a self-contained form accessible to develop= ers (but I
>>> could be wrong, of course).=C2=A0 I=E2=80=99m not going to per= sonally do it, but if
>>> any of you want go for it, have at it!
>>>
>>>
>>>
>>> 2.=C2=A0 If my experience is representative, telling developer= s to just hash
>>> the SPKI representation of a JWK won=E2=80=99t be very effecti= ve unless they
>>> already have X.509 support.=C2=A0 Most will probably give up w= ell before the
>>> 5 hours that I=E2=80=99ve invested to get this this partial un= derstanding of
>>> what I=E2=80=99d need to know.=C2=A0 If my experience is repre= sentative,
>>> draft-ietf-jose-jwk-thumbprint will be much easier to implemen= t for
>>> these developers.
>>>
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Trying to live in the shoes of de= velopers,
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


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


--089e013c6af0465ce605110767ec-- From nobody Wed Mar 11 17:29:55 2015 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 5FFFC1A88F4 for ; Wed, 11 Mar 2015 17:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] 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 r-bIerV2_KhH for ; Wed, 11 Mar 2015 17:29:51 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 123AC1A889D for ; Wed, 11 Mar 2015 17:29:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,385,1422882000"; d="scan'208,217";a="275589244" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 Mar 2015 11:09:41 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7737"; a="306128093" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 12 Mar 2015 11:29:47 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 12 Mar 2015 11:29:46 +1100 From: "Manger, James" To: Mike Jones , "jose@ietf.org" Date: Thu, 12 Mar 2015 11:29:45 +1100 Thread-Topic: My quest to learn how to create SubjectPublicKeyInfo values from scratch Thread-Index: AdBbunvjG3Fobl38T+ib6QLqsv0XzAAmMgSg Message-ID: <255B9BB34FB7D647A506DC292726F6E12855654940@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E12855654940WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 12 Mar 2015 00:29:54 -0000 --_000_255B9BB34FB7D647A506DC292726F6E12855654940WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> Things I learned by looking at these 1024-bit RSA public key representat= ions included: * ASN.1 uses byte-aligned Tag-Length-Value encodings. * The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER are res= pectively 0x30, 0x06, 0x05, 0x03, and 0x02. * These Length values are encoded as follows: o 159 - 0x81 0x9f o 9 - 0x09 o 0 - 0x00 * The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 0= x48 0x86 0xf7 0x0d 0x01 0x01 0x01. * The OID is followed by an ASN.1 NULL - 0x05 0x00. * The RSA Key is represented as an encapsulated bit field. * There is an apparently unused zero byte (the 22nd byte of the SPK= I field in the RFC 7250 example) as the first byte of this bit field. The ASN.1 BIT STRING is DER-encoded as: |Tag|Len |Value | | | |Unused-bit-count Bits-paddeded-with-0-bits | | 03| 818D| 00 30818902... | For a BIT SRING, the value part of the tag-length-value starts with 1 byte = that holds the number of unused bits in the last byte of the value. As an example, the 7 bits 1110001 are DER-encoded as 03(tag) 02(length) 01(= unused bit count) E2(bits plus 1 unused bit) * The rest of the bit field contains concatenated representations o= f the modulus and the exponent as ASN.1 INTEGERs. The modulus and exponent are encapsulated in a SEQUENCE (tag byte 0x30), no= t just concatenated. * The 1024 bit modulus is represented in 129 bytes, with the first = byte being zero. Integers are represented in 2's-complement to handle positive and negative = integers. If the top bit of the first byte is 1 you have a negative integer= . Hence, you need an extra leading 0x00 byte for some positive integers. > RSA_2048_PREFIX =3D "30820122300D06092A864886F70D01010105000382010F003082= 010A02820101"; There are plenty of "2048-bit RSA keys" where the modulus is actually 2047-= bits long (multiply two 1024-bit primes and you get a 2048-bit or 2047-bit = modulus). There is no extra leading 0x00 byte when DER-encoding a 2047-bit = modulus. Consequently, concatenating a fixed prefix to build a DER-encoding= is likely to cause interop bugs. * How are the OIDs in the table at http://tools.ietf.org/html/draft= -ietf-jose-json-web-algorithms-40#appendix-A represented as ASN.1 OID value= s? Example: HS256 1.2.840.113549.2.9 Believe it or not, the first step to DER-encode an OID is to convert the fi= rst two numbers (1.2.) to a single number. Multiple the first by 40 and add= the second: 1*40 + 2 =3D 42 =3D 0x2A (aren't standards great ;). Now 42 an= d the following four numbers are each represented with a variable-length en= coding: 7 bits per byte; 8th bit (most significant bit) indicates if there = are more bytes to follow. Example: 113549 =3D 6*2^14 + 119 * 2^7 + 13 =3D> encoded in 3 bytes 86 F7 0= D, which you can see in the middle of RSA_2048_PREFIX above. P.S. The draft splits the number 113549 (and JCA labels) over two lines. Yu= ck. Might be better to put the XML DSIG uris in a separate table to avoid w= rapping. * Is there always the apparently unused zero byte in the key repres= entation or if not, when is it present and absent? Whenever you put a whole number of bytes into a BIT STRING you get the 0x00= byte as there are no unused bits. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E12855654940WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

>> Things = I learned by looking at these 1024-bit RSA public key representations inclu= ded:

·      &n= bsp;  ASN.1 uses byt= e-aligned Tag-Length-Value encodings.

· = ;        = The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGE= R are respectively 0x30, 0x06, 0x05, 0x03, and 0x02.

<= p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l2 level1 = lfo2'>= ·         These Length values are encoded as follow= s:

o   <= /span>159 – 0x81 0x9f<= /span>

o   <= ![endif]>9 – 0x09

o   0 – 0x00

·   &= nbsp;     The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 0x48 0= x86 0xf7 0x0d 0x01 0x01 0x01.

·  &= nbsp;      The OID is followed by an ASN.1 NULL - 0x05 0x00.

·         <= /span>The RSA Key is represented as an = encapsulated bit field.

·   &= nbsp;     There is an apparently unused zero byte (the 22nd byte of t= he SPKI field in the RFC 7250 example) as the first byte of this bit field.=

 

The ASN.1 BIT STRING is DER-encoded as:

|Tag|Len  |Value     =              &n= bsp;            = ;        |

|   |     |Unused-bit-count  Bits= -paddeded-with-0-bits |

| 03| 818D| 00 =              &n= bsp;30818902…          &= nbsp;      |    

 

For a BIT SRING, the value part of the tag-length-value= starts with 1 byte that holds the number of unused bits in the last byte o= f the value.

As an example, the 7 bits 1110001 are DER-encoded as= 03(tag) 02(length) 01(unused bit count) E2(bits plus 1 unused bit)

 

·     &nb= sp;   The rest = of the bit field contains concatenated representations of the modulus and t= he exponent as ASN.1 INTEGERs.

 

The modulus and e= xponent are encapsulated in a SEQUENCE (tag byte 0x30), not just concatenat= ed.

 

= ·   &nbs= p;     The 1024 bit modulus is represented in 129 bytes, with the first byte bei= ng zero.

=  

Integers are represented in 2’s-complement to handle posi= tive and negative integers. If the top bit of the first byte is 1 you have = a negative integer. Hence, you need an extra leading 0x00 byte for some pos= itive integers.

 

= > RSA_2048_PREFIX =3D "30820122300D06092A864886F70D0101010500038201= 0F003082010A02820101";

There are plenty of “2048-bit RSA keys” where the= modulus is actually 2047-bits long (multiply two 1024-bit primes and you g= et a 2048-bit or 2047-bit modulus). There is no extra leading 0x00 byte whe= n DER-encoding a 2047-bit modulus. Consequently, concatenating a fixed pref= ix to build a DER-encoding is likely to cause interop bugs.

=  

·       = ;  How are the OIDs = in the table at http://tools.ietf.org/html/draft-ietf-jose-js= on-web-algorithms-40#appendix-A represented as ASN.1 OID values?

 

Example: HS= 256   1.2.840.113549.2.9

 

Believe it or not, the= first step to DER-encode an OID is to convert the first two numbers (1.2.)= to a single number. Multiple the first by 40 and add the second: 1*40 + 2 = =3D 42 =3D 0x2A (aren’t standards great ;). Now 42 and the following = four numbers are each represented with a variable-length encoding: 7 bits p= er byte; 8th bit (most significant bit) indicates if there are m= ore bytes to follow.

Example: 11= 3549 =3D 6*2^14 + 119 * 2^7 + 13 =3D> encoded in 3 bytes 86 F7 0D, which= you can see in the middle of RSA_2048_PREFIX above.

<= p class=3DMsoListParagraph style=3D'margin-left:0cm'> 

P.S.= The draft splits the number 113549 (and JCA labels) over two lines. Yuck. = Might be better to put the XML DSIG uris in a separate table to avoid wrapp= ing.

 

·         = Is there always the apparently unused z= ero byte in the key representation or if not, when is it present and absent= ?

 

Whenever you put a whole number of bytes into = a BIT STRING you get the 0x00 byte as there are no unused bits.<= /span>

<= o:p> 

 

--

James Manger

= --_000_255B9BB34FB7D647A506DC292726F6E12855654940WSMSG3153Vsrv_-- From nobody Wed Mar 11 17:50:24 2015 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 558471A8993 for ; Wed, 11 Mar 2015 17:50:23 -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 QLHES36hoZbD for ; Wed, 11 Mar 2015 17:50:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0134.outbound.protection.outlook.com [207.46.100.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B491A8991 for ; Wed, 11 Mar 2015 17:50:15 -0700 (PDT) Received: from CH1PR03CA011.namprd03.prod.outlook.com (10.255.156.156) by CY1PR0301MB0617.namprd03.prod.outlook.com (25.160.142.24) with Microsoft SMTP Server (TLS) id 15.1.99.9; Thu, 12 Mar 2015 00:50:15 +0000 Received: from BN1BFFO11FD046.protection.gbl (10.255.156.132) by CH1PR03CA011.outlook.office365.com (10.255.156.156) with Microsoft SMTP Server (TLS) id 15.1.112.16 via Frontend Transport; Thu, 12 Mar 2015 00:50:14 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD046.mail.protection.outlook.com (10.58.145.1) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Thu, 12 Mar 2015 00:50:14 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.148]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0224.003; Thu, 12 Mar 2015 00:49:47 +0000 From: Mike Jones To: "Manger, James" Thread-Topic: My quest to learn how to create SubjectPublicKeyInfo values from scratch Thread-Index: AdBbunvjG3Fobl38T+ib6QLqsv0XzAAmMgSgAAIxMyA= Date: Thu, 12 Mar 2015 00:49:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2F4C5B4@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E12855654940@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E12855654940@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2F4C5B4TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; 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; team.telstra.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(438002)(43784003)(52604005)(189002)(377454003)(199003)(19617315012)(19580405001)(86612001)(6806004)(110136001)(19580395003)(104016003)(19300405004)(46102003)(33656002)(92566002)(86362001)(62966003)(77156002)(54356999)(575784001)(102836002)(16236675004)(84326002)(50986999)(76176999)(87936001)(2656002)(512954002)(2920100001)(2900100001)(16297215004)(15975445007)(66066001)(106466001)(2950100001)(55846006)(7059030)(16503001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0617; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0617; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:CY1PR0301MB0617; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0617; X-Forefront-PRVS: 05134F8B4F X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2015 00:50:14.1369 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]; Helo=[mail.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0617 Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 12 Mar 2015 00:50:23 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2F4C5B4TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for explaining about the unused bit count, James. Another mystery s= olved! Your point about 2048 bit keys sometimes being 2047 bits in length seems qu= ite pertinent, as it changes the encoded key length (and therefore several = other encoded lengths) by a byte. About the draft splitting the number 113549 (and JCA labels) over two lines= , I'll plan to work with the RFC editor to see what we can do about that. Thanks agai= n, -- Mike From: Manger, James [mailto:James.H.Manger@team.telstra.com] Sent: Wednesday, March 11, 2015 5:30 PM To: Mike Jones; jose@ietf.org Subject: RE: My quest to learn how to create SubjectPublicKeyInfo values fr= om scratch >> Things I learned by looking at these 1024-bit RSA public key representat= ions included: * ASN.1 uses byte-aligned Tag-Length-Value encodings. * The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER are res= pectively 0x30, 0x06, 0x05, 0x03, and 0x02. * These Length values are encoded as follows: o 159 - 0x81 0x9f o 9 - 0x09 o 0 - 0x00 * The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 0= x48 0x86 0xf7 0x0d 0x01 0x01 0x01. * The OID is followed by an ASN.1 NULL - 0x05 0x00. * The RSA Key is represented as an encapsulated bit field. * There is an apparently unused zero byte (the 22nd byte of the SPK= I field in the RFC 7250 example) as the first byte of this bit field. The ASN.1 BIT STRING is DER-encoded as: |Tag|Len |Value | | | |Unused-bit-count Bits-paddeded-with-0-bits | | 03| 818D| 00 30818902... | For a BIT SRING, the value part of the tag-length-value starts with 1 byte = that holds the number of unused bits in the last byte of the value. As an example, the 7 bits 1110001 are DER-encoded as 03(tag) 02(length) 01(= unused bit count) E2(bits plus 1 unused bit) * The rest of the bit field contains concatenated representations o= f the modulus and the exponent as ASN.1 INTEGERs. The modulus and exponent are encapsulated in a SEQUENCE (tag byte 0x30), no= t just concatenated. * The 1024 bit modulus is represented in 129 bytes, with the first = byte being zero. Integers are represented in 2's-complement to handle positive and negative = integers. If the top bit of the first byte is 1 you have a negative integer= . Hence, you need an extra leading 0x00 byte for some positive integers. > RSA_2048_PREFIX =3D "30820122300D06092A864886F70D01010105000382010F003082= 010A02820101"; There are plenty of "2048-bit RSA keys" where the modulus is actually 2047-= bits long (multiply two 1024-bit primes and you get a 2048-bit or 2047-bit = modulus). There is no extra leading 0x00 byte when DER-encoding a 2047-bit = modulus. Consequently, concatenating a fixed prefix to build a DER-encoding= is likely to cause interop bugs. * How are the OIDs in the table at http://tools.ietf.org/html/draft= -ietf-jose-json-web-algorithms-40#appendix-A represented as ASN.1 OID value= s? Example: HS256 1.2.840.113549.2.9 Believe it or not, the first step to DER-encode an OID is to convert the fi= rst two numbers (1.2.) to a single number. Multiple the first by 40 and add= the second: 1*40 + 2 =3D 42 =3D 0x2A (aren't standards great ;). Now 42 an= d the following four numbers are each represented with a variable-length en= coding: 7 bits per byte; 8th bit (most significant bit) indicates if there = are more bytes to follow. Example: 113549 =3D 6*2^14 + 119 * 2^7 + 13 =3D> encoded in 3 bytes 86 F7 0= D, which you can see in the middle of RSA_2048_PREFIX above. P.S. The draft splits the number 113549 (and JCA labels) over two lines. Yu= ck. Might be better to put the XML DSIG uris in a separate table to avoid w= rapping. * Is there always the apparently unused zero byte in the key repres= entation or if not, when is it present and absent? Whenever you put a whole number of bytes into a BIT STRING you get the 0x00= byte as there are no unused bits. -- James Manger --_000_4E1F6AAD24975D4BA5B1680429673943A2F4C5B4TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for explaining = about the unused bit count, James.  Another mystery solved!=

 

Your point about 2048 = bit keys sometimes being 2047 bits in length seems quite pertinent, as it c= hanges the encoded key length (and therefore several other encoded lengths)= by a byte.

 

About the draft splitting the number 113549 (and JCA labels)= over two lines, I’ll plan to work with the RFC editor to see what we= can do about that.

 

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

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

 

From: Manger, = James [mailto:James.H.Manger@team.telstra.com]
Sent: Wednesday, March 11, 2015 5:30 PM
To: Mike Jones; jose@ietf.org
Subject: RE: My quest to learn how to create SubjectPublicKeyInfo va= lues from scratch

 

&n= bsp;

>> Things= I learned by looking at these 1024-bit RSA public key representations incl= uded:

·         ASN.1 uses byte-aligned Tag-Length-Value enc= odings.

·         The tags for SEQUENCE, OID, NULL, BIT STRING= , and INTEGER are respectively 0x30, 0x06, 0x05, 0x03, and 0x02.=

·         These Length values are encoded as follows:<= o:p>

o   159 – 0x81 0x9f

o   9 – 0x09

o   0 – 0x00

·         The OID 1.2.840.113549.1.1.1 is encoded in 9= bytes as 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01.

·         The OID is followed by an ASN.1 NULL - 0x05 = 0x00.

·         The RSA Key is represented as an encapsulate= d bit field.

·         There is an apparently unused zero byte (the= 22nd byte of the SPKI field in the RFC 7250 example) as the fir= st byte of this bit field.

 

The ASN.1 BIT STRING i= s DER-encoded as:

|= Tag|Len  |Value         &= nbsp;            &nb= sp;            =     |

|=    |     |Unused-bit-count  Bits-paddede= d-with-0-bits |

|= 03| 818D| 00          &n= bsp;    30818902…       =           |  &n= bsp; 

 

For a BIT SRING, the v= alue part of the tag-length-value starts with 1 byte that holds the number = of unused bits in the last byte of the value.

As an example, the 7 b= its 1110001 are DER-encoded as 03(tag) 02(length) 01(unused bit count) E2(b= its plus 1 unused bit)

 

·         The rest of the bit field contains concatena= ted representations of the modulus and the exponent as ASN.1 INTEGERs.=

 

The modulus and expone= nt are encapsulated in a SEQUENCE (tag byte 0x30), not just concatenated.

 

·         The 1024 bit modulus is represented in 129 b= ytes, with the first byte being zero.

 

Integers are represent= ed in 2’s-complement to handle positive and negative integers. If the= top bit of the first byte is 1 you have a negative integer. Hence, you nee= d an extra leading 0x00 byte for some positive integers.

 

= > RSA_2048_PREFIX =3D "30820122300D06092A864886F70D0101010500038201= 0F003082010A02820101";=

There are plenty of &#= 8220;2048-bit RSA keys” where the modulus is actually 2047-bits long = (multiply two 1024-bit primes and you get a 2048-bit or 2047-bit modulus). = There is no extra leading 0x00 byte when DER-encoding a 2047-bit modulus. Consequently, concatenating a fixed prefix to build a = DER-encoding is likely to cause interop bugs.

 

·         How are the OIDs in the table at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A represented as ASN.1 OID values?

 

Example: HS256   1.2.840.113549.2.9<= /p>

 

Believe it or not, the first step to DER-encode an OID is to con= vert the first two numbers (1.2.) to a single number. Multiple the first by= 40 and add the second: 1*40 + 2 =3D 42 =3D 0x2A (aren’t standards great ;). Now 42 and the following four n= umbers are each represented with a variable-length encoding: 7 bits per byt= e; 8th bit (most significant bit) indicates if there are more by= tes to follow.

Example: 113549 =3D 6*2^14 + 119 * 2^7 + 13 =3D> enco= ded in 3 bytes 86 F7 0D, which you can see in the middle of RSA_2048_PREFIX= above.

 

P.S. The draft splits the number 113549 (and JCA labels) over tw= o lines. Yuck. Might be better to put the XML DSIG uris in a separate table= to avoid wrapping.

 

·         Is there always the apparently unused zero b= yte in the key representation or if not, when is it present and absent?

 

Whenever you put a who= le number of bytes into a BIT STRING you get the 0x00 byte as there are no = unused bits.

 

 

--

James Manger

--_000_4E1F6AAD24975D4BA5B1680429673943A2F4C5B4TK5EX14MBXC292r_-- From nobody Wed Mar 11 20:58:04 2015 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 93DD31A8A3E for ; Wed, 11 Mar 2015 20:57:56 -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 U_gmk_Nr-3cY for ; Wed, 11 Mar 2015 20:57:53 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8CD1A8A27 for ; Wed, 11 Mar 2015 20:57:51 -0700 (PDT) Received: from Philemon (ip-64-134-132-146.public.wayport.net [64.134.132.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 2CCEB2CA26; Wed, 11 Mar 2015 20:57:51 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> Date: Wed, 11 Mar 2015 20:56:47 -0700 Message-ID: <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F1F_01D05C3D.E7F94D60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJeXUdN+AvHxI03P38QRReVQq26kZv8EM8w Content-Language: en-us Archived-At: Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 12 Mar 2015 03:57:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0F1F_01D05C3D.E7F94D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I cannot respond for Richard, but personally I feel rather insulted by the current draft. My first half a dozen responses were rather vulgar and pejorative to this draft and thus deleted. This draft seems to be, more or less, what Richard and I were proposing in Denver and were told was not possible due to backwards compatibility. What has changed that this is no longer true? Why is there need to have a compact formation for this draft? We were told in no uncertain terms that this was completely unnecessary in Denver and thus was out of scope for the documents. This document does not seem to have read the security considerations section of the JWS draft specifically dealing with the existence of multiple sharers of the secret key. This document has messed up the current documentation in JWE about how to determine what type of document is being presented. This is completely unacceptable. There are now multiple representations of direct keying for mac. This is a significant problem as one does not know which of the version one is supposed to be using. (The fact that I am half, if not all the way drunk has make this message much easier to write). Jim From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, March 03, 2015 2:42 AM To: jose@ietf.org Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification I took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload. We had considered doing this in JOSE issue #2 but didn't do so at the time because of lack of demand. However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future - possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-0 0 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature -00.html. This spec reuses key management functionality already present in the JWE spec and MAC functionality already present in the JWS spec . The result is essentially a JWS with an Encrypted Key value added, and a new "mac" Header Parameter value representing the MAC algorithm used. (Like JWE, the key management algorithm is carried in the "alg" Header Parameter value.) I also wrote this now as possible input into our thinking on options for creating a CBOR JOSE mapping. If there are CBOR use cases needing managed MAC keys, this could help us reason about ways to structure the solution. Yes, the spec name and abbreviation are far from catchy. Better naming ideas would be great. Feedback welcomed. -- Mike P.S. This note was also posted at http://self-issued.info/?p=1344 and as @selfissued. ------=_NextPart_000_0F1F_01D05C3D.E7F94D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I cannot respond for Richard, but personally I = feel rather insulted by the current draft.  My first half a dozen = responses were rather vulgar and pejorative to this draft and thus = deleted.

 

This draft seems to be, = more or less, what Richard and I were proposing in Denver and were told = was not possible due to backwards compatibility.  What has changed = that this is no longer true?

 

Why is there  need = to have a compact formation for this draft?  We were told in no = uncertain terms that this was completely unnecessary in Denver and thus = was out of scope for the documents.

 

This document does not = seem to have read the security considerations section of the JWS draft = specifically dealing with the existence of multiple sharers of the = secret key.

 

This document has messed = up the current documentation in JWE about how to determine what type of = document is being presented.  This is completely = unacceptable.

 

There are now multiple = representations of direct keying for mac.  This is a significant = problem as one does not know which of the version one is supposed to be = using.

 

(The fact that I am = half, if not all the way drunk has make this message much easier to = write).

 

Jim

 

 

From:= = jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Tuesday, March 03, 2015 2:42 AM
To: = jose@ietf.org
Subject: [jose] Key Managed JSON Web Signature = (KMJWS) specification

 

I took a = little time today and wrote a short draft specifying a JWS-like object = that uses key management for the MAC key used to integrity protect the = payload.  We had considered doing this in JOSE issue = #2 but didn’t do so at the time because of lack of = demand.  However, I wanted to get this down now to demonstrate that = it is easy to do and specify a way to do it, should demand develop in = the future – possibly after the JOSE working = group has been closed.  See http://tools.ietf.org/html/draft-jones-jose-key-managed-jso= n-web-signature-00 or http://self-issued.info/docs/draft-jones-jose-key-ma= naged-json-web-signature-00.html.

 

This spec = reuses key management functionality already present in the J= WE spec and MAC functionality already present in the JW= S spec.  The result is essentially a JWS with an Encrypted Key = value added, and a new “mac” Header Parameter value representing the MAC = algorithm used.  (Like JWE, the key management algorithm is carried = in the “alg” Header Parameter value.)

 

I also wrote = this now as possible input into our thinking on options for creating a = CBOR JOSE = mapping.  If there are CBOR use cases needing managed MAC keys, = this could help us reason about ways to structure the = solution.

 

Yes, the spec name and abbreviation are far from = catchy.  Better naming ideas would be great.

 

Feedback = welcomed.

 

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

 

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

 

------=_NextPart_000_0F1F_01D05C3D.E7F94D60-- From nobody Wed Mar 11 22:39:49 2015 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 910751A8A68 for ; Wed, 11 Mar 2015 22:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glLYXDLemuul for ; Wed, 11 Mar 2015 22:39:45 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3271A0334 for ; Wed, 11 Mar 2015 22:39:44 -0700 (PDT) Received: by labge10 with SMTP id ge10so13445941lab.7 for ; Wed, 11 Mar 2015 22:39:43 -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=jpOM/qSVez4zdaFuYo7OXzwiaU8th/kpdzaKntb1Jio=; b=GGixM2x+Nbs74JAoFZ8Tt+kk7FrPZN/ZmKIWiv4ouGCaV63o5Tz1MH9cjFFDlsLsK1 3635TZTOSbhDqyk+p1Fxnu5Rm3jwdZ/c9QHGrq/szzOWBdPPLgq2DGNr0TE8qBYgnjMg 98o+yzdX+fPetC+H75nVgYoQ9DcycaHX2BDWO1TwqxzvczkrZfKsO3Fkq1rX86adQcZq CybnhrdRS52Euf/RO5kPcoQbk6S/5ISlWRdGGh1g1dcbYHJ/4aBiONMmNj1v5Cw2nU1L SR55MgBx4jP5QMCckpV24EZecvPr7jUxxEk684gFijGt+iKXCCpoGeW0TV9SsSWeHSb/ L32Q== X-Gm-Message-State: ALoCoQmK/dBw+5z0PQnQBy3YEaS7ri7pLK1RVilAb2cBuOSVl4LbfbkkpaL98AsGLhrfeEMOoHJh MIME-Version: 1.0 X-Received: by 10.152.179.139 with SMTP id dg11mr31769983lac.28.1426138783132; Wed, 11 Mar 2015 22:39:43 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Wed, 11 Mar 2015 22:39:43 -0700 (PDT) In-Reply-To: <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> References: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> Date: Wed, 11 Mar 2015 22:39:43 -0700 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1134919291c3ec051110cfc6 Archived-At: Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 12 Mar 2015 05:39:47 -0000 --001a1134919291c3ec051110cfc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was simply going to note with bemusement that exactly this eventuality was foreseen by those of us that favored a more general approach to key wrapping [0][1]. Those that dismissed that idea have made their bed full of complexity, and now they are lying in it. At this point, the least harmful approach would be to simply define an "ek" header field that contains an encrypted key, in the form of a JWE containing a JWK [0]. [0] http://tools.ietf.org/agenda/85/slides/slides-85-jose-7.pdf [1] http://tools.ietf.org/agenda/86/slides/slides-86-jose-0.pdf On Wed, Mar 11, 2015 at 8:56 PM, Jim Schaad wrote: > I cannot respond for Richard, but personally I feel rather insulted by th= e > current draft. My first half a dozen responses were rather vulgar and > pejorative to this draft and thus deleted. > > > > This draft seems to be, more or less, what Richard and I were proposing i= n > Denver and were told was not possible due to backwards compatibility. Wh= at > has changed that this is no longer true? > > > > Why is there need to have a compact formation for this draft? We were > told in no uncertain terms that this was completely unnecessary in Denver > and thus was out of scope for the documents. > > > > This document does not seem to have read the security considerations > section of the JWS draft specifically dealing with the existence of > multiple sharers of the secret key. > > > > This document has messed up the current documentation in JWE about how to > determine what type of document is being presented. This is completely > unacceptable. > > > > There are now multiple representations of direct keying for mac. This is > a significant problem as one does not know which of the version one is > supposed to be using. > > > > (The fact that I am half, if not all the way drunk has make this message > much easier to write). > > > > Jim > > > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Tuesday, March 03, 2015 2:42 AM > *To:* jose@ietf.org > *Subject:* [jose] Key Managed JSON Web Signature (KMJWS) specification > > > > I took a little time today and wrote a short draft specifying a JWS-like > object that uses key management for the MAC key used to integrity protect > the payload. We had considered doing this in JOSE issue #2 > but didn=E2=80=99t do = so at > the time because of lack of demand. However, I wanted to get this down n= ow > to demonstrate that it is easy to do and specify a way to do it, should > demand develop in the future =E2=80=93 possibly after the JOSE working gr= oup > has been closed. See > http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signatur= e-00 > or > http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signat= ure-00.html > . > > > > This spec reuses key management functionality already present in the JWE > spec and > MAC functionality already present in the JWS spec > . The > result is essentially a JWS with an Encrypted Key value added, and a new = =E2=80=9C > mac=E2=80=9D Header Parameter value representing the MAC algorithm used. = (Like > JWE, the key management algorithm is carried in the =E2=80=9Calg=E2=80=9D= Header > Parameter value.) > > > > I also wrote this now as possible input into our thinking on options for > creating a CBOR JOSE mapping. If > there are CBOR use cases needing managed MAC keys, this could help us > reason about ways to structure the solution. > > > > Yes, the spec name and abbreviation are far from catchy. Better naming > ideas would be great. > > > > Feedback welcomed. > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1344 and = as > @selfissued. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a1134919291c3ec051110cfc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was simply going to note with bemusement that exact= ly this eventuality was foreseen by those of us that favored a more general= approach to key wrapping [0][1].=C2=A0 Those that dismissed that idea have= made their bed full of complexity, and now they are lying in it.

At this point, the least harmful approach would be to simply define an = "ek" header field that contains an encrypted key, in the form of = a JWE containing a JWK [0].

On Wed, Mar 11, 2015 at 8:56 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I cannot respond for Richard, but pe= rsonally I feel rather insulted by the current draft.=C2=A0 My first half a= dozen responses were rather vulgar and pejorative to this draft and thus d= eleted.

=C2=A0

This draft seems to be, more or less, what Richard and I= were proposing in Denver and were told was not possible due to backwards c= ompatibility.=C2=A0 What has changed that this is no longer true?=

= =C2=A0

Why is there=C2=A0 need to have a compact formation for this draft?=C2=A0= We were told in no uncertain terms that this was completely unnecessary in= Denver and thus was out of scope for the documents.

=C2=A0=

This docume= nt does not seem to have read the security considerations section of the JW= S draft specifically dealing with the existence of multiple sharers of the = secret key.

=C2=A0

This document has messed up the current documentatio= n in JWE about how to determine what type of document is being presented.= =C2=A0 This is completely unacceptable.

=C2=A0

There are now multiple r= epresentations of direct keying for mac.=C2=A0 This is a significant proble= m as one does not know which of the version one is supposed to be using.=

= =C2=A0

(The fact that I am half, if not all the way drunk has make this m= essage much easier to write).

=C2=A0

Jim

=C2=A0<= /p>

=C2=A0

From= : jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike J= ones
Sent: Tuesday, March 03, 2015 2:42 AM
To: jose@ietf.org
Subject= : [jose] Key Managed JSON Web Signature (KMJWS) specification=

=C2=A0

I took a little time today and= wrote a short draft specifying a JWS-like object that uses key management = for the MAC key used to integrity protect the payload.=C2=A0 We had conside= red doing this in JOSE issue #2 but didn=E2=80=99t do so at the tim= e because of lack of demand.=C2=A0 However, I wanted to get this down now t= o demonstrate that it is easy to do and specify a way to do it, should dema= nd develop in the future =E2=80=93 possibly after the JOSE working group has been closed.=C2=A0 See http://tools.= ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jon= es-jose-key-managed-json-web-signature-00.html.

=C2=A0

This spec r= euses key management functionality already present in the JWE spec and MAC functionality already present in the JWS spec.=C2=A0 The result is essentially a JWS with an Encrypted Key = value added, and a new =E2=80=9Cmac=E2=80=9D Header Parameter value representing the MAC al= gorithm used.=C2=A0 (Like JWE, the key management algorithm is carried in t= he =E2=80=9Calg= =E2=80=9D Header Parameter value.)

= =C2=A0

I also wrote this now as pos= sible input into our thinking on options for creating a CBOR JOSE mapping.=C2=A0 = If there are CBOR use cases needing managed MAC keys, this could help us re= ason about ways to structure the solution.

=C2=A0

Yes, the spec name a= nd abbreviation are far from catchy.=C2=A0 Better naming ideas would be gre= at.

=C2=A0

Feedback welcomed.

= =C2=A0

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

=C2=A0

P.S.=C2=A0 This note was al= so posted at http://self-issued.info/?p=3D1344 and as @selfissued.

=C2=A0


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


--001a1134919291c3ec051110cfc6-- From nobody Wed Mar 11 22:45:08 2015 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 80CC31A8A6D for ; Wed, 11 Mar 2015 22:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlqksGInJBCo for ; Wed, 11 Mar 2015 22:45:05 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9CB1A8A70 for ; Wed, 11 Mar 2015 22:45:04 -0700 (PDT) Received: by labge10 with SMTP id ge10so13463709lab.7 for ; Wed, 11 Mar 2015 22:45:03 -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=Qn/RO0qMXn8kMxY+Ns0k4Hl932SvtMNHJi0K09SP/Zg=; b=b+3XhnLl/ukv55b5Jb+WV4MpwDAElmZcvTTahDxQuZVtTYqcKcqwOnysuQxEQDTLMy Y6tgU+NUpBEO5pxsPF1pLm30kIOZ6xbWSK49w0N1uBebscFgks0UVxVOW9kFJAObdeVC RhidpCSvzvfk+eEGkr+LgKwxFvPKFnN1tKHLcB6hU1tkUCdBl6XN4HMCu7qGmBYojz29 qRYyWOkK2ujNpzGt4W1IZyqxMg3w6H6oKOAC+84s6DMm7GBvuK4+3oPWJfcWtx57ZhRw VSyXUQmSrUTnhNmoYff0Yz+izAJDrtXn0p0y/LV51jsDNyM1NfTag9qdJUTfNWheGcz1 y0HA== X-Gm-Message-State: ALoCoQkOU+q9HZgeoKuWWcNVbLlRk+Az4TmsGXKEwcygNpL93SfNEwsr/Nwdu7J3+RvXJpWaOQ8o MIME-Version: 1.0 X-Received: by 10.112.110.231 with SMTP id id7mr37701424lbb.28.1426139103022; Wed, 11 Mar 2015 22:45:03 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Wed, 11 Mar 2015 22:45:02 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E12855654940@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E12855654940@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 11 Mar 2015 22:45:02 -0700 Message-ID: From: Richard Barnes To: "Manger, James" Content-Type: multipart/alternative; boundary=001a1134daf6a2ecf5051110e23b Archived-At: Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 12 Mar 2015 05:45:07 -0000 --001a1134daf6a2ecf5051110e23b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 11, 2015 at 5:29 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > > > >> Things I learned by looking at these 1024-bit RSA public key > representations included: > > =C2=B7 ASN.1 uses byte-aligned Tag-Length-Value encodings. > > =C2=B7 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER = are > respectively 0x30, 0x06, 0x05, 0x03, and 0x02. > > =C2=B7 These Length values are encoded as follows: > > o 159 =E2=80=93 0x81 0x9f > > o 9 =E2=80=93 0x09 > > o 0 =E2=80=93 0x00 > > =C2=B7 The OID 1.2.840.113549.1.1.1 is encoded in 9 bytes as 0x2a= 0x86 > 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01. > > =C2=B7 The OID is followed by an ASN.1 NULL - 0x05 0x00. > > =C2=B7 The RSA Key is represented as an encapsulated bit field. > > =C2=B7 There is an apparently unused zero byte (the 22nd byte of = the > SPKI field in the RFC 7250 example) as the first byte of this bit field. > > > > The ASN.1 BIT STRING is DER-encoded as: > > |Tag|Len |Value | > > | | |Unused-bit-count Bits-paddeded-with-0-bits | > > | 03| 818D| 00 30818902=E2=80=A6 | > > > > For a BIT SRING, the value part of the tag-length-value starts with 1 byt= e > that holds the number of unused bits in the last byte of the value. > > As an example, the 7 bits 1110001 are DER-encoded as 03(tag) 02(length) > 01(unused bit count) E2(bits plus 1 unused bit) > > > > =C2=B7 The rest of the bit field contains concatenated representa= tions > of the modulus and the exponent as ASN.1 INTEGERs. > > > > The modulus and exponent are encapsulated in a SEQUENCE (tag byte 0x30), > not just concatenated. > > > > =C2=B7 The 1024 bit modulus is represented in 129 bytes, with the > first byte being zero. > > > > Integers are represented in 2=E2=80=99s-complement to handle positive and= negative > integers. If the top bit of the first byte is 1 you have a negative > integer. Hence, you need an extra leading 0x00 byte for some positive > integers. > > > > > RSA_2048_PREFIX =3D > "30820122300D06092A864886F70D01010105000382010F003082010A02820101"; > > There are plenty of =E2=80=9C2048-bit RSA keys=E2=80=9D where the modulus= is actually > 2047-bits long (multiply two 1024-bit primes and you get a 2048-bit or > 2047-bit modulus). There is no extra leading 0x00 byte when DER-encoding = a > 2047-bit modulus. Consequently, concatenating a fixed prefix to build a > DER-encoding is likely to cause interop bugs. > I'm sorry, what? Could you please provide an example of two 1024-bit primes that multiply to a 2047-bit value? Last I checked, (1< 1<<(2*N). --Richard > > > =C2=B7 How are the OIDs in the table at > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendi= x-A > represented as ASN.1 OID values? > > > > Example: HS256 1.2.840.113549.2.9 > > > > Believe it or not, the first step to DER-encode an OID is to convert the > first two numbers (1.2.) to a single number. Multiple the first by 40 and > add the second: 1*40 + 2 =3D 42 =3D 0x2A (aren=E2=80=99t standards great = ;). Now 42 and > the following four numbers are each represented with a variable-length > encoding: 7 bits per byte; 8th bit (most significant bit) indicates if > there are more bytes to follow. > > Example: 113549 =3D 6*2^14 + 119 * 2^7 + 13 =3D> encoded in 3 bytes 86 F7= 0D, > which you can see in the middle of RSA_2048_PREFIX above. > > > > P.S. The draft splits the number 113549 (and JCA labels) over two lines. > Yuck. Might be better to put the XML DSIG uris in a separate table to avo= id > wrapping. > > > > =C2=B7 Is there always the apparently unused zero byte in the key > representation or if not, when is it present and absent? > > > > Whenever you put a whole number of bytes into a BIT STRING you get the > 0x00 byte as there are no unused bits. > > > > > > -- > > James Manger > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a1134daf6a2ecf5051110e23b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 11, 2015 at 5:29 PM, Manger, James <James.H.= Manger@team.telstra.com> wrote:

=C2=A0

>> Things I learned by looking at th= ese 1024-bit RSA public key representations included:<= /p>

=C2=B7= =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ASN.1 uses byte-aligned Tag-Length-Value encodings.

=C2= =B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER are respe= ctively 0x30, 0x06, 0x05, 0x03, and 0x02.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 These L= ength values are encoded as follows:

o=C2=A0=C2=A0 159 =E2= =80=93 0x81 0x9f

o=C2=A0=C2=A0 9 =E2=80=93 0x09

o=C2=A0=C2=A0 0 =E2=80=93 0x00

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The OID 1.2.840.= 113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x= 01 0x01.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The OID is followed by an ASN.1 NULL - 0x0= 5 0x00.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The RSA Key is represented as an encapsulat= ed bit field.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is an apparently unused zero by= te (the 22nd byte of the SPKI field in the RFC 7250 example) as = the first byte of this bit field.

=C2=A0

The ASN.1 BIT STRING is DER-encoded as:

|Tag|Len =C2=A0|Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|

|=C2=A0=C2=A0 |=C2=A0 =C2=A0=C2=A0=C2=A0|Unused-bit-count=C2=A0 Bits-= paddeded-with-0-bits |

| 03| 818D| 00= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A030818902=E2=80=A6 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2= =A0

=C2=A0

For a BIT SRING, the value pa= rt of the tag-length-value starts with 1 byte that holds the number of unus= ed bits in the last byte of the value.

As an example, the = 7 bits 1110001 are DER-encoded as 03(tag) 02(length) 01(unused bit count) E= 2(bits plus 1 unused bit)

=C2=A0

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The rest of the bit field contains concatenated representa= tions of the modulus and the exponent as ASN.1 INTEGERs.

<= u>=C2=A0

The modulus and exponent are encapsulated in = a SEQUENCE (tag byte 0x30), not just concatenated.

=

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = The 1024 bit modulus is represent= ed in 129 bytes, with the first byte being zero.

=C2=A0

In= tegers are represented in 2=E2=80=99s-complement to handle positive and neg= ative integers. If the top bit of the first byte is 1 you have a negative i= nteger. Hence, you need an extra leading 0x00 byte for some positive intege= rs.

=C2=A0

= > RSA_2048_PREFIX =3D "30820122300D06092A864886F70D0101010500038201= 0F003082010A02820101";

There are plenty of =E2=80=9C2048-bit RSA keys=E2=80= =9D where the modulus is actually 2047-bits long (multiply two 1024-bit pri= mes and you get a 2048-bit or 2047-bit modulus). There is no extra leading = 0x00 byte when DER-encoding a 2047-bit modulus. Consequently, concatenating= a fixed prefix to build a DER-encoding is likely to cause interop bugs.


I'm sorry, what?= =C2=A0 Could you please provide an example of two 1024-bit primes that mult= iply to a 2047-bit value?=C2=A0 Last I checked, (1<<N + x)*(1<<= N + y) > 1<<(2*N).

--Richard
=C2= =A0

=C2=A0

=C2= =B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 How are the OIDs in the table at ht= tp://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A<= /a> represented as ASN.1 OID values?

=C2=A0

<= p style=3D"margin-left:0cm">Ex= ample: HS256=C2=A0=C2=A0 1.2.840.113549.2.9

= =C2=A0

Believe it or not, the first step to DER-encode an O= ID is to convert the first two numbers (1.2.) to a single number. Multiple = the first by 40 and add the second: 1*40 + 2 =3D 42 =3D 0x2A (aren=E2=80=99= t standards great ;). Now 42 and the following four numbers are each repres= ented with a variable-length encoding: 7 bits per byte; 8th bit = (most significant bit) indicates if there are more bytes to follow.<= u>

Example: 113549 =3D 6*2^14 + 119 * 2^7 + 13 =3D> encoded= in 3 bytes 86 F7 0D, which you can see in the middle of RSA_2048_PREFIX ab= ove.

=C2=A0

P.S. The draft sp= lits the number 113549 (and JCA labels) over two lines. Yuck. Might be bett= er to put the XML DSIG uris in a separate table to avoid wrapping.

=C2=A0

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Is ther= e always the apparently unused zero byte in the key representation or if no= t, when is it present and absent?

=C2=A0

Whenever you put a whole number of bytes into a BIT STRING you get t= he 0x00 byte as there are no unused bits.

=C2=A0

=C2=A0

--

James Manger<= u>


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


--001a1134daf6a2ecf5051110e23b-- From nobody Thu Mar 12 00:04:15 2015 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 2CB031A0419 for ; Thu, 12 Mar 2015 00:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] 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 KiCjxzJ90QzE for ; Thu, 12 Mar 2015 00:04:12 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id F11ED1A0461 for ; Thu, 12 Mar 2015 00:04:11 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,387,1422882000"; d="scan'208,217"; a="66248427" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Mar 2015 17:37:55 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7737"; a="285555366" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 12 Mar 2015 18:04:11 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 12 Mar 2015 18:04:10 +1100 From: "Manger, James" To: Richard Barnes Date: Thu, 12 Mar 2015 18:04:08 +1100 Thread-Topic: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch Thread-Index: AdBch7JceKmZL0MORm2lyGFoJa1T5wACexEA Message-ID: <255B9BB34FB7D647A506DC292726F6E12855655143@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B1680429673943A2F496F5@TK5EX14MBXC292.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E12855654940@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E12855655143WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 12 Mar 2015 07:04:14 -0000 --_000_255B9BB34FB7D647A506DC292726F6E12855655143WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4+IFJTQV8yMDQ4X1BSRUZJWCA9ICIzMDgyMDEyMjMwMEQwNjA5MkE4NjQ4ODZGNzBEMDEwMTAx MDUwMDAzODIwMTBGMDAzMDgyMDEwQTAyODIwMTAxIjsNCj4+IFRoZXJlIGFyZSBwbGVudHkgb2Yg 4oCcMjA0OC1iaXQgUlNBIGtleXPigJ0gd2hlcmUgdGhlIG1vZHVsdXMgaXMgYWN0dWFsbHkgMjA0 Ny1iaXRzIGxvbmcgKG11bHRpcGx5IHR3byAxMDI0LWJpdCBwcmltZXMgYW5kIHlvdSBnZXQgYSAy MDQ4LWJpdCBvciAyMDQ3LWJpdCBtb2R1bHVzKS4gVGhlcmUgaXMgbm8gZXh0cmEgbGVhZGluZyAw eDAwIGJ5dGUgd2hlbiBERVItZW5jb2RpbmcgYSAyMDQ3LWJpdCBtb2R1bHVzLiBDb25zZXF1ZW50 bHksIGNvbmNhdGVuYXRpbmcgYSBmaXhlZCBwcmVmaXggdG8gYnVpbGQgYSBERVItZW5jb2Rpbmcg aXMgbGlrZWx5IHRvIGNhdXNlIGludGVyb3AgYnVncy4NCg0KPiBJJ20gc29ycnksIHdoYXQ/ICBD b3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgYW4gZXhhbXBsZSBvZiB0d28gMTAyNC1iaXQgcHJpbWVz IHRoYXQgbXVsdGlwbHkgdG8gYSAyMDQ3LWJpdCB2YWx1ZT8gIExhc3QgSSBjaGVja2VkLCAoMTw8 TiArIHgpKigxPDxOICsgeSkgPiAxPDwoMipOKS4NCg0KcDEgPSAyXjEwMjMgKyAxDQpwMiA9IDJe MTAyMyArIDMNCm4gPSBwMSAqIHAyID0gMl4yMDQ2ICsgMl4xMDI1ICsgMw0KDQpwMSAmIHAyIGFy ZSAxMDI0LWJpdCBudW1iZXJzIChwcm9iYWJseSBub3QgYWN0dWFsbHkgcHJpbWUpLg0KVGhlaXIg cHJvZHVjdCBuIGlzIGEgMjA0Ny1iaXQgbnVtYmVyLg0KDQpUaGUgY2FsY3VsYXRpb24gaXMgKDE8 PE4gLSB4KSooMTw8TiAtIHkpID0gKDE8PDJOIC0geikNCg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_255B9BB34FB7D647A506DC292726F6E12855655143WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVy cGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OyZndDs8L3NwYW4+Jmd0 OyBSU0FfMjA0OF9QUkVGSVggPSAmcXVvdDszMDgyMDEyMjMwMEQwNjA5MkE4NjQ4ODZGNzBEMDEw MTAxMDUwMDAzODIwMTBGMDAzMDgyMDEwQTAyODIwMTAxJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PiZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5U aGVyZSBhcmUgcGxlbnR5IG9mIOKAnDIwNDgtYml0IFJTQSBrZXlz4oCdIHdoZXJlIHRoZSBtb2R1 bHVzIGlzIGFjdHVhbGx5IDIwNDctYml0cyBsb25nIChtdWx0aXBseSB0d28gMTAyNC1iaXQgcHJp bWVzIGFuZCB5b3UgZ2V0IGEgMjA0OC1iaXQgb3IgMjA0Ny1iaXQgbW9kdWx1cykuIFRoZXJlIGlz IG5vIGV4dHJhIGxlYWRpbmcgMHgwMCBieXRlIHdoZW4gREVSLWVuY29kaW5nIGEgMjA0Ny1iaXQg bW9kdWx1cy4gQ29uc2VxdWVudGx5LCBjb25jYXRlbmF0aW5nIGEgZml4ZWQgcHJlZml4IHRvIGJ1 aWxkIGEgREVSLWVuY29kaW5nIGlzIGxpa2VseSB0byBjYXVzZSBpbnRlcm9wIGJ1Z3MuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFu PkknbSBzb3JyeSwgd2hhdD8mbmJzcDsgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIGFuIGV4YW1w bGUgb2YgdHdvIDEwMjQtYml0IHByaW1lcyB0aGF0IG11bHRpcGx5IHRvIGEgMjA0Ny1iaXQgdmFs dWU/Jm5ic3A7IExhc3QgSSBjaGVja2VkLCAoMSZsdDsmbHQ7TiArIHgpKigxJmx0OyZsdDtOICsg eSkgJmd0OyAxJmx0OyZsdDsoMipOKS4gPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5wMSA9 IDJeMTAyMyArIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+cDIgPSAyXjEwMjMgKyAzPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPm4gPSBwMSAqIHAyID0gMl4y MDQ2ICsgMl4xMDI1ICsgMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+cDEgJmFtcDsgcDIgYXJlIDEwMjQt Yml0IG51bWJlcnMgKHByb2JhYmx5IG5vdCBhY3R1YWxseSBwcmltZSkuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZWlyIHBy b2R1Y3QgbiBpcyBhIDIwNDctYml0IG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBjYWxj dWxhdGlvbiBpcyAoMSZsdDsmbHQ7TiAtIHgpKigxJmx0OyZsdDtOIC0geSkgPSAoMSZsdDsmbHQ7 Mk4gLSB6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E12855655143WSMSG3153Vsrv_-- From nobody Thu Mar 12 00:37:57 2015 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 5AF041A1B40 for ; Thu, 12 Mar 2015 00:37:55 -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 Xv6YV6tKnMoy for ; Thu, 12 Mar 2015 00:37:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0E41A1B91 for ; Thu, 12 Mar 2015 00:37:48 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.106.11; Thu, 12 Mar 2015 07:37:24 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0106.007; Thu, 12 Mar 2015 07:37:24 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Key Managed JSON Web Signature (KMJWS) specification Thread-Index: AdBVnrlYeSkbpnXYQGWf+2U9DVU+8wG2dZWAAARd7NA= Date: Thu, 12 Mar 2015 07:37:24 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> In-Reply-To: <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.90.173] authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(209900001)(52604005)(377454003)(51704005)(43784003)(19617315012)(77096005)(102836002)(2900100001)(15975445007)(2950100001)(19609705001)(74316001)(50986999)(54356999)(76176999)(62966003)(77156002)(92566002)(46102003)(19625215002)(66066001)(33656002)(76576001)(2656002)(19300405004)(99286002)(2501003)(16236675004)(87936001)(86362001)(86612001)(19580405001)(19580395003)(40100003)(122556002)(107886001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 05134F8B4F Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4427BF68CEE0CE400972401F5060BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 07:37:24.1569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 12 Mar 2015 07:37:55 -0000 --_000_BY2PR03MB4427BF68CEE0CE400972401F5060BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim. Thanks for responding and for your honest feedback. While you may= feel insulted (I'm genuinely sorry about that!), I'm to try to take the ne= gatives you've expressed as positives, in the sense that they can construct= ively inform future work by the working group. One reason I wrote this draft was to get down a straightforward way of usin= g key managed HMACs, should people want to do that in the future, especiall= y since there's talk of closing the working group soon. The other reason I= wrote it was to further illuminate the upsides and downsides of some of th= e choices we made in JWS and JWE, given we have a chance to reuse and/or re= visit those choices should the COSE work go forward. Replies to your specific points follow inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, March 11, 2015 8:57 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Key Managed JSON Web Signature (KMJWS) specification > I cannot respond for Richard, but personally I feel rather insulted by th= e current draft. My first half a dozen responses were rather vulgar and pe= jorative to this draft and thus deleted. > > This draft seems to be, more or less, what Richard and I were proposing i= n Denver and were told was not possible due to backwards compatibility. Wh= at has changed that this is no longer true? For what it's worth, I've occasionally been thinking about key management f= or MACs ever since you and Richard raised the possibility in Denver. Somew= here along the way I realized that there was a simple way to combine the JW= E key management methods and the JWS MAC methods. So I decided to write it= down, while there was still a working group to consider it, should the wor= king group decide to do so. If the reason you're insulted is that you feel that you should receive more= credit for some of the ideas, I'd be glad to point out in the Acknowledgem= ents that you and Richard suggested the possibility of key-managed MACs and= /or make you co-editors if you agree with the approach and would like to wo= rk more actively on it. If the reason that you're insulted is that you fee= l that we should have done this earlier, I think the verdict is still out o= n whether we need to do this at all. Looking at http://trac.tools.ietf.org= /wg/jose/trac/ticket/2, Karen made a consensus call that "we should not add= the ability to have a randomly generated MAC key protected by a different = key" based on working group input. I think the key question for the working group relative to this draft is wh= ether people now want to see a standard way to do this or not. As for the backwards compatibility issues discussed in Denver, I know that = several participants were opposed to seeing the JWS format for non-key-mana= ged MACs change. I suspect that's what you're referring to. The good news= about the current draft is that it adds the ability to have key-managed MA= Cs without such a change. Should we have thought of this approach then? Probably. Did we? At least= I didn't. I thought of it recently, so I decided to write it down. > Why is there need to have a compact formation for this draft? We were to= ld in no uncertain terms that this was completely unnecessary in Denver and= thus was out of scope for the documents. I can't remember the part of the discussion that you're referring to in Den= ver and I can't find it in the published notes. The only uses of "compact"= in the notes aren't about this. That said, there's a compact serialization for key managed MACs for the sam= e reason that there's a compact serialization for the other JOSE objects - = to provide a compact, URL-safe representation for use cases that need it. = It also makes this draft more parallel to both JWS and JWE than it would ot= herwise be. > This document does not seem to have read the security considerations sect= ion of the JWS draft specifically dealing with the existence of multiple sh= arers of the secret key. I'm not sure I'm following you here, because different recipients use diffe= rent ephemeral keys in this representation. What's the security considerat= ion that you think wasn't taken into account? > This document has messed up the current documentation in JWE about how to= determine what type of document is being presented. This is completely un= acceptable. It's backwards-compatible in the sense that if an implementation supports J= WSs and JWEs but not KMJWSs (I'm still looking for a better name than KMJWS= , BTW), the current rules all continue to do the right thing. If an implem= entation supports all three, yes, a little bit of additional logic would be= needed, just like a little bit of additional code would be needed, but no = breaking changes result. A KMJWS is neither a legal JWS nor a legal JWE, s= o even if the existing discrimination rules were applied to a KMJWS and it = was mis-categorized as one or the other, upon parsing, it would still be re= jected, since it would be missing required properties. > There are now multiple representations of direct keying for mac. This is= a significant problem as one does not know which of the version one is sup= posed to be using. Thanks for pointing this out. We should probably just prohibit the use of = "alg":"dir" in KMJWS so that there's exactly one way of representing non-ke= y-managed MACS - the existing way. > (The fact that I am half, if not all the way drunk has make this message = much easier to write). I'm glad you enjoyed your evening. :) > Jim Thanks again, -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, March 03, 2015 2:42 AM To: jose@ietf.org Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification I took a little time today and wrote a short draft specifying a JWS-like ob= ject that uses key management for the MAC key used to integrity protect the= payload. We had considered doing this in JOSE issue #2 but didn't do so at the time because of lac= k of demand. However, I wanted to get this down now to demonstrate that it= is easy to do and specify a way to do it, should demand develop in the fut= ure - possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones= -jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/dra= ft-jones-jose-key-managed-json-web-signature-00.html. This spec reuses key management functionality already present in the JWE sp= ec and MAC = functionality already present in the JWS spec. The result is essentially a JWS with an= Encrypted Key value added, and a new "mac" Header Parameter value represen= ting the MAC algorithm used. (Like JWE, the key management algorithm is ca= rried in the "alg" Header Parameter value.) I also wrote this now as possible input into our thinking on options for cr= eating a CBOR JOSE mapping. If there a= re CBOR use cases needing managed MAC keys, this could help us reason about= ways to structure the solution. Yes, the spec name and abbreviation are far from catchy. Better naming ide= as would be great. Feedback welcomed. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1344 and as= @selfissued. --_000_BY2PR03MB4427BF68CEE0CE400972401F5060BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim.  Thanks f= or responding and for your honest feedback.  While you may feel insult= ed (I’m genuinely sorry about that!), I’m to try to take the ne= gatives you’ve expressed as positives, in the sense that they can constructively inform future work by the working group.

 

One reason I wrote thi= s draft was to get down a straightforward way of using key managed HMACs, s= hould people want to do that in the future, especially since there’s = talk of closing the working group soon.  The other reason I wrote it was to further illuminate the upsides and downside= s of some of the choices we made in JWS and JWE, given we have a chance to = reuse and/or revisit those choices should the COSE work go forward.

 

Replies to your specif= ic points follow inline…

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Wednesday, March 11, 2015 8:57 PM
To: Mike Jones; jose@ietf.org
Subject: RE: [jose] Key Managed JSON Web Signature (KMJWS) specifica= tion

 

> I cannot respond for Richard, but personally I feel rat= her insulted by the current draft.  My first half a dozen responses we= re rather vulgar and pejorative to this draft and thus deleted.

> 

> This draft seems to be, more or less, what Richard and = I were proposing in Denver and were told was not possible due to backwards = compatibility.  What has changed that this is no longer true?

 

For what it’s wo= rth, I’ve occasionally been thinking about key management for MACs ev= er since you and Richard raised the possibility in Denver.  Somewhere = along the way I realized that there was a simple way to combine the JWE key management methods and the JWS MAC methods.  S= o I decided to write it down, while there was still a working group to cons= ider it, should the working group decide to do so.

 

If the reason you̵= 7;re insulted is that you feel that you should receive more credit for some= of the ideas, I’d be glad to point out in the Acknowledgements that = you and Richard suggested the possibility of key-managed MACs and/or make you co-editors if you agree with the approach and would l= ike to work more actively on it.  If the reason that you’re insu= lted is that you feel that we should have done this earlier, I think the ve= rdict is still out on whether we need to do this at all.  Looking at http://trac.tools.ietf.org/wg/jose/trac/ticket/2, Karen made a consensu= s call that “we should not add the= ability to have a randomly generated MAC key protected by a different key<= /span>” based on working group input.

 

I think the key questi= on for the working group relative to this draft is whether people now want = to see a standard way to do this or not.

 

As for the backwards c= ompatibility issues discussed in Denver, I know that several participants w= ere opposed to seeing the JWS format for non-key-managed MACs change. = I suspect that’s what you’re referring to.  The good news about the current draft is that it adds the ability to have = key-managed MACs without such a change.

 

Should we have thought= of this approach then?  Probably.  Did we?  At least I didn= ’t.  I thought of it recently, so I decided to write it down.

 

> Why is there need to have a compact formation for this = draft?  We were told in no uncertain terms that this was completely un= necessary in Denver and thus was out of scope for the documents.

 

I can’t remember= the part of the discussion that you’re referring to in Denver and I = can’t find it in the published notes.  The only uses of “c= ompact” in the notes aren’t about this.

 

That said, there’= ;s a compact serialization for key managed MACs for the same reason that th= ere’s a compact serialization for the other JOSE objects – to p= rovide a compact, URL-safe representation for use cases that need it.  It also makes this draft more parallel to both JWS and= JWE than it would otherwise be.

 

> This document does not seem to have read the security c= onsiderations section of the JWS draft specifically dealing with the existe= nce of multiple sharers of the secret key.

 

I’m not sure I&#= 8217;m following you here, because different recipients use different ephem= eral keys in this representation.  What’s the security considera= tion that you think wasn’t taken into account?

 

> This document has messed up the current documentation i= n JWE about how to determine what type of document is being presented. = ; This is completely unacceptable.

 

It’s backwards-c= ompatible in the sense that if an implementation supports JWSs and JWEs but= not KMJWSs (I’m still looking for a better name than KMJWS, BTW), th= e current rules all continue to do the right thing.  If an implementation supports all three, yes, a little bit of additional l= ogic would be needed, just like a little bit of additional code would be ne= eded, but no breaking changes result.  A KMJWS is neither a legal JWS = nor a legal JWE, so even if the existing discrimination rules were applied to a KMJWS and it was mis-categorized as= one or the other, upon parsing, it would still be rejected, since it would= be missing required properties.

 

> There are now multiple representations of direct keying= for mac.  This is a significant problem as one does not know which of= the version one is supposed to be using.

 

Thanks for pointing th= is out.  We should probably just prohibit the use of “alg”= :”dir” in KMJWS so that there’s exactly one way of repres= enting non-key-managed MACS – the existing way.

 

> (The fact that I am half, if not all the way drunk has = make this message much easier to write).

 

I’m glad you enj= oyed your evening. J

 

> Jim

 

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

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, March 03, 2015 2:42 AM
To: jose@ietf.org
Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification=

 

I took a little time today and wrote a short draft s= pecifying a JWS-like object that uses key management for the MAC key used t= o integrity protect the payload.  We had considered doing this in JOSE issue #2<= /a> but didn’t do so at the time because of lack of demand.  How= ever, I wanted to get this down now to demonstrate that it is easy to do an= d specify a way to do it, should demand develop in the future – possibly after the JOSE working group has been closed.  See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-= 00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signatur= e-00.html.

 

This spec reuses key management functionality alread= y present in the = JWE spec and MAC functionality already present in the J= WS spec.  The result is essentially a JWS with an Encrypted Key va= lue added, and a new “mac” Header Parameter value representing the MAC algorithm used.  (Like JWE, the key management algorithm is carri= ed in the “alg” Header Parameter value.)

 

I also wrote this now as possible input into our thi= nking on options for creating a CBOR JOSE mapping. = If there are CBOR use cases needing managed MAC keys, this could help us r= eason about ways to structure the solution.

 

Yes, the spec name and abbreviation are far from cat= chy.  Better naming ideas would be great.

 

Feedback welcomed.

 

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

 

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

 

--_000_BY2PR03MB4427BF68CEE0CE400972401F5060BY2PR03MB442namprd_-- From nobody Thu Mar 12 00:56:25 2015 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 166DB1A8AA1 for ; Thu, 12 Mar 2015 00:56:23 -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 MMRUey7Xo65B for ; Thu, 12 Mar 2015 00:56:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0137.outbound.protection.outlook.com [65.55.169.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591E91A0084 for ; Thu, 12 Mar 2015 00:56:19 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.106.11; Thu, 12 Mar 2015 07:56:16 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0106.007; Thu, 12 Mar 2015 07:56:16 +0000 From: Mike Jones To: Richard Barnes , Jim Schaad Thread-Topic: [jose] Key Managed JSON Web Signature (KMJWS) specification Thread-Index: AdBVnrlYeSkbpnXYQGWf+2U9DVU+8wG2dZWAAAOYS4AABDJqMA== Date: Thu, 12 Mar 2015 07:56:15 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.90.173] authentication-results: ipv.sx; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(209900001)(243025005)(377454003)(24454002)(87936001)(19300405004)(2656002)(76576001)(16236675004)(99286002)(122556002)(40100003)(86612001)(86362001)(19580395003)(19580405001)(74316001)(19609705001)(76176999)(54356999)(50986999)(19617315012)(77096005)(102836002)(15975445007)(2950100001)(2900100001)(33656002)(19625215002)(66066001)(92566002)(62966003)(77156002)(46102003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 05134F8B4F Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442FCA01F4D1B404C2CDC51F5060BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 07:56:15.0383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 12 Mar 2015 07:56:23 -0000 --_000_BY2PR03MB442FCA01F4D1B404C2CDC51F5060BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyIG15IG5vdGUgdG8gSmltIGp1c3Qgbm93LCBJIGdpdmUgeW91IGFuZCBKaW0gZnVsbCBjcmVk aXQgZm9yIGJyaW5naW5nIHVwIHRoZSBwb3NzaWJpbGl0eSBvZiBrZXktbWFuYWdlZCBNQUNzIGZv ciBKT1NFIGluIERlbnZlciBhbmQgc3Vic2VxdWVudGx5LiAgVGhlIHBvc3NpYmlsaXR5IGhhcyBp bnRyaWd1ZWQgbWUgZXZlciBzaW5jZSwgZm9yIHdoYXQgaXTigJlzIHdvcnRoLg0KDQpJIHVuZGVy c3RhbmQgYnV0IGRpc2FncmVlIHdpdGggeW91ciDigJxla+KAnSBzdWdnZXN0aW9uLiAgSSBkaXNh Z3JlZSBiZWNhdXNlIGl04oCZcyBpbnZlbnRpbmcgYSBuZXcgbWVjaGFuaXNtIG5vdCBjdXJyZW50 bHkgdXNlZCBpbiBKT1NFLCB3aGVyZWFzIHRoZSBwcmVzZW50IGRyYWZ0IHByb3ZpZGVzIGFuIGV4 aXN0ZW5jZSBwcm9vZiB0aGF0IEpXRSBrZXkgbWFuYWdlbWVudCBhbmQgSldTIE1BQ3MgY2FuIGJl IGNvbWJpbmVkIGluIGEgc3RyYWlnaHRmb3J3YXJkIHdheSB0byBhY2NvbXBsaXNoIHRoZSBnb2Fs IHdpdGhvdXQgaW52ZW50aW5nIGFueSBuZXcgbWVjaGFuaXNtcy4gIChZZXMsIHRoZSBuZXcgaGVh ZGVyIHBhcmFtZXRlciBmaWVsZCBuYW1lIOKAnG1hY+KAnSBpcyBpbnZlbnRlZCB0byBob2xkIHRo ZSBNQUMgYWxnb3JpdGhtLCBpbnN0ZWFkIG9mIOKAnGFsZ+KAnSwgYnV0IHRoYXTigJlzIHByZXR0 eSBtdWNoIHRoZSBleHRlbnQgb2YgdGhlIGludmVudGlvbi4pDQoNCkxpa2Ugd2UgdGFsa2VkIGFi b3V0IGluIERlbnZlciBhbmQgYWZ0ZXJ3YXJkcywgd2hpbGUgSSB1bmRlcnN0YW5kIHRoZSBjb25j ZXB0dWFsIGVsZWdhbmNlIG9mIGhhdmluZyBhbGwgd3JhcHBlZCBrZXlzIGJlIHJlcHJlc2VudGVk IGFzIGVuY3J5cHRlZCBKV0tzLCBpbiBwcmFjdGljZSwgdGhhdCBnZW5lcmFsaXR5IGlzbuKAmXQg bmVlZGVkIGZvciB3cmFwcGVkIGtleXMgKHNpbmNlIG5vIGtleSBhdHRyaWJ1dGVzIGFyZSBuZWVk ZWQpIGFuZCBpdCB0YWtlcyB1cCBleHRyYSBzcGFjZS4gIEFsbCB5b3UgYWN0dWFsbHkgbmVlZCBh cmUgdGhlIHN5bW1ldHJpYyBrZXkgYml0cywgc28gdGhhdOKAmXMgd2hlcmUgd2UgbGFuZGVkLCBh bmQgcHV0IHRoZW0gaW4gdGhlIGVuY3J5cHRlZF9rZXkgZmllbGQuICBLTUpXUyBkb2VzIHRoZSBz YW1lLg0KDQpBcyBhbiBhc2lkZSwgSSBkbyByZWFsaXplIG5vdyB0aGF0IGlmIHdl4oCZZCB1c2Vk IGhlYWRlciBwYXJhbWV0ZXIgbmFtZXMgZGlmZmVyZW50bHksIGFuZCBpbiBwYXJ0aWN1bGFyLCBu b3Qgb3ZlcmxvYWRlZCDigJxhbGfigJ0gaW4gdGhlIHdheSB3ZSBkaWQsIHRoaXMgY291bGQgYmUg ZXZlbiBtb3JlIGVsZWdhbnQuICBIaW5kc2lnaHQgaXMgMjAtMjAuICBXZSBoYXZlIHRoZSBvcHBv cnR1bml0eSB0byBoYXZlIGl0IGJlIG1vcmUgZWxlZ2FudCBpbiBDT1NFLCB3aGlsZSBrZWVwaW5n IHRoZSBiYXNpYyBtb2RlbCB0aGUgc2FtZSwgc2hvdWxkIHdlIGNob29zZSB0byB0YWtlIG9uIHRo YXQgbmV3IHdvcmsuICAoSW4gZmFjdCwgbWFraW5nIHRoYXQgY2xlYXIgZm9yIENPU0UgaXMgcGFy dCBvZiB3aHkgSSB3cm90ZSBLTUpXUyBpbiB0aGUgZmlyc3QgcGxhY2UuKQ0KDQpJ4oCZbSBsb29r aW5nIGZvcndhcmQgdG8gc2VlaW5nIHlvdSBpbiBEYWxsYXMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogUmljaGFyZCBCYXJuZXMgW21haWx0bzpybGJAaXB2LnN4XQ0KU2VudDogV2VkbmVzZGF5LCBN YXJjaCAxMSwgMjAxNSAxMDo0MCBQTQ0KVG86IEppbSBTY2hhYWQNCkNjOiBNaWtlIEpvbmVzOyBq b3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2pvc2VdIEtleSBNYW5hZ2VkIEpTT04gV2ViIFNp Z25hdHVyZSAoS01KV1MpIHNwZWNpZmljYXRpb24NCg0KSSB3YXMgc2ltcGx5IGdvaW5nIHRvIG5v dGUgd2l0aCBiZW11c2VtZW50IHRoYXQgZXhhY3RseSB0aGlzIGV2ZW50dWFsaXR5IHdhcyBmb3Jl c2VlbiBieSB0aG9zZSBvZiB1cyB0aGF0IGZhdm9yZWQgYSBtb3JlIGdlbmVyYWwgYXBwcm9hY2gg dG8ga2V5IHdyYXBwaW5nIFswXVsxXS4gIFRob3NlIHRoYXQgZGlzbWlzc2VkIHRoYXQgaWRlYSBo YXZlIG1hZGUgdGhlaXIgYmVkIGZ1bGwgb2YgY29tcGxleGl0eSwgYW5kIG5vdyB0aGV5IGFyZSBs eWluZyBpbiBpdC4NCkF0IHRoaXMgcG9pbnQsIHRoZSBsZWFzdCBoYXJtZnVsIGFwcHJvYWNoIHdv dWxkIGJlIHRvIHNpbXBseSBkZWZpbmUgYW4gImVrIiBoZWFkZXIgZmllbGQgdGhhdCBjb250YWlu cyBhbiBlbmNyeXB0ZWQga2V5LCBpbiB0aGUgZm9ybSBvZiBhIEpXRSBjb250YWluaW5nIGEgSldL IFswXS4NCg0KWzBdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvODUvc2xpZGVzL3NsaWRl cy04NS1qb3NlLTcucGRmDQpbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2FnZW5kYS84Ni9zbGlk ZXMvc2xpZGVzLTg2LWpvc2UtMC5wZGYNCg0KT24gV2VkLCBNYXIgMTEsIDIwMTUgYXQgODo1NiBQ TSwgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbT4+IHdyb3RlOg0KSSBjYW5ub3QgcmVzcG9uZCBmb3IgUmljaGFyZCwgYnV0IHBl cnNvbmFsbHkgSSBmZWVsIHJhdGhlciBpbnN1bHRlZCBieSB0aGUgY3VycmVudCBkcmFmdC4gIE15 IGZpcnN0IGhhbGYgYSBkb3plbiByZXNwb25zZXMgd2VyZSByYXRoZXIgdnVsZ2FyIGFuZCBwZWpv cmF0aXZlIHRvIHRoaXMgZHJhZnQgYW5kIHRodXMgZGVsZXRlZC4NCg0KVGhpcyBkcmFmdCBzZWVt cyB0byBiZSwgbW9yZSBvciBsZXNzLCB3aGF0IFJpY2hhcmQgYW5kIEkgd2VyZSBwcm9wb3Npbmcg aW4gRGVudmVyIGFuZCB3ZXJlIHRvbGQgd2FzIG5vdCBwb3NzaWJsZSBkdWUgdG8gYmFja3dhcmRz IGNvbXBhdGliaWxpdHkuICBXaGF0IGhhcyBjaGFuZ2VkIHRoYXQgdGhpcyBpcyBubyBsb25nZXIg dHJ1ZT8NCg0KV2h5IGlzIHRoZXJlICBuZWVkIHRvIGhhdmUgYSBjb21wYWN0IGZvcm1hdGlvbiBm b3IgdGhpcyBkcmFmdD8gIFdlIHdlcmUgdG9sZCBpbiBubyB1bmNlcnRhaW4gdGVybXMgdGhhdCB0 aGlzIHdhcyBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5IGluIERlbnZlciBhbmQgdGh1cyB3YXMgb3V0 IG9mIHNjb3BlIGZvciB0aGUgZG9jdW1lbnRzLg0KDQpUaGlzIGRvY3VtZW50IGRvZXMgbm90IHNl ZW0gdG8gaGF2ZSByZWFkIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIHRo ZSBKV1MgZHJhZnQgc3BlY2lmaWNhbGx5IGRlYWxpbmcgd2l0aCB0aGUgZXhpc3RlbmNlIG9mIG11 bHRpcGxlIHNoYXJlcnMgb2YgdGhlIHNlY3JldCBrZXkuDQoNClRoaXMgZG9jdW1lbnQgaGFzIG1l c3NlZCB1cCB0aGUgY3VycmVudCBkb2N1bWVudGF0aW9uIGluIEpXRSBhYm91dCBob3cgdG8gZGV0 ZXJtaW5lIHdoYXQgdHlwZSBvZiBkb2N1bWVudCBpcyBiZWluZyBwcmVzZW50ZWQuICBUaGlzIGlz IGNvbXBsZXRlbHkgdW5hY2NlcHRhYmxlLg0KDQpUaGVyZSBhcmUgbm93IG11bHRpcGxlIHJlcHJl c2VudGF0aW9ucyBvZiBkaXJlY3Qga2V5aW5nIGZvciBtYWMuICBUaGlzIGlzIGEgc2lnbmlmaWNh bnQgcHJvYmxlbSBhcyBvbmUgZG9lcyBub3Qga25vdyB3aGljaCBvZiB0aGUgdmVyc2lvbiBvbmUg aXMgc3VwcG9zZWQgdG8gYmUgdXNpbmcuDQoNCihUaGUgZmFjdCB0aGF0IEkgYW0gaGFsZiwgaWYg bm90IGFsbCB0aGUgd2F5IGRydW5rIGhhcyBtYWtlIHRoaXMgbWVzc2FnZSBtdWNoIGVhc2llciB0 byB3cml0ZSkuDQoNCkppbQ0KDQoNCkZyb206IGpvc2UgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBNaWtlIEpv bmVzDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwMywgMjAxNSAyOjQyIEFNDQpUbzogam9zZUBpZXRm Lm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtqb3NlXSBLZXkgTWFuYWdlZCBK U09OIFdlYiBTaWduYXR1cmUgKEtNSldTKSBzcGVjaWZpY2F0aW9uDQoNCkkgdG9vayBhIGxpdHRs ZSB0aW1lIHRvZGF5IGFuZCB3cm90ZSBhIHNob3J0IGRyYWZ0IHNwZWNpZnlpbmcgYSBKV1MtbGlr ZSBvYmplY3QgdGhhdCB1c2VzIGtleSBtYW5hZ2VtZW50IGZvciB0aGUgTUFDIGtleSB1c2VkIHRv IGludGVncml0eSBwcm90ZWN0IHRoZSBwYXlsb2FkLiAgV2UgaGFkIGNvbnNpZGVyZWQgZG9pbmcg dGhpcyBpbiBKT1NFIGlzc3VlICMyPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2Uv dHJhYy90aWNrZXQvMj4gYnV0IGRpZG7igJl0IGRvIHNvIGF0IHRoZSB0aW1lIGJlY2F1c2Ugb2Yg bGFjayBvZiBkZW1hbmQuICBIb3dldmVyLCBJIHdhbnRlZCB0byBnZXQgdGhpcyBkb3duIG5vdyB0 byBkZW1vbnN0cmF0ZSB0aGF0IGl0IGlzIGVhc3kgdG8gZG8gYW5kIHNwZWNpZnkgYSB3YXkgdG8g ZG8gaXQsIHNob3VsZCBkZW1hbmQgZGV2ZWxvcCBpbiB0aGUgZnV0dXJlIOKAkyBwb3NzaWJseSBh ZnRlciB0aGUgSk9TRSB3b3JraW5nIGdyb3VwPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93 Zy9qb3NlL2NoYXJ0ZXIvPiBoYXMgYmVlbiBjbG9zZWQuICBTZWUgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtam9uZXMtam9zZS1rZXktbWFuYWdlZC1qc29uLXdlYi1zaWduYXR1cmUt MDAgb3IgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1qb25lcy1qb3NlLWtleS1t YW5hZ2VkLWpzb24td2ViLXNpZ25hdHVyZS0wMC5odG1sLg0KDQpUaGlzIHNwZWMgcmV1c2VzIGtl eSBtYW5hZ2VtZW50IGZ1bmN0aW9uYWxpdHkgYWxyZWFkeSBwcmVzZW50IGluIHRoZSBKV0Ugc3Bl YzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5j cnlwdGlvbj4gYW5kIE1BQyBmdW5jdGlvbmFsaXR5IGFscmVhZHkgcHJlc2VudCBpbiB0aGUgSldT IHNwZWM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2Vi LXNpZ25hdHVyZT4uICBUaGUgcmVzdWx0IGlzIGVzc2VudGlhbGx5IGEgSldTIHdpdGggYW4gRW5j cnlwdGVkIEtleSB2YWx1ZSBhZGRlZCwgYW5kIGEgbmV3IOKAnG1hY+KAnSBIZWFkZXIgUGFyYW1l dGVyIHZhbHVlIHJlcHJlc2VudGluZyB0aGUgTUFDIGFsZ29yaXRobSB1c2VkLiAgKExpa2UgSldF LCB0aGUga2V5IG1hbmFnZW1lbnQgYWxnb3JpdGhtIGlzIGNhcnJpZWQgaW4gdGhlIOKAnGFsZ+KA nSBIZWFkZXIgUGFyYW1ldGVyIHZhbHVlLikNCg0KSSBhbHNvIHdyb3RlIHRoaXMgbm93IGFzIHBv c3NpYmxlIGlucHV0IGludG8gb3VyIHRoaW5raW5nIG9uIG9wdGlvbnMgZm9yIGNyZWF0aW5nIGEg Q0JPUjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDQ5PiBKT1NFIG1hcHBpbmcuICBJ ZiB0aGVyZSBhcmUgQ0JPUiB1c2UgY2FzZXMgbmVlZGluZyBtYW5hZ2VkIE1BQyBrZXlzLCB0aGlz IGNvdWxkIGhlbHAgdXMgcmVhc29uIGFib3V0IHdheXMgdG8gc3RydWN0dXJlIHRoZSBzb2x1dGlv bi4NCg0KWWVzLCB0aGUgc3BlYyBuYW1lIGFuZCBhYmJyZXZpYXRpb24gYXJlIGZhciBmcm9tIGNh dGNoeS4gIEJldHRlciBuYW1pbmcgaWRlYXMgd291bGQgYmUgZ3JlYXQuDQoNCkZlZWRiYWNrIHdl bGNvbWVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNClAuUy4gIFRoaXMgbm90ZSB3YXMgYWxzbyBwb3N0ZWQg YXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTM0NCBhbmQgYXMgQHNlbGZpc3N1ZWQuDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2Ug bWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg== --_000_BY2PR03MB442FCA01F4D1B404C2CDC51F5060BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5QZXIgbXkgbm90ZSB0byBKaW0ganVzdCBub3csIEkgZ2l2ZSB5b3UgYW5kIEppbSBmdWxs IGNyZWRpdCBmb3IgYnJpbmdpbmcgdXAgdGhlIHBvc3NpYmlsaXR5IG9mIGtleS1tYW5hZ2VkIE1B Q3MgZm9yIEpPU0UgaW4gRGVudmVyIGFuZCBzdWJzZXF1ZW50bHkuJm5ic3A7IFRoZSBwb3NzaWJp bGl0eQ0KIGhhcyBpbnRyaWd1ZWQgbWUgZXZlciBzaW5jZSwgZm9yIHdoYXQgaXTigJlzIHdvcnRo LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB1bmRlcnN0YW5kIGJ1dCBkaXNhZ3JlZSB3aXRoIHlvdXIg4oCcZWvigJ0g c3VnZ2VzdGlvbi4mbmJzcDsgSSBkaXNhZ3JlZSBiZWNhdXNlIGl04oCZcyBpbnZlbnRpbmcgYSBu ZXcgbWVjaGFuaXNtIG5vdCBjdXJyZW50bHkgdXNlZCBpbiBKT1NFLCB3aGVyZWFzIHRoZSBwcmVz ZW50IGRyYWZ0DQogcHJvdmlkZXMgYW4gZXhpc3RlbmNlIHByb29mIHRoYXQgSldFIGtleSBtYW5h Z2VtZW50IGFuZCBKV1MgTUFDcyBjYW4gYmUgY29tYmluZWQgaW4gYSBzdHJhaWdodGZvcndhcmQg d2F5IHRvIGFjY29tcGxpc2ggdGhlIGdvYWwgd2l0aG91dCBpbnZlbnRpbmcgYW55IG5ldyBtZWNo YW5pc21zLiZuYnNwOyAoWWVzLCB0aGUgbmV3IGhlYWRlciBwYXJhbWV0ZXIgZmllbGQgbmFtZSDi gJxtYWPigJ0gaXMgaW52ZW50ZWQgdG8gaG9sZCB0aGUgTUFDIGFsZ29yaXRobSwgaW5zdGVhZA0K IG9mIOKAnGFsZ+KAnSwgYnV0IHRoYXTigJlzIHByZXR0eSBtdWNoIHRoZSBleHRlbnQgb2YgdGhl IGludmVudGlvbi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaWtlIHdlIHRhbGtlZCBhYm91dCBpbiBEZW52ZXIgYW5k IGFmdGVyd2FyZHMsIHdoaWxlIEkgdW5kZXJzdGFuZCB0aGUgY29uY2VwdHVhbCBlbGVnYW5jZSBv ZiBoYXZpbmcgYWxsIHdyYXBwZWQga2V5cyBiZSByZXByZXNlbnRlZCBhcyBlbmNyeXB0ZWQgSldL cywgaW4gcHJhY3RpY2UsDQogdGhhdCBnZW5lcmFsaXR5IGlzbuKAmXQgbmVlZGVkIGZvciB3cmFw cGVkIGtleXMgKHNpbmNlIG5vIGtleSBhdHRyaWJ1dGVzIGFyZSBuZWVkZWQpIGFuZCBpdCB0YWtl cyB1cCBleHRyYSBzcGFjZS4mbmJzcDsgQWxsIHlvdSBhY3R1YWxseSBuZWVkIGFyZSB0aGUgc3lt bWV0cmljIGtleSBiaXRzLCBzbyB0aGF04oCZcyB3aGVyZSB3ZSBsYW5kZWQsIGFuZCBwdXQgdGhl bSBpbiB0aGUgZW5jcnlwdGVkX2tleSBmaWVsZC4mbmJzcDsgS01KV1MgZG9lcyB0aGUgc2FtZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkFzIGFuIGFzaWRlLCBJIGRvIHJlYWxpemUgbm93IHRoYXQgaWYgd2XigJlkIHVz ZWQgaGVhZGVyIHBhcmFtZXRlciBuYW1lcyBkaWZmZXJlbnRseSwgYW5kIGluIHBhcnRpY3VsYXIs IG5vdCBvdmVybG9hZGVkIOKAnGFsZ+KAnSBpbiB0aGUgd2F5IHdlIGRpZCwgdGhpcyBjb3VsZCBi ZQ0KIGV2ZW4gbW9yZSBlbGVnYW50LiZuYnNwOyBIaW5kc2lnaHQgaXMgMjAtMjAuJm5ic3A7IFdl IGhhdmUgdGhlIG9wcG9ydHVuaXR5IHRvIGhhdmUgaXQgYmUgbW9yZSBlbGVnYW50IGluIENPU0Us IHdoaWxlIGtlZXBpbmcgdGhlIGJhc2ljIG1vZGVsIHRoZSBzYW1lLCBzaG91bGQgd2UgY2hvb3Nl IHRvIHRha2Ugb24gdGhhdCBuZXcgd29yay4mbmJzcDsgKEluIGZhY3QsIG1ha2luZyB0aGF0IGNs ZWFyIGZvciBDT1NFIGlzIHBhcnQgb2Ygd2h5IEkgd3JvdGUgS01KV1MgaW4gdGhlDQogZmlyc3Qg cGxhY2UuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gbG9va2luZyBmb3J3YXJkIHRvIHNlZWluZyB5b3UgaW4g RGFsbGFzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5z eF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDExLCAyMDE1IDEwOjQwIFBN PGJyPg0KPGI+VG86PC9iPiBKaW0gU2NoYWFkPGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzOyBq b3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0gS2V5IE1hbmFnZWQg SlNPTiBXZWIgU2lnbmF0dXJlIChLTUpXUykgc3BlY2lmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pkkgd2FzIHNpbXBseSBnb2luZyB0byBub3RlIHdpdGggYmVtdXNlbWVudCB0aGF0IGV4YWN0bHkg dGhpcyBldmVudHVhbGl0eSB3YXMgZm9yZXNlZW4gYnkgdGhvc2Ugb2YgdXMgdGhhdCBmYXZvcmVk IGEgbW9yZSBnZW5lcmFsIGFwcHJvYWNoIHRvIGtleSB3cmFwcGluZyBbMF1bMV0uJm5ic3A7IFRo b3NlIHRoYXQgZGlzbWlzc2VkIHRoYXQgaWRlYSBoYXZlIG1hZGUgdGhlaXINCiBiZWQgZnVsbCBv ZiBjb21wbGV4aXR5LCBhbmQgbm93IHRoZXkgYXJlIGx5aW5nIGluIGl0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGlzIHBvaW50LCB0aGUgbGVhc3Qg aGFybWZ1bCBhcHByb2FjaCB3b3VsZCBiZSB0byBzaW1wbHkgZGVmaW5lIGFuICZxdW90O2VrJnF1 b3Q7IGhlYWRlciBmaWVsZCB0aGF0IGNvbnRhaW5zIGFuIGVuY3J5cHRlZCBrZXksIGluIHRoZSBm b3JtIG9mIGEgSldFIGNvbnRhaW5pbmcgYSBKV0sgWzBdLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K WzBdIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvODUvc2xpZGVzL3NsaWRl cy04NS1qb3NlLTcucGRmIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzg1L3NsaWRlcy9z bGlkZXMtODUtam9zZS03LnBkZjwvYT48YnI+DQpbMV0gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2FnZW5kYS84Ni9zbGlkZXMvc2xpZGVzLTg2LWpvc2UtMC5wZGYiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9hZ2VuZGEvODYvc2xpZGVzL3NsaWRlcy04Ni1qb3NlLTAucGRmPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IE1hciAxMSwgMjAxNSBhdCA4OjU2IFBNLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFy cy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBjYW5ub3QgcmVz cG9uZCBmb3IgUmljaGFyZCwgYnV0IHBlcnNvbmFsbHkgSSBmZWVsIHJhdGhlciBpbnN1bHRlZCBi eSB0aGUgY3VycmVudCBkcmFmdC4mbmJzcDsgTXkgZmlyc3QgaGFsZiBhIGRvemVuIHJlc3BvbnNl cyB3ZXJlIHJhdGhlciB2dWxnYXIgYW5kIHBlam9yYXRpdmUNCiB0byB0aGlzIGRyYWZ0IGFuZCB0 aHVzIGRlbGV0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhp cyBkcmFmdCBzZWVtcyB0byBiZSwgbW9yZSBvciBsZXNzLCB3aGF0IFJpY2hhcmQgYW5kIEkgd2Vy ZSBwcm9wb3NpbmcgaW4gRGVudmVyIGFuZCB3ZXJlIHRvbGQgd2FzIG5vdCBwb3NzaWJsZSBkdWUg dG8gYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuJm5ic3A7IFdoYXQNCiBoYXMgY2hhbmdlZCB0aGF0 IHRoaXMgaXMgbm8gbG9uZ2VyIHRydWU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+V2h5IGlzIHRoZXJlJm5ic3A7IG5lZWQgdG8gaGF2ZSBhIGNvbXBhY3QgZm9ybWF0 aW9uIGZvciB0aGlzIGRyYWZ0PyZuYnNwOyBXZSB3ZXJlIHRvbGQgaW4gbm8gdW5jZXJ0YWluIHRl cm1zIHRoYXQgdGhpcyB3YXMgY29tcGxldGVseSB1bm5lY2Vzc2FyeSBpbiBEZW52ZXIgYW5kDQog dGh1cyB3YXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgZG9jdW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoaXMgZG9jdW1lbnQgZG9lcyBub3Qgc2VlbSB0byBo YXZlIHJlYWQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgdGhlIEpXUyBk cmFmdCBzcGVjaWZpY2FsbHkgZGVhbGluZyB3aXRoIHRoZSBleGlzdGVuY2Ugb2YgbXVsdGlwbGUg c2hhcmVycw0KIG9mIHRoZSBzZWNyZXQga2V5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlRoaXMgZG9jdW1lbnQgaGFzIG1lc3NlZCB1cCB0aGUgY3VycmVudCBkb2N1 bWVudGF0aW9uIGluIEpXRSBhYm91dCBob3cgdG8gZGV0ZXJtaW5lIHdoYXQgdHlwZSBvZiBkb2N1 bWVudCBpcyBiZWluZyBwcmVzZW50ZWQuJm5ic3A7IFRoaXMgaXMgY29tcGxldGVseSB1bmFjY2Vw dGFibGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlcmUgYXJl IG5vdyBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMgb2YgZGlyZWN0IGtleWluZyBmb3IgbWFjLiZu YnNwOyBUaGlzIGlzIGEgc2lnbmlmaWNhbnQgcHJvYmxlbSBhcyBvbmUgZG9lcyBub3Qga25vdyB3 aGljaCBvZiB0aGUgdmVyc2lvbiBvbmUgaXMgc3VwcG9zZWQNCiB0byBiZSB1c2luZy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4oVGhlIGZhY3QgdGhhdCBJIGFtIGhh bGYsIGlmIG5vdCBhbGwgdGhlIHdheSBkcnVuayBoYXMgbWFrZSB0aGlzIG1lc3NhZ2UgbXVjaCBl YXNpZXIgdG8gd3JpdGUpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkppbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gam9zZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5NaWtlIEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDAzLCAy MDE1IDI6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W2pvc2VdIEtleSBNYW5hZ2VkIEpTT04gV2ViIFNpZ25hdHVyZSAoS01KV1MpIHNwZWNpZmljYXRp b248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIHRvb2sgYSBsaXR0bGUgdGltZSB0b2RheSBhbmQgd3JvdGUgYSBzaG9ydCBk cmFmdCBzcGVjaWZ5aW5nIGEgSldTLWxpa2Ugb2JqZWN0IHRoYXQgdXNlcyBrZXkgbWFuYWdlbWVu dCBmb3IgdGhlIE1BQyBrZXkgdXNlZCB0byBpbnRlZ3JpdHkgcHJvdGVjdCB0aGUgcGF5bG9hZC4m bmJzcDsgV2UgaGFkIGNvbnNpZGVyZWQNCiBkb2luZyB0aGlzIGluIDxhIGhyZWY9Imh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMiIgdGFyZ2V0PSJfYmxhbmsi Pg0KSk9TRSBpc3N1ZSAjMjwvYT4gYnV0IGRpZG7igJl0IGRvIHNvIGF0IHRoZSB0aW1lIGJlY2F1 c2Ugb2YgbGFjayBvZiBkZW1hbmQuJm5ic3A7IEhvd2V2ZXIsIEkgd2FudGVkIHRvIGdldCB0aGlz IGRvd24gbm93IHRvIGRlbW9uc3RyYXRlIHRoYXQgaXQgaXMgZWFzeSB0byBkbyBhbmQgc3BlY2lm eSBhIHdheSB0byBkbyBpdCwgc2hvdWxkIGRlbWFuZCBkZXZlbG9wIGluIHRoZSBmdXR1cmUg4oCT IHBvc3NpYmx5IGFmdGVyIHRoZQ0KPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L3dnL2pvc2UvY2hhcnRlci8iIHRhcmdldD0iX2JsYW5rIj5KT1NFIHdvcmtpbmcgZ3JvdXA8L2E+ IGhhcyBiZWVuIGNsb3NlZC4mbmJzcDsgU2VlDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1qb25lcy1qb3NlLWtleS1tYW5hZ2VkLWpzb24td2ViLXNpZ25hdHVyZS0w MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9u ZXMtam9zZS1rZXktbWFuYWdlZC1qc29uLXdlYi1zaWduYXR1cmUtMDA8L2E+IG9yDQo8YSBocmVm PSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLWpvc2Uta2V5LW1hbmFn ZWQtanNvbi13ZWItc2lnbmF0dXJlLTAwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9z ZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtam9zZS1rZXktbWFuYWdlZC1qc29uLXdl Yi1zaWduYXR1cmUtMDAuaHRtbDwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlz IHNwZWMgcmV1c2VzIGtleSBtYW5hZ2VtZW50IGZ1bmN0aW9uYWxpdHkgYWxyZWFkeSBwcmVzZW50 IGluIHRoZQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1q b3NlLWpzb24td2ViLWVuY3J5cHRpb24iIHRhcmdldD0iX2JsYW5rIj4NCkpXRSBzcGVjPC9hPiBh bmQgTUFDIGZ1bmN0aW9uYWxpdHkgYWxyZWFkeSBwcmVzZW50IGluIHRoZSA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJl IiB0YXJnZXQ9Il9ibGFuayI+DQpKV1Mgc3BlYzwvYT4uJm5ic3A7IFRoZSByZXN1bHQgaXMgZXNz ZW50aWFsbHkgYSBKV1Mgd2l0aCBhbiBFbmNyeXB0ZWQgS2V5IHZhbHVlIGFkZGVkLCBhbmQgYSBu ZXcg4oCcPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5t YWM8L3NwYW4+4oCdIEhlYWRlciBQYXJhbWV0ZXIgdmFsdWUgcmVwcmVzZW50aW5nIHRoZSBNQUMg YWxnb3JpdGhtIHVzZWQuJm5ic3A7IChMaWtlIEpXRSwgdGhlIGtleSBtYW5hZ2VtZW50IGFsZ29y aXRobSBpcyBjYXJyaWVkDQogaW4gdGhlIOKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+YWxnPC9zcGFuPuKAnSBIZWFkZXIgUGFyYW1ldGVyIHZhbHVl Lik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWxzbyB3cm90ZSB0aGlzIG5vdyBhcyBw b3NzaWJsZSBpbnB1dCBpbnRvIG91ciB0aGlua2luZyBvbiBvcHRpb25zIGZvciBjcmVhdGluZyBh DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDQ5IiB0YXJnZXQ9Il9i bGFuayI+Q0JPUjwvYT4gSk9TRSBtYXBwaW5nLiZuYnNwOyBJZiB0aGVyZSBhcmUgQ0JPUiB1c2Ug Y2FzZXMgbmVlZGluZyBtYW5hZ2VkIE1BQyBrZXlzLCB0aGlzIGNvdWxkIGhlbHAgdXMgcmVhc29u IGFib3V0IHdheXMgdG8gc3RydWN0dXJlIHRoZSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlllcywgdGhlIHNwZWMgbmFtZSBhbmQgYWJicmV2aWF0aW9uIGFyZSBmYXIgZnJv bSBjYXRjaHkuJm5ic3A7IEJldHRlciBuYW1pbmcgaWRlYXMgd291bGQgYmUgZ3JlYXQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5GZWVkYmFjayB3ZWxjb21lZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5QLlMuJm5ic3A7IFRoaXMgbm90ZSB3YXMgYWxzbyBwb3N0ZWQgYXQNCjxhIGhyZWY9Imh0 dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTEzNDQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby8/cD0xMzQ0PC9hPiBhbmQgYXMgQHNlbGZpc3N1ZWQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB442FCA01F4D1B404C2CDC51F5060BY2PR03MB442namprd_-- From nobody Thu Mar 12 06:11:31 2015 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 6468A1A00E1 for ; Thu, 12 Mar 2015 06:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 853b2J54hxL7 for ; Thu, 12 Mar 2015 06:11:27 -0700 (PDT) Received: from lvs-smtpgate4.nz.fh-koeln.de (lvs-smtpgate4.nz.FH-Koeln.DE [139.6.1.50]) by ietfa.amsl.com (Postfix) with ESMTP id B84EE1A0105 for ; Thu, 12 Mar 2015 06:11:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,388,1422918000"; d="asc'?scan'208";a="18999936" Received: from loiacono.fo.fh-koeln.de ([139.6.100.123]) by smtp.intranet.fh-koeln.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 12 Mar 2015 14:11:25 +0100 Message-ID: <55019208.2030806@fh-koeln.de> Date: Thu, 12 Mar 2015 14:18:00 +0100 From: "Prof. Dr.-Ing. Luigi Lo Iacono" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: jose@ietf.org References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> In-Reply-To: <55006F95.5090807@connect2id.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kr7auKWv3phGtM3grRabgWoR2WdWkmJFH" Archived-At: Subject: Re: [jose] Java-based JOSE implementation X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: luigi.lo_iacono@fh-koeln.de List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 13:11:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kr7auKWv3phGtM3grRabgWoR2WdWkmJFH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Vladimir, yes, we do support the flattened serialisation, but you are right, we did not mention it in the "feature list". This is mainly because we do not see any benefit in having this serialisation. We followed the discussions on it and had own discussions internally. I do not see the point to define a distinct serialisation which is very close to an already existing one. This increases complexity only and that's it. The marginal amount of data reduction coming with the flattened serialisation is ridiculous in comparison to the JSON serialisation with only one signature. I personally like the second approach more, since it still give you the flexibility to add further signatures along the way. Basically, this is the way our architecture supports multiple signatures. They are added by the signing parties one after the other. =46rom our perspective, this is the only realistic use case here. Having = a signing process in possession of multiple distinct private key breaks with a lot of security principles. At least in my understanding or do I miss something here!? In our architectural approach a JwsDocument is constructed by a JwsMaker (either from scratch or by parsing an existing one): JwsDocument jws =3D JwsMaker.generate... Having such an object, getting a particular serialisation is just a matter of calling the respective method: - Compact: jws.getCompactSerialisation(); - Compact DETACHED: jws.getCompactDetachedSerialisation(); - JSON: jws.getJsonSerialisation(); - JSON PRETTYPRINTED: jws.getJsonSerialisation(true); - JSON DETACHED: jws.getJsonDetachedSerialisation(); - JSON PRETTYPRINTED & DETACHED: jws.getJsonDetachedSerialisation(true); - JSON Flattened: jws.getJsonFlattenedSerialisation(); - JSON Flattened PRITTYPRINTED: jws.getJsonFlattenedSerialisation(true); - JSON Flattened DETACHED: jws.getJsonFlattenedDetachedSerialisation(); - JSON Flattened PRITTYPRINTED & DETACHED: jws.getJsonFlattenedDetachedSerialisation(true) Hope that helps!? Do not hesitate to ask further questions. We are happy to help and further feedback is welcome! BR, Luigi. Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov: > Thanks for sharing this. >=20 > I see that you support JSON and compact serialisation, but what is > flattened serialisation? >=20 > Thanks, >=20 > Vladimir >=20 > On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >> Dear all, >> >> we developed an own JOSE implementation in Java, mainly because we >> missed the JSON serialisation in almost all of the available libs. You= >> can grasp it here: >> >> http://jw-asterisk.realsoasecurity.de/ >> >> We are still doing some polishing, that is why the sources are still >> lacking. Stay tuned, though, updates will follow soon... >> >> The documentation and especially the unit tests should help in taking >> the first steps. >> >> Let us know what you think about it... >> >> BR, Luigi. >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > --=20 > Vladimir Dzhuvinov :: vladimir@connect2id.com >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 --kr7auKWv3phGtM3grRabgWoR2WdWkmJFH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVAZIOAAoJEFL6uArWI9sN1+kQANbCvZhsJURJfLS1OZY6CEmY +KHQJMizR6bezUUSB/neocRfClDhvBlSk+ZswQarArQKK2qrVazeuzL7ZJobx0WF alUQ6rQX+tbBbZ+h+qqEmJp7Uwc5t/9SvSZdiKsI5A6a4IT334SZWI8U3NYv3OHd E/Ejohko26LQksQB4pAFg3CjiQlLrL6WUihi8p6QjEzECQAsxUDn7Ths1AYZ7Eti jcak2fy8ogRPELD+KoNRGM9gONLiQ3mM5szhMGVKVOc4ysJamQj7jK8U+78ukPDG wFnLgLLrTbCUW1PEWOVtpSQhn1spOXdLmV7FX579yF9pdMPKFyPs2kfMEBi9EJbY RnDR2peArfLDWhhB1GtRxRklvbmPmkypWKEKURjYkwjhZ3S0oybVqd1hLQnib55m VV7EvXK3mAtO3xj7hBGGVkYfFy4/u4sespXvbK2vePi1wKTyMNVq0IHyVzpMOaIU LB6i1WpM+btC61gMgQF0U8AgzMByKifvtVIwV4kFoj7bO46cjn2YUcfd50G6BieV HtrOJ8xCdfG4gVJCg9bc5rFz82jiuCxLhZC/yW3ntK37WhstgkTu/bTzs32obOzK nnJeC79a+x7QUs/MaM0CEljSDv7ZZML3QdUkJxGXvgxv5sv+chlTbUFly0Rl70/3 /8jVzOGXj8xT+TiQAEZI =Qxq5 -----END PGP SIGNATURE----- --kr7auKWv3phGtM3grRabgWoR2WdWkmJFH-- From nobody Thu Mar 12 07:08:15 2015 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 23CD91A0264 for ; Thu, 12 Mar 2015 07:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnzcr86J3_iS for ; Thu, 12 Mar 2015 07:08:12 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E66D1A0233 for ; Thu, 12 Mar 2015 07:08:12 -0700 (PDT) X-AuditID: 12074423-f79066d0000058b8-9f-55019dcbaeec Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C5.9D.22712.BCD91055; Thu, 12 Mar 2015 10:08:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t2CE8ABd025230; Thu, 12 Mar 2015 10:08:10 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2CE7Cph002659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2015 10:08:10 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_581232E4-4B9F-4D76-A45E-780E64DC181F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Justin Richer In-Reply-To: <55019208.2030806@fh-koeln.de> Date: Thu, 12 Mar 2015 10:08:09 -0400 Message-Id: <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> To: luigi.lo_iacono@fh-koeln.de X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsUixG6nont6LmOowZyZ/BZr1nQzWZxq6WN2 YPJ4tn0+k8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJeP9nCVPBbp6L50g2WBsb7ql2MnBwSAiYS n+4/ZYSwxSQu3FvPBmILCSxmkthxK7SLkQvI3sgocXPycXYI5yGTxP9Lt1lAqoQFjCRWnXkN ZvMKGEjMPfWFCaSIWWASo8SNZd3sEGOlJB7cXgO2gk1AVWL6mhYmEJtTQFti3t8NYM0sQPGm nkdgNrOAoMSkxxsYIYZaSSx6dZEF4qRsiYkv94GdJyIgL7Gp4zWQzQE0X16iZ1P6BEbBWUjO mIXsjFlgY7Ulli18zQxhG0g87XzFCmHLS2x/OwcqbimxeOYNFgjbVuJW3wImCNtO4tG0RawL GDlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrp5WaW6KWmlG5iBMeOi/IOxj8HlQ4xCnAwKvHw PmBlDBViTSwrrsw9xCjJwaQkysvaDRTiS8pPqcxILM6ILyrNSS0+xKgCtOvRhtUXGKVY8vLz UpVEeEvbgep4UxIrq1KL8mHKpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnw1s4BahQs Sk1PrUjLzClBSDNxcB5ilODgARqeDVLDW1yQmFucmQ6RP8WoKCXOawmSEABJZJTmwfXCUt4r RnGgt4R554JU8QDTJVz3K6DBTECDWaz/hwANLklESEk1MHaWSaT9vnW+7pfyllIXuQq/GrGi 1ErzrNpron/OlYoeua46d538g1uHK29Jx2d5Mory7LTu52zO3dh44+MPq1KLlfzntk78ZWhS vlGJUX7JhbhUzg0ZwQse1HnFRG1/e7Hbnof1ce/EI1/dLixOD7veyrxZ9dHBnwHfluzdwc6T 0eVz4PL3qUosxRmJhlrMRcWJAKGmKzlUAwAA Archived-At: Cc: jose@ietf.org Subject: Re: [jose] Java-based JOSE implementation 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, 12 Mar 2015 14:08:15 -0000 --Apple-Mail=_581232E4-4B9F-4D76-A45E-780E64DC181F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Just to add some perspective, if by =93flattened=94 serialization, you = mean the compact serializations of JWS (header.payload.signature) and = JWE (header.stuff.stuff.stuff.stuff I forgot the order), then there are = huge advantages to these, and they=92re the only ones that I personally = use. The simplicity gained in processing the compact forms, both in terms of = generating and consuming. With the compact forms, you get something that = can be dropped on the wire into an HTTP header, form parameter, query = parameter, a string in just about any language, all without any quoting = or further processing. Plus, to get back to the crypto calculations, you = use the literal strings sent across the wire, which is a really nice = feature. I=92ve personally yet to have a use case that required the multiple = signatures or other features of the JSON serialized flavor, nor have I = seen much uptake of it in the wild compared to the compact forms. =97 Justin > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono = wrote: >=20 > Dear Vladimir, >=20 > yes, we do support the flattened serialisation, but you are right, we > did not mention it in the "feature list". This is mainly because we do > not see any benefit in having this serialisation. We followed the > discussions on it and had own discussions internally. I do not see the > point to define a distinct serialisation which is very close to an > already existing one. This increases complexity only and that's it. = The > marginal amount of data reduction coming with the flattened > serialisation is ridiculous in comparison to the JSON serialisation = with > only one signature. I personally like the second approach more, since = it > still give you the flexibility to add further signatures along the = way. > Basically, this is the way our architecture supports multiple > signatures. They are added by the signing parties one after the other. > =46rom our perspective, this is the only realistic use case here. = Having a > signing process in possession of multiple distinct private key breaks > with a lot of security principles. At least in my understanding or do = I > miss something here!? >=20 > In our architectural approach a JwsDocument is constructed by a = JwsMaker > (either from scratch or by parsing an existing one): >=20 > JwsDocument jws =3D JwsMaker.generate... >=20 > Having such an object, getting a particular serialisation is just a > matter of calling the respective method: >=20 > - Compact: jws.getCompactSerialisation(); > - Compact DETACHED: jws.getCompactDetachedSerialisation(); > - JSON: jws.getJsonSerialisation(); > - JSON PRETTYPRINTED: jws.getJsonSerialisation(true); > - JSON DETACHED: jws.getJsonDetachedSerialisation(); > - JSON PRETTYPRINTED & DETACHED: = jws.getJsonDetachedSerialisation(true); > - JSON Flattened: jws.getJsonFlattenedSerialisation(); > - JSON Flattened PRITTYPRINTED: = jws.getJsonFlattenedSerialisation(true); > - JSON Flattened DETACHED: = jws.getJsonFlattenedDetachedSerialisation(); > - JSON Flattened PRITTYPRINTED & DETACHED: > jws.getJsonFlattenedDetachedSerialisation(true) >=20 > Hope that helps!? >=20 > Do not hesitate to ask further questions. We are happy to help and > further feedback is welcome! >=20 > BR, Luigi. >=20 >=20 > Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov: >> Thanks for sharing this. >>=20 >> I see that you support JSON and compact serialisation, but what is >> flattened serialisation? >>=20 >> Thanks, >>=20 >> Vladimir >>=20 >> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>> Dear all, >>>=20 >>> we developed an own JOSE implementation in Java, mainly because we >>> missed the JSON serialisation in almost all of the available libs. = You >>> can grasp it here: >>>=20 >>> http://jw-asterisk.realsoasecurity.de/ >>>=20 >>> We are still doing some polishing, that is why the sources are still >>> lacking. Stay tuned, though, updates will follow soon... >>>=20 >>> The documentation and especially the unit tests should help in = taking >>> the first steps. >>>=20 >>> Let us know what you think about it... >>>=20 >>> BR, Luigi. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> -- >> Vladimir Dzhuvinov :: vladimir@connect2id.com >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_581232E4-4B9F-4D76-A45E-780E64DC181F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJVAZ3JAAoJEDPAngkbd+w9QOkH/A3VCd9EkdoOcmP759GMIZqT NNwr8stlISXPIDUSytSFDR249WHgjTybPal4R9T9ShkRINuSc4xKEg6ZoGvKghEC EpB5L5Bjr1OPbVx+d+EhQotFArTlRrqnCVRTLLKSyctmlEzF7zZV2mX79/lJhFMO KarC/fjVfsBLD+qEH/jtIUNJdc+1d0db8q2bYRs/Ze+WVasS4EA/RRThFE/I73oG qgwJEsxdsTmmEl1ADLbVVIGL4EAhG2lmeUp8CX9DWAL8RJ44CsFyAM1vs9Z3yWCV p5FMdRfvbtIXGAKhOTrfXgIiE86jo9YYGV8MEmPDY8F44qURMbO6Epj4IPvPuyE= =pDfX -----END PGP SIGNATURE----- --Apple-Mail=_581232E4-4B9F-4D76-A45E-780E64DC181F-- From nobody Thu Mar 12 07:50:18 2015 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 244991A870B for ; Thu, 12 Mar 2015 07:50:16 -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 M-aP62GPynVf for ; Thu, 12 Mar 2015 07:50:13 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649AE1A8701 for ; Thu, 12 Mar 2015 07:50:11 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKVQGnorPIzuyBVRGNR3+TDlcMERMqviGm@postini.com; Thu, 12 Mar 2015 07:50:11 PDT Received: by igbhl2 with SMTP id hl2so17152497igb.5 for ; Thu, 12 Mar 2015 07:50:10 -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=xEJ3BkCzz9+Uiv8RNiYvtmqD6sfHwKi0A8pe3vpkq64=; b=UmoO9VOZ5N770GLjfmoDqnzPKJkB91euL4Sffs+TWmfY0xgTgyTg9UeJtQa5ire/ZQ B7clc7BOd4si8cpLokOI4nz9G1/3dmnWy09IP2tHn44Hp1dWNOuZvljxI3h04TBZ4XKv rqKrw3Lz7Zc2nu7lcJLxvE822YW8e97YVzrZNh7rKOayqC3yidkjuzDSVa2yjdgrNm2g 7+ppO48y+B3KZ87ThOU8gPyqUQiIDAETxRVQzNstRiHnGzqR63fbT+vx811E3izxN5/S xJwQGKrF5w/cJsqdv8eIBOgvOhkDbZ6dlWLjyc+DoXuw8uwlRGaZLwfvLxe8FkFuFLmN kUeg== X-Gm-Message-State: ALoCoQmhWrCiczlMoZMD7a2Ufx0E7B5pTn6rxO8ZGap91SCkz34dNbPQ1UjoHFBMYxTWqfuDx+UW5f/xBlZ/gxSO9BYkeznbivKafitoADyACZcA7GQOXF9nSzvNEicDxKDu4KGYxFlN X-Received: by 10.107.154.79 with SMTP id c76mr77078572ioe.14.1426171810351; Thu, 12 Mar 2015 07:50:10 -0700 (PDT) X-Received: by 10.107.154.79 with SMTP id c76mr77078364ioe.14.1426171809246; Thu, 12 Mar 2015 07:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.143.138 with HTTP; Thu, 12 Mar 2015 07:49:39 -0700 (PDT) In-Reply-To: <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> From: Brian Campbell Date: Thu, 12 Mar 2015 08:49:39 -0600 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a1140fa20146b4505111880e7 Archived-At: Cc: luigi.lo_iacono@fh-koeln.de, "jose@ietf.org" Subject: Re: [jose] Java-based JOSE implementation 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, 12 Mar 2015 14:50:16 -0000 --001a1140fa20146b4505111880e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable flattened is not the same as compact FWIW compact -> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7= .1 flattened -> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7= .2.2 On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer wrote: > Just to add some perspective, if by =E2=80=9Cflattened=E2=80=9D serializa= tion, you mean > the compact serializations of JWS (header.payload.signature) and JWE > (header.stuff.stuff.stuff.stuff I forgot the order), then there are huge > advantages to these, and they=E2=80=99re the only ones that I personally = use. > > The simplicity gained in processing the compact forms, both in terms of > generating and consuming. With the compact forms, you get something that > can be dropped on the wire into an HTTP header, form parameter, query > parameter, a string in just about any language, all without any quoting o= r > further processing. Plus, to get back to the crypto calculations, you use > the literal strings sent across the wire, which is a really nice feature. > > I=E2=80=99ve personally yet to have a use case that required the multiple > signatures or other features of the JSON serialized flavor, nor have I se= en > much uptake of it in the wild compared to the compact forms. > > =E2=80=94 Justin > > > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono < > luigi.lo_iacono@fh-koeln.de> wrote: > > > > Dear Vladimir, > > > > yes, we do support the flattened serialisation, but you are right, we > > did not mention it in the "feature list". This is mainly because we do > > not see any benefit in having this serialisation. We followed the > > discussions on it and had own discussions internally. I do not see the > > point to define a distinct serialisation which is very close to an > > already existing one. This increases complexity only and that's it. The > > marginal amount of data reduction coming with the flattened > > serialisation is ridiculous in comparison to the JSON serialisation wit= h > > only one signature. I personally like the second approach more, since i= t > > still give you the flexibility to add further signatures along the way. > > Basically, this is the way our architecture supports multiple > > signatures. They are added by the signing parties one after the other. > > From our perspective, this is the only realistic use case here. Having = a > > signing process in possession of multiple distinct private key breaks > > with a lot of security principles. At least in my understanding or do I > > miss something here!? > > > > In our architectural approach a JwsDocument is constructed by a JwsMake= r > > (either from scratch or by parsing an existing one): > > > > JwsDocument jws =3D JwsMaker.generate... > > > > Having such an object, getting a particular serialisation is just a > > matter of calling the respective method: > > > > - Compact: jws.getCompactSerialisation(); > > - Compact DETACHED: jws.getCompactDetachedSerialisation(); > > - JSON: jws.getJsonSerialisation(); > > - JSON PRETTYPRINTED: jws.getJsonSerialisation(true); > > - JSON DETACHED: jws.getJsonDetachedSerialisation(); > > - JSON PRETTYPRINTED & DETACHED: jws.getJsonDetachedSerialisation(true)= ; > > - JSON Flattened: jws.getJsonFlattenedSerialisation(); > > - JSON Flattened PRITTYPRINTED: jws.getJsonFlattenedSerialisation(true)= ; > > - JSON Flattened DETACHED: jws.getJsonFlattenedDetachedSerialisation(); > > - JSON Flattened PRITTYPRINTED & DETACHED: > > jws.getJsonFlattenedDetachedSerialisation(true) > > > > Hope that helps!? > > > > Do not hesitate to ask further questions. We are happy to help and > > further feedback is welcome! > > > > BR, Luigi. > > > > > > Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov: > >> Thanks for sharing this. > >> > >> I see that you support JSON and compact serialisation, but what is > >> flattened serialisation? > >> > >> Thanks, > >> > >> Vladimir > >> > >> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: > >>> Dear all, > >>> > >>> we developed an own JOSE implementation in Java, mainly because we > >>> missed the JSON serialisation in almost all of the available libs. Yo= u > >>> can grasp it here: > >>> > >>> http://jw-asterisk.realsoasecurity.de/ > >>> > >>> We are still doing some polishing, that is why the sources are still > >>> lacking. Stay tuned, though, updates will follow soon... > >>> > >>> The documentation and especially the unit tests should help in taking > >>> the first steps. > >>> > >>> Let us know what you think about it... > >>> > >>> BR, Luigi. > >>> > >>> > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > >> -- > >> Vladimir Dzhuvinov :: vladimir@connect2id.com > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > >> > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a1140fa20146b4505111880e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu= , Mar 12, 2015 at 8:08 AM, Justin Richer <jricher@mit.edu> wro= te:
Just to add some perspective, if by = =E2=80=9Cflattened=E2=80=9D serialization, you mean the compact serializati= ons of JWS (header.payload.signature) and JWE (header.stuff.stuff.stuff.stu= ff I forgot the order), then there are huge advantages to these, and they= =E2=80=99re the only ones that I personally use.

The simplicity gained in processing the compact forms, both in terms of gen= erating and consuming. With the compact forms, you get something that can b= e dropped on the wire into an HTTP header, form parameter, query parameter,= a string in just about any language, all without any quoting or further pr= ocessing. Plus, to get back to the crypto calculations, you use the literal= strings sent across the wire, which is a really nice feature.

I=E2=80=99ve personally yet to have a use case that required the multiple s= ignatures or other features of the JSON serialized flavor, nor have I seen = much uptake of it in the wild compared to the compact forms.

=C2=A0=E2=80=94 Justin

> On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono <luigi.lo_iacono@fh-koeln.de>= ; wrote:
>
> Dear Vladimir,
>
> yes, we do support the flattened serialisation, but you are right, we<= br> > did not mention it in the "feature list". This is mainly bec= ause we do
> not see any benefit in having this serialisation. We followed the
> discussions on it and had own discussions internally. I do not see the=
> point to define a distinct serialisation which is very close to an
> already existing one. This increases complexity only and that's it= . The
> marginal amount of data reduction coming with the flattened
> serialisation is ridiculous in comparison to the JSON serialisation wi= th
> only one signature. I personally like the second approach more, since = it
> still give you the flexibility to add further signatures along the way= .
> Basically, this is the way our architecture supports multiple
> signatures. They are added by the signing parties one after the other.=
> From our perspective, this is the only realistic use case here. Having= a
> signing process in possession of multiple distinct private key breaks<= br> > with a lot of security principles. At least in my understanding or do = I
> miss something here!?
>
> In our architectural approach a JwsDocument is constructed by a JwsMak= er
> (either from scratch or by parsing an existing one):
>
> JwsDocument jws =3D JwsMaker.generate...
>
> Having such an object, getting a particular serialisation is just a > matter of calling the respective method:
>
> - Compact: jws.getCompactSerialisation();
> - Compact DETACHED: jws.getCompactDetachedSerialisation();
> - JSON: jws.getJsonSerialisation();
> - JSON PRETTYPRINTED: jws.getJsonSerialisation(true);
> - JSON DETACHED: jws.getJsonDetachedSerialisation();
> - JSON PRETTYPRINTED & DETACHED: jws.getJsonDetachedSerialisation(= true);
> - JSON Flattened: jws.getJsonFlattenedSerialisation();
> - JSON Flattened PRITTYPRINTED: jws.getJsonFlattenedSerialisation(true= );
> - JSON Flattened DETACHED: jws.getJsonFlattenedDetachedSerialisation()= ;
> - JSON Flattened PRITTYPRINTED & DETACHED:
>=C2=A0 jws.getJsonFlattenedDetachedSerialisation(true)
>
> Hope that helps!?
>
> Do not hesitate to ask further questions. We are happy to help and
> further feedback is welcome!
>
> BR, Luigi.
>
>
> Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov:
>> Thanks for sharing this.
>>
>> I see that you support JSON and compact serialisation, but what is=
>> flattened serialisation?
>>
>> Thanks,
>>
>> Vladimir
>>
>> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
>>> Dear all,
>>>
>>> we developed an own JOSE implementation in Java, mainly becaus= e we
>>> missed the JSON serialisation in almost all of the available l= ibs. You
>>> can grasp it here:
>>>
>>> http://jw-asterisk.realsoasecurity.de/
>>>
>>> We are still doing some polishing, that is why the sources are= still
>>> lacking. Stay tuned, though, updates will follow soon...
>>>
>>> The documentation and especially the unit tests should help in= taking
>>> the first steps.
>>>
>>> Let us know what you think about it...
>>>
>>> BR, Luigi.
>>>
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> --
>> Vladimir Dzhuvinov :: v= ladimir@connect2id.com
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


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


--001a1140fa20146b4505111880e7-- From nobody Thu Mar 12 08:38:46 2015 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 B5C671A88F0 for ; Thu, 12 Mar 2015 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBXX0ukBh4nX for ; Thu, 12 Mar 2015 08:38:37 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4901A88E3 for ; Thu, 12 Mar 2015 08:38:37 -0700 (PDT) Received: by qgea108 with SMTP id a108so18965339qge.8 for ; Thu, 12 Mar 2015 08:38:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SU0VlJZwItS5tIIoc40Ga4pIgZ9VU5eg6UeeNZAyiqM=; b=SdyHe4YIcQqnXaPBoG3KrrasgQtQfmzGNbJhcnVifpDAzWP3Bc/x9KqdAuQ+bJ+RLn VTj5eBCgi0BhjFh38nIh21BOgP2qf12fhK1rsNoUH8rghJva1ou/lYeuWAHxIIUWlBCN ivwuu9FDsKrnJiBlx86m/nCgkIg5JfvMJisQIhRISQOHOjad5LZyhIB+AY7KdaUDFLkv YAokMIkY3al5e8++vHyseQop5BJhHYWkPRq2iYd9TAgVsCPxJ1SsPE6ONO744bgnO9EL LIaUPLjpfgDKB3UZ61WwbpvFMvARRX1ijwuwjkL7hg7BdjyEVSkUBsxsaVIqbSqz0WRa 09yw== X-Gm-Message-State: ALoCoQlMGajATNpFzJyxr+Tv3mzKxHdzeO37fbA/V46ZxFVECAbvtKzokM/u70IaXpAeqfXBvFbs X-Received: by 10.140.148.201 with SMTP id 192mr27786118qhu.36.1426174716568; Thu, 12 Mar 2015 08:38:36 -0700 (PDT) Received: from [192.168.8.100] ([181.202.5.185]) by mx.google.com with ESMTPSA id l49sm4977781qgd.21.2015.03.12.08.38.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 08:38:35 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B21A29EE-379A-4F93-BB63-9B293F1B9536"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Thu, 12 Mar 2015 12:38:30 -0300 Message-Id: <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: luigi.lo_iacono@fh-koeln.de, "jose@ietf.org" , Justin Richer Subject: Re: [jose] Java-based JOSE implementation 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, 12 Mar 2015 15:38:44 -0000 --Apple-Mail=_B21A29EE-379A-4F93-BB63-9B293F1B9536 Content-Type: multipart/alternative; boundary="Apple-Mail=_E1F26B03-697B-4DAB-BB3F-3546D0348A72" --Apple-Mail=_E1F26B03-697B-4DAB-BB3F-3546D0348A72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes flattened is a special case of the JSON serialization that has only = one signature. I don't know that there is a huge benefit to it over the regular JSON = serialization that supports multiple signatures. Some people really wanted it at the time. =20 Supporting the general JSON serialization would be a higher priority for = me. In most cases I have seen, as Justin points out people wanting a = single signature go with compact. John B. > On Mar 12, 2015, at 11:49 AM, Brian Campbell = wrote: >=20 > flattened is not the same as compact FWIW=20 >=20 > compact -> = https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-= 7.1 = >=20 > flattened -> = https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-= 7.2.2 = >=20 > On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer > wrote: > Just to add some perspective, if by =E2=80=9Cflattened=E2=80=9D = serialization, you mean the compact serializations of JWS = (header.payload.signature) and JWE (header.stuff.stuff.stuff.stuff I = forgot the order), then there are huge advantages to these, and = they=E2=80=99re the only ones that I personally use. >=20 > The simplicity gained in processing the compact forms, both in terms = of generating and consuming. With the compact forms, you get something = that can be dropped on the wire into an HTTP header, form parameter, = query parameter, a string in just about any language, all without any = quoting or further processing. Plus, to get back to the crypto = calculations, you use the literal strings sent across the wire, which is = a really nice feature. >=20 > I=E2=80=99ve personally yet to have a use case that required the = multiple signatures or other features of the JSON serialized flavor, nor = have I seen much uptake of it in the wild compared to the compact forms. >=20 > =E2=80=94 Justin >=20 > > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono = > = wrote: > > > > Dear Vladimir, > > > > yes, we do support the flattened serialisation, but you are right, = we > > did not mention it in the "feature list". This is mainly because we = do > > not see any benefit in having this serialisation. We followed the > > discussions on it and had own discussions internally. I do not see = the > > point to define a distinct serialisation which is very close to an > > already existing one. This increases complexity only and that's it. = The > > marginal amount of data reduction coming with the flattened > > serialisation is ridiculous in comparison to the JSON serialisation = with > > only one signature. I personally like the second approach more, = since it > > still give you the flexibility to add further signatures along the = way. > > Basically, this is the way our architecture supports multiple > > signatures. They are added by the signing parties one after the = other. > > =46rom our perspective, this is the only realistic use case here. = Having a > > signing process in possession of multiple distinct private key = breaks > > with a lot of security principles. At least in my understanding or = do I > > miss something here!? > > > > In our architectural approach a JwsDocument is constructed by a = JwsMaker > > (either from scratch or by parsing an existing one): > > > > JwsDocument jws =3D JwsMaker.generate... > > > > Having such an object, getting a particular serialisation is just a > > matter of calling the respective method: > > > > - Compact: jws.getCompactSerialisation(); > > - Compact DETACHED: jws.getCompactDetachedSerialisation(); > > - JSON: jws.getJsonSerialisation(); > > - JSON PRETTYPRINTED: jws.getJsonSerialisation(true); > > - JSON DETACHED: jws.getJsonDetachedSerialisation(); > > - JSON PRETTYPRINTED & DETACHED: = jws.getJsonDetachedSerialisation(true); > > - JSON Flattened: jws.getJsonFlattenedSerialisation(); > > - JSON Flattened PRITTYPRINTED: = jws.getJsonFlattenedSerialisation(true); > > - JSON Flattened DETACHED: = jws.getJsonFlattenedDetachedSerialisation(); > > - JSON Flattened PRITTYPRINTED & DETACHED: > > jws.getJsonFlattenedDetachedSerialisation(true) > > > > Hope that helps!? > > > > Do not hesitate to ask further questions. We are happy to help and > > further feedback is welcome! > > > > BR, Luigi. > > > > > > Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov: > >> Thanks for sharing this. > >> > >> I see that you support JSON and compact serialisation, but what is > >> flattened serialisation? > >> > >> Thanks, > >> > >> Vladimir > >> > >> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: > >>> Dear all, > >>> > >>> we developed an own JOSE implementation in Java, mainly because we > >>> missed the JSON serialisation in almost all of the available libs. = You > >>> can grasp it here: > >>> > >>> http://jw-asterisk.realsoasecurity.de/ = > >>> > >>> We are still doing some polishing, that is why the sources are = still > >>> lacking. Stay tuned, though, updates will follow soon... > >>> > >>> The documentation and especially the unit tests should help in = taking > >>> the first steps. > >>> > >>> Let us know what you think about it... > >>> > >>> BR, Luigi. > >>> > >>> > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose = > >> > >> -- > >> Vladimir Dzhuvinov :: vladimir@connect2id.com = > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose = > >> > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose = >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose = >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_E1F26B03-697B-4DAB-BB3F-3546D0348A72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes flattened is a special case of the JSON serialization = that has only one signature.

I don't know that there is a huge benefit to it over the = regular JSON serialization that supports multiple signatures.

Some people really = wanted it at the time.  

Supporting the general JSON = serialization would be a higher priority for me.  In most cases I = have seen, as Justin points out people wanting a single signature go = with compact.

John B.


On Mar 12, 2015, at 11:49 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:


On Thu, Mar 12, 2015 at 8:08 AM, = Justin Richer <jricher@mit.edu> wrote:
Just to add some perspective, if by = =E2=80=9Cflattened=E2=80=9D serialization, you mean the compact = serializations of JWS (header.payload.signature) and JWE = (header.stuff.stuff.stuff.stuff I forgot the order), then there are huge = advantages to these, and they=E2=80=99re the only ones that I personally = use.

The simplicity gained in processing the compact forms, both in terms of = generating and consuming. With the compact forms, you get something that = can be dropped on the wire into an HTTP header, form parameter, query = parameter, a string in just about any language, all without any quoting = or further processing. Plus, to get back to the crypto calculations, you = use the literal strings sent across the wire, which is a really nice = feature.

I=E2=80=99ve personally yet to have a use case that required the = multiple signatures or other features of the JSON serialized flavor, nor = have I seen much uptake of it in the wild compared to the compact = forms.

 =E2=80=94 Justin

> On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono <luigi.lo_iacono@fh-koeln.de> wrote:
>
> Dear Vladimir,
>
> yes, we do support the flattened serialisation, but you are right, = we
> did not mention it in the "feature list". This is mainly because we = do
> not see any benefit in having this serialisation. We followed = the
> discussions on it and had own discussions internally. I do not see = the
> point to define a distinct serialisation which is very close to = an
> already existing one. This increases complexity only and that's it. = The
> marginal amount of data reduction coming with the flattened
> serialisation is ridiculous in comparison to the JSON serialisation = with
> only one signature. I personally like the second approach more, = since it
> still give you the flexibility to add further signatures along the = way.
> Basically, this is the way our architecture supports multiple
> signatures. They are added by the signing parties one after the = other.
> =46rom our perspective, this is the only realistic use case here. = Having a
> signing process in possession of multiple distinct private key = breaks
> with a lot of security principles. At least in my understanding or = do I
> miss something here!?
>
> In our architectural approach a JwsDocument is constructed by a = JwsMaker
> (either from scratch or by parsing an existing one):
>
> JwsDocument jws =3D JwsMaker.generate...
>
> Having such an object, getting a particular serialisation is just = a
> matter of calling the respective method:
>
> - Compact: jws.getCompactSerialisation();
> - Compact DETACHED: jws.getCompactDetachedSerialisation();
> - JSON: jws.getJsonSerialisation();
> - JSON PRETTYPRINTED: jws.getJsonSerialisation(true);
> - JSON DETACHED: jws.getJsonDetachedSerialisation();
> - JSON PRETTYPRINTED & DETACHED: = jws.getJsonDetachedSerialisation(true);
> - JSON Flattened: jws.getJsonFlattenedSerialisation();
= > - JSON Flattened PRITTYPRINTED: = jws.getJsonFlattenedSerialisation(true);
> - JSON Flattened DETACHED: = jws.getJsonFlattenedDetachedSerialisation();
> - JSON Flattened PRITTYPRINTED & DETACHED:
>  jws.getJsonFlattenedDetachedSerialisation(true)
>
> Hope that helps!?
>
> Do not hesitate to ask further questions. We are happy to help = and
> further feedback is welcome!
>
> BR, Luigi.
>
>
> Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov:
>> Thanks for sharing this.
>>
>> I see that you support JSON and compact serialisation, but what = is
>> flattened serialisation?
>>
>> Thanks,
>>
>> Vladimir
>>
>> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
>>> Dear all,
>>>
>>> we developed an own JOSE implementation in Java, mainly = because we
>>> missed the JSON serialisation in almost all of the = available libs. You
>>> can grasp it here:
>>>
>>> http://jw-asterisk.realsoasecurity.de/ >>>
>>> We are still doing some polishing, that is why the sources = are still
>>> lacking. Stay tuned, though, updates will follow soon...
>>>
>>> The documentation and especially the unit tests should help = in taking
>>> the first steps.
>>>
>>> Let us know what you think about it...
>>>
>>> BR, Luigi.
>>>
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> --
>> Vladimir Dzhuvinov :: vladimir@connect2id.com
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


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


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

= --Apple-Mail=_E1F26B03-697B-4DAB-BB3F-3546D0348A72-- --Apple-Mail=_B21A29EE-379A-4F93-BB63-9B293F1B9536 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTIxNTM4MzBaMCMGCSqGSIb3DQEJBDEWBBR4Ue0LNKAH9echBe06vSqd X1eMwTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCo5T5UqzDZLqYHs3QDIdQLaEQhoZuYGAttwC02MQ/8l3mP1pSnImIj A74FGF2bU4qsBImwS7zRuwKE7ngHIN7jNaoKsfFSSKN/I6zGUyJPIvNbmYUgdoeyqWJuLVwmpEMC vdHb5F/3ArLRH0uG07lSr9cKOx5RyRUpNgKgLayjCEvmy6NbdRZmdKnjaeSg0kYfBZgYwlpf7NMh KKpiA2gu9knDzNF45Y730OjqH5Cj+izrLF6q6xD0ICSQG/AknFgsmGILfZ2+AoQcE4JY9bJwWlLo 2XYNGP9vMYPPlYSulB9dMdiHzAfuUCHVOqys6vyIJCwr5ANIGGC+W6JirI8KAAAAAAAA --Apple-Mail=_B21A29EE-379A-4F93-BB63-9B293F1B9536-- From nobody Thu Mar 12 08:56:16 2015 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 1BE4F1A8779 for ; Thu, 12 Mar 2015 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52lZ7WpMok8l for ; Thu, 12 Mar 2015 08:56:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257261A8775 for ; Thu, 12 Mar 2015 08:56:07 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.106.11; Thu, 12 Mar 2015 15:55:45 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0106.007; Thu, 12 Mar 2015 15:55:45 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Key Managed JSON Web Signature (KMJWS) specification Thread-Index: AdBVnrlYeSkbpnXYQGWf+2U9DVU+8wG2dZWAAARd7NAAFJ1+sA== Date: Thu, 12 Mar 2015 15:55:45 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.90.173] authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(209900001)(377454003)(52604005)(51704005)(87936001)(2656002)(62966003)(74316001)(19617315012)(107886001)(77096005)(77156002)(99286002)(40100003)(76576001)(122556002)(16236675004)(19609705001)(86362001)(66066001)(86612001)(2900100001)(19300405004)(50986999)(76176999)(2950100001)(54356999)(102836002)(15975445007)(2501003)(92566002)(46102003)(19580395003)(19580405001)(33656002)(19625215002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 05134F8B4F Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4420B9763C5DB021DEE13DBF5060BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 15:55:45.6825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 12 Mar 2015 15:56:14 -0000 --_000_BY2PR03MB4420B9763C5DB021DEE13DBF5060BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll add one other thing, Jim. I'm sorry that you left the Denver meeting = feeling like your idea for key management was dismissed. We should have pu= shed harder then to try to come up with an approach for that that would wor= k for all. I'll try to personally take this an object lesson for future st= andards work. See you in Dallas! -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Thursday, March 12, 2015 12:37 AM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification Hi Jim. Thanks for responding and for your honest feedback. While you may= feel insulted (I'm genuinely sorry about that!), I'm to try to take the ne= gatives you've expressed as positives, in the sense that they can construct= ively inform future work by the working group. One reason I wrote this draft was to get down a straightforward way of usin= g key managed HMACs, should people want to do that in the future, especiall= y since there's talk of closing the working group soon. The other reason I= wrote it was to further illuminate the upsides and downsides of some of th= e choices we made in JWS and JWE, given we have a chance to reuse and/or re= visit those choices should the COSE work go forward. Replies to your specific points follow inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, March 11, 2015 8:57 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Key Managed JSON Web Signature (KMJWS) specification > I cannot respond for Richard, but personally I feel rather insulted by th= e current draft. My first half a dozen responses were rather vulgar and pe= jorative to this draft and thus deleted. > > This draft seems to be, more or less, what Richard and I were proposing i= n Denver and were told was not possible due to backwards compatibility. Wh= at has changed that this is no longer true? For what it's worth, I've occasionally been thinking about key management f= or MACs ever since you and Richard raised the possibility in Denver. Somew= here along the way I realized that there was a simple way to combine the JW= E key management methods and the JWS MAC methods. So I decided to write it= down, while there was still a working group to consider it, should the wor= king group decide to do so. If the reason you're insulted is that you feel that you should receive more= credit for some of the ideas, I'd be glad to point out in the Acknowledgem= ents that you and Richard suggested the possibility of key-managed MACs and= /or make you co-editors if you agree with the approach and would like to wo= rk more actively on it. If the reason that you're insulted is that you fee= l that we should have done this earlier, I think the verdict is still out o= n whether we need to do this at all. Looking at http://trac.tools.ietf.org= /wg/jose/trac/ticket/2, Karen made a consensus call that "we should not add= the ability to have a randomly generated MAC key protected by a different = key" based on working group input. I think the key question for the working group relative to this draft is wh= ether people now want to see a standard way to do this or not. As for the backwards compatibility issues discussed in Denver, I know that = several participants were opposed to seeing the JWS format for non-key-mana= ged MACs change. I suspect that's what you're referring to. The good news= about the current draft is that it adds the ability to have key-managed MA= Cs without such a change. Should we have thought of this approach then? Probably. Did we? At least= I didn't. I thought of it recently, so I decided to write it down. > Why is there need to have a compact formation for this draft? We were to= ld in no uncertain terms that this was completely unnecessary in Denver and= thus was out of scope for the documents. I can't remember the part of the discussion that you're referring to in Den= ver and I can't find it in the published notes. The only uses of "compact"= in the notes aren't about this. That said, there's a compact serialization for key managed MACs for the sam= e reason that there's a compact serialization for the other JOSE objects - = to provide a compact, URL-safe representation for use cases that need it. = It also makes this draft more parallel to both JWS and JWE than it would ot= herwise be. > This document does not seem to have read the security considerations sect= ion of the JWS draft specifically dealing with the existence of multiple sh= arers of the secret key. I'm not sure I'm following you here, because different recipients use diffe= rent ephemeral keys in this representation. What's the security considerat= ion that you think wasn't taken into account? > This document has messed up the current documentation in JWE about how to= determine what type of document is being presented. This is completely un= acceptable. It's backwards-compatible in the sense that if an implementation supports J= WSs and JWEs but not KMJWSs (I'm still looking for a better name than KMJWS= , BTW), the current rules all continue to do the right thing. If an implem= entation supports all three, yes, a little bit of additional logic would be= needed, just like a little bit of additional code would be needed, but no = breaking changes result. A KMJWS is neither a legal JWS nor a legal JWE, s= o even if the existing discrimination rules were applied to a KMJWS and it = was mis-categorized as one or the other, upon parsing, it would still be re= jected, since it would be missing required properties. > There are now multiple representations of direct keying for mac. This is= a significant problem as one does not know which of the version one is sup= posed to be using. Thanks for pointing this out. We should probably just prohibit the use of = "alg":"dir" in KMJWS so that there's exactly one way of representing non-ke= y-managed MACS - the existing way. > (The fact that I am half, if not all the way drunk has make this message = much easier to write). I'm glad you enjoyed your evening. :) > Jim Thanks again, -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, March 03, 2015 2:42 AM To: jose@ietf.org Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification I took a little time today and wrote a short draft specifying a JWS-like ob= ject that uses key management for the MAC key used to integrity protect the= payload. We had considered doing this in JOSE issue #2 but didn't do so at the time because of lac= k of demand. However, I wanted to get this down now to demonstrate that it= is easy to do and specify a way to do it, should demand develop in the fut= ure - possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones= -jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/dra= ft-jones-jose-key-managed-json-web-signature-00.html. This spec reuses key management functionality already present in the JWE sp= ec and MAC = functionality already present in the JWS spec. The result is essentially a JWS with an= Encrypted Key value added, and a new "mac" Header Parameter value represen= ting the MAC algorithm used. (Like JWE, the key management algorithm is ca= rried in the "alg" Header Parameter value.) I also wrote this now as possible input into our thinking on options for cr= eating a CBOR JOSE mapping. If there a= re CBOR use cases needing managed MAC keys, this could help us reason about= ways to structure the solution. Yes, the spec name and abbreviation are far from catchy. Better naming ide= as would be great. Feedback welcomed. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1344 and as= @selfissued. --_000_BY2PR03MB4420B9763C5DB021DEE13DBF5060BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll add one oth= er thing, Jim.  I’m sorry that you left the Denver meeting feeli= ng like your idea for key management was dismissed.  We should have pushed harder then to t= ry to come up with an approach for that that would work for all.  I= 217;ll try to personally take this an object lesson for future standards wo= rk.

 

See you in Dallas!

 

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

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, March 12, 2015 12:37 AM
To: Jim Schaad; jose@ietf.org
Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specifica= tion

 

Hi Jim.  Thanks f= or responding and for your honest feedback.  While you may feel insult= ed (I’m genuinely sorry about that!), I’m to try to take the ne= gatives you’ve expressed as positives, in the sense that they can constructively inform future work by the working group.

 

One reason I wrote thi= s draft was to get down a straightforward way of using key managed HMACs, s= hould people want to do that in the future, especially since there’s = talk of closing the working group soon.  The other reason I wrote it was to further illuminate the upsides and downside= s of some of the choices we made in JWS and JWE, given we have a chance to = reuse and/or revisit those choices should the COSE work go forward.

 

Replies to your specif= ic points follow inline…

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com= ]
Sent: Wednesday, March 11, 2015 8:57 PM
To: Mike Jones; jose@ietf.org Subject: RE: [jose] Key Managed JSON Web Signature (KMJWS) specifica= tion

 

> I cannot respond = for Richard, but personally I feel rather insulted by the current draft.&nb= sp; My first half a dozen responses were rather vulgar and pejorative to th= is draft and thus deleted.

> <= /span>

> This draft seems = to be, more or less, what Richard and I were proposing in Denver and were t= old was not possible due to backwards compatibility.  What has changed= that this is no longer true?

 

For what it’s wo= rth, I’ve occasionally been thinking about key management for MACs ev= er since you and Richard raised the possibility in Denver.  Somewhere = along the way I realized that there was a simple way to combine the JWE key management methods and the JWS MAC methods.  S= o I decided to write it down, while there was still a working group to cons= ider it, should the working group decide to do so.

 

If the reason you̵= 7;re insulted is that you feel that you should receive more credit for some= of the ideas, I’d be glad to point out in the Acknowledgements that = you and Richard suggested the possibility of key-managed MACs and/or make you co-editors if you agree with the approach and would l= ike to work more actively on it.  If the reason that you’re insu= lted is that you feel that we should have done this earlier, I think the ve= rdict is still out on whether we need to do this at all.  Looking at http://trac.tools.ietf.org/wg/jose/trac/ticket/2, Karen made a consensu= s call that “we should not add the= ability to have a randomly generated MAC key protected by a different key<= /span>” based on working group input.

 

I think the key questi= on for the working group relative to this draft is whether people now want = to see a standard way to do this or not.

 

As for the backwards c= ompatibility issues discussed in Denver, I know that several participants w= ere opposed to seeing the JWS format for non-key-managed MACs change. = I suspect that’s what you’re referring to.  The good news about the current draft is that it adds the ability to have = key-managed MACs without such a change.

 

Should we have thought= of this approach then?  Probably.  Did we?  At least I didn= ’t.  I thought of it recently, so I decided to write it down.

 

> Why is there need= to have a compact formation for this draft?  We were told in no uncer= tain terms that this was completely unnecessary in Denver and thus was out = of scope for the documents.

 

I can’t remember= the part of the discussion that you’re referring to in Denver and I = can’t find it in the published notes.  The only uses of “c= ompact” in the notes aren’t about this.

 

That said, there’= ;s a compact serialization for key managed MACs for the same reason that th= ere’s a compact serialization for the other JOSE objects – to p= rovide a compact, URL-safe representation for use cases that need it.  It also makes this draft more parallel to both JWS and= JWE than it would otherwise be.

 

> This document doe= s not seem to have read the security considerations section of the JWS draf= t specifically dealing with the existence of multiple sharers of the secret= key.

 

I’m not sure I&#= 8217;m following you here, because different recipients use different ephem= eral keys in this representation.  What’s the security considera= tion that you think wasn’t taken into account?

 

> This document has= messed up the current documentation in JWE about how to determine what typ= e of document is being presented.  This is completely unacceptable.

 

It’s backwards-c= ompatible in the sense that if an implementation supports JWSs and JWEs but= not KMJWSs (I’m still looking for a better name than KMJWS, BTW), th= e current rules all continue to do the right thing.  If an implementation supports all three, yes, a little bit of additional l= ogic would be needed, just like a little bit of additional code would be ne= eded, but no breaking changes result.  A KMJWS is neither a legal JWS = nor a legal JWE, so even if the existing discrimination rules were applied to a KMJWS and it was mis-categorized as= one or the other, upon parsing, it would still be rejected, since it would= be missing required properties.

 

> There are now mul= tiple representations of direct keying for mac.  This is a significant= problem as one does not know which of the version one is supposed to be us= ing.

 

Thanks for pointing th= is out.  We should probably just prohibit the use of “alg”= :”dir” in KMJWS so that there’s exactly one way of repres= enting non-key-managed MACS – the existing way.

 

> (The fact that I = am half, if not all the way drunk has make this message much easier to writ= e).

 

I’m glad you enj= oyed your evening. J

 

> Jim

 

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

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, March 03, 2015 2:42 AM
To: jose@ietf.org
Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification=

 

I took a little time today and wrote a short draft s= pecifying a JWS-like object that uses key management for the MAC key used t= o integrity protect the payload.  We had considered doing this in JOSE issue #2<= /a> but didn’t do so at the time because of lack of demand.  How= ever, I wanted to get this down now to demonstrate that it is easy to do an= d specify a way to do it, should demand develop in the future – possibly after the JOSE working group has been closed.  See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-= 00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signatur= e-00.html.

 

This spec reuses key management functionality alread= y present in the = JWE spec and MAC functionality already present in the J= WS spec.  The result is essentially a JWS with an Encrypted Key va= lue added, and a new “mac” Header Parameter value representing the MAC algorithm used.  (Like JWE, the key management algorithm is carri= ed in the “alg” Header Parameter value.)

 

I also wrote this now as possible input into our thi= nking on options for creating a CBOR JOSE mapping. = If there are CBOR use cases needing managed MAC keys, this could help us r= eason about ways to structure the solution.

 

Yes, the spec name and abbreviation are far from cat= chy.  Better naming ideas would be great.

 

Feedback welcomed.

 

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

 

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

 

--_000_BY2PR03MB4420B9763C5DB021DEE13DBF5060BY2PR03MB442namprd_-- From nobody Thu Mar 12 10:20:19 2015 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 107E11A8ABE for ; Thu, 12 Mar 2015 10:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC0LJK9Mq7rB for ; Thu, 12 Mar 2015 10:20:14 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B331A8ABF for ; Thu, 12 Mar 2015 10:20:10 -0700 (PDT) X-AuditID: 12074424-f79356d000004839-47-5501cac93c25 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2D.A4.18489.9CAC1055; Thu, 12 Mar 2015 13:20:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2CHK8Cw003151; Thu, 12 Mar 2015 13:20:08 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2CHK6kN009519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Mar 2015 13:20:07 -0400 Message-ID: <5501CAC2.9000401@mit.edu> Date: Thu, 12 Mar 2015 13:20:02 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Bradley , Brian Campbell References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> In-Reply-To: <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------020100050007060200030509" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqrHvyFGOowfXVUhar/99ktFizppvJ 4lRLH7PF6rt/2RxYPJ5tn8/ksWTJTyaPu0cvsnjcvr2RJYAlissmJTUnsyy1SN8ugSuj/+Mz toIDxxgrXj1UaWB8WNbFyMkhIWAisfbvE3YIW0ziwr31bF2MXBxCAouZJI7sescE4WxklFh8 +ggzhHObSWLZpTVMIC28AmoSm6ffA2tnEVCVeNZ9iRnEZgOyp69pAasRFYiS6PnTzQZRLyhx cuYTFhBbBCj+Z8tUsDizgIPErQWtYHOEBYwkVp15zQKxbCKTxO8zfawgCU4BO4kJv58xQjSE Sfy908Q2gVFgFpK5s5CkIGwziXmbHzJD2PISzVtnA9kcQLaaxLJWJWThBYxsqxhlU3KrdHMT M3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3MYJig91FZQdj8yGlQ4wCHIxKPLwPWBlDhVgTy4or cw8xSnIwKYnyNp0ECvEl5adUZiQWZ8QXleakFh9ilOBgVhLh/Q+S401JrKxKLcqHSUlzsCiJ 8276wRciJJCeWJKanZpakFoEk5Xh4FCS4PUBaRQsSk1PrUjLzClBSDNxcIIM5wEaznQKZHhx QWJucWY6RP4Uo6KUOG8kSLMASCKjNA+uF5a6XjGKA70izGsM0s4DTHtw3a+ABjMBDWax/h8C NLgkESEl1cA4yZK/7NDzvYWBheWXTpgLsXL3fr6+Y0HX9Bd7a6xtjh+y/s75V/fEzy0veUrK m+Z0/VDhmfqTc8ev1ZFz0nPTdjXaPn9uyZdvwFZxdAm/20wBFvbDMz5zaJ55vWvhlJ6g/ofW 2wxTi/5syntw38pNY69jBVdQ5sL6oJcffSIUeQLfW8b4vM1VYinOSDTUYi4qTgQA9HO2PDgD AAA= Archived-At: Cc: luigi.lo_iacono@fh-koeln.de, "jose@ietf.org" Subject: Re: [jose] Java-based JOSE implementation 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, 12 Mar 2015 17:20:18 -0000 This is a multi-part message in MIME format. --------------020100050007060200030509 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit My bad, I totally missed that. -- Justin On 3/12/2015 11:38 AM, John Bradley wrote: > Yes flattened is a special case of the JSON serialization that has > only one signature. > > I don't know that there is a huge benefit to it over the regular JSON > serialization that supports multiple signatures. > > Some people really wanted it at the time. > > Supporting the general JSON serialization would be a higher priority > for me. In most cases I have seen, as Justin points out people > wanting a single signature go with compact. > > John B. > > >> On Mar 12, 2015, at 11:49 AM, Brian Campbell >> > wrote: >> >> flattened is not the same as compact FWIW >> >> compact -> >> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.1 >> >> flattened -> >> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.2.2 >> >> On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer > > wrote: >> >> Just to add some perspective, if by “flattened” serialization, >> you mean the compact serializations of JWS >> (header.payload.signature) and JWE >> (header.stuff.stuff.stuff.stuff I forgot the order), then there >> are huge advantages to these, and they’re the only ones that I >> personally use. >> >> The simplicity gained in processing the compact forms, both in >> terms of generating and consuming. With the compact forms, you >> get something that can be dropped on the wire into an HTTP >> header, form parameter, query parameter, a string in just about >> any language, all without any quoting or further processing. >> Plus, to get back to the crypto calculations, you use the literal >> strings sent across the wire, which is a really nice feature. >> >> I’ve personally yet to have a use case that required the multiple >> signatures or other features of the JSON serialized flavor, nor >> have I seen much uptake of it in the wild compared to the compact >> forms. >> >> — Justin >> >> > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono >> > > wrote: >> > >> > Dear Vladimir, >> > >> > yes, we do support the flattened serialisation, but you are >> right, we >> > did not mention it in the "feature list". This is mainly >> because we do >> > not see any benefit in having this serialisation. We followed the >> > discussions on it and had own discussions internally. I do not >> see the >> > point to define a distinct serialisation which is very close to an >> > already existing one. This increases complexity only and that's >> it. The >> > marginal amount of data reduction coming with the flattened >> > serialisation is ridiculous in comparison to the JSON >> serialisation with >> > only one signature. I personally like the second approach more, >> since it >> > still give you the flexibility to add further signatures along >> the way. >> > Basically, this is the way our architecture supports multiple >> > signatures. They are added by the signing parties one after the >> other. >> > From our perspective, this is the only realistic use case here. >> Having a >> > signing process in possession of multiple distinct private key >> breaks >> > with a lot of security principles. At least in my understanding >> or do I >> > miss something here!? >> > >> > In our architectural approach a JwsDocument is constructed by a >> JwsMaker >> > (either from scratch or by parsing an existing one): >> > >> > JwsDocument jws = JwsMaker.generate... >> > >> > Having such an object, getting a particular serialisation is just a >> > matter of calling the respective method: >> > >> > - Compact: jws.getCompactSerialisation(); >> > - Compact DETACHED: jws.getCompactDetachedSerialisation(); >> > - JSON: jws.getJsonSerialisation(); >> > - JSON PRETTYPRINTED: jws.getJsonSerialisation(true); >> > - JSON DETACHED: jws.getJsonDetachedSerialisation(); >> > - JSON PRETTYPRINTED & DETACHED: >> jws.getJsonDetachedSerialisation(true); >> > - JSON Flattened: jws.getJsonFlattenedSerialisation(); >> > - JSON Flattened PRITTYPRINTED: >> jws.getJsonFlattenedSerialisation(true); >> > - JSON Flattened DETACHED: >> jws.getJsonFlattenedDetachedSerialisation(); >> > - JSON Flattened PRITTYPRINTED & DETACHED: >> > jws.getJsonFlattenedDetachedSerialisation(true) >> > >> > Hope that helps!? >> > >> > Do not hesitate to ask further questions. We are happy to help and >> > further feedback is welcome! >> > >> > BR, Luigi. >> > >> > >> > Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov: >> >> Thanks for sharing this. >> >> >> >> I see that you support JSON and compact serialisation, but what is >> >> flattened serialisation? >> >> >> >> Thanks, >> >> >> >> Vladimir >> >> >> >> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >> >>> Dear all, >> >>> >> >>> we developed an own JOSE implementation in Java, mainly >> because we >> >>> missed the JSON serialisation in almost all of the available >> libs. You >> >>> can grasp it here: >> >>> >> >>> http://jw-asterisk.realsoasecurity.de/ >> >>> >> >>> We are still doing some polishing, that is why the sources >> are still >> >>> lacking. Stay tuned, though, updates will follow soon... >> >>> >> >>> The documentation and especially the unit tests should help >> in taking >> >>> the first steps. >> >>> >> >>> Let us know what you think about it... >> >>> >> >>> BR, Luigi. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> jose mailing list >> >>> jose@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> -- >> >> Vladimir Dzhuvinov :: vladimir@connect2id.com >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> jose mailing list >> >> jose@ietf.org >> >> https://www.ietf.org/mailman/listinfo/jose >> >> >> > >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > --------------020100050007060200030509 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit My bad, I totally missed that.

 -- Justin

On 3/12/2015 11:38 AM, John Bradley wrote:
Yes flattened is a special case of the JSON serialization that has only one signature.

I don't know that there is a huge benefit to it over the regular JSON serialization that supports multiple signatures.

Some people really wanted it at the time.  

Supporting the general JSON serialization would be a higher priority for me.  In most cases I have seen, as Justin points out people wanting a single signature go with compact.

John B.


On Mar 12, 2015, at 11:49 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:


On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer <jricher@mit.edu> wrote:
Just to add some perspective, if by “flattened” serialization, you mean the compact serializations of JWS (header.payload.signature) and JWE (header.stuff.stuff.stuff.stuff I forgot the order), then there are huge advantages to these, and they’re the only ones that I personally use.

The simplicity gained in processing the compact forms, both in terms of generating and consuming. With the compact forms, you get something that can be dropped on the wire into an HTTP header, form parameter, query parameter, a string in just about any language, all without any quoting or further processing. Plus, to get back to the crypto calculations, you use the literal strings sent across the wire, which is a really nice feature.

I’ve personally yet to have a use case that required the multiple signatures or other features of the JSON serialized flavor, nor have I seen much uptake of it in the wild compared to the compact forms.

 — Justin

> On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono <luigi.lo_iacono@fh-koeln.de> wrote:
>
> Dear Vladimir,
>
> yes, we do support the flattened serialisation, but you are right, we
> did not mention it in the "feature list". This is mainly because we do
> not see any benefit in having this serialisation. We followed the
> discussions on it and had own discussions internally. I do not see the
> point to define a distinct serialisation which is very close to an
> already existing one. This increases complexity only and that's it. The
> marginal amount of data reduction coming with the flattened
> serialisation is ridiculous in comparison to the JSON serialisation with
> only one signature. I personally like the second approach more, since it
> still give you the flexibility to add further signatures along the way.
> Basically, this is the way our architecture supports multiple
> signatures. They are added by the signing parties one after the other.
> From our perspective, this is the only realistic use case here. Having a
> signing process in possession of multiple distinct private key breaks
> with a lot of security principles. At least in my understanding or do I
> miss something here!?
>
> In our architectural approach a JwsDocument is constructed by a JwsMaker
> (either from scratch or by parsing an existing one):
>
> JwsDocument jws = JwsMaker.generate...
>
> Having such an object, getting a particular serialisation is just a
> matter of calling the respective method:
>
> - Compact: jws.getCompactSerialisation();
> - Compact DETACHED: jws.getCompactDetachedSerialisation();
> - JSON: jws.getJsonSerialisation();
> - JSON PRETTYPRINTED: jws.getJsonSerialisation(true);
> - JSON DETACHED: jws.getJsonDetachedSerialisation();
> - JSON PRETTYPRINTED & DETACHED: jws.getJsonDetachedSerialisation(true);
> - JSON Flattened: jws.getJsonFlattenedSerialisation();
> - JSON Flattened PRITTYPRINTED: jws.getJsonFlattenedSerialisation(true);
> - JSON Flattened DETACHED: jws.getJsonFlattenedDetachedSerialisation();
> - JSON Flattened PRITTYPRINTED & DETACHED:
>  jws.getJsonFlattenedDetachedSerialisation(true)
>
> Hope that helps!?
>
> Do not hesitate to ask further questions. We are happy to help and
> further feedback is welcome!
>
> BR, Luigi.
>
>
> Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov:
>> Thanks for sharing this.
>>
>> I see that you support JSON and compact serialisation, but what is
>> flattened serialisation?
>>
>> Thanks,
>>
>> Vladimir
>>
>> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
>>> Dear all,
>>>
>>> we developed an own JOSE implementation in Java, mainly because we
>>> missed the JSON serialisation in almost all of the available libs. You
>>> can grasp it here:
>>>
>>> http://jw-asterisk.realsoasecurity.de/
>>>
>>> We are still doing some polishing, that is why the sources are still
>>> lacking. Stay tuned, though, updates will follow soon...
>>>
>>> The documentation and especially the unit tests should help in taking
>>> the first steps.
>>>
>>> Let us know what you think about it...
>>>
>>> BR, Luigi.
>>>
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> --
>> Vladimir Dzhuvinov :: vladimir@connect2id.com
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


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


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


--------------020100050007060200030509-- From nobody Thu Mar 12 22:52:45 2015 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 1FE041AC432 for ; Thu, 12 Mar 2015 22:52:44 -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 uGJsvVfVMxh6 for ; Thu, 12 Mar 2015 22:52:41 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB40F1AC428 for ; Thu, 12 Mar 2015 22:52:40 -0700 (PDT) Received: by wggx13 with SMTP id x13so20916597wgg.12 for ; Thu, 12 Mar 2015 22:52:39 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kbJ/Jp971g0uM6NF105v7EWO/0RrV+cy8n2NNdsbYyE=; b=TLcWXjb/26rcDWdJFraGR3jqIIn5HYntjCi4wSiA1lMcphNiJtkT6BnmjeSljiVJsX E/UE5Hhc6UykT0HvN6YDXLNjltMfAe+SVYpO1mr33WVPdnVThAkkIMutdfudvMw6aMVa e3VDCTCmMwKWtsudP/sWva/IK9NsVz0uX1ZXSGseuKYjzF3cibnCQaDtobJM7Qgrh3u6 IQjNnclU3n7cKnwmcHkZeCKXTtgGKYUTM3eE2dbLahlyNIc9YxJGt7sdbbgnN4dNLPuE /0NvWCvQhFK790GKO5M6yYru87IDU1kLGIXoHDV0LPnyLRG78iau3n2YzJM8oKI6NmGm htQw== X-Received: by 10.180.87.66 with SMTP id v2mr15976378wiz.51.1426225959484; Thu, 12 Mar 2015 22:52:39 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id pa4sm1332888wjb.11.2015.03.12.22.52.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 22:52:38 -0700 (PDT) Message-ID: <55027B14.4020702@gmail.com> Date: Fri, 13 Mar 2015 06:52:20 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Jones , Jim Schaad , "jose@ietf.org" References: <4E1F6AAD24975D4BA5B1680429673943A2E74771@TK5EX14MBXC292.redmond.corp.microsoft.com> <0f1e01d05c78$94573b00$bd05b100$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification 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, 13 Mar 2015 05:52:44 -0000 Hi Guys, Mainly for satisfying my curiosity: Would it be possible to get a minimal rationale/use-case for using encrypted MAC keys compared to traditional asymmetric signature schemes? Is this scheme already featured in another standard or widely deployed system? Cheers, Anders On 2015-03-12 16:55, Mike Jones wrote: > I’ll add one other thing, Jim. I’m sorry that you left the Denver meeting feeling like your idea for key management was dismissed. We should have pushed harder then to try to come up with an approach for that that would work for all. I’ll try to personally take this an object lesson for future standards work. > > See you in Dallas! > > -- Mike > > *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Thursday, March 12, 2015 12:37 AM > *To:* Jim Schaad; jose@ietf.org > *Subject:* Re: [jose] Key Managed JSON Web Signature (KMJWS) specification > > Hi Jim. Thanks for responding and for your honest feedback. While you may feel insulted (I’m genuinely sorry about that!), I’m to try to take the negatives you’ve expressed as positives, in the sense that they can constructively inform future work by the working group. > > One reason I wrote this draft was to get down a straightforward way of using key managed HMACs, should people want to do that in the future, especially since there’s talk of closing the working group soon. The other reason I wrote it was to further illuminate the upsides and downsides of some of the choices we made in JWS and JWE, given we have a chance to reuse and/or revisit those choices should the COSE work go forward. > > Replies to your specific points follow inline… > > *From:*Jim Schaad [mailto:ietf@augustcellars.com] > *Sent:* Wednesday, March 11, 2015 8:57 PM > *To:* Mike Jones; jose@ietf.org > *Subject:* RE: [jose] Key Managed JSON Web Signature (KMJWS) specification > >> I cannot respond for Richard, but personally I feel rather insulted by the current draft. My first half a dozen responses were rather vulgar and pejorative to this draft and thus deleted. > >> > >> This draft seems to be, more or less, what Richard and I were proposing in Denver and were told was not possible due to backwards compatibility. What has changed that this is no longer true? > > For what it’s worth, I’ve occasionally been thinking about key management for MACs ever since you and Richard raised the possibility in Denver. Somewhere along the way I realized that there was a simple way to combine the JWE key management methods and the JWS MAC methods. So I decided to write it down, while there was still a working group to consider it, should the working group decide to do so. > > If the reason you’re insulted is that you feel that you should receive more credit for some of the ideas, I’d be glad to point out in the Acknowledgements that you and Richard suggested the possibility of key-managed MACs and/or make you co-editors if you agree with the approach and would like to work more actively on it. If the reason that you’re insulted is that you feel that we should have done this earlier, I think the verdict is still out on whether we need to do this at all. Looking at http://trac.tools.ietf.org/wg/jose/trac/ticket/2, Karen made a consensus call that “we should not add the ability to have a randomly generated MAC key protected by a different key” based on working group input. > > I think the key question for the working group relative to this draft is whether people now want to see a standard way to do this or not. > > As for the backwards compatibility issues discussed in Denver, I know that several participants were opposed to seeing the JWS format for non-key-managed MACs change. I suspect that’s what you’re referring to. The good news about the current draft is that it adds the ability to have key-managed MACs without such a change. > > Should we have thought of this approach then? Probably. Did we? At least I didn’t. I thought of it recently, so I decided to write it down. > >> Why is there need to have a compact formation for this draft? We were told in no uncertain terms that this was completely unnecessary in Denver and thus was out of scope for the documents. > > I can’t remember the part of the discussion that you’re referring to in Denver and I can’t find it in the published notes. The only uses of “compact” in the notes aren’t about this. > > That said, there’s a compact serialization for key managed MACs for the same reason that there’s a compact serialization for the other JOSE objects – to provide a compact, URL-safe representation for use cases that need it. It also makes this draft more parallel to both JWS and JWE than it would otherwise be. > >> This document does not seem to have read the security considerations section of the JWS draft specifically dealing with the existence of multiple sharers of the secret key. > > I’m not sure I’m following you here, because different recipients use different ephemeral keys in this representation. What’s the security consideration that you think wasn’t taken into account? > >> This document has messed up the current documentation in JWE about how to determine what type of document is being presented. This is completely unacceptable. > > It’s backwards-compatible in the sense that if an implementation supports JWSs and JWEs but not KMJWSs (I’m still looking for a better name than KMJWS, BTW), the current rules all continue to do the right thing. If an implementation supports all three, yes, a little bit of additional logic would be needed, just like a little bit of additional code would be needed, but no breaking changes result. A KMJWS is neither a legal JWS nor a legal JWE, so even if the existing discrimination rules were applied to a KMJWS and it was mis-categorized as one or the other, upon parsing, it would still be rejected, since it would be missing required properties. > >> There are now multiple representations of direct keying for mac. This is a significant problem as one does not know which of the version one is supposed to be using. > > Thanks for pointing this out. We should probably just prohibit the use of “alg”:”dir” in KMJWS so that there’s exactly one way of representing non-key-managed MACS – the existing way. > >> (The fact that I am half, if not all the way drunk has make this message much easier to write). > > I’m glad you enjoyed your evening. J > >> Jim > > Thanks again, > > -- Mike > > *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Tuesday, March 03, 2015 2:42 AM > *To:* jose@ietf.org > *Subject:* [jose] Key Managed JSON Web Signature (KMJWS) specification > > I took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload. We had considered doing this in JOSE issue #2 but didn’t do so at the time because of lack of demand. However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future – possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html. > > This spec reuses key management functionality already present in the JWE spec and MAC functionality already present in the JWS spec . The result is essentially a JWS with an Encrypted Key value added, and a new “mac” Header Parameter value representing the MAC algorithm used. (Like JWE, the key management algorithm is carried in the “alg” Header Parameter value.) > > I also wrote this now as possible input into our thinking on options for creating a CBOR JOSE mapping. If there are CBOR use cases needing managed MAC keys, this could help us reason about ways to structure the solution. > > Yes, the spec name and abbreviation are far from catchy. Better naming ideas would be great. > > Feedback welcomed. > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=1344 and as @selfissued. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Fri Mar 13 01:04:14 2015 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 1ACF91A19FA for ; Fri, 13 Mar 2015 01:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuRmJ0u82OW8 for ; Fri, 13 Mar 2015 01:04:10 -0700 (PDT) Received: from lvs-smtpgate3.nz.fh-koeln.de (lvs-smtpgate3.nz.FH-Koeln.DE [139.6.1.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE5C1A1A02 for ; Fri, 13 Mar 2015 01:04:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,393,1422918000"; d="asc'?scan'208";a="19016442" Received: from nat079004.nat.fh-koeln.de (HELO mac-01.local) ([139.6.79.4]) by smtp.intranet.fh-koeln.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 13 Mar 2015 09:04:00 +0100 Message-ID: <55029B7E.1070903@fh-koeln.de> Date: Fri, 13 Mar 2015 09:10:38 +0100 From: "Prof. Dr.-Ing. Luigi Lo Iacono" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Richer , John Bradley , Brian Campbell References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> In-Reply-To: <5501CAC2.9000401@mit.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gFU9awBW4EKqPVja0jqxxl2FbhHXomxtu" Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] Java-based JOSE implementation X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: luigi.lo_iacono@fh-koeln.de List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 08:04:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gFU9awBW4EKqPVja0jqxxl2FbhHXomxtu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Seems that there is some uncertainty about this "special" serialisation. I would actually vote for replacing the flatened JSON serialisation with one, that provides a real benefit. Taken up on a discussion I read earlier on the list, wouldn't it be more sensible to have a "readable" JSON serialisation (i.e., leaving the signed payload "human readbale")!? This would of course require some form of normalisation/canonicalisaton as used e.g. in XML Security. Still, this would be something valuable to have and a real distinguishing point in comparison to the other serialisations. If people think that this is worth a discussion, then maybe we should kick-off an explicit thread on it. Another point I would like to raise is to have an additional mandatory header entry specifying the JWS/JWE version used. As the standards will evolve over time, it would be good to know, with what version of the JWS/JWE standards a given object have been protected. BR, Luigi. Am 12.03.15 um 18:20 schrieb Justin Richer: > My bad, I totally missed that. >=20 > -- Justin >=20 > On 3/12/2015 11:38 AM, John Bradley wrote: >> Yes flattened is a special case of the JSON serialization that has >> only one signature. >> >> I don't know that there is a huge benefit to it over the regular JSON >> serialization that supports multiple signatures. >> >> Some people really wanted it at the time. =20 >> >> Supporting the general JSON serialization would be a higher priority >> for me. In most cases I have seen, as Justin points out people >> wanting a single signature go with compact. >> >> John B. >> >> >>> On Mar 12, 2015, at 11:49 AM, Brian Campbell >>> > wrot= e: >>> >>> flattened is not the same as compact FWIW >>> >>> compact -> >>> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#sec= tion-7.1 >>> >>> flattened -> >>> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#sec= tion-7.2.2 >>> >>> On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer >> > wrote: >>> >>> Just to add some perspective, if by =E2=80=9Cflattened=E2=80=9D s= erialization, >>> you mean the compact serializations of JWS >>> (header.payload.signature) and JWE >>> (header.stuff.stuff.stuff.stuff I forgot the order), then there >>> are huge advantages to these, and they=E2=80=99re the only ones t= hat I >>> personally use. >>> >>> The simplicity gained in processing the compact forms, both in >>> terms of generating and consuming. With the compact forms, you >>> get something that can be dropped on the wire into an HTTP >>> header, form parameter, query parameter, a string in just about >>> any language, all without any quoting or further processing. >>> Plus, to get back to the crypto calculations, you use the literal= >>> strings sent across the wire, which is a really nice feature. >>> >>> I=E2=80=99ve personally yet to have a use case that required the = multiple >>> signatures or other features of the JSON serialized flavor, nor >>> have I seen much uptake of it in the wild compared to the compact= >>> forms. >>> >>> =E2=80=94 Justin >>> >>> > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono >>> >> > wrote: >>> > >>> > Dear Vladimir, >>> > >>> > yes, we do support the flattened serialisation, but you are >>> right, we >>> > did not mention it in the "feature list". This is mainly >>> because we do >>> > not see any benefit in having this serialisation. We followed t= he >>> > discussions on it and had own discussions internally. I do not >>> see the >>> > point to define a distinct serialisation which is very close to= an >>> > already existing one. This increases complexity only and that's= >>> it. The >>> > marginal amount of data reduction coming with the flattened >>> > serialisation is ridiculous in comparison to the JSON >>> serialisation with >>> > only one signature. I personally like the second approach more,= >>> since it >>> > still give you the flexibility to add further signatures along >>> the way. >>> > Basically, this is the way our architecture supports multiple >>> > signatures. They are added by the signing parties one after the= >>> other. >>> > From our perspective, this is the only realistic use case here.= >>> Having a >>> > signing process in possession of multiple distinct private key >>> breaks >>> > with a lot of security principles. At least in my understanding= >>> or do I >>> > miss something here!? >>> > >>> > In our architectural approach a JwsDocument is constructed by a= >>> JwsMaker >>> > (either from scratch or by parsing an existing one): >>> > >>> > JwsDocument jws =3D JwsMaker.generate... >>> > >>> > Having such an object, getting a particular serialisation is ju= st a >>> > matter of calling the respective method: >>> > >>> > - Compact: jws.getCompactSerialisation(); >>> > - Compact DETACHED: jws.getCompactDetachedSerialisation(); >>> > - JSON: jws.getJsonSerialisation(); >>> > - JSON PRETTYPRINTED: jws.getJsonSerialisation(true); >>> > - JSON DETACHED: jws.getJsonDetachedSerialisation(); >>> > - JSON PRETTYPRINTED & DETACHED: >>> jws.getJsonDetachedSerialisation(true); >>> > - JSON Flattened: jws.getJsonFlattenedSerialisation(); >>> > - JSON Flattened PRITTYPRINTED: >>> jws.getJsonFlattenedSerialisation(true); >>> > - JSON Flattened DETACHED: >>> jws.getJsonFlattenedDetachedSerialisation(); >>> > - JSON Flattened PRITTYPRINTED & DETACHED: >>> > jws.getJsonFlattenedDetachedSerialisation(true) >>> > >>> > Hope that helps!? >>> > >>> > Do not hesitate to ask further questions. We are happy to help = and >>> > further feedback is welcome! >>> > >>> > BR, Luigi. >>> > >>> > >>> > Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov: >>> >> Thanks for sharing this. >>> >> >>> >> I see that you support JSON and compact serialisation, but wha= t is >>> >> flattened serialisation? >>> >> >>> >> Thanks, >>> >> >>> >> Vladimir >>> >> >>> >> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>> >>> Dear all, >>> >>> >>> >>> we developed an own JOSE implementation in Java, mainly >>> because we >>> >>> missed the JSON serialisation in almost all of the available >>> libs. You >>> >>> can grasp it here: >>> >>> >>> >>> http://jw-asterisk.realsoasecurity.de/ >>> >>> >>> >>> We are still doing some polishing, that is why the sources >>> are still >>> >>> lacking. Stay tuned, though, updates will follow soon... >>> >>> >>> >>> The documentation and especially the unit tests should help >>> in taking >>> >>> the first steps. >>> >>> >>> >>> Let us know what you think about it... >>> >>> >>> >>> BR, Luigi. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> jose mailing list >>> >>> jose@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/jose >>> >> >>> >> -- >>> >> Vladimir Dzhuvinov :: vladimir@connect2id.com >>> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> jose mailing list >>> >> jose@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/jose >>> >> >>> > >>> > _______________________________________________ >>> > jose mailing list >>> > jose@ietf.org >>> > https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> >=20 --gFU9awBW4EKqPVja0jqxxl2FbhHXomxtu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVApuEAAoJEFL6uArWI9sNGqsQAN5log/3qCZEdhPLQfltPa1i s1cBNDFOh7Sa//+pfBkYdCsRnWH/NQOPMoeqb1Qoj4TqOWQkEbFzVRD3ySt7DbwK 8wzZrkqS5I3xpF24lBk++NjyD05G4IJYWPTqBhg8FLxYmSzzftlnMT7xsdPHeqYP E6GO1rMPIwPTnbmG8yeIW8XxJqrMEg1NhSXxo5qe2XspzevgpFSvMWbN1ZKIbZWB areED95BU/P55f/khAVr/+4sVLoHYMa9vvVYErnQDGWZe6nsL1GS0srslUNe2+zM Z7tfdrlvpfQrO9visTiARFHuHXweY9Gh5bFZrRz0/MS2A7que7bSm9uI+07grzEC ke35DILc+GbxangoDxe7H/0NEJ0FzU/rVpVgoEc0f2J9VlcEIA7J62Kz0R80l4vz bZnSTKB2JGrRcqt+0ziMaSdach8TCyx9IUJsZ1kGzLYwxc4hYdLGS2XFcqIermtP xuEFOrqorUO3JFoVDygBmhPDSUaiBzMQ44/OqIAdux5HE2xzi+M1XEXmWJdX4cHG IxmSoCJmBsGJfldlDfUbvu7AQyYABUqVejKbjsH3Zkwz+FqfOxf7VZwj/TnZLS27 SBwWLWywKZZQXkNzr+tXm4z0FR/CCdGqi4KLk+d+nazUQH0oB007AaVFeTfP4myg vnWMhEYLpZTHDeKRkqHM =ffkD -----END PGP SIGNATURE----- --gFU9awBW4EKqPVja0jqxxl2FbhHXomxtu-- From nobody Fri Mar 13 02:02:22 2015 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 CCB0A1A1B67 for ; Fri, 13 Mar 2015 02:02:19 -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 NLEiGuKjwkjf for ; Fri, 13 Mar 2015 02:02:18 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186351A1B17 for ; Fri, 13 Mar 2015 02:02:06 -0700 (PDT) Received: by wggx13 with SMTP id x13so21792842wgg.4 for ; Fri, 13 Mar 2015 02:02:04 -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=hDxCjV/SJeMfJORLgSA256y3AtT7tEculW8jzB1INRc=; b=PDi4sxCFFgHL9qsHwpUOLGyVvdziKndku5dZzKM1WtIqC6jCjzoQLQNEt7VyIkvojk N9cUtPJGcZv/APtV+oJhJkRWlFjJuCAG5w2Fqd6CayzVMeRnud9oG+6eqYI5M5NX/c+a SGs97BIBbJtZ+ODoQDlSVhq73puyZkf9sQL+jxyaGHTtyUuBUTIWAW53O8sgnTYE78TQ amp1cg10hEXWAP5PQzjigIuDi7ayDEnG+zhlFii4XwOJqKqIplrFo8uCgMw5tr9HCCEU tTWYgsisT74V5eQTAzX2IPXpeNkRgsSze33JNgcvRLEhcfDVvD7DYJzNXImJu+7A1DFv 5CHQ== X-Received: by 10.194.174.106 with SMTP id br10mr42983211wjc.21.1426237324838; Fri, 13 Mar 2015 02:02:04 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id ge8sm1887895wjc.32.2015.03.13.02.02.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 02:02:04 -0700 (PDT) Message-ID: <5502A778.8090709@gmail.com> Date: Fri, 13 Mar 2015 10:01:44 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: luigi.lo_iacono@fh-koeln.de, Justin Richer , John Bradley , Brian Campbell References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> In-Reply-To: <55029B7E.1070903@fh-koeln.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] Java-based JOSE implementation 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, 13 Mar 2015 09:02:20 -0000 On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: > Seems that there is some uncertainty about this "special" serialisation. > I would actually vote for replacing the flatened JSON serialisation with > one, that provides a real benefit. Taken up on a discussion I read > earlier on the list, wouldn't it be more sensible to have a "readable" > JSON serialisation (i.e., leaving the signed payload "human readbale")!? > This would of course require some form of normalisation/canonicalisaton > as used e.g. in XML Security. Still, this would be something valuable to > have and a real distinguishing point in comparison to the other > serialisations. > > If people think that this is worth a discussion, then maybe we should > kick-off an explicit thread on it. Human-readable JSON signatures is a reality although not as an IETF standard. Since nobody is interested in bringing in the complexity of XML DSig normalization, there seems to be some possible routes ahead. Phillip Hallam-Baker have proposed a scheme based on separating the payload and the signature where the payload is used "verbatim" reducing normalization and canonicalization to exactly ZERO: http://www.ietf.org/mail-archive/web/acme/current/msg00224.html I have FWIW designed and also implemented a scheme which is based on JSON's intrinsic normalization (white-space removal + character escapes) but adds the constraint that a verifier honors the property order of the serialized object: https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html Since a JSON parser-core typically is less than 500 lines of fairly simple code I don't see that upgrading existing parsers with an ordered dictionary would be a show-stopper. It surely didn't stop me at least :-) Runnable Java+JavaScript implementation: https://mobilepki.org/jcs Partial Python implementation: https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py Minimal .NET implementation: https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs Cheers, Anders From nobody Fri Mar 13 13:09:38 2015 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 D76421A1BAE for ; Fri, 13 Mar 2015 13:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv_VkXzydVJt for ; Fri, 13 Mar 2015 13:09:35 -0700 (PDT) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) by ietfa.amsl.com (Postfix) with ESMTP id D231C1A1B34 for ; Fri, 13 Mar 2015 13:09:27 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.115]) by p3plsmtpa07-07.prod.phx3.secureserver.net with id 389S1q0042Vi9sD0189Sz9; Fri, 13 Mar 2015 13:09:27 -0700 Message-ID: <550343F5.1010709@connect2id.com> Date: Fri, 13 Mar 2015 22:09:25 +0200 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: jose@ietf.org References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> <5502A778.8090709@gmail.com> In-Reply-To: <5502A778.8090709@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [jose] Java-based JOSE implementation 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, 13 Mar 2015 20:09:37 -0000 > > Phillip Hallam-Baker have proposed a scheme based on separating the > payload and > the signature where the payload is used "verbatim" reducing > normalization and > canonicalization to exactly ZERO: > http://www.ietf.org/mail-archive/web/acme/current/msg00224.html > Sounds appealing :) --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com From nobody Fri Mar 13 13:33:35 2015 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 089E11A6F01 for ; Fri, 13 Mar 2015 13:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylqn5jELVfU5 for ; Fri, 13 Mar 2015 13:33:31 -0700 (PDT) Received: from lvs-smtpgate3.nz.fh-koeln.de (lvs-smtpgate3.nz.FH-Koeln.DE [139.6.1.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5AA1A6F04 for ; Fri, 13 Mar 2015 13:33:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,396,1422918000"; d="asc'?scan'208";a="19033880" Received: from aftr-37-201-195-189.unity-media.net (HELO mac-01.local) ([37.201.195.189]) by smtp.intranet.fh-koeln.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 13 Mar 2015 21:33:30 +0100 Message-ID: <55034AAD.4000408@fh-koeln.de> Date: Fri, 13 Mar 2015 21:38:05 +0100 From: "Prof. Dr.-Ing. Luigi Lo Iacono" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Anders Rundgren , Justin Richer , John Bradley , Brian Campbell References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> <5502A778.8090709@gmail.com> In-Reply-To: <5502A778.8090709@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jPgvlNLjordnXRFdP5QCqXa9qr6iOAQuN" Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] Java-based JOSE implementation X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: luigi.lo_iacono@fh-koeln.de List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:33:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jPgvlNLjordnXRFdP5QCqXa9qr6iOAQuN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks a lot for the pointer, Anders. Will check them soon! Cheers, Luigi. Am 13.03.15 um 10:01 schrieb Anders Rundgren: > On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >> Seems that there is some uncertainty about this "special" serialisatio= n. >> I would actually vote for replacing the flatened JSON serialisation wi= th >> one, that provides a real benefit. Taken up on a discussion I read >> earlier on the list, wouldn't it be more sensible to have a "readable"= >> JSON serialisation (i.e., leaving the signed payload "human readbale")= !? >> This would of course require some form of normalisation/canonicalisato= n >> as used e.g. in XML Security. Still, this would be something valuable = to >> have and a real distinguishing point in comparison to the other >> serialisations. >> >> If people think that this is worth a discussion, then maybe we should >> kick-off an explicit thread on it. >=20 > Human-readable JSON signatures is a reality although not as an IETF > standard. >=20 > Since nobody is interested in bringing in the complexity of XML DSig > normalization, > there seems to be some possible routes ahead. >=20 > Phillip Hallam-Baker have proposed a scheme based on separating the > payload and > the signature where the payload is used "verbatim" reducing > normalization and > canonicalization to exactly ZERO: > http://www.ietf.org/mail-archive/web/acme/current/msg00224.html >=20 > I have FWIW designed and also implemented a scheme which is based on JS= ON's > intrinsic normalization (white-space removal + character escapes) but > adds the > constraint that a verifier honors the property order of the serialized > object: > https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html > Since a JSON parser-core typically is less than 500 lines of fairly > simple code > I don't see that upgrading existing parsers with an ordered dictionary > would be > a show-stopper. It surely didn't stop me at least :-) > Runnable Java+JavaScript implementation: https://mobilepki.org/jcs > Partial Python implementation: > https://code.google.com/p/openkeystore/source/browse/python/trunk/src/o= rg/webpki/json/JCSValidator.py >=20 > Minimal .NET implementation: > https://code.google.com/p/openkeystore/source/browse/resources/trunk/do= cs/JCSDemo.cs >=20 >=20 > Cheers, > Anders >=20 --jPgvlNLjordnXRFdP5QCqXa9qr6iOAQuN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVA0qtAAoJEFL6uArWI9sNVM0P/iMgJQuOHff13jaZK0KP2UiU KphxhWhd163jvGxobdSxNLDKb/5CZCiuwuD5S3abneJrOKejANSv5SwPf3LizY6M EQs6cTtMJOMxNR/oF9joCVYcHxfeoO9BQPB8+5Hg+9r8P8jeoJUPPQ0IbLM2ORJ2 21p/0Qqti47sAMVC97iRTL+2rMyyYQVg+v2etGqj1lmH2Xhg8Cxiwr+Pwxr8kVht MKVA9/NBa2UhKzo5wbNXpi4DXmquthvVVrQArfQVFHnF/Pq6UsfbsRvv5S9jkvl8 F8yMqsx+CyKYCP4Xvj6VGXiQsUXKCp5iK+GalSo3727iX9NwyWqCdWOR+kL79J4P IyAedF5SneTcKq+dTBwR/8X/vI6EiTL9JCFlhKkRVMEZCZlegrp+C4gtiFBprgMM 8D+Antalep9iwKN1HEv9sSsNyzzJMJC+qG0uabeviTCsCCxEtAuPyTXgdtfAocVJ bG9RDK23/nX68DmXzBXLkNkbvC0rjzlbji3V9HQ2hgxxQwzyo0KIva0G1o3u/4dj 2x+rBf88wrHkkHtqqlJkI5AZBoxsL7z5xE+5J8dXYWNvHUFSDNyOH3FmLi5vZmAE MUkmQLoS5cNbtPFEW5ixiPAb0tqB0zCNCLePDER8bwUbVSQTAVCq3uUY8eqzU3Lo 2u4L0bLR9BeWuuXmHS62 =R8hk -----END PGP SIGNATURE----- --jPgvlNLjordnXRFdP5QCqXa9qr6iOAQuN-- From nobody Wed Mar 18 01:57:20 2015 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 8F6141A00F3 for ; Wed, 18 Mar 2015 01:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkLtuPm0ujMb for ; Wed, 18 Mar 2015 01:57:17 -0700 (PDT) Received: from lvs-smtpgate4.nz.fh-koeln.de (lvs-smtpgate4.nz.FH-Koeln.DE [139.6.1.50]) by ietfa.amsl.com (Postfix) with ESMTP id EF5331A011D for ; Wed, 18 Mar 2015 01:57:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,421,1422918000"; d="asc'?scan'208";a="19142685" Received: from nat079004.nat.fh-koeln.de (HELO mac-01.local) ([139.6.79.4]) by smtp.intranet.fh-koeln.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 18 Mar 2015 09:57:15 +0100 Message-ID: <55093F90.406@fh-koeln.de> Date: Wed, 18 Mar 2015 10:04:16 +0100 From: "Prof. Dr.-Ing. Luigi Lo Iacono" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Anders Rundgren , Justin Richer , John Bradley , Brian Campbell References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> <5502A778.8090709@gmail.com> In-Reply-To: <5502A778.8090709@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VsGumkueipmxMqen084woR1FLKOM66p2l" Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] Java-based JOSE implementation X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: luigi.lo_iacono@fh-koeln.de List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 08:57:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VsGumkueipmxMqen084woR1FLKOM66p2l Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Anders, thanks again for the pointers. Interesting reading. I like your approach a lot. While crawling though the web I stumbled upon this fall asleep dra= ft: https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 Have you been aware of this one!? Anyway, I still think that JOSE requires a readable JSON serialisation. I am not really familiar with the IETF procedures and seing that no one else reacted on the suggestion so far, I guess that raising such thoughts in the mailing list is not enough. What needs to be done in order to have a discussion on replacing the flatened JSON serialisation by a readbale JSON serialisation? Thanks and BR, Luigi. Am 13.03.15 um 10:01 schrieb Anders Rundgren: > On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >> Seems that there is some uncertainty about this "special" serialisatio= n. >> I would actually vote for replacing the flatened JSON serialisation wi= th >> one, that provides a real benefit. Taken up on a discussion I read >> earlier on the list, wouldn't it be more sensible to have a "readable"= >> JSON serialisation (i.e., leaving the signed payload "human readbale")= !? >> This would of course require some form of normalisation/canonicalisato= n >> as used e.g. in XML Security. Still, this would be something valuable = to >> have and a real distinguishing point in comparison to the other >> serialisations. >> >> If people think that this is worth a discussion, then maybe we should >> kick-off an explicit thread on it. >=20 > Human-readable JSON signatures is a reality although not as an IETF > standard. >=20 > Since nobody is interested in bringing in the complexity of XML DSig > normalization, > there seems to be some possible routes ahead. >=20 > Phillip Hallam-Baker have proposed a scheme based on separating the > payload and > the signature where the payload is used "verbatim" reducing > normalization and > canonicalization to exactly ZERO: > http://www.ietf.org/mail-archive/web/acme/current/msg00224.html >=20 > I have FWIW designed and also implemented a scheme which is based on JS= ON's > intrinsic normalization (white-space removal + character escapes) but > adds the > constraint that a verifier honors the property order of the serialized > object: > https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html > Since a JSON parser-core typically is less than 500 lines of fairly > simple code > I don't see that upgrading existing parsers with an ordered dictionary > would be > a show-stopper. It surely didn't stop me at least :-) > Runnable Java+JavaScript implementation: https://mobilepki.org/jcs > Partial Python implementation: > https://code.google.com/p/openkeystore/source/browse/python/trunk/src/o= rg/webpki/json/JCSValidator.py >=20 > Minimal .NET implementation: > https://code.google.com/p/openkeystore/source/browse/resources/trunk/do= cs/JCSDemo.cs >=20 >=20 > Cheers, > Anders >=20 --VsGumkueipmxMqen084woR1FLKOM66p2l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVCT+RAAoJEFL6uArWI9sNdT4P/2G5J1y8rCLtdpqhm8JYWrG4 oaxq3S02nMW6ZZDe/lV8RQJO+3oOjL1vPMHMokpgnTSlWHE0QTL7cx/Ya7v3gaP0 dj0UM4X7o9jcu2xzz1pYduuPokb9dgfdeIPKYKd0a1YVHrps2q5LHmNLSMfoclog WXxU1eFeXngVrAyQWtDjNsk2MrnkqRGA4m1EjvXC6gHVuZszD6+AgMcc2t1pqW3c qoCfwtNs68ffWW8roHwMs5Q9f6DUdS7XAJQqMXIvuL8eGg1nw01dlrEYalael9wP yvM2rWhSgUReDh7hAwStwH7NcjlZxBknOw4WVjoiOIEQJoANmkvNMDSB+QhG1ff8 dvXKz//4iu8PU3/GO0C3UYYT2SbyasoCDNB7/ydJUZLI9HsIpuyW516xsUG3KAkn SMjvBNEal3qXao/Jadyd7kOQ6lIdxk4R+OLla06eBg9IgqERHLHT3JBFcVL942oJ c8Vi2PUSosPm2/IvlNkTHJvDmS6lL7qOcrRO1gEmMh4vEgihgoHOrVpybRtm4npk /RiD7nsJ0+jBk3DJl5FFzWzjFFQ2dnSSmcsB7e86P3xjEC+zdpVpjo0VNCqiT1RF 84Ja28AgXcGMO5BV6//Wu8hZ6HU1ayE3dNRz2dJjNTQUy2tsbugAKrIGsNb+8fOp qWSUqETq5BzJ0BaHC3hw =szYK -----END PGP SIGNATURE----- --VsGumkueipmxMqen084woR1FLKOM66p2l-- From nobody Wed Mar 18 12:14:16 2015 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 75AFC1A887E for ; Wed, 18 Mar 2015 12:14:14 -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 pqZ6DOdyvtlc for ; Wed, 18 Mar 2015 12:14:12 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABC71A887D for ; Wed, 18 Mar 2015 12:14:12 -0700 (PDT) Received: by wixw10 with SMTP id w10so48594506wix.0 for ; Wed, 18 Mar 2015 12:14:11 -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=sR+rQwOSzrq5HmOsMbuAY/U8jRj1Ysq6tLZq6u+Z/SI=; b=B8DHmDJzCu+rgB1QCR5nbcffIpfXzYnMjMckEgqdjBwwxCf0Tq5ZNrDz4g6Rzs5jfk uCCASxs53XN+Bumqg73vNg3ssbI+Cl2sLW9wCw7y1iK4ytB1F8/xjZyLpyD2x5t8KHE1 QHTHG8s0+awt78SxRUVrRl7ZOmP0mor72O8uuBlnp76kUCDpOIIpX/czH/XITGggsoYz LYreBbqixZ06AuAMqzuXevcYmFxOHJICyj/W1pvMXJ4RpCt2SOHdE4pA5BBtkfL24WLi eTiCKf1+fFbI1BzvmUM1Dui+Hk9K/D09vvBlMc4wJvKXCU1r3+uaPOocGo49+tBpgh6P Q5bw== X-Received: by 10.180.89.34 with SMTP id bl2mr9698507wib.23.1426706050998; Wed, 18 Mar 2015 12:14:10 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id j7sm4427006wix.4.2015.03.18.12.14.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 12:14:10 -0700 (PDT) Message-ID: <5509CE69.5080204@gmail.com> Date: Wed, 18 Mar 2015 20:13:45 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: luigi.lo_iacono@fh-koeln.de, Justin Richer , John Bradley , Brian Campbell References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> <5502A778.8090709@gmail.com> <55093F90.406@fh-koeln.de> In-Reply-To: <55093F90.406@fh-koeln.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] Java-based JOSE implementation 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, 18 Mar 2015 19:14:14 -0000 On 2015-03-18 10:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: > Anders, Hi Luigi, > thanks again for the pointers. Interesting reading. I like your approach > a lot. Thanx! > While crawling though the web I stumbled upon this fall asleep draft: > > https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 > > Have you been aware of this one!? Yes, I think so. As you can see "there are many roads to Rome" :-) One school says: "You must canonicalize data in a similar way as for XML", while another school claim that "Canonicalization is lunacy!". Full canonicalization like in the I-D above forces you to use a stand-alone canonicalizer which is like building a parallel single-purpose JSON parser. Using text "as is" makes canonicalization a zero issue but I felt that it would be cooler using a standard (or moderately updated) JSON parser for creating and validating signatures. This design also enables security properties like keys to be handled exactly as any other properties. When I found (on stackoverflow) that many developers also feel that parsers that read properties A, B, C but outputs them as A, C, B as inferior, the decision to maintain strict property input/creation order became obvious. I'm currently not considering an IETF process, it seems like a better idea establishing this scheme through open source and actual usage :-) JCS was designed for supporting complex signature systems like: https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserSignedAuthorization Regards, Anders > > Anyway, I still think that JOSE requires a readable JSON serialisation. > I am not really familiar with the IETF procedures and seing that no one > else reacted on the suggestion so far, I guess that raising such > thoughts in the mailing list is not enough. What needs to be done in > order to have a discussion on replacing the flatened JSON serialisation > by a readbale JSON serialisation? > > Thanks and BR, Luigi. > > > Am 13.03.15 um 10:01 schrieb Anders Rundgren: >> On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>> Seems that there is some uncertainty about this "special" serialisation. >>> I would actually vote for replacing the flatened JSON serialisation with >>> one, that provides a real benefit. Taken up on a discussion I read >>> earlier on the list, wouldn't it be more sensible to have a "readable" >>> JSON serialisation (i.e., leaving the signed payload "human readbale")!? >>> This would of course require some form of normalisation/canonicalisaton >>> as used e.g. in XML Security. Still, this would be something valuable to >>> have and a real distinguishing point in comparison to the other >>> serialisations. >>> >>> If people think that this is worth a discussion, then maybe we should >>> kick-off an explicit thread on it. >> >> Human-readable JSON signatures is a reality although not as an IETF >> standard. >> >> Since nobody is interested in bringing in the complexity of XML DSig >> normalization, >> there seems to be some possible routes ahead. >> >> Phillip Hallam-Baker have proposed a scheme based on separating the >> payload and >> the signature where the payload is used "verbatim" reducing >> normalization and >> canonicalization to exactly ZERO: >> http://www.ietf.org/mail-archive/web/acme/current/msg00224.html >> >> I have FWIW designed and also implemented a scheme which is based on JSON's >> intrinsic normalization (white-space removal + character escapes) but >> adds the >> constraint that a verifier honors the property order of the serialized >> object: >> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html >> Since a JSON parser-core typically is less than 500 lines of fairly >> simple code >> I don't see that upgrading existing parsers with an ordered dictionary >> would be >> a show-stopper. It surely didn't stop me at least :-) >> Runnable Java+JavaScript implementation: https://mobilepki.org/jcs >> Partial Python implementation: >> https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py >> >> Minimal .NET implementation: >> https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs >> >> >> Cheers, >> Anders >> > From nobody Wed Mar 18 12:52:39 2015 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 8464C1A8891 for ; Wed, 18 Mar 2015 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8jalSWzzDz6 for ; Wed, 18 Mar 2015 12:52:35 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D091A8884 for ; Wed, 18 Mar 2015 12:52:35 -0700 (PDT) Received: from Philemon (75-150-47-141-Oregon.hfc.comcastbusiness.net [75.150.47.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 641B52C9BB; Wed, 18 Mar 2015 12:52:34 -0700 (PDT) From: "Jim Schaad" To: "'Anders Rundgren'" , References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> <5502A778.8090709@gmail.com> <55093F90.406@fh-koeln.de> <5509CE69.5080204@gmail.com> In-Reply-To: <5509CE69.5080204@gmail.com> Date: Wed, 18 Mar 2015 12:51:32 -0700 Message-ID: <05d101d061b4$ef63b140$ce2b13c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8ZXUu+YdcphCBR36uGFS1We8LRgIevucCA0QNsN4Cyc5/cgF6V6AFAvYIXqUBZTFrVAIVuVyMAgfVsm4AogZgEwHJvb32m6ZCPCA= Content-Language: en-us Archived-At: Cc: jose@ietf.org Subject: Re: [jose] Java-based JOSE implementation 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, 18 Mar 2015 19:52:37 -0000 What do you consider to be clear text signatures? Would you consider carrying a payload that is a JSON string which is not base64-ed to be plain text? I.e. {"signature":"abc...def", "payload":"{'tag1':'value1','tag2':'value2'}", "headers":"...."} The item to be signed is not at the top level, but it is readable by humans. Jim > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren > Sent: Wednesday, March 18, 2015 12:14 PM > To: luigi.lo_iacono@fh-koeln.de; Justin Richer; John Bradley; Brian Campbell > Cc: jose@ietf.org > Subject: Re: [jose] Java-based JOSE implementation > > On 2015-03-18 10:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: > > Anders, > > Hi Luigi, > > > thanks again for the pointers. Interesting reading. I like your > > approach a lot. > > Thanx! > > > While crawling though the web I stumbled upon this fall asleep draft: > > > > https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 > > > > Have you been aware of this one!? > > Yes, I think so. As you can see "there are many roads to Rome" :-) > > One school says: "You must canonicalize data in a similar way as for XML", > while another school claim that "Canonicalization is lunacy!". > > Full canonicalization like in the I-D above forces you to use a stand-alone > canonicalizer which is like building a parallel single-purpose JSON parser. > > Using text "as is" makes canonicalization a zero issue but I felt that it would be > cooler using a standard (or moderately updated) JSON parser for creating and > validating signatures. This design also enables security properties like keys to > be handled exactly as any other properties. > > When I found (on stackoverflow) that many developers also feel that parsers > that read properties A, B, C but outputs them as A, C, B as inferior, the decision > to maintain strict property input/creation order became obvious. > > I'm currently not considering an IETF process, it seems like a better idea > establishing this scheme through open source and actual usage :-) > > JCS was designed for supporting complex signature systems like: > https://openkeystore.googlecode.com/svn/wcpp-payment- > demo/trunk/docs/messages.html#UserSignedAuthorization > > Regards, > Anders > > > > > Anyway, I still think that JOSE requires a readable JSON serialisation. > > I am not really familiar with the IETF procedures and seing that no > > one else reacted on the suggestion so far, I guess that raising such > > thoughts in the mailing list is not enough. What needs to be done in > > order to have a discussion on replacing the flatened JSON > > serialisation by a readbale JSON serialisation? > > > > Thanks and BR, Luigi. > > > > > > Am 13.03.15 um 10:01 schrieb Anders Rundgren: > >> On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: > >>> Seems that there is some uncertainty about this "special" serialisation. > >>> I would actually vote for replacing the flatened JSON serialisation > >>> with one, that provides a real benefit. Taken up on a discussion I > >>> read earlier on the list, wouldn't it be more sensible to have a "readable" > >>> JSON serialisation (i.e., leaving the signed payload "human readbale")!? > >>> This would of course require some form of > >>> normalisation/canonicalisaton as used e.g. in XML Security. Still, > >>> this would be something valuable to have and a real distinguishing > >>> point in comparison to the other serialisations. > >>> > >>> If people think that this is worth a discussion, then maybe we > >>> should kick-off an explicit thread on it. > >> > >> Human-readable JSON signatures is a reality although not as an IETF > >> standard. > >> > >> Since nobody is interested in bringing in the complexity of XML DSig > >> normalization, there seems to be some possible routes ahead. > >> > >> Phillip Hallam-Baker have proposed a scheme based on separating the > >> payload and the signature where the payload is used "verbatim" > >> reducing normalization and canonicalization to exactly ZERO: > >> http://www.ietf.org/mail-archive/web/acme/current/msg00224.html > >> > >> I have FWIW designed and also implemented a scheme which is based on > >> JSON's intrinsic normalization (white-space removal + character > >> escapes) but adds the constraint that a verifier honors the property > >> order of the serialized > >> object: > >> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html > >> Since a JSON parser-core typically is less than 500 lines of fairly > >> simple code I don't see that upgrading existing parsers with an > >> ordered dictionary would be > >> a show-stopper. It surely didn't stop me at least :-) > >> Runnable Java+JavaScript implementation: https://mobilepki.org/jcs > >> Partial Python implementation: > >> https://code.google.com/p/openkeystore/source/browse/python/trunk/src > >> /org/webpki/json/JCSValidator.py > >> > >> Minimal .NET implementation: > >> https://code.google.com/p/openkeystore/source/browse/resources/trunk/ > >> docs/JCSDemo.cs > >> > >> > >> Cheers, > >> Anders > >> > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Wed Mar 18 14:56:25 2015 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 A9E0E1A90E6 for ; Wed, 18 Mar 2015 14:56:23 -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 b3hfWEXjNWv4 for ; Wed, 18 Mar 2015 14:56:21 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212CA1A90EE for ; Wed, 18 Mar 2015 14:56:21 -0700 (PDT) Received: by wggv3 with SMTP id v3so46736432wgg.1 for ; Wed, 18 Mar 2015 14:56:19 -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=SevnG9wNW5YKoUVcWOvC8b/A1z65dIVAWY/GOxIGjjU=; b=v11RWyoXJQP1UvgUcmza105R/8szmNWDWZ6JZhrhRPoZCwgBI+qD1nj4+1yA2YpNfc NWUzgPV9J6ZjIpb62d9QUVdkMADxRlKcnqTwE7oL1AUXX0Jd4SzFTyFfzm8H4PMvxiAu YbePLq4q4OTzpChj9b5j6WezV/CMI8+7aWJUy4NiDnm7Ec/+9MEygwea5u3ZyVeGvppr thxyul9lm0Ms/X6Y3BOXCccn7dosn+OL+KnFVfgOBd0jyDH/w15Iy5kwYfi0Ai0wLjPX 1sNIgbG7Xi/A/p7a/BbaGojfgZFqHX8rTLMJ6BC+tCuzJfOoUZ71UsmGvgPnFaNXLyVV EzEQ== X-Received: by 10.180.74.135 with SMTP id t7mr10758482wiv.72.1426715779874; Wed, 18 Mar 2015 14:56:19 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id hl15sm4896180wib.3.2015.03.18.14.56.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 14:56:18 -0700 (PDT) Message-ID: <5509F46A.5090604@gmail.com> Date: Wed, 18 Mar 2015 22:55:54 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jim Schaad , luigi.lo_iacono@fh-koeln.de References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> <5502A778.8090709@gmail.com> <55093F90.406@fh-koeln.de> <5509CE69.5080204@gmail.com> <05d101d061b4$ef63b140$ce2b13c0$@augustcellars.com> In-Reply-To: <05d101d061b4$ef63b140$ce2b13c0$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: jose@ietf.org Subject: Re: [jose] Java-based JOSE implementation 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, 18 Mar 2015 21:56:23 -0000 On 2015-03-18 20:51, Jim Schaad wrote: > What do you consider to be clear text signatures? > > Would you consider carrying a payload that is a JSON string which is not > base64-ed to be plain text? > > I.e. > {"signature":"abc...def", "payload":"{'tag1':'value1','tag2':'value2'}", > "headers":"...."} > > The item to be signed is not at the top level, but it is readable by humans. That would of course qualify as a clear text signature. JCS was inspired by enveloped XML signatures which I found "pretty" since they just introduces an extra element in an existing XML object (i.e. context is unchanged), although JCS is much, much more primitive. Anders > Jim > > >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren >> Sent: Wednesday, March 18, 2015 12:14 PM >> To: luigi.lo_iacono@fh-koeln.de; Justin Richer; John Bradley; Brian > Campbell >> Cc: jose@ietf.org >> Subject: Re: [jose] Java-based JOSE implementation >> >> On 2015-03-18 10:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>> Anders, >> >> Hi Luigi, >> >>> thanks again for the pointers. Interesting reading. I like your >>> approach a lot. >> >> Thanx! >> >>> While crawling though the web I stumbled upon this fall asleep draft: >>> >>> https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 >>> >>> Have you been aware of this one!? >> >> Yes, I think so. As you can see "there are many roads to Rome" :-) >> >> One school says: "You must canonicalize data in a similar way as for XML", >> while another school claim that "Canonicalization is lunacy!". >> >> Full canonicalization like in the I-D above forces you to use a > stand-alone >> canonicalizer which is like building a parallel single-purpose JSON > parser. >> >> Using text "as is" makes canonicalization a zero issue but I felt that it > would be >> cooler using a standard (or moderately updated) JSON parser for creating > and >> validating signatures. This design also enables security properties like > keys to >> be handled exactly as any other properties. >> >> When I found (on stackoverflow) that many developers also feel that > parsers >> that read properties A, B, C but outputs them as A, C, B as inferior, the > decision >> to maintain strict property input/creation order became obvious. >> >> I'm currently not considering an IETF process, it seems like a better idea >> establishing this scheme through open source and actual usage :-) >> >> JCS was designed for supporting complex signature systems like: >> https://openkeystore.googlecode.com/svn/wcpp-payment- >> demo/trunk/docs/messages.html#UserSignedAuthorization >> >> Regards, >> Anders >> >>> >>> Anyway, I still think that JOSE requires a readable JSON serialisation. >>> I am not really familiar with the IETF procedures and seing that no >>> one else reacted on the suggestion so far, I guess that raising such >>> thoughts in the mailing list is not enough. What needs to be done in >>> order to have a discussion on replacing the flatened JSON >>> serialisation by a readbale JSON serialisation? >>> >>> Thanks and BR, Luigi. >>> >>> >>> Am 13.03.15 um 10:01 schrieb Anders Rundgren: >>>> On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>>>> Seems that there is some uncertainty about this "special" > serialisation. >>>>> I would actually vote for replacing the flatened JSON serialisation >>>>> with one, that provides a real benefit. Taken up on a discussion I >>>>> read earlier on the list, wouldn't it be more sensible to have a > "readable" >>>>> JSON serialisation (i.e., leaving the signed payload "human > readbale")!? >>>>> This would of course require some form of >>>>> normalisation/canonicalisaton as used e.g. in XML Security. Still, >>>>> this would be something valuable to have and a real distinguishing >>>>> point in comparison to the other serialisations. >>>>> >>>>> If people think that this is worth a discussion, then maybe we >>>>> should kick-off an explicit thread on it. >>>> >>>> Human-readable JSON signatures is a reality although not as an IETF >>>> standard. >>>> >>>> Since nobody is interested in bringing in the complexity of XML DSig >>>> normalization, there seems to be some possible routes ahead. >>>> >>>> Phillip Hallam-Baker have proposed a scheme based on separating the >>>> payload and the signature where the payload is used "verbatim" >>>> reducing normalization and canonicalization to exactly ZERO: >>>> http://www.ietf.org/mail-archive/web/acme/current/msg00224.html >>>> >>>> I have FWIW designed and also implemented a scheme which is based on >>>> JSON's intrinsic normalization (white-space removal + character >>>> escapes) but adds the constraint that a verifier honors the property >>>> order of the serialized >>>> object: >>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html >>>> Since a JSON parser-core typically is less than 500 lines of fairly >>>> simple code I don't see that upgrading existing parsers with an >>>> ordered dictionary would be >>>> a show-stopper. It surely didn't stop me at least :-) >>>> Runnable Java+JavaScript implementation: https://mobilepki.org/jcs >>>> Partial Python implementation: >>>> https://code.google.com/p/openkeystore/source/browse/python/trunk/src >>>> /org/webpki/json/JCSValidator.py >>>> >>>> Minimal .NET implementation: >>>> https://code.google.com/p/openkeystore/source/browse/resources/trunk/ >>>> docs/JCSDemo.cs >>>> >>>> >>>> Cheers, >>>> Anders >>>> >>> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > From nobody Wed Mar 18 22:41:06 2015 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 8A34B1A8934 for ; Wed, 18 Mar 2015 22:41:04 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8y77dlx3wHa for ; Wed, 18 Mar 2015 22:41:02 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B011A891D for ; Wed, 18 Mar 2015 22:41:02 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so52853152wgb.0 for ; Wed, 18 Mar 2015 22:41:01 -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:subject:references :in-reply-to:content-type; bh=bxews5fn+BmDAr7tLmirlj6ALfMWVYPWOhcJR7z0M9s=; b=Q1Jwh4mYbfe+N5so5VKiARHUbUBMbhvXpbeGKzMc4bdUgjgl4Ke8rZrF1OF6MKPkY7 U4o/Mvx6U2NKamsovqZaaYxnLOyfVpOsOiexEo/yxPB2uusupRrRqQqgzAFBjf8tORRS JrADuDZCNC7P372Q06cu8iPbKuEQH9HJgW+3wSF06kjB83ROFJGmofr59rqoig2qWUqs X4nh8jinvxM196rQtBv7J2xiPPn8aIwzsjhitasaXhbkRbA9SygbPgAKOZllQXMsB6wz vacf6DbtLeqWK8+3T8EfkQL+M2B4Tb1oVgSWtasAQdzc7TCUENAVl/BmPRso41fP3/EC Xitw== X-Received: by 10.194.86.194 with SMTP id r2mr151985414wjz.41.1426743661383; Wed, 18 Mar 2015 22:41:01 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id ps4sm415271wjc.31.2015.03.18.22.41.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 22:41:00 -0700 (PDT) Message-ID: <550A6154.9040907@gmail.com> Date: Thu, 19 Mar 2015 06:40:36 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "jose@ietf.org" References: <550909EF.4040505@gmail.com> In-Reply-To: <550909EF.4040505@gmail.com> Content-Type: multipart/alternative; boundary="------------030007020407030103010101" Archived-At: Subject: [jose] Charter Proposal: "Trusted Code" for the Web 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, 19 Mar 2015 05:41:04 -0000 This is a multi-part message in MIME format. --------------030007020407030103010101 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Trusted Code for the Web Existing security-related applications like authentication, payments, etc. are all based on that a core-part is executed by statically installed software that is supposed to be TRUSTED. Since web-based applications are transiently downloaded, unsigned and come from any number of more or less unknown sources, such applications are by definition UNTRUSTED. To compensate for this, web-based security applications currently rely on a hodge-podge of non-standard methods [1] where trusted code resides (and executes) somewhere outside of the actual web application. However, because each browser-vendor have their own idea on what is secure and useful [2], interoperability has proven to be a major hassle. In addition, the ongoing quest for locking down browsers (in order to make them more secure), tends to break applications after browser updates. Although security applications are interesting, they haven't proved to be a driver. Fortunately it has turned out that the desired capability ("Trusted Code"), is also used by massively popular music streaming services, cloud-based storage systems, on-line gaming sites and open source collaboration networks. The goal for the proposed effort would be to define a vendor- and device-neutral solution for dealing with trusted code on the Web. *References** * 1] An non-exhaustive list include: - Custom protocol handlers. Primarily used on Android and iOS. GitHub also uses it on Windows - Local web services on 127.0.0.1. Used by lots of services, from Spotify to digital signatures - Browser plugins like NPAPI/ActiveX. Used (for example) by millions of people in Korea for PKI support but is now being deprecated - Chrome native messaging. Fairly recent solution which enables Native <=> Web communication 2] https://code.google.com/p/chromium/issues/detail?id=378566 --------------030007020407030103010101 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Trusted Code for the Web

Existing security-related applications like authentication, payments, etc. are all based on that a core-part is executed by statically installed software that is supposed to be TRUSTED.

Since web-based applications are transiently downloaded, unsigned and come from any number of more or less unknown sources, such applications are by definition UNTRUSTED.

To compensate for this, web-based security applications currently rely on a hodge-podge of non-standard methods [1] where trusted code resides (and executes) somewhere outside of the actual web application.

However, because each browser-vendor have their own idea on what is secure and useful [2], interoperability has proven to be a major hassle.  In addition, the ongoing quest for locking down browsers (in order to make them more secure), tends to break applications after browser updates.

Although security applications are interesting, they haven't proved to be a driver.  Fortunately it has turned out that the desired capability ("Trusted Code"), is also used by massively popular music streaming services, cloud-based storage systems, on-line gaming sites and open source collaboration networks.

The goal for the proposed effort would be to define a vendor- and device-neutral solution for dealing with trusted code on the Web.


References

1] An non-exhaustive list include:
- Custom protocol handlers.  Primarily used on Android and iOS.  GitHub also uses it on Windows
- Local web services on 127.0.0.1.  Used by lots of services, from Spotify to digital signatures
- Browser plugins like NPAPI/ActiveX.  Used (for example) by millions of people in Korea for PKI support but is now being deprecated
- Chrome native messaging.  Fairly recent solution which enables Native <=> Web communication

2] https://code.google.com/p/chromium/issues/detail?id=378566



--------------030007020407030103010101-- From nobody Thu Mar 19 09:32:26 2015 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 94E861A1B27 for ; Thu, 19 Mar 2015 09:32:24 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_h_YjdlVS9K for ; Thu, 19 Mar 2015 09:32:21 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C23B1A1AAD for ; Thu, 19 Mar 2015 09:32:21 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so122759015wib.0 for ; Thu, 19 Mar 2015 09:32:19 -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; bh=MZ5tlUxENikqvkjNAU5yLbPG9jNZVaJPPGYXbTFf+ZU=; b=fCXPuRlNmpPcNTlVHdPu5YLdCklFJXaT1OJdSQs0qhLs29+rXbr8sh4C2ilhnvTxQh KGKxA3ZaH69zf1C5Gha9FrIVkf1I67rutugPjcFOrVGQEB8Xhppbr6XdpicsGBGaJxKs QXA9yOdOPn6wjwSaX2ZLomwRUvLygLVFnGe+5UZRvmFqQr/wZS79GCY/YRvHt1VR1LDe c41u1fcGKzOzGn5yKvN9da0PnUdJYA8QVtp+mKvHHKhajXThJmTakrA1TmzWPurTWhWR SOY1yhh9LQb/UhQxIvhVw9/aG1Qe8h+SXYr/rTYqPHb2hCM5r2gJIunKUOKZgdljDtYT klKw== X-Received: by 10.180.74.47 with SMTP id q15mr17322044wiv.49.1426782739705; Thu, 19 Mar 2015 09:32:19 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id g8sm3099846wiy.19.2015.03.19.09.32.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 09:32:18 -0700 (PDT) Message-ID: <550AF9F9.2070507@gmail.com> Date: Thu, 19 Mar 2015 17:31:53 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jim Schaad , luigi.lo_iacono@fh-koeln.de References: <54F8466B.8060007@fh-koeln.de> <55006F95.5090807@connect2id.com> <55019208.2030806@fh-koeln.de> <6CBC4A66-2B2D-42A7-B028-AFE962E44101@mit.edu> <94F8AC9B-4B93-4B0E-BEEA-94CF6E42D79E@ve7jtb.com> <5501CAC2.9000401@mit.edu> <55029B7E.1070903@fh-koeln.de> <5502A778.8090709@gmail.com> <55093F90.406@fh-koeln.de> <5509CE69.5080204@gmail.com> <05d101d061b4$ef63b140$ce2b13c0$@augustcellars.com> In-Reply-To: <05d101d061b4$ef63b140$ce2b13c0$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------040904070305070606050803" Archived-At: Cc: jose@ietf.org Subject: Re: [jose] Java-based JOSE implementation 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, 19 Mar 2015 16:32:24 -0000 This is a multi-part message in MIME format. --------------040904070305070606050803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2015-03-18 20:51, Jim Schaad wrote: Slight rehash of the clear text signature topic.... > What do you consider to be clear text signatures? > > Would you consider carrying a payload that is a JSON string which is not > base64-ed to be plain text? > > I.e. > {"signature":"abc...def", "payload":"{'tag1':'value1','tag2':'value2'}", > "headers":"...."} > > The item to be signed is not at the top level, but it is readable by humans. Yes, this is indeed a human readable signature. Below are three examples which shows the primary motive why JCS embeds signatures in JSON objects rather than as in your example/proposal embedding JSON objects in signature objects. Unsigned JSON Object { "@context": "https://json.example.com/protocol" "@qualifier": "Init", "property-1": ... "property-2": ... ... "property-n": ... } Optionally signed JSON Object { "@context": "https://json.example.com/protocol" "@qualifier": "Request", "property-1": ... "property-2": ... ... "property-n": ... "signature": { ... } } Signed JSON Object { "@context": "https://json.example.com/protocol" "@qualifier": "Response", "property-1": ... "property-2": ... ... "property-n": ... "signature": { ... } } That is, JCS maintains the message structure which makes message validation and documentation nicer. https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#KeyCreationRequest Anders > Jim > > >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren >> Sent: Wednesday, March 18, 2015 12:14 PM >> To: luigi.lo_iacono@fh-koeln.de; Justin Richer; John Bradley; Brian > Campbell >> Cc: jose@ietf.org >> Subject: Re: [jose] Java-based JOSE implementation >> >> On 2015-03-18 10:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>> Anders, >> Hi Luigi, >> >>> thanks again for the pointers. Interesting reading. I like your >>> approach a lot. >> Thanx! >> >>> While crawling though the web I stumbled upon this fall asleep draft: >>> >>> https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 >>> >>> Have you been aware of this one!? >> Yes, I think so. As you can see "there are many roads to Rome" :-) >> >> One school says: "You must canonicalize data in a similar way as for XML", >> while another school claim that "Canonicalization is lunacy!". >> >> Full canonicalization like in the I-D above forces you to use a > stand-alone >> canonicalizer which is like building a parallel single-purpose JSON > parser. >> Using text "as is" makes canonicalization a zero issue but I felt that it > would be >> cooler using a standard (or moderately updated) JSON parser for creating > and >> validating signatures. This design also enables security properties like > keys to >> be handled exactly as any other properties. >> >> When I found (on stackoverflow) that many developers also feel that > parsers >> that read properties A, B, C but outputs them as A, C, B as inferior, the > decision >> to maintain strict property input/creation order became obvious. >> >> I'm currently not considering an IETF process, it seems like a better idea >> establishing this scheme through open source and actual usage :-) >> >> JCS was designed for supporting complex signature systems like: >> https://openkeystore.googlecode.com/svn/wcpp-payment- >> demo/trunk/docs/messages.html#UserSignedAuthorization >> >> Regards, >> Anders >> >>> Anyway, I still think that JOSE requires a readable JSON serialisation. >>> I am not really familiar with the IETF procedures and seing that no >>> one else reacted on the suggestion so far, I guess that raising such >>> thoughts in the mailing list is not enough. What needs to be done in >>> order to have a discussion on replacing the flatened JSON >>> serialisation by a readbale JSON serialisation? >>> >>> Thanks and BR, Luigi. >>> >>> >>> Am 13.03.15 um 10:01 schrieb Anders Rundgren: >>>> On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>>>> Seems that there is some uncertainty about this "special" > serialisation. >>>>> I would actually vote for replacing the flatened JSON serialisation >>>>> with one, that provides a real benefit. Taken up on a discussion I >>>>> read earlier on the list, wouldn't it be more sensible to have a > "readable" >>>>> JSON serialisation (i.e., leaving the signed payload "human > readbale")!? >>>>> This would of course require some form of >>>>> normalisation/canonicalisaton as used e.g. in XML Security. Still, >>>>> this would be something valuable to have and a real distinguishing >>>>> point in comparison to the other serialisations. >>>>> >>>>> If people think that this is worth a discussion, then maybe we >>>>> should kick-off an explicit thread on it. >>>> Human-readable JSON signatures is a reality although not as an IETF >>>> standard. >>>> >>>> Since nobody is interested in bringing in the complexity of XML DSig >>>> normalization, there seems to be some possible routes ahead. >>>> >>>> Phillip Hallam-Baker have proposed a scheme based on separating the >>>> payload and the signature where the payload is used "verbatim" >>>> reducing normalization and canonicalization to exactly ZERO: >>>> http://www.ietf.org/mail-archive/web/acme/current/msg00224.html >>>> >>>> I have FWIW designed and also implemented a scheme which is based on >>>> JSON's intrinsic normalization (white-space removal + character >>>> escapes) but adds the constraint that a verifier honors the property >>>> order of the serialized >>>> object: >>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html >>>> Since a JSON parser-core typically is less than 500 lines of fairly >>>> simple code I don't see that upgrading existing parsers with an >>>> ordered dictionary would be >>>> a show-stopper. It surely didn't stop me at least :-) >>>> Runnable Java+JavaScript implementation: https://mobilepki.org/jcs >>>> Partial Python implementation: >>>> https://code.google.com/p/openkeystore/source/browse/python/trunk/src >>>> /org/webpki/json/JCSValidator.py >>>> >>>> Minimal .NET implementation: >>>> https://code.google.com/p/openkeystore/source/browse/resources/trunk/ >>>> docs/JCSDemo.cs >>>> >>>> >>>> Cheers, >>>> Anders >>>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose --------------040904070305070606050803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 2015-03-18 20:51, Jim Schaad wrote:

Slight rehash of the clear text signature topic....

What do you consider to be clear text signatures?

Would you consider carrying a payload that is a JSON string which is not
base64-ed to be plain text?

I.e.
{"signature":"abc...def", "payload":"{'tag1':'value1','tag2':'value2'}",
"headers":"...."}

The item to be signed is not at the top level, but it is readable by humans.
Yes, this is indeed a human readable signature.

Below are three examples which shows the primary motive why JCS embeds signatures in JSON
objects rather than as in your example/proposal embedding JSON objects in signature objects.

Unsigned JSON Object

{
  "@context": "https://json.example.com/protocol"
  "@qualifier": "Init",
  "property-1": ...
  "property-2": ...
     ...
  "property-n": ...
}


Optionally signed JSON Object

{
  "@context": "https://json.example.com/protocol"
  "@qualifier": "Request",
  "property-1": ...
  "property-2": ...
     ...
  "property-n": ...
  "signature":
    {
      ...
    }

}


Signed JSON Object

{

  "@context": "https://json.example.com/protocol"
  "@qualifier": "Response",
  "property-1": ...
  "property-2": ...
     ...
  "property-n": ...
  "signature":
    {
      ...
    }

}


That is, JCS maintains the message structure which makes message validation and documentation nicer.

https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#KeyCreationRequest

Anders


Jim


-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren
Sent: Wednesday, March 18, 2015 12:14 PM
To: luigi.lo_iacono@fh-koeln.de; Justin Richer; John Bradley; Brian
Campbell
Cc: jose@ietf.org
Subject: Re: [jose] Java-based JOSE implementation

On 2015-03-18 10:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
Anders,
Hi Luigi,

thanks again for the pointers. Interesting reading. I like your
approach a lot.
Thanx!

While crawling though the web I stumbled upon this fall asleep draft:

https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00

Have you been aware of this one!?
Yes, I think so.  As you can see "there are many roads to Rome" :-)

One school says: "You must canonicalize data in a similar way as for XML",
while another school claim that "Canonicalization is lunacy!".

Full canonicalization like in the I-D above forces you to use a
stand-alone
canonicalizer which is like building a parallel single-purpose JSON
parser.
Using text "as is" makes canonicalization a zero issue but I felt that it
would be
cooler using a standard (or moderately updated) JSON parser for creating
and
validating signatures.  This design also enables security properties like
keys to
be handled exactly as any other properties.

When I found (on stackoverflow) that many developers also feel that
parsers
that read properties A, B, C but outputs them as A, C, B as inferior, the
decision
to maintain strict property input/creation order became obvious.

I'm currently not considering an IETF process, it seems like a better idea
establishing this scheme through open source and actual usage :-)

JCS was designed for supporting complex signature systems like:
https://openkeystore.googlecode.com/svn/wcpp-payment-
demo/trunk/docs/messages.html#UserSignedAuthorization

Regards,
Anders

Anyway, I still think that JOSE requires a readable JSON serialisation.
I am not really familiar with the IETF procedures and seing that no
one else reacted on the suggestion so far, I guess that raising such
thoughts in the mailing list is not enough. What needs to be done in
order to have a discussion on replacing the flatened JSON
serialisation by a readbale JSON serialisation?

Thanks and BR, Luigi.


Am 13.03.15 um 10:01 schrieb Anders Rundgren:
On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
Seems that there is some uncertainty about this "special"
serialisation.
I would actually vote for replacing the flatened JSON serialisation
with one, that provides a real benefit. Taken up on a discussion I
read earlier on the list, wouldn't it be more sensible to have a
"readable"
JSON serialisation (i.e., leaving the signed payload "human
readbale")!?
This would of course require some form of
normalisation/canonicalisaton as used e.g. in XML Security. Still,
this would be something valuable to have and a real distinguishing
point in comparison to the other serialisations.

If people think that this is worth a discussion, then maybe we
should kick-off an explicit thread on it.
Human-readable JSON signatures is a reality although not as an IETF
standard.

Since nobody is interested in bringing in the complexity of XML DSig
normalization, there seems to be some possible routes ahead.

Phillip Hallam-Baker have proposed a scheme based on separating the
payload and the signature where the payload is used "verbatim"
reducing normalization and canonicalization to exactly ZERO:
http://www.ietf.org/mail-archive/web/acme/current/msg00224.html

I have FWIW designed and also implemented a scheme which is based on
JSON's intrinsic normalization (white-space removal + character
escapes) but adds the constraint that a verifier honors the property
order of the serialized
object:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html
Since a JSON parser-core typically is less than 500 lines of fairly
simple code I don't see that upgrading existing parsers with an
ordered dictionary would be
a show-stopper.   It surely didn't stop me at least :-)
Runnable Java+JavaScript implementation: https://mobilepki.org/jcs
Partial Python implementation:
https://code.google.com/p/openkeystore/source/browse/python/trunk/src
/org/webpki/json/JCSValidator.py

Minimal .NET implementation:
https://code.google.com/p/openkeystore/source/browse/resources/trunk/
docs/JCSDemo.cs


Cheers,
Anders


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

    

--------------040904070305070606050803-- From nobody Thu Mar 19 11:07:09 2015 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 3D1E51A8743 for ; Thu, 19 Mar 2015 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wa-jqIrjawJW for ; Thu, 19 Mar 2015 11:07:05 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C266F1A8778 for ; Thu, 19 Mar 2015 11:06:53 -0700 (PDT) Received: from Philemon (unknown [170.173.8.12]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 272B038EF1; Thu, 19 Mar 2015 11:06:53 -0700 (PDT) From: "Jim Schaad" To: "'Anders Rundgren'" , References: <550909EF.4040505@gmail.com> <550A6154.9040907@gmail.com> In-Reply-To: <550A6154.9040907@gmail.com> Date: Thu, 19 Mar 2015 11:05:50 -0700 Message-ID: <069401d0626f$55cb1990$01614cb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0695_01D06234.A96E1650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKiIy2EyuGHkycg0453GkEqWmRy2QMyUodcm2cFn4A= Content-Language: en-us Archived-At: Subject: Re: [jose] Charter Proposal: "Trusted Code" for the Web 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, 19 Mar 2015 18:07:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0695_01D06234.A96E1650 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To me this sounds more like a W3C activity than an IETF activity. =20 Jim =20 =20 From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren Sent: Wednesday, March 18, 2015 10:41 PM To: jose@ietf.org Subject: [jose] Charter Proposal: "Trusted Code" for the Web =20 Trusted Code for the Web Existing security-related applications like authentication, payments, = etc. are all based on that a core-part is executed by statically = installed software that is supposed to be TRUSTED.=20 Since web-based applications are transiently downloaded, unsigned and = come from any number of more or less unknown sources, such applications = are by definition UNTRUSTED. To compensate for this, web-based security applications currently rely = on a hodge-podge of non-standard methods [1] where trusted code resides = (and executes) somewhere outside of the actual web application. However, because each browser-vendor have their own idea on what is = secure and useful [2], interoperability has proven to be a major hassle. = In addition, the ongoing quest for locking down browsers (in order to = make them more secure), tends to break applications after browser = updates. Although security applications are interesting, they haven't proved to = be a driver. Fortunately it has turned out that the desired capability = ("Trusted Code"), is also used by massively popular music streaming = services, cloud-based storage systems, on-line gaming sites and open = source collaboration networks. The goal for the proposed effort would be to define a vendor- and = device-neutral solution for dealing with trusted code on the Web. References 1] An non-exhaustive list include: - Custom protocol handlers. Primarily used on Android and iOS. GitHub = also uses it on Windows - Local web services on 127.0.0.1. Used by lots of services, from = Spotify to digital signatures - Browser plugins like NPAPI/ActiveX. Used (for example) by millions of = people in Korea for PKI support but is now being deprecated - Chrome native messaging. Fairly recent solution which enables Native = <=3D> Web communication 2] https://code.google.com/p/chromium/issues/detail?id=3D378566 =20 ------=_NextPart_000_0695_01D06234.A96E1650 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

To me this sounds more like a W3C activity than an IETF = activity.

 

Jim

 

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders = Rundgren
Sent: Wednesday, March 18, 2015 10:41 = PM
To: jose@ietf.org
Subject: [jose] Charter = Proposal: "Trusted Code" for the = Web

 

Trusted Code for the = Web


Existing security-related = applications like authentication, payments, etc. are all based on that a = core-part is executed by statically installed software that is supposed = to be TRUSTED.

Since web-based applications are transiently = downloaded, unsigned and come from any number of more or less unknown = sources, such applications are by definition UNTRUSTED.

To = compensate for this, web-based security applications currently rely on a = hodge-podge of non-standard methods [1] where trusted code resides (and = executes) somewhere outside of the actual web = application.

However, because each browser-vendor have their own = idea on what is secure and useful [2], interoperability has proven to be = a major hassle.  In addition, the ongoing quest for locking down = browsers (in order to make them more secure), tends to break = applications after browser updates.

Although security = applications are interesting, they haven't proved to be a driver.  = Fortunately it has turned out that the desired capability ("Trusted = Code"), is also used by massively popular music streaming services, = cloud-based storage systems, on-line gaming sites and open source = collaboration networks.

The goal for the proposed effort would be = to define a vendor- and device-neutral solution for dealing with trusted = code on the Web.


References

1] An = non-exhaustive list include:
- Custom protocol handlers.  = Primarily used on Android and iOS.  GitHub also uses it on = Windows
- Local web services on 127.0.0.1.  Used by lots of = services, from Spotify to digital signatures
- Browser plugins like = NPAPI/ActiveX.  Used (for example) by millions of people in Korea = for PKI support but is now being deprecated
- Chrome native = messaging.  Fairly recent solution which enables Native <=3D> = Web communication

2] htt= ps://code.google.com/p/chromium/issues/detail?id=3D378566

 

------=_NextPart_000_0695_01D06234.A96E1650-- From nobody Thu Mar 19 11:15:30 2015 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 DDE931A8AC3 for ; Thu, 19 Mar 2015 11:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teeE0k6KemqB for ; Thu, 19 Mar 2015 11:15:26 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C161A8AA6 for ; Thu, 19 Mar 2015 11:15:26 -0700 (PDT) Received: by qcaz10 with SMTP id z10so73838708qca.1 for ; Thu, 19 Mar 2015 11:15: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:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5nAxZuOqsC5GwSTOvbYK9BIIMDRRWbGMMCH6Tz++8D0=; b=EuiUjMi347kzv4XQABPXF99Eg0ENjG0Z2G5k1w9fjbAssvYnElvr+UUhwX8tleuao7 mtE8Q6C+XyUFvNw91znC2X2vSmU/+BaoB/Cp3nQcDm3qcit0KuIqfLXaPfXzaIB4A5n9 mFjSuRKoTak+M2iqDFhZrYlMHn4upLcdgcIHLqB4Qy4EY1VVQihp6nAmawOJPuQZafdG puSWcpd30aSLJucbaPzrNi5Vn9G+L/IKwsGFTZi1JvLaNcUJhMLyfJi8kOthr5sCWDki xMMbXDj2etIeArfqOmBa+ug+quhH93xMPr3Kpnswdq7ag6eeNr2TTkbDUMvOkLfzLdkx xvrw== X-Gm-Message-State: ALoCoQmg08owQM1szdJ0Km6Gif3G9dp/axDUJSF35lPdnBWJMi+Cddl/kef8Tfdn4MkLPRICUhA9 X-Received: by 10.55.42.88 with SMTP id q85mr128394782qkh.65.1426788925521; Thu, 19 Mar 2015 11:15:25 -0700 (PDT) Received: from [192.168.8.100] ([181.202.157.120]) by mx.google.com with ESMTPSA id h85sm1324373qhc.6.2015.03.19.11.15.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Mar 2015 11:15:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_78BB3CBB-7FA6-480B-9C58-675713480499"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <069401d0626f$55cb1990$01614cb0$@augustcellars.com> Date: Thu, 19 Mar 2015 15:15:19 -0300 Message-Id: References: <550909EF.4040505@gmail.com> <550A6154.9040907@gmail.com> <069401d0626f$55cb1990$01614cb0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: jose@ietf.org, Anders Rundgren Subject: Re: [jose] Charter Proposal: "Trusted Code" for the Web 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, 19 Mar 2015 18:15:29 -0000 --Apple-Mail=_78BB3CBB-7FA6-480B-9C58-675713480499 Content-Type: multipart/alternative; boundary="Apple-Mail=_327F9D77-3AAB-4A69-8485-C7057E775E7B" --Apple-Mail=_327F9D77-3AAB-4A69-8485-C7057E775E7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It sounds like WebCrypto or something more related to it. = http://www.w3.org/2012/webcrypto/ =20 > On Mar 19, 2015, at 3:05 PM, Jim Schaad = wrote: >=20 > To me this sounds more like a W3C activity than an IETF activity. > =20 > Jim > =20 > =20 > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren > Sent: Wednesday, March 18, 2015 10:41 PM > To: jose@ietf.org > Subject: [jose] Charter Proposal: "Trusted Code" for the Web > =20 > Trusted Code for the Web >=20 > Existing security-related applications like authentication, payments, = etc. are all based on that a core-part is executed by statically = installed software that is supposed to be TRUSTED.=20 >=20 > Since web-based applications are transiently downloaded, unsigned and = come from any number of more or less unknown sources, such applications = are by definition UNTRUSTED. >=20 > To compensate for this, web-based security applications currently rely = on a hodge-podge of non-standard methods [1] where trusted code resides = (and executes) somewhere outside of the actual web application. >=20 > However, because each browser-vendor have their own idea on what is = secure and useful [2], interoperability has proven to be a major hassle. = In addition, the ongoing quest for locking down browsers (in order to = make them more secure), tends to break applications after browser = updates. >=20 > Although security applications are interesting, they haven't proved to = be a driver. Fortunately it has turned out that the desired capability = ("Trusted Code"), is also used by massively popular music streaming = services, cloud-based storage systems, on-line gaming sites and open = source collaboration networks. >=20 > The goal for the proposed effort would be to define a vendor- and = device-neutral solution for dealing with trusted code on the Web. >=20 >=20 > References >=20 > 1] An non-exhaustive list include: > - Custom protocol handlers. Primarily used on Android and iOS. = GitHub also uses it on Windows > - Local web services on 127.0.0.1. Used by lots of services, from = Spotify to digital signatures > - Browser plugins like NPAPI/ActiveX. Used (for example) by millions = of people in Korea for PKI support but is now being deprecated > - Chrome native messaging. Fairly recent solution which enables = Native <=3D> Web communication >=20 > 2] https://code.google.com/p/chromium/issues/detail?id=3D378566 = >=20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_327F9D77-3AAB-4A69-8485-C7057E775E7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It sounds like WebCrypto or something more related to = it. http://www.w3.org/2012/webcrypto/ 


On Mar 19, 2015, at 3:05 PM, = Jim Schaad <ietf@augustcellars.com> wrote:

To me this sounds more like a W3C activity = than an IETF activity.
 
Jim
 
 
From: jose [mailto:jose-bounces@ietf.org] On Behalf = Of Anders = Rundgren
Sent: Wednesday, March 18, 2015 = 10:41 PM
To: jose@ietf.org
Subject: [jose] Charter Proposal: = "Trusted Code" for the Web
 
Trusted Code for = the Web


Existing = security-related applications like authentication, payments, etc. are = all based on that a core-part is executed by statically installed = software that is supposed to be TRUSTED. 

Since web-based applications are transiently downloaded, = unsigned and come from any number of more or less unknown sources, such = applications are by definition UNTRUSTED.

To = compensate for this, web-based security applications currently rely on a = hodge-podge of non-standard methods [1] where trusted code resides (and = executes) somewhere outside of the actual web application.

However, because each browser-vendor have = their own idea on what is secure and useful [2], interoperability has = proven to be a major hassle.  In addition, the ongoing quest for = locking down browsers (in order to make them more secure), tends to = break applications after browser updates.

Although security applications are interesting, they haven't = proved to be a driver.  Fortunately it has turned out that the = desired capability ("Trusted Code"), is also used by massively popular = music streaming services, cloud-based storage systems, on-line gaming = sites and open source collaboration networks.

The goal for the proposed effort would be to define a vendor- = and device-neutral solution for dealing with trusted code on the Web.


References

1] An non-exhaustive list include:
- Custom protocol handlers.  Primarily used on Android = and iOS.  GitHub also uses it on Windows
- Local web = services on 127.0.0.1.  Used by lots of services, from Spotify to = digital signatures
- Browser plugins like = NPAPI/ActiveX.  Used (for example) by millions of people in Korea = for PKI support but is now being deprecated
- Chrome = native messaging.  Fairly recent solution which enables Native = <=3D> Web communication

2] https://code.google.com/p/chromium/issues/detail?id=3D378566

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

= --Apple-Mail=_327F9D77-3AAB-4A69-8485-C7057E775E7B-- --Apple-Mail=_78BB3CBB-7FA6-480B-9C58-675713480499 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTkxODE1MTlaMCMGCSqGSIb3DQEJBDEWBBTxd38Dsh1F2wlZgwomnz1K KXt8mzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQChaN+DrVhkCPHVl513kin+EPwUDNhhlK1ChEA/Oy/Bm0sQ58eO3WYI EgJVkXPOY5N8CdyWOsngayGFmQwXy6WdC2wLbDuwd1UhKXDZKT/BrZNIHqZ/SKR/ybM/KhKzTRsq FKmdKYida7Dy7n6NsS/EbIaVBTO0eCuNQ9K6ysRUqedlttRhmpSBJ/ebIeSOsrdIjkkTpoAnPO1e /pwArt0dm8twAAOfFBKe7bUmGhWZt2H7oqXggsTeHrO4zIVg1TCb+w/BGFWujXxHFfPWd0dPqjAk PmIoJ6Qo0ESV4c/yacb5i5GZ/ulmpJVat5yasHTTBs/TA3FYoKkNPjae5NPDAAAAAAAA --Apple-Mail=_78BB3CBB-7FA6-480B-9C58-675713480499-- From nobody Thu Mar 19 22:50:23 2015 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 E7BBD1B2C23 for ; Thu, 19 Mar 2015 22:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_26=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 v_ykVcUKRHhY for ; Thu, 19 Mar 2015 22:50:20 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9171B2C1C for ; Thu, 19 Mar 2015 22:50:20 -0700 (PDT) Received: by webcq43 with SMTP id cq43so74058079web.2 for ; Thu, 19 Mar 2015 22:50:18 -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=6KK4Ppf14evsMSTtyyvju9sWxHuj8gGjwsFnb7a03Pk=; b=QvW4qPM+TOx76T8/p1CbBoKQzLheHId9Kt4lgA/1tyrqTPA7YgpQp2uHP/lsFD1A2/ OMrYT145lEQvRSrk4+uP3j8KdE0R+DtBrMH6bwy62ZdKIgy4jGhq70KL8tNuCidTThZd C+Bu2lLt3S0AFhGhGlDljHtzToWdzjuaS3cJBUxMHuBwHwPj3hwb+m+kUKzhIpBFc3wr cEVz0ZMlWc/Q4i2NBvd+vNGGW1BSRp6v+UVR1/PFOx3fc0KaFIN4wgPBSl5P5dnyTdT6 nHBE7X+FK/DHIHkkJoTIn+k8gYlm66XHtj4JvDnekN5xeWVlkgHfXHrJAT7XBxxu/atk veDg== X-Received: by 10.194.133.199 with SMTP id pe7mr116069283wjb.120.1426830618809; Thu, 19 Mar 2015 22:50:18 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id k6sm1487663wia.6.2015.03.19.22.50.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 22:50:18 -0700 (PDT) Message-ID: <550BB500.4070505@gmail.com> Date: Fri, 20 Mar 2015 06:49:52 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Bradley , Jim Schaad References: <550909EF.4040505@gmail.com> <550A6154.9040907@gmail.com> <069401d0626f$55cb1990$01614cb0$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: jose@ietf.org Subject: Re: [jose] Charter Proposal: "Trusted Code" for the Web 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, 20 Mar 2015 05:50:22 -0000 On 2015-03-19 19:15, John Bradley wrote: > It sounds like WebCrypto or something more related to it. http://www.w3.org/2012/webcrypto/ I would rather characterize this as the opposite to WebCrypto since the referred schemes all are based on the idea that "The Web is not enough". That is, the Web needs (as proven any number of times), to be extended with its more powerful native/platform companion for a lot of reasons including access to platform- resident keys as well as breaking away from the crippling SOP notion. The W3C does not appear to be a suitable home for such an effort, they rather prefer continuing the so far pretty unsuccessful efforts DUPLICATING the native level into the Web [1], instead of recognizing the power of COMBINING these worlds. Cheers, Anders 1] https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/0000.html > > >> On Mar 19, 2015, at 3:05 PM, Jim Schaad > wrote: >> >> To me this sounds more like a W3C activity than an IETF activity. >> Jim >> *From:*jose [mailto:jose-bounces@ietf.org]*On Behalf Of*Anders Rundgren >> *Sent:*Wednesday, March 18, 2015 10:41 PM >> *To:*jose@ietf.org >> *Subject:*[jose] Charter Proposal: "Trusted Code" for the Web >> Trusted Code for the Web >> >> >> Existing security-related applications like authentication, payments, etc. are all based on that a core-part is executed by statically installed software that is supposed to be TRUSTED. >> >> Since web-based applications are transiently downloaded, unsigned and come from any number of more or less unknown sources, such applications are by definition UNTRUSTED. >> >> To compensate for this, web-based security applications currently rely on a hodge-podge of non-standard methods [1] where trusted code resides (and executes) somewhere outside of the actual web application. >> >> However, because each browser-vendor have their own idea on what is secure and useful [2], interoperability has proven to be a major hassle. In addition, the ongoing quest for locking down browsers (in order to make them more secure), tends to break applications after browser updates. >> >> Although security applications are interesting, they haven't proved to be a driver. Fortunately it has turned out that the desired capability ("Trusted Code"), is also used by massively popular music streaming services, cloud-based storage systems, on-line gaming sites and open source collaboration networks. >> >> The goal for the proposed effort would be to define a vendor- and device-neutral solution for dealing with trusted code on the Web. >> >> >> *References >> * >> 1] An non-exhaustive list include: >> - Custom protocol handlers. Primarily used on Android and iOS. GitHub also uses it on Windows >> - Local web services on 127.0.0.1. Used by lots of services, from Spotify to digital signatures >> - Browser plugins like NPAPI/ActiveX. Used (for example) by millions of people in Korea for PKI support but is now being deprecated >> - Chrome native messaging. Fairly recent solution which enables Native <=> Web communication >> >> 2]https://code.google.com/p/chromium/issues/detail?id=378566 >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > From nobody Fri Mar 20 00:31:03 2015 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 2724C1A90AB for ; Fri, 20 Mar 2015 00:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkJ9kyyuCNWp for ; Fri, 20 Mar 2015 00:31:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D647E1B2C68 for ; Fri, 20 Mar 2015 00:30:59 -0700 (PDT) Received: from [192.168.131.145] ([80.92.115.8]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M82zV-1ZTaqY1CAz-00vimZ; Fri, 20 Mar 2015 08:30:43 +0100 Message-ID: <550BCCA2.709@gmx.net> Date: Fri, 20 Mar 2015 08:30:42 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Anders Rundgren , John Bradley , Jim Schaad References: <550909EF.4040505@gmail.com> <550A6154.9040907@gmail.com> <069401d0626f$55cb1990$01614cb0$@augustcellars.com> <550BB500.4070505@gmail.com> In-Reply-To: <550BB500.4070505@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NKBGfXpJgO32doH7B51KOm7nANfBJehMT" X-Provags-ID: V03:K0:OEqRAszdKNkj9bnU9R5oVLkn7RYTPvkNbvnvH8a+UusbdQzyBZ0 YBro6AubypvZXPXNaVPSRnvh+0F42LGUtcneX/+ymlvyDMeUPz80KTvvmXCRw+k2tgXlybx FK0UpXpoYFDv5sHlz+8rV69kMo4ghrLAYTbWY1J4PcPYZMWtwHhkjwUewlb84tdQW+dhoBr DjUYJwR9/P4wQ1/ngYZZA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: jose@ietf.org Subject: Re: [jose] Charter Proposal: "Trusted Code" for the Web 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, 20 Mar 2015 07:31:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NKBGfXpJgO32doH7B51KOm7nANfBJehMT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I like the proposal Anders put forward. Doing some work in the IETF in that area might not be a bad idea to stimulate discussions. Ciao Hannes On 03/20/2015 06:49 AM, Anders Rundgren wrote: > On 2015-03-19 19:15, John Bradley wrote: >> It sounds like WebCrypto or something more related to it. >> http://www.w3.org/2012/webcrypto/ >=20 > I would rather characterize this as the opposite to WebCrypto since the= > referred schemes > all are based on the idea that "The Web is not enough". >=20 > That is, the Web needs (as proven any number of times), to be extended > with its more > powerful native/platform companion for a lot of reasons including acces= s > to platform- > resident keys as well as breaking away from the crippling SOP notion. >=20 > The W3C does not appear to be a suitable home for such an effort, they > rather prefer > continuing the so far pretty unsuccessful efforts DUPLICATING the nativ= e > level into > the Web [1], instead of recognizing the power of COMBINING these worlds= =2E >=20 > Cheers, > Anders >=20 > 1] https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/0000.htm= l >=20 >> >> >>> On Mar 19, 2015, at 3:05 PM, Jim Schaad >> > wrote: >>> >>> To me this sounds more like a W3C activity than an IETF activity. >>> Jim >>> *From:*jose [mailto:jose-bounces@ietf.org]*On Behalf Of*Anders Rundgr= en >>> *Sent:*Wednesday, March 18, 2015 10:41 PM >>> *To:*jose@ietf.org >>> *Subject:*[jose] Charter Proposal: "Trusted Code" for the Web >>> Trusted Code for the Web >>> >>> >>> Existing security-related applications like authentication, payments,= >>> etc. are all based on that a core-part is executed by statically >>> installed software that is supposed to be TRUSTED. >>> >>> Since web-based applications are transiently downloaded, unsigned and= >>> come from any number of more or less unknown sources, such >>> applications are by definition UNTRUSTED. >>> >>> To compensate for this, web-based security applications currently >>> rely on a hodge-podge of non-standard methods [1] where trusted code >>> resides (and executes) somewhere outside of the actual web applicatio= n. >>> >>> However, because each browser-vendor have their own idea on what is >>> secure and useful [2], interoperability has proven to be a major >>> hassle. In addition, the ongoing quest for locking down browsers (in= >>> order to make them more secure), tends to break applications after >>> browser updates. >>> >>> Although security applications are interesting, they haven't proved >>> to be a driver. Fortunately it has turned out that the desired >>> capability ("Trusted Code"), is also used by massively popular music >>> streaming services, cloud-based storage systems, on-line gaming sites= >>> and open source collaboration networks. >>> >>> The goal for the proposed effort would be to define a vendor- and >>> device-neutral solution for dealing with trusted code on the Web. >>> >>> >>> *References >>> * >>> 1] An non-exhaustive list include: >>> - Custom protocol handlers. Primarily used on Android and iOS.=20 >>> GitHub also uses it on Windows >>> - Local web services on 127.0.0.1. Used by lots of services, from >>> Spotify to digital signatures >>> - Browser plugins like NPAPI/ActiveX. Used (for example) by millions= >>> of people in Korea for PKI support but is now being deprecated >>> - Chrome native messaging. Fairly recent solution which enables >>> Native <=3D> Web communication >>> >>> 2]https://code.google.com/p/chromium/issues/detail?id=3D378566 >>> >>> _______________________________________________ >>> 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 --NKBGfXpJgO32doH7B51KOm7nANfBJehMT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVC8yiAAoJEGhJURNOOiAtsLIH/32/f6ayLdFr3ygO7rbBxjbq UZP6vaiwrNSuHmZ0Pkhs0262p6HEesjfGjQBmYf/sZQ5EW9iD7MLswOCqKgzeoI0 PD4MucUo9FUtKNXoueM7ChM6fQWZZz7bKP9ZXIUXKGNjM4ExDTtGaZKRQ4LX7guD RT18EbtoKaxMJoJ6ACaeILQj4/NaWGMmC8j6iByo4E5/Oy1dWHuo0zzGThvuiyg2 +Cy6ryMYxGsRLJXNJNeocyaYv2XXTA01mTof1hCC/TmTqflN4F3I6ix7bdU4znjL d2FxcN7bObcUgrV9vHtxnofs97Pte7Ps6oy9kUv9pFBCHaqRdvqLRQS9jOzvJ2o= =xUCG -----END PGP SIGNATURE----- --NKBGfXpJgO32doH7B51KOm7nANfBJehMT-- From nobody Fri Mar 20 01:23:21 2015 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 9070F1B2C72 for ; Fri, 20 Mar 2015 01:23:19 -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 4Mi0FPzIWAZo for ; Fri, 20 Mar 2015 01:23:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301471A894B for ; Fri, 20 Mar 2015 01:23:16 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-82-550bd8f2808b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 32.BC.01716.2F8DB055; Fri, 20 Mar 2015 09:23:14 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.133]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Fri, 20 Mar 2015 09:23:13 +0100 From: John Mattsson To: "Joe Hildebrand (jhildebr)" Thread-Topic: [jose] COSE: what would change? Thread-Index: AQHQWEJ1QLnkI9RDkEaFuLpGIA6Fwp0lDPqA Date: Fri, 20 Mar 2015 08:23:13 +0000 Message-ID: References: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> In-Reply-To: <66855374-D565-4E65-8978-36AE2F539FBD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_D57BD7B602DB45D1B497573AB32C7468ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RvfTDe5QgxcH5S3O7jnObrFmTTeT A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVxfsprtoKZhRXHf8g0MPbldTFyckgImEis 37SDHcIWk7hwbz1bFyMXh5DAEUaJe7OXskA4SxglXs87xQJSxSZgIDF3TwMbiC0C1P3uzRrG LkYODmYBZYkbfaYgYWEBHYlbR3ZDlehKvGzawA5SIiJgJHHuHStImEVAVeLHi+1MIDavgL3E xwXPGEFsIQEbiW1LT4Nt4hSwlTh+5xTYbYxAt30/tQasnllAXOLWk/lMEDcLSCzZc54ZwhaV ePn4HyuErSSx6PZnqPpkiVm357FB7BKUODnzCcsERtFZSEbNQlI2C0nZLLDHNCXW79KHKFGU mNL9kB3C1pBonTMXyraWeLB8LxuymgWMHKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAiPw 4JbfujsYV792PMQowMGoxMNr0MsdKsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxrXHl6mzGccYO/HsTeO3O8FiwWEps2+p3aOu6S4tbBx+y9UPq1s4VRzu UZf+Evv4Y2TzBRaFpcfWTXQ4zm60/dUct1/iGecesrkHaS7YfOj6vVbBpq2FoserJl/camMu yl74NN8qL2L7vVerVhsztazn2Hk4/OLm/5VJm9a139wdeaox5KtVqhJLcUaioRZzUXEiAANA 8/GhAgAA Archived-At: Cc: "jose@ietf.org" Subject: Re: [jose] COSE: what would change? 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, 20 Mar 2015 08:23:19 -0000 --_000_D57BD7B602DB45D1B497573AB32C7468ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBzdGFydGluZyB0aGUgZGlzY3Vzc2lvbiBKb2UsDQoNCkkgc3Ryb25nbHkgc3Vw cG9ydCB0aGUgd29yayBvbiBDT1NFLiBNeSB2aWV3IGlzIHRoYXQgdG8gYmUgcmVsZXZhbnQgZm9y IHRoZSBJb1QgdXNlIGNhc2VzLCBhbmQgaW4gcGFydGljdWxhciBkZXZpY2VzIHVzaW5nIElFRUUg ODAyLjE1LjQsIENPU0UgbXVzdCBiZSBoaWdobHkgb3B0aW1pemVkIGNvbXBhcmVkIHRvIEpPU0U6 DQoNCkluIG91ciBkcmFmdCBvbiBlbmQtdG8tZW5kIHNlY3VyaXR5IGZvciBJb1QgKGRyYWZ0LXNl bGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDEpIHdlcmUgd2UgcGxhbiB0byB1c2UgQ09TRSwg b3VyIG1lYXN1cmVtZW50cyBzaG93IHRoYXQgdXNhZ2Ugb2YgSldTIGNhbiBlYXNpbHkgYWRkIDEz NSBieXRlcywgZmlsbGluZyB1cCBtb3JlIHRoYW4gYW4gZW50aXJlIElFRUUgODAyLjE1LjQgZnJh bWUuICBDT1NFIChhY2NvcmRpbmcgdG8gZHJhZnQtYm9ybWFubi1qb3NlLWNvc2UtMDApIHdvdWxk IGJlIGZhciBiZXR0ZXIgYnV0IHN0aWxsIHVzZSA3MCBieXRlcy4gTXkgdmlldyBpcyB0aGF0IHRo aXMgaXMgc3RpbGwgdG8gbGFyZ2UgZm9yIElFRUUgODAyLjE1LjQgYW5kIHRoYXQgdGhlIGZvbGxv d2luZyB0aHJlZSBvcHRpbWl6YXRpb25zIGFyZSBuZWVkZWQgKGltcGVyYXRpdmUpOg0KDQotIENh cnN0ZW4gaGFzIGFscmVhZHkgc3VnZ2VzdGVkIHJlcGxhY2luZyBjZXJ0YWluIG1lbWJlciBuYW1l cyAoImFsZyIuLi4pIHdpdGggcHJlZGVmaW5lZCBudW1iZXJzLiBJIHN0cm9uZ2x5IHN1cHBvcnQg dGhpcy4NCg0KLSBFdmVuIHdpdGhvdXQgYmFzZTY0IGVuY29kaW5nLCB0aGUgSldTIE1BQ3MgdGFr ZXMgMzIgYnl0ZXMuIElvVCBkZXZpY2VzIHVzaW5nIERUTFMgdXNlIDggYnl0ZSBNQUNzLiBJIHN0 cm9uZ2x5IHRoaW5rIElvVCBzcGVjaWZpYyBhbGdvcml0aG1zIHdpdGggdHJ1bmNhdGVkIE1BQ3Mg KG1heWJlIDE2IGFuZCA4IGJ5dGVzKSBhcmUgbmVjZXNzYXJ5Lg0KDQotIFRoZSBKV0UgSW5pdGlh bGl6YXRpb24gVmVjdG9yIHRha2VzIHVwIDEyIGJ5dGVzLCBJb1QgZGV2aWNlcyB3b3VsZCBsaWtl bHkgd2FudCB0byBzYXZlIGEgbm9uY2UgdG9nZXRoZXIgd2l0aCB0aGUga2V5IHRvIHNhdmUgYmFu ZHdpZHRoIChhbmQgdGhlcmVmb3JlIGJhdHRlcnkpLg0KDQpXaXRoIHRoZXNlIGNoYW5nZXMsIHRo ZSBvdmVyaGVhZCBvZiBDT1NFIChib3RoIENXUyBhbmQgQ1dFKSBjb3VsZCBiZSBiZWxvdyAzMCBi eXRlcy4gSSB0aGluayB0aGlzIG5vdCBvbmx5IGRlc2lyYWJsZSwgYnV0IGFsc28gbmVjZXNzYXJ5 LiBUaGUgYWxnb3JpdGhtIGFuZCBJViBvcHRpbWl6YXRpb25zIGNvdWxkIGJlIGRvbmUgaW4gcGFy YWxsZWwgdG8gdGhlIENPU0UgZW5jb2Rpbmcgd29yay4NCg0KQ2hlZXJzLA0KSm9obg0KDQrigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJQNCkpvaG4gTWF0dHNzb24NCkVyaWNzc29uIElFVEYgU2VjdXJpdHkgQ29vcmRpbmF0 b3INClNlbmlvciBSZXNlYXJjaGVyLCBTZWN1cml0eQ0KDQpPbiAwNiBNYXIgMjAxNSwgYXQgMjA6 MTksIEpvZSBIaWxkZWJyYW5kIChqaGlsZGVicikgPGpoaWxkZWJyQGNpc2NvLmNvbTxtYWlsdG86 amhpbGRlYnJAY2lzY28uY29tPj4gd3JvdGU6DQoNCkluIHRhbGtpbmcgd2l0aCBzZXZlcmFsIGZv bGtzIGFib3V0IENPU0UsIGl0IGFwcGVhcnMgdGhhdCB0aGVyZSBhcmUgZGlmZmVyaW5nIHZpZXdz IG9uIGhvdyBtdWNoIHRvIGNoYW5nZSBpbiB0aGUgSk9TRS9DT1NFIHRyYW5zbGF0aW9uLiAgSSB3 b3VsZCBsaWtlIHRvIGV4cGxvcmUgdGhlIHBvaW50cyBvZiBhZ3JlZW1lbnQgYW5kIGRpc2FncmVl bWVudCBhIGxpdHRsZS4NCg0KDQpJdCBzZWVtcyBsaWtlIG1vc3QgcGVvcGxlIGFncmVlIHRoYXQg bWFpbnRhaW5pbmcgc2lnbmF0dXJlIGNvbXBhdGliaWxpdHkgaXMgYSBub24tZ29hbDsgSSBhZ3Jl ZSB0aGF0IGlzIHRoZSBvbmx5IHdheSBmb3IgdXMgdG8gaGF2ZSBhIGNoYW5jZSBhdCBzdWNjZXNz Lg0KDQoNCkkgdGhpbmsgd2UncmUgYWxzbyBsaWtlbHkgdG8gZ2V0IGFncmVlbWVudCB0aGF0IHdl IHNob3VsZCBkbyBvdXIgYmVzdCB0byB1c2UgQ0JPUiBpZGlvbXMgaW4gQ09TRSAoc3VjaCBhcyBt aXhlZC10eXBlIGtleXMgZm9yIG1hcHMpIG9uY2UgdGhleSBhcmUgZXhwbGFpbmVkIHRvIHRoZSBn cm91cCBpbiBlbm91Z2ggZGV0YWlsIGZvciBldmVyeW9uZSB0byB1bmRlcnN0YW5kIHRoZSBwcm9w b3NhbHMuDQoNCkZpbmFsbHksIEkgdGhpbmsgb25lIG9mIHRoZSByZWFzb25zIHBlb3BsZSBhcmUg aW50ZXJlc3RlZCBpbiBDT1NFIGlzIGEgY2hhbmNlIHRvIG9wdGltaXplIGZvciBhIGRpZmZlcmVu dCBzZXQgb2YgdXNlIGNhc2VzIHRoYW4gd2UgaGFkIGZvciBKT1NFLg0KDQoNClRoZSBtYWluIHNv dXJjZSBvZiBkaXNhZ3JlZW1lbnQgc2VlbXMgdG8gYmUgd2hhdCB3ZSB3b3VsZCBjaGFuZ2UgaW4g Q09TRSBvZiB0aGUgdGhpbmdzIHNvbWUgbWlnaHQgaGF2ZSB3YW50ZWQgdG8gZG9uZSBkaWZmZXJl bnRseSBpbiBKT1NFLiAgSSdtIHN5bXBhdGhldGljIHRvIGJvdGggdGhlIGdyb3VwIHRoYXQgd2Fu dHMgdG8gY3Jhbmsgc29tZXRoaW5nIG91dCBxdWlja2x5IHdpdGhvdXQgcmUtbGl0aWdhdGluZyB0 aGUgcGFzdCwgYXMgd2VsbCBhcyB0byB0aGUgZ3JvdXAgdGhhdCB3YW50cyB0byByZS1vcHRpbWl6 ZSBhcyBtYW55IHRoaW5ncyBhcyBwb3NzaWJsZSBnaXZlbiB0aGUgcmVtb3ZhbCBvZiB0aGUgcHJl c3N1cmUgb2YgZXhpc3RpbmcgY29kZWJhc2VzIHRoYXQgd2UgaGFkIHdpdGggSk9TRS4NCg0KDQpB biBhcHByb2FjaCB0aGF0IG1pZ2h0IHdvcmsgZm9yIHRoaXMgd291bGQgYmUgdG8gc2V0IGEgYmFy IGZvciBjaGFuZ2VzIGFsb25nIHRoZSBsaW5lcyBvZiAic2lnbmlmaWNhbnQgaW1wcm92ZW1lbnQg aW4gc2VjdXJpdHksIHBlcmZvcm1hbmNlICh3aXJlIHNpemUsIGNvZGUgc2l6ZSwgQ1BVLCBwb3dl ciwgZXRjLiksIG9yIGRlcGxveWFiaWxpdHkiIHdvdWxkIGJlIHJlcXVpcmVkIHRvIGp1c3RpZnkg YSBjaGFuZ2UuICBUbyBzZWUgaWYgdGhhdCBhcHByb2FjaCB3b3VsZCB3b3JrLCBpdCB3b3VsZCBi ZSBuaWNlIHRvIHNlZSBhIGxpc3Qgb2YgdGhpbmdzIHRoYXQgZm9sa3Mgd291bGQgd2FudCB0byBj aGFuZ2UsIGFuZCB0byBnZXQgZWFybHkgYWdyZWVtZW50IG9uIGEgY291cGxlIG9mIHRob3NlIGNo YW5nZXMgYXMgYmVpbmcgYWJvdmUgdGhlIGJhciB0aGF0IHdlIHNldCwgc28gdGhhdCB3ZSBoYXZl IHNvbWUgcHJlY2VkZW50IHRvIHJlYXNvbiBmcm9tLg0KDQoNClRvIHRoYXQgZW5kLCBJIHByb3Bv c2UgdGhhdCB0aG9zZSB0aGF0IHdhbnQgY2hhbmdlcyBwcm9kdWNlIGEgbGlzdCwgcGVyaGFwcyBh bm5vdGF0ZWQgd2l0aCB3aGV0aGVyIHRoZSBjaGFuZ2UgaXMgc2VlbiBhcyBpbXBlcmF0aXZlIG9y IG1lcmVseSBuaWNlLXRvLWhhdmUuICBUaGUgZm9sa3MgdGhhdCB3YW50IGEgcXVpY2sgb3V0Y29t ZSB3b3VsZCB0aGVuIHNlbGVjdCBzZXZlcmFsIGNoYW5nZXMgdGhleSBzZWUgYXMgYmVpbmcgZGVm aW5pdGVseSBhYm92ZSB0aGUgbGluZS4gIE15IGhvcGUgaXMgdGhhdCB0aGlzIGV4ZXJjaXNlIHdv dWxkIGJ1aWxkIHRydXN0IHRoYXQgd2UgYWxsIHdhbnQgc29tZXRoaW5nIHNpbWlsYXI6IGEgaGln aCBxdWFsaXR5IHByb3RvY29sIHN0YW5kYXJkaXplZCBpbiBhcyBzaG9ydCBhIHRpbWUgYXMgcG9z c2libGUuDQoNCg0KLS0NCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0 Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2pvc2UNCg0K --_000_D57BD7B602DB45D1B497573AB32C7468ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVk aXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsgbWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IiBjbGFzcz0iIj5UaGFua3MgZm9yIHN0YXJ0aW5nIHRoZSBk aXNjdXNzaW9uIEpvZSw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyIgY2xhc3M9IiI+ SSBzdHJvbmdseSBzdXBwb3J0IHRoZSB3b3JrIG9uIENPU0UuIE15IHZpZXcgaXMgdGhhdCB0byBi ZSByZWxldmFudCBmb3IgdGhlIElvVCB1c2UgY2FzZXMsIGFuZCBpbiBwYXJ0aWN1bGFyIGRldmlj ZXMgdXNpbmcgSUVFRSZuYnNwOzgwMi4xNS40LCBDT1NFIG11c3QgYmUgaGlnaGx5IG9wdGltaXpl ZCBjb21wYXJlZCB0byBKT1NFOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkluIG91ciBk cmFmdCBvbiBlbmQtdG8tZW5kIHNlY3VyaXR5IGZvciBJb1QgKGRyYWZ0LXNlbGFuZGVyLWFjZS1v YmplY3Qtc2VjdXJpdHktMDEpIHdlcmUgd2UgcGxhbiB0byB1c2UgQ09TRSwgb3VyJm5ic3A7bWVh c3VyZW1lbnRzIHNob3cgdGhhdCB1c2FnZSBvZiBKV1MgY2FuIGVhc2lseSBhZGQgMTM1IGJ5dGVz LCBmaWxsaW5nIHVwIG1vcmUgdGhhbiBhbiBlbnRpcmUgSUVFRSA4MDIuMTUuNCBmcmFtZS4gJm5i c3A7Q09TRSZuYnNwOyhhY2NvcmRpbmcgdG8gZHJhZnQtYm9ybWFubi1qb3NlLWNvc2UtMDApDQog d291bGQgYmUgZmFyIGJldHRlciBidXQgc3RpbGwgdXNlIDcwIGJ5dGVzLiBNeSB2aWV3IGlzIHRo YXQgdGhpcyBpcyBzdGlsbCB0byBsYXJnZSBmb3IgSUVFRSZuYnNwOzgwMi4xNS40IGFuZCB0aGF0 IHRoZSBmb2xsb3dpbmcgdGhyZWUgb3B0aW1pemF0aW9ucyBhcmUgbmVlZGVkIChpbXBlcmF0aXZl KTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotIENhcnN0ZW4gaGFzIGFscmVhZHkgc3Vn Z2VzdGVkIHJlcGxhY2luZyBjZXJ0YWluIG1lbWJlciBuYW1lcyAoJnF1b3Q7YWxnJnF1b3Q7Li4u KSB3aXRoIHByZWRlZmluZWQgbnVtYmVycy4gSSBzdHJvbmdseSBzdXBwb3J0IHRoaXMuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLSBFdmVuIHdpdGhvdXQgYmFzZTY0IGVuY29kaW5nLCB0 aGUgSldTIE1BQ3MgdGFrZXMgMzIgYnl0ZXMuIElvVCBkZXZpY2VzIHVzaW5nIERUTFMgdXNlIDgg Ynl0ZSBNQUNzLiBJIHN0cm9uZ2x5IHRoaW5rIElvVCZuYnNwO3NwZWNpZmljIGFsZ29yaXRobXMg d2l0aCB0cnVuY2F0ZWQgTUFDcyAobWF5YmUgMTYgYW5kIDggYnl0ZXMpIGFyZSBuZWNlc3Nhcnku PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLSBUaGUgSldFIEluaXRpYWxpemF0aW9uIFZl Y3RvciB0YWtlcyB1cCAxMiBieXRlcywgSW9UIGRldmljZXMgd291bGQgbGlrZWx5IHdhbnQgdG8g c2F2ZSBhIG5vbmNlIHRvZ2V0aGVyIHdpdGggdGhlIGtleSB0byBzYXZlJm5ic3A7YmFuZHdpZHRo IChhbmQgdGhlcmVmb3JlIGJhdHRlcnkpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldp dGggdGhlc2UgY2hhbmdlcywgdGhlIG92ZXJoZWFkIG9mIENPU0UgKGJvdGggQ1dTIGFuZCBDV0Up IGNvdWxkIGJlIGJlbG93IDMwIGJ5dGVzLiBJIHRoaW5rIHRoaXMgbm90IG9ubHkgZGVzaXJhYmxl LCBidXQmbmJzcDthbHNvIG5lY2Vzc2FyeS4gVGhlIGFsZ29yaXRobSBhbmQgSVYgb3B0aW1pemF0 aW9ucyBjb3VsZCBiZSBkb25lIGluIHBhcmFsbGVsIHRvIHRoZSBDT1NFIGVuY29kaW5nIHdvcmsu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2hlZXJzLDxiciBjbGFzcz0iIj4NCkpvaG48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIi PuKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlDwvc3Bhbj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPkpvaG4gTWF0dHNzb24NCjxkaXYgY2xhc3M9IiI+ RXJpY3Nzb24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvciZuYnNwOzxiciBjbGFzcz0iIj4NClNl bmlvciBSZXNlYXJjaGVyLCBTZWN1cml0eTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDA2IE1hciAyMDE1LCBhdCAyMDoxOSwgSm9lIEhpbGRl YnJhbmQgKGpoaWxkZWJyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoaWxkZWJyQGNpc2NvLmNvbSIg Y2xhc3M9IiI+amhpbGRlYnJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5JbiB0YWxraW5n IHdpdGggc2V2ZXJhbCBmb2xrcyBhYm91dCBDT1NFLCBpdCBhcHBlYXJzIHRoYXQgdGhlcmUgYXJl IGRpZmZlcmluZyB2aWV3cyBvbiBob3cgbXVjaCB0byBjaGFuZ2UgaW4gdGhlIEpPU0UvQ09TRSB0 cmFuc2xhdGlvbi4gJm5ic3A7SSB3b3VsZCBsaWtlIHRvIGV4cGxvcmUgdGhlIHBvaW50cyBvZiBh Z3JlZW1lbnQgYW5kIGRpc2FncmVlbWVudCBhIGxpdHRsZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCBzZWVtcyBsaWtlIG1vc3QgcGVvcGxlIGFncmVlIHRo YXQgbWFpbnRhaW5pbmcgc2lnbmF0dXJlIGNvbXBhdGliaWxpdHkgaXMgYSBub24tZ29hbDsgSSBh Z3JlZSB0aGF0IGlzIHRoZSBvbmx5IHdheSBmb3IgdXMgdG8gaGF2ZSBhIGNoYW5jZSBhdCBzdWNj ZXNzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgdGhpbmsg d2UncmUgYWxzbyBsaWtlbHkgdG8gZ2V0IGFncmVlbWVudCB0aGF0IHdlIHNob3VsZCBkbyBvdXIg YmVzdCB0byB1c2UgQ0JPUiBpZGlvbXMgaW4gQ09TRSAoc3VjaCBhcyBtaXhlZC10eXBlIGtleXMg Zm9yIG1hcHMpIG9uY2UgdGhleSBhcmUgZXhwbGFpbmVkIHRvIHRoZSBncm91cCBpbiBlbm91Z2gg ZGV0YWlsIGZvciBldmVyeW9uZSB0byB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbHMuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KRmluYWxseSwgSSB0aGluayBvbmUgb2YgdGhlIHJlYXNvbnMg cGVvcGxlIGFyZSBpbnRlcmVzdGVkIGluIENPU0UgaXMgYSBjaGFuY2UgdG8gb3B0aW1pemUgZm9y IGEgZGlmZmVyZW50IHNldCBvZiB1c2UgY2FzZXMgdGhhbiB3ZSBoYWQgZm9yIEpPU0UuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIG1haW4gc291cmNlIG9m IGRpc2FncmVlbWVudCBzZWVtcyB0byBiZSB3aGF0IHdlIHdvdWxkIGNoYW5nZSBpbiBDT1NFIG9m IHRoZSB0aGluZ3Mgc29tZSBtaWdodCBoYXZlIHdhbnRlZCB0byBkb25lIGRpZmZlcmVudGx5IGlu IEpPU0UuICZuYnNwO0knbSBzeW1wYXRoZXRpYyB0byBib3RoIHRoZSBncm91cCB0aGF0IHdhbnRz IHRvIGNyYW5rIHNvbWV0aGluZyBvdXQgcXVpY2tseSB3aXRob3V0IHJlLWxpdGlnYXRpbmcgdGhl IHBhc3QsIGFzIHdlbGwgYXMNCiB0byB0aGUgZ3JvdXAgdGhhdCB3YW50cyB0byByZS1vcHRpbWl6 ZSBhcyBtYW55IHRoaW5ncyBhcyBwb3NzaWJsZSBnaXZlbiB0aGUgcmVtb3ZhbCBvZiB0aGUgcHJl c3N1cmUgb2YgZXhpc3RpbmcgY29kZWJhc2VzIHRoYXQgd2UgaGFkIHdpdGggSk9TRS48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbiBhcHByb2FjaCB0aGF0IG1p Z2h0IHdvcmsgZm9yIHRoaXMgd291bGQgYmUgdG8gc2V0IGEgYmFyIGZvciBjaGFuZ2VzIGFsb25n IHRoZSBsaW5lcyBvZiAmcXVvdDtzaWduaWZpY2FudCBpbXByb3ZlbWVudCBpbiBzZWN1cml0eSwg cGVyZm9ybWFuY2UgKHdpcmUgc2l6ZSwgY29kZSBzaXplLCBDUFUsIHBvd2VyLCBldGMuKSwgb3Ig ZGVwbG95YWJpbGl0eSZxdW90OyB3b3VsZCBiZSByZXF1aXJlZCB0byBqdXN0aWZ5IGEgY2hhbmdl LiAmbmJzcDtUbyBzZWUgaWYgdGhhdCBhcHByb2FjaA0KIHdvdWxkIHdvcmssIGl0IHdvdWxkIGJl IG5pY2UgdG8gc2VlIGEgbGlzdCBvZiB0aGluZ3MgdGhhdCBmb2xrcyB3b3VsZCB3YW50IHRvIGNo YW5nZSwgYW5kIHRvIGdldCBlYXJseSBhZ3JlZW1lbnQgb24gYSBjb3VwbGUgb2YgdGhvc2UgY2hh bmdlcyBhcyBiZWluZyBhYm92ZSB0aGUgYmFyIHRoYXQgd2Ugc2V0LCBzbyB0aGF0IHdlIGhhdmUg c29tZSBwcmVjZWRlbnQgdG8gcmVhc29uIGZyb20uDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpUbyB0aGF0IGVuZCwgSSBwcm9wb3NlIHRoYXQgdGhvc2UgdGhh dCB3YW50IGNoYW5nZXMgcHJvZHVjZSBhIGxpc3QsIHBlcmhhcHMgYW5ub3RhdGVkIHdpdGggd2hl dGhlciB0aGUgY2hhbmdlIGlzIHNlZW4gYXMgaW1wZXJhdGl2ZSBvciBtZXJlbHkgbmljZS10by1o YXZlLiAmbmJzcDtUaGUgZm9sa3MgdGhhdCB3YW50IGEgcXVpY2sgb3V0Y29tZSB3b3VsZCB0aGVu IHNlbGVjdCBzZXZlcmFsIGNoYW5nZXMgdGhleSBzZWUgYXMgYmVpbmcgZGVmaW5pdGVseSBhYm92 ZQ0KIHRoZSBsaW5lLiAmbmJzcDtNeSBob3BlIGlzIHRoYXQgdGhpcyBleGVyY2lzZSB3b3VsZCBi dWlsZCB0cnVzdCB0aGF0IHdlIGFsbCB3YW50IHNvbWV0aGluZyBzaW1pbGFyOiBhIGhpZ2ggcXVh bGl0eSBwcm90b2NvbCBzdGFuZGFyZGl6ZWQgaW4gYXMgc2hvcnQgYSB0aW1lIGFzIHBvc3NpYmxl LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tIDxiciBjbGFz cz0iIj4NCkpvZSBIaWxkZWJyYW5kPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpqb3NlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiBjbGFzcz0iIj5qb3NlQGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v am9zZTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D57BD7B602DB45D1B497573AB32C7468ericssoncom_-- From nobody Mon Mar 23 00:36:36 2015 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 398B71A8935 for ; Mon, 23 Mar 2015 00:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umMBxAqvHDdD for ; Mon, 23 Mar 2015 00:36:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2D21A8934 for ; Mon, 23 Mar 2015 00:36:30 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.125.14; Mon, 23 Mar 2015 07:36:12 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Mon, 23 Mar 2015 07:36:12 +0000 From: Mike Jones To: Stephen Farrell Thread-Topic: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch Thread-Index: AdBlO/J/G3Fobl38T+ib6QLqsv0XzA== Date: Mon, 23 Mar 2015 07:36:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.52.104] authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(52314003)(52604005)(51444003)(479174004)(13464003)(24454002)(51414003)(51704005)(86612001)(99286002)(19580395003)(2900100001)(86362001)(575784001)(19300405004)(19273905006)(66066001)(77156002)(62966003)(87936001)(2656002)(92566002)(5890100001)(19580405001)(110136001)(50986999)(54356999)(40100003)(46102003)(15975445007)(102836002)(33656002)(15395725005)(76576001)(77096005)(74316001)(122556002)(1720100001)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 05245CA661 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2015 07:36:11.2760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: Nat Sakimura , "jose@ietf.org" Subject: Re: [jose] My quest to learn how to create SubjectPublicKeyInfo values from scratch 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, 23 Mar 2015 07:36:35 -0000 SGkgU3RlcGhlbiwNCg0KVGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcHV0IHRvZ2V0aGVy IHRoZSByZXNvdXJjZXMgY2l0ZWQgYmVsb3cuICBJIHNwZW50IGFib3V0IDkwIG1pbnV0ZXMgbG9v a2luZyBhdCBhbGwgb2YgdGhlbSBvbiB0aGUgcGxhbmUgdG8gRGFsbGFzIGFuZCBwcm9iYWJseSBh bm90aGVyIDYwIG1pbnV0ZXMgYWZ0ZXIgYXJyaXZpbmcuICBIZXJlJ3MgbXkgdGhvdWdodHMgb24g d2hpY2ggb2YgdGhlbSB3b3VsZCBiZSB1c2VmdWwgdG8gdGhlIHRhc2sgb2YgY3JlYXRpbmcgU3Vi amVjdFB1YmxpY0tleUluZm8gdmFsdWVzIGZyb20gc2NyYXRjaCBhbmQgd2hhdCBnYXBzIHJlbWFp bi4NCg0KWzBdIGlzIGEgUE9TSVggc2hlbGwgcHJvZ3JhbSB0aGF0IGdlbmVyYXRlcyBTUEtJIEZp bmdlcnByaW50cyBmcm9tIFBFTS1lbmNvZGVkIGNlcnRpZmljYXRlcy4gVGhpcyBpc24ndCBhcHBs aWNhYmxlLCBzaW5jZSBpZiBhbGwgeW91IGhhdmUgaXMgYSBKV0ssIHlvdSBkb24ndCBoYXZlIGEg UEVNLWVuY29kZWQgY2VydGlmaWNhdGUuDQoNClsxXSBhbHNvIGNvdW50cyBvbiBhbHJlYWR5IGhh dmluZyB0aGUgQVNOLjEgcmVwcmVzZW50YXRpb24gaW4gaGFuZCwgc28gaXNuJ3QgYXBwbGljYWJs ZS4gIEknbGwgbm90ZSB0aGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjgwI3Nl Y3Rpb24tNC4yLjEuMiByZWNvbW1lbmRzIHR3byBkaWZmZXJlbnQga2V5IGlkZW50aWZpZXIgYWxn b3JpdGhtcywgc28gd2UncmUgYWxyZWFkeSBpbiBhIHNpdHVhdGlvbiB3aGVyZSBpbXBvcnRhbnQg UkZDcyBkZWZpbmUgbW9yZSB0aGFuIG9uZSByZWNvbW1lbmRlZCB3YXkgdG8gZ2VuZXJhdGUgYSBL ZXkgSUQgdmFsdWUuICAoQW5kIHRoYXQncyB3aXRob3V0IHRha2luZyBpbnRvIGFjY291bnQgdGhh dCBkaWZmZXJlbnQgaGFzaCBhbGdvcml0aG1zIGFuZCB0cnVuY2F0ZWQgaGFzaGVzIG1pZ2h0IGJl IHVzZWQuKQ0KDQpbMl0gaXMgYmV0dGVyLCBpbiB0aGF0IGl0IHByb3ZpZGVzIGFjdGlvbmFibGUg aW5zdHJ1Y3Rpb25zIGZvciBjcmVhdGluZyBTdWJqZWN0UHVibGljS2V5SW5mbyB2YWx1ZXMgc3Vj aCBhcyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzI3OSNzZWN0aW9uLTIuMy4xLCBi dXQgdGhleSdyZSBhY3Rpb25hYmxlIG9ubHkgaWYgeW91IGhhdmUgYW4gQVNOLjEgZW5jb2RlciBh dmFpbGFibGUuICBIYWxmIHdheSB0aGVyZS4NCg0KWzNdIGlzIGFsc28gaGFsZi13YXkgdGhlcmUs IHNpbmNlIGl0J3MgYWN0aW9uYWJsZSAqaWYqIHlvdSBoYXZlIGFuIEFTTi4xIGVuY29kZXIuDQoN Cls0XSBNb3N0IG9mIHRoZSBmaXJzdCBwYWdlIG9mIHNlYXJjaCByZXN1bHRzIGhlcmUgZG9uJ3Qg cHJvdmlkZSBhY3Rpb25hYmxlIGluZm9ybWF0aW9uIGZvciB0aGUgdGFzay4gIFRoZSBleGNlcHRp b24gaXMgdGhlIEJvdW5jeUNhc3RsZSBwYWdlIHdpdGggY29uc3RydWN0b3IgZnVuY3Rpb25zLCBz dWNoIGFzICJTdWJqZWN0UHVibGljS2V5SW5mbyhBbGdvcml0aG1JZGVudGlmaWVyIGFsZ0lkLCBi eXRlW10gcHVibGljS2V5KSIuICBBZ2FpbiB0aGlzIGlzbid0IGZyb20gc2NyYXRjaCwgYnV0IGlm IHlvdSBoYXZlIGl0LCB5b3UgY291bGQgcHJvYmFibHkgd29yayBvdXQgaG93IHRvIGNvbnZlcnQg YSBKV0sgdG8gYSBwdWJsaWNLZXkgYnl0ZSBhcnJheSBhbmQgZ28gZnJvbSB0aGVyZSAob25jZSB5 b3UgYWxzbyBmaW5kICJuZXcgUlNBUHVibGljS2V5U3RydWN0dXJlbW9kdWx1cywgZXhwb25lbnQp LmdldERFUk9iamVjdCgpKSIgdG8gZG8gdGhlIEFTTi4xIGVuY29kaW5nIGZvciB5b3UuKSAgQWxs IHRoZXNlIHNlYXJjaCByZXN1bHRzIHdpdGggYWN0aW9uYWJsZSBjb250ZW50IGNvdW50ZWQgb24g aGF2aW5nIGFuIEFTTi4xIGxpYnJhcnkuDQoNCls1XSB3YXMgc2ltaWxhciB0byBbNF0sIGV4Y2Vw dCB0aGUgcGFydGlhbGx5LWFjdGlvbmFibGUgaW5mb3JtYXRpb24gZm91bmQgYWx3YXlzIGNvdW50 ZWQgb24gaGF2aW5nIG9wZW5zc2wgYXZhaWxhYmxlLg0KDQpbNl0gVGhlIGZpcnN0IDQgcGFnZXMg ZGlzcGxheWVkIHJlcXVpcmVkIG9wZW5zc2wsIHRoZSBuZXh0IDQgd2VyZSBrZXkgcGlubmluZyBy ZWZlcmVuY2VzLCB0aGUgOXRoIHJlcXVpcmVkIG9wZW5zc2wsIGFuZCB0aGUgMTB0aCB3YXMgWE1M RFNJRyENCg0KWzddIFRoaXMgd2FzIHRoZSBmaXJzdCBvbmUgdGhhdCByZWFsbHkgZGlkIHRoZSBq b2IsIGZvciB0aGUgY2FzZXMgb2YgMTAyNCBhbmQgMjA0OCBiaXQgUlNBIGtleXMgd2l0aCB0aGUg aGlnaCBiaXQgc2V0IGFuZCBhbiBleHBvbmVudCB2YWx1ZSBvZiA2NTUzNy4NCg0KWzhdIGFsc28g ZG9lc24ndCByZXF1aXJlIEFTTi4xIG9yIFguNTA5IGJ1dCBsaWtlIFs3XSBpcyBsaW1pdGVkIHRv IFJTQSBrZXlzLg0KDQpbOV0gaW1wbGVtZW50cyBbMTBdIGJ1dCBJIGNvdWxkbid0IGZpbmQgdGhl IHN0cmluZyBTdWJqZWN0UHVibGljS2V5SW5mbyBpbmZvIGF0IGxlYXN0IGluIHRoZSBQSFAgYW5k IFB5dGhvbiBjb2RlIEkgYnJvd3NlZCwgbm9yIGNvdWxkIEkgZmluZCBjb2RlIGxpa2UgdGhhdCBp biBbN10gdGhhdCByZWFsbHkgZG9lcyB0aGUgam9iLiAgSSBjb3VsZCBoYXZlIG1pc3NlZCBpdC4N Cg0KSW4gc3VtbWFyeSwgSSB0aGluayB0aGUgY29yZSB0aGluZyB3ZSdyZSB0YWxraW5nIGFib3V0 IGlzIHJlYWxseSB0aGlzIGFzc2VydGlvbiBpbiBbMTBdOiAgImZvcm1hdHRpbmcgYW55IHB1Ymxp YyBrZXkgYXMgYSBTdWJqZWN0UHVibGljS2V5SW5mbyBpcyByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9y d2FyZCBhbmQgd2VsbCBzdXBwb3J0ZWQgYnkgbGlicmFyaWVzIi4gIFRoZSAid2VsbCBzdXBwb3J0 ZWQgYnkgbGlicmFyaWVzIiBpcyByZWZ1dGVkIGZvciBzb21lIGNvbW1vbiBkZXZlbG9wbWVudCBl bnZpcm9ubWVudHMgYnkgdGhlIGRhdGEgaW4gTmF0J3MgbWVzc2FnZSBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0OTU4Lmh0bWwgLSBlc3BlY2lh bGx5IHRoYXQgYXQgcHJlc2VudCBTUEtJIHN1cHBvcnQgaW4gUEhQIGRlcGxveW1lbnRzIHN0YW5k cyBhdCBhYm91dCAwLjclLiAgU28gdGhhdCBsZWF2ZXMgdXMgd2l0aCB0aGUgInJlbGF0aXZlbHkg c3RyYWlnaHRmb3J3YXJkIiBhc3NlcnRpb24uDQoNClllcywgdGhlIGNvZGUgaW4gWzddIGFuZCBS aWNoYXJkJ3Mgc2ltaWxhciBjb2RlIG1lZXQgdGhlICJyZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2Fy ZCIgdGVzdCBmb3IgdGhlIGNhc2Ugb2YgYSBzdWJzZXQgb2YgUlNBIGtleXMuICBJdCBkb2Vzbid0 IHN1cHBvcnQgb3RoZXIga2V5IHR5cGVzIG9yIHNvbWUgb3RoZXIgUlNBIGtleXMuICBUaGF0J3Mg dGhlIHByaW1hcnkgZ2FwIHJlbWFpbmluZyB0aGF0IEkgc2VlIGluIHdoYXQncyBjaXRlZCBhYm92 ZS4NCg0KRG9uJ3QgZ2V0IG1lIHdyb25nIC0gSSB0aGluayB0aGF0IGhhc2hlcyBvZiBTUEtJIHZh bHVlcyBhcmUgYSBmaW5lIHRoaW5nIGZvciBtYW55IHVzZXMgY2FzZXMuICBJIGFsc28gdGhpbmsg aXQncyBub3QgdGhlIG9ubHkgcmVhc29uYWJsZSBoYXNoIGlucHV0IHRvIGNvbnNpZGVyIHVzaW5n LiAgSGVjaywgWzFdLCB3aGljaCB5b3Ugd2VyZSBhbiBhdXRob3Igb2YsIHJlY29tbWVuZHMgInR3 byBjb21tb24gbWV0aG9kcyIuICBCdXQgZGVzcGl0ZSBoYXZpbmcgcHV0IGEgZmV3IG1vcmUgaG91 cnMgaW50byB0aGlzIGFuZCB0cmllZCB0byBnZW51aW5lbHkgY29uc2lkZXIgYWxsIHRoZSBjb250 ZW50IGluIHlvdXIgcmVmZXJlbmNlcywgSSBzdGlsbCBoYXZlbid0IHNlZW4gYW55IHBsYWNlIHRo YXQgcHJvdmlkZXMgYW4gYWN0aW9uYWJsZSBkZXNjcmlwdGlvbiBvZiBob3cgdG8gY3JlYXRlIFN1 YmplY3RQdWJsaWNLZXlJbmZvIHZhbHVlcyBmcm9tIHNjcmF0Y2ggZm9yIGV2ZW4gYWxsIHRoZSBj b21tb24gUlNBIGFuZCBFQyBrZXkgcmVwcmVzZW50YXRpb25zIGluIHVzZSB0b2RheS4gIChJJ2xs IHJlcGVhdCB0aGF0IEkgdGhpbmsgdGhhdCB3cml0aW5nIHRoaXMgZG93biBpbiBvbmNlIHBsYWNl IGFzIGEgc3BlYyB3b3VsZCBiZSBhIHZhbHVhYmxlIGNvbnRyaWJ1dGlvbiwgaWYgYW55b25lIHdh bnRzIHRvIHRha2UgdGhpcyBvbi4gIFRoZSBsYWNrIG9mIHRoaXMgc2ltcGxlIHNwZWMgaXMgdGhl IHJlYWwgZ2FwIGluIG1vcmUgZWFzaWx5IGVuYWJsaW5nIHRoaXMgb3B0aW9uLCBJTU8uKQ0KDQpZ b3UgY2FuIGRpc2xpa2UgaXQgYmVjYXVzZSBpdCB1c2VzIGEgZGlmZmVyZW50IGhhc2ggaW5wdXQs IGJ1dCBhdCBsZWFzdCBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQgZG9lcyB3cml0ZSBk b3duIGhvdyB0byBlYXNpbHkgZG8gdGhpcyBmb3IgYWxsIGN1cnJlbnRseSBkZWZpbmVkIEpXS3Mg aW4gb25lIHBsYWNlLiAgTGlrZSBoYXNoaW5nIFNQS0kgdmFsdWVzLCBpdCdzIGFsc28gYSBmaW5l IHRoaW5nIGZvciBtYW55IHVzZSBjYXNlcy4NCg0KSXQncyBub3QgIkkgd2FudCB0byBkbyB3aGF0 IEkgdGhvdWdodCBvZiBmaXJzdC4iICBJdCdzICJJIHdhbnQgdG8gZ2l2ZSBkZXZlbG9wZXJzIHNl bWFudGljYWxseSBzb3VuZCBjaG9pY2VzIHRoZXkgd2lsbCBncmF2aXRhdGUgdG8gYW5kIGFjdHVh bGx5IGJ1aWxkLiIgIFRoaXMgaXMgdGhlIHNhbWUgcmVhc29uIHdlIGRpZCBKT1NFIHdoZW4gd2Ug YWxyZWFkeSBoYWQgQ01TIGFuZCBYTUxEU0lHLg0KDQpJJ2xsIGNsb3NlIGJ5IGFncmVlaW5nIHdp dGggYSBzdGF0ZW1lbnQgbWFkZSBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTIw I3NlY3Rpb24tMiAtICJIYXNoZXMgYXJlIHdoYXQgY291bnQiLiAgVGhpcyBpcyB0aGUgInNlbWFu dGljYWxseSBzb3VuZCIgdGhpbmcgSSB3YXMgcmVmZXJyaW5nIHRvIGFib3ZlLiAgTmF0IGFuZCBJ IGFuZCBzZXZlcmFsIG90aGVycyBhcmUgdHJ5aW5nIHRvIGluY3JlYXNlIHRoZSB1c2Ugb2YgaGFz aC1iYXNlZCBrZXkgSURzIGJ5IHB1dHRpbmcgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50 IG91dCB0aGVyZSBhcyBhbiBlYXN5IG9wdGlvbiBmb3IgZGV2ZWxvcGVycyB3aG8gYXJlIGNvbWZv cnRhYmxlIHdpdGggSlNPTiBhbmQgd2hvIGFyZSBhbHJlYWR5IHVzaW5nIHRoZSBKV0sgSlNPTi1i YXNlZCBrZXkgcmVwcmVzZW50YXRpb24uICBUaGUgYmVuZWZpdCB0byBiZSBnYWluZWQgYnkgbW9y ZSBkZXZlbG9wZXJzIGhhdmluZyB0aGUgcGVyY2VwdGlvbiB0aGF0IGl0J3MgZWFzeSB0byB1c2Ug aGFzaC1iYXNlZCBrZXkgSURzIGlzIGdyZWF0ZXIgdGhhbiB0aGUgYmVuZWZpdCBvZiB0cnlpbmcg dG8gbWFrZSBldmVyeW9uZSBkbyBpdCB0aGUgc2FtZSB3YXksIGFuZCBoYXZlIHNvbWUgY2hvb3Nl IG5vdCB0byBkbyBpdCBhdCBhbGwsIGJlY2F1c2UgcmlnaHQtb3Itd3JvbmcsIGl0IGp1c3Qgc2Vl bXMgdG9vIGhhcmQgdG8gdGhlbS4gIFBlcmNlcHRpb24gbWF0dGVycy4NCg0KQW55d2F5LCBJIHJl YWxseSBoYXZlIGVuam95ZWQgdGhpcyBsZWFybmluZyBleGVyY2lzZSBhbmQgYXBwcmVjaWF0ZSBl dmVyeW9uZSB3aG8gcHJvdmlkZWQgZGF0YSBpbiByZXNwb25zZSB0byB0aGlzIHRocmVhZC4gIEdv b2Qgc3R1ZmYuDQoNCkknbGwgbG9vayBmb3J3YXJkIHRvIHNlZWluZyBtYW55IG9mIHlvdSBpbiBu b3QgdG9vIG1hbnkgaG91cnMuICBIb3BlZnVsbHkgd2UgY2FuIGNvbnRpbnVlIHRoaXMgZGlzY3Vz c2lvbiBpbiBwZXJzb24uICBJIGtub3cgdGhhdCBJJ20gbGVhcm5pbmcgdGhpbmdzLCBhbnl3YXks IHdoaWNoIGlzIGFsd2F5cyBnb29kLg0KDQoJCQkJQ2hlZXJzLA0KCQkJCS0tIE1pa2UNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMSwgMjAx NSA3OjQyIEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6IGpvc2VAaWV0Zi5vcmc7IE5hdCBTYWtpbXVy YQ0KU3ViamVjdDogUmU6IFtqb3NlXSBNeSBxdWVzdCB0byBsZWFybiBob3cgdG8gY3JlYXRlIFN1 YmplY3RQdWJsaWNLZXlJbmZvIHZhbHVlcyBmcm9tIHNjcmF0Y2gNCg0KDQpIaSBNaWtlLA0KDQpT aW1wbGVzdCBpcyBbMF0gYXMgdXNlZCBpbiBwdWJsaWMga2V5IHBpbm5pbmcgZm9yIHdlYiBzZXJ2 ZXJzLiAoVGhhdCBzaG91bGQgcG9wIG91dCBhcyBhbiBSRkMgYW55IHRpbWUgbm93DQpidHcuKSBJ IHJlYWxseSBkb3VidCBhbnkgY2xhaW0gdGhhdCB0aGF0IHRoZXJlJ3Mgc29tZSBtYWdpYyBuZWVk ZWQgdG8gbWFrZSB0aGlzIHdvcmsgYXMgdGhvc2UgdHdvIGxpbmVzIG9mIHNjcmlwdCBzaG93Lg0K DQpCdXQgZ2l2ZW4geW91IHdhbnRlZCB0byBsZWFybiwgYW5kIG5vdCBqdXN0IGdldCBzdHVmZiBk b25lLCBpdCdzIGEgcGl0eSB5b3UgZGlkbid0IHN0YXJ0IGZyb20gUkZDNTI4MCwgWzFdIGFuZCBS RkNzIDMyNzkgWzJdIGFuZCA1NDgwLiBbM10gTG90cyBvZiBwYWdlcyB0aGVyZSBpdCdzIHRydWUs IGJ1dCBhY3R1YWxseSBvbmx5IHZlcnkgZmV3IG5lZWQgdG8gYmUgcmVhZCBpZiBvbmUgb25seSBj YXJlcyBhYm91dCBTUEtJLg0KDQpPciwgbWF5YmUganVzdCBzZWFyY2ggZm9yIHRoZSB0aGluZyB5 b3UncmUgYWZ0ZXIgWzRdIGFuZCB5b3UnbGwgc2VlIGEgYnVuY2ggb2YgZmluZSBpbmZvcm1hdGlv biwgaW5jbHVkaW5nIGhvd3RvIGluIHRoZSBzZWFyY2ggaXMgZXZlbiBiZXR0ZXIuIFs1XSBPciwg aWYgeW91IHdhbnQgY29kZSBleGFtcGxlcyB0aG9zZSBhcmUgdGhlcmUgdG9vLiBbNl0NCg0KSSBo YXZlIHRvIGFkbWl0IHRvIGJlaW5nIG1vcmUgdGhhbiBzdXJwcmlzZWQgdGhhdCA1IGhvdXJzIG9m IGVmZm9ydCBkaWRuJ3QgdGhyb3cgdXAgYW55IG9mIHRoYXQuDQoNCkJ1dCBpZiwgYWZ0ZXIgdGhh dCwgeW91J3JlIHN0aWxsIGRlc3BlcmF0ZSwgdGhlbiB5b3UgY291bGQgbG9vayBhdCBjb2RlIEkg d3JvdGUsICh5b3Ugd291bGQgbmVlZCB0byBiZSBkZXNwZXJhdGUgdG8gdHJ5IGxlYXJuIGZyb20g bXkgY3JhcHB5IGNvZGU6LSkgWzddIGJlaW5nIGFuIGV4YW1wbGUgb2YgZG9pbmcgdGhpcyBmb3Ig UlNBIGluIGFib3V0IGEgZG96ZW4gSlMgTE9DIHdpdGhvdXQgYW55DQpBU04uMSBzdXBwb3J0IHVz aW5nIHRoZSBTdGFuZm9yZCBKUyBsaWJyYXJ5LCBhbmQgWzhdIGJlaW5nIG9wZW5zc2wgJ0MnIGNv ZGUuIE9yIHRoZSBuZXRpbmYgY29kZSBbOV0gaW1wbGVtZW50cw0KUkZDNjkyMCBbMTBdIHdpdGgg aW1wbGVtZW50YXRpb25zIG9mIHdoYXQgeW91IG5lZWQgaW4gb3RoZXIgbGFuZ3VhZ2VzIGxpa2Ug cGhwLCBweXRob24gYW5kIHJ1YnkgYXMgd2VsbCwgZXZlbiBjbG9qdXJlIGlmIHlvdSB3YW50IHRv IGJlIGZhbmN5Oi0pDQoNCkFueXdheSwgaXQgdG9vayBtZSB+MjAgbWludXRlcyB0byBmaW5kIGFs bCB0aG9zZSBhZ2FpbiwgYW5kIEkgZ3Vlc3MgaXQgbWlnaHQgdGFrZSBhIHdoaWxlIHRvIHJlYWQg ZXZlcnl0aGluZyBhbmQgZmluZCB0aGUgYml0cyB5b3Ugd2FudCwgYnV0IGZyb20gbXkgUE9WIGlm IHNvbWVvbmUgaXMgZGV2ZWxvcGluZyBhIGdlbmVyaWMgbGlicmFyeSBmb3IgdGhpcyBraW5kIG9m IHRoaW5nLCB0aGV5IHJlYWxseSBzaG91bGQgdW5kZXJzdGFuZCBhbGwgdGhpcyBhbHJlYWR5LCAo b3IgSSBkb24ndCB3YW50IHRoZW0gd3JpdGluZyBjcnlwdG8gY29kZSBvbiB3aGljaCBJIGRlcGVu ZCkgb3IgZWxzZSBpZiBhbGwgdGhhdCdzIG5lZWRlZCBhIHF1aWNrIGJpdCBvZiBjb2RlIGZvciBz YXkgYSBjbGllbnQgdGhhdCBlbWl0cyBhIGtleSBpZCwgdGhlbiB0aGUgc3RhY2tvdmVyZmxvdyBh cHByb2FjaCBvZiBjb3B5aW5nIGZyb20gZXhhbXBsZXMgc2hvdWxkIGJlIGZpbmUuDQoNCkVpdGhl ciB3YXksIHRoZXJlIGlzIElNTyBub3QgZXZlbiBhIHNjaW50aWxsYSBvZiBjcmVkaWJpbGl0eSB0 byBhbnkgY2xhaW0gdGhhdCB0aGlzIGlzIHN1cGVyIGNvbXBsZXggb3IgYW55dGhpbmcgbGlrZSBp dC4NCg0KSSB0aGluayBJJ2Qgc3VtbWFyaXNlIHRoZSByZWFsIGFyZ3VtZW50IGFnYWluc3QgU1BL SSBoZXJlIGFzDQpiZWluZzogIkkgd2FudCB0byBkbyB3aGF0IEkgdGhvdWdodCBvZiBmaXJzdC4i IEFuZCBvZiBjb3Vyc2Ugc2luY2UgdGhhdCdzIG5vdCBhIHZlcnkgZ29vZCBhcmd1bWVudCwgZnVy dGhlciBkaXNjdXNzaW9uIHNlZW1zIHRvIGRpdmUgaW50byBldmVuIHdvcnNlIGFyZ3VtZW50LCBz dWNoIGFzIHRoaXMgYmVpbmcgdG9vIGRpZmZpY3VsdCwgdGFraW5nIGhvdXJzIG9yIGJlaW5nIG5h c3R5LW9sZC1BU04uMSBldGMuDQoNCkNoZWVycywNClMuDQoNClswXSBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi13ZWJzZWMta2V5LXBpbm5pbmctMjEjYXBwZW5kaXgtQQ0K WzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjgwDQpbMl0gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzMyNzkNClszXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTQ4MA0KWzRdDQpodHRwczovL3d3dy5nb29nbGUuaWUvc2VhcmNoP3E9c3ViamVjdHB1Ymxp Y2tleWluZm8mc2E9RyZnYnY9MSZzZWk9YUM0QVZkUDFPY0hQN2dhTzlvSG9Cdw0KWzVdDQpodHRw czovL3d3dy5nb29nbGUuaWUvc2VhcmNoP3E9c3ViamVjdHB1YmxpY2tleWluZm8raG93dG8mYnRu Rz1TZWFyY2gmZ2J2PTENCls2XSBodHRwczovL3d3dy5nb29nbGUuaWUvc2VhcmNoP3E9c2hhMjU2 K3Nwa2krY29kZSZidG5HPVNlYXJjaCZnYnY9MQ0KWzddIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQv cC9ob2JhL2NvZGUvY2kvbWFzdGVyL3RyZWUvanMvaG9iYS1nZW4ta2V5LmpzI2w2MA0KWzhdIGh0 dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcC9ob2JhL2NvZGUvY2kvbWFzdGVyL3RyZWUvbGliL2hvYmEt Y3J5cHQuY2MjbDc0DQpbOV0gaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wL25ldGluZi9jb2RlL2Np L2RlZmF1bHQvdHJlZS8NClsxMF0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjkyMA0K DQpPbiAxMS8wMy8xNSAwNToxNiwgTWlrZSBKb25lcyB3cm90ZToNCj4gSSd2ZSBhbHdheXMgbG92 ZWQgbGVhcm5pbmcgbmV3IHRoaW5ncywgc28gSSBkZWNpZGVkIHllc3RlcmRheSB0byB0cnkgDQo+ IHRvIGxlYXJuIGZpcnN0LWhhbmQgaG93IHRvIHdyaXRlIGNvZGUgdGhhdCBlbWl0dGVkIFguNTA5 IA0KPiBTdWJqZWN0UHVibGljS2V5SW5mbyAoU1BLSSkgdmFsdWVzIGZyb20gc2NyYXRjaC4gIEJ5 ICJmcm9tIHNjcmF0Y2giLCBJIA0KPiBtZWFuIHVzaW5nIGRldmVsb3BtZW50IHRvb2xzIHdpdGhv dXQgYnVpbHQtaW4gWC41MDkgb3IgQVNOLjEgc3VwcG9ydC4NCj4gDQo+IEkgdG9vayB0aGlzIG9u IGJlY2F1c2Ugb2YgU3RlcGhlbidzIHN1Z2dlc3Rpb24gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQ5NTQuaHRtbCB0aGF0IA0KPiBwZW9w bGUgY291bGQganVzdCBoYXNoIHRoZSBTUEtJIHZhbHVlcyB0byBjcmVhdGUgYSBrZXkgdGh1bWJw cmludC4NCj4gR2l2ZW4gSSdkIGhlbHBlZCBjcmVhdGUgdGhlIEpTT04tYmFzZWQgaGFzaCBpbnB1 dCBkZXNjcmliZWQgaW4gDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt am9zZS1qd2stdGh1bWJwcmludC0wMywgSSB3YW50ZWQgDQo+IHRvIGdpdmUgaGlzIGFsdGVybmF0 aXZlIHN1Z2dlc3Rpb24gYSBmYWlyIHNoYWtlIChhbmQgbGVhcm4gc29tZSBuZXcgDQo+IHRoaW5n cyBhbG9uZyB0aGUgd2F5KS4gIFRoaXMgYWRtaXR0ZWRseSBzdHJlYW0tb2YtY29uc2Npb3VzbmVz cyBhbmQgDQo+IG92ZXJseSBsb25nIG1lc3NhZ2UgZGVzY3JpYmVzIG15IGV4cGVkaXRpb24gdG8g ZGF0ZS4uLg0KPiANCj4gVGh1cyBmYXIsIEkndmUgc3BlbnQgNSBob3VycyB0cnlpbmcgdG8gbGVh cm4gdG8gZG8gdGhpcy4gIEkgc3BlbnQgDQo+IGFib3V0IHRoZSBmaXJzdCB0d28gaG91cnMgc2Vh cmNoaW5nIGZvciBleGFtcGxlcyBvZiBjcmVhdGluZyB0aGUgYnl0ZXMgDQo+IG9mIFguNTA5IGNl cnRpZmljYXRlcyBvciBTdWJqZWN0UHVibGljS2V5SW5mbyB2YWx1ZXMgd2l0aG91dCB1c2luZyAN Cj4gQVNOLjEgYW5kL29yIFguNTA5IGxpYnJhcmllcy4gIEkgZmFpbGVkLg0KPiANCj4gTmV4dCwg SSB0cmllZCB0byByZWFkIHRoZSBhdXRob3JpdGF0aXZlIHJlZmVyZW5jZSBmb3Igd2hhdCdzIGlu IHRoZSANCj4gU1BLSSBmaWVsZCAtIHRoZSBYLjUwOSBzcGVjLiAgVW5mb3J0dW5hdGVseSwgDQo+ IGh0dHA6Ly93d3cuaXR1LmludC9yZWMvVC1SRUMtWC41MDkvZW4gdG9sZCBtZSAiVGhpcyB0ZXh0 IHdhcyBwcm9kdWNlZCANCj4gdGhyb3VnaCBhIGpvaW50IGFjdGl2aXR5IHdpdGggSVNPIGFuZCBJ RUMuIEFjY29yZGluZyB0byB0aGUgYWdyZWVtZW50IA0KPiB3aXRoIG91ciBwYXJ0bmVycywgdGhp cyBkb2N1bWVudCBpcyBvbmx5IGF2YWlsYWJsZSB0aHJvdWdoIHBheW1lbnQuIg0KPiBTaW5jZSBt b3N0IGRldmVsb3BlcnMgd291bGQgc3RvcCBhdCB0aGF0IHBvaW50LCBJIGRpZCB0b28uDQo+IA0K PiBBZnRlciB0aGF0LCBJIGNoYW5nZWQgdGFja3MgYW5kIHRyaWVkIHRvIGZpbmQgZXhhbXBsZXMg b2Ygc2FtcGxlIA0KPiBjZXJ0aWZpY2F0ZXMgd2l0aCBjb21tZW50YXJ5IG9uIHdoYXQgYWxsIHRo ZSB2YWx1ZXMgbWVhbiAtIHRoZSBraW5kIG9mIA0KPiBpbmZvIGRldmVsb3BlcnMgd291bGQgd2Fu dCB3aGVuIGNvZGluZyB0aGlzLiAgSSBoYWQgYmV0dGVyIGx1Y2sgd2l0aCANCj4gdGhhdC4gIEFm dGVyIGFib3V0IGFub3RoZXIgaG91ciBvZiBXZWIgc2VhcmNoaW5nLCBJIGZvdW5kIHRoaXMgcmVh bGx5IA0KPiB1c2VmdWwgZXhhbXBsZTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI1 MCNhcHBlbmRpeC1BLg0KPiBJIGFsc28gZm91bmQgdGhpcyBvbmU6DQo+IGh0dHA6Ly93d3cuamVu c2lnbi5jb20vSmF2YVNjaWVuY2UvZG90bmV0L0pLZXlOZXQvaW5kZXguaHRtbC4gIEdvaW5nIA0K PiB0aHJvdWdoIHRoZW0gYnl0ZS1ieS1ieXRlIGVuYWJsZWQgbWUgdG8gcmV2ZXJzZSBlbmdpbmVl ciBzb21lIG9mIHRoZQ0KPiBBU04uMSBhbmQgWC41MDkgY29uc3RydWN0cyB1c2VkLg0KPiANCj4g VGhpbmdzIEkgbGVhcm5lZCBieSBsb29raW5nIGF0IHRoZXNlIDEwMjQtYml0IFJTQSBwdWJsaWMg a2V5IA0KPiByZXByZXNlbnRhdGlvbnMgaW5jbHVkZWQ6DQo+IA0KPiAqICAgICAgICBBU04uMSB1 c2VzIGJ5dGUtYWxpZ25lZCBUYWctTGVuZ3RoLVZhbHVlIGVuY29kaW5ncy4NCj4gDQo+ICogICAg ICAgIFRoZSB0YWdzIGZvciBTRVFVRU5DRSwgT0lELCBOVUxMLCBCSVQgU1RSSU5HLCBhbmQgSU5U RUdFUg0KPiBhcmUgcmVzcGVjdGl2ZWx5IDB4MzAsIDB4MDYsIDB4MDUsIDB4MDMsIGFuZCAweDAy Lg0KPiANCj4gKiAgICAgICAgVGhlc2UgTGVuZ3RoIHZhbHVlcyBhcmUgZW5jb2RlZCBhcyBmb2xs b3dzOg0KPiANCj4gbyAgIDE1OSAtIDB4ODEgMHg5Zg0KPiANCj4gbyAgIDkgLSAweDA5DQo+IA0K PiBvICAgMCAtIDB4MDANCj4gDQo+ICogICAgICAgIFRoZSBPSUQgMS4yLjg0MC4xMTM1NDkuMS4x LjEgaXMgZW5jb2RlZCBpbiA5IGJ5dGVzIGFzIDB4MmENCj4gMHg4NiAweDQ4IDB4ODYgMHhmNyAw eDBkIDB4MDEgMHgwMSAweDAxLg0KPiANCj4gKiAgICAgICAgVGhlIE9JRCBpcyBmb2xsb3dlZCBi eSBhbiBBU04uMSBOVUxMIC0gMHgwNSAweDAwLg0KPiANCj4gKiAgICAgICAgVGhlIFJTQSBLZXkg aXMgcmVwcmVzZW50ZWQgYXMgYW4gZW5jYXBzdWxhdGVkIGJpdCBmaWVsZC4NCj4gDQo+ICogICAg ICAgIFRoZXJlIGlzIGFuIGFwcGFyZW50bHkgdW51c2VkIHplcm8gYnl0ZSAodGhlIDIybmQgYnl0 ZSBvZg0KPiB0aGUgU1BLSSBmaWVsZCBpbiB0aGUgUkZDIDcyNTAgZXhhbXBsZSkgYXMgdGhlIGZp cnN0IGJ5dGUgb2YgdGhpcyBiaXQgDQo+IGZpZWxkLg0KPiANCj4gKiAgICAgICAgVGhlIHJlc3Qg b2YgdGhlIGJpdCBmaWVsZCBjb250YWlucyBjb25jYXRlbmF0ZWQNCj4gcmVwcmVzZW50YXRpb25z IG9mIHRoZSBtb2R1bHVzIGFuZCB0aGUgZXhwb25lbnQgYXMgQVNOLjEgSU5URUdFUnMuDQo+IA0K PiAqICAgICAgICBUaGUgMTAyNCBiaXQgbW9kdWx1cyBpcyByZXByZXNlbnRlZCBpbiAxMjkgYnl0 ZXMsIHdpdGggdGhlDQo+IGZpcnN0IGJ5dGUgYmVpbmcgemVyby4NCj4gDQo+IFRoaXMgYnJvdWdo dCBtZSB1cCB0byBob3VyIGZvdXIuICBOZXh0LCBJIHdlbnQgbG9va2luZyBmb3IgYSAyMDQ4IGJp dCANCj4gY2VydCB0byBsZWFybiBmcm9tIChlc3BlY2lhbGx5IHNpbmNlIEpXQSByZXF1aXJlcyAy MDQ4KyBiaXQgUlNBIGtleXMpLiAgDQo+IEkgZm91bmQgaHR0cDovL2ZtNGRkLmNvbS9vcGVuc3Ns L2NlcnRleGFtcGxlcy5odG0gYW5kIGNob3NlIA0KPiAyMDQ4Yi1yc2EtZXhhbXBsZS1jZXJ0LmRl ciwgZnJvbSB3aGljaCBJIGFsc28gbGVhcm5lZDoNCj4gDQo+ICogICAgICAgIFRoZXNlIGxlbmd0 aCB2YWx1ZXMgYXJlIGVuY29kZWQgYXMgZm9sbG93czoNCj4gDQo+IG8gICAyOTAgLSAweDgyIDB4 MDEgMHgyMg0KPiANCj4gbyAgIDI1NyAtIDB4ODIgMHgwMSAweDAxDQo+IA0KPiAqICAgICAgICBG cm9tIHRoaXMsIEkgZGVkdWNlZCAocG9zc2libHkgaW5jb3JyZWN0bHkgOikpIHRoYXQgaWYgdGhl DQo+IGhpZ2ggYml0IG9mIHRoZSBmaXJzdCBsZW5ndGggYnl0ZSBpcyAwLCB0aGUgcmVtYWluaW5n IDcgYml0cyByZXByZXNlbnQgDQo+IHRoZSBsZW5ndGgsIGJ1dCBpZiB0aGUgaGlnaCBiaXQgb2Yg dGhlIGZpcnN0IGxlbmd0aCBieXRlIGlzIDEsIHRoZSANCj4gcmVtYWluaW5nIDcgYml0cyByZXBy ZXNlbnQgdGhlIG51bWJlciBvZiBieXRlcyB1c2VkIHRvIHJlcHJlc2VudCB0aGUgDQo+IGFjdHVh bCBsZW5ndGguICAoSGVuY2UgdGhlIHVzZSBvZiAweDgxIGZvciByZXByZXNlbnRpbmcgdmFsdWVz IGluIHRoZSANCj4gcmFuZ2UgMTI4LTI1NSBhbmQgdGhlIHVzZSBvZiAweDgyIGZvciByZXByZXNl bnRpbmcgdmFsdWVzIGluIHRoZSByYW5nZSANCj4gMjU2LTMyNzY3LikNCj4gDQo+ICogICAgICAg IExlbmd0aCB2YWx1ZXMgYXJlIHJlcHJlc2VudGVkIGluIGJpZy1lbmRpYW4gYnl0ZSBvcmRlci4N Cj4gDQo+ICogICAgICAgIFRoZSAyMDQ4IGJpdCBrZXkgcmVwcmVzZW50YXRpb24gYWxzbyBzdGFy dHMgd2l0aCBhbg0KPiBhcHBhcmVudGx5IHVudXNlZCB6ZXJvIGJ5dGUuDQo+IA0KPiAqICAgICAg ICBUaGUgMjA0OCBiaXQgbW9kdWx1cyBpcyByZXByZXNlbnRlZCBieSAyNTcgYnl0ZXMsIHdpdGgg dGhlDQo+IGZpcnN0IGJ5dGUgYmVpbmcgemVyby4NCj4gDQo+IFRoaW5ncyBJIGhhdmVuJ3QgeWV0 IGxlYXJuZWQgdGhhdCBJJ2QgbmVlZCB0byBrbm93IHRvIHJlYWxseSB3cml0ZSANCj4gdGhpcyBj b2RlOg0KPiANCj4gKiAgICAgICAgSG93IGFyZSB0aGUgT0lEcyBpbiB0aGUgdGFibGUgYXQNCj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29y aXRobXMtNDAjYXBwZQ0KPiBuZGl4LUENCj4gcmVwcmVzZW50ZWQgYXMgQVNOLjEgT0lEIHZhbHVl cz8NCj4gDQo+ICogICAgICAgIEFyZSBtdWx0aXBsZSBPSURzIHNvbWV0aW1lcyBwcmVzZW50IGJl Zm9yZSB0aGUgQVNOLjEgTlVMTCwNCj4gYW5kIGlmIHNvLCB3aGljaCBhbGdvcml0aG1zIHJlcXVp cmUgd2hpY2ggc2V0cyBvZiBPSURzIGluIHdoYXQgb3JkZXI/DQo+IA0KPiAqICAgICAgICBJcyB0 aGVyZSBhbHdheXMgdGhlIGFwcGFyZW50bHkgdW51c2VkIHplcm8gYnl0ZSBpbiB0aGUga2V5DQo+ IHJlcHJlc2VudGF0aW9uIG9yIGlmIG5vdCwgd2hlbiBpcyBpdCBwcmVzZW50IGFuZCBhYnNlbnQ/ DQo+IA0KPiAqICAgICAgICBJcyB0aGVyZSBhbHdheXMgYSBsZWFkaW5nIHplcm8gYnl0ZSBpbiB0 aGUgUlNBIG1vZHVsdXMgb3IgaWYNCj4gbm90LCB3aGVuIGlzIGl0IHByZXNlbnQgYW5kIGFic2Vu dD8NCj4gDQo+ICogICAgICAgIEhvdyBhcmUgZWxsaXB0aWMgY3VydmUga2V5cyByZXByZXNlbnRl ZD8NCj4gDQo+IFRoaXMgYnJvdWdodCBtZSB1cCB0byBhYm91dCB0aGUgZmlmdGggaG91ciBvZiBt eSBpbnZlc3RpZ2F0aW9uLCBhbmQgSSANCj4gZGVjaWRlZCB0byBzdG9wIGFuZCB3cml0ZSB1cCBt eSBmaW5kaW5ncyB0byBkYXRlLiAgSGlnaGxpZ2h0ZWQgDQo+IHZlcnNpb25zIG9mIHRoZSBleGFt cGxlIGNlcnRpZmljYXRlIGZyb20gUkZDIDcyNTAgYW5kIHRoZSBTUEtJIHZhbHVlIA0KPiBmcm9t IGZtNGRkLmNvbSBhcmUgYXR0YWNoZWQsIHNob3VsZCBhbnkgb2YgeW91IHdhbnQgdG8gZm9sbG93 IGFsb25nIA0KPiB3aXRoIG15IHJldmVyc2UgZW5naW5lZXJpbmcuICBUYWdzIGFyZSB5ZWxsb3cu ICBMZW5ndGhzIGFyZSBncmVlbi4NCj4gT0lEcyBhcmUgcHVycGxlLiAgVGhlIGFwcGFyZW50bHkg dW51c2VkIGJ5dGUgaXMgcmVkLiAgS2V5IHZhbHVlcyBhcmUgDQo+IGJsdWUuDQo+IA0KPiBJIHJl YWRpbHkgYWRtaXQgdGhhdCBJIGNvdWxkIGhhdmUgZWFzaWx5IG1pc3NlZCBzb21ldGhpbmcgd2hp bGUgDQo+IHNlYXJjaGluZy4gIElmIHNvbWVvbmUgY2FuIHBvaW50IG1lIHRvIHNlbGYtY29udGFp bmVkIGRlc2NyaXB0aW9ucyBvZiANCj4gdGhpcyBpbmZvcm1hdGlvbiwgSSdkIGxvdmUgdG8gc2Vl IHRoZW0hDQo+IA0KPiA9PT09IENPTkNMVVNJT05TID09PT0NCj4gDQo+IDEuICBJIHRoaW5rIGl0 IHdvdWxkIGJlIGEgZmluZSB0aGluZyB0byBkbyB0byB3cml0ZSBhbiBSRkMgZGVzY3JpYmluZyAN Cj4gdGhlIG1hcHBpbmcgYmV0d2VlbiBrZXkgdmFsdWVzIGFuZCB0aGVpciBTUEtJIHJlcHJlc2Vu dGF0aW9ucy4gIFRoaXMgDQo+IGNvdWxkIHRha2UgdGhlIGZvcm0gb2YgYSBjb29rYm9vayB3aXRo IGVudHJpZXMgbGlrZSAiRm9yIGEgMjA0OCBiaXQgDQo+IFJTQSBrZXkgdXNpbmcgUlNBU1NBIHdp dGggU0hBLTI1NiwgZW1pdCB0aGVzZSBieXRlcywgZmlsbGluZyBpbiBzbG90cyANCj4gQSBhbmQg QiBpbiB0aGUgdGVtcGxhdGUgd2l0aCB0aGUgMjU2IGJpdGVzIG9mIHRoZSBtYW50aXNzYSBhbmQg dGhlIDMgDQo+IGJ5dGVzIG9mIHRoZSBleHBvbmVudCIuICBCYXNlZCBvbiBteSBzZWFyY2hpbmcs IEkgZG9uJ3QgdGhpbmsgdGhpcyANCj4gaW5mb3JtYXRpb24gZXhpc3RzIGFueXdoZXJlIGluIGEg c2VsZi1jb250YWluZWQgZm9ybSBhY2Nlc3NpYmxlIHRvIA0KPiBkZXZlbG9wZXJzIChidXQgSSBj b3VsZCBiZSB3cm9uZywgb2YgY291cnNlKS4gIEknbSBub3QgZ29pbmcgdG8gDQo+IHBlcnNvbmFs bHkgZG8gaXQsIGJ1dCBpZiBhbnkgb2YgeW91IHdhbnQgZ28gZm9yIGl0LCBoYXZlIGF0IGl0IQ0K PiANCj4gMi4gIElmIG15IGV4cGVyaWVuY2UgaXMgcmVwcmVzZW50YXRpdmUsIHRlbGxpbmcgZGV2 ZWxvcGVycyB0byBqdXN0IA0KPiBoYXNoIHRoZSBTUEtJIHJlcHJlc2VudGF0aW9uIG9mIGEgSldL IHdvbid0IGJlIHZlcnkgZWZmZWN0aXZlIHVubGVzcyANCj4gdGhleSBhbHJlYWR5IGhhdmUgWC41 MDkgc3VwcG9ydC4gIE1vc3Qgd2lsbCBwcm9iYWJseSBnaXZlIHVwIHdlbGwgDQo+IGJlZm9yZSB0 aGUgNSBob3VycyB0aGF0IEkndmUgaW52ZXN0ZWQgdG8gZ2V0IHRoaXMgdGhpcyBwYXJ0aWFsIA0K PiB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgSSdkIG5lZWQgdG8ga25vdy4gIElmIG15IGV4cGVyaWVu Y2UgaXMgDQo+IHJlcHJlc2VudGF0aXZlLCBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQg d2lsbCBiZSBtdWNoIGVhc2llciB0byANCj4gaW1wbGVtZW50IGZvciB0aGVzZSBkZXZlbG9wZXJz Lg0KPiANCj4gVHJ5aW5nIHRvIGxpdmUgaW4gdGhlIHNob2VzIG9mIGRldmVsb3BlcnMsIC0tIE1p a2UNCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIGpvc2UgbWFpbGluZyBsaXN0IA0KPiBqb3NlQGlldGYub3JnIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KPiANCg== From nobody Tue Mar 24 12:34:36 2015 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 409E11A8ACF for ; Tue, 24 Mar 2015 12:34:33 -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 9v7m68Aq76WA for ; Tue, 24 Mar 2015 12:34:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B431A8AB7 for ; Tue, 24 Mar 2015 12:34:29 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.125.14; Tue, 24 Mar 2015 19:34:26 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Tue, 24 Mar 2015 19:34:26 +0000 From: Mike Jones To: Jim Schaad , Karen O'Donoghue Thread-Topic: Presentation for Key Managed JWS new business (time permitting) Thread-Index: AdBmaYP+77G2cRcKRDiL00HNb5uXgQ== Date: Tue, 24 Mar 2015 19:34:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:e9d0:2d22:b046:e6d7] authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(19300405004)(15975445007)(77096005)(46102003)(33656002)(229853001)(77156002)(54356999)(102836002)(99286002)(19617315012)(50986999)(19609705001)(62966003)(99936001)(19580395003)(558084003)(2656002)(87936001)(86362001)(86612001)(74316001)(122556002)(16236675004)(19625215002)(40100003)(76576001)(92566002)(2900100001)(569964003)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0525BB0ADF Content-Type: multipart/mixed; boundary="_004_BY2PR03MB442AE4BC9D853A29D0C7643F50A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2015 19:34:26.4071 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "jose@ietf.org" Subject: [jose] Presentation for Key Managed JWS new business (time permitting) 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, 24 Mar 2015 19:34:33 -0000 --_004_BY2PR03MB442AE4BC9D853A29D0C7643F50A0BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442AE4BC9D853A29D0C7643F50A0BY2PR03MB442namprd_" --_000_BY2PR03MB442AE4BC9D853A29D0C7643F50A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim or Karen, could you please add this to meeting information for the new = business agenda item at http://www.ietf.org/proceedings/92/agenda/agenda-92= -jose? Thanks, -- Mike --_000_BY2PR03MB442AE4BC9D853A29D0C7643F50A0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim or Karen, could you please add this to meeting i= nformation for the new business agenda item at http:/= /www.ietf.org/proceedings/92/agenda/agenda-92-jose?

 

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

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

 

--_000_BY2PR03MB442AE4BC9D853A29D0C7643F50A0BY2PR03MB442namprd_-- --_004_BY2PR03MB442AE4BC9D853A29D0C7643F50A0BY2PR03MB442namprd_ Content-Type: application/pdf; name="Key Managed JSON Web Signature - IETF 92.pdf" Content-Description: Key Managed JSON Web Signature - IETF 92.pdf Content-Disposition: attachment; filename="Key Managed JSON Web Signature - IETF 92.pdf"; size=305297; creation-date="Tue, 24 Mar 2015 19:22:08 GMT"; modification-date="Tue, 24 Mar 2015 19:34:25 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDQxIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDcvS2lkc1sgMyAwIFIgMTMg MCBSIDIwIDAgUiAyMiAwIFIgMjYgMCBSIDMwIDAgUiAzOCAwIFJdID4+DQplbmRvYmoNCjMgMCBv YmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvR1M1 IDUgMCBSPj4vRm9udDw8L0YxIDYgMCBSL0YyIDggMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1h Z2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDQg MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz L1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCAzOTM+Pg0Kc3RyZWFtDQp4nIWSy27CMBBF95HyD7O0UTHjsZ04EmLBU1ClDxGJ BXSRtoGiUqpCu+jf10GUkgToJlIkzznXdwyNO2g2G3Fn2AVstaDd7cCH7yGgQERJhCGEhGA0wibz vUkN1r7XGIwNLLa+J2FxOIwYSNSF0/Oa7937HvTiDsCRSe5N7cSx+hK0Fm4ymedARwMJUksRRqDI iCiE5C237FQD35uyay4jlnHDvoErFqfrdOF+smfgmo3Gtzcw4Spg2SPwB0hGvtdznmNXUJLZSEQS KFRC6p1sysbLxTrlIfv82nCpWAYz5lTX8WjiTOMZL5F/UUa5LoIi6jhFpQoqVaGoXAVZK9wXUSi1 J8bLV66sCzV653Vi62x7Jo5WUlhbHL4YR52IU2qLTJRfURotiPbMYS9x7fSB1xWLyG2h2jydYqkA BekCq4kq1K3q3k5Nh4GgYpCy93DUKlH0sG66Wrldpme7c9miC/hKd/r/VRqbsyTav9cRp+6BBezp BUhfuU1JczbPbpeF4UqeHxXvwpcNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBl L0V4dEdTdGF0ZS9CTS9Ob3JtYWwvY2EgMT4+DQplbmRvYmoNCjYgMCBvYmoNCjw8L1R5cGUvRm9u dC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZvbnQvQUJDREVFK0NhbGlicmkvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDcgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0 Q2hhciAxMjIvV2lkdGhzIDE3NiAwIFI+Pg0KZW5kb2JqDQo3IDAgb2JqDQo8PC9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAv QXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lk dGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250QkJveFsgLTUw MyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDE3NCAwIFI+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8 PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9FbmNvZGlu Zy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyA5IDAgUi9Ub1VuaWNvZGUgMTczIDAgUj4+DQpl bmRvYmoNCjkgMCBvYmoNClsgMTAgMCBSXSANCmVuZG9iag0KMTAgMCBvYmoNCjw8L0Jhc2VGb250 L0FCQ0RFRStDYWxpYnJpL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1h cC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gMTEgMCBSL0ZvbnREZXNjcmlwdG9yIDEy IDAgUi9XIDE3NSAwIFI+Pg0KZW5kb2JqDQoxMSAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkp IC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9U eXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxp Y0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1 MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250 QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDE3NCAwIFI+Pg0KZW5kb2JqDQox MyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8 PC9HUzUgNSAwIFI+Pi9Gb250PDwvRjEgNiAwIFIvRjMgMTUgMCBSPj4vUHJvY1NldFsvUERGL1Rl eHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRl bnRzIDE0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC Pj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMT4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDk5NT4+DQpzdHJlYW0NCnicnVZNb9s4EL0b8H+YI1msGX5TWgQ5 OM0GDRC02wTIodiDYsm2to7UWlID//udkZ2uJVuu0ZNpcT4f3xsSLj7B5eXF/fWH9yCvrmD6/hq+ j0cSpJBSKq1lgKAlOCthnY1HT++gGI8ubh8cLKrxSMHip7GUXknbsZ6/G4/+Ho/g5v4aYC+T2mWa PmKsvxRYK6S38DiniBgOFCilRIw7LhIuhscXStPmuh2PvrBpMvu6WHMVWNkUKZ9oBtyxpEjhvqzz H1xplvCI1XlZ8H/g8W48usFUlO4tvpeRUNF+/C8Y43/bg5p1p2YDRgvZLdkaocFEUphoG/BSyihc dfNTu4euQfZc2dNA3XEQkbZdWwTCs7KmrjPCIV1zLRGAwOb1QBitlfBxN8xkyNYo4UzX9t+yyKoB eyOVMOG82AaPWat+7CobMvdWaHdm6GCF6oX+yo1nGQKzGXCyKohwJi5WB+F6CV6SIlkg87J0wMnZ SGh/XgKH5OxjUw0zmhQTnRd5yzeLDm5n+YqgZM8D5ko74X3XYSi0Mk64rmmVc8MWBRGybpCsFmla 00/55xDl4li40I1yUp2mp048mth3JRYLTcKRUvjwU59TdUSfh84KKR2ijjMq1Gi2zrllNY+xo7TE Ll8L4JOYJVBRfzUK0bAkXyy5kqyec61ZueYTtONKsQSxMCxFD1Tu9gtXjm1IwxSzxJi4GVg+JGMX Ak7Obl0ncbJ9nHDy6v7kdYgUaO+EVKcH2TFvY/re7HN75E2VFwvAthAGx7J2PhMbcF1BstquknSz neaefdvtZQX61ECf8wLunm4AeUSj/u4JFw+D8z1G7XTKOAmMO5dAGrUQfpdA+87soRVEXtHcnhMp Nm2T86ZukEk7nfCJ2y2/Nxl+rogydUWcCWxHKKiXpLCqpd68KXA9o6svWeXEpA0Pnv0BQ3rdVqZi LdRbZdWybFZ0kVAaz+plhuexgXI2ozLx0IYGfzudO6FOgu6PgB7ZY6grp/De+zXqPe+35va82ScU pWIl6vYHiTcljD1SC/v91pCaqWmzE+D19OPndv/uI6L6cAPPaIhOBCyxmZTb/qlmTVXRoiyG7kVv YhG6tZxEJxxo9ZhOlfL0kPmFTo9pdN+TfShmqyZtFRrY6zJpNdfOpAxeaIC1GsS/OJKQDzjfcLC9 ZMQHEivpMc3nNOa28l63r5GCRL4aumy99e3p7NdxEpHovDdYQP5Z+1tvsH1XnPA6Pnhc4SymllGW RTvw4TmbIThJU9Gl5hhiQ3PpFnDzJaGH2AZN0MGy2QpfNkMPA+8M3pud/H3Jnia5kSI65tmi+B+J VYBjDQplbmRzdHJlYW0NCmVuZG9iag0KMTUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5 cGUwL0Jhc2VGb250L0FyaWFsL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDE2 IDAgUi9Ub1VuaWNvZGUgMTc3IDAgUj4+DQplbmRvYmoNCjE2IDAgb2JqDQpbIDE3IDAgUl0gDQpl bmRvYmoNCjE3IDAgb2JqDQo8PC9CYXNlRm9udC9BcmlhbC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9U eXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDE4IDAg Ui9Gb250RGVzY3JpcHRvciAxOSAwIFIvVyAxNzkgMCBSPj4NCmVuZG9iag0KMTggMCBvYmoNCjw8 L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5k b2JqDQoxOSAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BcmlhbC9GbGFn cyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjEwL0NhcEhlaWdodCA3Mjgv QXZnV2lkdGggNDQxL01heFdpZHRoIDI2NjUvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVh ZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEwIDIwMDAgNzI4XSAvRm9udEZpbGUy IDE3OCAwIFI+Pg0KZW5kb2JqDQoyMCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9S ZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9HUzUgNSAwIFI+Pi9Gb250PDwvRjEgNiAwIFIvRjMgMTUg MCBSL0YyIDggMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+ L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDIxIDAgUi9Hcm91cDw8L1R5cGUvR3Jv dXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMj4+ DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDcyNT4+DQpz dHJlYW0NCnicnVZLb9pAEL5b8n+Y424kNrPvXQlZCq+0RDSpjJRD1IMFJkVNCAVySH5914Y0Nq8g DgjYne+b+eZlw+UdNJuXg/b3DmCSQKvThr9xhIAMEbkQaMEKBK0QFnkc3V/ALI4ur1MNj8s44vD4 3xjRcFQ168lFHP2MI+gO2gAVT3zjqTUMXD0OSjE0CoaTgjHQAQeBilkPSjumPQyfCzelr+s4eiA3 g/49lSQFqki6WryOVq8LyjnJ6S8Y9uOoG4gL8g82zTWTVbIHAhXTnQBFLUAJUjCsx6ckEyAdMunW hE1EZ5O6+0LbLtTiFpRcQSEoBboNF3vgApFpteVb2i7ytk04byLn4bdHlFqHokjkupPIcOyvkoYM 91K3Eu2bpU15j2L9HQy43OBde/3RnXDfK/GmV16VptaUMG51eSZtb33OMdHB1HYKk8Q2P0kLa91Z Iz0WhFKfli+jbKG0lrGj1ZNb1ROWeVMvgWdChBxKz0KDf9SvxffEswvmyJl1NTDp36Zd+JZn43xx oAWF0gx9HXVUhTpVhfCOWX2miiqYdGejBW0o8janjqyoJ/kYaMORG8pdmK1wcUickcz4OtlRcXqP OKf2qgtDq/jX6rbQH/IqaHJHhSIZ5Ya8PVFNXrLxATmhQZmsuz4ux5xcK+6KLjizVhUwGVyF+rQP CdCG6br90fjtafuOW8G8PWvfVaGk/fI8z0arsMG3V95nBSTTro5K88U0e5oG1DvlNhTSklXx72UW mtSQ39kSFMyzxWp56CkQ0sh9nfRoWtyJaRGGOXNeWipQ0k9vf0BKG5KUSoO06XsxeVWlr8t8CcWz IpsVs6lI/74Ls+w5PyTahIVj636OavantrLToULqzFaugklnGlbLJLTzhAoTtFOuSD6jHMkqSNRk fTCazqdhajcXy3IxhWxAka/xFwzrYSkhf6jEzS4LLwwHW8WVz5xamDtp+wc6jeMWDQplbmRzdHJl YW0NCmVuZG9iag0KMjIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2Vz PDwvRXh0R1N0YXRlPDwvR1M1IDUgMCBSPj4vRm9udDw8L0YxIDYgMCBSL0YzIDE1IDAgUi9GNCAy NCAwIFIvRjIgOCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0g Pj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMjMgMCBSL0dyb3VwPDwvVHlwZS9H cm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAz Pj4NCmVuZG9iag0KMjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTMwPj4N CnN0cmVhbQ0KeJyNU01r20AQvQv0Hwaf5FCvZ/ZbQSzYsvLhYpLWhhxCD6Z1fIlLm14Kpf+9s5KT euMPfBCLRm/eezNPC8N7qKrhrL6dAIYA40kNP/MMAQUikpTowEkEoxFeVnn2cAHf82x4PTew/pVn BOs3MKIl1An66SLPPuUZNLMaYEeJtkrjBXNdEWgt0GpYPEVGpgMCckaQAW28MCUsNlGm1brOs8fi 42z60DfFHPq6mN7NG7hZLb+tXvpfYDHNs4ZpI/Url2F+L3e5HgvYwe75k4k/BUoKTO1pJSQoj0L5 jrBC9C6k+nG0/VaH71qL5neffLHc/Hjuq2J1eWQK8l5Ym3aenEIlU2iQTpQ2tVIKKTUojcLQlvJP b/m85rX2Lnuf53yOjtiRVgnj0t7BMSx7libF3o2a+x7zf+htlhzlV9a74de5NDaW/x6hsmTYc0p1 cgv6vCxlqURpTmUpj2WZtirTBEkVEkoke4VkMAw0xg9XfEdU0PytxkB6BzM2SNQglRhUFVF89TyS rwMZhrkJP6atoxohOh0GEcc8LdbWQfkqUgQX2V1X5pZWwdnuZCdl1Qm5raCzbakctdYGOvHd+jnn l7Z8wUqfLOJ0KOZAKPZQKtoJf0Yq9lAsSS/H8n8hhG9pmNNpmKpbTIS9JuL3EmlDcxqRRdqS1jFm PgNhzEl2gZy12vd7KEuBKplmf7f/AOGiJa0NCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNCAwIG9iag0K PDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GNC9CYXNlRm9udC9BQkNERUUrQ291 cmllciMyME5ldy9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMjUgMCBS L0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjUvV2lkdGhzIDE4MCAwIFI+Pg0KZW5kb2JqDQoyNSAw IG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ291cmllciMyME5l dy9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4MzMvRGVzY2VudCAtMTg4L0NhcEhlaWdo dCA2MTMvQXZnV2lkdGggNjAwL01heFdpZHRoIDc0NC9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1 MC9TdGVtViA2MC9Gb250QkJveFsgLTEyMiAtMTg4IDYyMyA2MTNdIC9Gb250RmlsZTIgMTgxIDAg Uj4+DQplbmRvYmoNCjI2IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNl czw8L0V4dEdTdGF0ZTw8L0dTNSA1IDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMyAxNSAwIFIvRjIg OCAwIFIvRjUgMjggMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUld ID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDI3IDAgUi9Hcm91cDw8L1R5cGUv R3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMg ND4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyMzA+ Pg0Kc3RyZWFtDQp4nJ1X3W/aSBB/R+J/2Md1VTb7vfYJWQIHqvYUXe+K1If2HlxwCDowORuay39/ M2sg2MYhdw+J1rszs7/Z33xBbj6T4fDmLvl4S3gck/FtQv7u9zjhjHMupOSOOMmJ0ZwUWb/39R3J +72bD18MWZb9niDLkzDnVnBdk75/1+/93u+RyV1CyNlN4nDTeAa2poJozbjVZHaPFsEcESTiTESS aBsyKclsg9f4uz6AvQFcqCNBZvNvdESCP8nsU783AWNo8GhBSMOcOLcA26gxC1xE078CJWmWBpo+ BULSNBAhfe6ypbhjuobmG70vAuHodtOlo7liYV1l1iUKUGVD9mFVksk/gbQ0g4sUna/KrEPdyoi5 hvo5qtb7y9r7K3Cv9vZaMUlU5FhUGRtyHrq4fjfS1lBzvK5GZw8ZgfctAyHortjPd3vvid+cB/B2 +/WCBIb+yAJFySYYSLotkAwvsc9X8P8+kAJ24ZUHFgUd3T0F8CYZnOXNp7+ZAgCIDakvALOGaXdy SI04dzq2sDQTroyB+FXHbYj8BPdiPcTteGCGXEXhQSThXOuTBVdZwCPhbuOBHHLBp1zYiAsxiRV8 CrAXjeCPe2shbJlbSK4QT71iIhAJyHsBg8sRCiEAv3QW8Iz9CVg6XIYo46jSE2Hihe20OuHSK6K5 S2904X2UYvz0Ph6vGZ0ggWllJrH03snqGsPjgYrwYPri1+jk9QHBEdzR1TCqjmBLRAcxZ7yW9vfG QgxbWuD/ueTVWNShYFFUc+r1lFBvSAkZqfMQenNOnOvRKWbDtiAY3HmJ0b7DnTSfZ+8xDfYlhjbZ YTY8YGKUWWdVMoYpVzefrnc+gwrQzNMgpLvVzyDCjAorc+nCn7VTR3SmjrSCcXO44DEtAgn1cpNB 5nroYE9yWr7vgiklFEJTt/LkseQkfXxcg7ureSA4TX+s0egvXVUS8KmobudVTnWDU2mhbdTdi6Bi akBomDUnYsfiQs60lQUXWHbrypAlVXY7i6UB43mg1EuSdPQqE2J/aZiC6tIm6QIOJ5iq42jR+yLr mLR12Y85VlWIj2xZrHbQA6E7rpdAxBY+HzbkO73DYByBRIJhBMFbrpYQXBH1FR0i4HvQcZ8JObO2 G1uLM/NWzkQEXqv/yVldGSub5oeig5UGCvYVvqCZuCaGt/MVMlfT7aYr1E3RZJvjwyNdfkH8al5g f3x+hNa4W23zJoddGQXNGkakTigtduwFduxleoxlUXidHnuZn5q2zymbVNUfusAVbpxmpmmhk5rm /SEMeram3U0O1t2G7K84RmIRgzSCxNikeboMhKbZBsodEAZVbnckx14hJ4TqbrqhtMhxb2hhQoSI +T+3sHO941w33xeF9y33Ax759BVc+kKwVqT5Aj81ncCnoYsVeF/NfnNw36IKTLQQs+osZuewSMus vDzVtTGFB/oOEwvMUFhwcfgZm2pCqSanangZv0xOVXmu5jIUG5vTnFXNLiiFRWGAc8xL4PnhDoLv +pspqOfS1BC+zl3Y4q7Vij1/2jKtX6PPdHbxM1X62U/VZYmt98f6GWtIkWEjzjBCf6a+IxBo0jmy tchKnFaWOVK7ypcYwMn4tz/wk6AC1B/Y2i7grOsnCjRtVYPQeo5/AQksBfoNCmVuZHN0cmVhbQ0K ZW5kb2JqDQoyOCAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GNS9C YXNlRm9udC9BQkNERUUrQ2FsaWJyaSxJdGFsaWMvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Zv bnREZXNjcmlwdG9yIDI5IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1dpZHRocyAxODUg MCBSPj4NCmVuZG9iag0KMjkgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv QUJDREVFK0NhbGlicmksSXRhbGljL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIC0xMS9Bc2NlbnQgNzUw L0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUyMS9NYXhXaWR0aCAxOTg0L0Zv bnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRCQm94WyAtNzI1IC0yNTAgMTI2 MCA3NTBdIC9Gb250RmlsZTIgMTgzIDAgUj4+DQplbmRvYmoNCjMwIDAgb2JqDQo8PC9UeXBlL1Bh Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L0dTNSA1IDAgUj4+L0ZvbnQ8 PC9GMiA4IDAgUi9GMSA2IDAgUi9GMyAxNSAwIFIvRjYgMzMgMCBSL0Y1IDI4IDAgUj4+L1Byb2NT ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9Bbm5vdHNbIDMyIDAgUl0gL01l ZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDMxIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAv Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgNT4+DQpl bmRvYmoNCjMxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwNTM+Pg0Kc3Ry ZWFtDQp4nI1WyW7jOBC9G/A/EJgL1YAV7stAEJDISaMDZLZk0If0HNSxYhsT22lLRtB/P0VSa2R7 cjBEloqvFr56Frr4AyXJxV32ZY5ImqKreYZ+TCcEkZgQQhkjGmlGkBQE7Yvp5OsntJ1OLj7fS7Qs pxOKlq0zIYoSMfB+/jSd/DmdoOu7DKFeJFpHunoArBuGuI2tEejh2SECHKJIkdgYg4SEVxQ9bFwY H+vzdPKYECKvCbWXhMo5oerG/VIBZsIJ1Qp+c//a7ykJLhSOEEaoyYLdH78MdpOllCV+zeVVqgis rauJp9KZazctHUQ6c64uDK1DMJMyb5s38MGnCeGytCT9Bz3cTifXUHWonB6tHEomtl/5I0ZRd3TU TTboJkecxWQIKXgMTTYk5iYAQqeMTkeY96/5toXlA1h6BFaTIWyw7pfN6i93V/j29/trFM0Y/lKW kcCHAv3CzpUjenGbSEyIWNFhrJYNg+4MTklIWQ4Kx9/wbzv0b8Q1LiKNf6JNvs2XkcXFptjCo0LP EeN4t0d3l5HB2beoD94VGErXKjYIYKnULkLYv0wnLl2pjuxFrJUztAcaQ43XbFdhdvrFBA9BYyu7 Bjzit4hSnJfo6QV6uyuLBcrLiI9acnGjjlwgk0AM2UcFZtCMBiIDwWEWujkCksOIeS5nasRleQSf KxlbPsA/T2X5MSozK2Ojj1P5f+jaP4pv1xvfq5nE90+rPF/AkuO3fUQl3lURZbhAkcRvq2ILDd6V 6+0SratfT9BNEh1rO4xwtlr1TgaZHomBtjFjAi4KCNQWzOV1OhNO7pRoJcxfUUZT3ckQVZm7Ln9r Tq1kELQZT/zai56p3a9A2YxNeRJcbBKAnV7a3jG3d1rqjqqk01QnkJluJZiSVCUtixyCy6OvpA5A 1wBBRdMZpQPJ9P5NcFMH71T3yJ27Bqqj/WMkts2drGBc3JUvikjhys3+frOGa94W7v7BtMq9Ejif dYXe1i/w8gVtd5Wnx/fCP/LFwvOkKGHoYjABW/7egmZU3h8MFuenlKlOixqQgSYtQBO4+HEogJJl RLnPAB4gSMwJUrVygYXbK1zkoF7VAc7AGj1FlODdpii9w3oLUuCzf4b3Fl74Te5FeAkmjXeHV9hp XB6eVmOpoGeYSEEytKhThkaGrDj+GgmKi+8ZhN7/fK0bu3MVCB/TuJjNsK2rZuWaK1xzweD7K0J/ GQ7NPTVqnDv9HCQzG9XBThOCAiGoaCUP+KrHfOXv+Ko6vnJpUs3dKN58iIeOgEYOwp7XBv0xJdQy JkycU0J2SgnfHRWy/9XkNcPYUDev63ZtCTrRaEU4QcKfQl9idG+S4YPJJi3wTCTjTy/RfXpJ2029 Hn16DQTAK1L42vPJgPp95H9AcQUcGNQ/vov/AE7hTdgNCmVuZHN0cmVhbQ0KZW5kb2JqDQozMiAw IG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDcwLjIyNCAzNzEuNzEgMjQ0LjYxIDQxMC44Nl0g L0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8yKSA+Pi9TdHJ1Y3RQYXJlbnQgNj4+DQpl bmRvYmoNCjMzIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNE RUUrQ2FsaWJyaSxJdGFsaWMvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMzQg MCBSL1RvVW5pY29kZSAxODIgMCBSPj4NCmVuZG9iag0KMzQgMCBvYmoNClsgMzUgMCBSXSANCmVu ZG9iag0KMzUgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpLEl0YWxpYy9TdWJ0eXBl L0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURT eXN0ZW1JbmZvIDM2IDAgUi9Gb250RGVzY3JpcHRvciAzNyAwIFIvVyAxODQgMCBSPj4NCmVuZG9i ag0KMzYgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBw bGVtZW50IDA+Pg0KZW5kb2JqDQozNyAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250 TmFtZS9BQkNERUUrQ2FsaWJyaSxJdGFsaWMvRmxhZ3MgMzIvSXRhbGljQW5nbGUgLTExL0FzY2Vu dCA3NTAvRGVzY2VudCAtMjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTIxL01heFdpZHRoIDE5 ODQvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTIvRm9udEJCb3hbIC03MjUgLTI1 MCAxMjYwIDc1MF0gL0ZvbnRGaWxlMiAxODMgMCBSPj4NCmVuZG9iag0KMzggMCBvYmoNCjw8L1R5 cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvR1M1IDUgMCBSPj4v Rm9udDw8L0YxIDYgMCBSL0YzIDE1IDAgUi9GMiA4IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0lt YWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAz OSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1Rh YnMvUy9TdHJ1Y3RQYXJlbnRzIDc+Pg0KZW5kb2JqDQozOSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA2NTA+Pg0Kc3RyZWFtDQp4nJ1UW2/aMBR+j5T/cB6darjH1yQSilQCrTqp uxVpD9UeUgiXCRJGwrT9+x0HspFSULWn2M53OT72Z7j+BP3+9UN6PwRMEhgMU/jhewjIEVFIiSGE EsFohG3ue1+voPC967tHA/PK9wTM/4IRrUDdQc+ufO+z78HoIQU4chIHp8GYtG4FaM3RahjPnCLJ gQAhNA9j0CbiJobx2tk0Xne+98Q+5IEw7FfQk6yGxzoQkuWbQLEKsmIKaRn0NCsmq121LAsHqoJv MH7veyMydKati0XDRXTs8sTgCHtSuexUrkBJjt3CteISVIRcRXvBPmIUJl1/t+lTaogvqOweNqus ALcd2qRiJQ0V2zb7DTT7uaxyCEJWL3JYFtNlszTdZSuCCWTTbSCRZQSY1dQcWjTHMtmUADTLqwrO 9GdfkRY8NoeKJqRWrtd5EcSsrpzq82+gz/vlurV4nCyybHpGUcWWi7irebHj6m0dl7HhUXip4/Jc x19Q5S2K+CbpKeyjMoPExH1acPdboRgYFJGbqKRn+g1QKPqGw/2aGztMi08FCnODQowS3cDbKcmk DUWfUWnXUKKwaaKcG9Ea1VbGDFunpCfpv4wOFaYN31G6bo3Fv7Hdzwn6lutpQ8uN7bSLvbw4LdO+ 1mcd8/A14smZ6zeeOSpu4/9K2TGVjQJJwQkoMXkBS7rGsyZx33eVi0cNWQX1otzNF7Rs2f7p2eTb pUuBEASYBZJSsQWXw0tJEtZw2bpuyqpyiX1e5U0c08HHL/B8iHExbxL8bh/ke1iUmz1qk5cbIswI Q9CmoHrhGJczLKTlkT04Hx5PaVhOD4Blk+YZoZ3sqtx1YbZbndGSFrkJu2onJ/kHEo5ZXg0KZW5k c3RyZWFtDQplbmRvYmoNCjQwIDAgb2JqDQo8PC9UaXRsZShLZXkgTWFuYWdlZCBKU09OIFdlYiBT aWduYXR1cmUgXChLTUpXU1wpKSAvQXV0aG9yKE1pa2UgSm9uZXMpIC9DcmVhdGlvbkRhdGUoRDoy MDE1MDMyNDE0MjkyNC0wNScwMCcpIC9Nb2REYXRlKEQ6MjAxNTAzMjQxNDI5MjQtMDUnMDAnKSAv UHJvZHVjZXIo/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAg ADIAMAAxADApIC9DcmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABQAG8AdwBlAHIAUABv AGkAbgB0AK4AIAAyADAAMQAwKSA+Pg0KZW5kb2JqDQo0NyAwIG9iag0KPDwvVHlwZS9PYmpTdG0v TiAxMzEvRmlyc3QgMTEwMC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE4Nzg+Pg0Kc3RyZWFt DQp4nK1a247TSBB9R+If+g/S94uEkJYFBMtVM0j7gPYhMN5hlpkEhYwEf7+n3OUkm7i7HbMS4I7t qnOq6nS53cY6IYVNwilho1DS0Eh5J5wWWnnhjNA+CCeFUVFYK0yywjlhfRQOf7QUDpeDEV4Lb7zw SviEoRMBRt6KKHEyioghHCUYeC9SiCJIwnO4HcekRNBCKVAJIKAl2ePojQhWKKNw3uAYAlCEssYK DJWj8x5H3OzhzxsEAH9BgiXsAiADfkerRYT/CPYR/pMNYCS0VFJEhyM4xYSINa5HHKMUoKS1iSJJ HGGXkAqDtCA6bSXOw85SLFZop+E/4Eh2OHrkJsF/ULCD34DgEvxGTUmGgwh0JYGQLMKRSK9E7iPy K5HBaJBuUESWjFaUJ1zQIKpkEMYYcuIxSJQyJYxFDRTuMw54SCYGlDWlhaGMKOUwIERcNoEQFfxE SQP4iZQ6BUyqjkJoJiEYEoOVKJ1Ckq2yMEeUViEepSEXDW2gQMKSMpSGJkxfMpKJoUHAgBga3Owc DSA1D3YKnJA5GsBhgA8FAxuIIQprIzHUAE2yrzkGyISCuhwJRhnoVSYaQIGKPKNsDsXDAPU3fVy4 ZIi8VVACkbckCSIP784RedK9J/LQvPOkO/hyQdIZ0rWnM7g5IgJlSfAoENXFJRKhI81pGkDaEpWn HHllMXAYaEkCTRhQeiEIbxSdIQWTdi3MrSFimBKOLtHccRQXzRVP8xEwPkAvCpF4ErPCXx81SRtW PR/k0SdEqaCxICUNMJmkI3OP2UQB0nRUELAClQCVooyYTwDHvAgWMws5CQGlQQQhQo6OjiCGqEKi hNCETASn6aQh/pA8CUp5GkCyjx4t3lOLkOJicbm4/LZcLT78/NYtLreb+8/bZ7fd3eL9tTD99VdC Pn788EE2iWzyQp0YvPoo1F9iZ7e3GWA+dD+2n9Y/xgxRXtwzZo3qZuv3Y3b6fBNzvomdGxbEinuo QfcHUwrSqqEStzdX3SgF17vI+We6o4G0aqpOiwqZTyiqKgDVwo97mkfmfoj49ZP11c9KaY/thkK9 fjlm5HUZ0bYQzbidqSO6MmJoIdpxO19HrGR1x3XUMJQNU4uqm5OcIIuIoSkAPwuxLIDQFEAYt2sg VgRQLUfm01D5aGJ6Q5YJl47zyWTH4/Ct+OOcKRfKqnKpGkZmnJPE7Ga3Gl9WWru5utxccx9k1uMp HB5/pe6q5Ul3jQN8tbtmw1OgSsjxQOpH5tFN7K7HdrZa6ujLiLGFaMbtQh0xFRGTbCHaOYhJlRH1 xCZ5JqIpIzZblp+F6Mp13CGOliMvP3LqOR9Mcpx/s+WEOTpMoYzY1GGchVjWIb0aNiBTwbDeWOnl c16ZmNK4ZfWZlBsH64fLxzkd+M7vV2WdtFt0yE+53Ew5iEJWhwCLPVqf9Gh6RZ/SpHUBqhI1bQPs uR45UM0epgvIqS4dpcqgMla1o+QE09qb1UmQzSZmC4b1hRdtlZQz2+w8biZopZytzOZ1G3P7FUkl dqT5aIoO2zOLNqzy9PZ8jJW0NhdA/nRy6WkrIF+AqmVCH7bIIwd68iLo2LD+LFDaV0Cb73xmJmgs g5rJS6Fj0EYbMaoCOnk1dC6oqYBOXhCdC+oqNa0/bHP2h4QMHAv8Jy+IzpSHCRXQyWuic0FTJWnV dQZPzmG+DPUZEjRw/pXOUK7ChJ6omE5uXUM043TsMPuK26inL4W0sT2hJxpZgKpFbg8iP3HQ6t87 rpqN+nvePfnjYvHu0z+CJ/2IZzc5C2aEzuub1dfRYHgHVTn9fwRlD4yajVpZFoHjCf6f/dtjDvU9 O+Y4buuaTc3NA3WuQnj3dBzny/PS1cQ0uBhdDfpCsM1mFAqG9Xdadbhtc2awrlKcaVOOu5YbjqHo cELzsaz53CMG9uP0fHPaxdPm46c1n1iAqmXCH+rl2EFzyumCYUPnhzviJ7bNnW0zD/Rwb/vYtr25 bWeC6kqkdZF7ntG8X8wcf6XUvuhggsh595e1OLAf8XZg/GHTdRfr9XZxsb7t3iy/0SfR/nG03HSr /qrg5yplOL/W5AbGGxTD+9Wwhhim9xAxwe98vUXsr7qfIjKR50Berbfd4i3982x1tf8xpOmy+7xd vOiWV90mj8lmGL9c3d6sussvS4qHTvy2gofl9ma94t+b7c3fSwz6X3+uN18/rddfF0/Xn+/vwKk/ 8/1L122J5HbxZvl5sz74/fsX/Hvw++nN8nZ9fXAiF2N/b8bBbdeb5d3i+c31/abjWN/e333/KOj/ AOT0CO5smr4y08D0n5lplL8z96nuPzTTyO8emqH/5tynllzvP2RmFY5/IKX7hj35XCfPfvPJPN/5 6xJ/8uHvMLvPEeRj2DTKN+Tda95S5n1e3nzlHVHeWOTdvv0GHPnavybzPFIs4N1LOK9o1QGB/TqS b9KcT83yM+zEsCwNOzEMMqywe2e75wIz2a1P2LljJ5y6/dPo0Mlu3rETziW3s32HefjgX7AaHewN CmVuZHN0cmVhbQ0KZW5kb2JqDQoxNzMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggNDk1Pj4NCnN0cmVhbQ0KeJyFVE2P2jAUvOdX+Lh7WCV2YhskZAkCSBz6obI9VXsIiaGRihOZ cODf13kTdpdUSiOBNXhm3kceL853652rOxZ/9025tx071q7y9tJcfWnZwZ5qFwnJqrrsBkTf5blo oziI97dLZ887d2yixYLFP8LlpfM39rSsmoN9juJvvrK+dif29DPfB7y/tu0fe7auY0lkDKvsMRh9 KdqvxdmymGQvuyrc193tJWg+GK+31jJBmCOZsqnspS1K6wt3stEiCY9hi214TGRdNbofVIfjBz0N 9HBkhv0Kp0gIZty89fI7Ud515e/C9zIuwEsNoRxIEhJboDmhdAm0BBqYKwN78vs3qyy7G9KxNp+T ycbJyA3RJJJR0MqMkB6Q7hFPkLbik+F5QhVwjmYo8RB+PgrPOSpUFJBzJKOoF1zMgBQhORgiGTno ZkBrIOoaDwehJRC6plZA6G/4cbIITc3jWoH92EM1LkIP4bcUYobwOgFCeC0IzVGEToFQhEbxK7yw EHoytZwseM7BVg+piXFquQaNOpNKhBDT1aeSRKmcYa6HKRSbx7nmo1ipXAWeCGX9x30D9y3YuZk0 pRkMtHTaVMNU4/WGyZk0nWOyhPps2v/j+8X0vk7Kq/dhk9D2ohXSL4/a2fcF1zZtr+o/fwEMamcW DQplbmRzdHJlYW0NCmVuZG9iag0KMTc0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDkzMTY3L0xlbmd0aDEgMTk2MjAwPj4NCnN0cmVhbQ0KeJzsewd8VFXa/jn3TsuUzEwykzZJ ZpIhk0ACAUIJRTKQQi8pA0kgkJDQVARCEWli1yDqKhbsvYEyGUSiWFCxd9eya8XVdd1dcHEtq0iS 7zn3nRMCsn74lf9++//lJM99nvOecs957znnvkMGxhljblx0bFpJ5fixr6/pO4Mpn33LWMqK0jEl VcGfgh2MfTGJsYTXSsdMKjYteOBDxj5uYsz45diS0rI/PYOqyn4dY+pXY6dNrVzUNOJcxtpTGb/R OrYyNEZVe//IlK05jJW9P7Uyf+CPH773HWP8d7hrfePihqUZq4eWMpazAgOY1rhqhS98w763GKs5 xJg+df7SBYu//36ylbG8fYzFpCxoWL6UpTI/7l+F9o4Fp581/9J7y/syNgd1yiYsnNfQdODjgfvR /yyUD1kIg+0BYyHyW5DvtXDxitXsQk8+BgxbYPhp85rPKNx7Sgljz9zLmG3C6UsaG/rflYH53VXN WPqUxQ2rl2YM6PUk2rehve+MhsXzku9ftpaxNzBp26ilS5av6PSwCzGeQaJ8afO8paftUOCvwRhD LwcTvtW3Vcz74fvxc+wjv2PJJibSnr+ue0Xwy+/vPO+nw+2bYg4YH0Y2himMEtoZWAfj+8y3/nT4 8K0xB7SeuiX1H8JiD7ANTK8ZFOZg+WweY84rcF+tii6XX4FSk36rvgBdphOrb7ALFWZiil2vKIpO VXT7mdIZZNs76b6MTa70+VgQ00mjMRhvVgI+xm/ROt2tjxUzRe+xR0fDX8fTu008l1+XdLVsu66E NZyw7ADbfsyMvzw2/8+S+gDbrreymT/r78jR9oru5PrS6m5mRq19zi+3MbyH+/Y5cR39JNZ4svfT 7pV5tB9d9XF+eICNPVEb9QtmP+aemez+X3NPYzo75dfU70k9SST1HTbr17bRDWJb1bms9iTr1h9z v59Y3cm0U5axrF87rv+XSd3HBp9MPeErqfm77IJfcw/+l853uu53xzH9bD1RfUMT29r9fj8bS+HJ PbOu+tG+xDNUXjq2XzWDlZ9MH8qDLOPX3PO/kzDOLSdbV72JZerbfv4M1TNZb/UWlvkze29W898d X0/qST2pJ/Wkf5+k3MDNJ1uXd7I+WptebI+iZ9cebxdJrWEXA7n/Y+Nbzkq1fo90fn9S9RezC4A1 /1P3P1FSB7NN+pX/m3f4T+5/hPX61939fyfh8/o44EGgOZrvD8w7rk7Fv2Z0Pakn9aSe1JN6Uk/q ST2pJ/WkntSTelJP6kk9qSf1pJ7Uk/4/SWoUqfSdMx5EDkrNYzou/u29D/MxHRN/ObExPwuw3qwf G8gGs+FsIpvGQmwGW8NuZQ/4HL54X7IvrbNT69WGVgGWw/JYfzaIDWOj2WRWgboN3eqmoi7v/A73 alan4/qY+ljXqNIY62xUnv1s7mcNn435bEz0W3cB7ZoTvfZho1gJ1LjjZ6ROUK9Vd6sh9FutfqfO wPidLI4lYY4Blo0x5WP0I9G2FHOYwWrZbNbEFnKF27mDp/B0nsOn8Vpexxfx0/kSvpKv4uv5JXwT v5Rfwa/nu/he/hR/jj/PX2EGfkC759fHfy8QeSX6LUKF/XLi3UetyeuADerZmtZmAT6gHlS/Ah9S v45OU8ysezrxLFnXPJmcKdSKEwzjvzL//9tJ7SYxY3W2OgfXn30j8SRTz374T9dDcGzTnNl1s2bW 1lSHqioryqdNnTJ50sQJ48eNLSstKR4zOlg06pSRI4YPKxw6ZHB+v755OYGsXv5Mb5LL6bDbLOYY k9Gg16kKZ3ml/rJ6XzhQH9YF/OPG9RV5fwMMDd0M9WEfTGXH1gn76rVqvmNrBlFz/nE1g1Qz2FWT O3wj2ci+eb5Svy/8aonf18Zry6uhN5f4a3zhg5qerGldQMvYkMnIQAtfadLCEl+Y1/tKw2WrFraU 1pegv1aLudhfPM/cN4+1mi2QFqhwjn9pK88ZxTWh5JQOb1WYySZuG1azShuawtPKq0tLPBkZNZqN FWt9hQ3FYaPWl2+RGDPb5GvN29tyaZuDza3PtTb5mxpmVYfVBjRqUUtbWi4KO3PDvf0l4d5rPk/C lOeF8/wlpeFcPzqbWNF1Ax7WZzn8vpbvGAbvP3jgWEtD1GLIcnzHhBRT7HITyqVmGBtGiPllZIix bGoLsrnIhDeWV1Pex+Z6IiyYn1sTVupFyV5Z4g6Jko2ypKt5vT9DPKrS+ujvqoVJ4Y1zfX3z4H3t Nwu/KPeF1UD93MaFghvmtfhLSshvVdXhYAlEsCE619LW/vmo31CPSSwSbiivDuf7l4Zd/jFUAQaf eAaLKqu1JtFmYVdxmNU3RluF80tLxLh8pS31JTRA0Ze/vPoRVtC5v3WQz7OzALu8RowjnFCMhxIo balumh/21nuasD7n+6o9GeFgDdxX46+eVyOekt8R7r0ft8vQ7qi1wtyOqy0ri5kbs0y+asWj1oin BYOvDBf/mJEocOBxaVnxRMeM9FVzD5PVcJdoDaGO6QcZNat4nChSRdPicZ6MmgxKvzAkT3RM+qyw qVtfDhi6xkT3+adDo9piQL19pfNKug3wmE710QFGezvxOBXhi+iN0cIkHuc4WaRmYefCpqAbzSSe YpIvzKb5qv3z/DV+rKHgtGoxN+Fr7flOrPRPLK+t1p52dJVUHZOj8kLKhVkGimVGKcYaLMv1yMeq 5cdq+a7suOOKx8tiX4vJP7GyRXTuj3bIfNhBmLQhML5hU2HcIGzNMpxu/rIGP14iZS0NbZ0b57a0 BoMtS0vrFw4XffjHN7X4K6tHerSxVlSv96wRt4pjE/nEqjF983D2jGn184vLW4P84sra6kccjPku rqqOKFwprh9T09oLZdWP+BgLalZFWIVRZHwiI3qqQMak1fc8EmRso1aq0wxavrGNM81mkjbOGtsU sjmkTYFNR7agZhMJDylpIVyM47bU1yQez7qahS31NWJzsQQ8SvzyMPePYmHFP6qVKwZr2OyfNyZs 8Y8R9iJhLyK7QdiNWBg8gcM54kxqqffjnMKCqmYeTktRFV362jo7q6ozXvUcrMnAUpsF1FaHY3Jx 9uuzJqDeWIF6mMeGNzY2iHGwULVoa8wa31iDZSs7RJXx4Rj0EBPtATXKtDZiOaJRI54NHqDWfiMy 4Y014ZpccdPqRTXacnaE2Tj/cDx26lMfEDfKr2mJ8w/U9ia2gjnrIkExGBurrCaLB1ncrIacZLRi 5I1+FDXW++BtHWusxFKns9TsIcs8HIm6wDwNZk+0kIlpqVkWmzkc0w8d4ldoSz+xJfVZxpoaGryW uyhaAfd2hC0YUaCbK6MN4B0UjRdjwe9FGKqo+pTopryNVfhX42QRg9Z6MqI4bMsa34DDn9pbYPEX ysYmcUZYon3sI6tRzNwKv6tZVW2d9/jPyuiW+ub5xctBLEzmeQQLm9W0HG8Iz8ztm2c63mrTzC0t JtuJG5C/TLYuFkZfKd4ajEViVF+bcv5DMUl8AsR5UpwrxTlSbJTibCk2SLFeinVSrJVijRRnSbFa ijOlWCXFSilWSLFcimVSLJViiRRnSLFYitOlOE2KU6VYJMVCKRZIMV+KeVI0SdEoxVwpGqSol2KO FLOlqJNilhQzpaiVokaKailmSDFdipAUVVJUSlEhRbkU06SYKsUUKSZLMUmKiVJMkGK8FOOkGCtF mRSlUpRIUSzFGClGSxGUokiKUVKcIsVIKUZIMVyKYVIUSjFUiiFSDJZikBQFUgyUYoAU/aXIl6Kf FH2lyJMiV4o+UvSWIkeKbCkCUmRJ0UsKvxSZUmRI4ZPCK0W6FGlSpErhkSJFimQpkqRIlCJBCrcU LinipYiTwimFQwq7FLFS2KSwSmGRwixFjBQmKYxSGKTQS6GTQpVCkYJLwaKCd0rRIUW7FEek+EmK w1L8KMUPUvxDiu+l+E6Kb6X4Roq/S/G1FIek+JsUX0lxUIoDUvxVir9I8WcpvpTiT1J8IcUfpfhc is+k+IMUn0qxX4pPpPhYio+k+FCKD6R4X4rfS/E7Kd6T4l0p3pHibSl+K8VbUrwpxRtSvC7Fa1K8 KsUrUrwsxUtSvCjFC1I8L8VzUjwrxT4pnpHiaSmekmKvFE9K8YQUj0vxmBR7pHhUikekaJNitxQP S7FLioek2ClFRIpWKcJS7JDiQSkekGK7FNukuF+K+6S4V4p7pLhbirukuFOKO6S4XYrbpLhViluk uFmKm6S4UYobpLheiq1SXCfFtVJcI8XVUmyR4ioprpTiN1JcIcXlUlwmxWYpLpVikxQtUlwixcVS XCTFhVJcIIUMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gMe7gM e7gMe3izFDL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+ 4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TL+4TLs4TLs4TLs4TLa 4TLa4TLa4TLa4TLa4TLa4TLa4TLa4TLa4cU7hUDUHEkf5UXMHEl3g86l3DmR9OGgjZQ7m2hDJN0K Wk+5dURridYQnRVJGw1aHUkrBp1JtIpoJZWtoNxyomYyLoukjQEtJVpCdAZVWUx0OtFpkdRS0KlE i4gWEi0gmh9JLQHNo1wTUSPRXKIGonqiOUSzqV0d5WYRzSSqJaohqiaaQTSdKERURVRJVEFUTjSN aCrRFKLJRJOIJhJNiHjGg8YTjYt4JoDGEpVFPBNBpRHPJFAJUTHRGCobTe2CREXUbhTRKUQjqeYI ouHUfBhRIdFQoiFEg6mzQUQF1MtAogFE/amzfKJ+1K4vUR5RLlEfot5EOUTZ1HWAKIv67EXkJ8qk rjOIfNTOS5ROlEaUSuQhSomkTAElEyVFUqaCEokSyOgmcpExniiOyEllDiI7GWOJbERWKrMQmYli qMxEZCQyRJKngfSR5HKQjkglo0I5TsQ04p1EHVoV3k65I0Q/ER2msh8p9wPRP4i+J/ouklQF+jaS VAn6hnJ/J/qa6BCV/Y1yXxEdJDpAZX8l+gsZ/0z0JdGfiL6gKn+k3OeU+4xyfyD6lGg/lX1C9DEZ PyL6kOgDovepyu8p9zui9yKJM0DvRhKng94hepuMvyV6i+hNojeoyutEr5HxVaJXiF4meomqvEj0 AhmfJ3qO6FmifUTPUM2nKfcU0V6iJ6nsCaLHyfgY0R6iR4keIWqjmrsp9zDRLqKHiHZGEopAkUjC TFArUZhoB9GDRA8QbSfaRnR/JAHnNb+PermX6B4qu5voLqI7ie4gup3oNqJbiW6hzm6mXm4iupHK biC6nmgr0XXU4FrKXUN0NdEWKruKermS6DdUdgXR5USXEW0mupRqbqJcC9ElRBcTXUR0YcTdALog 4p4LOp/ovIh7PuhconMi7hBoY8SNw5ifHXEPAW0gWk/N11G7tURrIu4m0FnUfDXRmUSriFYSrSBa Tl03U/NlREsj7kbQEursDKq5mOh0otOITiVaRO0WEi2gkc2n5vOImqhmI9FcogaieqI5RLNp0nU0 sllEM2nStdR1Dd2ommgGDXc63ShEvVQRVRJVEJVHXEHQtIhL3GFqxCWW95SI6zzQ5IirL2gSVZlI NCHiQlzAx1NuHNFYMpZFXBtApRHXRaCSiOtsUHHEtRE0JhJXBhpNFCQqIhoVicP7nZ9CuZERZw1o BNHwiFMsjWFEhRHnWNDQiLMaNCTirAUNprJBRAURZx5oINUcEHGKifWPOMXezCfqR8370h3yiHKp sz5EvamzHKJsogBRVsQpvNSLyE99ZlKfGdSZj3rxEqVTuzSiVCIPUQpRcsRRB0qKOGaDEiOOOaAE IjeRiyieKI4aOKmBg4x2olgiG5GValqoppmMMUQmIiORgWrqqaaOjCqRQsSJWLDTPtcr0GFv9Lbb m7xHoH8CDgM/wvYDbP8Avge+A76F/Rvg7yj7GvlDwN+Ar4CDsB8A/oqyvyD/Z+BL4E/AF7ELvH+M Xej9HPgM+APwKWz7wZ8AHwMfIf8h+APgfeD3wO9sp3nfsw3wvgt+x3a6921bwPtb4C3oN2253jeA 14HXUP4qbK/YFntfhn4J+kXoF2ynep+3LfI+Z1vofda2wLsPbZ9Bf08DTwHBzr24Pgk8ATxuXeZ9 zNrs3WNd7n3UusL7CNAG7Ib9YWAXyh5C2U7YIkArEAZ2WM7yPmhZ433Ass673bLeu82ywXs/cB9w L3APcDdwl6Wv907wHcDtaHMb+FbLad5boG+Gvgm4EfoG9HU9+tqKvq6D7VrgGuBqYAtwFXAl2v0G /V1hnuK93DzVe5l5gXez+S7vpeZ7vBeoWd7z1ULvebzQe25oY+icbRtDZ4fWhzZsWx+yrOeW9Z71 E9evXb9t/Qfrg3EG87rQmtDabWtCZ4XODK3edmboUeVCNl+5IDgytGrbypBupWvlipXqtyv5tpW8 ZCXvv5IrbKVjpW+lal0Rag4t39YcYs3Tmjc2h5t1I8LN+5sV1szNbZ17dzZ70svAwXXNNkfZstCS 0NJtS0JnzF8cOhUDXFS4ILRw24LQ/MKm0LxtTaHGwrmhhsL60JzCutDsbXWhWYW1oZnbakM1hdWh Gag/vbAqFNpWFaosLA9VbCsPTS2cEpoC++TCiaFJ2yaGJhSOC43fNi40trAsVIrJs1RHqi9VdYgB TEnFSJiHj+nvCXr2ew55dMwT9uz1qHH2FG+K0tuezIunJvMlyWcnX56s2pNeT1KCSb3zyuyJryd+ kvi3RF18MLF3vzKW4EjwJahuMbeEyVVlGheVEA8YrM11coI/UGZ3c7vb61ZKvW7OnPudh5yq+0nH 6w7Fbud2e6ddCdpR3R7rjVXEpTNWDcYOGFpmt3ltirh02tSEoA0W0WO2dVpVmd3itSihIstUixK0 FBWXBS19+5cxlfs4Z9wBUk1iFNztLcO+3pnA9Rzv89aqytzciW0mVjExbJo2M8wvDmdVimuwvDZs uDjMQrUzq1s5v6ymlSvFVWGX+Iutlr9g82Y2Jm1iOK2yOnxrWs3E8EaIoBCdECytNYGNqcmdvXzl 8tzcFbNxmb18Ra72ixxfKXK5wih+l69AXvys1PIs9xcTVQPNWY60QhpX/HKr/+uJ/6sH8O+fWpn4 ksHoTuV81qScB5wLnANsBM4GNgDrgXXAWmANcBawGjgTWAWsBFYAy4FlwFJgCXAGsBg4HTgNOBVY BCwEFgDzgXlAE9AIzAUagHpgDjAbqANmATOBWqAGqAZmANOBEFAFVAIVQDkwDZgKTAEmA5OAicAE YDwwDhgLlAGlQAlQDIwBRgNBoAgYBZwCjARGAMOBYUAhMBQYAgwGBgEFwEBgANAfyAf6AX2BPCAX 6AP0BnKAbCAAZAG9AD+QCWQAPsALpANpQCrgAVKAZCAJSAQSADfgAuKBOMAJOAA7EAvYACtgAcxA DGACjIAB0AO60Z24qoACcICxJg4b7wDagSPAT8Bh4EfgB+AfwPfAd8C3wDfA34GvgUPA34CvgIPA AeCvwF+APwNfAn8CvgD+CHwOfAb8AfgU2A98AnwMfAR8CHwAvA/8Hvgd8B7wLvAO8DbwW+At4E3g DeB14DXgVeAV4GXgJeBF4AXgeeA54FlgH/AM8DTwFLAXeBJ4AngceAzYAzwKPAK0AbuBh4FdwEPA TiACtAJhYAfwIPAAsB3YBtwP3AfcC9wD3A3cBdwJ3AHcDtwG3ArcAtwM3ATcCNwAXA9sBa4DrgWu Aa4GtgBXAVcCvwGuAC4HLgM2A5cCm4AW4BLgYuAi4ELgAtY0eiPH/ufY/xz7n2P/c+x/jv3Psf85 9j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufY/7wZwBnAcQZwnAEcZwDHGcBxBnCcARxnAMcZwHEG cJwBHGcAxxnAcQZwnAEcZwDHGcBxBnCcARxnAMcZwHEGcJwBHGcAxxnAcQZwnAEcZwDHGcBxBnCc ARxnAMf+59j/HPufY+9z7H2Ovc+x9zn2Psfe59j7HHufY+9z7P1/9Tn8b55q/tUD+DdPSXNmM2a8 mbGOq475rvY0dipbzjbi50K2mV3FnmQfsLnsPKit7FZ2N7uPhdlT7EX23n/xO+wnTB1n6Rczq7qb GVg8Y52HOw923A206WO7Wa5CLl7nO2rpdHR+dZztq46rOh0dbYY4Ztba2pS3YP2Gt3cexvsV+c4h Iq9cBG3XWnxtvLljR8c9x/mgnNWymWwWq2P1rAHzF/9nYRE8cxo7nS1mZ2i5M1C2ANf5yM1BLZwl mj5aawlbCjSzFWwlW4WfpdDLozlRtkzLr2Rn4mc1O4utYWvZOrY+ej1Ts6xDyRotvxrYwM7GkzmH naspyWQ5j53PLsBTu4hdzC75xdwlXaqFbWKX4jlfxi7/p3rzMbkr8PMbdiXWwxZ2NbuGXYd1cQO7 8TjrtZr9enYzuwVrRpRdDcstmhKlj7Hn2C72INvBHtZ82QivkUekX+ZrPlwKH6zDDM/rNmLy35ld 3tqAuYu5tURnuhr2c7u1WBX1o6h5HmpSL/QcRC/rj/PEFZgD6aMzotzV2vyPWrt75Zes0h83dvPM DVpOqOOt/0xfw27CDrwNV+FVoW6HJnWLprvbb+6qe6uWv4Pdye7Cs7hHU5LJcjf0Pexe7O372Ta2 HT9HdXdF/CB7QHtyYdbKImwnewhP8mG2m7Vp9l8qO5F9Z9Qe6bI8wh5le7BCnmB7cdI8jR9peRy2 J6PWfZqN8k+zZ5AXtSj3HHseJ9RL7GX2CnudPYvca9r1BeTeYG+x37L3uA3qTfZnXNvZG/rPWSwb zZj+Ufj5RjYbP3qcSsvVt3CKqMzIhrHJbAqb+Riz4XWfwIbzXbvcJSWmvsYn8CpXmA/BgIlxXhy0 6xTb7pSUIv/uwYbNqnN8G+/7UJFxM8LcovaP21/Lb//4YNyw/IM8/6NPP/7U8fVrzmH5BZ++/emA /tyZ4dTgilWMRpfBn9lPGZwdGFJQMHCUMnhQwJ8Zq2i2QUOGjlILBqYrqktaRikiz9W3jtSqU9sN ygZ/0fQCfXqK3WUz6JXUpLi+I7MclTOzRvZLM6pGg6o3GXOGjsmceHpp5vtGZ5o7IS3OZIpLS3Cn OY3tH+hjD/9dH/tTse70n7aohhGzinqp15lNis5gaEtPSu4zImP8dHu8Q2eJdzgTTMY4pzWnZFb7 he5U0Ueq2019tU+GW/ydh3Ub9C6WyQLspkdYr84vH7I6+CR/W1QE2joPPWSBsEhhhgimCJXlEFeb drVq12AOzxLFeRY+uZc/kPWt1WJNykzzm208QWdlVodV2eF/0v+6X/Vb/da4tIq4kD7EioqK4oYN y8+vq3MmDnNCOgscBwc6C+Dx3Dp6FbLc3KyEBIPm8mw1Q41V/ZmBwJChnPycaPSrGbqVJu7I8nqz 4mN0S9q/OFU1x/tT07Ls3MQjOltydrqvT0qsbi3/hD99SoInVqcarTF8RMeLMbYYnT7Wk6CLWGJN qmqyWza3rxX/L2y7+O9cWF3pLJcVsheCKd4kB5/sddjFxYZLkhUXH+Yq/kYczElxB1HuDqLc7bbk icp5onKeqJwnKueJynmP4jMh69y7C5oFCuDpnagJPrTTHmWbxt/vtGr85U6LYMURtN1q2WtRLCnZ 3w4YYOyl/at0+aA2bmk1VrGig0Xauh3G8+s+1Zw28O1cEjDn5g4jDae6YnX+jMzAYOegIQUZ8J5b rOd0lQ/qp/j9TrGY449KHfcWTm1cNr7jwcTevRN5YMWWxoEJuaP7DJ5VmtPRnlJYOyGyr7hiSPKU rLGnlb92eER1cYAvP2VBxag+bm+27txsb17Vmsn9qsYWxpkHV5yh8PxJg1M76vwjprZ/NLx6pLej MHVoBeOsofOQzqpPxy6euzOVjciNeiU36hXwAeEV8FfCK7lRr+Q+gc/YsSyJ57MMFuB5kfhK3R7e hw1m/Xm/1pjp2NJvHxTg+TR9x7v7BvTPcsUaum1Lgzu6TcUGdrvSFTFvsax0VkVvcgXnrB2/4eXL J1de8+bZhafWlnlMelVnsphiB05dNnX65qahgxuvmDl5efkgu9FsUHc7kuJiXb2zPVV3fn3TbUd2 zHL7+nhi41PiXKnxMdn52aUXPrVu7eNnjw7kBwzOdOxAscouxyqLY152ZjCtKIPHi5UTL1ZOvAtz jo/DhOOTMNv4PWLlsBTyTUrUNynRFZMSXTEpUd+k7MHn/hj4xhqJLfe08UCrnlaJ9MXbckXUiRPt mCVh7LYALp9+16G7O77SHn/WvV/eVL5r0JL7L9zRuu7+5mHK9ff+dFcFPegZd3y5ddGu8ycccY7a +JT4H6uYmboOM8tjq1pTsqNPNDs66uzoqLOjo86Ojjq7TXEGY2LiffE+DD6ljZuCto0BvjfA3wjw QMCQLP5AYyvPBrUaulZ93bJmTCtfO0Yc0dWvPWflZyvdn+E8TqrrdGabqf0qMUNlvslm0utx6TDw iAlHgy4GeorCTTazbmycJ85EszXFeVxxHqep49QYR2p8XIrD2DHA5PRo8+48rFZh3tlsVqsxPjrv +Oi846Pzjo/OOz4673jMe5ctjaWnGTG1nfHxyYY2nrMzszxZHJDRN1L+Puewrtnxn01Gvm3kdNUq TMzYAe8ZMXhNB00uX0pSpsuEqZZp1n3xqZjFOKPD4473OGPa/2i0GfV6XHQPilmmiRnN7PxKt1rv Y0Xs9mBaaqo9SazQJLFCk8TZlmS2CoVZJImnZ2NPZnNfdjC7PlvNtkfnb4/O3x7dyfboTrZH528X 3w7PH8QHJbVx80OZmcPyR+3hZrzjzbx3ZFilq43nteZPF88bu9lJ7oiec2/X1e3rOuiifjlmNw8Z 6hSrQOx2zVtOcQIe3f863WqdyWq0Fs4+r/a0+1cVla65b97ItYM73nY6dTF4R9xgSYgzxw2fNbdp wDUH7phed9/BKyacO680xaybHZ8Wbwr0C0xpeWLJur3nl6Sl8bMye8GNJpMjNa4jPiWQlplkrdt+ aMv1h8MNKf7eKZm0PnTT8M7NZ20PFQ3gfmvURdaoi6zRJWKNLhFr1EVW4dzUxF4W4X2L8L5FeN8i vG8R54NFvCMSWdCNF0swXlwcTj6JBVHOEsUfLVAg+GGUJfapwAskL2jfa+VvWLn12LcxNtTBIo63 xtvCrdEld3Rj1WV1LbXuq45OTTdsUuqmmVwZSSk+l6l9J1SyWHkmV2ZScobLpEzW1iJUCryPJWc1 KaPan5Za975U7YcVg9TR/cWr4T83m7a7KHFq4o5ElUVdyKIuZFEXsqgLWdSF7FGciebOvbvhCbOj Qpsuptl1EGb9bDK8Wo47xp2RmNx9tEdHKEZl7PyKf45R5bDqR/B6P/nhpGE4Tj45LdZfEbOHD8TH 5CS8u/TRdxc2fW63N7cYnUGGk1rceXSkn6eWLKlIHdov02LUKyreUKZkfz9vZn+fg6YQH8PLJm+s HRBjd1qtzuS4BMSS9ji7s1/5aPVmMR+xC6Ln1w+YSQGbG3QOENu6v1hd+UJlmKOeNkenZo5OzRyd mjk6NbNYrFZ3dkWG2eGpcByN84rk6wfrCFfyeCCQzU+wkKLhndtlMHKekKD+YHRlevx5CcaOXsev Jv6SwZGYkZLiizfa4joq+WtOY6o4yg0Os3JR+1ldh9rRVfWUUhRjNer0MNhSEts7269PiafZG3Jx eo9k24OO+lFLRym2/v0T8/PN/ZKSUtpO8tUrJp/ea4DVahZ71Sz2qlnsVbPYq2bhTbN49IgCg8li HfQaUm5JSrTlJw3oZ/DmlHtDcisWxSEkLoDPZCyHuNjRpZzDTskvKBCRcreV6+ciOkaczP3HvBG0 QJkXCJ9qTjXkmlze5MSMeJPSUaBa3Gkud7rLonSM5diXyUlwZJ5noa9/r6QYfqaeX2hJ8QaSF9s9 8dajG2DBT1uMZqOqQ+CDjyJbu+x39+llTcnxHJmh3p3eJ9kSE5/mjp57G/ROdgq7YGe23e6KOlNj e5RtGh8SznRFnenSnJlu7tdvoHDmwCS7uKDiQIdVKFQZKKo4WHphhbmfPVuXLN6aIjjQ3Cec9zPf 5RdEwwPyFNafPyHBfQJ/pauJBYHA0TWp22Bzp9iGpmT7/e6Ohb7RqYqimOK9SUneOFNeSkVatjfN yYenDRk4IIkjaIj3Jif44kxjXfjsZUkbmK3sH7Z+xLhrJhz5pmtF3p+TaU7s7W1/YVBjfV3+1G1T lSfwyQRxBzaj+N+unQd1X+ozcCxks3XBFJfwgUssKJcIDl0iOHQlkZsKgjE+1p9txGeX9Khz06Mr NT362k2PvnbTo85N34MA2syS8ZK1V/rbeK528HQPEuuOO326PsxqMWK3iFn35YSrPt5y5TubSiZs +XjL5W9vLt2VPfO6pUuvm9M7UHtt87LrZ+co19x0pHXOjLu/v3Xr4R1zpt/1zX1nPL5pStWlexY0 7900ueryx0Q8jNPneey/VNabrW7tZYhOxBCdiCG65QzRLWeITsQglkCiM024J024J81htfFJ/8He l4fHUV171q3qfa3qfV/Uu1qtfd+6ZMvaZVneJC+SN4GBAN5twOxbQgwT1ryP5XuQTAaSkASMNxmS if2Ng4ck5pEFmyRAyOTxACcOD14eS0Ddc86t6pYsyy/Jm/nmn5GPfep2dVf1vb977rlnK7cfPS4/ lvcyQgwsiwMqlQGGqT9gHzbMMKwkAeHPt60isw0qxQyzmDsp7vnuNQ9orWE3qp9SD7GXDl5+1UDq UMvIWNnjjy7e3BXlHtjw2NWtufLiuoCpVjuza68dGbqi1jT1abJ7EyONWKGHEdczncx9YoAvFxo0 0OsGHEUDHUUDjqoBZ7kBZvlICv3MVFZAKKAlyNAIMjSCDI0gQyNg2a+vnAdb+vBWkYiisw0QOBQe dspKhlrQ6Dhe4Dc2yauEut3l3AWQOJwBTnYfnVaHg9TGE/F4wXHQq2zRgCds0yv22DPty1t2FMAC R8Ja1eHp37E4EVmwtilUm0nadpo0uanOJe5szX3f7Ny0IAhKBjYkLSzxqtqRbGTqV0UQwSxVcsbG lVsWdmwearaZ0q2Lq3K/j/q5OwYud6pVuYFwyxLQNt35c9wmWDe9zDtHmY78uwfNPBnokCHqkKHr kHVNhwxVxyRbJqarRauNDFSLsCtHq6PVBq8Lr/WiAvfyPDK4xIvT4X2erUItfsBLN/VjB9zy0SYd D5vRADOUv0ASTAOYsnFRL4QaSIOoN5ABAWtOdNhqEBoERyvY/Yc6vMrUMsckScnrEKbgnIBeTTo9 xp/jUVSnLTKL9MasBao4zzyoLZoLs91cFbdp4Z6vjXVsGWlx6mHr15hqlmzraxxbGK1eevnVly2t abn8vuXpkcFWq0rBciq9Wl/ROdZcv6TWU73siquvWFZDvrDmv2yqdoRKXLGgw29RlyQjgYYlNQ2L W6pq2pdvGxq+aWXG7A5a9YLLagHv1xfx+ysXxOoXt1bXtC3bBnNkhrV+BiS/hLnkiEtET0JA1A6i qfQ3L3zcSIX8sUMo+SoLOk1+eW1Xg2n3AQXnR2n+RLroMk0brwV1Rr2lM9TVe7BgWUBLdgW526kj SD2lz/6xKIgbNYLPapWCaWgBfhs09bVgN6WZh0X/+gwJ4aoN4SoOoeiEcO8PodTgc52iMNNOB0lj HPKAHfKAHfKAHfKAHfKAHc+zPNqwaM1j8ZeohVvo4kv5pd5puaHGu6zB09MiMkYuNLJssw1JxbWL bp7c9YVnb+yUnEWrpmzZrt7+XcNpCk0Y7Mg3dx+9eUH7tYf3cJECHJ9/uPrOVZmy0VtHOOdMu7gN 7Km3AJVWZvOBeCupnsx/Ii5EoY/B9GiwkawgMZ6eiZESFzZSJcQVwkamimQqSSZKMhHSsLR0aaRS z810VGB3z8Ko4A+GCmWKFe0frtCKx+vrZ9g/M1oOh0qtvE3B+1KBYNpnUuQ+YP/CmTypULjMZ+Zy 31YRIR4KRq1qlkQIsXFaWyzgC9u0HEmxxM+prBF/IMITZdwk4J4tmLiffV5RaCuednpMCk5j0n92 QtGsN6OJbdZ/9qKiRQdtpcnjRP2/FjRVlvsx2Nsi86wYMi8ILqhYwOm1zloDTHstyk4tik0tj2qo dpJ8LJqYRMLMEAOD0sU0y1qsWbagmmVJwSNVe82TrEa0Cc4fMbV8LdtyrJYw4GnXlneUThKvaH6l hJSUKPxny/vaXjcMKpiKQlSFOtpj28bHCubAifT4WJMcYamGzWEc7E6MyoKFVKeajqnV1Mm2gXxG QeVKLSkeBzrkXJb3eT1BU8t9w907hjPtO795+fWOqsVNbRt6qwwaMH/U3gUrL63d8KXl8W/c0zmx ILhqSceWNpfBAPu3YXW2K9Z1acfA1r5YV+2SOq8/4tfwbrPb74n4rWUrblx+wpnJprqWLegEdB8G dF9VbmNK0e48BAtDF66XV1S9vMLqZbzwNcWrfpJ8InrtaTSu0iGMOyL+aVzPaZ6GI1mdqGXsuvq6 sEJZOUmUh+N93i5+oAma+5WDdAUChM6mou05jVlxDSbsFy5GSTgLppVacDiosfFqzaZ7x9K9XV0J jcVrB2NSpbaGXG6wLJP9PT3JjftGkt+z164UQ+3iokTn9QvbRxvc5J1dL9zeJcSbU1fDelQoYD0q GzWSm6eZejvVGOEX3/bsrkW3TrRZShdU5x5eNtK6aS+s2NWAWIh7ialj7trvo7uZ5Mq+Jbuw7x5E l2WOgN6fzg/k5c9KAT5WLxorTMTkfico6ow9wegkYQ9a+7g/VKGu1xp7qsomiWq/dhA93vQ5yorB nRPFUN6skK1K2spUMwO2XIhVqt2t/aMVG756SV3HtodXpYc761xaFWsxmhOtK5r33BQWx1qbVmbT BnRcvi64BaM75reIew/suuOH17XwnhKXyeqyJILhZPjI90ZuG01H0xGN1Y/rdD3g8pjyKibONDH7 xGC2hei9Tbg6m1CzN6Fl0ITS0YTC0vQC+ZRhmAoJtQoZrAoZrAp5xVbIYFWgQOms4S59U8KrMJVi UbmrD5a64oBpUDmAmxkVp+ys2C2Vp6LrN3MJgmlWlCouHp9pqDdwj6kFnw3TQd0Pr9l090iyeuN9 64ZuE9W2IMqU9smFN3RmQYJAojrCbWJXwl0QoD2DKwdv279x5wu3dy9ayOoLPszUIpCdjdeLnbde ArK0sArRGgO0HgatlmZqme+JpRX12fot9ZwVV5M1hIFQa7gM7agyREtKkVD9BrLw6aHO9DfSLAb/ D+Fqq1XIwqeQZYy+1tOjpOAUiF84XHbyZsW9CvaYgryiIAqFr+L1eJ/r7HrTVhNr0p71UQEbmxkx lhblG2lJ2GiehC5QVSQ8Q6zs5wsfa0/UU0DV3MMJ99Rzga6tw+JEb4VBrVdxLKfW16/cJm55antz 67YnNl3x0PrMk9y1e9rWtpeAq5gI91+zstzusatNbovRajbo3S5r+3WT1+08esuizh2PjlpvfbB8 4JIG3Dlj+b+wdyqvgZ1z4jkHjwuQLjyvrLW8BW3lldWZVxYmLz4+V1kam8y/IlowAhjTnavv9sTP VfaEBvgeavFXo4eXPlHzgbTGak7Mipva5bjLTIs/IsdQawpxU/ZOhVKjUtsDKW+sNmR6SaPXKi3m lzSgmlwhq+YmnkdVc1Ok56q+yIKoQcMpzVanSanVa101w80b1YLHGg19/geNHnWSXsPZQ1GrR1CP jX9xZcpoNli9mIWryz3A3cX9T6adWcysY14R7ZZMN66ybg0MuTvEW8lAd00WrAqEICuvLzi+dRjf yqqHoCkazRYyMORVmCu5GrUapYeneB0TjdDI1Ki9XnVNRoEYi7UI8ih+xWiIh8tGS2OiHo4xc6Wa a+z7tWHZu3b7+kbuvdae0tCCXzX2rflVaEhORGSl0PRpSfWna04huE6w0tFOF+AkfyoNf9MFhqgD xg6HtBXEEyrQZw6n7FUVZK4BttfaesqllQ2OF6mNF7dTTNjFEwkTJ7/i7rKab4n4qsduXtywyWtx dtT/YeHWpeW1X3hy21UPbyzjw1WhqorqWDBau/aWgVR3kPCCkMtdMlbZXeG8ZE1VT4Vz2brh90Ip l/b23f2XtHu5nZFgdKRi8TXLyvwOS3kgUs7q2HDbqpb2rSuqYuKq2nB7Y43bPVDWtj4eG1sweN3y jFYTzn2wdnOosTe56tJgQ8/UeHOW1bgzqaS9Y6G/sh3l+2Gw/p+AnbmaufZgtpaUTqdCZMGekSOR cyawLTsDUsCbhr5p1JuqDT2+p5Ni3YFSNzi7qiOZvmiXe4CqT+rkFmOp0mbcdH7Al+4m6jmikJLp aOee0FikPddV3lvZfn0nvKRhssJW3H1v7+q9A2F3QZ5Z8+B4Z3R0xdS+wpmZ+29/b9uld21ATXlH /i9kWFnB2Jkwc/eRbGQosiXCOWRb7jzr30qPb83yEiSv4AV2G+Nj7BJSdvkqu/yuvQCpHWA6rAti jhofJDvo5nspPqfPpWVtKO8sc0fDrbjtojCCFJL22QBYy1qa0/ivCAF3eyGuTCqbS1NN8A9GnH81 9wCZgBFHmUrmzgND1Vg1QI0FOH6I/Y4VFDuWE+AAYvhMfdrAyJ+bEUiXxlWMqIPuE3VuN1NdjmMs hzEeSAZ7bbCT7lfSVQojFWpqCvasNFoYq/I859lxvkd03rCHA+JEdyjj0ioIp9aqVRFnuCJgKig9 xKA03dJSap7Yuzyt0RkFixGzg0pbpqeXe/pCOKR1cD2sg1rmIdGQrSepKlIlWsggmEev0MFVydtf FY7eQI90+6t6gU2A72yQMbh43giWhseRyTAIibREHCV6ZbLX1yUUloelCZYHGFtg3dM9ofqtghQU xeBvCtFfr7GWeLwRl1mVu322fJDlGou7xOUusWuN5tzz5GqjnoZ5OLVRSz7MGS9cJp//nOzWGbUc bKpag4vPPZ+LCXZZd5B2wMzOiDQHtIXmgOZOskzLCPnkoI7voiOWBWDunM8Fku2+sGtyL5SvgI2z hDkrei2YH6F5+jj1ZhPUld26lHRdmOuVok8zcsJni/otEHBgnDZQLeUKaNaAJgyomtOBfB9ZgvGC Je0Xps6l216QYn+BfAJKlieq5/r7wPhWicaOvvauTGNvZsA9Y/5nhn2b5Big0FRIP6G2pA8U/Ucq 82I61C6737KwKF+RVKlVYyvrLG/asQhXjzNsVTvKFpY37SxqVpXF53T4efXAV3obV3VW8pnh/u7o yO7e4LSOjTTN0rEXnuFuB8OE47R6zZ4VQ56KjmRVZ6kVlO9AYQ+CGaxmHhTN0gwik7ej2bN0kcw9 OosBPc8XdiWamp2RlSWfHJE3JtyWRF2mr9Qd7S1Aj1bDdJaPPw/tv2F7sv+17akI4j8M/pXt6Tyg AKD1uDuhN/gmIIT5h2+KvmyKJC0kJZC4kcQNJK4hcTUppdGQOXIOb82Zc0BjPVChI7oZyYzQ+cmM 51kdxlWPmJnBrTBNbnyS1twXAc9Rdq/RQ5QhqyimKMYKf/5aroJ7s3nHd7dv+W9X1zft+M4OODZ8 z9t+xVDv5Z1hb/aKoZ4rOkPk7auP3tm/4MaD2+HYB8fre2/d2FS77tbBvls3NNWO34qxhdyD3KuA DcYWbsbYQrh+jnyopH2mE6NoxNilsAINMNDoshRhmDOu0MsPXTSuMFdYYQ4ZuXhY4f7xZGeHGJ0h LDa716JODQwOZzZ+GcMKNTSs0JXovG5h+6oGD3lv9/dv6+ZLaiO59oIuVLwHMsNxID3Xlran7AO3 P7Nr0S0TrdbUwqrcI8tGWyeup/4zoPWYjNadohfgCurTuGDSOkMhxEKVXBp951KmRhKbGZVxZ+XK uELFXKEyDnxne6xX35YOKvhy9J09fY3oO/ODuOfP7Tufh1mdIEUKC/LirLu476zFZRa0qVN9Pb0J hKh6033rkl2LukuxuNLmE9QX+M+5gwWkyKlUU8Rc8KGFWEvqqgJ0uX+XnGgpIANONNVO7FM0Mrjp 4NY6EjfLQjVdNCMLl1mWOjMKl2VGUBmljPGAzMVEbbovbraHeu2odai6pxt+umgLz3QA51I0VIhU 7FOsSqvROP1Ru7uyrjkyW83EOpqb/MZw1G9QcITb6AgIWq1WYysfaJh69kJFc1t9Z8LMaXQ6rYnW Tg3nz7Evw4h7mZdFQ0V/tn+o/6b+Z/qVMxI3H8kJGyoUHRiess5K6NBEDnldDErZG5q3QRGTkzfo IqPO8T5PPqIpeB2aRQaRmkrwMg73yxqeMbCG8jcadH8Qlgjrha0CJyVpfoMZmj7Hu9JiLKZn5OTM GIbbZyRnpm3pvzc5w75cM37r4sqRRZUOnQKTL+nsysbSzmpvQlyyYlhMpJbuXRrtaU7Z1RxYRzqV tqS+t6JUTNmT4tIVy8QEMS26Eubb6bZFg1awP70hryVSH4vXJoMl6faVrXUbessMFjtvMDt4wc2r HW6HNVLpS9QlQyWlrctxLsL599mrFN9lmpm1B1OMEMnImGfkucjIc5GRF2RGlsoMCqHBacyci/T4 jeecPVVofasltX0Kxa5Gjl6dOiGF9hRzBxjOD0M4CuEY9ioNH0qVO7smRP+NZgtmaG4oGGrvYOzY Yn6nodsZ9dk0Sq1SscZfwpu0qlj/jsWsSYownC4k2E9LMYicbmydVqdVmlw47gcxzsd9H2yC+8Ug WAL6BEpQAiUogYnZBFVSCZ6aXOTTw9JKC8qoBGVU4PgJXZvYOECLhOXFGpRlNIi+itaa6U3ole5e MMyU08G+mYUyRZGaM9g3K5FT3zAd9ntMbfHbnX5BNfhVuvWrbZKP4qzoqWzfu0htC8LKtWiLFsGe FYtbN9+1kS0prM6pPw+tWxgbXcHuKpxBfErAZtoL+JQxvz/KRPKwm6GhG6S5nFiQBKRGgDjkcdrl o23a/KVHSzE/nf9XsQGT22BVCCTBk6SSlCThRFsJiZaQMDazYRINkxA9GyLREEmYye4wCWOQSyvY e8IhWLXw6l1RC6IYxggjvsKZCOP9DVi8lOwN6z29ekkB0hRZGmvLx6jlkJb+ErQfJNwxm5Sm1f7F kpoZW4TV2WCVy/z3EpZjc6cURk8yEEi6TYrcywolFn84/RGrVpFTcJ+xOmvY6wwIau5xhVZnUH/+ Law2V2hMOm7EYNFy4BOywLRTHoOB/RetQcOxGj2iXQc+xu2A9iLmzaNMN6inNhhaIwa/Uo2kAY+x chIPk3iIxIMkHiBxP0n4SFJBUhxpbiEtzaQlQ1rxdyvsZJCXwwd4FHUgrnwI7sCb5dN4FA24keBp c0cv/RyCmeWH+C38TbyCFy2OHr6mN9bbfG8ZKcP3ylBr8lZHz+ayPWXsIjjrHNAiyK8ikmMnstlT gKSEd4WkDxlqpRXtNQloVRFnLqGekbubA/IZTeXtCmXuY87oTAaCpW4D9wOWfYYzelKBYAJe5T5V KsC7cPpKLBruVyx7ktVaQOyDFg17hiWnWa017HH5cVrUNvP0pLD3aLVTO6anyGxTa/UwQ+CpTnm0 WpghIyheLCNzFV6xGh3OVwpWRz/MVwVz51GmCoARML6PeqMcNUZLOXGBPB7GfJ6LOGXd4CicchAt Smsp+q14TStDGiOkXk/0IXQvcFb0+qrKVG9EL/h7haIL0ZQVLEQKXzMILAqvJL/pmMNWeHBi+rmJ 6Yyo1VpIgxJuocaaCAYidr3itTMKvb3E548JREtcuY81xJoI+SM2neLUKwqdEPT6YxZWm/u0zGQ1 KME7V5NLco/CgVMarCZyhDxlshoVnEqnzu0nQyqsEdPbzLlx1B5gBV4P+ESZpUcZL4y1Dle+l6S8 xEWdZxeJm+pNbEJLPLglN3uIuxGBc5Ngr1tn7dX1K4aYftlpxexvWlq0uHjDnDTUBitWFMZri1lf K43qOGxqtuYaVVW1JySwquu1PJf7oYaPBgIlNq2SEO4TlVAS8kUFVe4QLygNNhNpUlh03Fq7y6Tk NGbjVDl72qpXwj5hgZGsAqP2DHeESTMtRxkeRuLAWp04rdipgPdrtZ1aVhsTwGk54O4xJ6jzAh3H 4Hs12AqnxrACslikTiO95LxCZVpaQ7DJnlFpTJqp03YvyiO5J3cTb1VojVpWoRcMajyX20We1Bi1 qi6rV1D7wiUmh8PNs1eEYxZ4rTI5hJDJ5fTwU19V82BpsUSX/4i8rhxn7EyKMR1SxryDfBeA+sbL Myq9uHgxADbrQaYfqPFBIp9FLRCNPeLzRuwak9adDAZTsB5cqWAw6daSXQWrl3veYDEoVQbB8FlT OO3V673pcDjj1uvdGcCpNPcm2cG8xXgZ3XN6p4/hf3lKKjtSqyUd0GAtfu8Olckp3KU0Wt1Wwakj ijv0rqjHHXXqvxKsLc+4X1brNHRZEuvN3hCvUvEh9DxeyH9M7uEeoj6sdz9jm2T3HtEFIuCBm3uY 7KnsKTRJqi8scRNmD/seHGMoiWNMhnCMs19zoVAZjq8sVJLBY2YqGZZOwIBBtXsyqCP+AfpzNYxY zzj3Y6HLscNY0KLlYDFDV9LHcfgzIo5XV7S3luO/q7oryhfBP7xHKbeL7FBeA6hpAbVuuFLq/98D mjIerKnIuF5WG6gy0xLrTZ6QRaWyUNS+xO3hyuk3NDDGg6oSRzV8S80pxOm87IT8sJt6jrN0xT2p d0ZcrhKHXmV08l9UGixuC+/QEWXOOccboHsU3TfKvfAEamBST2l0anxaS5M7d5E3sLdpbg/7s2Jv 9QlnTbG3RVTi8dppWJRzgsX+DDvzJYXR4sLOcLfrnBG3M+LQ5x6Z8QZ0X0Hfwd4rE0HojeuURg+9 gS2cCICioFIJIc/F3oD5W0QOsuVsG2NmTAcZtf6cgsFCRDkjFJbmnq78couQG7fAH/J1WN9K8mki EIzHAyrBwxBYw+cULHsj3EV4Du5ylPiYi91IwVqtn2etFouVO641a5VsfTwSicciWumplTtyT5F/ U+5jIkyJaOdwq+LQSeKoOuPsQf0dTLYC1olUaqYCq9ziLD6SV87ROZcEgby/bmzdGiUx+d0Wj9XA 1S9t9AWbltYQLe9zOH08q9z4Um7V6TO51T8xCHolq9IoL/3Za29s2/b6r36+WaFSwbbBY4+ugx69 Az0KMzVHGYtkQ1pkHwSPh7BnFlpmp6dertTDdHWxGk5d2O/qLXW1bELWZk6Hhbzjaxyu5wxWj8Xj NxLl2vHxcQXL+5x2n6BhN+9i3dveeO1nlyo1KlYJCvbH5Kkzp8lTL2l5HfROpTiVGwKJ28ddyj6i 3FXQoN54Nw8ilz01U5FwhQDUrDMOO3ubindaLC6zyqmzhZ2usE1Lcl8871xlnLuzGDj4p0IrV3X+ OZ6HKWfyf1IGlX3McuYy+hx1hajr3VEbuMa9Wm2+epJwhxYPplLmpkmiOtQ5OPFHc1fhySkaGqmq tOL0SbNYM/1IoLOdq5v2xaRz4GLQdKVkndGDgthobLdQ9cMVgiXlHHyAXBkQN/cmm2J86dj9l43e siIdX37bWMmSkTVl4I8Y1HzQ7QjawA6rCmQWVgR1OoseUDeEPLZKcUVT6djlOxZmt60fqAOz1hzM BHs3tXrt5V1Vdb0Vjp2RzksXphZ3i97azetXxaoXpiy535EVDZvGRsrqRwcWRdq3jdTEuza1tWxc u6Y6tWr1SNK7aHBJKqozahWs2mx0N165eTwZrQwYWI3L7Q6YdRpTpLW8pDnldKTahzZyrLexrSud WiSKUX9dyuXNtE4la1dmI4I/5cxs2LihPJTNitwdIA1RWstoA6tgjGkS/UuWrmzr/e3qOtXqWvWa 3wZKhcBqoOjCpdEVzulHXoUafNS1Wj5kC4XHqDntUqugn8LFVtFLtso7RI1sCNu5sNxS4w2U8BJ6 BKbpbcmdZqtKY1TfUUpUIOTOAK8ipbmzpazS7HO68FWKfsKguTN1rdlqNX8pRdRCwOnymRWlxJEg Gj7gcvpNSpLcYbZO7U8Seym3W3CZ1bmDgRJ6/DYaf9QQXDmz7cd3NWQgEIoESAecUijUelXuv89s B9fnDpIB1OE94HmfpLXuaeas6J4VaI4VAs0Z9DdiZnZwfYbMCCFj3sSGXroNi75t+MCt7QUWNlwm JAUoQrLyCMmRxJDsqsPxXdyBwavE3x0RtTosoxcZjj7rrMV6Hd2QjmWor0kf5YDvZmj1LjZ0jC5T 5sX/KtK8DGvMCyX0aJHTAl00xPnfjc2M76ep3XrxaLViRtBRwZ2suOrZW6576tJ05ZXP3rwXjs+a vOnWwcoVV7Q5Ah2X9DSuaAMbhP3yQx/t3zDyrY+fePBjevzOhkd2r2hwL7n7+1fe95Obm6MLx7ff AXr1ewzDPa50MuXM22I0GiBRP4n6SMRLoh4SdRM0wJ0kRbG3oNdRSeskEO5KwiC0TEqO+KRkQFNy 7CMlA5qS3ZoUFuWbAi68yKVHrhfQ05SK1X95AO4pyPVlM84fk4vXAXq44gmBCFbLJMkeiCxN8ZNE LT32WZ2dOkXjbfjnFJawFCp9EVkmPe1bjskWdqHUF6xhleRTNsTkhSNQL/5xlc6onlqrNuhVKq1R Q0x/wWoVTqXXklKFAbZ9FxgfZ8HOVXZiRE3Ne6wWj6DlXntIpzAGnIKLN6h+yCkUBMX6s69oYYMG tLcD2o+BTLczD4rGVD1JB0jKj366iLA6EVaROFCKHXSrdYSoP8hmDtfEgJgmGeum59mbGL0Ejh69 cj1mmYTGplCoCYSv/HCNQ1W+jAcVnywgJEUnK2hqF+O8p4qPx1KMqP99HjjoUs8q3VQVtwM1LZJ+ TAm2w1SdyW5Wczqz4bORy5ssvroltbRwE9c0q9S4WlZ9oWX8nrFyR/edW06xNRqzXtmHFeBqPuCw BZxOI9Gtvf+ajen0YHNJSbJEYwnYzQ7eZI9GXHVrr1vUvvcrz2w/rbWgn8JUgl79BejVUpDXz8Rm DHZkSKKMRBMkGicxH4l7SYQKbsxFYk4Sd5C4ncRtJM6TuJlElSSqIGkvoVJskaQ443BBwxHi5XoK qY7irSNYZ+ErL+cn85+LfvgEj9PCo3LhMQTIo3Lh0TTi8dnqBKOQZFgBiqFQlibqsC5NUVmR8JZP Er2oU6TDPK8LL9WtoFEnmI0a1PiSt56WI6H4aNKptFTqWJiZWX/I+cVYxSkj0zLsIBES5n5hs9xf eIJr6qyBN4KFpVOTnyutgbIAbLL8/YI99zU2t4Y8RbaG47l/LYT/CK8CNW8NuJ1GzoJemxLszc9f jLDvTTWjJF8C2vmrShNI8nHRmGggiXqa/uOoJB+WBLlBltYG+t9F4KMrWJ6fBOiTcDaJBQhJ01D1 luqbqrnquR/WeZ6toc9Pyjr2EK1ZsE5iMhBrgqyuenxu1VDW/OcQ1i0ry4Zd+F8gFJ6XqBg7x6PU pwl/Wk5unBj75S9pUwIX0Z3zUUopxxo574FxMKHlAiDuq10377+y9crl9WYVfb5SrSvtvrxn4dbh 8sTw9SvbRuM+V9DPtmnMOqXNkvNHeiu3PLmliTxx2de3NAtul8kgeCyCV9C4/Z5Q5+a+9nXZoMET Y83hkBYWRzSZe0jJ1m34Msj8UkD6SdAZlcwC5geiNVVOSpUkRSN6pXES15FOFOYQQt5JqjRYGiIB eF0Vaarqrbq8iktXkSp8mEXLmEwhZivD0gJeCdO3DiKmLaik4dIW1LQWvHxXC6lv6Wq5tIWLtpCW STYtmipiJCZ+GAqp6/9cugxw1uxXryz+VxNYpEuDpSdgi8OycHhRPRNlirNidtqjYWaZqvxQ1fSz 2tyTtsrhvd/amh7uKLNpQftq9Mm2pTUb9o2WsXUPrr/ygVWJ6iu+sX34hrViQnimZMH6bMfaFp+7 cfWC/rvZ55d/5/F9l7XoeYsl6HF4TEqzxdx/45Nrg5Utl969bOWju7tSg1d9+WtdNz9zZWXF0ERd y8bOWEb6H6W+JhGpuCi9zW6cQf8kEdc/Bx1UrCnSZ0jKrjnpaeXTqtJZdEa9fQadnZs0m5C0Jpne miZdt0w/n5v0m+bpYmSwXJSeNjbMQS9LZNoyB334f5fMv72Q+E2UXp+bhE2UppAs4jRZw9bnZpJN vAidsZ2xb7W/J5HjmQvJmf5P0QtzkWu7u69Iv/Zki/SP8zRP/5/S7+cirw1orfdGSs8g+VS+8b+J bgF6cg5635/9O+mOQNf/Eb37/4qCj4aWhj4MfRg+UnKlRJHYPM3TPM3TPM3TPM3TPM3TPM3TPM3T PM3TPM3TPM3TPM3Tf4ZoPpkwjLGLIWytgWG0pJFRMJb8B8ATlDczTuD9+feAT+TXA78s/xbwnfln GQV5JP9T4MfyvwZ+Mn+GUXArGDPwUcYAfE3+OeDj+X7g62h7O9xTYBT5PwKfyL8CfGf+XUYgSTwD d0N+jPIX8ZNwT2hzK/L/DHwcuAV69SfgzXB/C/QK2xOMjrHAZz4GvoZZBXwc3+XWQdsF3/W/gDfn zwKfgFG44Bs/ZFzw+ZeAj0IfXHAVB3w8/z7wddD2wVVngVugbz74RuT9MGofMw798RE2/yZwHvrj Ix64v48E8r8BnswfA34Dbe+j5x/Ba2FErwA/Tq86iW3A4W0mDt9yD3ALjCJOxxWHfj4AvJ+2x/O/ Z+LwXS8Bx++Kw3f9EXgA7hyHb8Ez++iZe/NvMHEYUS3w0XwWOI4oTseSgFF/BHwn4JOAnvwe+HEY XQIQ/hD4SbhbGR17M/TnDaYZ7vM28FHoQyv07TngCZjrVujV48DH6fnL4D6tcM83mVaKRiv08DXg nvxvgSMarYDGO8B3AW6tZDflN9Dzd9H2PvrJu2n7XrwnYPVr4IfomWP5R4Efz38N+Mn800wrIPYm A3IEM9gPKL0NfAKQ6Yc+nGX6YSx/Bv5TGGk/9P8V4KMwrn7AwQAc+9wPaBiYEbjD5cCb8zuBTwAm I9D/XwLn868C98C3jED/zwBP4uehz9jeR8/fC30bIY/Q8yeRw3exwEdznwFfw1QCH2eMwNfR9vb8 /2BW0/ldDRieA94P87UaMHwb+ARt78R34RtfB35D/jTwY/l/AX4c8FkNYwcOq0nHjEPPPwDeDH0e h2s/BL4Tz8Dn3wN+HGZwHD7/DjMO6w7e5VBWx2HdYXs7XDUBd1gP3ALfMgH9+RHw5vwPgffnXwQ+ DuhNAPmYCcAEf8GQz+PvEHry+AuIgTz+BuGSPP764a48/sbibspvoOfvou199JN30/a9efx9xEO0 fSyPvxB5PI+/H/liHn818mQefy/yp/ntzARgWA58JH8d8NF8HXBEcgKQdABfR9vboT+XQf9/AbwZ JO0yqhMug8+/zuyE8/8VuAUkYSeMC3lz/pvA+2kbx7UTRnQUOA/yvBNGNAk8kD8EfEn+x8B35U8A 3035DdDPnTAibO+jn7ybtu/NHwF+iLaPgTzshFH8hNkJPUkCH81XA1/DmICvo3x7/puEhVXwZ+CP 5M8Bh6uAH89/CPxFeuZk/teEhZn6DTHDJ98Hfm/+I+CP5D8Gfoy2j1P+Yv4M8JO0/dP8PxMzXHWW 8DCu94HfADwAd/gT8Efy/w4crw3QawNw7e+An8z/G/Cf5v9IArgiSBKufQ04n/8FcE/+J8AD+VPA QRsDX5I/AfyG/KvA99F3782/DfwYYwR+nFEBP8nogOM9k4DDrcBH89cAX8NcBXyccQNfR9v/m7jv gY+quvK/d978/xOGiBgohQkgBKQhIlU+EDFgUAwIIwqlYSWZJJNkJH+GySQkkMAjBgyQxdGlSlnb RpaytnXV1RWtWjsxbEI1tYhBKYMaUFBpwEghZt2Ut9973pvJBNDS3V8/v3c859377r3n3vu955x7 X4IvAeV3kBvYaO5Gv0chnUDGjX7PQI7G+N3cza6BrAM+bvQonu/CyN3YU66DXMHuhYR/QeYgnU3Y ZhO22YRtNmGbTdhmE7bZhO39aDscMgfSR2kfpUswkg8gncpByJHKAcjRyuuQdcqrkNvoSQjaStBL L+SLyilegrm8wCup90rqvZJ6r6TeK6n3Suq9knqvoppVVLOKalZRzSqqWUU1q6hmHUq/gmxR+iDb sDp1KL0A2QHk64BwhG8hO9lCdrKF7GQLrfUWWustZCdbyE62kJ1sITvZBmytvAnzfQ/SqZyAHInS Jsz3JKSb0nXKR5DbKI09BTKMFWnCWtsgxVo3YQxuSFg75Aq2AnIldrUm4CnSAdhMCCM8A7lL+Rwy jBUM0dhCGNtpyHbMIoSxneUhjO0k34VRfQrpJDkSrXZhVKch62BXuzAe8WSX8jHfhR7vhFyJ8exC jyIdUFp4GBpOQAoNYbFLQo4mmYKaYZpdGNrOQG6j5yHgFkYkt0KGmR2yhWQ7yQ6schgz9UAuV5ZD rhB7EvqFT6JfkQ4o7/AW9Ps5pBM6W9DvWcjRJFPgHS3oV6RFvy3oV6RDJHfhtNRC/bagXzNkO6U7 sLIthHAL+oUdUL8t1G8L9duCfg/zNvQbgXQqhyBHKp2Qo5U3IevgZW3oSzwJwera0JcR8kWMsA3a boLMIRlQ3uDt0HMc0on5tkPPZ5CjgWE7xm+FdNPzOnq+jaTwhXbCrZ3G307jbyfbaKfxt2P8ZZDL lRrIFWw2pBh/O/oV6QCiTYc4M0A6KT0Ss+hAv0KmwE460O8XkHVUuo2eh2APHZiFKA0Dww5xhoFs F2n0MgoyB+eqpTiZ4ryIs8xwyAJlHWRQeUBaCvs5LC3Fzoh4LU6kkDmUDipvYn/VMztkonIUciLJ mewaSOwgkAVKEWSxchYyqPil5RjnEUg3elkOzZ2QYeUFyBblNch2Sncwq7QcPT4AuVK5FTKH0gHl YYxYf7EPMhH1V6DHFyBnKushF1C6gA2RVgClVZBOpQRypFIOOZqkW6mAvJ+ZIX1KL2Sl8i5kFck6 qr+F0tuofhOlQ8qDkC9SOqychGwh2aa8A9kOfFZgBT+VVmAFZ0Iux5jFqeM+yInKMUmcPfZCCkxw AmErIIOY40qM821Ip/Ik5EjlXyBHK7+AdCvPQNYpr0Buo+ch9LUS+udCLlfmYM0EDjmEQw7hkEM4 5BAOOYRDDuGQQzjkEA45hEMO4ZBDOOQQDjmEQw7hkEM45BAOOYRDDuGQQzjkEA45hEMO4ZBDOOQQ DjmEQw7hkEM4BMTeChkm2QYLCYh3E2m9iKuQPnYbvUt9TzeWiW+BiquApERvWAmUE2kdS5D0Wlpi 46VELa2Pq2PAe8jNWtoY99zEqqRFWtrMJqNETVuYS9qvpa265lh9G1smfaKl7WyyfqaWduh26qN1 EliJsV+8A9I1zVSspTkzmXZpaR0zmU9raYklmr/U0vq4OgZmt0ha2hj33MRmWYZoaTO71lSupS3M acnS0lbujtW3sRss2Vrazq61bNLSDr7QEq2TwG62nsJIuN6i4aymVZzVtIqzmlZxVtP6uDoqzmra GPdcxVlNqziraRVnNa3irKZVnNW0irOaVnFW0yrOv2AuNg0n2hshXexu+mu1AVbOKsCF8CYXu53+ yq/6t349eOJDqoylomQOKwG52BI8K8I5OIhWIufF3YvaVZAFqHk72pWgTh6e+VDDR/U84FLoKqC6 ZchV4FkZlantfRiBC+xBPR801CC3Bqkg+nLR3xbOQ7oEdV005kq0LqC/XVxEWso1rUHUKNX6FDVc mGM59emlv1Es5nIXzbUQTzz0t3MDNAsX3T00S9GvOo98lEwhzaX0pIQ0eoCR+jzaSyn0lBBifm2U ZXhSSr2qOsU8g3EjED36aS7Rv62soq2OXfRUDgRc9FeFiwgFH/0dYfH3mYOUEzMOxtZDxUztxUVj L9PmVU7Y5lHNgRHHz0igVk3t1FmvQj6V7CF+NSeStlLSUEM4VGorH4+3WDF1/l4av5i/ui4BsgZx V3sUa+2CDn9sNuoYi7Q6Fcit1bQHMQt1hapiq+QhG/HgaemgeUWtOR8j8VD/+Vr/qWSxRbRWouRy H5h52ayXaZbj02zs+9ByCzzomy09SH0WkCWKXlbF1iCKzZV8r0iza3+strBcdcXLUN9LtrMQNfJZ CmE6CXUKSN+d1Lac9AdBfsxjKmgNUSr51OD+UjXtU5GuIQssolH7oaEGTwVihTRjYamDtUafF9Jf FA+QvUT1/ZDmoFpJDa1uBY0wSHZcQX6ntnbRHIQPeGkFfdSHl9Ywj9pG0ZrHlmLec7S2gbgS1X8K CJMBn1ij/SXu4m/oV82LuvlYwUrCsCBmYwVU7icLqYmzKz/NtEyzLFWXl6TwlEvnLcpVj0xBK7FS whryYj1daVRll2m+eowGtEejokuLa0Ead/6g+HL53KPR5NJxzYpDQMxEnYsaZaP7RCAWsQsoZpVR 7PJ840xVnD2DMFU9vlyT6qzUdCVZXiW1LCD/F7PxxvSImiXkNd+2Qv+v/GLAJ6bSaIQPqJE/ldbK z6p/4ZqWduM0192+/EB5RXlh0HV7ecBfHvAEfeVlqa45JSWuJb6i4mCFa4m3whuo8hak3u4p8eUF fC5fhcvjKi0v8AbKXBWesgoXyn2FrkJPqa+kxrXGFyx2VVTmBUu8rkB5ZVmBr6yowlWOqkFvKVqW FbjyywNl3kBFquuuoKvQ6wlWBrwVroDXU+LyBdFHfsUUV0WpByPI9/iRFk1KK0uCPj9UllWWegOo WeENkoIKlz9QjnGLYUN7SUn5GlcxBu7ylfo9+UGXr8wVFPPAyNDEVeIrQ1/lha48XxEpVjsKequD aOxb5U11adOcWOEq9ZTVuPIrMXl13MFi9O9d4wp4MJeAD9NGQ0+pq9IvuoHGIjyp8K1F9WA5JlQl puRxrfEEStW+BMz5xZ4ABuYNpC7xFlWWeAKxFZgZ7XoZwMF0XN9PvWXaINCDAU+Bt9QTWCVmIEYz sHpFwNovHueXY+JlPm9F6sLK/BRPxSRXgdd1Z6C8PFgcDPpnTp26Zs2a1NJou1RUnxqs8ZcXBTz+ 4pqp+cHC8rJghVZVpAs96H6VqPfD8kpAUuOqrPCicwxIFLs8WAFvoNQXDHoLXHk1NKx5SxfOQWmA Mlifgkp1JdYU+/KL49ri7ivLL6ksQFMgVuCr8JegA4GVP+BDhXzU8pYFU13RvsvLsJApvkkub2me aDSgqixa+YojourCFLEsFcGAL1+1l1jvwkyiumbRAFJ86AUmK3wiIAy7oHxNWUm5J75TjNmjjhQL j+kCY5GoDPorg4C9ypfvFXWKvSX+SyZ0NWtBKzG1wFvogfGneir81bH3JqYksc3sShdHDZy82TXM pChsCM746tsG4ylgl/q7rG+59NIFu52jjm7+1dZ3OER9qfhq6w8ZIurrG6+2vtMp6hueutr6Q4eK +sYDV1v/mmtQH3cm3r70VF+8fc4lOZQ5WCIbyZJwrhzFprMJ2OEnskU4Va9AbC1GpK5k6ayeZbKH cQJ4gi3A+8sP2D6WzVrZSnYQ0fcD1BI/Y/+K67idD+HXcScfz0fyqXw0T+cp/E7u5vfxbO7h9/My 7uPreAnfysv547yS7+FV/Flex1/hW/h/8m38EG/iH/EQFz/5u8Bf1HEe1tl5i+463qZL4e26m3iH LkPK0i2QluqWSz/Q5UrLdaukFbrV0kpdjZSj2ygFdFukoO5hab3uR9IG3R7pcd0L0k7dq9JLugNS t+6wdEZ3Qjqr+0Lq0fVLX0oW6YI0HGs7bjA+0sT/JT57gM+/A5/Xgc9bwOcI8DmJWueAjwJ8hgGf McDne8BnBvC5A/jcA3xygE8J8FkLfB5C6jHgswf4PA98fgN8DgCfd4FPF/ARP1ft47t0EvBxAp/v AJ8JwOcW4DMX+CwGPtnApxj4+IHPOuCzEfhsAT6PAJ8fA5+fAZ+fA58Xgc9/Ap/fA58I8PkM+FyQ zko6qUcaAnxGAZ9JwOPmwfgY74/D5zrgcz3wuQn4zAE+i4HP/cBnFfCpAT4PAZ8fAZ9/AT6vAJ8D wOc94PMJ8DnHCqCumCewIB8FfG4CPrcBn0XAJxv4+IBPJfBpQO6fgM9uPHkO+LQAn4Mo+Qj4nAM+ F/kWnZVv043gTbCTkG468MkAPouATzbwKQQ+NcBnE/DZAXyagc+zwOdl4LMf+LwFfDqBzwfA5xTw 6QY+56QNkl56XBou7ZTGSC9JqVK3lC6dkbKAz3LgUwh8gsCnHviEBuNjOROHzwjgkwJ8bgE+dwCf peL3scBHnF3qgc8jwKcZ+DwLfA4An/eBTw/wUdhK4FLAvwt8pgCfWcDnPuCTC3z8wKcW+DQBn53A 5yng8xLwaQc+h4HPKeDTyyt1Rl4FTOp01wOfG4FPBvBZDHxWAJ8i4FMJfDYCn38EPs3A52ng8yrw aQc+7wOfLuDTDXz+DHz6pRzJIAWkBMx6mLReGgl8vgd8MoDPXcCnAPhUAJ964PMI8GkGPs8Cn9eB z+8H4+N4JQ6f7wCfG4DPLPEbduCzAvisAj6bgc+TwOffgU8L8HkH+HSzBdzEfsDHsmw+DfjMBT5L gE+e+J0d8NkJfH4OfPYBn1bg0wl8jgOfczxbp+P3667hPt1YXgL7KNfNAz7LgM8q4FMNfDYBnx8B n58Dn+eBz2+Bz9vAJwJ8PgM+f+HtkpV3YN5Z0kRpqTRD+oE0B5awSPy0VFoJypGKgI8f+FQBn1rg EwI+e4DPvwGfN4HPUeBzGvh8LfXordKX+pHSBf1khOOZg/EZej4On+8Cn1TgswD4FAOfGuCzFfj8 K/DZD3wOA59TwOcrNo8PAz43Ap9FwCcH+NQCn38EPj8FPq8CnyPA5xTw6eMjYRujdUk8BbHDrZsB fO4CPiuATynwqQc+O4DPXuCD+KN7C/j8EficBj7/zUOShe+SruMvShN5WPo+b5EW8jYpH/isBj7b gc8TQOQZ4AP/ktqAz++BzvvA5zjw+RPw+RL49Ekb9A7pcf1Yaad+ivSSfoHUrS+WzuhrpLP6rcDn n4HPy8Dnd8DnqNjnzSb853SmpGTW1tebDdxs6gqFehobG3tExuhvlHE1+s1Gbjb3NDbgQokeJT2y jP/kQRmZqs3IlOUnGjJnUAYN+kUrM+dmvaxdZomZ9S71ClM/jaHmcHMo1Gg2c7O1tfXnuH78Y1Kw f/+ePTt2NDVRprqBrmpqQ6MU2sSoKRNqbKTh5IbkDJczlGs2MLOxT+soOhxVgY2ZbQ2uBldWRlbG PSCX7JKNBm409ZirGxupAxMm1SjUGvXcaPCLgfvpuVlUQSWq72/sk+Vqsx4zSsvoyRAXKhmN1aFQ ruxXYYSm5w6IJioKTEXBKilmycViOIiRy7IAojk0CC6jmRut+363BRd1qerSesclRmU0qWMlOIwm dYBms1HiRn2XqgWzMPrlcJqzy6RnJr062DRSI2rvLDYamNHQ2Oh2u1xGCzNaGuVGeSlC61iQWoYS d6N5oFpGhujA0IWE3BU3ZiZLOsYlPDVybpRkcWiSOS5JFJhFgYTpGtzNzRKQM7jdzVxien0XNzK9 sd+qgybUoSsjg7IiIS5ZliS0bG5uNpuwoGnz56ctaWoKmI1Y6pSU2hR3n9tN607QEDjI5DYTyH1a idnsdGWombQ0tzvU53SqtiIM2qy18ROEzq5vcRGYlEmYuyxr5v73cxFTzEUs3GxrkVvk3aAdILFM g10FwFhmZNbjQhcx7/g/uIr9W1zFYuAWkxzvK0bVV6jAHHMWUZAb6hEFemaBs1zJW6LKvsFd9APu YtFzC9xF8xcL55YYdv8nhxG+/lz4Eoch9864sscYv8VjjAMeY7yCx8SP+ttdxqK5jEVzGculLmPT QVXUZeAqlI/6jOo0FuE0FhO3WITT5D16udfAOAa8BpkBr6GSqNcgM+A1yAx4jaZAeI3FwiwWMxsG EmjMYRtoHS1GbjEL5PtgW31iNOb0uTTmuek0tr4GYbf1KBOm0CerbjOQ6yMtoqZot72+XmsnGl0U YrApCFszOLWri3pvUD2pscFi5RZ7GNeTGU9mPErUBLKYucXa8uSTj2zZsmnTg5RLn7tRXOhKKKCh xyZDuUb4PQ1RbJh+AYbFxCymi9GeY0Mkn7TYuMUhXGqr5lQ3ysKpTAZuEjBXw7KsRm41o4uX90P9 /pdFkboZN/qpSK/XB5tQ1BQ0GblJbIz9slxr1TOrIeZZGahpMtWK5ZRRoXqQToyXgNK8S7ZLimXA veBgVgO3ClfU0LJybh2AVTZZuMn+Auug6KMSDUTTHR1Ug9qt9nz/y8KPRVYbO2Zh0nOT5nCySIvg kSuWSixcdCZppI/UYcICJuFNcCeTlZlsmRmZGZNlQUNxtFOLUeh2N1rjqsLjSH+PU/hej5XrrIaY 78l6HdPphaeYODdhnsL7ZLwq6/SiDFMXZXpAYpwfCoX0BobE/PkhLnG9oQvHZ4PpokPiVoMrzgdd 9EQk1Eto0EMDFISsZm61zsjMxO61tWFzDVnL+PHrx4+f3z9/vmZJmitSTnNFV59WBl8Uzigs0JSU kjJ/fmO/2Rx1EnijsECjpgVhzdlltTAr/HHAIzfAJymumrjVQkYsPK9fDMwye446hzmzaZz99WT+ G1EqTKg/6ob9ZCMxr5SpMrV9eONGra1op1DrSyyIbNUZc03S3BDd5BqsNm51hHPDuYhZzY+4HoGr bHUJlyGlwjtV97RauNU2W5tK9JrDZjPSJ6alumpslvDVhoZ6Grjwp1yngMpqYlZzzFmdsYGrTi/G ktDgiu6BcQ6rWrm+FlZpM3KbcK54jzVpHktl+iu7rE3PbMJlYz5rQtl64Tcyjhu1g9X+Vae1GbhN OG3Ua22c2+Iw/zu5rZhqNcW9nr+329q4zhZ126vwW1vUb20m1W9FYsBvzcxgVhIkbovzW+Gv9GjA cTXPtZHn2izcZpuBd8NMNp+lsXvYFraJ1YOrYf8wo7FjxypjM5XMzEwyQe2VRQBq0FnNrpgja6V6 PW2rqmclxVyZsrUYfDXA1kJ3tQa+ucdmZTar+Jf6gpJBGfIGGRPIkDNsJm7TDJ382WZGfrRHnV2G Z7TIW/s2qx5dv7mPDEx4tObSA3kSMk13DMuVMxjwZg+reuRceQyjogHbUuLs7FK7Iyt3Dng7jbI+ thPX2xzcNiScFE5qTmlOCc0PzReRb5N5k7neTL2E5WZQCNQoN4DqQRvVsY1i+YPcfw7yo5gGA50k aADRvOr/9TTN6gZMJc0sALaZmC0uAjgvmVt8ZKGx1mNk85wqpYhBNzsznBnaSyoCAhbKbuJ2i+q6 Ytvf//Kg1wUq1eGaeYcovWOm9mIgggJKDcxumDEQFcSymgfCQn3tJcrr69XoGsPBISnW+MjgCtuN 3G6OCw0Nds7t8Wskm23cnPDrcJurIY7oZSLayaA3C9tACUUIykdng4nR+4UWImTtbCjiLcKt2Ecz MvrUqc0grWoHgAFvW2aoz0xJwfEy/t0jGinUtyERGxAqbPHVnXh1oQMpPMqVIffZuc5ujE0vPlqY uc5skNVDdly4sEfDhT0aLuzRcGGIhoshEreLcBGNF0i56BmlovGCAobdJAKG3crtdjVgZLIUhAw3 jFiEjNtZethmht1RyFBjBtmpinAUZJslzR3SzPIi5asbAK9ehI2L5N72YcPGZ2Y2KAgVVK7GDdQR dh3VJ9ZE32e3MbstgSWw7xDdKN8o54Y3YKMVe63dzO3W/ra2tv39ba2trW39dgsejGF+OZeF4ygX T8YwmtdF1opX0XDc1SK3yhcZ2edFke+npxcHHlxU61HzMbI/Q9XdrjXPDfvDY2QqHNCpxHcQtuuw rIMewFuMSbFrp58m0trW0XGk58iRjra2VnsCtzu7RnWN6kk/OOVIyZGSAws7OvY3tTe12lvt1FlX uCd8MHwE1AFqA70Rbg23hO02bneMYas1iKKUG14dBgQqYISVOhIBWD9rY61EbUyk1VyLTBCkF4bD XdWjEozGjmq7mdktysDAky6Z9sDlkW9j9iHcPrTF2GJs3ZzflN9U2FHYcfOR6cvTq5PSktLoBaO2 zWhc39b2dpXDzB1W0e7YqVZxnTqmvmkVkrLCdCqXcM0qovKiWeI1B2Nra8Pq5KU7jNxhTM/Nze3L 1S67KN8A02irDa9Hi/WXdtHa6tBxhz4cZiw2aqdecRjS0hhLG7i6HCbusIjSNqxOz5GOjjatYdxl sXPLkGNdn6a1DSJ6F4v1p76ZFVK6MN0eV3bqmFgK8SA2P8yVTsdHuqJdiHe36v1iLexN1eLcZByY 7gzSrfUDcMS7rPiRSz4TdDNoFMiSgP+EAeUnFe0s2Dn9ufSepNykXJyyLebWwsL0pPTCwlb7ldsm gdIYDaLfnpSUBoPqd+h0jji7Bo4GiesMGE9YxlZhMQhwmcBX7BsGKnaoxQaAah5b2NHRYTAxh7mw sLCjkeu5wdjDxc8lFNmpx4qmibpRP8vNTaOHlNIuUW7A2ps7xOWwcYdjNlMHXsjS2YxwCfxCOHx+ OD0XM7Nbkun4ochCzgUp8ly6k2doixNdH7t1RvWRqKkr9KC2DQtjNNoBgEK+k8BGs+HAaAI6vAOe o8hGJohqrxdrU2tEk7bagQ7ybxMa+rTf2lrZbt1yJuXXBErYsKKAdxWbWeIJlrGFKOH3LpnrAvBM Uej3AEbmwMuQmuPMhKh4LT1Xn+jwsjQEgxnOpLvc7vls/JLFd7tY2n1LFrhwClDriN+bO9l1lJPQ w9CYdhx4cDYboeUQoNg1bCT7Tr6/ws/2kPwlyedI7iP5Gsk3VnkDZewAybdJdpI8SrKL5CmS3eKf dbBzQnIjyZEkU0nOJbmM5AOlq0pX8fUkN5PcTvIxkj8luZfkM7Hffv81ya9SmoGkBAyMQBiuAVz+ /z3TYR0cf/NdGKX495XiXwTWs0fZbvY8e4MdYifYOa5jFpqpWZttNxP/tllCu2Fwcy5+x8JnqvfG zer9J31xbWBvZ3cPynN7/+B8woTB+aGJg/PX7Bqcv/7i4HzKJeWTRw7OT0cg0sXnz8eVGxm/M31w fuFW3K2w6RTmFv8eHG3qAVWazs026Pbo3mfN0k+kn7BOfVD/JDtseNfYyCXrvVYP/7X1IbwYHLA7 7fN0t9tX2H+qq3EUOB7Q/caxwdGk25+gSzDrDiV8lfCV7o+My70CG+N7jn1XpIOgo45P4ui0Rgev QOcTxsYoBTQTlAl6gGjnpeQ4mLA74T+cj2nUHEe/FCSOoVcg61B3jLYO3RGjXpUSR12BUkHTh+2K oz0qUcklNOz5YQdi9Pa1XaBTgobrr0SJqcMTh6dctzWOdhC9cUU6eN3XUUoaljQyRpkaZV2R3ETL tPtgkjUp6rURdcZIbf1hUs+IySMKRvx0xFOCLtU+4pkrkap9xMsjTmh0foBELyO+pr5kwd9dOG5m jBaOWxKjAo0eAMnjHhB/KHh8xvWp12eOewAy9fo3JhyY+B7R+ZRskH/SBNCUSScm9YFPTLo4+cAN PxU06cQNr91w+obTU/RTEqYMm/IKqDN1Nsidmj31CY1ev1G+acJNn01/9ObpoNm3JN2SfUv1jOc1 em1G24zOmZNBM2ZunnXsViNR6NY3iPpn3zz7aY323dqP/NOzeyjXc5vuNt3sp2+bkrE947U5qfOW gz68s/jWkFob9x611l2zRb27FmaNzUrLmp311IIJRO4FDxBVL9i84AnI6gVvgroWrl0oL/zwbj/o sUW5qOVe9Paitxe8CXlMpEAnFnUv+nqxTLR3cQfRh4u7wR8u7nXrF/eivNud7T7mPnFPEPToEhfq 7V3cq5YsWbu4d8knS84udS9rW778/sT7R90/oUhflF10pOjr6L14Cuj5MmfZWH+1v94f9p/wd/t7 V+tXT1udubpwtX/12tWNqx9b/fTqfav3rz4U8AceDTwVOFfBKhIr5lfkVbxW8V5wejAv+ETlssrG ytcrz1cZq6ZU3VH1dNWpNZlrvq4eVX1HdW51oPqJ6meqj9SMrfmHmn01R2q+XmtfO3ztjLVz1xas 3bv2yLrJ6zLXrVy3c90v1x1b11ubUbu29rU6Y11GXaDuubq2uv71I9cXr9+7vnvDzA3VG56R3d8Q q/ZdGo8GRxu5aoBEHKGfdWikRpBv8L2sSz1usJ+oln7FqBONPHE0OHbIbQMkooPcOUBqXBAx1PnL pLbrdiAOH53dg6hJMZjuiLdD3YivOxN2Ox9zHIzFTNQd2juuQLR17EvYORA7VZQQnTMp/qq1xibs jqInnopYTHWPinKqryEIvfscnyCS70aLo6TtIEb3GO5HiQZ2h9OX7AqZcfvAwE6wW4z7suj/y8ui v1WL+Vsp3lOUJz1onZCJ9M5oJMR6PKWtF2KTGn/U+KatI2IiIqBYtYJYdIyuKGJcUpZ8QrQYWONx S+QT8gloE7XOo8w94sS4JZfbBOJgZ1xEvUKcjY+rl8dULXK3kTWpUXRhNH6KuI4n6FXuHvEUnixJ ct88fdHbw/XqPkZ37FnXfX1tF6wqMbr7RHeVxFHD9QM7kGqVYm+j2npRA23fGJ4oSsQTUUs8Txzl OBi11KSRiaOwAyaK9iKtPh3YR+N3UjEW2jW1fTNu50yEhkv3yR2DdseD2s44LDp6lH+t9i76X+C+ tispE+MZhL5ATWCMlYrz2CjGqicKNFVLGVcAvLPEagokktzDdtF6PyXWJs6rZ454BnON7rCdqla5 O0mWu1USPYj7uCViVURKtTRxl7uvTx0/TWV1hxs/jXalOBI7nLq70f74vyTaU+Po8hq008aRtuPG 6PIWYqf924j24qum2I79DXQpUoJi+/g3EO3sV0102rhKuhQdOqPE0eX40dkljoTdqyv9t9Hlmv/6 6K6OVJzF2SVh963GrLG39juOilMPUYieGMVJh3KhrLHiDKSVgXCCmiFOTepTEftFShCdjpbTyUqc oXpm99D5CKcjpN64NUSnEzl2ihG0d7G86NhiWZxgKLdXO+eo6b04BZ0QT8SJRrRbpBGdeIJ0NkJd Kt0r5IhnUHuvOE0hWkxYdIzOXdUauenJBHHqopx70TERl7QyEE5uaTiriROaaLeZUiA6p/npPIe6 dFKLndcWuG/TESL9Aot7gioStxppPhixOtIFb5Ju0dNm0kV6B3vi5SsabwcT31NzzCi+WSXdrbwm vlclvlYlvkwlvc5uYeIrLQfp+0wi1U3fmeH0dSmd+GYUfTHKxn6l9LP9Sj/PZddwD1vC89gIns+S eQEbylfRF6umiy8xSSXKbxmnry7pUdeOukNR1466VtJ3kr6zZOHiGxq5bBzKl6L8uygfB13XQ1ey +BYSff3IhtTzGO9QqRbjqFNewnhnSh8rj0ufsDTpJJsmfcpukD5X3pFO421XaD9IX0HSi68UiW8U YTQ76JtE1WwIy2JO8Ew2ic0CFyjvMC+4EFyhfMqCynlWCa4CrwFXg2uYna1VDrF14FpwHXg9+EG0 bwBvAm8GPwRuBG8BbwVvAzeBf83mslfAfUhfBCtsEmdgDnazWfwe8BLwveD7wD62mLexMZixT1rG 0qUV4v/zB5ewRvEdGWkjc0kPstH6nymH9M3gJ8GH2CT9u+BO8GHwe+D3wUfAfwQfBUfAx8AfsEkG p/KOoUs5ZPgTsxu6kT4D7lEOGQ0syzgJ95vYJOPNuJco7xhLwWXgcnCl8qmxCgxsjMDGCGyMa8HA xvgsm2V8DvwS+Cs2yzSZjTHdAM5hk0y54DzwanAAXAOWwRvBwMgUAj8C/hn4STbX9Cvcz4DPgnvA X4LPgb8CA0NzPrgA7AVXsjEWxmZZhrExZLun6LtRIvU5ff/pWljtC7DaF2BtE2Btc2Bt9bC2e2Ft ebC2u2BtGeJbTeKLTNIyZbv4JpP4IhPs5kfiC0zS68pe6WPY2UkmSadgg5+zFWRnn9B3mIbGvGIl mxqnfz70V0H/POi/BbWzoXsHdL+EVjdB92PQ/c/Q9xr0LWMJ0PIFtHwBLU5omQgtZdAyFVqmQssN 0CK+Y/ah+O4SNIlvRk0T31qimf4OqWdZEnT8Fjp+Cx0pPEd5BXqmQk8O9EyHnnuh5zbuU/4AXVP5 TuVltHwV+vTQV4WRFULnNRjZg9C2TTqhnMfo3pQ+g7d+zr4nndY8dii0ToZWH7TeAq3zoHU8NKZA 27viOyfwvLsxy6XMpkWYvyCSiMjyY/ag0s0awJvAm8EPgRvBW8BbweK7bk3gN5U+9ha4A/x78Nvg P4APgt8BHwK/C+4EHwYfAX+gKOxD8EfgLvBx8Anwx8pb7BPwSfA5JcL+DD8/D74A7gV/Be5DdPsv lH8N/m9wP/gv4IsYi6J0cwbmFBU/lrJhYf+gfCGtxD1X+UJ/SOnWvwvuBB8Gvwd+H3wE/EfwUXAE fAz8AfgzpU//Ofg0+E/gbvAZ8FnwF+Ae8Jfgc+A/g8+DMRb9RbCivGVIVN4yZSh9pnngLPAC8CLl U9N9uC8FZ6N8BXglOEfpNuWC88CrULYa9wA4iPQacDW4Bvla3GXcN4I3I/0QGOtgehj3EO6PgP8J 6R3gH4EfAz8O/T/D891I70H6V0g/i/SrYKyRCWtkwhqZsEamiKKYjoGxRiaskQlrZOpCm+PgE2Cs kelzJWI6Df4T5tINPqMcNJ0Ff4GyHuj+EnwOfB55rJ2pF/evkMcamfPBBWAv1kvHtrNhtHNJbDts d6n40g3W14DcvyGXhdxdsPL90h/YDYzjaS/LhGVGYJkRWGYElhmBZUZgmRFYZgSWGYFlRmCZEdT+ FJbWB0vrg6X1wdL6YGl9sLQ+WFE3LKYXFtMLi+mFxfSiP/EtpYh0PzNIHnAeLChf+RhWE4HVRGA1 EVhNBFYTgdVEYDURWE0EVhOB1URgNRFYTQQr2YuV7MVK9mIVI1jFCFauF6sWwapFsFq9WKlerFQE qxLBakSAeh9Q7wPqfUC9D6j3AdVuoNoNRHuBaC8Q7QWKEaDYCxQjQDECFCPksUeZCVjOgSebsff+ Bnvvi9JB7LXvYBfCbkP4nsYM38EMjxO+tciJr0uOAr710PA+W459Mhn7ZDL2yWTsk8nYJ5OxTyZj n0zGPpnMxN+PbwJvZzdjrxyPvXI8fLYTPtsJn+2Ezx6Hz16Az16Az16Az16Az17AfpoInz0Jnz0J nz0Jnz0Jn8V6swXYN6fDT4/DTz+Cnx6Hn34k5bEJUj64hDVgHx2DfXQM9tHvYO9Mxt6ZjL0zGXtn MvbOZOydydg7k7F3JmPvTMbemYy9Mxl7ZzJ88SR88SR88SR8sRO+dwE+1wmf64TPncQel4w9Lhn7 WzL2t2Tsa8nwlZPY25Kxt42Hr5zE/pYM+++E/XfC/jth/52w/+Ow/+Ow/wuw/wvY/xKx/yXC/k/C 5jth8xdg8yexByZj/0vG/peM/S9Z2LtyDlifw/lsu7IJKzAf8fw44nklVmI+VuLnKG2Ctc+TDuEk 1alclA6zPFq9CGofRa0j2DG3K+uRy0PbQ2j7Lp5moO12tG1H2yy07US7HzKj5kc/QM3DqNmJmll0 vhI286+kyYvy21D+NsrfQ/ksaNqC0uegaS40vQlNaVT/j3RO/JDk//B27/Fx1tW+x5/MpEmaTLiW FigI5Q5ykbtcvCBaQaWIbtmIW8zeW9AgIIIF1FNoDcJWwHIRKEIFNxVatK0SCyI2FGhpm5KSXnJp Wpo06ZBkOkmTNDOZpuDvvGd25KDnnNc5/5zzx8e5PvOs9f2utX6/Z0jHbFRetHd0WNGVuA7X47u4 Ed/DTfg+fmal3zf/e3z5397L//Je/lf2Cnujp6JJ8ZejM+Ov8r8zOtKq/WW7xP2s3AfbJR4Z7zEZ ekWQ8tyO6Ezr+U3hVUdMtKc8Ir+mO/666GIr2JX5X5mKLo5fVdh9XRztJbLJIpsssskimyyyySKb LLLJIpsssskim+zICY68wZETHHlD4chKR1Y6stKRlY6sdGSlIysdWenISkdWOjL/C6anOjL/G6an Fo5MODLhyIQjE45MODLhyIQjE45MODIxduQZY0eeIZOvRSe4d0JB49rCHmEk/zt6+d8cwmX4Er6M f4rK7d3K7d3K7d3K7d3Kx+f/O21x/lfw8r/KNrbTWF7waFu0sei40Fl0PE7Ah3EiTsLJOAUfwak4 DafjDJyJs3A2PopzcC7Ow/n4GD6OT+CTuACfwoX4ND6DqfgsLsLF+Bw+jy/gEkzDpfglHscT+BWe xFP4Nf4TT2MefoNn8CzmYwGew2/xOyzEIizG7/EHPI9a/BFL7NaWuX01tBW9htexHCvwhudXhqai VViNeqxB/jf2GrAWb9lBXOlq5arQWLzCTuINrMQqrEY91uBNNISm4rV4KzSN2zd0jpuAAzARk3Ag DgqdJbPxGGhQ8qvwTskzYWfJs5iPBXgOf/T8627tNktWuN8Ymko2eH+r+9nQWXooPoTDcDimhJ2l R+BIHIWjcUxoKj0Wx4W20uOhFkrVQinfS0/z+HSvnRfeKT3f7ZfCzrJY6CyLoxjjUIJSlGE8ylGB BCqxF/bGPpBv2X7YH/Iuk3eZvMvkXSbvMnmXHYzJOATiLxN/mfjLxF82BUfgSByFo3GMmE4L75Sd jnNCU9m5OM9zn8RUfBbf8L5/c3uN177lfd9GNa7FdK/NwO24AzMx2/NPe/+z3j8/tJUt8Pg5DHku EzrHF0Gu4/cPTePlMf6A8M74w9XQjwq/40idIuoUUaeIOkXUKaJOkSOKqFNEnSLKFH7tcV/sh/0x AQdgIibhQByE/O9B5n8N8jAcjik4AkfiKByNY3Bs/ldMXWUfjxPwYZyIk3AyTsFHcCpOw+k4A2fi LJyNj+IcnIvzcD4+ho/jE/gkLsCncCE+jc9gKj6Li3AxPofP4wu4BNNwKfK/ZHkZvoQv45/wFXFf jn/GFfgq8r85eTvuwEzMwo9RgzvxE9yFu/EfyP8qZv43MR/Ag3gIv8DDeASPIv+rj4/jCfwKT+Ip /Br/iacxD7/BM7ACFs3HAjyH3+J3WIhFMGuLzNqiP+B51OKP+V/kzP8WJl7D61iOFfnfmsQqrEY9 1uAfp8hXwr/mf7HTOrB3/rcz8788mf/dzPyvdRabeMUmXrGJV2ziFZt4xSZesYlXbOIVm3jFJl6x iVds4hUvco2yGL/HH/A8avFHLMGfQl/xS/gzXsZfsBR1eAXL8Cpew+tYjoYoUbwWb0WJcftG5eMm RBXjDsBETMKBOCiqKLk39JXcF9Ils91/xP05obvkMWsSDwrT7CmvyaXkN14Tc4mYS8RcYkqXLA7b S36P571Wi/yUe8H7X/TcS17/M172+C8QZ4k4C9Nvpcf1Xlvj9k3PNWAt3kJjlCjZ4Nyu7Upc25U0 e64ljBQmZZvYXM+VdDvWNUtJ2n276xK765KdcM1S4pqlxDVLyS4MI4Os3EbC9tK9Ql/p3tgH++LA MFJ6EA7GZByCQ6Py0g/hMByOY6JE6bE4DsfjVM+d5vZ0WGVLra7/NXWjRFksqiiLoxjjUIL8X1Hn /6J1PMpRgQQqsRf2xj7YF/thf0yIyssOwERMwoE4CAdjMg6BOMvEWSbOMnGWTcn/oT2OxFE4GseG vrIPu0Y7ESfhZI/tFMpOdf9vk/gM98/C2fgozpHHufiC+5fAdW7ZpY77Ylhedhm+hK+GkbJviPMa 7/vHKe16t8z1btmtmCGG23EHZnr/T51b/xem9iNu5/jcx/BLPI5nfd58/G2K/9ZzPCzLOHZPGBkf he3ji/L/aCekx9NzfLnbfT2/f5QoTHYr1PhJnjsQB8E8Hn9I/nvJfKeP7atm5H/XtrBHe+3952/I /4Zs4XuU/H6rPxoXuyj8S/yS8LrdaXn+uy2v9UUnxj4SUrEzcDY+gYvCutjFYU3s87jErvwrYavd xRa7iy3lV4Q15Vfi7pAq/w/8FD/DPbgX98G1XPls3I8H8CAewi/wMB7Bo5iDx/BLPI4nMBe/wpN4 Cr/Gf+JpzAupxIdDKoqLNBu7wjXxTa6hzxN/RvyZ2LkhKf5M7EK3Pw3bYj9z7fK16CTz6yTvXFP+ 5ZAs/ydcjn/Bv4dt5dfiOtyAG/F93B0ycsvILSO3jNwycsvILSO3jNwycsvILSO3jNwycsvILSO3 jNwycsvILSO3jNwycsvILSO3jNwycsvILSO3jNwycstUfC5sq/g8voBLMA2X4ou4LGyTe4aHZ4cW Dr0ZK/gYVhW+OTxM7vPlPT/2tbAo9k1cj5+GZTTI/9Jym9zny32+3OfLfb7cl8l9mdyXyX2Z3JfJ fVn5bWFR+Q/wI8zCT8IicS0T1zJxLRPXMnEtE9cycS0T17LoAg5Uc6BabF0cqBbfiAoaVkHD4mwX SatIWuNf+etw/Iq/ZqwulZw5Jf9b5Nw5Zewaf7nqGlZdw6JrFV2r6FpF1yq6VtG1cqaaM9WcqeZM NWeqOVPNmWrOVHOmmjPVnKnmTDVnqjlTzZlqzlRzppoz1Zyp5kw1Z6o5U82Zas5Uc6aaM9WcqeZM NWeqOVNNgVYKtFKglQKtFGilQCsFWinQypnq6EIqVFGhiherqVDFj9Wxi6JDZT9N9tPGvm+9Z+x6 +gQqTMz/onT+d/rzvyk99i3xV3m1mlerebWaV6upMY0a06gxjRrTqDGNGtOoUUWNKmpUUaOKGlXU qKJGFTWqqFFFjSpqVFGjihpV1KiiRhU1qqhRRY0qalRRo4oaVdSookYVNaqoUUWNKmpUUaOKGlXU qKLGNGpMo8Y0akyjxjRqTKPGNGpMo0ZVVKoWhmWckPEDMr5FxvvJ8HYZ3hodRKPl9FlOm2baNOd/ yTn/K8ZefUj+y+W/XP7L5b9c/s3yb5Z/s/yb5d8s/2ZxNIujWRzN4mgWR7M4msXRLI5mvVIdnv2H eTccnRS7zIy7AtXm3LVm3HdwHXy2iDven3UzzIw7wpqKH4VUxX/DDNyOOzATs/Bj1OBO/AR3wWys MBsrzMYKs7HCbKwwGyvMxgqzscJsrDAbK8zFCnOxwlysMBcrzMUKc7HCXKwwF/caj3JUmHn5yZ4q xJ7R40k9ntTjSbrlr9OP8ep6vZvUu0m9m9S7Sb2bFHtG7BmxZ8SeEXtG7BmxZ8SeEXtG7BmxZ8Se EXtG7BmxZ8SeEXtG7BmxZ8SeEXtG7BmxZ8SeEXtG7BmxZ8SeEXtG7BmxZ8SeEXt+Zl0RNlH7TQq/ +v7MymfUHp0mo1qvd3p9hBvvcuNdbrzrve3eW+a9FTqlXKYn65Ry2Z489h3QGxx6l0PvyrJWlrWy rJVlrSxrZVkry1pZ1sqyVpa1sqyVZa0sa2VZK8taWdbKslaWtbKslWWtLGtlWSvLWlnWyrJWlrWy rJVlrSxrZVkry1pZ1sqyNjpTJjW8WcWbVbHq6BD+rJLBv+uA3TogK5M7ZTJp7JuZSflvZmTyaP7b LN6t4t0q3q3i3SrerZJVjaxqZFUjqxpZ1ciqRlY1sqqRVY2samRVI6saWdXIqkZWNbKqkVWNrGpk VSOrGlnVyKpGVjWyqpFVjaxqZFUjqxpZ1ciqRlY1sqqRVY0+vqLQxx+VxVtj/81pqqgfEvXzUYV8 G+TbINcGeR0gpwO88rB8GuTTIJ8G+TTIpyEqiU3n6y1hd+zW8E7sTnVxX+iPPZz/pt2zo7E7QzYq 8r+7o+O9Ixu7TUX8AHeGpthdUVnsbkffG3pij+R/FzrsiT0W9lTY31bY31Ycig/hMByOKTgC3/Se q3ENvoVvoxrX4ju4DtfjBnwXN+J7uAk34/uYjltwK27DD/DDsKeQz6hIu2IzQrdctsd+EXbGXOlF V8ZuUu03Y7pnb5PlD3BHaIzNxCz8GHdGB8TuCotjs73v/tARewAP4iHMCS/J76WKWHizIo5ijEMJ SlGG8ShHBRKoxF7YG/tgX+yH/TEBB2AiJuFAHISDMTn007Cfhv007KdhPw37adhPw/6Kc0NjxXk4 Hx/Dx/EJfBIX4FO4EJ/GZzAVn8VFuBjflMfVuAbfwrdRjWvxHVyH63EDvosb8T3chJvxfUzHLbgV t+EH+GF4KSpWOVupuIGK22KPhEG1dGcYUicj0Re5kONCjgOjHMhX2DYrTtaKk/WOLJVzVM5ZYbJW mKwVJmuFyVphslaYLPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9 HPVz1M9RP0f9HPVz1B+l/ij1R6k/Sv1R6o9Sf5T6o1a5rFUua5XLWuWyVrmsVS5rlcta5bLUzVE3 R90cdXPUzVE3R90cdXPUzVE3R90cdXPUzVE3R90cdXPUzVE3R90cdXPUzVE3R92cnrtFded7cQZN b1fdd0Z7UbuL2p3U3hndSOM6Gtep9B7vXEXrLlp3xX7o8YzQ66ghlZ9W+WmVn1b5aT68x4c6PtTx YTD287BSB7TogBYd0KIDWvTSm2bDGzxq4lETj+p4VMejOh7V8aiOR3U8quNRHY/qeFTHozoe1fGo jkd1PKrjUR2P6nhUx6M6HtXxqI5HdTyq41Edj+p4VMejOh7V8aiOR3U8quNRF4+6eNTFoy4edfGo i0ddPOrSIWkdktYhaR2S1iFpHZLWIWkdktYhaR2S1iFpHZLWIWkdktYhaR2S5nEdj+t4XMfjOh7X 8biOx3U8ruNxE4+beNzE4yYeN/G4icdNPG7icROPm3jcxOMmHjfxuInHTTxu4nETj5t43MTjJh43 8biJx01RNQeTHExycBe/X+PiTs61cW4H5/o518+5fs718z/B/+e5l+ZeOnaP5+7j9OywkIM9HOzh YA8HezjYx8FBdbKUi+1cbOdimotpLqa5mOZimotpLia5mORikotJLia5mORikotJLia5mORikotJ Lia5mORikotJLia5mORikotJLia5mORikotJLia51M+lfi71c6mfS/1c6udSP5f6udTPpX4u9XOp n0v9XOrnUj+X+rmU5lKaS2kupbmU5lKaS2kupbnUzqV2LrVzqZ1L7Vxq51I7l9q51M6ldi61c6md S+1caudSO5faudTOpXYutXOpnUvtXGrnUnv0ES5luZQtdON/uTDMhUEuDHIgy4H8ddMgdQepO0jd QeoOUneQulnqZqmbpW6WulnqZqmbpW6WulnqZqmbpW6WulnqZqmbpW6WulnqZqmbpW6WulnqZqmb pW6WulnqDFJnkDqD1BmkziB1BqkzSJ3B6AST4V2T4V3dn7ael8fukcW9sihE7/4jmGO9f8y6Pdmu 7hAcig/hMByOKTgC3/Seq3ENvoVvww6S1iO0HqH1CK1HaD1C6xFaj9B6hNYjtB6h9QitR2g9QusR Wo/QeoTWI9G3ad1D6x4Rp0Wc1gUpXZDSBSldkCro/7cOoPv/VPl28LH8Nxv/+2rv4UcPP3r40cOP Hn708KOHHz386OFHDz96+NHDjx5+9PCjhx89/OjhRw8/evjRw48efvTwo4cfPfzooWCagmkKpimY pmCagmkKpimY1g0p3ZDSDSndkNINKd2Q0g0p3ZDSDSndkNINKd2Q0g0p3ZDSDSndkPq/6IYUh1Ic SnEoxaEUh1IcSnEoxaEUh1IcSnEoxaEUh1IcSnEoxaEUh1IcSnEoxaEUh1IcShXW+IHCf4U8i1dp XqVNm7Rpk6R9mvZ5jdM0TtM4TeM0jdM0TtM4TeM0jdM0TtM4TeM0jdM0TtM4TeM0jdM0TtM4TeM0 jdM0TtM4TeM0jfM5puWYlmNajmk5puWYlmNajmk5puWYlmNajmk5puWYlmNajumKfC1Mxy24FepN jmk5pqN9zOLM3/eMSrun0OlZMzX7f+oRe/db7FFdmeq2hG4r0W3bdNoBOq08mvb+RJluNZ6B212X 3+lcPw0DKnvAu3N6c8DqPOyokymcpfDwB3ZNA6p7QHUPqO4B1T2gugf+P02bAdU3oPoGVN+A6htQ fQOqb0D1Dfw/3RXlr1ZylFr5/nXLcBQfey7HpT3RV2hbT9t6/vXxr4+2+SubNk6Mo283fbsL82+2 x79wjfCwndIczz0WuunaTdduunbTtZuu3XTtpms9XevpWk/XerrW07WervV0radrPV3r6VpP13q6 1tO1nq71dK2naz1d6+laT9d6utbTtZ6u9XStp2u9mupTU31qqk9N9ampPjXVp6b61FQf3bvp3k33 brp3072b7t1076Z7N9276d5N9266d9O9m+7ddO+mezfdu+neTfduunfTvZvu3XTvpnt3RT7P6bgF t+I2/AA/DN0FjXePdUIu2j+2JJoYe9WO8zV1+XqYGVsZ5sd22WdkwuzY7tAYNznjJ7l6PSUsjp8R ku//tfLl0T7xfy78/5Xl/6awJ7E5rOXYPJ+7CK/pgNfDxthylb4CK51zlds1YXNsrSvdjc7W5LYZ PdH4WK9OzdjjZu2ERjAaBuNR6IiXogwHufo/JXTFTw274qfhdJwZsvHzQmeiKqQTV4eGxHdgRiS+ 6/bGsDnxPZgJiR+5neH2dthDJ2pgxUzcB12ZmO31hzxn9iUe9XgOnvAZ88LuxAKfvxi/D7sSf8Dz nqv1+CW3cko0em4d1qPF41Zsdn8LOryvL3QkdmEkdFROCP2VB2AiXB1WujqsPMrz14aGSnv6SnFV 3h2GK+8LuyofxmN4OvRHnxtTtY1POaq2ULWPqn1UfZeq26naStUWqu6iagtVW6iZpeYQNYcoOUTJ IUoOUXE3FTNUzFAxQ8E+CrZRsIWCLRRso2ALBVsp2ErBNgq2/oOCbRTso2AfBfso2ErBNgq2UbCP gn0UbKFeH/X6qJehXoZyfRTLUCxDsQylMpTKUKqPUkOUGqLUEKWGKDVEqSFKDVFqiFJDlGoZU6qN Un2UylAqQ6kMpYaiI2LPhR/FloTfU6pODe6h0DNU2RHbGr6lzqbHesOTqvvy2LCd9u7wcXX2Rjwe lsdLws/jiXCDam+KTwhT4odF18SPDt9X+UfETw6fotrTqn+qmns8/vFwe/yC8LWxv85qj/9zeCp+ Rbg2Xh2W5v9+SVZ/NpNetUq8jpXhbWd8hx9bnTHpDL0+dcAndvrEnXrpPL30MVeEz3Hs1bDOUfl+ ebPQIz3Rhxy93pGrHbldbEmxVfiEjYV+OCNsdOSrYbWj3nHUC47Y3xHbnK+90L+uqgs9fJg+Pcnj U8JWR3WIcnl0qMraVThyucpagVUqZo2j16qqjXaRTW6bw3bVsV11bFcZ21XGNpWxTVVsUxW7VMUu VbFLReRURE5F5FTENpWQUwk5lbCdc9s5t4tr+cnfE+0lnhKRz3O+55z3T3J9CavCKF230DOZuC1k ff6Qzx/y+UOJxzz+Vcj6nKGo2FHDIr/JEZ35urcTfs4sWSKX10OjZzfH1pkjeQ23hhTd1vncFp/b El3hrLO9e6ae6ipUy5/CDGef4chBSoxSYtQndFEiUGJ4rK+GKTEcaw2LfGKtSmqMpVVPOSaEq+MT uTEJB+LIcHP8KBwddsSP4/PxOIl7dI9/wusXFP52+VTRnKr3uqg7TN1hvddF4WEKBwoHvddFhRmU DpSYTYnZlJit/7qoPUrtUWqPUjvovy7910X1UaqPUmsG5YcpNiOx0CRahJfDzYnlbt9EA9ZiE9rw ttfa3W7zGZ3h5soovFE5LiyqLEEppnh8DK41oWaF2Xqwi5ujlY+EzspHMQe/xNywKKpQkUOqsZPT p5s+75k+75k+73H9bJ3+nk5/T6e/p6vfiw7hR97LLO0HaD/gqBIzatCMGjSjBuU+LPdhuQ/Le0De A/IekOuAXAfMl0HzZdBsGTRbBs2WQfU9aLYMinVYnANmxaBZMWhWDBaVO+MsFfAI95dx/0HuPxhb ytE6vBpWxpZbFVdgZXhaFeyJrff8RrXVGqbHNoW/xNqwGVvwNraGu2PtbjvR5TO3u02iGz3RLNVS G0u5vwNpldfnth87w82xAQy6P4RdodpsajS5W03uVh18uRm1NrbHa+/ivbA09le3wSpchBjy86tY tY1zv8ScKg8z4xXuJ8L1hXm2t9t9sC/2w4Rwnmq9SLVepFovsrbeFT843Bqf7LVDcFj01fgUt0fg SDPvKBwd/iV+jMfH4jiPj8cJ7p+Ik8KFZuS/miwLuTaLa7O4Nku1X2Je3hc/y3vOxkfDj+PnuD0X 54U74ue7/Rg+Hr6uKy6Kf9L9C8JNOuPysb+YXahDbo1fGR0YvwrV4S3z9XeJ6tCYuBY3hj26ZI8O eVCH7FEls1TJLFUyKzHL6z/Gf+Cn+BnujSYm7sPPMdv7H/bcI3jU4zl4zOc87vGv3D4Zrk/8Gk9j Xrgr8Ztwq9XsjsRzHv8Wv8PCMFVXTbXC3aECZ6nAWfYHd1nl7kj8Mfw4sQQveN9LnnvZ+/7i/lLU eX65xys9v8rn1ntuDd70XAPWotFnrcN6bPD+Fu9txSavtcH0Vt2zdO3UxNbwF5071Sp6h+69SPdO TXR5Tg0m1GDiHajDRA96w7KEOkyow0QaajCxEwMYNAGGkHU/F5YmdmPU/feg5hJqzlSYWanuKtVd ZTwsrSx2Oy5MNyWmmxLTK8s8Hm96lEMNVibCsspK7OX+3tjH8/tiP+zv+Qmh1UrfaqVvrZzk8w70 noNwMCbjEBzqvYd5/XBMcf4jPGfCmkYzK+8IjTp8VuXd0cRKXlfyupLXlffgXtzntYfCrTp/lkk1 1aSaalJNNQVmmVZTKx/3OXPF/aTPfNrnz/P4N3gGz4aboymmxE2mxB8KK/NrhfV8hUnQreNn6+yv 6+wlunaxrl1tzc3o2Fd0bJeuXKcb63XhUl24Qdd9RmddpZMW65j7dMwKHdOtSx7WJRt0QZ3q/43q v1T1L1P9+X+pcJaKfyv6N/NqgUh+Z8VaH1tslVpiJvzJcy/hNevc615bHppNz2Yr1zIzq8/KtcQa 2CfaXqvXEqvXEvNrnshXmFO9Il9rFi0Xdat502nedIq827zeKPKdZvZGM3ujebJc9AvNgoVmwUJR 7hHll/J7HqvX+sS/mrRXhyVWsCVWsPVWsCV6s09v9lnB1uvPBfqzT38u0J8L9OcCK9j6xJ2O+wnu wb2h2VRvNtWb9Waf1Wy91Wy9Cd9swjfrzQVWsyV6c4FeWqjuF6rzhWq613qy0XqyUd32WlM2qtVe dbpcXc5Tl/PU5Ty12KvWOtVap1rrVFu9aqtXXXWqq051tdxatFFNLbfCLVFTC6xw660czepjnvro VR+ddpBL1UEdXrVDWxn+ROntVod1auFTpvkW03yLelhD1Q6qNlK1UU28aHJvpewqk3oLZVdRdpXa 2KE23jGNN5jGG0zjDWrkRDUyYsq2mbJtamWTOkmarA0ma4PJ2qBmmkzTTaZoq8m5wURcZyKuo/p2 qm+n9nYTcJ0JuM4EXGcCrjMB11F2u6m3ztRbZ9KtM9FaTbE2U6zNFGs1xRpMsQYTrNUE22SCbTKt NplWbaZTm+nUZjq1mU4NplOD6dRgOm0yldpMpbaxqdRgGrWZRq2m0QburDJZtpgsW7i0ikOrTJet pstWE2SrabHFtNhiMmwxGbaYDFs41cipRk41mgpbTYAtnGrkVKPO38KpVTp/nY5fp+PX6fh1On6d jl+n4xt0e4Nub9Ptbbq9Tbc36PY23b6Fi426fIsu36LLt+jyLa6Je+yO8/vqM8K70Zm6LH+d9R0d NUdHzdFRr/F5pq7Zzddn+FrL11rdkuJrF18X8XQRTxfpiJwuyPFiJi9m6oAcP2aq+Jwqn6PK56jy ObyYqcpzqjynyueo8jmqeTe9FtFpkWreTatFtOqiVZeq3k2vLpW8mz619KmlTy19ulTzbtW8m0a1 NKqlzyLVm1O9c1TubjnXyvH1cJ+KHZHBUo92iT0TnlObW6ODZbbLo6TMemXWK7MBWTWYAymZNcis QXS7RNcgugbR7RJdg6h2iWiXiHpF1CuiXtHsEs0u0fSKplc0DaLIX8v2Roc5U8aZNjlT0pmSztRD w/w1aqOzDTtbo7M1OlvG2RqdrdHZMs7WSIshWgw5a4YWQ86cceakMyedOUmLIWfPOHvG2ZPOnnT2 RmfPXx8mXSNsNS93hbdk/ZYzDzvjFrPsJRO3xcTNXx+8WJi4Jd41PHYNlRr7N0ynxK+ITiso1+GV LV7pKDzKX9vtKeg4buyoIY/SPr/Z5w/aDbfa06YpPCrPckpEGGdPWoJSTPH4GMwNAz5ja8GZdd69 2SqSj3E4OsZnrPDKn+g35LP+7B3v/O36vrDeROZLKcpQHv4sq8tk8+90HKLjVjpupWP++nor/YbE 8GcxrBDDCjGsoOXfX3dPxiEfuP6e4v1H6cVj3M71/ic9l7/mLpJzfzRJfINiGhTTDjHtGPsGZ6fo e8W1U1w7xbFTHDvFsNO5B5170LkHnXeH8+5w3h3Ot8P5djjXTucZdI4d0VE+/WXZvyHzVR+Yshvp vNCZsoWpWl74S5GfjHm5SfbV+b/o+dv0kfEqZ33ZWV921pf/l5MnP2mmeF9+yhzjNj8x5nrvP06M 8YVVdJd9wG7X1iV8/Uq4ceyvO95y5q8W/mL0NHFv9c4XudbguqBZ/K9QafEHJkh+ZWil1Fxe59fd d6g1l1pz5fOKT73Hpy3iYoO9WzMF51JwLicbqDhXR7TqiFaONsjvFV3RKsetctwqx61cbbAHa7YH a7bfav6HydHK5QYuN7w/Oab4jKPCXLm/Iu+tXG4oTI/JVN9M9c2FbyMypsju8Lqo+yi/WcR9Is5/ h9NH7c3U3izKPhH2UXkzlTdTeTOVN1N5M5U3U3izM/VReDN1N1N3M3U3U3ezrsqYuqNWP9WjwjLh lShmFRy1U9odxe1GVno06FF3NMWjftcwOfuTfvuTfivliJVyxEo5MvYdYcqeZcA+PmfFS1npUla6 ESvdiP16zmqXskfP2Vf025PnrG4jVrcRq9uIfXfOvjtnZRuxso3Yd/Rb2VL2Hv1WmhErzYjVZSQa by3fLZInrN391uz8vu4dZ+3n4NMcfLowVcZb7YfjE0ySk0JaBr3elY6fGe1twrjmiU51ntao2Ods 9zn571xz+QxknCh8g5DKv58SE/TTmSHn+fy3st7huM7oAI/y2Q/Lflj2w4XMr7RXuCo0fSDzYZkP F7JudLsO67EZWyA7mQ3LbFhmw9HhzraWvhn6ttC35YNX5s6ddpYkbTPOkHSG5PtX488XvvFL0jZD 2xbaZv7uCr3F49bCt4CFK3Xatjh7krYtH7xaj4pknomOile6NyE8abfUb7fUb7fUL6YXxPQCtTJ2 TL12TPlv1/rotMPOqJ8D73Lgtxz4revI/VxH5v86Mr/r6bXr6RXXC3Y3vXY3vXY3vXY3vXYzvXYz veJ5wU6m1y6mX0wv2FH02lH02lH02k30RqWi+YMz73LGnDPucrbdzrbG2dZER3p1G926xbhJjJu8 Mzv2Hfb/cOhMO7vz1PUFdJgXumk4SsPR91163nO1Hr/k9mU7rZVuP+hai8et+Jt7b3tPh/d3hk1/ 5+JEqnVQrYNqHZTqoFSHuNvHvpPqoEgHRTqo0UGNDmp0UKODGh3U6KBEByU6qNBBhQ4qdFChIzpY nm/L8W05vi3HnXLcKMcNctwgxw12qvmq2yCfDXaVKbvKlFzetrPMV+AGuWyQywY7yZQ8Nshjgzze lsPbctgghw1y2FD4V5RHxr8RHRnNib4ZHouuxjW4OTwV/TA8EP0I/w0zcDu6wpxoO5IY8p7d4f5o FHvwLt4L9xcdFxqLjscJ+DBOxEk4GafgIzgVp+F0nIEzcRbOxkdxDs7FeTgfH8PH8Ql8EhfgU7gQ n8ZnMBWfxUW4GJ/D5/EFXIJpuBTV0aSiZeGVolfDi0Wv4XUsxwqsDEuLVmE16rEmLC1+MjxQ/BR+ jQaP1+ItyLX4rwjh/nH7hMfG7RfmjLPLHmeXPc4ue9wkHIiD0BEeGJf2nj4MhAdKjsdZuC48VnI9 bsB3MT08VXIL6F4yOzSWNIalJa54So8JS0uPxXHhxdLjcRpO9/h8XBnmlH4NV4X7Sx/FPHR4vA2d 4Flpb3iqNIWdXhv2OBvuL4uFxrI4ijEOJbBTLLNTLBuPclQggUrshb2xD/bFftgf54SlZefiG+5f 43am22fdzg8vlmVC43ifNX5/++OvR/uFtdH+MP2iAzARk3AsjsPxOAEfxufxBVyCabgUX8Rl+BK+ jMvxVXwzPKFyn1C5T6jc26Pvh7nRdNyCW3Ebfhjmq+b5qnm+ap6vmucX/yysLb4H9+I+/ByzcT8e wIN4CL/Aw3gETzruKfw6zOf6E+NawtpxW/A22tHh+XfcdiPt9T4MeO69sLakBKUYj3IciINwNI4B HUrooDrml5zh9iy357n9LL6Oq/ANVOG68ITKeULlPKFynlA5t6uc20vkWyJfFTS/7Lt5baIHQmP0 IB7CL/AwHsEzeBbzsQDPoR5r8CYasBZvoRHrsB4bsBFNaEVXeN5MeN5MeN5MWB3twjAyyGIEu8Ni c2KxObHYnFhsTiwu7gmNxb1IYQfScHVS3I+dGMAghuCK5b8TdybgURR5H66u6unu6ekJVwj3fYrr gevqikdcN7oegLKKoiDggotgotwCIeCNgnIqICioICIoIvHiEA/Wc1UEBhgGgtyEEDuK3AlT39tN 3E9XXd399nm+5Hnt7uq6urqq/r9fdpkxD0JQLg1av8x6W2KzF9isfZu1brPWbda53VF/bF/HsTPc RJ6u0F2/bN/O9WAYAnfBMBgJD8IYYL3ZjJHNGNmMkc0YsZ5etp/lOJfjyxyXA+NgMw4242AzDqy1 Jay1Jay1Jay1Jay1j1lrH9v7oRTKKHuQdMaDdfeycbowRTURASv41png+yQgCsGnd8fAC7+fuJrI gHYiS5wPvXU+czyfOZ7PHB/CHO/HHO/HHO/HHO/HHO8nhlPDCJ3HPM9jnucxz/OY53niPlFF3A8P wIMwBh6Ch2EsjINHYKloKJbBTj2CNzqCNzqCN/oYb3Q+b3Q+b3Q+b3Q+b3S+CD5B+pgu4K0W8FYL eKsFvNUCY4Zeb8yEJ2EWzIan4Rl4FubAXHgO5sHzMB9egAWwEF6El2ARvAyL4RVYAoXwql4vzxRV ZFuRJc/mmA2X63x5hR4kr4JOXPfV98h+OlfeDrk6F812leqqB6PbrlI9OA7Wn6gheo36QkTUGpGp 1qF61+PKNwhX7dTz1S60yG7RWu3huDf4bCCO+0V1c7CoZg6BoXAXDIPhMALyYSQUwCgYDbN1HvtF HvtFnrlWVDHXQQLWwwbYCEnYBCnYDFugCBhPZnsBs72AvSY/Uk2vZ9aPYI/Ji+wXLvtLPvtLPvtL XqRcVLMUMLes6lADmsEpOs9qw7Et/FZksafkWedynqvz2T/y2T/y2T/y2T+GsH8MYf/ox/7Rz2Iu WSOAuWQ9oddbM8J/Qb/ebgANoRE0hrbQUc9npY1gpY1gpRXYA0QVeyDcDffAJJhG+myOz4iGrKYC eyHn28i/HXYAc46V8xgr5zFWznxWznz7KxG1fSgj/0HuM/9YQQX2EVHFydTrnZqQBbWgNtSBulAP 6gN9deirQ18d+uo0gabQDJpDC+hFXb3hVijgehSM1uujhl7vdtGD3JugQOe6o4F147JuXNaNy7px WTcu68Z9FMbDBJgIPK87GabAY/A4TIVpMB2egBkwE56Ep2AWMD7u0/AMPAtzYK6oEsuHkVAAo2A0 MLYxxjZ2L7C+Y6zvGOs7xvqO0c8Y/YzRzxj9jNHPGP2M0c8Y/YzRzxj9jNHHGH2M0ccYfYzRxxh9 jNHHGH30ThVVMqLgQoz9QarVrJSd7EbBWfDZI7XkXexmXvjtAhbY4EAUXIiBF36Cvcdu5qEAUiiA FAoghQJIoQBSKIAUCiCFAkihAFIogBQKIMXOV4OdrwZKoAQlUIISKEEJlKAESlACJSiBEpRACUqg BCVQghIoYZfswy7Zh12yj7hN+6Iv9IPbIRfy4A64E/rDABgIg3RfdtT+7Kj92VH7s6P2Z0ftz26a w26aw26aw26aw26aw27qspu67KYuu6nLbuqym7rspi67qctu6rKbusTdLcTdLcTdLcTdLcTdLcTd LcTdLSL4e8d8eAEWwFJRh523DvHXJ/76xF+f+OsTf33ir0/89Ym/PvHXJ/76xF+f+OsTf3126wHs 1gPYrQeIvXjZYtgHJbAfSuEr8KEMvoZv4ICexs4+j519Hjv7PHb2eezs89jVh7OrD2dXH86uPpxd fTiaPommT6Lpk2j6JJo+iaZPoumTaPokmj6Jpk+i6ZNo+iSaPommT6Lpk2j6JJo+iaZPoumTaPok mj6Jpk+i6ZNo+iSaPommT6Lpk2j6JJo+iaZPoumTaPokmj6Jpk+i6ZNo+iSaPommT6Lpk2j6pHGN yDI6wZ/hWrgOZugEkShBJEoQiRJEogSRKEEkShCJEkSiBJEoQSRKEIkSRKIEkShBJEoQiRJEogSR KEEkShCJEkSiBJEoQSRKEIkSRKIEkSiBlyjES6zAS6zAS6zAS6zAS6zASxTiJQrxEoV4iUK8RKHx qXCNz+BzWC1cophHFPOIYp5sF/wbVY5/5Hi5Hk0060g06xhGs666VPaGvkS370U1madLiWwXEtn6 EdkuJLL1w4tPUIP0S2q5fk+tFBnqXaLfavz8Gnz6OlGLKFdClFNqI/7+ZKSLEOmah58xWUL6fiLP YOER5TyinEeU84hyHlHOI8p5RDmPKOcR5TyinEeU81DSJSjpEpR0CUq6BCVdgpIuQUmXoKRLUNIl KOkSlHQJSroEJV1iTtO+OR2egBkwE56Ep2AWzNY5RM4cImcOvqsQ31WI7yokirpEUZco6hJFXaKo SxR1iaIuUdQlirpEUZco6hJFXXSmj8700Zk+OtNHZ/roTB+d6aMzfXSmj8700Zk+OtNHZ/rmIV1q HoYjcBSOwXEohwpgTRCZhxOZhxOZ+xCZE0TmAfi/JP4vif9L4v+S+L8k/i+JS0jhElK4hBJcQooI nhPZpX2cQgqnkCKS9yGS94nQpwh9IqLnENE9XEMqkuZaa98SYIAEJTwivYejSOEoUjiKFI4iReT3 iPweziKFs0hZ9cnbAJqR1oLrlsBei8tIoQxyUAaedSb3mYOogxq4jhQKIQeF4OE8UjiPFM4jhfNI 4TxSOI8UyqEPyqEPyqEPyqGPxT5qsY9a7KPWIBgMQ3Rf1ERf1ER/1ER/VEQOfjaJkkigJBLWrPAT mbKsxfBq+KlMWdb7HL/QhaiMhMW7xPcmrSMiC8WRQHEkUBwJFEcCL1yIFy7EC6/AC69AgSTwwyvw w4X2+cLFExfiC3x8gY8v8PEFPr5gCyplHr7Axxf4qJUBqJUBdjddat8M3fVw/IFv53LOmrLvgDuh PwygzoHAc+EdtuAdfLyDj3fwUTguCsfFQ/h4CN8eS/5x4acK+qgeFz/h4yd8/ISPn/BRQcNRQS4q qA6+wkcJDUcJuXgLH2/h4y18vIWPt/DxFj4KaQAKaQAKaQAKaYC9i7p3wx5gr7fZ61FN01BN01BN 81BN81BLw1FLA1BL81BLw1FLLl4/iddP4vWTeP0kXj+J10/i9ZN4/SReP4nXT+L1k3j9JF4/iddP 4vWTeP0kXj+J10+iuhKorgSqK4HqSqC6EqiuBKorgepKoLoSqK4EqiuB6kqguhKorgSqK4HqSqC6 EqiuhHMWffotnKcLnXbQg7p7cd0bboW/ktaH423QF/rBnboEhZZAoSVQaAnnbspMIP158s7XK5wX OF8Ah3QyKkQWCi4R5dmiNXRhtKZw3Wv1Tvc6uB666I4ou45uN86H6VJ3OOTDd0rvHs4fgDHCQ/F5 KD4Pxeeh+DwUn4fi81B8HorPQ/F5KD4Pxeeh+DwUn4fi81B8HorPQ/F5KD4Pxeeh+DwUn4fi81B8 HorPQ/F5KD4Pxeeh+DwUn/f/qPi8Hyi+mmK8vsDoLjoYPcW1xi1imPEXcanRS1xg9BY3yMtFF9lX XK8660tUF/0HtUzPUyt1B7VDf4w2zFTscGqPnqSK9Ydqn6inSvBb+/Vh0UiMT68SC/Va8Te9ltov qvw02HOo/VRqP5XaLzb66sPE1t20gpvDlXXW7WjlQloZolbo5eotWJkuVe/o14hxG9V7+n21So+n 9ftp+ajarffSejtan0DritZn0foq4ajP9Vz1BX3Cyau1updap5eqBKU26M1ExSJ06kL9AX37gJw3 Ejs/J/c0cuertek0uZ8h9xXE0dcocRclZoSf7XgGvS0gmjcgel8hOxDJ++q+8g6h5AJ08ir9F/mh ni63it/JQ0TkTFFFnaGfUyuER5Q+gyd4hZY+xI8qtRavuV6/SpSOUHuaJ0oQqfMrI7Wq9KSKJ9ur 9vFUJaTv118ZNwhTLxURsMAGB6LgQgw8iEMGVNHLRVVopzeL8+E+vVjcDw/AgzAGHoKHYSyMg0dg PGO4VK8Ry/QaQ+rNhgITImCBDQ5EwYUYxKEqVIPqUAMyoSZkQS2oDXWgITSCxtAEmkIzaA4toCW0 gmt0kdEJ/gzXwnVQAKNgNNwN98C9cB/cDw/AgzAGHoKJepMxCSbDFHgMHoepME1vkmfqxfJsyIZO +k35sE7JsTrFLO/MWyllnlUwxxbzJkqZY1czxyrU4XSxOsKKOKptdSx9RB1Pb1bl2lIV6b3qhM5W adK1rmNG0sWmpS8xbW2bTvqIGU1vNl1tmbH0XtPT2Wac9AzyDdZLzSEwFO6CYTAcRkA+jIQCGAWj 4Vm92ZwDc+E5mAfPw3x4ARbAQngRXoJF8DIshldgCRTCq/AavKmLzKWwDJbDCngLVsLb8A68C+/B KvgbrNWLzXWQgPWwATZCEjZBCjbDFijSiyPleqmlgPlrRfRyqzrHGtAM2kBb+K3ebJ3L8RFdZE2F 6VzznNZznPM8Fs9j8TwWz2O9TNpiWAKF8AYsJX0ZLIcVQN8t+m59wvnf4VPOP4PPYTVsgI16k5Xi 3l7YD9/AAfgWDsIhOKKL7AyoAlWhGtTWm+w6UBfqQX04W2+2z4UBerE9EO6Ge2ASzIZn9Bp7Iccj erHTShc5p+rNzukcz+TYEa7m/Ea9yenF/d5wKzxM+nTSn4AZMBMWQrneFBW6KFqNI+sryrqK1oX6 erPbS6fcfpALd0B/GAysd5f17rLeXda7y3p3We/uozAeJsBEoL/uZJgCj8HjMBWmwXR4AmbATHgS noJZwDO6T8Mz8CzMgbl6cexKnYpdBe2hA3SEq+Ea6AT5+s3YSCiAUTAa7oZ74F64D+6HB+BBGAMP wcMwFsbBI/AojIcJMBEmwxR4DB6HqTANpsMT+k3vVL04I6rfzHAhpt8UJrFiMTt/iVovTmdfrhCP ixF6psiHkVAAo+CYTuGfU/jnFP45hX9O4Z99/LOPf/bxzz7+2cc/+/hnH//s4599/LOPf/bxzz7+ 2cc/+/hnH//s4599/LOPf/bxzz7+2cc/+/hnH//s4599/LOPf/bxzz7+2cc/+/hnH//s4599/LOP f/bxzz7+2cc/+/hnH//sB5/CZXxAPz/UpXjWUjxrKZ61FM9aig+djg+dju9ch+9ch+9cJ+fq4vD/ H3ny/3W0XR7R24lmSaLYTLVaNCJebiOCPYKHm4mHm4mHm4mHK8XDleLhAv+Uwj+l8E8pPJOPZ/Lx TD6eyccz+XgmH480Ex80E58yE08yEw8xEw/h4xFK8QY+PqAUH1Bqt9Ep+9Tw8zhL0f6Blk+hs1No 6xRaOIUGTqF/ffSvj/710b8++tdH//roXx/966N/ffSvj/710b8++tdH//roXx/966N/ffSvj14t Ra+Wold9NGqpM4S67+b8+eBT07SP3vTRm6XRTNZTFz0djTkdTbkOTbnOK9DF3igYrYvjmXp7vCZk QSNoDPeQPkdvF5Ko8iJxHR2nlonz1HJxs3pbnK3eEbUZ3zfUeyipVaKV+lx0ZKw74usjKIaL8PbV VUKcxbh/iXJoiM7ZQepO0Qa90BG90FIVi8uo973Kv2WfSkvv6oXknxK2uZh7/VAVy0UGaR9ztTr4 XMoff5au0Vdk//Tn6dKftqyOC2i1PfHwCvpwMqUt0fIIqZcQLZcTLUvCzyjeH3wbJan1uboo/Jti LfK2oA/BdxHsEaeR43SuVotsnjCTew151uBT37roz9Rg0Y7+v2deiF6TpHzE1d/JTWxCE5ZxVcRV rohzdZyrj0QrYYpsEQELbHAgCi7EwIM4ZNBiZ1FT3YTG6w65PNNydOA76Mx39RpzsMg2h8BQuAuG wXAYAfkwEgpgFIwW2Xj5bDx7Np49G4+ejUfPxpNn47+z8d7Z+O3s8Psv4qjbg7RUxFPsUW/zJoNv M3lXv4663c+zD2ZMltGvt8jF0/LscVHd+EI0M9aIMxmZ7ozDH9VN5Ooquqru4WfMdVW5+t3gU4nU UL1DTRXnqGniXNrxedMtUDKLzPPEWWY7cSaj1VU0pERD2jmbtzlYNKalr4L2w5bild9r8qHqRumb yd+T4y0cBzPDvtCb0Mil6ONj4fzZIBxKKWEF34RC7ixyZpEzSk6fHGUiS+xkF0VDid3opoG0FLzT oXoduruUt16FHXdNWF+CN7ieUtQZKOJIdV2Bh6/Aw1fgkSvwyBV45Ao8cgXet4I2O+vi4F88UWMb Vood1rZeHxS1ftBmN/asnpDHsw1Gia/W39C7Mp7DZ8bVpO1DlHqfdmO0e/QX243R7o7gu1morTrt RqjxEDWWUuNBaoxS2zeVT1HBOutMavB5gd1Q8j1hIHcGizqUjNJji5KHKVlByTh9SQejRslyVsVO 8SexC3bDMWb2cSiHCjjB7tAZ59JFn6m6sVvcLHqonhxv4ZiH9xlIf4bqOWok82Kq+D3z4QJG/Ata bBe+m7X6qbC1hN7AmsvE5RyvnCNnmdRtpkGLVpHq4k/2TdAVuotW9jSYC9u43g47gH7aZaQd5HiY vgWf/1hGz47xzMfoWRue+xg9a8Nz1+W5gx3D4XldnnWv2iiqhrNuBSXeo8QuStSlxC5K1KXE78ld lT7vCWfeWl1Ov49ScldYKhF+L8FNtNeVmdydYw+OQ9gVd4im7Hhl7DEuO2MddsZq7Hcrwm/UCd5f ilyKlDLeQ2fOuoRrI/g0vCw1iFl1F/FuD/0upsV92g/n2zbK7aKcS+0ONUvupEQd0Vt/I26Fv8Ig 3n5n3udN9Ks7DGFmBrl3Mkv2MNJ76dM+/GUJtewnTl4oakWq6m8ipfCV/sbKhTy4A+6EITCUejMq vxMoSc0pak6pQTzVEPb8HbzHncyiXayg8GnZh4sZo33609CL16J/5fSvnP6VVz598DflrdSylVok tbShj1Wp5Qi1pKkl+KR5hxq2B99HRP/K6V85/Sunf+X0r5z+ldO/cnGa6C3ai1vhrzBC5Ih8GAkF MErk0GIVWvwNe1aEEe7EnhVhlDuxZz3PSC9hpN9inn7IPL2CedpeLdCTeKa/EyFanuwNcSvoTTFq 4jzRjjnazrxQJ83ZIsd8Gp4ROZGqon1kG8dSjl/B1yLHOgXOgVzR3sqDO+BOCPrn0KvDlfNGVs4b Gb6rYAT36b3hXyMW0e95lbmyKnNl0W+fnGeFf4HYp9cxM3LTq/CCX+H9tuH1vsLbbTNbp3cz13LT PqllpJSZrfVF1Jqb3qoOM87llK5gbzihPzcj+gi+8KgZ0wfJ+Tk5LwvLvsvdNaSsIcUNy/rqOO2V Myon9Ho8ZtqMCouyaXKtx0umyZnNvpSb3kMraVzqQXpWqo5xLKfVCmbmyZIVtJrGnR6kx6Wmw9Gl FzHST9ZUwRMcYtbl4muPCINayqglTS2aGorDti1hULqM0mlKa0oWV/bhlGCc0hPpww5KN6P0Zkof VsdZsUHvK5jHJ5hxaXSC1ifoyw5qa0Ztm6ntsBnVifCpYrxnT1TFKZdQ8wn69FIQRbWkxqP0o0il haTUUdouMuOct9ZNghzp1eTYS3vBSKXIsZc6g1FKUcfXjO4/vS/efuV7ovQvvJ8wb/heyPsL74Nn /D++B/bTf3P82WX+y+POM/7MeId3fnKcRYaZKaJmTfpXW7hmXWqrR5n6aIYGnDfkXiPuNeVec65b cK8l91oRD0wzixbqcbcxxxa8E8/M5AoPYdai/bq0UI+Wgroakt6I9CakNye9BenUw1sIcgct16vM EbQU1FWdfknu7jazSKkFtUVD+lednLupsyH9k/RPUmq32Zj7TaAp6c3J04K0lpy3Cr6VnFqK6Gvw hNKsQ1/rikhlLUHpIvofPKE0m3GvOfdOlpY8bybUZO5l0efa1FuXZ6nH269PWw2C5+J+I+435n5T 7jcnrQX3W3K/Fc/HU/BualJvFqm1oLbeQB/SjM4Osz7vsgHP3JA8jcjTmPtNoCl5mpGnOXlakqcV kS14T144rrVFJv0IRuwo/cikHzH64YVj25Tr5uEIHqUPmfQhFrwVocJnr1s5zid7H4yeCp/7ZImy yl5LUeU/nROsWp/x+6d5wWo/Q8T/3blBqTOF/XPzg7stRI3/1hyhtt/w1P/hPKF0a1Ht/zpXqOW8 4In+O/OFN/FJ+B7/ozkTxob4vztvwl29tTqc3sdO2pMdpz67Wgd1PF3GrnapqkiXsPv0ZldrzK7W zoyk97Gj9mQ3qs+u1sGMpsvY1S41Y+kSdqbe7GqN2dXamZnpw4zIaYzIKYzIKWZtruvo3zAiGfSq LaPSklFpYTYkvRH5GpOnCTTluhn5mpOvBflakq8VsyaKc/PwXNkq+F6fVaIGajcTpdscVfF7tML7 qL0q4XcLLTO6i/ONnuIy4xYxzvgLx1449876SXU9XuQGvQzl8WT4TXWn/Itc74e5gu9A2himfne1 +B9XEie/0nhHLw7Pgm+328FZFVzyaUKIdnjSNuIP/J4prhLXirbienEDqTei5S4Qt4lHxJVivFgg 7hTLxEqu3uF3kvhEbBCTRZLf2aIId/K02EuNLxj1jHpirdHQOE2sM9obHcRO42rjOrHbuMnoJvYb PYwewjduMXqLMiPXuEN8awwxpovDxgx+6xpP8lvPmMVvfeMFY4HRwHjHWG00kmfKs4wz5NnyXOMs 2U62M86RF8ls41z5R5ljnCcvk5cZ58vL5VXGBbKD7GBcLDvJa40/yOtlFyNHdpVdjT/JHrKHcbns LW81rpB9ZB/jKtlX3mG0lwPlUOPPcpgcY9wgH5aPGn3kBDnVyJXT5RPGYDlXvmIMlYXyfeN++aHc YEyTSbnTeF7uk/uNQlkmvzZelwfkEeNNeUyWGyulVsJ4V0mljFXKVnHjfVVFVTc+VZkq0/hCZam6 xhrVRDU1NqjmqoWRVK3UKUZK/UadZhSpM9QZxpeqrTrL2KbOVucYO1Q7db6xW12oLjL2qovVxcY+ dYm6xChROSrH2K86qKuNUnWd6mKUqZtUL+OgylV5RloNVHdJoUaqkdJSo9Qoaaupapp01CK1SLrq VfWqjKk31BvSU0vVKhlXn6uNsrbaofbLpuqw0vI3ZsTMkOeYmWZrebF5oXmh7GwONsfI682x5muy n/mmuVJONT8zV8unzLXmbvm0WWxq+WrEjbjy04gX8eRnkaqR6vLzyLrIJrkmsiWyTSYjOyM7ZVFk T2SP3BopjuyTX0b2R76W2yMHIgfk3sihyBFZHDkWOSb3R8oj5bI0csKKyK8s28qQh62qVlWZtqpb NaW2alsNlbKaWL9VrvU763eqgXWu9SfV0Lra6qzOsG627lXnWPdbD6pu1sPWONXDmmBNUH+xJlmT VS/rcetxdas1zXpS/dV62npa5VpzrDkqz3rOek7dYS20CtWd1uvWCjXMett6T422PrA+VPdZH1vr 1QPWRiupJlspK6Ues7ZaX6rHrb1WiZpmfWNVqJm2sKV63rbtxmqB3dI+W/3NPs++UK2zL7YvVkn7 j/af1Cb7Sruj2mp3sjupnfZ19nVql329fb3abd9k91B77F52b1Vq97X7Kt++3R6myuwR9ih1wr7b vseU9oP2GNO0x9rjTMueYE83HXuGPcOsbj9pP2nWsGfZs81Me64918yyF9rLzVr2Kvtjs7W9xt5g nmFvtg+Yv7MP2sfNDnaFrc3rnJZOS7OL09ppY97onO6cYXZzznbONrs75zntzB7OBc6F5i3Oxc7F Zi/ncudKs7fT3mlv9nE6OlebtznXOp3Nfs6Nzo1mntPL6WPe4dzpDDAHOSOcEeZQp8ApMO9y7nbu NYc5Y5yHzXxnnPOIOcqZ4Eww73YmO5PNe5ypzkzzXud5Z775kLPQWWiOdRY5i8xxzgHnW/MR55Bz yBzvHHWOmhOibHzmxKgZNc3JUTvqmlOiXrSWOS1aJ1rHnBOtF21ozo02jjY257vXujeZL7g93Z7m K25vt7e5xL3N7WsWure7t5uvuXnuHebrbn+3v/mmO9Qdai51R7gjzGXuSHe0udwd475ovu2+435k 7nbXu1tM393q7jYPu8didc10rFlsYqRxbHLsmcj42OuxlZFZsdWxA5HnPdurHfm7d6p3aaTI6+Ld Fjnq3e71t6LeQG+wVcUb6g2zqnsjvBFWTW+k94CV5T3kjbcaexO9iVYrb7L3mNXam+o9bZ3qPes9 a53jzfVetM71XvZetS723vCWW5d5b3lvWVd5b3tvW+29d72PrA7ep95aq7OX8BJWN2+Dl7Ru9lLe l1ZPb7v3tfVX71vvqDXUO+5VWCO9dFxYo+MyLq1742bcsu6LO/