From Michael.Jones@microsoft.com Mon Dec 10 17:31:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6D21F871D for ; Mon, 10 Dec 2012 17:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F64BaSm9vVbT for ; Mon, 10 Dec 2012 17:31:33 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 131B321F8713 for ; Mon, 10 Dec 2012 17:31:32 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.204) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.578.12; Tue, 11 Dec 2012 01:31:30 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Tue, 11 Dec 2012 01:31:30 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 01:31:00 +0000 From: Mike Jones To: hideki nara , "jose@ietf.org" Thread-Topic: [jose] JWS header x5c is a JSON arrary? Thread-Index: AQHNY9y+pzt6UL1nLUeqmKNszSkrkJgTtdXQ Date: Tue, 11 Dec 2012 01:31:00 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366924C6D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464002)(56776001)(47446002)(76482001)(74662001)(47776002)(23726001)(74502001)(5343655001)(54356001)(59766001)(56816002)(44976002)(54316002)(33656001)(31966008)(46406002)(49866001)(46102001)(53806001)(51856001)(50466001)(16406001)(50986001)(4396001)(15202345001)(77982001)(47736001)(47976001)(55846006)(42413001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 069255B8B8 Subject: Re: [jose] JWS header x5c is a JSON arrary? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 01:31:33 -0000 Hi Hideki, I'm sure that you probably already saw this, but I wanted to follow up and = state that in the -06 versions of the JOSE specs, "x5c" was changed to be a= n array of strings. Thanks for your attention to detail when reviewing and= implementing the specifications. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of hid= eki nara Sent: Monday, July 16, 2012 10:27 PM To: jose@ietf.org Cc: Jim Schaad Subject: [jose] JWS header x5c is a JSON arrary? Hi all, In http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section= -4.1.6 , "The certificate or certificate chain is represented as an array of certificate values. " But, Appendix B gives us a text stream which seems to be the same one as th= e return from "x5u" . (http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-= B ) Am I missing anything between lines ? I like the same format as the return of x5u anyway. --- hdknr _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Dec 10 17:35:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE2421F872C for ; Mon, 10 Dec 2012 17:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBRf56XMopIR for ; Mon, 10 Dec 2012 17:35:01 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id CB91D21F872E for ; Mon, 10 Dec 2012 17:34:55 -0800 (PST) Received: from BL2FFO11FD003.protection.gbl (10.173.161.201) by BL2FFO11HUB006.protection.gbl (10.173.160.226) with Microsoft SMTP Server (TLS) id 15.0.578.12; Tue, 11 Dec 2012 01:34:53 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Tue, 11 Dec 2012 01:34:53 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 01:34:26 +0000 From: Mike Jones To: "Axel.Nennker@telekom.de" , "jose@ietf.org" Thread-Topic: order of step for encryption. JWE section 5 Thread-Index: Ac1y1wQPutAF2XyLQPOP3bTnOMCRMwALGibgGQ76JcA= Date: Tue, 11 Dec 2012 01:34:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366924CBC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.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.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914002)(377454001)(13464002)(43784002)(56816002)(74662001)(4396001)(31966008)(53806001)(46102001)(50986001)(33656001)(54356001)(54316002)(51856001)(74502001)(55846006)(47736001)(49866001)(47446002)(47976001)(44976002)(23726001)(47776002)(15202345001)(56776001)(5343655001)(76482001)(46406002)(77982001)(16406001)(59766001)(50466001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB006; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 069255B8B8 Subject: Re: [jose] order of step for encryption. JWE section 5 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 01:35:02 -0000 Hi Axel, I'm sure that you probably saw this already, but in the -06 version of the = spec, this ordering was cleaned up, as you suggested. Thanks for your deta= iled and useful input on the specs. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Sunday, August 05, 2012 5:20 AM To: Axel.Nennker@telekom.de; jose@ietf.org Subject: Re: [jose] order of step for encryption. JWE section 5 Thanks for the careful read, Axel. I'll work to make the write-up of the s= teps clearer, using your input. In particular, I'll look for ways to bette= r structure the steps. (Unfortunately, the xml2rfc tool doesn't do a parti= cularly good job of structuring lists with sub-lists.) Answering your point 2c, a random CMK is not used in this case. Instead, t= he agreed-upon key is used directly to perform the encryption. I also plan= to add a key agreement example in the next draft. I expect that this will= help make this case clearer. Thanks again, -- Mike =20 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l.Nennker@telekom.de Sent: Saturday, August 04, 2012 11:55 PM To: jose@ietf.org Subject: [jose] order of step for encryption. JWE section 5 Hi, I have two issues with section 5 of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html 1) I would prefer it if the order of the steps 1 and 2 were reversed in sectio= n 5. Currently we have: Message Encryption The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. 1. When key agreement is employed, use the key agreement algorithm to compute the value of the agreed upon key. When key agreement without key wrapping is employed, let the Content Master Key (CMK) be the agreed upon key. When key agreement with key wrapping is employed, the agreed upon key will be used to wrap the CMK. 2. When key wrapping, key encryption, or key agreement with key wrapping are employed, generate a random Content Master Key (CMK). See RFC 4086 [RFC4086] for considerations on generating random values. The CMK MUST have a length equal to that of the larger of the required encryption and integrity keys. Step 1 refers to the CMK that might be randomly created in step 2. I think = it is better to have the CMK generation . 2) I find the text of the current step 1 confusing. 2a) The first sentence is nearly a tautology 2b) All sentences begin with When but the sentences two and three are alte= rnative choices and the first is not. 2c) Does "When key agreement without key wrapping is employed, let the Con= tent Master Key (CMK) be the agreed upon key." make sense? What is the key agreement good for then? Should this read: "When key agreement without key wrapping is employ= ed, let the agreed upon key be the CMK" ? There SHOULD be some randomness e= .g. through the epk. Could we structure these steps more? I) determine the CEK, generate random = values like IVs and epks II) build the jweHeaderSegment (e.g. put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) buil= d the jweCryptoSegment V) build the jweIntegritySegment VI) base64url encod= e and concatenate the segments ____________________________________________= ___ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Dec 10 18:30:36 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C4621F8735 for ; Mon, 10 Dec 2012 18:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6sPZCzVmLQJ for ; Mon, 10 Dec 2012 18:30:35 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4336B21F86BE for ; Mon, 10 Dec 2012 18:30:34 -0800 (PST) Received: from BL2FFO11FD008.protection.gbl (10.173.161.202) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.578.12; Tue, 11 Dec 2012 02:30:27 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Tue, 11 Dec 2012 02:30:27 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 02:30:25 +0000 From: Mike Jones To: Hannes Tschofenig , "jose@ietf.org" Thread-Topic: [jose] Extensibility (was "Criticality") Thread-Index: AQHNy8Za1POjZo7ZrECvrKwCKF1CXpgS9lHw Date: Tue, 11 Dec 2012 02:30:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366924E63@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43784002)(13464002)(377454001)(59766001)(56776001)(46102001)(44976002)(53806001)(76482001)(54316002)(31966008)(54356001)(47776002)(51856001)(56816002)(33656001)(55846006)(47976001)(4396001)(16406001)(47736001)(46406002)(74662001)(50986001)(50466001)(23726001)(47446002)(77982001)(74502001)(49866001)(5343655001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB027; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 069255B8B8 Subject: Re: [jose] Extensibility (was "Criticality") X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 02:30:37 -0000 As I think you know, there's an open issue in the JOSE working group about = whether all header fields must be understood or whether a mechanism should = be defined to specify which header fields may be safely ignored if not unde= rstood. John Bradley and Richard Barnes and I have been drafting a note ab= out these choices to the JOSE working group, which I expect should go out a= ny day now. Per my reply to your note on the OAuth list, the intended meaning is "The u= se of this header parameter is OPTIONAL." I'll plan to clarify this in the= next version of the specifications. Thanks again, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Han= nes Tschofenig Sent: Monday, November 26, 2012 3:07 AM To: jose@ietf.org Cc: Hannes Tschofenig Subject: [jose] Extensibility (was "Criticality") Hi all,=20 doing my shepherd writeup of some of the OAuth WG documents I was wondering= how the extensibility story for these JSON-based documents should look lik= e given a statement like this: "Implementations MUST understand the entire= contents of the header; otherwise, the JWS MUST be rejected." Absent a "feature discovery" mechanism I am curious whether any extension i= s actually possible.=20 (Funny enough then all individual parameters then say "This header paramete= r is OPTIONAL.")=20 Since this type of extensibility feature does not seem to a be a new concep= t I am curious how it has been handled (successfully) in other specificatio= ns.=20 Ciao Hannes PS: I remember that this has been discussed during the meeting but I do not= know what the outcome of the discussion was. The meeting minutes do not se= em to be available yet. =20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Dec 10 18:33:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326C421F86BE for ; Mon, 10 Dec 2012 18:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mri+0IJZn0JZ for ; Mon, 10 Dec 2012 18:33:18 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id BD8FA21F86AD for ; Mon, 10 Dec 2012 18:33:17 -0800 (PST) Received: from BL2FFO11FD008.protection.gbl (10.173.161.201) by BL2FFO11HUB005.protection.gbl (10.173.160.225) with Microsoft SMTP Server (TLS) id 15.0.578.12; Tue, 11 Dec 2012 02:33:15 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Tue, 11 Dec 2012 02:33:14 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 02:32:43 +0000 From: Mike Jones To: Hannes Tschofenig , "jose@ietf.org" Thread-Topic: [jose] Namespace Thread-Index: AQHNy8bGSoKXsVYl70eExe2oESJ5YZgS950A Date: Tue, 11 Dec 2012 02:32:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366924E98@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.net> <2F1412B7-4585-4372-9B2F-FA852DA759A8@gmx.net> In-Reply-To: <2F1412B7-4585-4372-9B2F-FA852DA759A8@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366924E98TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(53754002)(51704002)(43784002)(13464002)(47736001)(47976001)(50986001)(56816002)(77982001)(49866001)(5343655001)(59766001)(55846006)(5343635001)(44976002)(33656001)(76482001)(46102001)(4396001)(16236675001)(16406001)(74502001)(53806001)(54356001)(15202345001)(54316002)(56776001)(31966008)(47446002)(512954001)(74662001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB005; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 069255B8B8 Subject: Re: [jose] Namespace X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 02:33:21 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366924E98TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've repeated my reply to your Namespace comment on the OAuth list below. = My comments are in green. Thanks agai= n, -- Mike - Namespace The document defines a couple of claims. Quite naturally one wants to provi= de extension points since others will quite likely come up with new claims = in the near future. The obvious approach would be to use an IANA registry t= o maintain uniqueness of the labels but without using a namespace declarati= on concept like XML does. For some reason that does not seem to be enough to use IANA alone: the docu= ment introduces three types of claims, namely Reserved Claim Names, Public = Claim Names, and Private Claim Names No mechanism is stated how these claims can be differentiated but essential= ly everything is allowed. Section 2 ("Terminology") says that the claims th= at are not registered through IANA may be Domain Names, Object Identifiers = (OIDs), UUIDs, etc. Later in Section 4.2 it is said that public claims could be a URI, which is= again different to what is said in Section 2. Furthermore, Private Claims (as defined in Section 4.3) do not seem to have= the requirement for uniqueness anymore even though Section 4 says that cla= im names in a JWT have to be unique. The danger is obviously that two parties define claim names that have diffe= rent semantic. This will lead to confusion. When claims with the same names= are added to a JWT then, per specification, the receiver will have to fail= . If people are following the spec and using (IANA) reserved claim names, or = public claim names (those containing a collision-resistant namespace), then= the same names will always have the same semantics. IANA is used for rese= rved claim names, where conflicts would otherwise be likely. IANA is unnec= essary for public claim names, because the collision-resistant namespace in= the claim name prevents duplication. Do we really need to support claims where uniqueness cannot be guaranteed? Private claim names are there because in some contexts, the communication i= s between a fixed or constrained set of parties between whom private agreem= ents are a perfectly acceptable namespace allocation solution. Indeed, it = wouldn't make much sense to register the meanings of claims with IANA that = will only be used in a closed environment. Can we decide on a few namespace concepts rather than leaving the list open= -ended? What are the JOSE guys going to do about this issue? The same namespace allocation strategy is being used by JOSE. Btw, is it allowed to use JavaScript reserved keywords as claim names? Yes -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Han= nes Tschofenig Sent: Monday, November 26, 2012 3:11 AM To: jose@ietf.org Cc: Hannes Tschofenig Subject: [jose] Namespace Hi all, I posted a review of the JWT document to the OAuth mailing list but one spe= cific issue is probably more relevant for JOSE than for OAuth. The namespace concept form the JOSE header parameters has been copied to th= e "body" for the OAuth JWT spec: Begin forwarded message: > - Namespace > > The document defines a couple of claims. Quite naturally one wants to pro= vide extension points since others will quite likely come up with new claim= s in the near future. The obvious approach would be to use an IANA registry= to maintain uniqueness of the labels but without using a namespace declara= tion concept like XML does. > > For some reason that does not seem to be enough to use IANA alone: the do= cument introduces three types of claims, namely Reserved Claim Names, Publi= c Claim Names, and Private Claim Names > > No mechanism is stated how these claims can be differentiated but essenti= ally everything is allowed. Section 2 ("Terminology") says that the claims = that are not registered through IANA may be Domain Names, Object Identifier= s (OIDs), UUIDs, etc. > > Later in Section 4.2 it is said that public claims could be a URI, which = is again different to what is said in Section 2. > > Furthermore, Private Claims (as defined in Section 4.3) do not seem to ha= ve the requirement for uniqueness anymore even though Section 4 says that c= laim names in a JWT have to be unique. > > The danger is obviously that two parties define claim names that have dif= ferent semantic. This will lead to confusion. When claims with the same nam= es are added to a JWT then, per specification, the receiver will have to fa= il. > > Do we really need to support claims where uniqueness cannot be guaranteed= ? > Can we decide on a few namespace concepts rather than leaving the list op= en-ended? What are the JOSE guys going to do about this issue? > > Btw, is it allowed to use JavaScript reserved keywords as claim names? > In a summary, has someone looked at the way how the header parameters are r= eserved? Does this make sense to you? Ciao Hannes _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366924E98TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I've repeated my reply to your Namespace comment = on the OAuth list below.  My comments are in green.

 

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

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

 

- Namespace

 

The document defines a couple of claims. Quite na= turally one wants to provide extension points since others will quite likel= y come up with new claims in the near future. The obvious approach would be= to use an IANA registry to maintain uniqueness of the labels but without using a namespace declaration concept= like XML does.

 

For some reason that does not seem to be enough t= o use IANA alone: the document introduces three types of claims, namely Res= erved Claim Names, Public Claim Names, and Private Claim Names

 

No mechanism is stated how these claims can be di= fferentiated but essentially everything is allowed. Section 2 ("Termin= ology") says that the claims that are not registered through IANA may = be Domain Names, Object Identifiers (OIDs), UUIDs, etc.

 

Later in Section 4.2 it is said that public claim= s could be a URI, which is again different to what is said in Section 2.

 

Furthermore, Private Claims (as defined in Sectio= n 4.3) do not seem to have the requirement for uniqueness anymore even thou= gh Section 4 says that claim names in a JWT have to be unique.

 

The danger is obviously that two parties define c= laim names that have different semantic. This will lead to confusion. When = claims with the same names are added to a JWT then, per specification, the = receiver will have to fail.

 

If people are follo= wing the spec and using (IANA) reserved claim names, or public claim names = (those containing a collision-resistant namespace), then the same names wil= l always have the same semantics.  IANA is used for reserved claim names, where conflicts would otherwise be likel= y.  IANA is unnecessary for public claim names, because the collision-= resistant namespace in the claim name prevents duplication.

 

Do we really need to support claims where uniquen= ess cannot be guaranteed?

 

Private claim names= are there because in some contexts, the communication is between a fixed o= r constrained set of parties between whom private agreements are a perfectl= y acceptable namespace allocation solution.  Indeed, it wouldn’t make much sense to register the meanings of clai= ms with IANA that will only be used in a closed environment.

 

Can we decide on a few namespace concepts rather = than leaving the list open-ended? What are the JOSE guys going to do about = this issue?

 

The same namespace = allocation strategy is being used by JOSE.

 

Btw, is it allowed to use JavaScript reserved key= words as claim names?

 

Yes

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Han= nes Tschofenig
Sent: Monday, November 26, 2012 3:11 AM
To: jose@ietf.org
Cc: Hannes Tschofenig
Subject: [jose] Namespace

 

Hi all,

 

I posted a review of the JWT document to the OAut= h mailing list but one specific issue is probably more relevant for JOSE th= an for OAuth.

 

The namespace concept form the JOSE header parame= ters has been copied to the "body" for the OAuth JWT spec:

 

Begin forwarded message:

 

> - Namespace

>

> The document defines a couple of claims. Qui= te naturally one wants to provide extension points since others will quite = likely come up with new claims in the near future. The obvious approach wou= ld be to use an IANA registry to maintain uniqueness of the labels but without using a namespace declaration concept= like XML does.

>

> For some reason that does not seem to be eno= ugh to use IANA alone: the document introduces three types of claims, namel= y Reserved Claim Names, Public Claim Names, and Private Claim Names

>

> No mechanism is stated how these claims can = be differentiated but essentially everything is allowed. Section 2 ("T= erminology") says that the claims that are not registered through IANA= may be Domain Names, Object Identifiers (OIDs), UUIDs, etc.

>

> Later in Section 4.2 it is said that public = claims could be a URI, which is again different to what is said in Section = 2.

>

> Furthermore, Private Claims (as defined in S= ection 4.3) do not seem to have the requirement for uniqueness anymore even= though Section 4 says that claim names in a JWT have to be unique.

>

> The danger is obviously that two parties def= ine claim names that have different semantic. This will lead to confusion. = When claims with the same names are added to a JWT then, per specification,= the receiver will have to fail.

>

> Do we really need to support claims where un= iqueness cannot be guaranteed?

> Can we decide on a few namespace concepts ra= ther than leaving the list open-ended? What are the JOSE guys going to do a= bout this issue?

>

> Btw, is it allowed to use JavaScript reserve= d keywords as claim names?

>

 

In a summary, has someone looked at the way how t= he header parameters are reserved? Does this make sense to you?<= /p>

 

Ciao

Hannes

 

 

 

_______________________________________________

jose mailing list

jose@ietf.org

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

--_000_4E1F6AAD24975D4BA5B168042967394366924E98TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Dec 14 10:18:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FC921F84F2 for ; Fri, 14 Dec 2012 10:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-1.439, BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziqpLLHEbfB6 for ; Fri, 14 Dec 2012 10:18:18 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 858FC21F8501 for ; Fri, 14 Dec 2012 10:18:18 -0800 (PST) Received: from BL2FFO11FD001.protection.gbl (10.173.161.201) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.0.578.12; Fri, 14 Dec 2012 18:18:07 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Fri, 14 Dec 2012 18:18:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 14 Dec 2012 18:17:24 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Whether implementations must understand all JOSE header fields Thread-Index: Ac3aJ0LgLoD5fCkEQZSpS5iQpRZ88Q== Date: Fri, 14 Dec 2012 18:17:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366929F63TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52604002)(51856001)(53806001)(54316002)(47736001)(16236675001)(512954001)(33656001)(15202345001)(56816002)(44976002)(47446002)(49866001)(54356001)(16406001)(31966008)(50986001)(74502001)(5343635001)(4396001)(74662001)(77982001)(5343655001)(59766001)(76482001)(46102001)(47976001)(55846006)(56776001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB016; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06952FC175 Subject: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:18:21 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366929F63TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_4E1F6AAD24975D4BA5B168042967394366929F63TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Currently the JOSE specs contain the following la= nguage declaring that all header (and some other) fields must be understood= :  “Implementations MUST understand the entire contents of the h= eader; otherwise, the … MUST be rejected.”  There's currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that al= l header fields must be understood by implementations using them.

 

PRO:  This is a simple rule designed to resu= lt in secure implementations.  Representations of existing JWS & J= WE objects are unchanged.

CON:  Extensibility is limited to cases wher= e all participating parties understand new fields that are introduced.=

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of field= s can be designated as “may be ignored if not understood”. = ; For instance, an “ign” (may be ignored) member could be defined whose value is an array listing the member names that may be safel= y ignored if not understood.  An example using this field in a JWS hea= der is:

 

    {"alg":"ES256&q= uot;,

     "ign":["n= otes"],

     "notes":"= This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT co= ntain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain the= current semantics, while allowing explicit exceptions to be made in cases = where the fields are not security-critical and the structure has a meaningful interpretation without them.  Represen= tations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names a= nd may-be-ignored list, adding some implementation complexity.

 

2B.  Take an alternative approach where inst= ead of one header object, there would be two header objects.  Implemen= tations would be required to understand all fields in the first header obje= ct.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of = this approach, adding the second header object after the first in a JWS, wo= uld be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOi= JIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dX= JlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOj= EzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r= _wW1gFWFOEjXk

 

The first, third, and fourth fields are from the = example JWS in the current spec. The new second field is the base64url enco= ded representation of the string '{"notes":"This signature n= eed not be checked when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily disti= nguishable from must-be-understood fields.

CON:  Implementations must consult/merge two= sets of headers to understand the meaning/structure of the object, adding = some implementation complexity.  Existing JWS & JWE object represe= ntations would become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be cri= tical for implementations to understand?

YES – All header fields must continue to be= understood by implementations or the input must be rejected.

NO – A means of listing that specific heade= r fields may be safely ignored should be defined.

 

SECOND POLL:  Should the result of the first= poll be "NO", which syntax would you prefer for designating the = header fields that may be ignored if not understood?

A – Define a header field that explicitly l= ists the fields that may be safely ignored if not understood.

B – Introduce a second header, where implem= entations must understand all fields in the first but they may ignore not-u= nderstood fields in the second.

 

         =             &nb= sp;            =             &nb= sp; Thanks for considering these questions,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Richard Barnes, John Bradley, Mike Jones

 

 

--_000_4E1F6AAD24975D4BA5B168042967394366929F63TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Dec 17 22:36:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6A21F8722 for ; Mon, 17 Dec 2012 22:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkLy3++5Q0iV for ; Mon, 17 Dec 2012 22:36:14 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id A6DE721F8880 for ; Mon, 17 Dec 2012 22:36:10 -0800 (PST) Received: from mail89-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Dec 2012 06:36:09 +0000 Received: from mail89-am1 (localhost [127.0.0.1]) by mail89-am1-R.bigfish.com (Postfix) with ESMTP id 4A6C81E0069 for ; Tue, 18 Dec 2012 06:36:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fh148cIzz1de0h1202h1e76h1d1ah1d2ahzz18c673h17326ah8275bh8275dh1033ILz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail89-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1 (MessageSwitch) id 1355812566469476_19220; Tue, 18 Dec 2012 06:36:06 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.244]) by mail89-am1.bigfish.com (Postfix) with ESMTP id 70B753E004B for ; Tue, 18 Dec 2012 06:36:06 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Dec 2012 06:36:06 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.249]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Tue, 18 Dec 2012 06:36:05 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3c6fKiGIpH7bZFS4icWSDz6kDFIA== Date: Tue, 18 Dec 2012 06:36:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436694758E@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436694758ETK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 06:36:17 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436694758ETK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are people interested in discussing this, or are we proceed to have the cha= irs conduct polls and make consensus calls? Thus far, no one has commented= on the note below... -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fie= lds Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_4E1F6AAD24975D4BA5B16804296739436694758ETK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are people interested = in discussing this, or are we proceed to have the chairs conduct polls and = make consensus calls?  Thus far, no one has commented on the note belo= w…

 

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

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE hea= der fields

 

Currently the JOSE specs contain the following la= nguage declaring that all header (and some other) fields must be understood= :  “Implementations MUST understand the entire contents of the h= eader; otherwise, the … MUST be rejected.”  There's currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that al= l header fields must be understood by implementations using them.

 

PRO:  This is a simple rule designed to resu= lt in secure implementations.  Representations of existing JWS & J= WE objects are unchanged.

CON:  Extensibility is limited to cases wher= e all participating parties understand new fields that are introduced.=

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of field= s can be designated as “may be ignored if not understood”. = ; For instance, an “ign” (may be ignored) member could be defined whose value is an array listing the member names that may be safel= y ignored if not understood.  An example using this field in a JWS hea= der is:

 

    {"alg":"ES256&q= uot;,

     "ign":["n= otes"],

     "notes":"= This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT co= ntain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain the= current semantics, while allowing explicit exceptions to be made in cases = where the fields are not security-critical and the structure has a meaningful interpretation without them.  Represen= tations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names a= nd may-be-ignored list, adding some implementation complexity.

 

2B.  Take an alternative approach where inst= ead of one header object, there would be two header objects.  Implemen= tations would be required to understand all fields in the first header obje= ct.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of = this approach, adding the second header object after the first in a JWS, wo= uld be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOi= JIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dX= JlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOj= EzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r= _wW1gFWFOEjXk

 

The first, third, and fourth fields are from the = example JWS in the current spec. The new second field is the base64url enco= ded representation of the string '{"notes":"This signature n= eed not be checked when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily disti= nguishable from must-be-understood fields.

CON:  Implementations must consult/merge two= sets of headers to understand the meaning/structure of the object, adding = some implementation complexity.  Existing JWS & JWE object represe= ntations would become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be cri= tical for implementations to understand?

YES – All header fields must continue to be= understood by implementations or the input must be rejected.

NO – A means of listing that specific heade= r fields may be safely ignored should be defined.

 

SECOND POLL:  Should the result of the first= poll be "NO", which syntax would you prefer for designating the = header fields that may be ignored if not understood?

A – Define a header field that explicitly l= ists the fields that may be safely ignored if not understood.

B – Introduce a second header, where implem= entations must understand all fields in the first but they may ignore not-u= nderstood fields in the second.

 

         =             &nb= sp;            =             &nb= sp; Thanks for considering these questions,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Richard Barnes, John Bradley, Mike Jones

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436694758ETK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Mon Dec 17 22:39:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD721F89E8 for ; Mon, 17 Dec 2012 22:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Bh3Oj9FyO5l for ; Mon, 17 Dec 2012 22:39:34 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9703921F889C for ; Mon, 17 Dec 2012 22:39:33 -0800 (PST) Received: from mail28-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Dec 2012 06:39:32 +0000 Received: from mail28-am1 (localhost [127.0.0.1]) by mail28-am1-R.bigfish.com (Postfix) with ESMTP id 461924A00A0 for ; Tue, 18 Dec 2012 06:39:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fh148cIzz1de0h1202h1e76h1d1ah1d2ahzz18c673h17326ah8275bh8275dh1033ILz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail28-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail28-am1 (localhost.localdomain [127.0.0.1]) by mail28-am1 (MessageSwitch) id 135581276987363_31524; Tue, 18 Dec 2012 06:39:29 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.242]) by mail28-am1.bigfish.com (Postfix) with ESMTP id 0FA5130009C for ; Tue, 18 Dec 2012 06:39:29 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Dec 2012 06:39:23 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.249]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 18 Dec 2012 06:39:20 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3c6mdsGCuuUWr8RceJQKYrHIeUIw== Date: Tue, 18 Dec 2012 06:39:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669475B2@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669475B2TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 06:39:37 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943669475B2TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [resending with corrected text] Are people interested in discussing this, or are we ready to proceed to hav= e the chairs conduct polls and make consensus calls? Thus far, no one has = commented on the note below... -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fie= lds Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_4E1F6AAD24975D4BA5B1680429673943669475B2TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[resending with correc= ted text]

 

Are people interested = in discussing this, or are we ready to proceed to have the chairs conduct p= olls and make consensus calls?  Thus far, no one has commented on the = note below…

 

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

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE hea= der fields

 

Currently the JOSE specs contain the following la= nguage declaring that all header (and some other) fields must be understood= :  “Implementations MUST understand the entire contents of the h= eader; otherwise, the … MUST be rejected.”  There's currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that al= l header fields must be understood by implementations using them.

 

PRO:  This is a simple rule designed to resu= lt in secure implementations.  Representations of existing JWS & J= WE objects are unchanged.

CON:  Extensibility is limited to cases wher= e all participating parties understand new fields that are introduced.=

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of field= s can be designated as “may be ignored if not understood”. = ; For instance, an “ign” (may be ignored) member could be defined whose value is an array listing the member names that may be safel= y ignored if not understood.  An example using this field in a JWS hea= der is:

 

    {"alg":"ES256&q= uot;,

     "ign":["n= otes"],

     "notes":"= This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT co= ntain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain the= current semantics, while allowing explicit exceptions to be made in cases = where the fields are not security-critical and the structure has a meaningful interpretation without them.  Represen= tations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names a= nd may-be-ignored list, adding some implementation complexity.

 

2B.  Take an alternative approach where inst= ead of one header object, there would be two header objects.  Implemen= tations would be required to understand all fields in the first header obje= ct.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of = this approach, adding the second header object after the first in a JWS, wo= uld be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOi= JIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dX= JlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOj= EzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r= _wW1gFWFOEjXk

 

The first, third, and fourth fields are from the = example JWS in the current spec. The new second field is the base64url enco= ded representation of the string '{"notes":"This signature n= eed not be checked when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily disti= nguishable from must-be-understood fields.

CON:  Implementations must consult/merge two= sets of headers to understand the meaning/structure of the object, adding = some implementation complexity.  Existing JWS & JWE object represe= ntations would become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be cri= tical for implementations to understand?

YES – All header fields must continue to be= understood by implementations or the input must be rejected.

NO – A means of listing that specific heade= r fields may be safely ignored should be defined.

 

SECOND POLL:  Should the result of the first= poll be "NO", which syntax would you prefer for designating the = header fields that may be ignored if not understood?

A – Define a header field that explicitly l= ists the fields that may be safely ignored if not understood.

B – Introduce a second header, where implem= entations must understand all fields in the first but they may ignore not-u= nderstood fields in the second.

 

         =             &nb= sp;            =             &nb= sp; Thanks for considering these questions,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Richard Barnes, John Bradley, Mike Jones

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943669475B2TK5EX14MBXC284r_-- From Axel.Nennker@telekom.de Tue Dec 18 00:52:53 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7736F21F87A3 for ; Tue, 18 Dec 2012 00:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl5sl69gg3Bt for ; Tue, 18 Dec 2012 00:52:50 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10421F875A for ; Tue, 18 Dec 2012 00:52:48 -0800 (PST) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 18 Dec 2012 09:52:28 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Tue, 18 Dec 2012 09:52:27 +0100 From: To: , Date: Tue, 18 Dec 2012 09:52:26 +0100 Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3c6fKiGIpH7bZFS4icWSDz6kDFIAAEWr0A Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436694758E@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436694758E@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF4025238FC2A45HE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 08:52:53 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF4025238FC2A45HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did not comment on this because I thought I needed to think about all alt= ernatives. 3) have a field "ver" denoting the version of the JWT. All headers and valu= es are defined in a version. If a recipient does not understands a version = then the JWT must be rejected, if he understands the version then all heade= r fields and values must be understood and there are no extra header fields= . 4) For each value of alg and enc there is a new optinal field with the name= of the value of alg or enc containing the parameters for this value of alg= or enc. Example: {"alg":"ES1024T", /* some new algorithm */ "ES1024T ":{"param1": "value1","param2":"value2"}; "notes":"This signature need not be checked when the moon is full" } Recipient must understand alg and its value. If there is a field like ES102= 4T then recipient must understand all fields in its value e.g. param1, valu= e1 All other header fields like notes can safely be ignored because they are n= ot relevant to alg or enc. There needs to be wording to prevent name clashes likes this alg=3D"user_jw= k" Axel From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Tuesday, December 18, 2012 7:36 AM To: jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header= fields Are people interested in discussing this, or are we proceed to have the cha= irs conduct polls and make consensus calls? Thus far, no one has commented= on the note below... -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fie= lds Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_CE8995AB5D178F44A2154F5C9A97CAF4025238FC2A45HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did not comment on this because I thought I needed to think= about all alternatives.

 

3) have a field “ver” denoting the ve= rsion of the JWT. All headers and values are defined in a version. If a rec= ipient does not understands a version then the JWT must be rejected, if he = understands the version then all header fields and values must be understoo= d and there are no extra header fields.

 

4) For each value of alg and enc= there is a new optinal field with the name of the value of alg or enc cont= aining the parameters for this value of alg or enc.

Example:

    {"alg&= quot;:"ES1024T", /* some new algorithm */

      "ES1024T ":{"param1": "value1","param2&= quot;:"value2"};

 &nbs= p;   "notes":"This signature need not be checked w= hen the moon is full"

 &nbs= p;  }

Recipient must understand alg and its value. If there is a field like ES1024T then recipient must understand all fields in its value e.g. para= m1, value1

All other header fields like = notes can safely be ignored because they are not relevant to alg or enc.

There needs to be wording to prevent name = clashes likes this alg=3D”user_jwk”

 

Axel

 

 

From: jose-bounces@ietf.org [mailto:jose= -bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, = December 18, 2012 7:36 AM
To: jose@ietf.org
Subject: Re= : [jose] Whether implementations must understand all JOSE header fields

 

Are people interested in di= scussing this, or are we proceed to have the chairs conduct polls and make = consensus calls?  Thus far, no one has commented on the note belowR= 30;

 

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

 = ;

From: jose-bounces@ietf.= org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sen= t: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE heade= r fields

 <= /o:p>

Currently the JOSE specs contain the follo= wing language declaring that all header (and some other) fields must be und= erstood:  “Implementations MUST understand the entire contents o= f the header; otherwise, the … MUST be rejected.”  There's= currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  = Maintain the current requirement that all header fields must be understood = by implementations using them.

&= nbsp;

PRO:  This is a simple rule des= igned to result in secure implementations.  Representations of existin= g JWS & JWE objects are unchanged.

CON:  Extensibility is limited to cases where all participating part= ies understand new fields that are introduced.

 

2A.  Take an al= ternative approach where, by default, all fields must be understood, but wh= ere an explicit list of fields can be designated as “may be ignored i= f not understood”.  For instance, an “ign” (may be i= gnored) member could be defined whose value is an array listing the member = names that may be safely ignored if not understood.  An example using = this field in a JWS header is:

&= nbsp;

    {"alg":= "ES256",

   =   "ign":["notes"],

     "notes":"This signature need= not be checked when the moon is full"

    }

&nbs= p;

(Obviously, the "ign" field M= UST NOT contain the value "ign".)

 

PRO:  This would e= nable adding non-critical header fields without breaking implementations.&n= bsp; It would maintain the current semantics, while allowing explicit excep= tions to be made in cases where the fields are not security-critical and th= e structure has a meaningful interpretation without them.  Representat= ions of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names and may-be= -ignored list, adding some implementation complexity.

 

2B.  Tak= e an alternative approach where instead of one header object, there would b= e two header objects.  Implementations would be required to understand= all fields in the first header object.  Implementations would be allo= wed to ignore fields in the second header object if not understood.  A= n example of this approach, adding the second header object after the first= in a JWS, would be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGc= iOiJIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMg= c2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4M= TkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

 

The first, third, and fourth fields are from the example JWS in the curren= t spec. The new second field is the base64url encoded representation of the= string '{"notes":"This signature need not be checked when t= he moon is full"}'.

 <= /o:p>

PRO:  May-be-ignored fields are easil= y distinguishable from must-be-understood fields.

CON:  Implementations must consult/merge two sets of head= ers to understand the meaning/structure of the object, adding some implemen= tation complexity.  Existing JWS & JWE object representations woul= d become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be critical f= or implementations to understand?

YES= – All header fields must continue to be understood by implementation= s or the input must be rejected.

NO &= #8211; A means of listing that specific header fields may be safely ignored= should be defined.

 =

SECOND POLL:  Should the result of the fir= st poll be "NO", which syntax would you prefer for designating th= e header fields that may be ignored if not understood?

A – Define a header field that explicitly lists the= fields that may be safely ignored if not understood.

B – Introduce a second header, where implementations= must understand all fields in the first but they may ignore not-understood= fields in the second.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Thanks for considering these questions,

         &nbs= p;            &= nbsp;           &nbs= p;             = Richard Barnes, John Bradley, Mike Jones

 

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF4025238FC2A45HE111541eme_-- From James.H.Manger@team.telstra.com Tue Dec 18 04:59:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF1F21F8842 for ; Tue, 18 Dec 2012 04:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.119 X-Spam-Level: X-Spam-Status: No, score=0.119 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8dmjsBNp3MD for ; Tue, 18 Dec 2012 04:59:31 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8321F87B3 for ; Tue, 18 Dec 2012 04:59:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,309,1355058000"; d="scan'208,217";a="108861844" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 18 Dec 2012 23:59:23 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6929"; a="102746592" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbvi.tcif.telstra.com.au with ESMTP; 18 Dec 2012 23:59:23 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Tue, 18 Dec 2012 23:59:22 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Tue, 18 Dec 2012 23:59:19 +1100 Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3aJ0LgLoD5fCkEQZSpS5iQpRZ88QC6wIZg Message-ID: <255B9BB34FB7D647A506DC292726F6E115040896F0@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115040896F0WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:59:32 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115040896F0WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgY29tbWVudHMgaW4gcmVkLg0KDQoNCg0KQ3VycmVudGx5IHRoZSBKT1NFIHNwZWNzIGNvbnRh aW4gdGhlIGZvbGxvd2luZyBsYW5ndWFnZSBkZWNsYXJpbmcgdGhhdCBhbGwgaGVhZGVyIChhbmQg c29tZSBvdGhlcikgZmllbGRzIG11c3QgYmUgdW5kZXJzdG9vZDogIOKAnEltcGxlbWVudGF0aW9u cyBNVVNUIHVuZGVyc3RhbmQgdGhlIGVudGlyZSBjb250ZW50cyBvZiB0aGUgaGVhZGVyOyBvdGhl cndpc2UsIHRoZSDigKYgTVVTVCBiZSByZWplY3RlZC7igJ0gIFRoZXJlJ3MgY3VycmVudGx5IGFu IG9wZW4gaXNzdWUgYWJvdXQgd2hldGhlciBhbGwgaGVhZGVyIGZpZWxkcyBzaG91bGQgYmUgcmVx dWlyZWQgdG8gYmUgdW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgdGhlbSBvciB3 aGV0aGVyIHRvIHJlbGF4IHRoaXMgcmVxdWlyZW1lbnQgaW4gc29tZSBjaXJjdW1zdGFuY2VzLiAg V2Ugd291bGQgbGlrZSB0aGUgd29ya2luZyBncm91cCB0byBjb25zaWRlciB0aGUgZm9sbG93aW5n IHBvdGVudGlhbCByZXNvbHV0aW9ucyB0byB0aGUgaXNzdWUuDQoNCg0KDQoxLiAgTWFpbnRhaW4g dGhlIGN1cnJlbnQgcmVxdWlyZW1lbnQgdGhhdCBhbGwgaGVhZGVyIGZpZWxkcyBtdXN0IGJlIHVu ZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRoZW0uDQoNCg0KDQpQUk86ICBUaGlz IGlzIGEgc2ltcGxlIHJ1bGXigKYNCg0KDQoNCkl0IGlzIG5vdCBhcyBzaW1wbGUgYXMgaWdub3Jp bmcgdW5rbm93biBmaWVsZHMsIHdoaWNoIGFsbCBjb2RlIHdpbGwgZG8gbmF0dXJhbGx5Lg0KDQoN Cg0KQXJlIHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGVzIHdlbGwgZGVm aW5lZD8gT2J2aW91c2x5IGlmIGEgdG90YWxseSB1bmtub3duIGZpZWxkIGlzIHByZXNlbnQgdGhl IEpPU0UgbWVzc2FnZSBtdXN0IGJlIHJlamVjdGVkLg0KDQoNCg0KSG93IGFib3V0IGlmIGEgZGVm aW5lZCBmaWVsZCBpcyBpbiBhbiB1bmV4cGVjdGVkIHBsYWNlLCBlZyDigJx6aXDigJ0gaW4gYSBK V0UgaGVhZGVyPyBQcmVzdW1hYmx5IHRoYXQgaGFzIHRvIGJlIHJlamVjdGVkIHNvIGl0IGlzIG5v dCBzdWZmaWNpZW50IGZvciBjb2RlIHRvIGNoZWNrIGFueSBKT1NFIG1lc3NhZ2VzIGFnYWluc3Qg b25lIGxpc3QuDQoNCg0KDQpIb3cgYWJvdXQgYSBKV0Ugd2l0aCBhbiDigJxlcGvigJ0gZmllbGQg d2hlbiDigJxhbGfigJ064oCdUlNBLU9BRVDigJ0/IFByZXN1bWFibHkgdGhhdCBhbHNvIGhhcyB0 byBiZSByZWplY3RlZCBzbyBjaGVja2luZyBhZ2FpbnN0IGEgc3RhdGljIGxpc3Qgb2YgSldFIGZp ZWxkcyBpcyBub3Qgc3VmZmljaWVudC4NCg0KDQoNCkRvZXMgdGhlIHR5cGUgb3IgdmFsdWUgb2Yg YSBmaWVsZCBuZWVkIHRvIGJlIGNoZWNrZWQgaWYgYW4gaW1wbGVtZW50YXRpb24gZG9lc27igJl0 IG5lZWQgdG8gdXNlIGl0PyBGb3IgZXhhbXBsZSwgZG9lcyBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0 IGFscmVhZHkgaGFzIGEgZ2l2ZW4gY2VydCAoc28gaXQgZG9lc27igJl0IG5lZWQgdG8gdXNlIGEg 4oCceDV14oCdIHZhbHVlKSBuZWVkIHRvIGNvbmZpcm0gdGhhdCB0aGUg4oCceDV14oCdIHZhbHVl IGlzIGEgc3RyaW5nLCBvciBpcyBhIHZhbGlkIFVSSSwgb3IgYWN0dWFsbHkgcmVzb2x2ZXMgdG8g dGhlIHNhbWUgY2VydD8gUHJvYmFibHkgbm90LiBJIGFzc3VtZSBpdCBpcyBzdWZmaWNpZW50IHRv IHVuZGVyc3RhbmQgdGhhdCBhIGZpZWxkIGNhbiBiZSBpZ25vcmVkLCB3aXRob3V0IGFjdHVhbGx5 IHVuZGVyc3RhbmRpbmcgaXRzIGFjdHVhbCBzeW50YXggb3IgdmFsdWUgaXMgYSBzcGVjaWZpYyBt ZXNzYWdlLg0KDQoNCg0K4oCmZGVzaWduZWQgdG8gcmVzdWx0IGluIHNlY3VyZSBpbXBsZW1lbnRh dGlvbnMuDQoNCg0KDQpTZWN1cmUgaW4gd2hhdCB3YXk/IElzIHRoaXMgYWltZWQgc3BlY2lmaWNh bGx5IGF0IHByZXZlbnRpbmcgbmV3IGZpZWxkcyBiZWluZyBpZ25vcmVkIGluIGNhc2UgdGhleSBj aGFuZ2UgdGhlIHNlbWFudGljcyBvZiBleGlzdGluZyBmaWVsZHM/DQoNCg0KDQpQUk86IE5ldyBm aWVsZHMgYXJlIGFsbG93ZWQgdG8gY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgZXhpc3RpbmcgZmll bGRzIGJlY2F1c2UgaW1wbGVtZW50YXRpb25zIG5vdCB1bmRlcnN0YW5kaW5nIHRoZSBjaGFuZ2Vk IHNlbWFudGljcyB3aWxsIGZhaWwtc2FmZSBkdWUgdG8gc2VlaW5nIGFuIHVua25vd24gZmllbGQu DQoNCihvciBpcyB0aGlzIGEgQ09OIGZvciBlbmNvdXJhZ2luZyBkYW5nZXJvdXMgZXh0ZW5zaW9u cz8pDQoNCg0KDQrigKZSZXByZXNlbnRhdGlvbnMgb2YgZXhpc3RpbmcgSldTICYgSldFIG9iamVj dHMgYXJlIHVuY2hhbmdlZC4NCg0KQ09OOiAgRXh0ZW5zaWJpbGl0eSBpcyBsaW1pdGVkIHRvIGNh c2VzIHdoZXJlIGFsbCBwYXJ0aWNpcGF0aW5nIHBhcnRpZXMgdW5kZXJzdGFuZCBuZXcgZmllbGRz IHRoYXQgYXJlIGludHJvZHVjZWQuDQoNCg0KDQpDT046IEJlY2F1c2UgY29kZSBjYW4gc3VjY2Vz c2Z1bGx5IHByb2Nlc3MgSk9TRSBtZXNzYWdlIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRoZSDigJxN VVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUgaXQgaXMgaGFyZCB0byBoYXZlIGNvbmZp ZGVuY2UgdGhhdCBpdCBpcyBpbXBsZW1lbnRlZCAob3IgaW1wbGVtZW50ZWQgd2VsbCkuDQoNCg0K DQoyQS4gIFRha2UgYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggd2hlcmUsIGJ5IGRlZmF1bHQsIGFs bCBmaWVsZHMgbXVzdCBiZSB1bmRlcnN0b29kLCBidXQgd2hlcmUgYW4gZXhwbGljaXQgbGlzdCBv ZiBmaWVsZHMgY2FuIGJlIGRlc2lnbmF0ZWQgYXMg4oCcbWF5IGJlIGlnbm9yZWQgaWYgbm90IHVu ZGVyc3Rvb2TigJ0uICBGb3IgaW5zdGFuY2UsIGFuIOKAnGlnbuKAnSAobWF5IGJlIGlnbm9yZWQp IG1lbWJlciBjb3VsZCBiZSBkZWZpbmVkIHdob3NlIHZhbHVlIGlzIGFuIGFycmF5IGxpc3Rpbmcg dGhlIG1lbWJlciBuYW1lcyB0aGF0IG1heSBiZSBzYWZlbHkgaWdub3JlZCBpZiBub3QgdW5kZXJz dG9vZC4gIEFuIGV4YW1wbGUgdXNpbmcgdGhpcyBmaWVsZCBpbiBhIEpXUyBoZWFkZXIgaXM6DQoN Cg0KDQogICAgeyJhbGciOiJFUzI1NiIsDQoNCiAgICAgImlnbiI6WyJub3RlcyJdLA0KDQogICAg ICJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9v biBpcyBmdWxsIg0KDQogICAgfQ0KDQoNCg0KKE9idmlvdXNseSwgdGhlICJpZ24iIGZpZWxkIE1V U1QgTk9UIGNvbnRhaW4gdGhlIHZhbHVlICJpZ24iLikNCg0KDQoNClBSTzogIFRoaXMgd291bGQg ZW5hYmxlIGFkZGluZyBub24tY3JpdGljYWwgaGVhZGVyIGZpZWxkcyB3aXRob3V0IGJyZWFraW5n IGltcGxlbWVudGF0aW9ucy4gIEl0IHdvdWxkIG1haW50YWluIHRoZSBjdXJyZW50IHNlbWFudGlj cywgd2hpbGUgYWxsb3dpbmcgZXhwbGljaXQgZXhjZXB0aW9ucyB0byBiZSBtYWRlIGluIGNhc2Vz IHdoZXJlIHRoZSBmaWVsZHMgYXJlIG5vdCBzZWN1cml0eS1jcml0aWNhbCBhbmQgdGhlIHN0cnVj dHVyZSBoYXMgYSBtZWFuaW5nZnVsIGludGVycHJldGF0aW9uIHdpdGhvdXQgdGhlbS4gIFJlcHJl c2VudGF0aW9ucyBvZiBleGlzdGluZyBKV1MgJiBKV0Ugb2JqZWN0cyBhcmUgdW5jaGFuZ2VkLg0K DQpDT046ICBSZXF1aXJlcyBjb29yZGluYXRpb24gb2YgZmllbGQgbmFtZXMgYW5kIG1heS1iZS1p Z25vcmVkIGxpc3QsIGFkZGluZyBzb21lIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuDQoNCg0K DQoyQi4gIFRha2UgYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggd2hlcmUgaW5zdGVhZCBvZiBvbmUg aGVhZGVyIG9iamVjdCwgdGhlcmUgd291bGQgYmUgdHdvIGhlYWRlciBvYmplY3RzLiAgSW1wbGVt ZW50YXRpb25zIHdvdWxkIGJlIHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgYWxsIGZpZWxkcyBpbiB0 aGUgZmlyc3QgaGVhZGVyIG9iamVjdC4gIEltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSBhbGxvd2Vk IHRvIGlnbm9yZSBmaWVsZHMgaW4gdGhlIHNlY29uZCBoZWFkZXIgb2JqZWN0IGlmIG5vdCB1bmRl cnN0b29kLiAgQW4gZXhhbXBsZSBvZiB0aGlzIGFwcHJvYWNoLCBhZGRpbmcgdGhlIHNlY29uZCBo ZWFkZXIgb2JqZWN0IGFmdGVyIHRoZSBmaXJzdCBpbiBhIEpXUywgd291bGQgYmU6DQoNCg0KDQog ICAgZXlKMGVYQWlPaUpLVjFRaUxBMEtJQ0poYkdjaU9pSklVekkxTmlKOQ0KDQogICAgLg0KDQog ICAgZXlKdWIzUmxjeUk2SWxSb2FYTWdjMmxuYm1GMGRYSmxJRzVsWldRZ2JtOTBJR0psSUdOb1pX TnJaV1FnZDJobGJpQjBhR1VnYlc5dmJpQnBjeUJtZFd4c0luMA0KDQogICAgLg0KDQogICAgZXlK cGMzTWlPaUpxYjJVaUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRIQTZMeTls ZUdGdGNHeGxMbU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUQ0KDQogICAgLg0KDQogICAgZEJqZnRK ZVo0Q1ZQLW1COTJLMjd1aGJVSlUxcDFyX3dXMWdGV0ZPRWpYaw0KDQoNCg0KVGhlIGZpcnN0LCB0 aGlyZCwgYW5kIGZvdXJ0aCBmaWVsZHMgYXJlIGZyb20gdGhlIGV4YW1wbGUgSldTIGluIHRoZSBj dXJyZW50IHNwZWMuIFRoZSBuZXcgc2Vjb25kIGZpZWxkIGlzIHRoZSBiYXNlNjR1cmwgZW5jb2Rl ZCByZXByZXNlbnRhdGlvbiBvZiB0aGUgc3RyaW5nICd7Im5vdGVzIjoiVGhpcyBzaWduYXR1cmUg bmVlZCBub3QgYmUgY2hlY2tlZCB3aGVuIHRoZSBtb29uIGlzIGZ1bGwifScuDQoNCg0KDQpQUk86 ICBNYXktYmUtaWdub3JlZCBmaWVsZHMgYXJlIGVhc2lseSBkaXN0aW5ndWlzaGFibGUgZnJvbSBt dXN0LWJlLXVuZGVyc3Rvb2QgZmllbGRzLg0KDQpDT046ICBJbXBsZW1lbnRhdGlvbnMgbXVzdCBj b25zdWx0L21lcmdlIHR3byBzZXRzIG9mIGhlYWRlcnMgdG8gdW5kZXJzdGFuZCB0aGUgbWVhbmlu Zy9zdHJ1Y3R1cmUgb2YgdGhlIG9iamVjdCwgYWRkaW5nIHNvbWUgaW1wbGVtZW50YXRpb24gY29t cGxleGl0eS4gIEV4aXN0aW5nIEpXUyAmIEpXRSBvYmplY3QgcmVwcmVzZW50YXRpb25zIHdvdWxk IGJlY29tZSBpbnZhbGlkLg0KDQoNCg0KMy4gSGF2ZSBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIEpPU0UgbWVzc2FnZS4gRm9yIGluc3RhbmNlIHRoZSBmaWVsZCBj b3VsZCBiZSBjYWxsZWQg4oCcIeKAnSBhbmQgZGVmaW5lZCB2YWx1ZXMgY291bGQgYmUg4oCcc2ln 4oCdLCDigJxtYWPigJ0sIOKAnGVuY+KAneKApiBmb3Igc2lnbmVkLXdpdGgtYW4tYXN5bW1ldHJp Yy1rZXksIE1BQ2VkLXdpdGgtYS1zaGFyZWQtc2VjcmV0LCBlbmNyeXB0ZWQtKEFFQUQpLXdpdGgt c2hhcmVkLXNlY3JldOKApi4gVGhlIGRlZmluaXRpb24gb2YgYSB2YWx1ZSBmb3IgdGhlIOKAnCHi gJ0gZmllbGQgaW5kaWNhdGVzIHRoZSBvdGhlciBmaWVsZHMgaXQgdXNlcy4gUmVjaXBpZW50cyBN VVNUIGlnbm9yZSBhbnkgdW5yZWNvZ25pemVkIGZpZWxkcy4gT3JpZ2luYXRvcnMgYWRkaW5nIGEg bmV3IGZpZWxkIHRoYXQgY2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIGEgbWVzc2FnZSBNVVNUIHVz ZSBhIG5ldyB2YWx1ZSBmb3IgdGhlIOKAnCHigJ0gZmllbGQuDQoNCg0KDQpQUk86IENvZGUgd2ls bCBpbXBsZW1lbnQgdGhpcyBydWxlIG5hdHVyYWxseSwgc2ltcGx5IGJ5IHN3aXRjaGluZyBvbiB0 aGUg4oCcIeKAnSBmaWVsZCB2YWx1ZS4NCg0KDQoNClBSTzogSXQgaXMgZXh0ZW5zaWJsZS4gRXh0 cmEgZmllbGRzIGNhbiBiZSBkZWZpbmVkIGFuZCBkZXBsb3llZCB3aXRob3V0IHJlcXVpcmluZyBv cmlnaW5hdG9ycyBhbmQgcmVjaXBpZW50cyB0byBiZSB1cGdyYWRlZCBzaW11bHRhbmVvdXNseS4N Cg0KDQoNCkNPTjogQXJiaXRyYXJ5IGV4dHJhIGRhdGEgb2YgYSBvcmlnaW5hdG9y4oCZcyBjaG9v c2luZyBjYW4gYmUgaW5jbHVkZWQgYXMgdW5rbm93biBmaWVsZHMgaW4gbWVzc2FnZXMgdGhhdCBy ZWNpcGllbnRzIHdpbGwgYWNjZXB0LiBUaG91Z2ggdGhpcyBpcyB0cnVlIGV2ZW4gd2l0aCBhIOKA nE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZSAoZWcgd2hpdGVzcGFjZSBpbiB0aGUg SlNPTiBoZWFkZXIsIGp1bmsgaW4gYSDigJx4NXXigJ0gVVJJIGZyYWdtZW504oCmKS4NCg0KDQoN Cg0KDQpBZnRlciBhIGRpc2N1c3Npb24gcGVyaW9kLCB3ZSBiZWxpZXZlIHRoYXQgaXQgd291bGQg YmUgdXNlZnVsIGZvciB0aGUgY2hhaXJzIHRvIG1ha2UgdHdvIGZvcm1hbCBjb25zZW5zdXMgY2Fs bHMgb2YgdGhlIGZvbGxvd2luZyBraW5kOg0KDQoNCg0KRklSU1QgUE9MTDogIFNob3VsZCBhbGwg aGVhZGVyIGZpZWxkcyBiZSBjcml0aWNhbCBmb3IgaW1wbGVtZW50YXRpb25zIHRvIHVuZGVyc3Rh bmQ/DQoNCllFUyDigJMgQWxsIGhlYWRlciBmaWVsZHMgbXVzdCBjb250aW51ZSB0byBiZSB1bmRl cnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyBvciB0aGUgaW5wdXQgbXVzdCBiZSByZWplY3RlZC4N Cg0KTk8g4oCTIEEgbWVhbnMgb2YgbGlzdGluZyB0aGF0IHNwZWNpZmljIGhlYWRlciBmaWVsZHMg bWF5IGJlIHNhZmVseSBpZ25vcmVkIHNob3VsZCBiZSBkZWZpbmVkLg0KDQoNCg0KQUxURVJOQVRJ VkUgRklSU1QgUE9MTCBGT1IgRVhJU1RJTkcgSU1QTEVNRU5UT1JTOiBIYXZlIHlvdSBpbXBsZW1l bnRlZCB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxlPyBXaGljaCBzaXR1 YXRpb25zIGRvIHlvdSByZWplY3QgKGVnIOKAnGZvb+KAnTsg4oCcemlw4oCdIGluIEpXUzsg4oCc ZXBr4oCdIHdoZW4g4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdOyDigJxqa3XigJ06PG5vbi1zdHJp bmc+OyDigJxqa3XigJ064oCdPGludmFsaWQgVVJJPuKAnTsg4oCmPw0KDQoNCg0KQUxURVJOQVRJ VkUgU0VDT05EIFBPTEw6IEhvdyByZWFsIGlzIHRoZSByaXNrIHRoYXQgZnV0dXJlIGdyb3VwcyB3 aWxsIGRlbGliZXJhdGVseSBkZXNpZ24gJiBkZXBsb3kgbmV3IGZpZWxkcyB0aGF0IGNoYW5nZSB0 aGUgc2VtYW50aWNzIG9mIEpPU0UgbWVzc2FnZXMgZGVwZW5kaW5nIG9uIHdoZXRoZXIgb3Igbm90 IHRoZSBuZXcgZmllbGQgaXMgdW5kZXJzdG9vZCwgd2l0aG91dCByZWFsaXppbmcgdGhlIHNlY3Vy aXR5IGNvbnNlcXVlbmNlcz8NCg0KDQoNCkFMVEVSTkFUSVZFIFRISVJEIFBPTEw6IElzIEpPU0Ug c28gY29tcGxldGUgYW5kIHN0YWJsZSB0aGF0IGV4dGVuc2lvbnMgYXJlIHVubGlrZWx5IHRvIGJl IG5lZWRlZD8NCg0KDQoNClNFQ09ORCBQT0xMOiAgU2hvdWxkIHRoZSByZXN1bHQgb2YgdGhlIGZp cnN0IHBvbGwgYmUgIk5PIiwgd2hpY2ggc3ludGF4IHdvdWxkIHlvdSBwcmVmZXIgZm9yIGRlc2ln bmF0aW5nIHRoZSBoZWFkZXIgZmllbGRzIHRoYXQgbWF5IGJlIGlnbm9yZWQgaWYgbm90IHVuZGVy c3Rvb2Q/DQoNCkEg4oCTIERlZmluZSBhIGhlYWRlciBmaWVsZCB0aGF0IGV4cGxpY2l0bHkgbGlz dHMgdGhlIGZpZWxkcyB0aGF0IG1heSBiZSBzYWZlbHkgaWdub3JlZCBpZiBub3QgdW5kZXJzdG9v ZC4NCg0KQiDigJMgSW50cm9kdWNlIGEgc2Vjb25kIGhlYWRlciwgd2hlcmUgaW1wbGVtZW50YXRp b25zIG11c3QgdW5kZXJzdGFuZCBhbGwgZmllbGRzIGluIHRoZSBmaXJzdCBidXQgdGhleSBtYXkg aWdub3JlIG5vdC11bmRlcnN0b29kIGZpZWxkcyBpbiB0aGUgc2Vjb25kLg0KDQoNCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzIGZvciBjb25z aWRlcmluZyB0aGVzZSBxdWVzdGlvbnMsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJpY2hhcmQgQmFybmVzLCBKb2huIEJyYWRsZXksIE1pa2UgSm9u ZXMNCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= --_000_255B9BB34FB7D647A506DC292726F6E115040896F0WSMSG3153Vsrv_ 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 YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQs IGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9 V29yZFNlY3Rpb24xPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+TXkgY29tbWVudHMgaW4gcmVkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPkN1cnJlbnRseSB0aGUgSk9TRSBzcGVj cyBjb250YWluIHRoZSBmb2xsb3dpbmcgbGFuZ3VhZ2UgZGVjbGFyaW5nIHRoYXQgYWxsIGhlYWRl ciAoYW5kIHNvbWUgb3RoZXIpIGZpZWxkcyBtdXN0IGJlIHVuZGVyc3Rvb2Q6Jm5ic3A7IOKAnElt cGxlbWVudGF0aW9ucyBNVVNUIHVuZGVyc3RhbmQgdGhlIGVudGlyZSBjb250ZW50cyBvZiB0aGUg aGVhZGVyOyBvdGhlcndpc2UsIHRoZSDigKYgTVVTVCBiZSByZWplY3RlZC7igJ0mbmJzcDsgVGhl cmUncyBjdXJyZW50bHkgYW4gb3BlbiBpc3N1ZSBhYm91dCB3aGV0aGVyIGFsbCBoZWFkZXIgZmll bGRzIHNob3VsZCBiZSByZXF1aXJlZCB0byBiZSB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9u cyB1c2luZyB0aGVtIG9yIHdoZXRoZXIgdG8gcmVsYXggdGhpcyByZXF1aXJlbWVudCBpbiBzb21l IGNpcmN1bXN0YW5jZXMuJm5ic3A7IFdlIHdvdWxkIGxpa2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8g Y29uc2lkZXIgdGhlIGZvbGxvd2luZyBwb3RlbnRpYWwgcmVzb2x1dGlvbnMgdG8gdGhlIGlzc3Vl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVM+MS4mbmJzcDsgTWFpbnRhaW4gdGhlIGN1cnJlbnQgcmVxdWlyZW1lbnQg dGhhdCBhbGwgaGVhZGVyIGZpZWxkcyBtdXN0IGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRp b25zIHVzaW5nIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5QUk86Jm5ic3A7IFRoaXMgaXMgYSBzaW1wbGUg cnVsZTxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+SXQgaXMgbm90IGFzIHNpbXBs ZSBhcyBpZ25vcmluZyB1bmtub3duIGZpZWxkcywgd2hpY2ggYWxsIGNvZGUgd2lsbCBkbyBuYXR1 cmFsbHkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz5B cmUgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZXMgd2VsbCBkZWZpbmVk PyBPYnZpb3VzbHkgaWYgYSB0b3RhbGx5IHVua25vd24gZmllbGQgaXMgcHJlc2VudCB0aGUgSk9T RSBtZXNzYWdlIG11c3QgYmUgcmVqZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6cmVkJz5Ib3cgYWJvdXQgaWYgYSBkZWZpbmVkIGZpZWxkIGlzIGluIGFu IHVuZXhwZWN0ZWQgcGxhY2UsIGVnIOKAnHppcOKAnSBpbiBhIEpXRSBoZWFkZXI/IFByZXN1bWFi bHkgdGhhdCBoYXMgdG8gYmUgcmVqZWN0ZWQgc28gaXQgaXMgbm90IHN1ZmZpY2llbnQgZm9yIGNv ZGUgdG8gY2hlY2sgYW55IEpPU0UgbWVzc2FnZXMgYWdhaW5zdCBvbmUgbGlzdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2NvbG9yOnJlZCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPkhvdyBhYm91dCBhIEpXRSB3 aXRoIGFuIOKAnGVwa+KAnSBmaWVsZCB3aGVuIOKAnGFsZ+KAnTrigJ1SU0EtT0FFUOKAnT8gUHJl c3VtYWJseSB0aGF0IGFsc28gaGFzIHRvIGJlIHJlamVjdGVkIHNvIGNoZWNraW5nIGFnYWluc3Qg YSBzdGF0aWMgbGlzdCBvZiBKV0UgZmllbGRzIGlzIG5vdCBzdWZmaWNpZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Y29sb3I6cmVkJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+RG9lcyB0aGUgdHlwZSBvciB2 YWx1ZSBvZiBhIGZpZWxkIG5lZWQgdG8gYmUgY2hlY2tlZCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBk b2VzbuKAmXQgbmVlZCB0byB1c2UgaXQ/IEZvciBleGFtcGxlLCBkb2VzIGFuIGltcGxlbWVudGF0 aW9uIHRoYXQgYWxyZWFkeSBoYXMgYSBnaXZlbiBjZXJ0IChzbyBpdCBkb2VzbuKAmXQgbmVlZCB0 byB1c2UgYSDigJx4NXXigJ0gdmFsdWUpIG5lZWQgdG8gY29uZmlybSB0aGF0IHRoZSDigJx4NXXi gJ0gdmFsdWUgaXMgYSBzdHJpbmcsIG9yIGlzIGEgdmFsaWQgVVJJLCBvciBhY3R1YWxseSByZXNv bHZlcyB0byB0aGUgc2FtZSBjZXJ0PyBQcm9iYWJseSBub3QuIEkgYXNzdW1lIGl0IGlzIHN1ZmZp Y2llbnQgdG8gdW5kZXJzdGFuZCB0aGF0IGEgZmllbGQgY2FuIGJlIGlnbm9yZWQsIHdpdGhvdXQg YWN0dWFsbHkgdW5kZXJzdGFuZGluZyBpdHMgYWN0dWFsIHN5bnRheCBvciB2YWx1ZSBpcyBhIHNw ZWNpZmljIG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPuKApjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPmRlc2lnbmVkIHRvIHJl c3VsdCBpbiBzZWN1cmUgaW1wbGVtZW50YXRpb25zLjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9y OnJlZCc+U2VjdXJlIGluIHdoYXQgd2F5PyBJcyB0aGlzIGFpbWVkIHNwZWNpZmljYWxseSBhdCBw cmV2ZW50aW5nIG5ldyBmaWVsZHMgYmVpbmcgaWdub3JlZCBpbiBjYXNlIHRoZXkgY2hhbmdlIHRo ZSBzZW1hbnRpY3Mgb2YgZXhpc3RpbmcgZmllbGRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPlBSTzogTmV3IGZpZWxkcyBhcmUgYWxsb3dlZCB0 byBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBleGlzdGluZyBmaWVsZHMgYmVjYXVzZSBpbXBsZW1l bnRhdGlvbnMgbm90IHVuZGVyc3RhbmRpbmcgdGhlIGNoYW5nZWQgc2VtYW50aWNzIHdpbGwgZmFp bC1zYWZlIGR1ZSB0byBzZWVpbmcgYW4gdW5rbm93biBmaWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJl ZCc+KG9yIGlzIHRoaXMgYSBDT04gZm9yIGVuY291cmFnaW5nIGRhbmdlcm91cyBleHRlbnNpb25z Pyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+4oCmPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+UmVwcmVzZW50YXRpb25zIG9mIGV4aXN0aW5n IEpXUyAmYW1wOyBKV0Ugb2JqZWN0cyBhcmUgdW5jaGFuZ2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5DT046Jm5ic3A7IEV4dGVu c2liaWxpdHkgaXMgbGltaXRlZCB0byBjYXNlcyB3aGVyZSBhbGwgcGFydGljaXBhdGluZyBwYXJ0 aWVzIHVuZGVyc3RhbmQgbmV3IGZpZWxkcyB0aGF0IGFyZSBpbnRyb2R1Y2VkLjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6cmVkJz5DT046IEJlY2F1c2UgY29kZSBjYW4gc3VjY2Vzc2Z1bGx5IHByb2Nl c3MgSk9TRSBtZXNzYWdlIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRoZSDigJxNVVNUIHVuZGVyc3Rh bmQgb3IgcmVqZWN04oCdIHJ1bGUgaXQgaXMgaGFyZCB0byBoYXZlIGNvbmZpZGVuY2UgdGhhdCBp dCBpcyBpbXBsZW1lbnRlZCAob3IgaW1wbGVtZW50ZWQgd2VsbCkuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVM+MkEuJm5ic3A7IFRha2UgYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2gg d2hlcmUsIGJ5IGRlZmF1bHQsIGFsbCBmaWVsZHMgbXVzdCBiZSB1bmRlcnN0b29kLCBidXQgd2hl cmUgYW4gZXhwbGljaXQgbGlzdCBvZiBmaWVsZHMgY2FuIGJlIGRlc2lnbmF0ZWQgYXMg4oCcbWF5 IGJlIGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2TigJ0uJm5ic3A7IEZvciBpbnN0YW5jZSwgYW4g 4oCcaWdu4oCdIChtYXkgYmUgaWdub3JlZCkgbWVtYmVyIGNvdWxkIGJlIGRlZmluZWQgd2hvc2Ug dmFsdWUgaXMgYW4gYXJyYXkgbGlzdGluZyB0aGUgbWVtYmVyIG5hbWVzIHRoYXQgbWF5IGJlIHNh ZmVseSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29kLiZuYnNwOyBBbiBleGFtcGxlIHVzaW5nIHRo aXMgZmllbGQgaW4gYSBKV1MgaGVhZGVyIGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7Jm5i c3A7IHsmcXVvdDthbGcmcXVvdDs6JnF1b3Q7RVMyNTYmcXVvdDssPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDtpZ24mcXVvdDs6WyZxdW90O25vdGVzJnF1b3Q7XSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25vdGVzJnF1b3Q7OiZxdW90O1RoaXMgc2lnbmF0dXJl IG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPiZuYnNw OyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4oT2J2aW91c2x5LCB0aGUgJnF1b3Q7aWduJnF1 b3Q7IGZpZWxkIE1VU1QgTk9UIGNvbnRhaW4gdGhlIHZhbHVlICZxdW90O2lnbiZxdW90Oy4pPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUz5QUk86Jm5ic3A7IFRoaXMgd291bGQgZW5hYmxlIGFkZGluZyBub24tY3JpdGlj YWwgaGVhZGVyIGZpZWxkcyB3aXRob3V0IGJyZWFraW5nIGltcGxlbWVudGF0aW9ucy4mbmJzcDsg SXQgd291bGQgbWFpbnRhaW4gdGhlIGN1cnJlbnQgc2VtYW50aWNzLCB3aGlsZSBhbGxvd2luZyBl eHBsaWNpdCBleGNlcHRpb25zIHRvIGJlIG1hZGUgaW4gY2FzZXMgd2hlcmUgdGhlIGZpZWxkcyBh cmUgbm90IHNlY3VyaXR5LWNyaXRpY2FsIGFuZCB0aGUgc3RydWN0dXJlIGhhcyBhIG1lYW5pbmdm dWwgaW50ZXJwcmV0YXRpb24gd2l0aG91dCB0aGVtLiZuYnNwOyBSZXByZXNlbnRhdGlvbnMgb2Yg ZXhpc3RpbmcgSldTICZhbXA7IEpXRSBvYmplY3RzIGFyZSB1bmNoYW5nZWQuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPkNPTjombmJz cDsgUmVxdWlyZXMgY29vcmRpbmF0aW9uIG9mIGZpZWxkIG5hbWVzIGFuZCBtYXktYmUtaWdub3Jl ZCBsaXN0LCBhZGRpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVM+MkIuJm5ic3A7IFRha2UgYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggd2hlcmUgaW5zdGVhZCBv ZiBvbmUgaGVhZGVyIG9iamVjdCwgdGhlcmUgd291bGQgYmUgdHdvIGhlYWRlciBvYmplY3RzLiZu YnNwOyBJbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgcmVxdWlyZWQgdG8gdW5kZXJzdGFuZCBhbGwg ZmllbGRzIGluIHRoZSBmaXJzdCBoZWFkZXIgb2JqZWN0LiZuYnNwOyBJbXBsZW1lbnRhdGlvbnMg d291bGQgYmUgYWxsb3dlZCB0byBpZ25vcmUgZmllbGRzIGluIHRoZSBzZWNvbmQgaGVhZGVyIG9i amVjdCBpZiBub3QgdW5kZXJzdG9vZC4mbmJzcDsgQW4gZXhhbXBsZSBvZiB0aGlzIGFwcHJvYWNo LCBhZGRpbmcgdGhlIHNlY29uZCBoZWFkZXIgb2JqZWN0IGFmdGVyIHRoZSBmaXJzdCBpbiBhIEpX Uywgd291bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgZXlKMGVYQWlPaUpL VjFRaUxBMEtJQ0poYkdjaU9pSklVekkxTmlKOTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4m bmJzcDsmbmJzcDsmbmJzcDsgZXlKdWIzUmxjeUk2SWxSb2FYTWdjMmxuYm1GMGRYSmxJRzVsWldR Z2JtOTBJR0psSUdOb1pXTnJaV1FnZDJobGJpQjBhR1VnYlc5dmJpQnBjeUJtZFd4c0luMDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4m bmJzcDsmbmJzcDsmbmJzcDsgLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgZXlKcGMzTWlPaUpxYjJV aUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxMbU52 YlM5cGMxOXliMjkwSWpwMGNuVmxmUTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsm bmJzcDsmbmJzcDsgZEJqZnRKZVo0Q1ZQLW1COTJLMjd1aGJVSlUxcDFyX3dXMWdGV0ZPRWpYazxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVM+VGhlIGZpcnN0LCB0aGlyZCwgYW5kIGZvdXJ0aCBmaWVsZHMgYXJlIGZyb20g dGhlIGV4YW1wbGUgSldTIGluIHRoZSBjdXJyZW50IHNwZWMuIFRoZSBuZXcgc2Vjb25kIGZpZWxk IGlzIHRoZSBiYXNlNjR1cmwgZW5jb2RlZCByZXByZXNlbnRhdGlvbiBvZiB0aGUgc3RyaW5nICd7 JnF1b3Q7bm90ZXMmcXVvdDs6JnF1b3Q7VGhpcyBzaWduYXR1cmUgbmVlZCBub3QgYmUgY2hlY2tl ZCB3aGVuIHRoZSBtb29uIGlzIGZ1bGwmcXVvdDt9Jy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPlBSTzombmJzcDsg TWF5LWJlLWlnbm9yZWQgZmllbGRzIGFyZSBlYXNpbHkgZGlzdGluZ3Vpc2hhYmxlIGZyb20gbXVz dC1iZS11bmRlcnN0b29kIGZpZWxkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+Q09OOiZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgbXVz dCBjb25zdWx0L21lcmdlIHR3byBzZXRzIG9mIGhlYWRlcnMgdG8gdW5kZXJzdGFuZCB0aGUgbWVh bmluZy9zdHJ1Y3R1cmUgb2YgdGhlIG9iamVjdCwgYWRkaW5nIHNvbWUgaW1wbGVtZW50YXRpb24g Y29tcGxleGl0eS4mbmJzcDsgRXhpc3RpbmcgSldTICZhbXA7IEpXRSBvYmplY3QgcmVwcmVzZW50 YXRpb25zIHdvdWxkIGJlY29tZSBpbnZhbGlkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjMuIEhhdmUgYSBmaWVsZCB0aGF0IGluZGljYXRlcyB0 aGUgc2VtYW50aWNzIG9mIHRoZSBKT1NFIG1lc3NhZ2UuIEZvciBpbnN0YW5jZSB0aGUgZmllbGQg Y291bGQgYmUgY2FsbGVkIOKAnCHigJ0gYW5kIGRlZmluZWQgdmFsdWVzIGNvdWxkIGJlIOKAnHNp Z+KAnSwg4oCcbWFj4oCdLCDigJxlbmPigJ3igKYgZm9yIHNpZ25lZC13aXRoLWFuLWFzeW1tZXRy aWMta2V5LCBNQUNlZC13aXRoLWEtc2hhcmVkLXNlY3JldCwgZW5jcnlwdGVkLShBRUFEKS13aXRo LXNoYXJlZC1zZWNyZXTigKYuIFRoZSBkZWZpbml0aW9uIG9mIGEgdmFsdWUgZm9yIHRoZSDigJwh 4oCdIGZpZWxkIGluZGljYXRlcyB0aGUgb3RoZXIgZmllbGRzIGl0IHVzZXMuIFJlY2lwaWVudHMg TVVTVCBpZ25vcmUgYW55IHVucmVjb2duaXplZCBmaWVsZHMuIE9yaWdpbmF0b3JzIGFkZGluZyBh IG5ldyBmaWVsZCB0aGF0IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiBhIG1lc3NhZ2UgTVVTVCB1 c2UgYSBuZXcgdmFsdWUgZm9yIHRoZSDigJwh4oCdIGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVk Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+UFJPOiBDb2RlIHdpbGwgaW1wbGVtZW50IHRo aXMgcnVsZSBuYXR1cmFsbHksIHNpbXBseSBieSBzd2l0Y2hpbmcgb24gdGhlIOKAnCHigJ0gZmll bGQgdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVk Jz5QUk86IEl0IGlzIGV4dGVuc2libGUuIEV4dHJhIGZpZWxkcyBjYW4gYmUgZGVmaW5lZCBhbmQg ZGVwbG95ZWQgd2l0aG91dCByZXF1aXJpbmcgb3JpZ2luYXRvcnMgYW5kIHJlY2lwaWVudHMgdG8g YmUgdXBncmFkZWQgc2ltdWx0YW5lb3VzbHkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6cmVkJz5DT046IEFyYml0cmFyeSBleHRyYSBkYXRhIG9mIGEgb3JpZ2lu YXRvcuKAmXMgY2hvb3NpbmcgY2FuIGJlIGluY2x1ZGVkIGFzIHVua25vd24gZmllbGRzIGluIG1l c3NhZ2VzIHRoYXQgcmVjaXBpZW50cyB3aWxsIGFjY2VwdC4gVGhvdWdoIHRoaXMgaXMgdHJ1ZSBl dmVuIHdpdGggYSDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUgKGVnIHdoaXRl c3BhY2UgaW4gdGhlIEpTT04gaGVhZGVyLCBqdW5rIGluIGEg4oCceDV14oCdIFVSSSBmcmFnbWVu dOKApikuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz5BZnRlciBhIGRpc2N1c3Npb24gcGVyaW9kLCB3ZSBiZWxpZXZlIHRo YXQgaXQgd291bGQgYmUgdXNlZnVsIGZvciB0aGUgY2hhaXJzIHRvIG1ha2UgdHdvIGZvcm1hbCBj b25zZW5zdXMgY2FsbHMgb2YgdGhlIGZvbGxvd2luZyBraW5kOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+RklSU1Qg UE9MTDombmJzcDsgU2hvdWxkIGFsbCBoZWFkZXIgZmllbGRzIGJlIGNyaXRpY2FsIGZvciBpbXBs ZW1lbnRhdGlvbnMgdG8gdW5kZXJzdGFuZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+WUVTIOKAkyBBbGwgaGVhZGVyIGZpZWxkcyBt dXN0IGNvbnRpbnVlIHRvIGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIG9yIHRoZSBp bnB1dCBtdXN0IGJlIHJlamVjdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5OTyDigJMgQSBtZWFucyBvZiBsaXN0aW5nIHRoYXQg c3BlY2lmaWMgaGVhZGVyIGZpZWxkcyBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgc2hvdWxkIGJlIGRl ZmluZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJl ZCc+QUxURVJOQVRJVkUgRklSU1QgUE9MTCBGT1IgRVhJU1RJTkcgSU1QTEVNRU5UT1JTOiBIYXZl IHlvdSBpbXBsZW1lbnRlZCB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxl PyBXaGljaCBzaXR1YXRpb25zIGRvIHlvdSByZWplY3QgKGVnIOKAnGZvb+KAnTsg4oCcemlw4oCd IGluIEpXUzsg4oCcZXBr4oCdIHdoZW4g4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdOyDigJxqa3Xi gJ06Jmx0O25vbi1zdHJpbmcmZ3Q7OyDigJxqa3XigJ064oCdJmx0O2ludmFsaWQgVVJJJmd0O+KA nTsg4oCmPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpy ZWQnPkFMVEVSTkFUSVZFIFNFQ09ORCBQT0xMOiBIb3cgcmVhbCBpcyB0aGUgcmlzayB0aGF0IGZ1 dHVyZSBncm91cHMgd2lsbCBkZWxpYmVyYXRlbHkgZGVzaWduICZhbXA7IGRlcGxveSBuZXcgZmll bGRzIHRoYXQgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgSk9TRSBtZXNzYWdlcyBkZXBlbmRpbmcg b24gd2hldGhlciBvciBub3QgdGhlIG5ldyBmaWVsZCBpcyB1bmRlcnN0b29kLCB3aXRob3V0IHJl YWxpemluZyB0aGUgc2VjdXJpdHkgY29uc2VxdWVuY2VzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPkFMVEVSTkFUSVZFIFRISVJEIFBPTEw6IElz IEpPU0Ugc28gY29tcGxldGUgYW5kIHN0YWJsZSB0aGF0IGV4dGVuc2lvbnMgYXJlIHVubGlrZWx5 IHRvIGJlIG5lZWRlZD88L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+U0VDT05EIFBPTEw6Jm5ic3A7 IFNob3VsZCB0aGUgcmVzdWx0IG9mIHRoZSBmaXJzdCBwb2xsIGJlICZxdW90O05PJnF1b3Q7LCB3 aGljaCBzeW50YXggd291bGQgeW91IHByZWZlciBmb3IgZGVzaWduYXRpbmcgdGhlIGhlYWRlciBm aWVsZHMgdGhhdCBtYXkgYmUgaWdub3JlZCBpZiBub3QgdW5kZXJzdG9vZD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+QSDigJMgRGVm aW5lIGEgaGVhZGVyIGZpZWxkIHRoYXQgZXhwbGljaXRseSBsaXN0cyB0aGUgZmllbGRzIHRoYXQg bWF5IGJlIHNhZmVseSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29kLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5CIOKAkyBJbnRyb2R1 Y2UgYSBzZWNvbmQgaGVhZGVyLCB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5k IGFsbCBmaWVsZHMgaW4gdGhlIGZpcnN0IGJ1dCB0aGV5IG1heSBpZ25vcmUgbm90LXVuZGVyc3Rv b2QgZmllbGRzIGluIHRoZSBzZWNvbmQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhhbmtzIGZvciBjb25zaWRlcmlu ZyB0aGVzZSBxdWVzdGlvbnMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBSaWNoYXJkIEJhcm5lcywgSm9obiBCcmFkbGV5LCBNaWtlIEpv bmVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz5KYW1l cyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E115040896F0WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Tue Dec 18 13:47:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECF821F87C7 for ; Tue, 18 Dec 2012 13:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX4HHRcy2GQ8 for ; Tue, 18 Dec 2012 13:47:26 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1240821F87AC for ; Tue, 18 Dec 2012 13:47:25 -0800 (PST) Received: from mail16-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Dec 2012 21:47:25 +0000 Received: from mail16-tx2 (localhost [127.0.0.1]) by mail16-tx2-R.bigfish.com (Postfix) with ESMTP id 04193380160; Tue, 18 Dec 2012 21:47:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fhd772h148cIzz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail16-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail16-tx2 (localhost.localdomain [127.0.0.1]) by mail16-tx2 (MessageSwitch) id 1355867241406521_31732; Tue, 18 Dec 2012 21:47:21 +0000 (UTC) Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.238]) by mail16-tx2.bigfish.com (Postfix) with ESMTP id 544668006D; Tue, 18 Dec 2012 21:47:21 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Dec 2012 21:47:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 18 Dec 2012 21:47:20 +0000 From: Mike Jones To: "Axel.Nennker@telekom.de" , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3c6fKiGIpH7bZFS4icWSDz6kDFIAAEWr0AABe5RWA= Date: Tue, 18 Dec 2012 21:47:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436696753E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436694758E@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436696753ETK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 21:47:30 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436696753ETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your note, Axel. A few comments... I want to challenge the premise of your statement "All headers and values a= re defined in a version". In fact, future headers and values can be define= d by multiple specifications in parallel through use of the IANA registries= defined by the JOSE specifications. For instance, it was decided in an ad= -hoc meeting on Friday in Atlanta that Matt Miller would write an "applicat= ion" specification that specifies mechanisms for encrypting private and sym= metric keys as JWEs *and* adds a new algorithm for password-based encryptio= n to the registry. In parallel, others wanting definitions for additional = algorithms (using SHA-3 family, for instance) might also specify those. Wh= en parallel changes are both possible and likely, versioning-based solution= s tend to break down. Also, I want to push back on your statement "All other header fields ... ca= n be safely ignored because they are not relevant to alg or enc", based upo= n past input from the working group. When we discussed this issue in the p= ast, only one person was in favor of a must-ignore-by-default behavior, and= yet that's what you're advocating for fields "not relevant to alg or enc".= See http://www.ietf.org/mail-archive/web/jose/current/msg01216.html. The= refore, I don't think that's going to fly with the working group. If you w= ant to propose a different syntax that requires people to take special acti= on to ignore a not-understood field, that would be fine, but I suspect that= one that requires special action to mark fields as must-be-understood isn'= t likely to fly. Best wishes= , -- Mike From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] Sent: Tuesday, December 18, 2012 12:52 AM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header= fields I did not comment on this because I thought I needed to think about all alt= ernatives. 3) have a field "ver" denoting the version of the JWT. All headers and valu= es are defined in a version. If a recipient does not understands a version = then the JWT must be rejected, if he understands the version then all heade= r fields and values must be understood and there are no extra header fields= . 4) For each value of alg and enc there is a new optinal field with the name= of the value of alg or enc containing the parameters for this value of alg= or enc. Example: {"alg":"ES1024T", /* some new algorithm */ "ES1024T ":{"param1": "value1","param2":"value2"}; "notes":"This signature need not be checked when the moon is full" } Recipient must understand alg and its value. If there is a field like ES102= 4T then recipient must understand all fields in its value e.g. param1, valu= e1 All other header fields like notes can safely be ignored because they are n= ot relevant to alg or enc. There needs to be wording to prevent name clashes likes this alg=3D"user_jw= k" Axel From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, December 18, 2012 7:36 AM To: jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header= fields Are people interested in discussing this, or are we proceed to have the cha= irs conduct polls and make consensus calls? Thus far, no one has commented= on the note below... -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fie= lds Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_4E1F6AAD24975D4BA5B16804296739436696753ETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your note, = Axel.  A few comments…

 

I want to challenge th= e premise of your statement “All headers and values are defined in a = version”.  In fact, future headers and values can be defined by = multiple specifications in parallel through use of the IANA registries defined by the JOSE specifications.  For instance, it= was decided in an ad-hoc meeting on Friday in Atlanta that Matt Miller wou= ld write an “application” specification that specifies mechanis= ms for encrypting private and symmetric keys as JWEs *and* adds a new algorithm for password-based encryption to the reg= istry.  In parallel, others wanting definitions for additional algorit= hms (using SHA-3 family, for instance) might also specify those.  When= parallel changes are both possible and likely, versioning-based solutions tend to break down.

 

Also, I want to push b= ack on your statement “All other header fields … can be safely = ignored because they are not relevant to alg or enc”, based upon past= input from the working group.  When we discussed this issue in the past, only one person was in favor of a must-ignore-by-defaul= t behavior, and yet that’s what you’re advocating for fields &#= 8220;not relevant to alg or enc”.  See http://www.ietf.org/mail-archive/web/jose/current/msg01216.html. = Therefore, I don’t think that’s going to fly with the working = group.  If you want to propose a different syntax that requires people to take special action to ignore a not-understood field, t= hat would be fine, but I suspect that one that requires special action to m= ark fields as must-be-understood isn’t likely to fly.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Best wishes,<= /o:p>

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

 

From: Axel.Nen= nker@telekom.de [mailto:Axel.Nennker@telekom.de]
Sent: Tuesday, December 18, 2012 12:52 AM
To: Mike Jones; jose@ietf.org
Subject: RE: [jose] Whether implementations must understand all JOSE= header fields

 

I did not comment on t= his because I thought I needed to think about all alternatives.<= /span>

 

3) have a field “= ;ver” denoting the version of the JWT. All headers and values are def= ined in a version. If a recipient does not understands a version then the J= WT must be rejected, if he understands the version then all header fields and values must be understood and there are no extr= a header fields.

 

4) For each value of a= lg and enc there is a new optinal field with the name of the value of alg o= r enc containing the parameters for this value of alg or enc.

Example:

    {"alg&q= uot;:"ES1024T", /* some new algorithm */

      = "ES1024T ":{"param1": "value1","p= aram2":"value2"};

     "notes":"= This signature need not be checked when the moon is full"

    }

Recipient must underst= and alg and its value. If there is a field like ES1024T then recipient must understand all fields in its value e.g. = param1, value1

All other header fields like notes can safely be ign= ored because they are not relevant to alg or enc.

There needs to be wording to prevent name clashes li= kes this alg=3D”user_jwk”

 

Axel=

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, December 18, 2012 7:36 AM
To: jose@ietf.org
Subject: Re: [jose] Whether implementations must understand all JOSE= header fields

 

Are people interested = in discussing this, or are we proceed to have the chairs conduct polls and = make consensus calls?  Thus far, no one has commented on the note belo= w…

 

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

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE hea= der fields

 

Currently the JOSE specs contain the following la= nguage declaring that all header (and some other) fields must be understood= :  “Implementations MUST understand the entire contents of the h= eader; otherwise, the … MUST be rejected.”  There's currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that al= l header fields must be understood by implementations using them.

 

PRO:  This is a simple rule designed to resu= lt in secure implementations.  Representations of existing JWS & J= WE objects are unchanged.

CON:  Extensibility is limited to cases wher= e all participating parties understand new fields that are introduced.=

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of field= s can be designated as “may be ignored if not understood”. = ; For instance, an “ign” (may be ignored) member could be defined whose value is an array listing the member names that may be safel= y ignored if not understood.  An example using this field in a JWS hea= der is:

 

    {"alg":"ES256&q= uot;,

     "ign":["n= otes"],

     "notes":"= This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT co= ntain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain the= current semantics, while allowing explicit exceptions to be made in cases = where the fields are not security-critical and the structure has a meaningful interpretation without them.  Represen= tations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names a= nd may-be-ignored list, adding some implementation complexity.

 

2B.  Take an alternative approach where inst= ead of one header object, there would be two header objects.  Implemen= tations would be required to understand all fields in the first header obje= ct.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of = this approach, adding the second header object after the first in a JWS, wo= uld be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOi= JIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dX= JlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOj= EzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r= _wW1gFWFOEjXk

 

The first, third, and fourth fields are from the = example JWS in the current spec. The new second field is the base64url enco= ded representation of the string '{"notes":"This signature n= eed not be checked when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily disti= nguishable from must-be-understood fields.

CON:  Implementations must consult/merge two= sets of headers to understand the meaning/structure of the object, adding = some implementation complexity.  Existing JWS & JWE object represe= ntations would become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be cri= tical for implementations to understand?

YES – All header fields must continue to be= understood by implementations or the input must be rejected.

NO – A means of listing that specific heade= r fields may be safely ignored should be defined.

 

SECOND POLL:  Should the result of the first= poll be "NO", which syntax would you prefer for designating the = header fields that may be ignored if not understood?

A – Define a header field that explicitly l= ists the fields that may be safely ignored if not understood.

B – Introduce a second header, where implem= entations must understand all fields in the first but they may ignore not-u= nderstood fields in the second.

 

         =             &nb= sp;            =             &nb= sp; Thanks for considering these questions,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Richard Barnes, John Bradley, Mike Jones

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436696753ETK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Dec 18 14:03:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32D421F8555 for ; Tue, 18 Dec 2012 14:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISt4AlIKq4Et for ; Tue, 18 Dec 2012 14:03:49 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFDC21F84D8 for ; Tue, 18 Dec 2012 14:03:49 -0800 (PST) Received: from mail37-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Dec 2012 22:03:48 +0000 Received: from mail37-ch1 (localhost [127.0.0.1]) by mail37-ch1-R.bigfish.com (Postfix) with ESMTP id 508923E017B; Tue, 18 Dec 2012 22:03:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic89bh148cIc857hzz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail37-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1 (MessageSwitch) id 1355868225719958_21128; Tue, 18 Dec 2012 22:03:45 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail37-ch1.bigfish.com (Postfix) with ESMTP id ACE592005E; Tue, 18 Dec 2012 22:03:45 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Dec 2012 22:03:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 18 Dec 2012 22:03:45 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54Q== Date: Tue, 18 Dec 2012 22:03:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366968592TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:03:51 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366968592TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClBlciB0aGUgcmVzcG9uc2UgSSBqdXN0IHNlbnQgdG8gQXhlbCwgd2hlbiB3 ZSBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBpbiB0aGUgcGFzdCwgb25seSBvbmUgcGVyc29uIHdhcyBp biBmYXZvciBvZiBhIG11c3QtaWdub3JlLWJ5LWRlZmF1bHQgYmVoYXZpb3IsIGFuZCB5ZXQgdGhh dOKAmXMgd2hhdCB5b3XigJlyZSBhZHZvY2F0aW5nIGJlbG93LiAgU2VlIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDEyMTYuaHRtbC4gIE9mIGNv dXJzZSwgaXTigJlzIGFsd2F5cyBwb3NzaWJsZSB5b3UgY291bGQgY2hhbmdlIG1pbmRzLCBidXQg SSBzdXNwZWN0IHRoYXQgaWYgeW91IHdhbnQgdG8gaW5mbHVlbmNlIHRoZSBvdXRjb21lIG9mIHRo aXMgaXNzdWUsIHRoZSBoaWdoZXN0LXBheW9mZiBzdHJhdGVneSB3b3VsZCBiZSB0byBkaXNjdXNz IHN5bnRheCBvcHRpb25zIHRoYXQgcmVxdWlyZSBwZW9wbGUgdG8gdGFrZSBzcGVjaWFsIGFjdGlv biB0byBpZ25vcmUgYSBub3QtdW5kZXJzdG9vZCBmaWVsZCwgcmF0aGVyIHRoYW4gdGhlIG90aGVy IHdheSBhcm91bmQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNeSB0d28gY2VudHMgd29ydGjigKYNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0u dGVsc3RyYS5jb21dDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxOCwgMjAxMiA0OjU5IEFNDQpU bzogTWlrZSBKb25lczsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtqb3NlXSBXaGV0aGVy IGltcGxlbWVudGF0aW9ucyBtdXN0IHVuZGVyc3RhbmQgYWxsIEpPU0UgaGVhZGVyIGZpZWxkcw0K DQoNCk15IGNvbW1lbnRzIGluIHJlZC4NCg0KDQoNCkN1cnJlbnRseSB0aGUgSk9TRSBzcGVjcyBj b250YWluIHRoZSBmb2xsb3dpbmcgbGFuZ3VhZ2UgZGVjbGFyaW5nIHRoYXQgYWxsIGhlYWRlciAo YW5kIHNvbWUgb3RoZXIpIGZpZWxkcyBtdXN0IGJlIHVuZGVyc3Rvb2Q6ICDigJxJbXBsZW1lbnRh dGlvbnMgTVVTVCB1bmRlcnN0YW5kIHRoZSBlbnRpcmUgY29udGVudHMgb2YgdGhlIGhlYWRlcjsg b3RoZXJ3aXNlLCB0aGUg4oCmIE1VU1QgYmUgcmVqZWN0ZWQu4oCdICBUaGVyZSdzIGN1cnJlbnRs eSBhbiBvcGVuIGlzc3VlIGFib3V0IHdoZXRoZXIgYWxsIGhlYWRlciBmaWVsZHMgc2hvdWxkIGJl IHJlcXVpcmVkIHRvIGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRoZW0g b3Igd2hldGhlciB0byByZWxheCB0aGlzIHJlcXVpcmVtZW50IGluIHNvbWUgY2lyY3Vtc3RhbmNl cy4gIFdlIHdvdWxkIGxpa2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgdGhlIGZvbGxv d2luZyBwb3RlbnRpYWwgcmVzb2x1dGlvbnMgdG8gdGhlIGlzc3VlLg0KDQoNCg0KMS4gIE1haW50 YWluIHRoZSBjdXJyZW50IHJlcXVpcmVtZW50IHRoYXQgYWxsIGhlYWRlciBmaWVsZHMgbXVzdCBi ZSB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGVtLg0KDQoNCg0KUFJPOiAg VGhpcyBpcyBhIHNpbXBsZSBydWxl4oCmDQoNCg0KDQpJdCBpcyBub3QgYXMgc2ltcGxlIGFzIGln bm9yaW5nIHVua25vd24gZmllbGRzLCB3aGljaCBhbGwgY29kZSB3aWxsIGRvIG5hdHVyYWxseS4N Cg0KDQoNCkFyZSB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxlcyB3ZWxs IGRlZmluZWQ/IE9idmlvdXNseSBpZiBhIHRvdGFsbHkgdW5rbm93biBmaWVsZCBpcyBwcmVzZW50 IHRoZSBKT1NFIG1lc3NhZ2UgbXVzdCBiZSByZWplY3RlZC4NCg0KDQoNCkhvdyBhYm91dCBpZiBh IGRlZmluZWQgZmllbGQgaXMgaW4gYW4gdW5leHBlY3RlZCBwbGFjZSwgZWcg4oCcemlw4oCdIGlu IGEgSldFIGhlYWRlcj8gUHJlc3VtYWJseSB0aGF0IGhhcyB0byBiZSByZWplY3RlZCBzbyBpdCBp cyBub3Qgc3VmZmljaWVudCBmb3IgY29kZSB0byBjaGVjayBhbnkgSk9TRSBtZXNzYWdlcyBhZ2Fp bnN0IG9uZSBsaXN0Lg0KDQoNCg0KSG93IGFib3V0IGEgSldFIHdpdGggYW4g4oCcZXBr4oCdIGZp ZWxkIHdoZW4g4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdPyBQcmVzdW1hYmx5IHRoYXQgYWxzbyBo YXMgdG8gYmUgcmVqZWN0ZWQgc28gY2hlY2tpbmcgYWdhaW5zdCBhIHN0YXRpYyBsaXN0IG9mIEpX RSBmaWVsZHMgaXMgbm90IHN1ZmZpY2llbnQuDQoNCg0KDQpEb2VzIHRoZSB0eXBlIG9yIHZhbHVl IG9mIGEgZmllbGQgbmVlZCB0byBiZSBjaGVja2VkIGlmIGFuIGltcGxlbWVudGF0aW9uIGRvZXNu 4oCZdCBuZWVkIHRvIHVzZSBpdD8gRm9yIGV4YW1wbGUsIGRvZXMgYW4gaW1wbGVtZW50YXRpb24g dGhhdCBhbHJlYWR5IGhhcyBhIGdpdmVuIGNlcnQgKHNvIGl0IGRvZXNu4oCZdCBuZWVkIHRvIHVz ZSBhIOKAnHg1deKAnSB2YWx1ZSkgbmVlZCB0byBjb25maXJtIHRoYXQgdGhlIOKAnHg1deKAnSB2 YWx1ZSBpcyBhIHN0cmluZywgb3IgaXMgYSB2YWxpZCBVUkksIG9yIGFjdHVhbGx5IHJlc29sdmVz IHRvIHRoZSBzYW1lIGNlcnQ/IFByb2JhYmx5IG5vdC4gSSBhc3N1bWUgaXQgaXMgc3VmZmljaWVu dCB0byB1bmRlcnN0YW5kIHRoYXQgYSBmaWVsZCBjYW4gYmUgaWdub3JlZCwgd2l0aG91dCBhY3R1 YWxseSB1bmRlcnN0YW5kaW5nIGl0cyBhY3R1YWwgc3ludGF4IG9yIHZhbHVlIGlzIGEgc3BlY2lm aWMgbWVzc2FnZS4NCg0KDQoNCuKApmRlc2lnbmVkIHRvIHJlc3VsdCBpbiBzZWN1cmUgaW1wbGVt ZW50YXRpb25zLg0KDQoNCg0KU2VjdXJlIGluIHdoYXQgd2F5PyBJcyB0aGlzIGFpbWVkIHNwZWNp ZmljYWxseSBhdCBwcmV2ZW50aW5nIG5ldyBmaWVsZHMgYmVpbmcgaWdub3JlZCBpbiBjYXNlIHRo ZXkgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgZXhpc3RpbmcgZmllbGRzPw0KDQoNCg0KUFJPOiBO ZXcgZmllbGRzIGFyZSBhbGxvd2VkIHRvIGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIGV4aXN0aW5n IGZpZWxkcyBiZWNhdXNlIGltcGxlbWVudGF0aW9ucyBub3QgdW5kZXJzdGFuZGluZyB0aGUgY2hh bmdlZCBzZW1hbnRpY3Mgd2lsbCBmYWlsLXNhZmUgZHVlIHRvIHNlZWluZyBhbiB1bmtub3duIGZp ZWxkLg0KDQoob3IgaXMgdGhpcyBhIENPTiBmb3IgZW5jb3VyYWdpbmcgZGFuZ2Vyb3VzIGV4dGVu c2lvbnM/KQ0KDQoNCg0K4oCmUmVwcmVzZW50YXRpb25zIG9mIGV4aXN0aW5nIEpXUyAmIEpXRSBv YmplY3RzIGFyZSB1bmNoYW5nZWQuDQoNCkNPTjogIEV4dGVuc2liaWxpdHkgaXMgbGltaXRlZCB0 byBjYXNlcyB3aGVyZSBhbGwgcGFydGljaXBhdGluZyBwYXJ0aWVzIHVuZGVyc3RhbmQgbmV3IGZp ZWxkcyB0aGF0IGFyZSBpbnRyb2R1Y2VkLg0KDQoNCg0KQ09OOiBCZWNhdXNlIGNvZGUgY2FuIHN1 Y2Nlc3NmdWxseSBwcm9jZXNzIEpPU0UgbWVzc2FnZSB3aXRob3V0IGltcGxlbWVudGluZyB0aGUg 4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxlIGl0IGlzIGhhcmQgdG8gaGF2ZSBj b25maWRlbmNlIHRoYXQgaXQgaXMgaW1wbGVtZW50ZWQgKG9yIGltcGxlbWVudGVkIHdlbGwpLg0K DQoNCg0KMkEuICBUYWtlIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIHdoZXJlLCBieSBkZWZhdWx0 LCBhbGwgZmllbGRzIG11c3QgYmUgdW5kZXJzdG9vZCwgYnV0IHdoZXJlIGFuIGV4cGxpY2l0IGxp c3Qgb2YgZmllbGRzIGNhbiBiZSBkZXNpZ25hdGVkIGFzIOKAnG1heSBiZSBpZ25vcmVkIGlmIG5v dCB1bmRlcnN0b29k4oCdLiAgRm9yIGluc3RhbmNlLCBhbiDigJxpZ27igJ0gKG1heSBiZSBpZ25v cmVkKSBtZW1iZXIgY291bGQgYmUgZGVmaW5lZCB3aG9zZSB2YWx1ZSBpcyBhbiBhcnJheSBsaXN0 aW5nIHRoZSBtZW1iZXIgbmFtZXMgdGhhdCBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgaWYgbm90IHVu ZGVyc3Rvb2QuICBBbiBleGFtcGxlIHVzaW5nIHRoaXMgZmllbGQgaW4gYSBKV1MgaGVhZGVyIGlz Og0KDQoNCg0KICAgIHsiYWxnIjoiRVMyNTYiLA0KDQogICAgICJpZ24iOlsibm90ZXMiXSwNCg0K ICAgICAibm90ZXMiOiJUaGlzIHNpZ25hdHVyZSBuZWVkIG5vdCBiZSBjaGVja2VkIHdoZW4gdGhl IG1vb24gaXMgZnVsbCINCg0KICAgIH0NCg0KDQoNCihPYnZpb3VzbHksIHRoZSAiaWduIiBmaWVs ZCBNVVNUIE5PVCBjb250YWluIHRoZSB2YWx1ZSAiaWduIi4pDQoNCg0KDQpQUk86ICBUaGlzIHdv dWxkIGVuYWJsZSBhZGRpbmcgbm9uLWNyaXRpY2FsIGhlYWRlciBmaWVsZHMgd2l0aG91dCBicmVh a2luZyBpbXBsZW1lbnRhdGlvbnMuICBJdCB3b3VsZCBtYWludGFpbiB0aGUgY3VycmVudCBzZW1h bnRpY3MsIHdoaWxlIGFsbG93aW5nIGV4cGxpY2l0IGV4Y2VwdGlvbnMgdG8gYmUgbWFkZSBpbiBj YXNlcyB3aGVyZSB0aGUgZmllbGRzIGFyZSBub3Qgc2VjdXJpdHktY3JpdGljYWwgYW5kIHRoZSBz dHJ1Y3R1cmUgaGFzIGEgbWVhbmluZ2Z1bCBpbnRlcnByZXRhdGlvbiB3aXRob3V0IHRoZW0uICBS ZXByZXNlbnRhdGlvbnMgb2YgZXhpc3RpbmcgSldTICYgSldFIG9iamVjdHMgYXJlIHVuY2hhbmdl ZC4NCg0KQ09OOiAgUmVxdWlyZXMgY29vcmRpbmF0aW9uIG9mIGZpZWxkIG5hbWVzIGFuZCBtYXkt YmUtaWdub3JlZCBsaXN0LCBhZGRpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5Lg0K DQoNCg0KMkIuICBUYWtlIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIHdoZXJlIGluc3RlYWQgb2Yg b25lIGhlYWRlciBvYmplY3QsIHRoZXJlIHdvdWxkIGJlIHR3byBoZWFkZXIgb2JqZWN0cy4gIElt cGxlbWVudGF0aW9ucyB3b3VsZCBiZSByZXF1aXJlZCB0byB1bmRlcnN0YW5kIGFsbCBmaWVsZHMg aW4gdGhlIGZpcnN0IGhlYWRlciBvYmplY3QuICBJbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgYWxs b3dlZCB0byBpZ25vcmUgZmllbGRzIGluIHRoZSBzZWNvbmQgaGVhZGVyIG9iamVjdCBpZiBub3Qg dW5kZXJzdG9vZC4gIEFuIGV4YW1wbGUgb2YgdGhpcyBhcHByb2FjaCwgYWRkaW5nIHRoZSBzZWNv bmQgaGVhZGVyIG9iamVjdCBhZnRlciB0aGUgZmlyc3QgaW4gYSBKV1MsIHdvdWxkIGJlOg0KDQoN Cg0KICAgIGV5SjBlWEFpT2lKS1YxUWlMQTBLSUNKaGJHY2lPaUpJVXpJMU5pSjkNCg0KICAgIC4N Cg0KICAgIGV5SnViM1JsY3lJNklsUm9hWE1nYzJsbmJtRjBkWEpsSUc1bFpXUWdibTkwSUdKbElH Tm9aV05yWldRZ2QyaGxiaUIwYUdVZ2JXOXZiaUJwY3lCbWRXeHNJbjANCg0KICAgIC4NCg0KICAg IGV5SnBjM01pT2lKcWIyVWlMQTBLSUNKbGVIQWlPakV6TURBNE1Ua3pPREFzRFFvZ0ltaDBkSEE2 THk5bGVHRnRjR3hsTG1OdmJTOXBjMTl5YjI5MElqcDBjblZsZlENCg0KICAgIC4NCg0KICAgIGRC amZ0SmVaNENWUC1tQjkySzI3dWhiVUpVMXAxcl93VzFnRldGT0VqWGsNCg0KDQoNClRoZSBmaXJz dCwgdGhpcmQsIGFuZCBmb3VydGggZmllbGRzIGFyZSBmcm9tIHRoZSBleGFtcGxlIEpXUyBpbiB0 aGUgY3VycmVudCBzcGVjLiBUaGUgbmV3IHNlY29uZCBmaWVsZCBpcyB0aGUgYmFzZTY0dXJsIGVu Y29kZWQgcmVwcmVzZW50YXRpb24gb2YgdGhlIHN0cmluZyAneyJub3RlcyI6IlRoaXMgc2lnbmF0 dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0nLg0KDQoNCg0K UFJPOiAgTWF5LWJlLWlnbm9yZWQgZmllbGRzIGFyZSBlYXNpbHkgZGlzdGluZ3Vpc2hhYmxlIGZy b20gbXVzdC1iZS11bmRlcnN0b29kIGZpZWxkcy4NCg0KQ09OOiAgSW1wbGVtZW50YXRpb25zIG11 c3QgY29uc3VsdC9tZXJnZSB0d28gc2V0cyBvZiBoZWFkZXJzIHRvIHVuZGVyc3RhbmQgdGhlIG1l YW5pbmcvc3RydWN0dXJlIG9mIHRoZSBvYmplY3QsIGFkZGluZyBzb21lIGltcGxlbWVudGF0aW9u IGNvbXBsZXhpdHkuICBFeGlzdGluZyBKV1MgJiBKV0Ugb2JqZWN0IHJlcHJlc2VudGF0aW9ucyB3 b3VsZCBiZWNvbWUgaW52YWxpZC4NCg0KDQoNCjMuIEhhdmUgYSBmaWVsZCB0aGF0IGluZGljYXRl cyB0aGUgc2VtYW50aWNzIG9mIHRoZSBKT1NFIG1lc3NhZ2UuIEZvciBpbnN0YW5jZSB0aGUgZmll bGQgY291bGQgYmUgY2FsbGVkIOKAnCHigJ0gYW5kIGRlZmluZWQgdmFsdWVzIGNvdWxkIGJlIOKA nHNpZ+KAnSwg4oCcbWFj4oCdLCDigJxlbmPigJ3igKYgZm9yIHNpZ25lZC13aXRoLWFuLWFzeW1t ZXRyaWMta2V5LCBNQUNlZC13aXRoLWEtc2hhcmVkLXNlY3JldCwgZW5jcnlwdGVkLShBRUFEKS13 aXRoLXNoYXJlZC1zZWNyZXTigKYuIFRoZSBkZWZpbml0aW9uIG9mIGEgdmFsdWUgZm9yIHRoZSDi gJwh4oCdIGZpZWxkIGluZGljYXRlcyB0aGUgb3RoZXIgZmllbGRzIGl0IHVzZXMuIFJlY2lwaWVu dHMgTVVTVCBpZ25vcmUgYW55IHVucmVjb2duaXplZCBmaWVsZHMuIE9yaWdpbmF0b3JzIGFkZGlu ZyBhIG5ldyBmaWVsZCB0aGF0IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiBhIG1lc3NhZ2UgTVVT VCB1c2UgYSBuZXcgdmFsdWUgZm9yIHRoZSDigJwh4oCdIGZpZWxkLg0KDQoNCg0KUFJPOiBDb2Rl IHdpbGwgaW1wbGVtZW50IHRoaXMgcnVsZSBuYXR1cmFsbHksIHNpbXBseSBieSBzd2l0Y2hpbmcg b24gdGhlIOKAnCHigJ0gZmllbGQgdmFsdWUuDQoNCg0KDQpQUk86IEl0IGlzIGV4dGVuc2libGUu IEV4dHJhIGZpZWxkcyBjYW4gYmUgZGVmaW5lZCBhbmQgZGVwbG95ZWQgd2l0aG91dCByZXF1aXJp bmcgb3JpZ2luYXRvcnMgYW5kIHJlY2lwaWVudHMgdG8gYmUgdXBncmFkZWQgc2ltdWx0YW5lb3Vz bHkuDQoNCg0KDQpDT046IEFyYml0cmFyeSBleHRyYSBkYXRhIG9mIGEgb3JpZ2luYXRvcuKAmXMg Y2hvb3NpbmcgY2FuIGJlIGluY2x1ZGVkIGFzIHVua25vd24gZmllbGRzIGluIG1lc3NhZ2VzIHRo YXQgcmVjaXBpZW50cyB3aWxsIGFjY2VwdC4gVGhvdWdoIHRoaXMgaXMgdHJ1ZSBldmVuIHdpdGgg YSDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUgKGVnIHdoaXRlc3BhY2UgaW4g dGhlIEpTT04gaGVhZGVyLCBqdW5rIGluIGEg4oCceDV14oCdIFVSSSBmcmFnbWVudOKApikuDQoN Cg0KDQoNCg0KQWZ0ZXIgYSBkaXNjdXNzaW9uIHBlcmlvZCwgd2UgYmVsaWV2ZSB0aGF0IGl0IHdv dWxkIGJlIHVzZWZ1bCBmb3IgdGhlIGNoYWlycyB0byBtYWtlIHR3byBmb3JtYWwgY29uc2Vuc3Vz IGNhbGxzIG9mIHRoZSBmb2xsb3dpbmcga2luZDoNCg0KDQoNCkZJUlNUIFBPTEw6ICBTaG91bGQg YWxsIGhlYWRlciBmaWVsZHMgYmUgY3JpdGljYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byB1bmRl cnN0YW5kPw0KDQpZRVMg4oCTIEFsbCBoZWFkZXIgZmllbGRzIG11c3QgY29udGludWUgdG8gYmUg dW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMgb3IgdGhlIGlucHV0IG11c3QgYmUgcmVqZWN0 ZWQuDQoNCk5PIOKAkyBBIG1lYW5zIG9mIGxpc3RpbmcgdGhhdCBzcGVjaWZpYyBoZWFkZXIgZmll bGRzIG1heSBiZSBzYWZlbHkgaWdub3JlZCBzaG91bGQgYmUgZGVmaW5lZC4NCg0KDQoNCkFMVEVS TkFUSVZFIEZJUlNUIFBPTEwgRk9SIEVYSVNUSU5HIElNUExFTUVOVE9SUzogSGF2ZSB5b3UgaW1w bGVtZW50ZWQgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZT8gV2hpY2gg c2l0dWF0aW9ucyBkbyB5b3UgcmVqZWN0IChlZyDigJxmb2/igJ07IOKAnHppcOKAnSBpbiBKV1M7 IOKAnGVwa+KAnSB3aGVuIOKAnGFsZ+KAnTrigJ1SU0EtT0FFUOKAnTsg4oCcamt14oCdOjxub24t c3RyaW5nPjsg4oCcamt14oCdOuKAnTxpbnZhbGlkIFVSST7igJ07IOKApj8NCg0KDQoNCkFMVEVS TkFUSVZFIFNFQ09ORCBQT0xMOiBIb3cgcmVhbCBpcyB0aGUgcmlzayB0aGF0IGZ1dHVyZSBncm91 cHMgd2lsbCBkZWxpYmVyYXRlbHkgZGVzaWduICYgZGVwbG95IG5ldyBmaWVsZHMgdGhhdCBjaGFu Z2UgdGhlIHNlbWFudGljcyBvZiBKT1NFIG1lc3NhZ2VzIGRlcGVuZGluZyBvbiB3aGV0aGVyIG9y IG5vdCB0aGUgbmV3IGZpZWxkIGlzIHVuZGVyc3Rvb2QsIHdpdGhvdXQgcmVhbGl6aW5nIHRoZSBz ZWN1cml0eSBjb25zZXF1ZW5jZXM/DQoNCg0KDQpBTFRFUk5BVElWRSBUSElSRCBQT0xMOiBJcyBK T1NFIHNvIGNvbXBsZXRlIGFuZCBzdGFibGUgdGhhdCBleHRlbnNpb25zIGFyZSB1bmxpa2VseSB0 byBiZSBuZWVkZWQ/DQoNCg0KDQpTRUNPTkQgUE9MTDogIFNob3VsZCB0aGUgcmVzdWx0IG9mIHRo ZSBmaXJzdCBwb2xsIGJlICJOTyIsIHdoaWNoIHN5bnRheCB3b3VsZCB5b3UgcHJlZmVyIGZvciBk ZXNpZ25hdGluZyB0aGUgaGVhZGVyIGZpZWxkcyB0aGF0IG1heSBiZSBpZ25vcmVkIGlmIG5vdCB1 bmRlcnN0b29kPw0KDQpBIOKAkyBEZWZpbmUgYSBoZWFkZXIgZmllbGQgdGhhdCBleHBsaWNpdGx5 IGxpc3RzIHRoZSBmaWVsZHMgdGhhdCBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgaWYgbm90IHVuZGVy c3Rvb2QuDQoNCkIg4oCTIEludHJvZHVjZSBhIHNlY29uZCBoZWFkZXIsIHdoZXJlIGltcGxlbWVu dGF0aW9ucyBtdXN0IHVuZGVyc3RhbmQgYWxsIGZpZWxkcyBpbiB0aGUgZmlyc3QgYnV0IHRoZXkg bWF5IGlnbm9yZSBub3QtdW5kZXJzdG9vZCBmaWVsZHMgaW4gdGhlIHNlY29uZC4NCg0KDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBmb3Ig Y29uc2lkZXJpbmcgdGhlc2UgcXVlc3Rpb25zLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSaWNoYXJkIEJhcm5lcywgSm9obiBCcmFkbGV5LCBNaWtl IEpvbmVzDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_4E1F6AAD24975D4BA5B168042967394366968592TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5IaSBKYW1lcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBl ciB0aGUgcmVzcG9uc2UgSSBqdXN0IHNlbnQgdG8gQXhlbCwgd2hlbiB3ZSBkaXNjdXNzZWQgdGhp cyBpc3N1ZSBpbiB0aGUgcGFzdCwgb25seSBvbmUgcGVyc29uIHdhcyBpbiBmYXZvciBvZiBhIG11 c3QtaWdub3JlLWJ5LWRlZmF1bHQgYmVoYXZpb3IsIGFuZCB5ZXQgdGhhdOKAmXMgd2hhdCB5b3Xi gJlyZSBhZHZvY2F0aW5nIGJlbG93LiZuYnNwOyBTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwMTIxNi5odG1sLiZuYnNwOw0KIE9mIGNvdXJz ZSwgaXTigJlzIGFsd2F5cyBwb3NzaWJsZSB5b3UgY291bGQgY2hhbmdlIG1pbmRzLCBidXQgSSBz dXNwZWN0IHRoYXQgaWYgeW91IHdhbnQgdG8gaW5mbHVlbmNlIHRoZSBvdXRjb21lIG9mIHRoaXMg aXNzdWUsIHRoZSBoaWdoZXN0LXBheW9mZiBzdHJhdGVneSB3b3VsZCBiZSB0byBkaXNjdXNzIHN5 bnRheCBvcHRpb25zIHRoYXQgcmVxdWlyZSBwZW9wbGUgdG8gdGFrZSBzcGVjaWFsIGFjdGlvbiB0 byBpZ25vcmUgYSBub3QtdW5kZXJzdG9vZA0KIGZpZWxkLCByYXRoZXIgdGhhbiB0aGUgb3RoZXIg d2F5IGFyb3VuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNeSB0d28gY2VudHMgd29ydGjigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDE4LCAyMDEyIDQ6NTkgQU08 YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFtqb3NlXSBXaGV0aGVyIGltcGxlbWVudGF0aW9ucyBtdXN0IHVuZGVyc3RhbmQg YWxsIEpPU0UgaGVhZGVyIGZpZWxkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5NeSBjb21tZW50cyBpbiByZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkN1cnJlbnRseSB0aGUg Sk9TRSBzcGVjcyBjb250YWluIHRoZSBmb2xsb3dpbmcgbGFuZ3VhZ2UgZGVjbGFyaW5nIHRoYXQg YWxsIGhlYWRlciAoYW5kIHNvbWUgb3RoZXIpIGZpZWxkcyBtdXN0IGJlIHVuZGVyc3Rvb2Q6Jm5i c3A7IOKAnEltcGxlbWVudGF0aW9ucyBNVVNUIHVuZGVyc3RhbmQgdGhlIGVudGlyZSBjb250ZW50 cyBvZiB0aGUgaGVhZGVyOyBvdGhlcndpc2UsIHRoZSDigKYgTVVTVCBiZSByZWplY3RlZC7igJ0m bmJzcDsgVGhlcmUncw0KIGN1cnJlbnRseSBhbiBvcGVuIGlzc3VlIGFib3V0IHdoZXRoZXIgYWxs IGhlYWRlciBmaWVsZHMgc2hvdWxkIGJlIHJlcXVpcmVkIHRvIGJlIHVuZGVyc3Rvb2QgYnkgaW1w bGVtZW50YXRpb25zIHVzaW5nIHRoZW0gb3Igd2hldGhlciB0byByZWxheCB0aGlzIHJlcXVpcmVt ZW50IGluIHNvbWUgY2lyY3Vtc3RhbmNlcy4mbmJzcDsgV2Ugd291bGQgbGlrZSB0aGUgd29ya2lu ZyBncm91cCB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIHBvdGVudGlhbCByZXNvbHV0aW9ucw0K IHRvIHRoZSBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MS4mbmJzcDsgTWFp bnRhaW4gdGhlIGN1cnJlbnQgcmVxdWlyZW1lbnQgdGhhdCBhbGwgaGVhZGVyIGZpZWxkcyBtdXN0 IGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRoZW0uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlBSTzombmJzcDsgVGhpcyBpcyBhIHNpbXBsZSBydWxlPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5JdCBpcyBub3QgYXMgc2ltcGxlIGFzIGlnbm9yaW5nIHVua25vd24gZmllbGRzLCB3 aGljaCBhbGwgY29kZSB3aWxsIGRvIG5hdHVyYWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6cmVkIj5BcmUgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZXMg d2VsbCBkZWZpbmVkPyBPYnZpb3VzbHkgaWYgYSB0b3RhbGx5IHVua25vd24gZmllbGQgaXMgcHJl c2VudCB0aGUgSk9TRSBtZXNzYWdlIG11c3QgYmUgcmVqZWN0ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+SG93IGFib3V0IGlmIGEgZGVmaW5lZCBmaWVsZCBpcyBpbiBhbiB1 bmV4cGVjdGVkIHBsYWNlLCBlZyDigJx6aXDigJ0gaW4gYSBKV0UgaGVhZGVyPyBQcmVzdW1hYmx5 IHRoYXQgaGFzIHRvIGJlIHJlamVjdGVkIHNvIGl0IGlzIG5vdCBzdWZmaWNpZW50IGZvciBjb2Rl IHRvIGNoZWNrIGFueSBKT1NFIG1lc3NhZ2VzIGFnYWluc3Qgb25lIGxpc3QuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJl ZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SG93IGFib3V0IGEgSldFIHdpdGggYW4g4oCcZXBr4oCd IGZpZWxkIHdoZW4g4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdPyBQcmVzdW1hYmx5IHRoYXQgYWxz byBoYXMgdG8gYmUgcmVqZWN0ZWQgc28gY2hlY2tpbmcgYWdhaW5zdCBhIHN0YXRpYyBsaXN0IG9m IEpXRSBmaWVsZHMgaXMgbm90IHN1ZmZpY2llbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOnJlZCI+RG9lcyB0aGUgdHlwZSBvciB2YWx1ZSBvZiBhIGZpZWxkIG5lZWQgdG8gYmUgY2hl Y2tlZCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQgbmVlZCB0byB1c2UgaXQ/IEZvciBl eGFtcGxlLCBkb2VzIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgYWxyZWFkeSBoYXMgYSBnaXZlbiBj ZXJ0IChzbyBpdCBkb2VzbuKAmXQgbmVlZCB0byB1c2UgYSDigJx4NXXigJ0gdmFsdWUpIG5lZWQN CiB0byBjb25maXJtIHRoYXQgdGhlIOKAnHg1deKAnSB2YWx1ZSBpcyBhIHN0cmluZywgb3IgaXMg YSB2YWxpZCBVUkksIG9yIGFjdHVhbGx5IHJlc29sdmVzIHRvIHRoZSBzYW1lIGNlcnQ/IFByb2Jh Ymx5IG5vdC4gSSBhc3N1bWUgaXQgaXMgc3VmZmljaWVudCB0byB1bmRlcnN0YW5kIHRoYXQgYSBm aWVsZCBjYW4gYmUgaWdub3JlZCwgd2l0aG91dCBhY3R1YWxseSB1bmRlcnN0YW5kaW5nIGl0cyBh Y3R1YWwgc3ludGF4IG9yIHZhbHVlIGlzIGEgc3BlY2lmaWMNCiBtZXNzYWdlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+4oCmPC9zcGFuPmRlc2lnbmVkIHRvIHJl c3VsdCBpbiBzZWN1cmUgaW1wbGVtZW50YXRpb25zLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+U2VjdXJlIGluIHdoYXQg d2F5PyBJcyB0aGlzIGFpbWVkIHNwZWNpZmljYWxseSBhdCBwcmV2ZW50aW5nIG5ldyBmaWVsZHMg YmVpbmcgaWdub3JlZCBpbiBjYXNlIHRoZXkgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgZXhpc3Rp bmcgZmllbGRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5QUk86IE5l dyBmaWVsZHMgYXJlIGFsbG93ZWQgdG8gY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgZXhpc3Rpbmcg ZmllbGRzIGJlY2F1c2UgaW1wbGVtZW50YXRpb25zIG5vdCB1bmRlcnN0YW5kaW5nIHRoZSBjaGFu Z2VkIHNlbWFudGljcyB3aWxsIGZhaWwtc2FmZSBkdWUgdG8gc2VlaW5nIGFuIHVua25vd24gZmll bGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+KG9yIGlzIHRoaXMgYSBDT04gZm9yIGVuY291cmFnaW5nIGRhbmdl cm91cyBleHRlbnNpb25zPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPuKApjwvc3Bhbj5SZXByZXNlbnRhdGlvbnMgb2YgZXhpc3RpbmcgSldTICZhbXA7IEpXRSBv YmplY3RzIGFyZSB1bmNoYW5nZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5DT046Jm5ic3A7IEV4dGVuc2liaWxpdHkgaXMgbGltaXRlZCB0byBjYXNlcyB3aGVyZSBh bGwgcGFydGljaXBhdGluZyBwYXJ0aWVzIHVuZGVyc3RhbmQgbmV3IGZpZWxkcyB0aGF0IGFyZSBp bnRyb2R1Y2VkLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6cmVkIj5DT046IEJlY2F1c2UgY29kZSBjYW4gc3VjY2Vzc2Z1bGx5IHByb2Nl c3MgSk9TRSBtZXNzYWdlIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRoZSDigJxNVVNUIHVuZGVyc3Rh bmQgb3IgcmVqZWN04oCdIHJ1bGUgaXQgaXMgaGFyZCB0byBoYXZlIGNvbmZpZGVuY2UgdGhhdCBp dCBpcyBpbXBsZW1lbnRlZCAob3IgaW1wbGVtZW50ZWQgd2VsbCkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjJB LiZuYnNwOyBUYWtlIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIHdoZXJlLCBieSBkZWZhdWx0LCBh bGwgZmllbGRzIG11c3QgYmUgdW5kZXJzdG9vZCwgYnV0IHdoZXJlIGFuIGV4cGxpY2l0IGxpc3Qg b2YgZmllbGRzIGNhbiBiZSBkZXNpZ25hdGVkIGFzIOKAnG1heSBiZSBpZ25vcmVkIGlmIG5vdCB1 bmRlcnN0b29k4oCdLiZuYnNwOyBGb3IgaW5zdGFuY2UsIGFuIOKAnGlnbuKAnSAobWF5IGJlIGln bm9yZWQpIG1lbWJlciBjb3VsZCBiZQ0KIGRlZmluZWQgd2hvc2UgdmFsdWUgaXMgYW4gYXJyYXkg bGlzdGluZyB0aGUgbWVtYmVyIG5hbWVzIHRoYXQgbWF5IGJlIHNhZmVseSBpZ25vcmVkIGlmIG5v dCB1bmRlcnN0b29kLiZuYnNwOyBBbiBleGFtcGxlIHVzaW5nIHRoaXMgZmllbGQgaW4gYSBKV1Mg aGVhZGVyIGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgeyZxdW90O2FsZyZxdW90OzomcXVvdDtFUzI1NiZxdW90Oyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZ24m cXVvdDs6WyZxdW90O25vdGVzJnF1b3Q7XSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtub3RlcyZxdW90OzomcXVv dDtUaGlzIHNpZ25hdHVyZSBuZWVkIG5vdCBiZSBjaGVja2VkIHdoZW4gdGhlIG1vb24gaXMgZnVs bCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KE9idmlvdXNseSwgdGhl ICZxdW90O2lnbiZxdW90OyBmaWVsZCBNVVNUIE5PVCBjb250YWluIHRoZSB2YWx1ZSAmcXVvdDtp Z24mcXVvdDsuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QUk86Jm5ic3A7IFRoaXMg d291bGQgZW5hYmxlIGFkZGluZyBub24tY3JpdGljYWwgaGVhZGVyIGZpZWxkcyB3aXRob3V0IGJy ZWFraW5nIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgSXQgd291bGQgbWFpbnRhaW4gdGhlIGN1cnJl bnQgc2VtYW50aWNzLCB3aGlsZSBhbGxvd2luZyBleHBsaWNpdCBleGNlcHRpb25zIHRvIGJlIG1h ZGUgaW4gY2FzZXMgd2hlcmUgdGhlIGZpZWxkcyBhcmUgbm90IHNlY3VyaXR5LWNyaXRpY2FsIGFu ZA0KIHRoZSBzdHJ1Y3R1cmUgaGFzIGEgbWVhbmluZ2Z1bCBpbnRlcnByZXRhdGlvbiB3aXRob3V0 IHRoZW0uJm5ic3A7IFJlcHJlc2VudGF0aW9ucyBvZiBleGlzdGluZyBKV1MgJmFtcDsgSldFIG9i amVjdHMgYXJlIHVuY2hhbmdlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkNPTjombmJzcDsgUmVxdWlyZXMgY29vcmRpbmF0aW9uIG9mIGZpZWxkIG5hbWVzIGFuZCBt YXktYmUtaWdub3JlZCBsaXN0LCBhZGRpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4yQi4mbmJzcDsgVGFrZSBhbiBhbHRlcm5h dGl2ZSBhcHByb2FjaCB3aGVyZSBpbnN0ZWFkIG9mIG9uZSBoZWFkZXIgb2JqZWN0LCB0aGVyZSB3 b3VsZCBiZSB0d28gaGVhZGVyIG9iamVjdHMuJm5ic3A7IEltcGxlbWVudGF0aW9ucyB3b3VsZCBi ZSByZXF1aXJlZCB0byB1bmRlcnN0YW5kIGFsbCBmaWVsZHMgaW4gdGhlIGZpcnN0IGhlYWRlciBv YmplY3QuJm5ic3A7IEltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSBhbGxvd2VkIHRvIGlnbm9yZQ0K IGZpZWxkcyBpbiB0aGUgc2Vjb25kIGhlYWRlciBvYmplY3QgaWYgbm90IHVuZGVyc3Rvb2QuJm5i c3A7IEFuIGV4YW1wbGUgb2YgdGhpcyBhcHByb2FjaCwgYWRkaW5nIHRoZSBzZWNvbmQgaGVhZGVy IG9iamVjdCBhZnRlciB0aGUgZmlyc3QgaW4gYSBKV1MsIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZXlKMGVYQWlPaUpLVjFRaUxBMEtJ Q0poYkdjaU9pSklVekkxTmlKOTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBleUp1YjNSbGN5STZJbFJvYVhNZ2MybG5ibUYwZFhK bElHNWxaV1FnYm05MElHSmxJR05vWldOclpXUWdkMmhsYmlCMGFHVWdiVzl2YmlCcGN5Qm1kV3hz SW4wPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGV5SnBjM01pT2lKcWIyVWlMQTBLSUNKbGVIQWlPakV6TURBNE1Ua3pPREFzRFFv Z0ltaDBkSEE2THk5bGVHRnRjR3hsTG1OdmJTOXBjMTl5YjI5MElqcDBjblZsZlE8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZEJq ZnRKZVo0Q1ZQLW1COTJLMjd1aGJVSlUxcDFyX3dXMWdGV0ZPRWpYazxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5UaGUgZmlyc3QsIHRoaXJkLCBhbmQgZm91cnRoIGZpZWxkcyBhcmUgZnJv bSB0aGUgZXhhbXBsZSBKV1MgaW4gdGhlIGN1cnJlbnQgc3BlYy4gVGhlIG5ldyBzZWNvbmQgZmll bGQgaXMgdGhlIGJhc2U2NHVybCBlbmNvZGVkIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBzdHJpbmcg J3smcXVvdDtub3RlcyZxdW90OzomcXVvdDtUaGlzIHNpZ25hdHVyZSBuZWVkIG5vdCBiZSBjaGVj a2VkIHdoZW4gdGhlIG1vb24gaXMgZnVsbCZxdW90O30nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5QUk86Jm5ic3A7IE1heS1iZS1pZ25vcmVkIGZpZWxkcyBhcmUgZWFzaWx5IGRpc3Rp bmd1aXNoYWJsZSBmcm9tIG11c3QtYmUtdW5kZXJzdG9vZCBmaWVsZHMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DT046Jm5ic3A7IEltcGxlbWVudGF0aW9ucyBtdXN0 IGNvbnN1bHQvbWVyZ2UgdHdvIHNldHMgb2YgaGVhZGVycyB0byB1bmRlcnN0YW5kIHRoZSBtZWFu aW5nL3N0cnVjdHVyZSBvZiB0aGUgb2JqZWN0LCBhZGRpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBj b21wbGV4aXR5LiZuYnNwOyBFeGlzdGluZyBKV1MgJmFtcDsgSldFIG9iamVjdCByZXByZXNlbnRh dGlvbnMgd291bGQgYmVjb21lIGludmFsaWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJl ZCI+My4gSGF2ZSBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIEpP U0UgbWVzc2FnZS4gRm9yIGluc3RhbmNlIHRoZSBmaWVsZCBjb3VsZCBiZSBjYWxsZWQg4oCcIeKA nSBhbmQgZGVmaW5lZCB2YWx1ZXMgY291bGQgYmUg4oCcc2ln4oCdLCDigJxtYWPigJ0sIOKAnGVu Y+KAneKApiBmb3Igc2lnbmVkLXdpdGgtYW4tYXN5bW1ldHJpYy1rZXksIE1BQ2VkLXdpdGgtYS1z aGFyZWQtc2VjcmV0LA0KIGVuY3J5cHRlZC0oQUVBRCktd2l0aC1zaGFyZWQtc2VjcmV04oCmLiBU aGUgZGVmaW5pdGlvbiBvZiBhIHZhbHVlIGZvciB0aGUg4oCcIeKAnSBmaWVsZCBpbmRpY2F0ZXMg dGhlIG90aGVyIGZpZWxkcyBpdCB1c2VzLiBSZWNpcGllbnRzIE1VU1QgaWdub3JlIGFueSB1bnJl Y29nbml6ZWQgZmllbGRzLiBPcmlnaW5hdG9ycyBhZGRpbmcgYSBuZXcgZmllbGQgdGhhdCBjaGFu Z2VzIHRoZSBzZW1hbnRpY3Mgb2YgYSBtZXNzYWdlIE1VU1QgdXNlIGEgbmV3IHZhbHVlDQogZm9y IHRoZSDigJwh4oCdIGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPlBS TzogQ29kZSB3aWxsIGltcGxlbWVudCB0aGlzIHJ1bGUgbmF0dXJhbGx5LCBzaW1wbHkgYnkgc3dp dGNoaW5nIG9uIHRoZSDigJwh4oCdIGZpZWxkIHZhbHVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPlBSTzogSXQgaXMgZXh0ZW5zaWJsZS4gRXh0cmEgZmllbGRzIGNhbiBiZSBk ZWZpbmVkIGFuZCBkZXBsb3llZCB3aXRob3V0IHJlcXVpcmluZyBvcmlnaW5hdG9ycyBhbmQgcmVj aXBpZW50cyB0byBiZSB1cGdyYWRlZCBzaW11bHRhbmVvdXNseS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6cmVkIj5DT046IEFyYml0cmFyeSBleHRyYSBkYXRhIG9mIGEgb3JpZ2luYXRv cuKAmXMgY2hvb3NpbmcgY2FuIGJlIGluY2x1ZGVkIGFzIHVua25vd24gZmllbGRzIGluIG1lc3Nh Z2VzIHRoYXQgcmVjaXBpZW50cyB3aWxsIGFjY2VwdC4gVGhvdWdoIHRoaXMgaXMgdHJ1ZSBldmVu IHdpdGggYSDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUgKGVnIHdoaXRlc3Bh Y2UgaW4NCiB0aGUgSlNPTiBoZWFkZXIsIGp1bmsgaW4gYSDigJx4NXXigJ0gVVJJIGZyYWdtZW50 4oCmKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFmdGVyIGEgZGlz Y3Vzc2lvbiBwZXJpb2QsIHdlIGJlbGlldmUgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIHRo ZSBjaGFpcnMgdG8gbWFrZSB0d28gZm9ybWFsIGNvbnNlbnN1cyBjYWxscyBvZiB0aGUgZm9sbG93 aW5nIGtpbmQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZJUlNUIFBPTEw6Jm5ic3A7 IFNob3VsZCBhbGwgaGVhZGVyIGZpZWxkcyBiZSBjcml0aWNhbCBmb3IgaW1wbGVtZW50YXRpb25z IHRvIHVuZGVyc3RhbmQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Z RVMg4oCTIEFsbCBoZWFkZXIgZmllbGRzIG11c3QgY29udGludWUgdG8gYmUgdW5kZXJzdG9vZCBi eSBpbXBsZW1lbnRhdGlvbnMgb3IgdGhlIGlucHV0IG11c3QgYmUgcmVqZWN0ZWQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5OTyDigJMgQSBtZWFucyBvZiBsaXN0aW5n IHRoYXQgc3BlY2lmaWMgaGVhZGVyIGZpZWxkcyBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgc2hvdWxk IGJlIGRlZmluZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+QUxURVJOQVRJVkUg RklSU1QgUE9MTCBGT1IgRVhJU1RJTkcgSU1QTEVNRU5UT1JTOiBIYXZlIHlvdSBpbXBsZW1lbnRl ZCB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxlPyBXaGljaCBzaXR1YXRp b25zIGRvIHlvdSByZWplY3QgKGVnIOKAnGZvb+KAnTsg4oCcemlw4oCdIGluIEpXUzsg4oCcZXBr 4oCdIHdoZW4g4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdOyDigJxqa3XigJ06Jmx0O25vbi1zdHJp bmcmZ3Q7Ow0KIOKAnGprdeKAnTrigJ0mbHQ7aW52YWxpZCBVUkkmZ3Q74oCdOyDigKY/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkFMVEVSTkFUSVZFIFNFQ09ORCBQT0xM OiBIb3cgcmVhbCBpcyB0aGUgcmlzayB0aGF0IGZ1dHVyZSBncm91cHMgd2lsbCBkZWxpYmVyYXRl bHkgZGVzaWduICZhbXA7IGRlcGxveSBuZXcgZmllbGRzIHRoYXQgY2hhbmdlIHRoZSBzZW1hbnRp Y3Mgb2YgSk9TRSBtZXNzYWdlcyBkZXBlbmRpbmcgb24gd2hldGhlciBvciBub3QgdGhlIG5ldyBm aWVsZCBpcyB1bmRlcnN0b29kLA0KIHdpdGhvdXQgcmVhbGl6aW5nIHRoZSBzZWN1cml0eSBjb25z ZXF1ZW5jZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkFMVEVSTkFU SVZFIFRISVJEIFBPTEw6IElzIEpPU0Ugc28gY29tcGxldGUgYW5kIHN0YWJsZSB0aGF0IGV4dGVu c2lvbnMgYXJlIHVubGlrZWx5IHRvIGJlIG5lZWRlZD88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TRUNPTkQgUE9MTDombmJzcDsgU2hvdWxkIHRoZSBy ZXN1bHQgb2YgdGhlIGZpcnN0IHBvbGwgYmUgJnF1b3Q7Tk8mcXVvdDssIHdoaWNoIHN5bnRheCB3 b3VsZCB5b3UgcHJlZmVyIGZvciBkZXNpZ25hdGluZyB0aGUgaGVhZGVyIGZpZWxkcyB0aGF0IG1h eSBiZSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29kPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+QSDigJMgRGVmaW5lIGEgaGVhZGVyIGZpZWxkIHRoYXQgZXhwbGljaXRs eSBsaXN0cyB0aGUgZmllbGRzIHRoYXQgbWF5IGJlIHNhZmVseSBpZ25vcmVkIGlmIG5vdCB1bmRl cnN0b29kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QiDigJMgSW50 cm9kdWNlIGEgc2Vjb25kIGhlYWRlciwgd2hlcmUgaW1wbGVtZW50YXRpb25zIG11c3QgdW5kZXJz dGFuZCBhbGwgZmllbGRzIGluIHRoZSBmaXJzdCBidXQgdGhleSBtYXkgaWdub3JlIG5vdC11bmRl cnN0b29kIGZpZWxkcyBpbiB0aGUgc2Vjb25kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 VGhhbmtzIGZvciBjb25zaWRlcmluZyB0aGVzZSBxdWVzdGlvbnMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUmljaGFyZCBCYXJuZXMsIEpvaG4gQnJhZGxleSwgTWlrZSBK b25lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B168042967394366968592TK5EX14MBXC283r_-- From rbarnes@bbn.com Tue Dec 18 14:27:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83121E805A for ; Tue, 18 Dec 2012 14:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq6A9HoPw9e6 for ; Tue, 18 Dec 2012 14:27:10 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1152721E8054 for ; Tue, 18 Dec 2012 14:27:10 -0800 (PST) Received: from ros-dhcp192-1-51-58.bbn.com ([192.1.51.58]:52437) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tl5ct-000C8U-Vu; Tue, 18 Dec 2012 17:27:04 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 18 Dec 2012 17:27:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0CD0F737-D07D-4A7D-828C-57B4F66A7386@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:27:11 -0000 Maybe my opinion wasn't reflected clearly, but I agree with James that = "ignore by default" is the reality for basically everything these days, = especially at the formatting layer, where this stuff sits. Your average = JSON parser isn't even paying attention to what the field names are. = Even XML schemas, which can supposedly reject unknowns, are littered = with wide-open extension points in practice (). =20 Applications can always require that certain fields be present. Having = any notion of criticality at this layer is only a convenience that saves = applications from having to fix or pre-negotiate criticality values. (And, before it comes up: PKIX is an application protocol. CMS has no = notion of criticality.) =20 --Richard On Dec 18, 2012, at 5:03 PM, Mike Jones = wrote: > Hi James, > =20 > Per the response I just sent to Axel, when we discussed this issue in = the past, only one person was in favor of a must-ignore-by-default = behavior, and yet that=92s what you=92re advocating below. See = http://www.ietf.org/mail-archive/web/jose/current/msg01216.html. Of = course, it=92s always possible you could change minds, but I suspect = that if you want to influence the outcome of this issue, the = highest-payoff strategy would be to discuss syntax options that require = people to take special action to ignore a not-understood field, rather = than the other way around. > =20 > My two = cents worth=85 > -- = Mike > =20 > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 > Sent: Tuesday, December 18, 2012 4:59 AM > To: Mike Jones; jose@ietf.org > Subject: RE: [jose] Whether implementations must understand all JOSE = header fields > =20 > My comments in red. > =20 > Currently the JOSE specs contain the following language declaring that = all header (and some other) fields must be understood: =93Implementations= MUST understand the entire contents of the header; otherwise, the =85 = MUST be rejected.=94 There's currently an open issue about whether all = header fields should be required to be understood by implementations = using them or whether to relax this requirement in some circumstances. = We would like the working group to consider the following potential = resolutions to the issue. > =20 > 1. Maintain the current requirement that all header fields must be = understood by implementations using them. > =20 > PRO: This is a simple rule=85 > =20 > It is not as simple as ignoring unknown fields, which all code will do = naturally. > =20 > Are the =93MUST understand or reject=94 rules well defined? Obviously = if a totally unknown field is present the JOSE message must be rejected. > =20 > How about if a defined field is in an unexpected place, eg =93zip=94 = in a JWE header? Presumably that has to be rejected so it is not = sufficient for code to check any JOSE messages against one list. > =20 > How about a JWE with an =93epk=94 field when =93alg=94:=94RSA-OAEP=94? = Presumably that also has to be rejected so checking against a static = list of JWE fields is not sufficient. > =20 > Does the type or value of a field need to be checked if an = implementation doesn=92t need to use it? For example, does an = implementation that already has a given cert (so it doesn=92t need to = use a =93x5u=94 value) need to confirm that the =93x5u=94 value is a = string, or is a valid URI, or actually resolves to the same cert? = Probably not. I assume it is sufficient to understand that a field can = be ignored, without actually understanding its actual syntax or value is = a specific message. > =20 > =85designed to result in secure implementations. > =20 > Secure in what way? Is this aimed specifically at preventing new = fields being ignored in case they change the semantics of existing = fields? > =20 > PRO: New fields are allowed to change the semantics of existing fields = because implementations not understanding the changed semantics will = fail-safe due to seeing an unknown field. > (or is this a CON for encouraging dangerous extensions?) > =20 > =85Representations of existing JWS & JWE objects are unchanged. > CON: Extensibility is limited to cases where all participating = parties understand new fields that are introduced. > =20 > CON: Because code can successfully process JOSE message without = implementing the =93MUST understand or reject=94 rule it is hard to have = confidence that it is implemented (or implemented well). > =20 > 2A. Take an alternative approach where, by default, all fields must = be understood, but where an explicit list of fields can be designated as = =93may be ignored if not understood=94. For instance, an =93ign=94 (may = be ignored) member could be defined whose value is an array listing the = member names that may be safely ignored if not understood. An example = using this field in a JWS header is: > =20 > {"alg":"ES256", > "ign":["notes"], > "notes":"This signature need not be checked when the moon is = full" > } > =20 > (Obviously, the "ign" field MUST NOT contain the value "ign".) > =20 > PRO: This would enable adding non-critical header fields without = breaking implementations. It would maintain the current semantics, = while allowing explicit exceptions to be made in cases where the fields = are not security-critical and the structure has a meaningful = interpretation without them. Representations of existing JWS & JWE = objects are unchanged. > CON: Requires coordination of field names and may-be-ignored list, = adding some implementation complexity. > =20 > 2B. Take an alternative approach where instead of one header object, = there would be two header objects. Implementations would be required to = understand all fields in the first header object. Implementations would = be allowed to ignore fields in the second header object if not = understood. An example of this approach, adding the second header = object after the first in a JWS, would be: > =20 > eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 > . > = eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW= 9vbiBpcyBmdWxsIn0 > . > = eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS= 9pc19yb290Ijp0cnVlfQ > . > dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk > =20 > The first, third, and fourth fields are from the example JWS in the = current spec. The new second field is the base64url encoded = representation of the string '{"notes":"This signature need not be = checked when the moon is full"}'. > =20 > PRO: May-be-ignored fields are easily distinguishable from = must-be-understood fields. > CON: Implementations must consult/merge two sets of headers to = understand the meaning/structure of the object, adding some = implementation complexity. Existing JWS & JWE object representations = would become invalid. > =20 > 3. Have a field that indicates the semantics of the JOSE message. For = instance the field could be called =93!=94 and defined values could be = =93sig=94, =93mac=94, =93enc=94=85 for signed-with-an-asymmetric-key, = MACed-with-a-shared-secret, encrypted-(AEAD)-with-shared-secret=85. The = definition of a value for the =93!=94 field indicates the other fields = it uses. Recipients MUST ignore any unrecognized fields. Originators = adding a new field that changes the semantics of a message MUST use a = new value for the =93!=94 field. > =20 > PRO: Code will implement this rule naturally, simply by switching on = the =93!=94 field value. > =20 > PRO: It is extensible. Extra fields can be defined and deployed = without requiring originators and recipients to be upgraded = simultaneously. > =20 > CON: Arbitrary extra data of a originator=92s choosing can be included = as unknown fields in messages that recipients will accept. Though this = is true even with a =93MUST understand or reject=94 rule (eg whitespace = in the JSON header, junk in a =93x5u=94 URI fragment=85). > =20 > =20 > After a discussion period, we believe that it would be useful for the = chairs to make two formal consensus calls of the following kind: > =20 > FIRST POLL: Should all header fields be critical for implementations = to understand? > YES =96 All header fields must continue to be understood by = implementations or the input must be rejected. > NO =96 A means of listing that specific header fields may be safely = ignored should be defined. > =20 > ALTERNATIVE FIRST POLL FOR EXISTING IMPLEMENTORS: Have you implemented = the =93MUST understand or reject=94 rule? Which situations do you reject = (eg =93foo=94; =93zip=94 in JWS; =93epk=94 when =93alg=94:=94RSA-OAEP=94; = =93jku=94:; =93jku=94:=94=94; =85? > =20 > ALTERNATIVE SECOND POLL: How real is the risk that future groups will = deliberately design & deploy new fields that change the semantics of = JOSE messages depending on whether or not the new field is understood, = without realizing the security consequences? > =20 > ALTERNATIVE THIRD POLL: Is JOSE so complete and stable that extensions = are unlikely to be needed? > =20 > SECOND POLL: Should the result of the first poll be "NO", which = syntax would you prefer for designating the header fields that may be = ignored if not understood? > A =96 Define a header field that explicitly lists the fields that may = be safely ignored if not understood. > B =96 Introduce a second header, where implementations must understand = all fields in the first but they may ignore not-understood fields in the = second. > =20 > Thanks for considering = these questions, > Richard Barnes, John = Bradley, Mike Jones > =20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Tue Dec 18 14:41:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304B621F87D2 for ; Tue, 18 Dec 2012 14:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XNISfJMdzsC for ; Tue, 18 Dec 2012 14:41:57 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 02C7821F87D1 for ; Tue, 18 Dec 2012 14:41:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,312,1355058000"; d="scan'208,217";a="106500097" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 19 Dec 2012 09:41:47 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6930"; a="52607369" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcani.tcif.telstra.com.au with ESMTP; 19 Dec 2012 09:41:47 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Wed, 19 Dec 2012 09:41:47 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 19 Dec 2012 09:41:46 +1100 Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115040898B5WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:41:59 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115040898B5WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCg0KQ291bGQgeW91IGF0IGxlYXN0IGV4cGFuZCBhIGJpdCBvbiBob3cgeW91IGV4cGVj dCBhIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZSB3aWxsIHdvcmsgaW4gcHJh Y3RpY2U/DQpGb3IgaW5zdGFuY2UsIGRvZXMgdGhlIHNwZWMgd29yZGluZyBmb3JiaWQg4oCcemlw 4oCdIGluIGEgSldTPyDigJxlcGvigJ0gd2hlbiDigJxhbGfigJ064oCdUlNBLU9BRVDigJ0/IOKA nHg1deKAnTo3PyDigJx4NXXigJ064oCdaGVsbG8gd29ybGTigJ0/IFdpbGwgaW1wbGVtZW50YXRp b25zIGJlIGNvbnNpc3RlbnQ/DQoNClBlcmhhcHMgeW91IGhhdmUgYW4gaW1wbGVtZW50YXRpb24g b2YgdGhpcyBydWxlIGFscmVhZHkgYW5kIGNhbiB0ZWxsIHVzIHdoYXQgaXQgZG9lcz8NCg0KSSB3 b3VsZCBhbHNvIGFwcHJlY2lhdGUgeW91ciB0aG91Z2h0cyBvbiB3aGV0aGVyIHNvbWVvbmUgY2Fu IGV4dGVuZCBKV1MgYnkgc3BlY2lmeWluZzogd2hlbiB0aGUg4oCcemlw4oCdIGZpZWxkIGlzIHBy ZXNlbnQgaW4gYSBKV1MgdGhlIGNvbnRlbnQgaXMgY29tcHJlc3NlZC4NClRoYXQgbG9va3MgbGVn aXRpbWF0ZSB3aXRoIHRoZSBjdXJyZW50IOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0g cnVsZS4gSSB0aGluayBpdCBpcyBsaWtlbHksIGhvd2V2ZXIsIHRoYXQgc3VjaCBhbiBleHRlbnNp b24gd2lsbCBjYXVzZSBzZWN1cml0eSBwcm9ibGVtcy4gU29tZSBpbXBsZW1lbnRhdGlvbnMgd2ls bCBjb25maXJtIHRoYXQg4oCcemlw4oCdIGlzIG9uIHRoZSBsaXN0IG9mIGtub3duIHN0YW5kYXJk IGZpZWxkcywgYnV0IHdpbGwgaWdub3JlIGl0IGluIHRoZSBKV1MgcHJvY2Vzc2luZyBjb2RlLg0K DQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb21dDQpTZW50OiBXZWRuZXNkYXksIDE5IERlY2VtYmVyIDIwMTIgOTow NCBBTQ0KVG86IE1hbmdlciwgSmFtZXMgSDsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtq b3NlXSBXaGV0aGVyIGltcGxlbWVudGF0aW9ucyBtdXN0IHVuZGVyc3RhbmQgYWxsIEpPU0UgaGVh ZGVyIGZpZWxkcw0KDQpIaSBKYW1lcywNCg0KUGVyIHRoZSByZXNwb25zZSBJIGp1c3Qgc2VudCB0 byBBeGVsLCB3aGVuIHdlIGRpc2N1c3NlZCB0aGlzIGlzc3VlIGluIHRoZSBwYXN0LCBvbmx5IG9u ZSBwZXJzb24gd2FzIGluIGZhdm9yIG9mIGEgbXVzdC1pZ25vcmUtYnktZGVmYXVsdCBiZWhhdmlv ciwgYW5kIHlldCB0aGF04oCZcyB3aGF0IHlvdeKAmXJlIGFkdm9jYXRpbmcgYmVsb3cuICBTZWUg aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwMTIx Ni5odG1sLiAgT2YgY291cnNlLCBpdOKAmXMgYWx3YXlzIHBvc3NpYmxlIHlvdSBjb3VsZCBjaGFu Z2UgbWluZHMsIGJ1dCBJIHN1c3BlY3QgdGhhdCBpZiB5b3Ugd2FudCB0byBpbmZsdWVuY2UgdGhl IG91dGNvbWUgb2YgdGhpcyBpc3N1ZSwgdGhlIGhpZ2hlc3QtcGF5b2ZmIHN0cmF0ZWd5IHdvdWxk IGJlIHRvIGRpc2N1c3Mgc3ludGF4IG9wdGlvbnMgdGhhdCByZXF1aXJlIHBlb3BsZSB0byB0YWtl IHNwZWNpYWwgYWN0aW9uIHRvIGlnbm9yZSBhIG5vdC11bmRlcnN0b29kIGZpZWxkLCByYXRoZXIg dGhhbiB0aGUgb3RoZXIgd2F5IGFyb3VuZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE15IHR3byBjZW50cyB3b3J0aOKA pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWFuZ2VyLCBKYW1lcyBIIFttYWlsdG86SmFtZXMu SC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE4LCAy MDEyIDQ6NTkgQU0NClRvOiBNaWtlIEpvbmVzOyBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGll dGYub3JnPg0KU3ViamVjdDogUkU6IFtqb3NlXSBXaGV0aGVyIGltcGxlbWVudGF0aW9ucyBtdXN0 IHVuZGVyc3RhbmQgYWxsIEpPU0UgaGVhZGVyIGZpZWxkcw0KDQoNCk15IGNvbW1lbnRzIGluIHJl ZC4NCg0KDQoNCkN1cnJlbnRseSB0aGUgSk9TRSBzcGVjcyBjb250YWluIHRoZSBmb2xsb3dpbmcg bGFuZ3VhZ2UgZGVjbGFyaW5nIHRoYXQgYWxsIGhlYWRlciAoYW5kIHNvbWUgb3RoZXIpIGZpZWxk cyBtdXN0IGJlIHVuZGVyc3Rvb2Q6ICDigJxJbXBsZW1lbnRhdGlvbnMgTVVTVCB1bmRlcnN0YW5k IHRoZSBlbnRpcmUgY29udGVudHMgb2YgdGhlIGhlYWRlcjsgb3RoZXJ3aXNlLCB0aGUg4oCmIE1V U1QgYmUgcmVqZWN0ZWQu4oCdICBUaGVyZSdzIGN1cnJlbnRseSBhbiBvcGVuIGlzc3VlIGFib3V0 IHdoZXRoZXIgYWxsIGhlYWRlciBmaWVsZHMgc2hvdWxkIGJlIHJlcXVpcmVkIHRvIGJlIHVuZGVy c3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRoZW0gb3Igd2hldGhlciB0byByZWxheCB0 aGlzIHJlcXVpcmVtZW50IGluIHNvbWUgY2lyY3Vtc3RhbmNlcy4gIFdlIHdvdWxkIGxpa2UgdGhl IHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBwb3RlbnRpYWwgcmVzb2x1 dGlvbnMgdG8gdGhlIGlzc3VlLg0KDQoNCg0KMS4gIE1haW50YWluIHRoZSBjdXJyZW50IHJlcXVp cmVtZW50IHRoYXQgYWxsIGhlYWRlciBmaWVsZHMgbXVzdCBiZSB1bmRlcnN0b29kIGJ5IGltcGxl bWVudGF0aW9ucyB1c2luZyB0aGVtLg0KDQoNCg0KUFJPOiAgVGhpcyBpcyBhIHNpbXBsZSBydWxl 4oCmDQoNCg0KDQpJdCBpcyBub3QgYXMgc2ltcGxlIGFzIGlnbm9yaW5nIHVua25vd24gZmllbGRz LCB3aGljaCBhbGwgY29kZSB3aWxsIGRvIG5hdHVyYWxseS4NCg0KDQoNCkFyZSB0aGUg4oCcTVVT VCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxlcyB3ZWxsIGRlZmluZWQ/IE9idmlvdXNseSBp ZiBhIHRvdGFsbHkgdW5rbm93biBmaWVsZCBpcyBwcmVzZW50IHRoZSBKT1NFIG1lc3NhZ2UgbXVz dCBiZSByZWplY3RlZC4NCg0KDQoNCkhvdyBhYm91dCBpZiBhIGRlZmluZWQgZmllbGQgaXMgaW4g YW4gdW5leHBlY3RlZCBwbGFjZSwgZWcg4oCcemlw4oCdIGluIGEgSldFIGhlYWRlcj8gUHJlc3Vt YWJseSB0aGF0IGhhcyB0byBiZSByZWplY3RlZCBzbyBpdCBpcyBub3Qgc3VmZmljaWVudCBmb3Ig Y29kZSB0byBjaGVjayBhbnkgSk9TRSBtZXNzYWdlcyBhZ2FpbnN0IG9uZSBsaXN0Lg0KDQoNCg0K SG93IGFib3V0IGEgSldFIHdpdGggYW4g4oCcZXBr4oCdIGZpZWxkIHdoZW4g4oCcYWxn4oCdOuKA nVJTQS1PQUVQ4oCdPyBQcmVzdW1hYmx5IHRoYXQgYWxzbyBoYXMgdG8gYmUgcmVqZWN0ZWQgc28g Y2hlY2tpbmcgYWdhaW5zdCBhIHN0YXRpYyBsaXN0IG9mIEpXRSBmaWVsZHMgaXMgbm90IHN1ZmZp Y2llbnQuDQoNCg0KDQpEb2VzIHRoZSB0eXBlIG9yIHZhbHVlIG9mIGEgZmllbGQgbmVlZCB0byBi ZSBjaGVja2VkIGlmIGFuIGltcGxlbWVudGF0aW9uIGRvZXNu4oCZdCBuZWVkIHRvIHVzZSBpdD8g Rm9yIGV4YW1wbGUsIGRvZXMgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBhbHJlYWR5IGhhcyBhIGdp dmVuIGNlcnQgKHNvIGl0IGRvZXNu4oCZdCBuZWVkIHRvIHVzZSBhIOKAnHg1deKAnSB2YWx1ZSkg bmVlZCB0byBjb25maXJtIHRoYXQgdGhlIOKAnHg1deKAnSB2YWx1ZSBpcyBhIHN0cmluZywgb3Ig aXMgYSB2YWxpZCBVUkksIG9yIGFjdHVhbGx5IHJlc29sdmVzIHRvIHRoZSBzYW1lIGNlcnQ/IFBy b2JhYmx5IG5vdC4gSSBhc3N1bWUgaXQgaXMgc3VmZmljaWVudCB0byB1bmRlcnN0YW5kIHRoYXQg YSBmaWVsZCBjYW4gYmUgaWdub3JlZCwgd2l0aG91dCBhY3R1YWxseSB1bmRlcnN0YW5kaW5nIGl0 cyBhY3R1YWwgc3ludGF4IG9yIHZhbHVlIGlzIGEgc3BlY2lmaWMgbWVzc2FnZS4NCg0KDQoNCuKA pmRlc2lnbmVkIHRvIHJlc3VsdCBpbiBzZWN1cmUgaW1wbGVtZW50YXRpb25zLg0KDQoNCg0KU2Vj dXJlIGluIHdoYXQgd2F5PyBJcyB0aGlzIGFpbWVkIHNwZWNpZmljYWxseSBhdCBwcmV2ZW50aW5n IG5ldyBmaWVsZHMgYmVpbmcgaWdub3JlZCBpbiBjYXNlIHRoZXkgY2hhbmdlIHRoZSBzZW1hbnRp Y3Mgb2YgZXhpc3RpbmcgZmllbGRzPw0KDQoNCg0KUFJPOiBOZXcgZmllbGRzIGFyZSBhbGxvd2Vk IHRvIGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIGV4aXN0aW5nIGZpZWxkcyBiZWNhdXNlIGltcGxl bWVudGF0aW9ucyBub3QgdW5kZXJzdGFuZGluZyB0aGUgY2hhbmdlZCBzZW1hbnRpY3Mgd2lsbCBm YWlsLXNhZmUgZHVlIHRvIHNlZWluZyBhbiB1bmtub3duIGZpZWxkLg0KDQoob3IgaXMgdGhpcyBh IENPTiBmb3IgZW5jb3VyYWdpbmcgZGFuZ2Vyb3VzIGV4dGVuc2lvbnM/KQ0KDQoNCg0K4oCmUmVw cmVzZW50YXRpb25zIG9mIGV4aXN0aW5nIEpXUyAmIEpXRSBvYmplY3RzIGFyZSB1bmNoYW5nZWQu DQoNCkNPTjogIEV4dGVuc2liaWxpdHkgaXMgbGltaXRlZCB0byBjYXNlcyB3aGVyZSBhbGwgcGFy dGljaXBhdGluZyBwYXJ0aWVzIHVuZGVyc3RhbmQgbmV3IGZpZWxkcyB0aGF0IGFyZSBpbnRyb2R1 Y2VkLg0KDQoNCg0KQ09OOiBCZWNhdXNlIGNvZGUgY2FuIHN1Y2Nlc3NmdWxseSBwcm9jZXNzIEpP U0UgbWVzc2FnZSB3aXRob3V0IGltcGxlbWVudGluZyB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIG9y IHJlamVjdOKAnSBydWxlIGl0IGlzIGhhcmQgdG8gaGF2ZSBjb25maWRlbmNlIHRoYXQgaXQgaXMg aW1wbGVtZW50ZWQgKG9yIGltcGxlbWVudGVkIHdlbGwpLg0KDQoNCg0KMkEuICBUYWtlIGFuIGFs dGVybmF0aXZlIGFwcHJvYWNoIHdoZXJlLCBieSBkZWZhdWx0LCBhbGwgZmllbGRzIG11c3QgYmUg dW5kZXJzdG9vZCwgYnV0IHdoZXJlIGFuIGV4cGxpY2l0IGxpc3Qgb2YgZmllbGRzIGNhbiBiZSBk ZXNpZ25hdGVkIGFzIOKAnG1heSBiZSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29k4oCdLiAgRm9y IGluc3RhbmNlLCBhbiDigJxpZ27igJ0gKG1heSBiZSBpZ25vcmVkKSBtZW1iZXIgY291bGQgYmUg ZGVmaW5lZCB3aG9zZSB2YWx1ZSBpcyBhbiBhcnJheSBsaXN0aW5nIHRoZSBtZW1iZXIgbmFtZXMg dGhhdCBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuICBBbiBleGFtcGxl IHVzaW5nIHRoaXMgZmllbGQgaW4gYSBKV1MgaGVhZGVyIGlzOg0KDQoNCg0KICAgIHsiYWxnIjoi RVMyNTYiLA0KDQogICAgICJpZ24iOlsibm90ZXMiXSwNCg0KICAgICAibm90ZXMiOiJUaGlzIHNp Z25hdHVyZSBuZWVkIG5vdCBiZSBjaGVja2VkIHdoZW4gdGhlIG1vb24gaXMgZnVsbCINCg0KICAg IH0NCg0KDQoNCihPYnZpb3VzbHksIHRoZSAiaWduIiBmaWVsZCBNVVNUIE5PVCBjb250YWluIHRo ZSB2YWx1ZSAiaWduIi4pDQoNCg0KDQpQUk86ICBUaGlzIHdvdWxkIGVuYWJsZSBhZGRpbmcgbm9u LWNyaXRpY2FsIGhlYWRlciBmaWVsZHMgd2l0aG91dCBicmVha2luZyBpbXBsZW1lbnRhdGlvbnMu ICBJdCB3b3VsZCBtYWludGFpbiB0aGUgY3VycmVudCBzZW1hbnRpY3MsIHdoaWxlIGFsbG93aW5n IGV4cGxpY2l0IGV4Y2VwdGlvbnMgdG8gYmUgbWFkZSBpbiBjYXNlcyB3aGVyZSB0aGUgZmllbGRz IGFyZSBub3Qgc2VjdXJpdHktY3JpdGljYWwgYW5kIHRoZSBzdHJ1Y3R1cmUgaGFzIGEgbWVhbmlu Z2Z1bCBpbnRlcnByZXRhdGlvbiB3aXRob3V0IHRoZW0uICBSZXByZXNlbnRhdGlvbnMgb2YgZXhp c3RpbmcgSldTICYgSldFIG9iamVjdHMgYXJlIHVuY2hhbmdlZC4NCg0KQ09OOiAgUmVxdWlyZXMg Y29vcmRpbmF0aW9uIG9mIGZpZWxkIG5hbWVzIGFuZCBtYXktYmUtaWdub3JlZCBsaXN0LCBhZGRp bmcgc29tZSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5Lg0KDQoNCg0KMkIuICBUYWtlIGFuIGFs dGVybmF0aXZlIGFwcHJvYWNoIHdoZXJlIGluc3RlYWQgb2Ygb25lIGhlYWRlciBvYmplY3QsIHRo ZXJlIHdvdWxkIGJlIHR3byBoZWFkZXIgb2JqZWN0cy4gIEltcGxlbWVudGF0aW9ucyB3b3VsZCBi ZSByZXF1aXJlZCB0byB1bmRlcnN0YW5kIGFsbCBmaWVsZHMgaW4gdGhlIGZpcnN0IGhlYWRlciBv YmplY3QuICBJbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgYWxsb3dlZCB0byBpZ25vcmUgZmllbGRz IGluIHRoZSBzZWNvbmQgaGVhZGVyIG9iamVjdCBpZiBub3QgdW5kZXJzdG9vZC4gIEFuIGV4YW1w bGUgb2YgdGhpcyBhcHByb2FjaCwgYWRkaW5nIHRoZSBzZWNvbmQgaGVhZGVyIG9iamVjdCBhZnRl ciB0aGUgZmlyc3QgaW4gYSBKV1MsIHdvdWxkIGJlOg0KDQoNCg0KICAgIGV5SjBlWEFpT2lKS1Yx UWlMQTBLSUNKaGJHY2lPaUpJVXpJMU5pSjkNCg0KICAgIC4NCg0KICAgIGV5SnViM1JsY3lJNkls Um9hWE1nYzJsbmJtRjBkWEpsSUc1bFpXUWdibTkwSUdKbElHTm9aV05yWldRZ2QyaGxiaUIwYUdV Z2JXOXZiaUJwY3lCbWRXeHNJbjANCg0KICAgIC4NCg0KICAgIGV5SnBjM01pT2lKcWIyVWlMQTBL SUNKbGVIQWlPakV6TURBNE1Ua3pPREFzRFFvZ0ltaDBkSEE2THk5bGVHRnRjR3hsTG1OdmJTOXBj MTl5YjI5MElqcDBjblZsZlENCg0KICAgIC4NCg0KICAgIGRCamZ0SmVaNENWUC1tQjkySzI3dWhi VUpVMXAxcl93VzFnRldGT0VqWGsNCg0KDQoNClRoZSBmaXJzdCwgdGhpcmQsIGFuZCBmb3VydGgg ZmllbGRzIGFyZSBmcm9tIHRoZSBleGFtcGxlIEpXUyBpbiB0aGUgY3VycmVudCBzcGVjLiBUaGUg bmV3IHNlY29uZCBmaWVsZCBpcyB0aGUgYmFzZTY0dXJsIGVuY29kZWQgcmVwcmVzZW50YXRpb24g b2YgdGhlIHN0cmluZyAneyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNr ZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0nLg0KDQoNCg0KUFJPOiAgTWF5LWJlLWlnbm9yZWQg ZmllbGRzIGFyZSBlYXNpbHkgZGlzdGluZ3Vpc2hhYmxlIGZyb20gbXVzdC1iZS11bmRlcnN0b29k IGZpZWxkcy4NCg0KQ09OOiAgSW1wbGVtZW50YXRpb25zIG11c3QgY29uc3VsdC9tZXJnZSB0d28g c2V0cyBvZiBoZWFkZXJzIHRvIHVuZGVyc3RhbmQgdGhlIG1lYW5pbmcvc3RydWN0dXJlIG9mIHRo ZSBvYmplY3QsIGFkZGluZyBzb21lIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuICBFeGlzdGlu ZyBKV1MgJiBKV0Ugb2JqZWN0IHJlcHJlc2VudGF0aW9ucyB3b3VsZCBiZWNvbWUgaW52YWxpZC4N Cg0KDQoNCjMuIEhhdmUgYSBmaWVsZCB0aGF0IGluZGljYXRlcyB0aGUgc2VtYW50aWNzIG9mIHRo ZSBKT1NFIG1lc3NhZ2UuIEZvciBpbnN0YW5jZSB0aGUgZmllbGQgY291bGQgYmUgY2FsbGVkIOKA nCHigJ0gYW5kIGRlZmluZWQgdmFsdWVzIGNvdWxkIGJlIOKAnHNpZ+KAnSwg4oCcbWFj4oCdLCDi gJxlbmPigJ3igKYgZm9yIHNpZ25lZC13aXRoLWFuLWFzeW1tZXRyaWMta2V5LCBNQUNlZC13aXRo LWEtc2hhcmVkLXNlY3JldCwgZW5jcnlwdGVkLShBRUFEKS13aXRoLXNoYXJlZC1zZWNyZXTigKYu IFRoZSBkZWZpbml0aW9uIG9mIGEgdmFsdWUgZm9yIHRoZSDigJwh4oCdIGZpZWxkIGluZGljYXRl cyB0aGUgb3RoZXIgZmllbGRzIGl0IHVzZXMuIFJlY2lwaWVudHMgTVVTVCBpZ25vcmUgYW55IHVu cmVjb2duaXplZCBmaWVsZHMuIE9yaWdpbmF0b3JzIGFkZGluZyBhIG5ldyBmaWVsZCB0aGF0IGNo YW5nZXMgdGhlIHNlbWFudGljcyBvZiBhIG1lc3NhZ2UgTVVTVCB1c2UgYSBuZXcgdmFsdWUgZm9y IHRoZSDigJwh4oCdIGZpZWxkLg0KDQoNCg0KUFJPOiBDb2RlIHdpbGwgaW1wbGVtZW50IHRoaXMg cnVsZSBuYXR1cmFsbHksIHNpbXBseSBieSBzd2l0Y2hpbmcgb24gdGhlIOKAnCHigJ0gZmllbGQg dmFsdWUuDQoNCg0KDQpQUk86IEl0IGlzIGV4dGVuc2libGUuIEV4dHJhIGZpZWxkcyBjYW4gYmUg ZGVmaW5lZCBhbmQgZGVwbG95ZWQgd2l0aG91dCByZXF1aXJpbmcgb3JpZ2luYXRvcnMgYW5kIHJl Y2lwaWVudHMgdG8gYmUgdXBncmFkZWQgc2ltdWx0YW5lb3VzbHkuDQoNCg0KDQpDT046IEFyYml0 cmFyeSBleHRyYSBkYXRhIG9mIGEgb3JpZ2luYXRvcuKAmXMgY2hvb3NpbmcgY2FuIGJlIGluY2x1 ZGVkIGFzIHVua25vd24gZmllbGRzIGluIG1lc3NhZ2VzIHRoYXQgcmVjaXBpZW50cyB3aWxsIGFj Y2VwdC4gVGhvdWdoIHRoaXMgaXMgdHJ1ZSBldmVuIHdpdGggYSDigJxNVVNUIHVuZGVyc3RhbmQg b3IgcmVqZWN04oCdIHJ1bGUgKGVnIHdoaXRlc3BhY2UgaW4gdGhlIEpTT04gaGVhZGVyLCBqdW5r IGluIGEg4oCceDV14oCdIFVSSSBmcmFnbWVudOKApikuDQoNCg0KDQoNCg0KQWZ0ZXIgYSBkaXNj dXNzaW9uIHBlcmlvZCwgd2UgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhl IGNoYWlycyB0byBtYWtlIHR3byBmb3JtYWwgY29uc2Vuc3VzIGNhbGxzIG9mIHRoZSBmb2xsb3dp bmcga2luZDoNCg0KDQoNCkZJUlNUIFBPTEw6ICBTaG91bGQgYWxsIGhlYWRlciBmaWVsZHMgYmUg Y3JpdGljYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byB1bmRlcnN0YW5kPw0KDQpZRVMg4oCTIEFs bCBoZWFkZXIgZmllbGRzIG11c3QgY29udGludWUgdG8gYmUgdW5kZXJzdG9vZCBieSBpbXBsZW1l bnRhdGlvbnMgb3IgdGhlIGlucHV0IG11c3QgYmUgcmVqZWN0ZWQuDQoNCk5PIOKAkyBBIG1lYW5z IG9mIGxpc3RpbmcgdGhhdCBzcGVjaWZpYyBoZWFkZXIgZmllbGRzIG1heSBiZSBzYWZlbHkgaWdu b3JlZCBzaG91bGQgYmUgZGVmaW5lZC4NCg0KDQoNCkFMVEVSTkFUSVZFIEZJUlNUIFBPTEwgRk9S IEVYSVNUSU5HIElNUExFTUVOVE9SUzogSGF2ZSB5b3UgaW1wbGVtZW50ZWQgdGhlIOKAnE1VU1Qg dW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZT8gV2hpY2ggc2l0dWF0aW9ucyBkbyB5b3UgcmVq ZWN0IChlZyDigJxmb2/igJ07IOKAnHppcOKAnSBpbiBKV1M7IOKAnGVwa+KAnSB3aGVuIOKAnGFs Z+KAnTrigJ1SU0EtT0FFUOKAnTsg4oCcamt14oCdOjxub24tc3RyaW5nPjsg4oCcamt14oCdOuKA nTxpbnZhbGlkIFVSST7igJ07IOKApj8NCg0KDQoNCkFMVEVSTkFUSVZFIFNFQ09ORCBQT0xMOiBI b3cgcmVhbCBpcyB0aGUgcmlzayB0aGF0IGZ1dHVyZSBncm91cHMgd2lsbCBkZWxpYmVyYXRlbHkg ZGVzaWduICYgZGVwbG95IG5ldyBmaWVsZHMgdGhhdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBK T1NFIG1lc3NhZ2VzIGRlcGVuZGluZyBvbiB3aGV0aGVyIG9yIG5vdCB0aGUgbmV3IGZpZWxkIGlz IHVuZGVyc3Rvb2QsIHdpdGhvdXQgcmVhbGl6aW5nIHRoZSBzZWN1cml0eSBjb25zZXF1ZW5jZXM/ DQoNCg0KDQpBTFRFUk5BVElWRSBUSElSRCBQT0xMOiBJcyBKT1NFIHNvIGNvbXBsZXRlIGFuZCBz dGFibGUgdGhhdCBleHRlbnNpb25zIGFyZSB1bmxpa2VseSB0byBiZSBuZWVkZWQ/DQoNCg0KDQpT RUNPTkQgUE9MTDogIFNob3VsZCB0aGUgcmVzdWx0IG9mIHRoZSBmaXJzdCBwb2xsIGJlICJOTyIs IHdoaWNoIHN5bnRheCB3b3VsZCB5b3UgcHJlZmVyIGZvciBkZXNpZ25hdGluZyB0aGUgaGVhZGVy IGZpZWxkcyB0aGF0IG1heSBiZSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29kPw0KDQpBIOKAkyBE ZWZpbmUgYSBoZWFkZXIgZmllbGQgdGhhdCBleHBsaWNpdGx5IGxpc3RzIHRoZSBmaWVsZHMgdGhh dCBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuDQoNCkIg4oCTIEludHJv ZHVjZSBhIHNlY29uZCBoZWFkZXIsIHdoZXJlIGltcGxlbWVudGF0aW9ucyBtdXN0IHVuZGVyc3Rh bmQgYWxsIGZpZWxkcyBpbiB0aGUgZmlyc3QgYnV0IHRoZXkgbWF5IGlnbm9yZSBub3QtdW5kZXJz dG9vZCBmaWVsZHMgaW4gdGhlIHNlY29uZC4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBmb3IgY29uc2lkZXJpbmcgdGhlc2UgcXVl c3Rpb25zLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSaWNoYXJkIEJhcm5lcywgSm9obiBCcmFkbGV5LCBNaWtlIEpvbmVzDQoNCg0KLS0NCkphbWVz IE1hbmdlcg0K --_000_255B9BB34FB7D647A506DC292726F6E115040898B5WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5N c29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPk1pa2UsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Q291bGQgeW91 IGF0IGxlYXN0IGV4cGFuZCBhIGJpdCBvbiBob3cgeW91IGV4cGVjdCBhIOKAnE1VU1QgdW5kZXJz dGFuZCBvciByZWplY3TigJ0gcnVsZSB3aWxsIHdvcmsgaW4gcHJhY3RpY2U/PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ Rm9yIGluc3RhbmNlLCBkb2VzIHRoZSBzcGVjIHdvcmRpbmcgZm9yYmlkIOKAnHppcOKAnSBpbiBh IEpXUz8g4oCcZXBr4oCdIHdoZW4g4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdPyDigJx4NXXigJ06 Nz8g4oCceDV14oCdOuKAnWhlbGxvIHdvcmxk4oCdPyBXaWxsIGltcGxlbWVudGF0aW9ucyBiZSBj b25zaXN0ZW50PyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5QZXJoYXBzIHlvdSBoYXZl IGFuIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgcnVsZSBhbHJlYWR5IGFuZCBjYW4gdGVsbCB1cyB3 aGF0IGl0IGRvZXM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSB3b3VsZCBhbHNvIGFw cHJlY2lhdGUgeW91ciB0aG91Z2h0cyBvbiB3aGV0aGVyIHNvbWVvbmUgY2FuIGV4dGVuZCBKV1Mg Ynkgc3BlY2lmeWluZzogd2hlbiB0aGUg4oCcemlw4oCdIGZpZWxkIGlzIHByZXNlbnQgaW4gYSBK V1MgdGhlIGNvbnRlbnQgaXMgY29tcHJlc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGF0IGxvb2tzIGxlZ2l0 aW1hdGUgd2l0aCB0aGUgY3VycmVudCDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1 bGUuIEkgdGhpbmsgaXQgaXMgbGlrZWx5LCBob3dldmVyLCB0aGF0IHN1Y2ggYW4gZXh0ZW5zaW9u IHdpbGwgY2F1c2Ugc2VjdXJpdHkgcHJvYmxlbXMuIFNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwg Y29uZmlybSB0aGF0IOKAnHppcOKAnSBpcyBvbiB0aGUgbGlzdCBvZiBrbm93biBzdGFuZGFyZCBm aWVsZHMsIGJ1dCB3aWxsIGlnbm9yZSBpdCBpbiB0aGUgSldTIHByb2Nlc3NpbmcgY29kZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2Vy PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXSA8YnI+ PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgMTkgRGVjZW1iZXIgMjAxMiA5OjA0IEFNPGJyPjxiPlRv OjwvYj4gTWFuZ2VyLCBKYW1lcyBIOyBqb3NlQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBS RTogW2pvc2VdIFdoZXRoZXIgaW1wbGVtZW50YXRpb25zIG11c3QgdW5kZXJzdGFuZCBhbGwgSk9T RSBoZWFkZXIgZmllbGRzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SGkgSmFtZXMsPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlBlciB0aGUgcmVzcG9uc2UgSSBq dXN0IHNlbnQgdG8gQXhlbCwgd2hlbiB3ZSBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBpbiB0aGUgcGFz dCwgb25seSBvbmUgcGVyc29uIHdhcyBpbiBmYXZvciBvZiBhIG11c3QtaWdub3JlLWJ5LWRlZmF1 bHQgYmVoYXZpb3IsIGFuZCB5ZXQgdGhhdOKAmXMgd2hhdCB5b3XigJlyZSBhZHZvY2F0aW5nIGJl bG93LiZuYnNwOyBTZWUgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2pvc2UvY3VycmVudC9tc2cwMTIxNi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzAxMjE2Lmh0bWw8L2E+LiZuYnNwOyBPZiBjb3Vy c2UsIGl04oCZcyBhbHdheXMgcG9zc2libGUgeW91IGNvdWxkIGNoYW5nZSBtaW5kcywgYnV0IEkg c3VzcGVjdCB0aGF0IGlmIHlvdSB3YW50IHRvIGluZmx1ZW5jZSB0aGUgb3V0Y29tZSBvZiB0aGlz IGlzc3VlLCB0aGUgaGlnaGVzdC1wYXlvZmYgc3RyYXRlZ3kgd291bGQgYmUgdG8gZGlzY3VzcyBz eW50YXggb3B0aW9ucyB0aGF0IHJlcXVpcmUgcGVvcGxlIHRvIHRha2Ugc3BlY2lhbCBhY3Rpb24g dG8gaWdub3JlIGEgbm90LXVuZGVyc3Rvb2QgZmllbGQsIHJhdGhlciB0aGFuIHRoZSBvdGhlciB3 YXkgYXJvdW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTXkgdHdvIGNlbnRzIHdv cnRo4oCmPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gTWFuZ2VyLCBKYW1lcyBIIFs8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50 ZWxzdHJhLmNvbSI+bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L2E+XSA8 YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDE4LCAyMDEyIDQ6NTkgQU08YnI+PGI+ VG86PC9iPiBNaWtlIEpvbmVzOyA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBp ZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbam9zZV0gV2hldGhlciBpbXBsZW1l bnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5kIGFsbCBKT1NFIGhlYWRlciBmaWVsZHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+TXkg Y29tbWVudHMgaW4gcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPkN1cnJl bnRseSB0aGUgSk9TRSBzcGVjcyBjb250YWluIHRoZSBmb2xsb3dpbmcgbGFuZ3VhZ2UgZGVjbGFy aW5nIHRoYXQgYWxsIGhlYWRlciAoYW5kIHNvbWUgb3RoZXIpIGZpZWxkcyBtdXN0IGJlIHVuZGVy c3Rvb2Q6Jm5ic3A7IOKAnEltcGxlbWVudGF0aW9ucyBNVVNUIHVuZGVyc3RhbmQgdGhlIGVudGly ZSBjb250ZW50cyBvZiB0aGUgaGVhZGVyOyBvdGhlcndpc2UsIHRoZSDigKYgTVVTVCBiZSByZWpl Y3RlZC7igJ0mbmJzcDsgVGhlcmUncyBjdXJyZW50bHkgYW4gb3BlbiBpc3N1ZSBhYm91dCB3aGV0 aGVyIGFsbCBoZWFkZXIgZmllbGRzIHNob3VsZCBiZSByZXF1aXJlZCB0byBiZSB1bmRlcnN0b29k IGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGVtIG9yIHdoZXRoZXIgdG8gcmVsYXggdGhpcyBy ZXF1aXJlbWVudCBpbiBzb21lIGNpcmN1bXN0YW5jZXMuJm5ic3A7IFdlIHdvdWxkIGxpa2UgdGhl IHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBwb3RlbnRpYWwgcmVzb2x1 dGlvbnMgdG8gdGhlIGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+MS4mbmJzcDsgTWFpbnRhaW4gdGhlIGN1 cnJlbnQgcmVxdWlyZW1lbnQgdGhhdCBhbGwgaGVhZGVyIGZpZWxkcyBtdXN0IGJlIHVuZGVyc3Rv b2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5QUk86Jm5ic3A7 IFRoaXMgaXMgYSBzaW1wbGUgcnVsZTxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz7igKY8bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+ SXQgaXMgbm90IGFzIHNpbXBsZSBhcyBpZ25vcmluZyB1bmtub3duIGZpZWxkcywgd2hpY2ggYWxs IGNvZGUgd2lsbCBkbyBuYXR1cmFsbHkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6cmVkJz5BcmUgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0g cnVsZXMgd2VsbCBkZWZpbmVkPyBPYnZpb3VzbHkgaWYgYSB0b3RhbGx5IHVua25vd24gZmllbGQg aXMgcHJlc2VudCB0aGUgSk9TRSBtZXNzYWdlIG11c3QgYmUgcmVqZWN0ZWQuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdj b2xvcjpyZWQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz5Ib3cgYWJvdXQgaWYgYSBkZWZp bmVkIGZpZWxkIGlzIGluIGFuIHVuZXhwZWN0ZWQgcGxhY2UsIGVnIOKAnHppcOKAnSBpbiBhIEpX RSBoZWFkZXI/IFByZXN1bWFibHkgdGhhdCBoYXMgdG8gYmUgcmVqZWN0ZWQgc28gaXQgaXMgbm90 IHN1ZmZpY2llbnQgZm9yIGNvZGUgdG8gY2hlY2sgYW55IEpPU0UgbWVzc2FnZXMgYWdhaW5zdCBv bmUgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQn PkhvdyBhYm91dCBhIEpXRSB3aXRoIGFuIOKAnGVwa+KAnSBmaWVsZCB3aGVuIOKAnGFsZ+KAnTri gJ1SU0EtT0FFUOKAnT8gUHJlc3VtYWJseSB0aGF0IGFsc28gaGFzIHRvIGJlIHJlamVjdGVkIHNv IGNoZWNraW5nIGFnYWluc3QgYSBzdGF0aWMgbGlzdCBvZiBKV0UgZmllbGRzIGlzIG5vdCBzdWZm aWNpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+ RG9lcyB0aGUgdHlwZSBvciB2YWx1ZSBvZiBhIGZpZWxkIG5lZWQgdG8gYmUgY2hlY2tlZCBpZiBh biBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQgbmVlZCB0byB1c2UgaXQ/IEZvciBleGFtcGxlLCBk b2VzIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgYWxyZWFkeSBoYXMgYSBnaXZlbiBjZXJ0IChzbyBp dCBkb2VzbuKAmXQgbmVlZCB0byB1c2UgYSDigJx4NXXigJ0gdmFsdWUpIG5lZWQgdG8gY29uZmly bSB0aGF0IHRoZSDigJx4NXXigJ0gdmFsdWUgaXMgYSBzdHJpbmcsIG9yIGlzIGEgdmFsaWQgVVJJ LCBvciBhY3R1YWxseSByZXNvbHZlcyB0byB0aGUgc2FtZSBjZXJ0PyBQcm9iYWJseSBub3QuIEkg YXNzdW1lIGl0IGlzIHN1ZmZpY2llbnQgdG8gdW5kZXJzdGFuZCB0aGF0IGEgZmllbGQgY2FuIGJl IGlnbm9yZWQsIHdpdGhvdXQgYWN0dWFsbHkgdW5kZXJzdGFuZGluZyBpdHMgYWN0dWFsIHN5bnRh eCBvciB2YWx1ZSBpcyBhIHNwZWNpZmljIG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPuKApjwvc3Bhbj48c3BhbiBsYW5nPUVO LVVTPmRlc2lnbmVkIHRvIHJlc3VsdCBpbiBzZWN1cmUgaW1wbGVtZW50YXRpb25zLjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+U2VjdXJlIGluIHdoYXQgd2F5PyBJcyB0aGlzIGFpbWVk IHNwZWNpZmljYWxseSBhdCBwcmV2ZW50aW5nIG5ldyBmaWVsZHMgYmVpbmcgaWdub3JlZCBpbiBj YXNlIHRoZXkgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgZXhpc3RpbmcgZmllbGRzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPlBSTzogTmV3IGZp ZWxkcyBhcmUgYWxsb3dlZCB0byBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBleGlzdGluZyBmaWVs ZHMgYmVjYXVzZSBpbXBsZW1lbnRhdGlvbnMgbm90IHVuZGVyc3RhbmRpbmcgdGhlIGNoYW5nZWQg c2VtYW50aWNzIHdpbGwgZmFpbC1zYWZlIGR1ZSB0byBzZWVpbmcgYW4gdW5rbm93biBmaWVsZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOnJlZCc+KG9yIGlzIHRoaXMgYSBDT04gZm9yIGVuY291cmFnaW5nIGRh bmdlcm91cyBleHRlbnNpb25zPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+4oCmPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+UmVwcmVzZW50 YXRpb25zIG9mIGV4aXN0aW5nIEpXUyAmYW1wOyBKV0Ugb2JqZWN0cyBhcmUgdW5jaGFuZ2VkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V Uz5DT046Jm5ic3A7IEV4dGVuc2liaWxpdHkgaXMgbGltaXRlZCB0byBjYXNlcyB3aGVyZSBhbGwg cGFydGljaXBhdGluZyBwYXJ0aWVzIHVuZGVyc3RhbmQgbmV3IGZpZWxkcyB0aGF0IGFyZSBpbnRy b2R1Y2VkLjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjpyZWQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz5DT046IEJlY2F1c2UgY29kZSBjYW4g c3VjY2Vzc2Z1bGx5IHByb2Nlc3MgSk9TRSBtZXNzYWdlIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRo ZSDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUgaXQgaXMgaGFyZCB0byBoYXZl IGNvbmZpZGVuY2UgdGhhdCBpdCBpcyBpbXBsZW1lbnRlZCAob3IgaW1wbGVtZW50ZWQgd2VsbCku PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+MkEuJm5ic3A7IFRha2UgYW4gYWx0 ZXJuYXRpdmUgYXBwcm9hY2ggd2hlcmUsIGJ5IGRlZmF1bHQsIGFsbCBmaWVsZHMgbXVzdCBiZSB1 bmRlcnN0b29kLCBidXQgd2hlcmUgYW4gZXhwbGljaXQgbGlzdCBvZiBmaWVsZHMgY2FuIGJlIGRl c2lnbmF0ZWQgYXMg4oCcbWF5IGJlIGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2TigJ0uJm5ic3A7 IEZvciBpbnN0YW5jZSwgYW4g4oCcaWdu4oCdIChtYXkgYmUgaWdub3JlZCkgbWVtYmVyIGNvdWxk IGJlIGRlZmluZWQgd2hvc2UgdmFsdWUgaXMgYW4gYXJyYXkgbGlzdGluZyB0aGUgbWVtYmVyIG5h bWVzIHRoYXQgbWF5IGJlIHNhZmVseSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29kLiZuYnNwOyBB biBleGFtcGxlIHVzaW5nIHRoaXMgZmllbGQgaW4gYSBKV1MgaGVhZGVyIGlzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsmcXVvdDthbGcmcXVvdDs6JnF1b3Q7RVMyNTYmcXVvdDss PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZ24mcXVvdDs6WyZxdW90O25vdGVz JnF1b3Q7XSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25vdGVzJnF1b3Q7OiZx dW90O1RoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBm dWxsJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4oT2J2aW91c2x5 LCB0aGUgJnF1b3Q7aWduJnF1b3Q7IGZpZWxkIE1VU1QgTk9UIGNvbnRhaW4gdGhlIHZhbHVlICZx dW90O2lnbiZxdW90Oy4pPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5QUk86Jm5ic3A7IFRoaXMgd291bGQgZW5hYmxl IGFkZGluZyBub24tY3JpdGljYWwgaGVhZGVyIGZpZWxkcyB3aXRob3V0IGJyZWFraW5nIGltcGxl bWVudGF0aW9ucy4mbmJzcDsgSXQgd291bGQgbWFpbnRhaW4gdGhlIGN1cnJlbnQgc2VtYW50aWNz LCB3aGlsZSBhbGxvd2luZyBleHBsaWNpdCBleGNlcHRpb25zIHRvIGJlIG1hZGUgaW4gY2FzZXMg d2hlcmUgdGhlIGZpZWxkcyBhcmUgbm90IHNlY3VyaXR5LWNyaXRpY2FsIGFuZCB0aGUgc3RydWN0 dXJlIGhhcyBhIG1lYW5pbmdmdWwgaW50ZXJwcmV0YXRpb24gd2l0aG91dCB0aGVtLiZuYnNwOyBS ZXByZXNlbnRhdGlvbnMgb2YgZXhpc3RpbmcgSldTICZhbXA7IEpXRSBvYmplY3RzIGFyZSB1bmNo YW5nZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTPkNPTjombmJzcDsgUmVxdWlyZXMgY29vcmRpbmF0aW9uIG9mIGZpZWxkIG5hbWVz IGFuZCBtYXktYmUtaWdub3JlZCBsaXN0LCBhZGRpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBjb21w bGV4aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVM+MkIuJm5ic3A7IFRha2UgYW4gYWx0ZXJuYXRpdmUgYXBwcm9h Y2ggd2hlcmUgaW5zdGVhZCBvZiBvbmUgaGVhZGVyIG9iamVjdCwgdGhlcmUgd291bGQgYmUgdHdv IGhlYWRlciBvYmplY3RzLiZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgcmVxdWlyZWQg dG8gdW5kZXJzdGFuZCBhbGwgZmllbGRzIGluIHRoZSBmaXJzdCBoZWFkZXIgb2JqZWN0LiZuYnNw OyBJbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgYWxsb3dlZCB0byBpZ25vcmUgZmllbGRzIGluIHRo ZSBzZWNvbmQgaGVhZGVyIG9iamVjdCBpZiBub3QgdW5kZXJzdG9vZC4mbmJzcDsgQW4gZXhhbXBs ZSBvZiB0aGlzIGFwcHJvYWNoLCBhZGRpbmcgdGhlIHNlY29uZCBoZWFkZXIgb2JqZWN0IGFmdGVy IHRoZSBmaXJzdCBpbiBhIEpXUywgd291bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsm bmJzcDsgZXlKMGVYQWlPaUpLVjFRaUxBMEtJQ0poYkdjaU9pSklVekkxTmlKOTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsm bmJzcDsmbmJzcDsgLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgZXlKdWIzUmxjeUk2SWxSb2FYTWdj MmxuYm1GMGRYSmxJRzVsWldRZ2JtOTBJR0psSUdOb1pXTnJaV1FnZDJobGJpQjBhR1VnYlc5dmJp QnBjeUJtZFd4c0luMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJz cDsgZXlKcGMzTWlPaUpxYjJVaUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRI QTZMeTlsZUdGdGNHeGxMbU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsm bmJzcDsgLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgZEJqZnRKZVo0Q1ZQLW1COTJLMjd1aGJVSlUx cDFyX3dXMWdGV0ZPRWpYazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+VGhlIGZpcnN0LCB0aGlyZCwgYW5kIGZvdXJ0 aCBmaWVsZHMgYXJlIGZyb20gdGhlIGV4YW1wbGUgSldTIGluIHRoZSBjdXJyZW50IHNwZWMuIFRo ZSBuZXcgc2Vjb25kIGZpZWxkIGlzIHRoZSBiYXNlNjR1cmwgZW5jb2RlZCByZXByZXNlbnRhdGlv biBvZiB0aGUgc3RyaW5nICd7JnF1b3Q7bm90ZXMmcXVvdDs6JnF1b3Q7VGhpcyBzaWduYXR1cmUg bmVlZCBub3QgYmUgY2hlY2tlZCB3aGVuIHRoZSBtb29uIGlzIGZ1bGwmcXVvdDt9Jy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTPlBSTzombmJzcDsgTWF5LWJlLWlnbm9yZWQgZmllbGRzIGFyZSBlYXNpbHkgZGlzdGlu Z3Vpc2hhYmxlIGZyb20gbXVzdC1iZS11bmRlcnN0b29kIGZpZWxkcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+Q09OOiZuYnNwOyBJ bXBsZW1lbnRhdGlvbnMgbXVzdCBjb25zdWx0L21lcmdlIHR3byBzZXRzIG9mIGhlYWRlcnMgdG8g dW5kZXJzdGFuZCB0aGUgbWVhbmluZy9zdHJ1Y3R1cmUgb2YgdGhlIG9iamVjdCwgYWRkaW5nIHNv bWUgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS4mbmJzcDsgRXhpc3RpbmcgSldTICZhbXA7IEpX RSBvYmplY3QgcmVwcmVzZW50YXRpb25zIHdvdWxkIGJlY29tZSBpbnZhbGlkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjMuIEhhdmUgYSBmaWVs ZCB0aGF0IGluZGljYXRlcyB0aGUgc2VtYW50aWNzIG9mIHRoZSBKT1NFIG1lc3NhZ2UuIEZvciBp bnN0YW5jZSB0aGUgZmllbGQgY291bGQgYmUgY2FsbGVkIOKAnCHigJ0gYW5kIGRlZmluZWQgdmFs dWVzIGNvdWxkIGJlIOKAnHNpZ+KAnSwg4oCcbWFj4oCdLCDigJxlbmPigJ3igKYgZm9yIHNpZ25l ZC13aXRoLWFuLWFzeW1tZXRyaWMta2V5LCBNQUNlZC13aXRoLWEtc2hhcmVkLXNlY3JldCwgZW5j cnlwdGVkLShBRUFEKS13aXRoLXNoYXJlZC1zZWNyZXTigKYuIFRoZSBkZWZpbml0aW9uIG9mIGEg dmFsdWUgZm9yIHRoZSDigJwh4oCdIGZpZWxkIGluZGljYXRlcyB0aGUgb3RoZXIgZmllbGRzIGl0 IHVzZXMuIFJlY2lwaWVudHMgTVVTVCBpZ25vcmUgYW55IHVucmVjb2duaXplZCBmaWVsZHMuIE9y aWdpbmF0b3JzIGFkZGluZyBhIG5ldyBmaWVsZCB0aGF0IGNoYW5nZXMgdGhlIHNlbWFudGljcyBv ZiBhIG1lc3NhZ2UgTVVTVCB1c2UgYSBuZXcgdmFsdWUgZm9yIHRoZSDigJwh4oCdIGZpZWxkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6cmVkJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+UFJPOiBDb2Rl IHdpbGwgaW1wbGVtZW50IHRoaXMgcnVsZSBuYXR1cmFsbHksIHNpbXBseSBieSBzd2l0Y2hpbmcg b24gdGhlIOKAnCHigJ0gZmllbGQgdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6cmVkJz5QUk86IEl0IGlzIGV4dGVuc2libGUuIEV4dHJhIGZpZWxkcyBj YW4gYmUgZGVmaW5lZCBhbmQgZGVwbG95ZWQgd2l0aG91dCByZXF1aXJpbmcgb3JpZ2luYXRvcnMg YW5kIHJlY2lwaWVudHMgdG8gYmUgdXBncmFkZWQgc2ltdWx0YW5lb3VzbHkuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdj b2xvcjpyZWQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz5DT046IEFyYml0cmFyeSBleHRy YSBkYXRhIG9mIGEgb3JpZ2luYXRvcuKAmXMgY2hvb3NpbmcgY2FuIGJlIGluY2x1ZGVkIGFzIHVu a25vd24gZmllbGRzIGluIG1lc3NhZ2VzIHRoYXQgcmVjaXBpZW50cyB3aWxsIGFjY2VwdC4gVGhv dWdoIHRoaXMgaXMgdHJ1ZSBldmVuIHdpdGggYSDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN0 4oCdIHJ1bGUgKGVnIHdoaXRlc3BhY2UgaW4gdGhlIEpTT04gaGVhZGVyLCBqdW5rIGluIGEg4oCc eDV14oCdIFVSSSBmcmFnbWVudOKApikuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5BZnRlciBhIGRpc2N1c3Npb24gcGVy aW9kLCB3ZSBiZWxpZXZlIHRoYXQgaXQgd291bGQgYmUgdXNlZnVsIGZvciB0aGUgY2hhaXJzIHRv IG1ha2UgdHdvIGZvcm1hbCBjb25zZW5zdXMgY2FsbHMgb2YgdGhlIGZvbGxvd2luZyBraW5kOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVM+RklSU1QgUE9MTDombmJzcDsgU2hvdWxkIGFsbCBoZWFkZXIgZmllbGRzIGJl IGNyaXRpY2FsIGZvciBpbXBsZW1lbnRhdGlvbnMgdG8gdW5kZXJzdGFuZD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+WUVTIOKAkyBB bGwgaGVhZGVyIGZpZWxkcyBtdXN0IGNvbnRpbnVlIHRvIGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVt ZW50YXRpb25zIG9yIHRoZSBpbnB1dCBtdXN0IGJlIHJlamVjdGVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5OTyDigJMgQSBtZWFu cyBvZiBsaXN0aW5nIHRoYXQgc3BlY2lmaWMgaGVhZGVyIGZpZWxkcyBtYXkgYmUgc2FmZWx5IGln bm9yZWQgc2hvdWxkIGJlIGRlZmluZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOnJlZCc+QUxURVJOQVRJVkUgRklSU1QgUE9MTCBGT1IgRVhJU1RJTkcg SU1QTEVNRU5UT1JTOiBIYXZlIHlvdSBpbXBsZW1lbnRlZCB0aGUg4oCcTVVTVCB1bmRlcnN0YW5k IG9yIHJlamVjdOKAnSBydWxlPyBXaGljaCBzaXR1YXRpb25zIGRvIHlvdSByZWplY3QgKGVnIOKA nGZvb+KAnTsg4oCcemlw4oCdIGluIEpXUzsg4oCcZXBr4oCdIHdoZW4g4oCcYWxn4oCdOuKAnVJT QS1PQUVQ4oCdOyDigJxqa3XigJ06Jmx0O25vbi1zdHJpbmcmZ3Q7OyDigJxqa3XigJ064oCdJmx0 O2ludmFsaWQgVVJJJmd0O+KAnTsg4oCmPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdjb2xvcjpyZWQnPkFMVEVSTkFUSVZFIFNFQ09ORCBQT0xMOiBIb3cgcmVhbCBp cyB0aGUgcmlzayB0aGF0IGZ1dHVyZSBncm91cHMgd2lsbCBkZWxpYmVyYXRlbHkgZGVzaWduICZh bXA7IGRlcGxveSBuZXcgZmllbGRzIHRoYXQgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgSk9TRSBt ZXNzYWdlcyBkZXBlbmRpbmcgb24gd2hldGhlciBvciBub3QgdGhlIG5ldyBmaWVsZCBpcyB1bmRl cnN0b29kLCB3aXRob3V0IHJlYWxpemluZyB0aGUgc2VjdXJpdHkgY29uc2VxdWVuY2VzPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpyZWQnPkFMVEVSTkFU SVZFIFRISVJEIFBPTEw6IElzIEpPU0Ugc28gY29tcGxldGUgYW5kIHN0YWJsZSB0aGF0IGV4dGVu c2lvbnMgYXJlIHVubGlrZWx5IHRvIGJlIG5lZWRlZD88L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+ U0VDT05EIFBPTEw6Jm5ic3A7IFNob3VsZCB0aGUgcmVzdWx0IG9mIHRoZSBmaXJzdCBwb2xsIGJl ICZxdW90O05PJnF1b3Q7LCB3aGljaCBzeW50YXggd291bGQgeW91IHByZWZlciBmb3IgZGVzaWdu YXRpbmcgdGhlIGhlYWRlciBmaWVsZHMgdGhhdCBtYXkgYmUgaWdub3JlZCBpZiBub3QgdW5kZXJz dG9vZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxh bmc9RU4tVVM+QSDigJMgRGVmaW5lIGEgaGVhZGVyIGZpZWxkIHRoYXQgZXhwbGljaXRseSBsaXN0 cyB0aGUgZmllbGRzIHRoYXQgbWF5IGJlIHNhZmVseSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29k LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUz5CIOKAkyBJbnRyb2R1Y2UgYSBzZWNvbmQgaGVhZGVyLCB3aGVyZSBpbXBsZW1lbnRhdGlv bnMgbXVzdCB1bmRlcnN0YW5kIGFsbCBmaWVsZHMgaW4gdGhlIGZpcnN0IGJ1dCB0aGV5IG1heSBp Z25vcmUgbm90LXVuZGVyc3Rvb2QgZmllbGRzIGluIHRoZSBzZWNvbmQuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhh bmtzIGZvciBjb25zaWRlcmluZyB0aGVzZSBxdWVzdGlvbnMsPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSaWNoYXJkIEJhcm5lcywgSm9o biBCcmFkbGV5LCBNaWtlIEpvbmVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz4tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nY29sb3I6cmVkJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E115040898B5WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Tue Dec 18 15:23:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4105821F85FC for ; Tue, 18 Dec 2012 15:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stu3+jxKEM6N for ; Tue, 18 Dec 2012 15:23:27 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAEF1F0CB2 for ; Tue, 18 Dec 2012 15:23:23 -0800 (PST) Received: from mail62-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Dec 2012 23:23:21 +0000 Received: from mail62-am1 (localhost [127.0.0.1]) by mail62-am1-R.bigfish.com (Postfix) with ESMTP id A9FB4160104; Tue, 18 Dec 2012 23:23:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic89bh148cIc857hzz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail62-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail62-am1 (localhost.localdomain [127.0.0.1]) by mail62-am1 (MessageSwitch) id 1355872998329633_27333; Tue, 18 Dec 2012 23:23:18 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.251]) by mail62-am1.bigfish.com (Postfix) with ESMTP id 44500120070; Tue, 18 Dec 2012 23:23:18 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Dec 2012 23:23:17 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 18 Dec 2012 23:23:03 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRA= Date: Tue, 18 Dec 2012 23:23:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115040898B5@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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436696ABC0TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:23:29 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436696ABC0TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIGJlbGlldmUgdGhlIHNwZWMgd29yZGluZyBkb2VzIGZvcmJpZCDigJx6aXDigJ0gaW4g YSBKV1MsIGJlY2F1c2UgaXTigJlzIG5vdCBhIGZpZWxkIHdpdGggYSBkZWZpbmVkIG1lYW5pbmcg aW4gdGhhdCBjb250ZXh0IOKAkyBqdXN0IGFzIOKAnGVwa+KAnSBoYXMgbm8gZGVmaW5lZCBtZWFu aW5nIHdpdGgg4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdLiAgSSBhZ3JlZSB0aGF0IG1vcmUgZXhw bGljaXQgd29yZGluZyB0byB0aGF0IGVmZmVjdCBjYW4gYW5kIHByb2JhYmx5IHNob3VsZCBiZSBh ZGRlZC4gIElmIHlvdeKAmWQgbGlrZSB0byBzdWdnZXN0IHNvbWUsIHBsZWFzZSBoYXZlIGF0IGl0 Lg0KDQpPbmUgd291bGQgZGVmaW5lIOKAnHppcOKAnSBpbiBhIEpXUyBpbiB0aGUgbm9ybWFsIHdh eSB0aGF0IGV4dGVuc2lvbnMgYXJlIG1hZGUgdG8gSUVURiBzcGVjcyDigJMgeW914oCZZCB3cml0 ZSBhIHNwZWMgZGVmaW5pbmcgdGhlIG1lYW5pbmcgZm9yIGl0IGFuZCByZWdpc3RlciB0aGUg4oCc emlw4oCdIHZhbHVlIGluIHRoZSBJQU5BIEpTT04gV2ViIFNpZ25hdHVyZSBhbmQgRW5jcnlwdGlv biBIZWFkZXIgUGFyYW1ldGVycyByZWdpc3RyeSBmb3IgSldTIHVzYWdlLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVz dCB3aXNoZXMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0 bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1i ZXIgMTgsIDIwMTIgMjo0MiBQTQ0KVG86IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJFOiBbam9zZV0gV2hldGhlciBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5kIGFs bCBKT1NFIGhlYWRlciBmaWVsZHMNCg0KTWlrZSwNCg0KQ291bGQgeW91IGF0IGxlYXN0IGV4cGFu ZCBhIGJpdCBvbiBob3cgeW91IGV4cGVjdCBhIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3Ti gJ0gcnVsZSB3aWxsIHdvcmsgaW4gcHJhY3RpY2U/DQpGb3IgaW5zdGFuY2UsIGRvZXMgdGhlIHNw ZWMgd29yZGluZyBmb3JiaWQg4oCcemlw4oCdIGluIGEgSldTPyDigJxlcGvigJ0gd2hlbiDigJxh bGfigJ064oCdUlNBLU9BRVDigJ0/IOKAnHg1deKAnTo3PyDigJx4NXXigJ064oCdaGVsbG8gd29y bGTigJ0/IFdpbGwgaW1wbGVtZW50YXRpb25zIGJlIGNvbnNpc3RlbnQ/DQoNClBlcmhhcHMgeW91 IGhhdmUgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcyBydWxlIGFscmVhZHkgYW5kIGNhbiB0ZWxs IHVzIHdoYXQgaXQgZG9lcz8NCg0KSSB3b3VsZCBhbHNvIGFwcHJlY2lhdGUgeW91ciB0aG91Z2h0 cyBvbiB3aGV0aGVyIHNvbWVvbmUgY2FuIGV4dGVuZCBKV1MgYnkgc3BlY2lmeWluZzogd2hlbiB0 aGUg4oCcemlw4oCdIGZpZWxkIGlzIHByZXNlbnQgaW4gYSBKV1MgdGhlIGNvbnRlbnQgaXMgY29t cHJlc3NlZC4NClRoYXQgbG9va3MgbGVnaXRpbWF0ZSB3aXRoIHRoZSBjdXJyZW50IOKAnE1VU1Qg dW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZS4gSSB0aGluayBpdCBpcyBsaWtlbHksIGhvd2V2 ZXIsIHRoYXQgc3VjaCBhbiBleHRlbnNpb24gd2lsbCBjYXVzZSBzZWN1cml0eSBwcm9ibGVtcy4g U29tZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBjb25maXJtIHRoYXQg4oCcemlw4oCdIGlzIG9uIHRo ZSBsaXN0IG9mIGtub3duIHN0YW5kYXJkIGZpZWxkcywgYnV0IHdpbGwgaWdub3JlIGl0IGluIHRo ZSBKV1MgcHJvY2Vzc2luZyBjb2RlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IE1pa2Ug Sm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dDQpTZW50OiBXZWRuZXNk YXksIDE5IERlY2VtYmVyIDIwMTIgOTowNCBBTQ0KVG86IE1hbmdlciwgSmFtZXMgSDsgam9zZUBp ZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbam9zZV0gV2hldGhl ciBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5kIGFsbCBKT1NFIGhlYWRlciBmaWVsZHMN Cg0KSGkgSmFtZXMsDQoNClBlciB0aGUgcmVzcG9uc2UgSSBqdXN0IHNlbnQgdG8gQXhlbCwgd2hl biB3ZSBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBpbiB0aGUgcGFzdCwgb25seSBvbmUgcGVyc29uIHdh cyBpbiBmYXZvciBvZiBhIG11c3QtaWdub3JlLWJ5LWRlZmF1bHQgYmVoYXZpb3IsIGFuZCB5ZXQg dGhhdOKAmXMgd2hhdCB5b3XigJlyZSBhZHZvY2F0aW5nIGJlbG93LiAgU2VlIGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDEyMTYuaHRtbC4gIE9m IGNvdXJzZSwgaXTigJlzIGFsd2F5cyBwb3NzaWJsZSB5b3UgY291bGQgY2hhbmdlIG1pbmRzLCBi dXQgSSBzdXNwZWN0IHRoYXQgaWYgeW91IHdhbnQgdG8gaW5mbHVlbmNlIHRoZSBvdXRjb21lIG9m IHRoaXMgaXNzdWUsIHRoZSBoaWdoZXN0LXBheW9mZiBzdHJhdGVneSB3b3VsZCBiZSB0byBkaXNj dXNzIHN5bnRheCBvcHRpb25zIHRoYXQgcmVxdWlyZSBwZW9wbGUgdG8gdGFrZSBzcGVjaWFsIGFj dGlvbiB0byBpZ25vcmUgYSBub3QtdW5kZXJzdG9vZCBmaWVsZCwgcmF0aGVyIHRoYW4gdGhlIG90 aGVyIHdheSBhcm91bmQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBNeSB0d28gY2VudHMgd29ydGjigKYNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRl YW0udGVsc3RyYS5jb21dDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxOCwgMjAxMiA0OjU5IEFN DQpUbzogTWlrZSBKb25lczsgam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJFOiBbam9zZV0gV2hldGhlciBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5k IGFsbCBKT1NFIGhlYWRlciBmaWVsZHMNCg0KDQpNeSBjb21tZW50cyBpbiByZWQuDQoNCg0KDQpD dXJyZW50bHkgdGhlIEpPU0Ugc3BlY3MgY29udGFpbiB0aGUgZm9sbG93aW5nIGxhbmd1YWdlIGRl Y2xhcmluZyB0aGF0IGFsbCBoZWFkZXIgKGFuZCBzb21lIG90aGVyKSBmaWVsZHMgbXVzdCBiZSB1 bmRlcnN0b29kOiAg4oCcSW1wbGVtZW50YXRpb25zIE1VU1QgdW5kZXJzdGFuZCB0aGUgZW50aXJl IGNvbnRlbnRzIG9mIHRoZSBoZWFkZXI7IG90aGVyd2lzZSwgdGhlIOKApiBNVVNUIGJlIHJlamVj dGVkLuKAnSAgVGhlcmUncyBjdXJyZW50bHkgYW4gb3BlbiBpc3N1ZSBhYm91dCB3aGV0aGVyIGFs bCBoZWFkZXIgZmllbGRzIHNob3VsZCBiZSByZXF1aXJlZCB0byBiZSB1bmRlcnN0b29kIGJ5IGlt cGxlbWVudGF0aW9ucyB1c2luZyB0aGVtIG9yIHdoZXRoZXIgdG8gcmVsYXggdGhpcyByZXF1aXJl bWVudCBpbiBzb21lIGNpcmN1bXN0YW5jZXMuICBXZSB3b3VsZCBsaWtlIHRoZSB3b3JraW5nIGdy b3VwIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgcG90ZW50aWFsIHJlc29sdXRpb25zIHRvIHRo ZSBpc3N1ZS4NCg0KDQoNCjEuICBNYWludGFpbiB0aGUgY3VycmVudCByZXF1aXJlbWVudCB0aGF0 IGFsbCBoZWFkZXIgZmllbGRzIG11c3QgYmUgdW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMg dXNpbmcgdGhlbS4NCg0KDQoNClBSTzogIFRoaXMgaXMgYSBzaW1wbGUgcnVsZeKApg0KDQoNCg0K SXQgaXMgbm90IGFzIHNpbXBsZSBhcyBpZ25vcmluZyB1bmtub3duIGZpZWxkcywgd2hpY2ggYWxs IGNvZGUgd2lsbCBkbyBuYXR1cmFsbHkuDQoNCg0KDQpBcmUgdGhlIOKAnE1VU1QgdW5kZXJzdGFu ZCBvciByZWplY3TigJ0gcnVsZXMgd2VsbCBkZWZpbmVkPyBPYnZpb3VzbHkgaWYgYSB0b3RhbGx5 IHVua25vd24gZmllbGQgaXMgcHJlc2VudCB0aGUgSk9TRSBtZXNzYWdlIG11c3QgYmUgcmVqZWN0 ZWQuDQoNCg0KDQpIb3cgYWJvdXQgaWYgYSBkZWZpbmVkIGZpZWxkIGlzIGluIGFuIHVuZXhwZWN0 ZWQgcGxhY2UsIGVnIOKAnHppcOKAnSBpbiBhIEpXRSBoZWFkZXI/IFByZXN1bWFibHkgdGhhdCBo YXMgdG8gYmUgcmVqZWN0ZWQgc28gaXQgaXMgbm90IHN1ZmZpY2llbnQgZm9yIGNvZGUgdG8gY2hl Y2sgYW55IEpPU0UgbWVzc2FnZXMgYWdhaW5zdCBvbmUgbGlzdC4NCg0KDQoNCkhvdyBhYm91dCBh IEpXRSB3aXRoIGFuIOKAnGVwa+KAnSBmaWVsZCB3aGVuIOKAnGFsZ+KAnTrigJ1SU0EtT0FFUOKA nT8gUHJlc3VtYWJseSB0aGF0IGFsc28gaGFzIHRvIGJlIHJlamVjdGVkIHNvIGNoZWNraW5nIGFn YWluc3QgYSBzdGF0aWMgbGlzdCBvZiBKV0UgZmllbGRzIGlzIG5vdCBzdWZmaWNpZW50Lg0KDQoN Cg0KRG9lcyB0aGUgdHlwZSBvciB2YWx1ZSBvZiBhIGZpZWxkIG5lZWQgdG8gYmUgY2hlY2tlZCBp ZiBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQgbmVlZCB0byB1c2UgaXQ/IEZvciBleGFtcGxl LCBkb2VzIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgYWxyZWFkeSBoYXMgYSBnaXZlbiBjZXJ0IChz byBpdCBkb2VzbuKAmXQgbmVlZCB0byB1c2UgYSDigJx4NXXigJ0gdmFsdWUpIG5lZWQgdG8gY29u ZmlybSB0aGF0IHRoZSDigJx4NXXigJ0gdmFsdWUgaXMgYSBzdHJpbmcsIG9yIGlzIGEgdmFsaWQg VVJJLCBvciBhY3R1YWxseSByZXNvbHZlcyB0byB0aGUgc2FtZSBjZXJ0PyBQcm9iYWJseSBub3Qu IEkgYXNzdW1lIGl0IGlzIHN1ZmZpY2llbnQgdG8gdW5kZXJzdGFuZCB0aGF0IGEgZmllbGQgY2Fu IGJlIGlnbm9yZWQsIHdpdGhvdXQgYWN0dWFsbHkgdW5kZXJzdGFuZGluZyBpdHMgYWN0dWFsIHN5 bnRheCBvciB2YWx1ZSBpcyBhIHNwZWNpZmljIG1lc3NhZ2UuDQoNCg0KDQrigKZkZXNpZ25lZCB0 byByZXN1bHQgaW4gc2VjdXJlIGltcGxlbWVudGF0aW9ucy4NCg0KDQoNClNlY3VyZSBpbiB3aGF0 IHdheT8gSXMgdGhpcyBhaW1lZCBzcGVjaWZpY2FsbHkgYXQgcHJldmVudGluZyBuZXcgZmllbGRz IGJlaW5nIGlnbm9yZWQgaW4gY2FzZSB0aGV5IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIGV4aXN0 aW5nIGZpZWxkcz8NCg0KDQoNClBSTzogTmV3IGZpZWxkcyBhcmUgYWxsb3dlZCB0byBjaGFuZ2Ug dGhlIHNlbWFudGljcyBvZiBleGlzdGluZyBmaWVsZHMgYmVjYXVzZSBpbXBsZW1lbnRhdGlvbnMg bm90IHVuZGVyc3RhbmRpbmcgdGhlIGNoYW5nZWQgc2VtYW50aWNzIHdpbGwgZmFpbC1zYWZlIGR1 ZSB0byBzZWVpbmcgYW4gdW5rbm93biBmaWVsZC4NCg0KKG9yIGlzIHRoaXMgYSBDT04gZm9yIGVu Y291cmFnaW5nIGRhbmdlcm91cyBleHRlbnNpb25zPykNCg0KDQoNCuKAplJlcHJlc2VudGF0aW9u cyBvZiBleGlzdGluZyBKV1MgJiBKV0Ugb2JqZWN0cyBhcmUgdW5jaGFuZ2VkLg0KDQpDT046ICBF eHRlbnNpYmlsaXR5IGlzIGxpbWl0ZWQgdG8gY2FzZXMgd2hlcmUgYWxsIHBhcnRpY2lwYXRpbmcg cGFydGllcyB1bmRlcnN0YW5kIG5ldyBmaWVsZHMgdGhhdCBhcmUgaW50cm9kdWNlZC4NCg0KDQoN CkNPTjogQmVjYXVzZSBjb2RlIGNhbiBzdWNjZXNzZnVsbHkgcHJvY2VzcyBKT1NFIG1lc3NhZ2Ug d2l0aG91dCBpbXBsZW1lbnRpbmcgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0g cnVsZSBpdCBpcyBoYXJkIHRvIGhhdmUgY29uZmlkZW5jZSB0aGF0IGl0IGlzIGltcGxlbWVudGVk IChvciBpbXBsZW1lbnRlZCB3ZWxsKS4NCg0KDQoNCjJBLiAgVGFrZSBhbiBhbHRlcm5hdGl2ZSBh cHByb2FjaCB3aGVyZSwgYnkgZGVmYXVsdCwgYWxsIGZpZWxkcyBtdXN0IGJlIHVuZGVyc3Rvb2Qs IGJ1dCB3aGVyZSBhbiBleHBsaWNpdCBsaXN0IG9mIGZpZWxkcyBjYW4gYmUgZGVzaWduYXRlZCBh cyDigJxtYXkgYmUgaWdub3JlZCBpZiBub3QgdW5kZXJzdG9vZOKAnS4gIEZvciBpbnN0YW5jZSwg YW4g4oCcaWdu4oCdIChtYXkgYmUgaWdub3JlZCkgbWVtYmVyIGNvdWxkIGJlIGRlZmluZWQgd2hv c2UgdmFsdWUgaXMgYW4gYXJyYXkgbGlzdGluZyB0aGUgbWVtYmVyIG5hbWVzIHRoYXQgbWF5IGJl IHNhZmVseSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29kLiAgQW4gZXhhbXBsZSB1c2luZyB0aGlz IGZpZWxkIGluIGEgSldTIGhlYWRlciBpczoNCg0KDQoNCiAgICB7ImFsZyI6IkVTMjU2IiwNCg0K ICAgICAiaWduIjpbIm5vdGVzIl0sDQoNCiAgICAgIm5vdGVzIjoiVGhpcyBzaWduYXR1cmUgbmVl ZCBub3QgYmUgY2hlY2tlZCB3aGVuIHRoZSBtb29uIGlzIGZ1bGwiDQoNCiAgICB9DQoNCg0KDQoo T2J2aW91c2x5LCB0aGUgImlnbiIgZmllbGQgTVVTVCBOT1QgY29udGFpbiB0aGUgdmFsdWUgImln biIuKQ0KDQoNCg0KUFJPOiAgVGhpcyB3b3VsZCBlbmFibGUgYWRkaW5nIG5vbi1jcml0aWNhbCBo ZWFkZXIgZmllbGRzIHdpdGhvdXQgYnJlYWtpbmcgaW1wbGVtZW50YXRpb25zLiAgSXQgd291bGQg bWFpbnRhaW4gdGhlIGN1cnJlbnQgc2VtYW50aWNzLCB3aGlsZSBhbGxvd2luZyBleHBsaWNpdCBl eGNlcHRpb25zIHRvIGJlIG1hZGUgaW4gY2FzZXMgd2hlcmUgdGhlIGZpZWxkcyBhcmUgbm90IHNl Y3VyaXR5LWNyaXRpY2FsIGFuZCB0aGUgc3RydWN0dXJlIGhhcyBhIG1lYW5pbmdmdWwgaW50ZXJw cmV0YXRpb24gd2l0aG91dCB0aGVtLiAgUmVwcmVzZW50YXRpb25zIG9mIGV4aXN0aW5nIEpXUyAm IEpXRSBvYmplY3RzIGFyZSB1bmNoYW5nZWQuDQoNCkNPTjogIFJlcXVpcmVzIGNvb3JkaW5hdGlv biBvZiBmaWVsZCBuYW1lcyBhbmQgbWF5LWJlLWlnbm9yZWQgbGlzdCwgYWRkaW5nIHNvbWUgaW1w bGVtZW50YXRpb24gY29tcGxleGl0eS4NCg0KDQoNCjJCLiAgVGFrZSBhbiBhbHRlcm5hdGl2ZSBh cHByb2FjaCB3aGVyZSBpbnN0ZWFkIG9mIG9uZSBoZWFkZXIgb2JqZWN0LCB0aGVyZSB3b3VsZCBi ZSB0d28gaGVhZGVyIG9iamVjdHMuICBJbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgcmVxdWlyZWQg dG8gdW5kZXJzdGFuZCBhbGwgZmllbGRzIGluIHRoZSBmaXJzdCBoZWFkZXIgb2JqZWN0LiAgSW1w bGVtZW50YXRpb25zIHdvdWxkIGJlIGFsbG93ZWQgdG8gaWdub3JlIGZpZWxkcyBpbiB0aGUgc2Vj b25kIGhlYWRlciBvYmplY3QgaWYgbm90IHVuZGVyc3Rvb2QuICBBbiBleGFtcGxlIG9mIHRoaXMg YXBwcm9hY2gsIGFkZGluZyB0aGUgc2Vjb25kIGhlYWRlciBvYmplY3QgYWZ0ZXIgdGhlIGZpcnN0 IGluIGEgSldTLCB3b3VsZCBiZToNCg0KDQoNCiAgICBleUowZVhBaU9pSktWMVFpTEEwS0lDSmhi R2NpT2lKSVV6STFOaUo5DQoNCiAgICAuDQoNCiAgICBleUp1YjNSbGN5STZJbFJvYVhNZ2MybG5i bUYwZFhKbElHNWxaV1FnYm05MElHSmxJR05vWldOclpXUWdkMmhsYmlCMGFHVWdiVzl2YmlCcGN5 Qm1kV3hzSW4wDQoNCiAgICAuDQoNCiAgICBleUpwYzNNaU9pSnFiMlVpTEEwS0lDSmxlSEFpT2pF ek1EQTRNVGt6T0RBc0RRb2dJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlwYzE5eWIyOTBJanAw Y25WbGZRDQoNCiAgICAuDQoNCiAgICBkQmpmdEplWjRDVlAtbUI5MksyN3VoYlVKVTFwMXJfd1cx Z0ZXRk9FalhrDQoNCg0KDQpUaGUgZmlyc3QsIHRoaXJkLCBhbmQgZm91cnRoIGZpZWxkcyBhcmUg ZnJvbSB0aGUgZXhhbXBsZSBKV1MgaW4gdGhlIGN1cnJlbnQgc3BlYy4gVGhlIG5ldyBzZWNvbmQg ZmllbGQgaXMgdGhlIGJhc2U2NHVybCBlbmNvZGVkIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBzdHJp bmcgJ3sibm90ZXMiOiJUaGlzIHNpZ25hdHVyZSBuZWVkIG5vdCBiZSBjaGVja2VkIHdoZW4gdGhl IG1vb24gaXMgZnVsbCJ9Jy4NCg0KDQoNClBSTzogIE1heS1iZS1pZ25vcmVkIGZpZWxkcyBhcmUg ZWFzaWx5IGRpc3Rpbmd1aXNoYWJsZSBmcm9tIG11c3QtYmUtdW5kZXJzdG9vZCBmaWVsZHMuDQoN CkNPTjogIEltcGxlbWVudGF0aW9ucyBtdXN0IGNvbnN1bHQvbWVyZ2UgdHdvIHNldHMgb2YgaGVh ZGVycyB0byB1bmRlcnN0YW5kIHRoZSBtZWFuaW5nL3N0cnVjdHVyZSBvZiB0aGUgb2JqZWN0LCBh ZGRpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LiAgRXhpc3RpbmcgSldTICYgSldF IG9iamVjdCByZXByZXNlbnRhdGlvbnMgd291bGQgYmVjb21lIGludmFsaWQuDQoNCg0KDQozLiBI YXZlIGEgZmllbGQgdGhhdCBpbmRpY2F0ZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgSk9TRSBtZXNz YWdlLiBGb3IgaW5zdGFuY2UgdGhlIGZpZWxkIGNvdWxkIGJlIGNhbGxlZCDigJwh4oCdIGFuZCBk ZWZpbmVkIHZhbHVlcyBjb3VsZCBiZSDigJxzaWfigJ0sIOKAnG1hY+KAnSwg4oCcZW5j4oCd4oCm IGZvciBzaWduZWQtd2l0aC1hbi1hc3ltbWV0cmljLWtleSwgTUFDZWQtd2l0aC1hLXNoYXJlZC1z ZWNyZXQsIGVuY3J5cHRlZC0oQUVBRCktd2l0aC1zaGFyZWQtc2VjcmV04oCmLiBUaGUgZGVmaW5p dGlvbiBvZiBhIHZhbHVlIGZvciB0aGUg4oCcIeKAnSBmaWVsZCBpbmRpY2F0ZXMgdGhlIG90aGVy IGZpZWxkcyBpdCB1c2VzLiBSZWNpcGllbnRzIE1VU1QgaWdub3JlIGFueSB1bnJlY29nbml6ZWQg ZmllbGRzLiBPcmlnaW5hdG9ycyBhZGRpbmcgYSBuZXcgZmllbGQgdGhhdCBjaGFuZ2VzIHRoZSBz ZW1hbnRpY3Mgb2YgYSBtZXNzYWdlIE1VU1QgdXNlIGEgbmV3IHZhbHVlIGZvciB0aGUg4oCcIeKA nSBmaWVsZC4NCg0KDQoNClBSTzogQ29kZSB3aWxsIGltcGxlbWVudCB0aGlzIHJ1bGUgbmF0dXJh bGx5LCBzaW1wbHkgYnkgc3dpdGNoaW5nIG9uIHRoZSDigJwh4oCdIGZpZWxkIHZhbHVlLg0KDQoN Cg0KUFJPOiBJdCBpcyBleHRlbnNpYmxlLiBFeHRyYSBmaWVsZHMgY2FuIGJlIGRlZmluZWQgYW5k IGRlcGxveWVkIHdpdGhvdXQgcmVxdWlyaW5nIG9yaWdpbmF0b3JzIGFuZCByZWNpcGllbnRzIHRv IGJlIHVwZ3JhZGVkIHNpbXVsdGFuZW91c2x5Lg0KDQoNCg0KQ09OOiBBcmJpdHJhcnkgZXh0cmEg ZGF0YSBvZiBhIG9yaWdpbmF0b3LigJlzIGNob29zaW5nIGNhbiBiZSBpbmNsdWRlZCBhcyB1bmtu b3duIGZpZWxkcyBpbiBtZXNzYWdlcyB0aGF0IHJlY2lwaWVudHMgd2lsbCBhY2NlcHQuIFRob3Vn aCB0aGlzIGlzIHRydWUgZXZlbiB3aXRoIGEg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKA nSBydWxlIChlZyB3aGl0ZXNwYWNlIGluIHRoZSBKU09OIGhlYWRlciwganVuayBpbiBhIOKAnHg1 deKAnSBVUkkgZnJhZ21lbnTigKYpLg0KDQoNCg0KDQoNCkFmdGVyIGEgZGlzY3Vzc2lvbiBwZXJp b2QsIHdlIGJlbGlldmUgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIHRoZSBjaGFpcnMgdG8g bWFrZSB0d28gZm9ybWFsIGNvbnNlbnN1cyBjYWxscyBvZiB0aGUgZm9sbG93aW5nIGtpbmQ6DQoN Cg0KDQpGSVJTVCBQT0xMOiAgU2hvdWxkIGFsbCBoZWFkZXIgZmllbGRzIGJlIGNyaXRpY2FsIGZv ciBpbXBsZW1lbnRhdGlvbnMgdG8gdW5kZXJzdGFuZD8NCg0KWUVTIOKAkyBBbGwgaGVhZGVyIGZp ZWxkcyBtdXN0IGNvbnRpbnVlIHRvIGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIG9y IHRoZSBpbnB1dCBtdXN0IGJlIHJlamVjdGVkLg0KDQpOTyDigJMgQSBtZWFucyBvZiBsaXN0aW5n IHRoYXQgc3BlY2lmaWMgaGVhZGVyIGZpZWxkcyBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgc2hvdWxk IGJlIGRlZmluZWQuDQoNCg0KDQpBTFRFUk5BVElWRSBGSVJTVCBQT0xMIEZPUiBFWElTVElORyBJ TVBMRU1FTlRPUlM6IEhhdmUgeW91IGltcGxlbWVudGVkIHRoZSDigJxNVVNUIHVuZGVyc3RhbmQg b3IgcmVqZWN04oCdIHJ1bGU/IFdoaWNoIHNpdHVhdGlvbnMgZG8geW91IHJlamVjdCAoZWcg4oCc Zm9v4oCdOyDigJx6aXDigJ0gaW4gSldTOyDigJxlcGvigJ0gd2hlbiDigJxhbGfigJ064oCdUlNB LU9BRVDigJ07IOKAnGprdeKAnTo8bm9uLXN0cmluZz47IOKAnGprdeKAnTrigJ08aW52YWxpZCBV Ukk+4oCdOyDigKY/DQoNCg0KDQpBTFRFUk5BVElWRSBTRUNPTkQgUE9MTDogSG93IHJlYWwgaXMg dGhlIHJpc2sgdGhhdCBmdXR1cmUgZ3JvdXBzIHdpbGwgZGVsaWJlcmF0ZWx5IGRlc2lnbiAmIGRl cGxveSBuZXcgZmllbGRzIHRoYXQgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgSk9TRSBtZXNzYWdl cyBkZXBlbmRpbmcgb24gd2hldGhlciBvciBub3QgdGhlIG5ldyBmaWVsZCBpcyB1bmRlcnN0b29k LCB3aXRob3V0IHJlYWxpemluZyB0aGUgc2VjdXJpdHkgY29uc2VxdWVuY2VzPw0KDQoNCg0KQUxU RVJOQVRJVkUgVEhJUkQgUE9MTDogSXMgSk9TRSBzbyBjb21wbGV0ZSBhbmQgc3RhYmxlIHRoYXQg ZXh0ZW5zaW9ucyBhcmUgdW5saWtlbHkgdG8gYmUgbmVlZGVkPw0KDQoNCg0KU0VDT05EIFBPTEw6 ICBTaG91bGQgdGhlIHJlc3VsdCBvZiB0aGUgZmlyc3QgcG9sbCBiZSAiTk8iLCB3aGljaCBzeW50 YXggd291bGQgeW91IHByZWZlciBmb3IgZGVzaWduYXRpbmcgdGhlIGhlYWRlciBmaWVsZHMgdGhh dCBtYXkgYmUgaWdub3JlZCBpZiBub3QgdW5kZXJzdG9vZD8NCg0KQSDigJMgRGVmaW5lIGEgaGVh ZGVyIGZpZWxkIHRoYXQgZXhwbGljaXRseSBsaXN0cyB0aGUgZmllbGRzIHRoYXQgbWF5IGJlIHNh ZmVseSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29kLg0KDQpCIOKAkyBJbnRyb2R1Y2UgYSBzZWNv bmQgaGVhZGVyLCB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5kIGFsbCBmaWVs ZHMgaW4gdGhlIGZpcnN0IGJ1dCB0aGV5IG1heSBpZ25vcmUgbm90LXVuZGVyc3Rvb2QgZmllbGRz IGluIHRoZSBzZWNvbmQuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBUaGFua3MgZm9yIGNvbnNpZGVyaW5nIHRoZXNlIHF1ZXN0aW9ucywNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmljaGFyZCBC YXJuZXMsIEpvaG4gQnJhZGxleSwgTWlrZSBKb25lcw0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== --_000_4E1F6AAD24975D4BA5B16804296739436696ABC0TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+WWVzLCBJIGJlbGlldmUgdGhlIHNwZWMgd29yZGluZyBkb2VzIGZvcmJpZCDigJx6aXDi gJ0gaW4gYSBKV1MsIGJlY2F1c2UgaXTigJlzIG5vdCBhIGZpZWxkIHdpdGggYSBkZWZpbmVkIG1l YW5pbmcgaW4gdGhhdCBjb250ZXh0IOKAkyBqdXN0IGFzIOKAnGVwa+KAnSBoYXMgbm8gZGVmaW5l ZCBtZWFuaW5nIHdpdGgg4oCcYWxn4oCdOuKAnVJTQS1PQUVQ4oCdLiZuYnNwOyBJIGFncmVlIHRo YXQgbW9yZSBleHBsaWNpdA0KIHdvcmRpbmcgdG8gdGhhdCBlZmZlY3QgY2FuIGFuZCBwcm9iYWJs eSBzaG91bGQgYmUgYWRkZWQuJm5ic3A7IElmIHlvdeKAmWQgbGlrZSB0byBzdWdnZXN0IHNvbWUs IHBsZWFzZSBoYXZlIGF0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ T25lIHdvdWxkIGRlZmluZSDigJx6aXDigJ0gaW4gYSBKV1MgaW4gdGhlIG5vcm1hbCB3YXkgdGhh dCBleHRlbnNpb25zIGFyZSBtYWRlIHRvIElFVEYgc3BlY3Mg4oCTIHlvdeKAmWQgd3JpdGUgYSBz cGVjIGRlZmluaW5nIHRoZSBtZWFuaW5nIGZvciBpdCBhbmQgcmVnaXN0ZXIgdGhlIOKAnHppcOKA nSB2YWx1ZSBpbiB0aGUgSUFOQSBKU09OIFdlYiBTaWduYXR1cmUgYW5kIEVuY3J5cHRpb24NCiBI ZWFkZXIgUGFyYW1ldGVycyByZWdpc3RyeSBmb3IgSldTIHVzYWdlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFu Z2VyQHRlYW0udGVsc3RyYS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1i ZXIgMTgsIDIwMTIgMjo0MiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczsgam9zZUBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2pvc2VdIFdoZXRoZXIgaW1wbGVtZW50YXRp b25zIG11c3QgdW5kZXJzdGFuZCBhbGwgSk9TRSBoZWFkZXIgZmllbGRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5NaWtlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Db3VsZCB5b3UgYXQgbGVhc3QgZXhwYW5kIGEg Yml0IG9uIGhvdyB5b3UgZXhwZWN0IGEg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBy dWxlIHdpbGwgd29yayBpbiBwcmFjdGljZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZv ciBpbnN0YW5jZSwgZG9lcyB0aGUgc3BlYyB3b3JkaW5nIGZvcmJpZCDigJx6aXDigJ0gaW4gYSBK V1M/IOKAnGVwa+KAnSB3aGVuIOKAnGFsZ+KAnTrigJ1SU0EtT0FFUOKAnT8g4oCceDV14oCdOjc/ IOKAnHg1deKAnTrigJ1oZWxsbyB3b3JsZOKAnT8gV2lsbCBpbXBsZW1lbnRhdGlvbnMgYmUgY29u c2lzdGVudD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5QZXJoYXBzIHlvdSBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIHRo aXMgcnVsZSBhbHJlYWR5IGFuZCBjYW4gdGVsbCB1cyB3aGF0IGl0IGRvZXM/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgd291 bGQgYWxzbyBhcHByZWNpYXRlIHlvdXIgdGhvdWdodHMgb24gd2hldGhlciBzb21lb25lIGNhbiBl eHRlbmQgSldTIGJ5IHNwZWNpZnlpbmc6IHdoZW4gdGhlIOKAnHppcOKAnSBmaWVsZCBpcyBwcmVz ZW50IGluIGEgSldTIHRoZSBjb250ZW50IGlzIGNvbXByZXNzZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5UaGF0IGxvb2tzIGxlZ2l0aW1hdGUgd2l0aCB0aGUgY3VycmVudCDigJxNVVNU IHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUuIEkgdGhpbmsgaXQgaXMgbGlrZWx5LCBob3dl dmVyLCB0aGF0IHN1Y2ggYW4gZXh0ZW5zaW9uIHdpbGwgY2F1c2Ugc2VjdXJpdHkgcHJvYmxlbXMu IFNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwgY29uZmlybSB0aGF0DQog4oCcemlw4oCdIGlzIG9u IHRoZSBsaXN0IG9mIGtub3duIHN0YW5kYXJkIGZpZWxkcywgYnV0IHdpbGwgaWdub3JlIGl0IGlu IHRoZSBKV1MgcHJvY2Vzc2luZyBjb2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBNaWtlIEpvbmVzIFs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5tYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIDE5IERlY2VtYmVyIDIwMTIgOTowNCBB TTxicj4NCjxiPlRvOjwvYj4gTWFuZ2VyLCBKYW1lcyBIOyA8YSBocmVmPSJtYWlsdG86am9zZUBp ZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtqb3Nl XSBXaGV0aGVyIGltcGxlbWVudGF0aW9ucyBtdXN0IHVuZGVyc3RhbmQgYWxsIEpPU0UgaGVhZGVy IGZpZWxkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEph bWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGVyIHRoZSByZXNwb25z ZSBJIGp1c3Qgc2VudCB0byBBeGVsLCB3aGVuIHdlIGRpc2N1c3NlZCB0aGlzIGlzc3VlIGluIHRo ZSBwYXN0LCBvbmx5IG9uZSBwZXJzb24gd2FzIGluIGZhdm9yIG9mIGEgbXVzdC1pZ25vcmUtYnkt ZGVmYXVsdCBiZWhhdmlvciwgYW5kIHlldCB0aGF04oCZcyB3aGF0IHlvdeKAmXJlIGFkdm9jYXRp bmcgYmVsb3cuJm5ic3A7IFNlZQ0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwMTIxNi5odG1sIj5odHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzAxMjE2Lmh0bWw8L2E+LiZuYnNwOyBP ZiBjb3Vyc2UsIGl04oCZcyBhbHdheXMgcG9zc2libGUgeW91IGNvdWxkIGNoYW5nZSBtaW5kcywg YnV0IEkgc3VzcGVjdCB0aGF0IGlmIHlvdSB3YW50IHRvIGluZmx1ZW5jZSB0aGUgb3V0Y29tZSBv Zg0KIHRoaXMgaXNzdWUsIHRoZSBoaWdoZXN0LXBheW9mZiBzdHJhdGVneSB3b3VsZCBiZSB0byBk aXNjdXNzIHN5bnRheCBvcHRpb25zIHRoYXQgcmVxdWlyZSBwZW9wbGUgdG8gdGFrZSBzcGVjaWFs IGFjdGlvbiB0byBpZ25vcmUgYSBub3QtdW5kZXJzdG9vZCBmaWVsZCwgcmF0aGVyIHRoYW4gdGhl IG90aGVyIHdheSBhcm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTXkgdHdvIGNlbnRzIHdvcnRo4oCm PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTWFuZ2VyLCBKYW1lcyBIIFs8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJA dGVhbS50ZWxzdHJhLmNvbSI+bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDE4LCAyMDEyIDQ6NTkg QU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYu b3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2pvc2VdIFdo ZXRoZXIgaW1wbGVtZW50YXRpb25zIG11c3QgdW5kZXJzdGFuZCBhbGwgSk9TRSBoZWFkZXIgZmll bGRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPk15IGNvbW1lbnRz IGluIHJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q3VycmVudGx5IHRoZSBKT1NFIHNwZWNzIGNvbnRhaW4g dGhlIGZvbGxvd2luZyBsYW5ndWFnZSBkZWNsYXJpbmcgdGhhdCBhbGwgaGVhZGVyIChhbmQgc29t ZSBvdGhlcikgZmllbGRzIG11c3QgYmUgdW5kZXJzdG9vZDombmJzcDsg4oCcSW1wbGVtZW50YXRp b25zIE1VU1QgdW5kZXJzdGFuZCB0aGUgZW50aXJlIGNvbnRlbnRzIG9mIHRoZSBoZWFkZXI7IG90 aGVyd2lzZSwgdGhlIOKApiBNVVNUIGJlIHJlamVjdGVkLuKAnSZuYnNwOyBUaGVyZSdzDQogY3Vy cmVudGx5IGFuIG9wZW4gaXNzdWUgYWJvdXQgd2hldGhlciBhbGwgaGVhZGVyIGZpZWxkcyBzaG91 bGQgYmUgcmVxdWlyZWQgdG8gYmUgdW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMgdXNpbmcg dGhlbSBvciB3aGV0aGVyIHRvIHJlbGF4IHRoaXMgcmVxdWlyZW1lbnQgaW4gc29tZSBjaXJjdW1z dGFuY2VzLiZuYnNwOyBXZSB3b3VsZCBsaWtlIHRoZSB3b3JraW5nIGdyb3VwIHRvIGNvbnNpZGVy IHRoZSBmb2xsb3dpbmcgcG90ZW50aWFsIHJlc29sdXRpb25zDQogdG8gdGhlIGlzc3VlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xLiZuYnNwOyBNYWludGFpbiB0aGUgY3VycmVudCBy ZXF1aXJlbWVudCB0aGF0IGFsbCBoZWFkZXIgZmllbGRzIG11c3QgYmUgdW5kZXJzdG9vZCBieSBp bXBsZW1lbnRhdGlvbnMgdXNpbmcgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ UFJPOiZuYnNwOyBUaGlzIGlzIGEgc2ltcGxlIHJ1bGU8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkl0IGlzIG5vdCBh cyBzaW1wbGUgYXMgaWdub3JpbmcgdW5rbm93biBmaWVsZHMsIHdoaWNoIGFsbCBjb2RlIHdpbGwg ZG8gbmF0dXJhbGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkFyZSB0aGUg 4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxlcyB3ZWxsIGRlZmluZWQ/IE9idmlv dXNseSBpZiBhIHRvdGFsbHkgdW5rbm93biBmaWVsZCBpcyBwcmVzZW50IHRoZSBKT1NFIG1lc3Nh Z2UgbXVzdCBiZSByZWplY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5I b3cgYWJvdXQgaWYgYSBkZWZpbmVkIGZpZWxkIGlzIGluIGFuIHVuZXhwZWN0ZWQgcGxhY2UsIGVn IOKAnHppcOKAnSBpbiBhIEpXRSBoZWFkZXI/IFByZXN1bWFibHkgdGhhdCBoYXMgdG8gYmUgcmVq ZWN0ZWQgc28gaXQgaXMgbm90IHN1ZmZpY2llbnQgZm9yIGNvZGUgdG8gY2hlY2sgYW55IEpPU0Ug bWVzc2FnZXMgYWdhaW5zdCBvbmUgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 cmVkIj5Ib3cgYWJvdXQgYSBKV0Ugd2l0aCBhbiDigJxlcGvigJ0gZmllbGQgd2hlbiDigJxhbGfi gJ064oCdUlNBLU9BRVDigJ0/IFByZXN1bWFibHkgdGhhdCBhbHNvIGhhcyB0byBiZSByZWplY3Rl ZCBzbyBjaGVja2luZyBhZ2FpbnN0IGEgc3RhdGljIGxpc3Qgb2YgSldFIGZpZWxkcyBpcyBub3Qg c3VmZmljaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5Eb2VzIHRoZSB0 eXBlIG9yIHZhbHVlIG9mIGEgZmllbGQgbmVlZCB0byBiZSBjaGVja2VkIGlmIGFuIGltcGxlbWVu dGF0aW9uIGRvZXNu4oCZdCBuZWVkIHRvIHVzZSBpdD8gRm9yIGV4YW1wbGUsIGRvZXMgYW4gaW1w bGVtZW50YXRpb24gdGhhdCBhbHJlYWR5IGhhcyBhIGdpdmVuIGNlcnQgKHNvIGl0IGRvZXNu4oCZ dCBuZWVkIHRvIHVzZSBhIOKAnHg1deKAnSB2YWx1ZSkgbmVlZA0KIHRvIGNvbmZpcm0gdGhhdCB0 aGUg4oCceDV14oCdIHZhbHVlIGlzIGEgc3RyaW5nLCBvciBpcyBhIHZhbGlkIFVSSSwgb3IgYWN0 dWFsbHkgcmVzb2x2ZXMgdG8gdGhlIHNhbWUgY2VydD8gUHJvYmFibHkgbm90LiBJIGFzc3VtZSBp dCBpcyBzdWZmaWNpZW50IHRvIHVuZGVyc3RhbmQgdGhhdCBhIGZpZWxkIGNhbiBiZSBpZ25vcmVk LCB3aXRob3V0IGFjdHVhbGx5IHVuZGVyc3RhbmRpbmcgaXRzIGFjdHVhbCBzeW50YXggb3IgdmFs dWUgaXMgYSBzcGVjaWZpYw0KIG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj7igKY8L3NwYW4+ZGVzaWduZWQgdG8gcmVzdWx0IGluIHNlY3VyZSBpbXBs ZW1lbnRhdGlvbnMuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5TZWN1cmUgaW4gd2hhdCB3YXk/IElzIHRoaXMgYWltZWQg c3BlY2lmaWNhbGx5IGF0IHByZXZlbnRpbmcgbmV3IGZpZWxkcyBiZWluZyBpZ25vcmVkIGluIGNh c2UgdGhleSBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBleGlzdGluZyBmaWVsZHM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPlBSTzogTmV3IGZpZWxkcyBhcmUgYWxsb3dl ZCB0byBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBleGlzdGluZyBmaWVsZHMgYmVjYXVzZSBpbXBs ZW1lbnRhdGlvbnMgbm90IHVuZGVyc3RhbmRpbmcgdGhlIGNoYW5nZWQgc2VtYW50aWNzIHdpbGwg ZmFpbC1zYWZlIGR1ZSB0byBzZWVpbmcgYW4gdW5rbm93biBmaWVsZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4o b3IgaXMgdGhpcyBhIENPTiBmb3IgZW5jb3VyYWdpbmcgZGFuZ2Vyb3VzIGV4dGVuc2lvbnM/KTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+4oCmPC9zcGFuPlJlcHJl c2VudGF0aW9ucyBvZiBleGlzdGluZyBKV1MgJmFtcDsgSldFIG9iamVjdHMgYXJlIHVuY2hhbmdl ZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNPTjombmJzcDsgRXh0 ZW5zaWJpbGl0eSBpcyBsaW1pdGVkIHRvIGNhc2VzIHdoZXJlIGFsbCBwYXJ0aWNpcGF0aW5nIHBh cnRpZXMgdW5kZXJzdGFuZCBuZXcgZmllbGRzIHRoYXQgYXJlIGludHJvZHVjZWQuPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkNP TjogQmVjYXVzZSBjb2RlIGNhbiBzdWNjZXNzZnVsbHkgcHJvY2VzcyBKT1NFIG1lc3NhZ2Ugd2l0 aG91dCBpbXBsZW1lbnRpbmcgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBvciByZWplY3TigJ0gcnVs ZSBpdCBpcyBoYXJkIHRvIGhhdmUgY29uZmlkZW5jZSB0aGF0IGl0IGlzIGltcGxlbWVudGVkIChv ciBpbXBsZW1lbnRlZCB3ZWxsKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MkEuJm5ic3A7IFRha2UgYW4gYWx0 ZXJuYXRpdmUgYXBwcm9hY2ggd2hlcmUsIGJ5IGRlZmF1bHQsIGFsbCBmaWVsZHMgbXVzdCBiZSB1 bmRlcnN0b29kLCBidXQgd2hlcmUgYW4gZXhwbGljaXQgbGlzdCBvZiBmaWVsZHMgY2FuIGJlIGRl c2lnbmF0ZWQgYXMg4oCcbWF5IGJlIGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2TigJ0uJm5ic3A7 IEZvciBpbnN0YW5jZSwgYW4g4oCcaWdu4oCdIChtYXkgYmUgaWdub3JlZCkgbWVtYmVyIGNvdWxk IGJlDQogZGVmaW5lZCB3aG9zZSB2YWx1ZSBpcyBhbiBhcnJheSBsaXN0aW5nIHRoZSBtZW1iZXIg bmFtZXMgdGhhdCBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuJm5ic3A7 IEFuIGV4YW1wbGUgdXNpbmcgdGhpcyBmaWVsZCBpbiBhIEpXUyBoZWFkZXIgaXM6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB7JnF1b3Q7YWxnJnF1b3Q7 OiZxdW90O0VTMjU2JnF1b3Q7LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lnbiZxdW90OzpbJnF1b3Q7bm90ZXMm cXVvdDtdLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25vdGVzJnF1b3Q7OiZxdW90O1RoaXMgc2lnbmF0dXJlIG5l ZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsJnF1b3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oT2J2aW91c2x5LCB0aGUgJnF1b3Q7aWduJnF1b3Q7IGZp ZWxkIE1VU1QgTk9UIGNvbnRhaW4gdGhlIHZhbHVlICZxdW90O2lnbiZxdW90Oy4pPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlBSTzombmJzcDsgVGhpcyB3b3VsZCBlbmFibGUgYWRkaW5n IG5vbi1jcml0aWNhbCBoZWFkZXIgZmllbGRzIHdpdGhvdXQgYnJlYWtpbmcgaW1wbGVtZW50YXRp b25zLiZuYnNwOyBJdCB3b3VsZCBtYWludGFpbiB0aGUgY3VycmVudCBzZW1hbnRpY3MsIHdoaWxl IGFsbG93aW5nIGV4cGxpY2l0IGV4Y2VwdGlvbnMgdG8gYmUgbWFkZSBpbiBjYXNlcyB3aGVyZSB0 aGUgZmllbGRzIGFyZSBub3Qgc2VjdXJpdHktY3JpdGljYWwgYW5kDQogdGhlIHN0cnVjdHVyZSBo YXMgYSBtZWFuaW5nZnVsIGludGVycHJldGF0aW9uIHdpdGhvdXQgdGhlbS4mbmJzcDsgUmVwcmVz ZW50YXRpb25zIG9mIGV4aXN0aW5nIEpXUyAmYW1wOyBKV0Ugb2JqZWN0cyBhcmUgdW5jaGFuZ2Vk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09OOiZuYnNwOyBSZXF1 aXJlcyBjb29yZGluYXRpb24gb2YgZmllbGQgbmFtZXMgYW5kIG1heS1iZS1pZ25vcmVkIGxpc3Qs IGFkZGluZyBzb21lIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjJCLiZuYnNwOyBUYWtlIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIHdoZXJl IGluc3RlYWQgb2Ygb25lIGhlYWRlciBvYmplY3QsIHRoZXJlIHdvdWxkIGJlIHR3byBoZWFkZXIg b2JqZWN0cy4mbmJzcDsgSW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIHJlcXVpcmVkIHRvIHVuZGVy c3RhbmQgYWxsIGZpZWxkcyBpbiB0aGUgZmlyc3QgaGVhZGVyIG9iamVjdC4mbmJzcDsgSW1wbGVt ZW50YXRpb25zIHdvdWxkIGJlIGFsbG93ZWQgdG8gaWdub3JlDQogZmllbGRzIGluIHRoZSBzZWNv bmQgaGVhZGVyIG9iamVjdCBpZiBub3QgdW5kZXJzdG9vZC4mbmJzcDsgQW4gZXhhbXBsZSBvZiB0 aGlzIGFwcHJvYWNoLCBhZGRpbmcgdGhlIHNlY29uZCBoZWFkZXIgb2JqZWN0IGFmdGVyIHRoZSBm aXJzdCBpbiBhIEpXUywgd291bGQgYmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyBleUowZVhBaU9pSktWMVFpTEEwS0lDSmhiR2NpT2lKSVV6STFOaUo5 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGV5SnViM1JsY3lJNklsUm9hWE1nYzJsbmJtRjBkWEpsSUc1bFpXUWdibTkwSUdKbElH Tm9aV05yWldRZ2QyaGxiaUIwYUdVZ2JXOXZiaUJwY3lCbWRXeHNJbjA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZXlKcGMzTWlP aUpxYjJVaUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRIQTZMeTlsZUdGdGNH eGxMbU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBkQmpmdEplWjRDVlAtbUI5MksyN3Vo YlVKVTFwMXJfd1cxZ0ZXRk9FalhrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBm aXJzdCwgdGhpcmQsIGFuZCBmb3VydGggZmllbGRzIGFyZSBmcm9tIHRoZSBleGFtcGxlIEpXUyBp biB0aGUgY3VycmVudCBzcGVjLiBUaGUgbmV3IHNlY29uZCBmaWVsZCBpcyB0aGUgYmFzZTY0dXJs IGVuY29kZWQgcmVwcmVzZW50YXRpb24gb2YgdGhlIHN0cmluZyAneyZxdW90O25vdGVzJnF1b3Q7 OiZxdW90O1RoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBp cyBmdWxsJnF1b3Q7fScuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBSTzombmJzcDsg TWF5LWJlLWlnbm9yZWQgZmllbGRzIGFyZSBlYXNpbHkgZGlzdGluZ3Vpc2hhYmxlIGZyb20gbXVz dC1iZS11bmRlcnN0b29kIGZpZWxkcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkNPTjombmJzcDsgSW1wbGVtZW50YXRpb25zIG11c3QgY29uc3VsdC9tZXJnZSB0d28g c2V0cyBvZiBoZWFkZXJzIHRvIHVuZGVyc3RhbmQgdGhlIG1lYW5pbmcvc3RydWN0dXJlIG9mIHRo ZSBvYmplY3QsIGFkZGluZyBzb21lIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuJm5ic3A7IEV4 aXN0aW5nIEpXUyAmYW1wOyBKV0Ugb2JqZWN0IHJlcHJlc2VudGF0aW9ucyB3b3VsZCBiZWNvbWUg aW52YWxpZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4zLiBIYXZlIGEgZmllbGQg dGhhdCBpbmRpY2F0ZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgSk9TRSBtZXNzYWdlLiBGb3IgaW5z dGFuY2UgdGhlIGZpZWxkIGNvdWxkIGJlIGNhbGxlZCDigJwh4oCdIGFuZCBkZWZpbmVkIHZhbHVl cyBjb3VsZCBiZSDigJxzaWfigJ0sIOKAnG1hY+KAnSwg4oCcZW5j4oCd4oCmIGZvciBzaWduZWQt d2l0aC1hbi1hc3ltbWV0cmljLWtleSwgTUFDZWQtd2l0aC1hLXNoYXJlZC1zZWNyZXQsDQogZW5j cnlwdGVkLShBRUFEKS13aXRoLXNoYXJlZC1zZWNyZXTigKYuIFRoZSBkZWZpbml0aW9uIG9mIGEg dmFsdWUgZm9yIHRoZSDigJwh4oCdIGZpZWxkIGluZGljYXRlcyB0aGUgb3RoZXIgZmllbGRzIGl0 IHVzZXMuIFJlY2lwaWVudHMgTVVTVCBpZ25vcmUgYW55IHVucmVjb2duaXplZCBmaWVsZHMuIE9y aWdpbmF0b3JzIGFkZGluZyBhIG5ldyBmaWVsZCB0aGF0IGNoYW5nZXMgdGhlIHNlbWFudGljcyBv ZiBhIG1lc3NhZ2UgTVVTVCB1c2UgYSBuZXcgdmFsdWUNCiBmb3IgdGhlIOKAnCHigJ0gZmllbGQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+UFJPOiBDb2RlIHdpbGwgaW1wbGVt ZW50IHRoaXMgcnVsZSBuYXR1cmFsbHksIHNpbXBseSBieSBzd2l0Y2hpbmcgb24gdGhlIOKAnCHi gJ0gZmllbGQgdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+UFJPOiBJ dCBpcyBleHRlbnNpYmxlLiBFeHRyYSBmaWVsZHMgY2FuIGJlIGRlZmluZWQgYW5kIGRlcGxveWVk IHdpdGhvdXQgcmVxdWlyaW5nIG9yaWdpbmF0b3JzIGFuZCByZWNpcGllbnRzIHRvIGJlIHVwZ3Jh ZGVkIHNpbXVsdGFuZW91c2x5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkNP TjogQXJiaXRyYXJ5IGV4dHJhIGRhdGEgb2YgYSBvcmlnaW5hdG9y4oCZcyBjaG9vc2luZyBjYW4g YmUgaW5jbHVkZWQgYXMgdW5rbm93biBmaWVsZHMgaW4gbWVzc2FnZXMgdGhhdCByZWNpcGllbnRz IHdpbGwgYWNjZXB0LiBUaG91Z2ggdGhpcyBpcyB0cnVlIGV2ZW4gd2l0aCBhIOKAnE1VU1QgdW5k ZXJzdGFuZCBvciByZWplY3TigJ0gcnVsZSAoZWcgd2hpdGVzcGFjZSBpbg0KIHRoZSBKU09OIGhl YWRlciwganVuayBpbiBhIOKAnHg1deKAnSBVUkkgZnJhZ21lbnTigKYpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWZ0ZXIgYSBkaXNjdXNzaW9uIHBlcmlvZCwgd2Ug YmVsaWV2ZSB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIGNoYWlycyB0byBtYWtlIHR3 byBmb3JtYWwgY29uc2Vuc3VzIGNhbGxzIG9mIHRoZSBmb2xsb3dpbmcga2luZDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+RklSU1QgUE9MTDombmJzcDsgU2hvdWxkIGFsbCBoZWFkZXIg ZmllbGRzIGJlIGNyaXRpY2FsIGZvciBpbXBsZW1lbnRhdGlvbnMgdG8gdW5kZXJzdGFuZD88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPllFUyDigJMgQWxsIGhlYWRlciBm aWVsZHMgbXVzdCBjb250aW51ZSB0byBiZSB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyBv ciB0aGUgaW5wdXQgbXVzdCBiZSByZWplY3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPk5PIOKAkyBBIG1lYW5zIG9mIGxpc3RpbmcgdGhhdCBzcGVjaWZpYyBoZWFk ZXIgZmllbGRzIG1heSBiZSBzYWZlbHkgaWdub3JlZCBzaG91bGQgYmUgZGVmaW5lZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5BTFRFUk5BVElWRSBGSVJTVCBQT0xMIEZPUiBFWElT VElORyBJTVBMRU1FTlRPUlM6IEhhdmUgeW91IGltcGxlbWVudGVkIHRoZSDigJxNVVNUIHVuZGVy c3RhbmQgb3IgcmVqZWN04oCdIHJ1bGU/IFdoaWNoIHNpdHVhdGlvbnMgZG8geW91IHJlamVjdCAo ZWcg4oCcZm9v4oCdOyDigJx6aXDigJ0gaW4gSldTOyDigJxlcGvigJ0gd2hlbiDigJxhbGfigJ06 4oCdUlNBLU9BRVDigJ07IOKAnGprdeKAnTombHQ7bm9uLXN0cmluZyZndDs7DQog4oCcamt14oCd OuKAnSZsdDtpbnZhbGlkIFVSSSZndDvigJ07IOKApj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+QUxURVJOQVRJVkUgU0VDT05EIFBPTEw6IEhvdyByZWFsIGlzIHRoZSBy aXNrIHRoYXQgZnV0dXJlIGdyb3VwcyB3aWxsIGRlbGliZXJhdGVseSBkZXNpZ24gJmFtcDsgZGVw bG95IG5ldyBmaWVsZHMgdGhhdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBKT1NFIG1lc3NhZ2Vz IGRlcGVuZGluZyBvbiB3aGV0aGVyIG9yIG5vdCB0aGUgbmV3IGZpZWxkIGlzIHVuZGVyc3Rvb2Qs DQogd2l0aG91dCByZWFsaXppbmcgdGhlIHNlY3VyaXR5IGNvbnNlcXVlbmNlcz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+QUxURVJOQVRJVkUgVEhJUkQgUE9MTDogSXMg Sk9TRSBzbyBjb21wbGV0ZSBhbmQgc3RhYmxlIHRoYXQgZXh0ZW5zaW9ucyBhcmUgdW5saWtlbHkg dG8gYmUgbmVlZGVkPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlNFQ09ORCBQT0xMOiZuYnNwOyBTaG91bGQgdGhlIHJlc3VsdCBvZiB0aGUgZmlyc3Qg cG9sbCBiZSAmcXVvdDtOTyZxdW90Oywgd2hpY2ggc3ludGF4IHdvdWxkIHlvdSBwcmVmZXIgZm9y IGRlc2lnbmF0aW5nIHRoZSBoZWFkZXIgZmllbGRzIHRoYXQgbWF5IGJlIGlnbm9yZWQgaWYgbm90 IHVuZGVyc3Rvb2Q/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIOKA kyBEZWZpbmUgYSBoZWFkZXIgZmllbGQgdGhhdCBleHBsaWNpdGx5IGxpc3RzIHRoZSBmaWVsZHMg dGhhdCBtYXkgYmUgc2FmZWx5IGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CIOKAkyBJbnRyb2R1Y2UgYSBzZWNvbmQgaGVh ZGVyLCB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5kIGFsbCBmaWVsZHMgaW4g dGhlIGZpcnN0IGJ1dCB0aGV5IG1heSBpZ25vcmUgbm90LXVuZGVyc3Rvb2QgZmllbGRzIGluIHRo ZSBzZWNvbmQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGFua3MgZm9yIGNvbnNpZGVy aW5nIHRoZXNlIHF1ZXN0aW9ucyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBSaWNoYXJkIEJhcm5lcywgSm9obiBCcmFkbGV5LCBNaWtlIEpvbmVzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPi0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SmFtZXMg TWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739436696ABC0TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Dec 18 18:26:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690DC21E8034 for ; Tue, 18 Dec 2012 18:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPjXrO9AOYSN for ; Tue, 18 Dec 2012 18:26:37 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id 67F6321F8598 for ; Tue, 18 Dec 2012 18:26:37 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.202) by BY2FFO11HUB034.protection.gbl (10.1.14.118) with Microsoft SMTP Server (TLS) id 15.0.578.12; Wed, 19 Dec 2012 02:26:28 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Wed, 19 Dec 2012 02:26:28 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 02:26:21 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHg== Date: Wed, 19 Dec 2012 02:26:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464002)(46102001)(46406002)(51856001)(50466001)(4396001)(56776001)(47736001)(44976002)(53806001)(55846006)(5343655001)(76482001)(16406001)(47976001)(54356001)(49866001)(47776002)(23726001)(56816002)(47446002)(54316002)(77982001)(59766001)(15202345001)(74502001)(50986001)(33656001)(31966008)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB034; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 070092A9D3 Cc: Dick Hardt Subject: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 02:26:38 -0000 I've noticed that more than one person has expressed a desire to reduce the= size of JWS payloads before signing. This especially comes up when nested= encryption and signing is being performed. This note contains a quantitat= ive evaluation of some possible methods of reducing JWS payload size and as= ks for working group input based upon the data. Dick proposed one method below - have a header parameter to say that the pa= yload is already URL-safe and that base64url encoding is not to be performe= d. Another way that people have proposed is to allow the use of the "zip" = parameter to compress the JWS payload before base64url encoding. To get so= me initial data on how the solutions compare, I tried both methods using th= e sample JWE value in http://tools.ietf.org/html/draft-ietf-jose-json-web-e= ncryption-07#appendix-A.2 as the JWS payload. CURRENT SITUATION: The JWE is 526 characters in length. Currently, when u= sed as a JWS payload, base64url encoding it would increase its size to 702 = characters - an increase of 33% or 176 characters. AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter "b64":fa= lse to indicate that no additional base64url encoding is to be performed, t= he payload would be 176 characters smaller than the current situation. The= encoded header size would increase by 16 characters - the number of charac= ters needed to base64url encode this header parameter value and a comma, fo= r a net decrease in size of 160 characters. (Yes, parsing the three pieces= would be slightly more difficult.) APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on this = input results in a LARGER output - 536 bytes or a net increase of 10 bytes.= If you think about it, this isn't too surprising, as the encrypted data s= hould contain no usable predictability/redundancy. Base64url encoding thes= e 536 bytes results in a 715 character payload - an increase of 189 charact= ers or 36%. Plus, adding "zip":"DEF" to the header adds 16 characters, for= a total increase of 29 characters over the current situation. Clearly a s= uboptimal choice! CONCLUSION: Clearly, if we're going to enable reduction of the size of JWS= payloads, avoiding the double base64url encoding is preferable to zip, whi= ch actually makes things worse. QUESTION TO WORKING GROUP: I'm curious whether people would like to see us= enable avoiding double base64encoding of JWS payloads when they are alread= y URL-safe. The space savings are significant; they come at the cost of th= e JWS parsing becoming [part before first period . part between first and l= ast period . part after last period] rather than the current [part before f= irst period . part between first and second period . part after second peri= od (with no other periods allowed)]. Opinions? -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Monday, October 29, 2012 8:57 AM To: jose@ietf.org Subject: [jose] signing an existing JWT Let's say we have created a JWE as such: =09 headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne This is now the payload to a JWS. Rather than increasing the token size by = 4/3 by URL safe base 64 encoding the payload (since it is already URL safe)= , it would be useful to have a JWS header parameter that indicates the payl= oad was not re-encoded and does not need to be URL safe base 64 decoded. As there are more periods than expected in a JWS, decoding would ignore all= periods except the first and last one for separating out the header, paylo= ad and signature. The indicating parameter would seem to be either "tip" or "cty". I'm still = confused about the difference between the two parameters, so not sure which= one is appropriate. -- Dick _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Tue Dec 18 18:45:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9575A21F85A3 for ; Tue, 18 Dec 2012 18:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4o-RrrdpSNt for ; Tue, 18 Dec 2012 18:45:22 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9468321F859D for ; Tue, 18 Dec 2012 18:45:22 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id wz12so870127pbc.41 for ; Tue, 18 Dec 2012 18:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=nNM/qJVlQUdDQaKIUnWKZLOHKLrBO8pEvWaaINKDGU8=; b=iWE1Y8Z7HsfxMcNMguQlJXPmRbJkSmrivt8QXIHL/mJmehK9kCqugVoR8OZJuJ2XHU K+nv3jtIpebSzq8Z3LqiMWE6cAN56YrqFMNHw08P2aqegDl/agbE9eMv8Qu/TYajo2Bv NgWSe4KZHF7tTNN0SgGqyF23steIVPEK5+ptVyW2EBXw/IswfLyxJspTKAR59e3kivKH 7H98Sw90ncCWq5ud4Sg+r2GRQXbbtQZTI8UJeXT+dM1uLWDkykwxkQUen2xZqP0C7hf4 gPqZF/DCSpJeF7o6KBS2Kgjlp09RcRZASa8LaYzVEFU6SHGOEc124Rdbn670wjLr6a7X X6Uw== X-Received: by 10.68.242.3 with SMTP id wm3mr13504946pbc.44.1355885122239; Tue, 18 Dec 2012 18:45:22 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ir4sm2183859pbc.41.2012.12.18.18.45.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 18:45:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 18 Dec 2012 18:45:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 02:45:23 -0000 Hi Mike Thanks for bringing this up again.=20 An alternative approach I proposed was to have both the encryption and = signing information in one header, and to use the signing signature to = ensure integrity instead of having a separate encryption integrity = check. This would reduce the size of the token by the size of the = integrity value +1 bytes, as well as reduce the processing. Given that header properties are overloaded now (they have different = meanings depending on being a JWE or JWS, we could put the encryption = header values into a sub object in the header. Perhaps call that 'enc'. -- Dick The process below has=20 On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: > I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >=20 > Dick proposed one method below - have a header parameter to say that = the payload is already URL-safe and that base64url encoding is not to be = performed. Another way that people have proposed is to allow the use of = the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >=20 > CURRENT SITUATION: The JWE is 526 characters in length. Currently, = when used as a JWS payload, base64url encoding it would increase its = size to 702 characters - an increase of 33% or 176 characters. >=20 > AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter = "b64":false to indicate that no additional base64url encoding is to be = performed, the payload would be 176 characters smaller than the current = situation. The encoded header size would increase by 16 characters - = the number of characters needed to base64url encode this header = parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >=20 > APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on = this input results in a LARGER output - 536 bytes or a net increase of = 10 bytes. If you think about it, this isn't too surprising, as the = encrypted data should contain no usable predictability/redundancy. = Base64url encoding these 536 bytes results in a 715 character payload - = an increase of 189 characters or 36%. Plus, adding "zip":"DEF" to the = header adds 16 characters, for a total increase of 29 characters over = the current situation. Clearly a suboptimal choice! >=20 > CONCLUSION: Clearly, if we're going to enable reduction of the size = of JWS payloads, avoiding the double base64url encoding is preferable to = zip, which actually makes things worse. >=20 > QUESTION TO WORKING GROUP: I'm curious whether people would like to = see us enable avoiding double base64encoding of JWS payloads when they = are already URL-safe. The space savings are significant; they come at = the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Monday, October 29, 2012 8:57 AM > To: jose@ietf.org > Subject: [jose] signing an existing JWT >=20 >=20 > Let's say we have created a JWE as such: > =09 > = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >=20 > This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >=20 > As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >=20 > The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate. >=20 > -- Dick >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 From tonynad@microsoft.com Tue Dec 18 20:44:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376ED21F8577 for ; Tue, 18 Dec 2012 20:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYvyTN8gPbLc for ; Tue, 18 Dec 2012 20:44:29 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9BC21F84F6 for ; Tue, 18 Dec 2012 20:44:29 -0800 (PST) Received: from BY2FFO11FD006.protection.gbl (10.1.15.202) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.578.12; Wed, 19 Dec 2012 04:44:27 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Wed, 19 Dec 2012 04:44:26 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 19 Dec 2012 04:44:08 +0000 Received: from mail256-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Dec 2012 04:42:54 +0000 Received: from mail256-tx2 (localhost [127.0.0.1]) by mail256-tx2-R.bigfish.com (Postfix) with ESMTP id 72E2F7001E7 for ; Wed, 19 Dec 2012 04:42:54 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371Id6eah148cI542I1432Izz1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h9a9j1155h) Received-SPF: softfail (mail256-tx2: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB041; LANG:en; Received: from mail256-tx2 (localhost.localdomain [127.0.0.1]) by mail256-tx2 (MessageSwitch) id 1355892172570578_24323; Wed, 19 Dec 2012 04:42:52 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.247]) by mail256-tx2.bigfish.com (Postfix) with ESMTP id 88D90100043; Wed, 19 Dec 2012 04:42:52 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Dec 2012 04:42:52 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Wed, 19 Dec 2012 04:42:51 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 19 Dec 2012 04:42:37 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Wed, 19 Dec 2012 04:42:19 +0000 From: Anthony Nadalin To: Dick Hardt , Mike Jones Thread-Topic: [jose] Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgAAqR2AAAQEvdA= Date: Wed, 19 Dec 2012 04:42:14 +0000 Message-ID: <79f178fcdba34e6ea83635761d795178@BY2PR03MB041.namprd03.prod.outlook.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(24454001)(13464002)(52604002)(550184003)(56776001)(74662001)(51856001)(49866001)(76482001)(15202345001)(53806001)(74502001)(77982001)(23726001)(59766001)(54316002)(6806001)(46102001)(50466001)(33646001)(50986001)(31966008)(5343635001)(47776002)(5343655001)(46406002)(16676001)(54356001)(56816002)(44976002)(47976001)(47736001)(4396001)(47446002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 070092A9D3 Cc: "jose@ietf.org" Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 04:44:30 -0000 This forces a specific way and does not allow the flexability -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Tuesday, December 18, 2012 6:45 PM To: Mike Jones Cc: jose@ietf.org; Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads Hi Mike Thanks for bringing this up again.=20 An alternative approach I proposed was to have both the encryption and sign= ing information in one header, and to use the signing signature to ensure i= ntegrity instead of having a separate encryption integrity check. This woul= d reduce the size of the token by the size of the integrity value +1 bytes,= as well as reduce the processing. Given that header properties are overloaded now (they have different meanin= gs depending on being a JWE or JWS, we could put the encryption header valu= es into a sub object in the header. Perhaps call that 'enc'. -- Dick The process below has=20 On Dec 18, 2012, at 6:26 PM, Mike Jones wrote= : > I've noticed that more than one person has expressed a desire to reduce t= he size of JWS payloads before signing. This especially comes up when nest= ed encryption and signing is being performed. This note contains a quantit= ative evaluation of some possible methods of reducing JWS payload size and = asks for working group input based upon the data. >=20 > Dick proposed one method below - have a header parameter to say that the = payload is already URL-safe and that base64url encoding is not to be perfor= med. Another way that people have proposed is to allow the use of the "zip= " parameter to compress the JWS payload before base64url encoding. To get = some initial data on how the solutions compare, I tried both methods using = the sample JWE value in http://tools.ietf.org/html/draft-ietf-jose-json-web= -encryption-07#appendix-A.2 as the JWS payload. >=20 > CURRENT SITUATION: The JWE is 526 characters in length. Currently, when= used as a JWS payload, base64url encoding it would increase its size to 70= 2 characters - an increase of 33% or 176 characters. >=20 > AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter "b64":= false to indicate that no additional base64url encoding is to be performed,= the payload would be 176 characters smaller than the current situation. T= he encoded header size would increase by 16 characters - the number of char= acters needed to base64url encode this header parameter value and a comma, = for a net decrease in size of 160 characters. (Yes, parsing the three piec= es would be slightly more difficult.) >=20 > APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on thi= s input results in a LARGER output - 536 bytes or a net increase of 10 byte= s. If you think about it, this isn't too surprising, as the encrypted data= should contain no usable predictability/redundancy. Base64url encoding th= ese 536 bytes results in a 715 character payload - an increase of 189 chara= cters or 36%. Plus, adding "zip":"DEF" to the header adds 16 characters, f= or a total increase of 29 characters over the current situation. Clearly a= suboptimal choice! >=20 > CONCLUSION: Clearly, if we're going to enable reduction of the size of J= WS payloads, avoiding the double base64url encoding is preferable to zip, w= hich actually makes things worse. >=20 > QUESTION TO WORKING GROUP: I'm curious whether people would like to see = us enable avoiding double base64encoding of JWS payloads when they are alre= ady URL-safe. The space savings are significant; they come at the cost of = the JWS parsing becoming [part before first period . part between first and= last period . part after last period] rather than the current [part before= first period . part between first and second period . part after second pe= riod (with no other periods allowed)]. Opinions? >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of D= ick Hardt > Sent: Monday, October 29, 2012 8:57 AM > To: jose@ietf.org > Subject: [jose] signing an existing JWT >=20 >=20 > Let's say we have created a JWE as such: > =09 > headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integrit= ityVectorOne >=20 > This is now the payload to a JWS. Rather than increasing the token size b= y 4/3 by URL safe base 64 encoding the payload (since it is already URL saf= e), it would be useful to have a JWS header parameter that indicates the pa= yload was not re-encoded and does not need to be URL safe base 64 decoded. >=20 > As there are more periods than expected in a JWS, decoding would ignore a= ll periods except the first and last one for separating out the header, pay= load and signature. >=20 > The indicating parameter would seem to be either "tip" or "cty". I'm stil= l confused about the difference between the two parameters, so not sure whi= ch one is appropriate. >=20 > -- Dick >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Tue Dec 18 21:12:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C93121E802E for ; Tue, 18 Dec 2012 21:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhhod2u1lvGG for ; Tue, 18 Dec 2012 21:12:08 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDE421F85EE for ; Tue, 18 Dec 2012 21:12:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,315,1355058000"; d="scan'208,217";a="110494045" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 19 Dec 2012 16:12:05 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6930"; a="102950993" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 19 Dec 2012 16:12:04 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 19 Dec 2012 16:12:04 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 19 Dec 2012 16:12:03 +1100 Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sA== Message-ID: <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115041F5FFCWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 05:12:08 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115041F5FFCWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFtZXMgc2FpZDoNCj4+IEkgd291bGQgYWxzbyBhcHByZWNpYXRlIHlvdXIgdGhvdWdodHMgb24g d2hldGhlciBzb21lb25lIGNhbiBleHRlbmQgSldTIGJ5IHNwZWNpZnlpbmc6IHdoZW4gdGhlIOKA nHppcOKAnSBmaWVsZCBpcyBwcmVzZW50IGluIGEgSldTIHRoZSBjb250ZW50IGlzIGNvbXByZXNz ZWQuDQpUaGF0IGxvb2tzIGxlZ2l0aW1hdGUgd2l0aCB0aGUgY3VycmVudCDigJxNVVNUIHVuZGVy c3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUuIEkgdGhpbmsgaXQgaXMgbGlrZWx5LCBob3dldmVyLCB0 aGF0IHN1Y2ggYW4gZXh0ZW5zaW9uIHdpbGwgY2F1c2Ugc2VjdXJpdHkgcHJvYmxlbXMuIFNvbWUg aW1wbGVtZW50YXRpb25zIHdpbGwgY29uZmlybSB0aGF0IOKAnHppcOKAnSBpcyBvbiB0aGUgbGlz dCBvZiBrbm93biBzdGFuZGFyZCBmaWVsZHMsIGJ1dCB3aWxsIGlnbm9yZSBpdCBpbiB0aGUgSldT IHByb2Nlc3NpbmcgY29kZS4NCg0KTWlrZSBzYWlkOg0KPiBPbmUgd291bGQgZGVmaW5lIOKAnHpp cOKAnSBpbiBhIEpXUyBpbiB0aGUgbm9ybWFsIHdheSB0aGF0IGV4dGVuc2lvbnMgYXJlIG1hZGUg dG8gSUVURiBzcGVjcyDigJMgeW914oCZZCB3cml0ZSBhIHNwZWMgZGVmaW5pbmcgdGhlIG1lYW5p bmcgZm9yIGl0IGFuZCByZWdpc3RlciB0aGUg4oCcemlw4oCdIHZhbHVlIGluIHRoZSBJQU5BIEpT T04gV2ViIFNpZ25hdHVyZSBhbmQgRW5jcnlwdGlvbiBIZWFkZXIgUGFyYW1ldGVycyByZWdpc3Ry eSBmb3IgSldTIHVzYWdlLg0KDQoNCkxldHMgaWdub3JlIHRoZSBwcm9jZXNzIGZvciBub3cgKElF VEYsIElBTkHigKYpLCB0aGUgaXNzdWUgaXMgd2hldGhlciB0aGlzIHN0eWxlIG9mIGV4dGVuc2lv biBpcyBzZW5zaWJsZTogYW4gZXh0ZW5zaW9uIHRoYXQgaW5kaWNhdGVzIGEgY2hhbmdlIG9mIHNl bWFudGljcyBieSB0aGUgcHJlc2VuY2Ugb2YgYSBuZXcgZmllbGQuIEEgc3R5bGUgdGhhdCB0aGUg 4oCcTVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcnVsZSBlbmNvdXJhZ2VzLg0KTXkgYXJn dW1lbnQgaXMgdGhhdCB0aGlzIHN0eWxlIGlzIHRvbyBkYW5nZXJvdXMgYSB3YXkgdG8gaW5kaWNh dGUgbmV3IHNlbWFudGljcy4gV2hlbiBjaGFuZ2luZyBzZW1hbnRpY3MgKGFzIOKAnHppcOKAnSBk b2VzKSBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBjaGFuZ2UgYSBmaWVsZCB3ZSBhcmUgY29u ZmlkZW50IGltcGxlbWVudGF0aW9ucyB3aWxsIGJlIGxvb2tpbmcgYXQsIGFzIG9wcG9zZWQgdG8g cmVseWluZyBvbiB0aGVtIHRvIG5vdGljZSBhIG5ldyBmaWVsZC4NCg0KLS0NCkphbWVzIE1hbmdl cg0K --_000_255B9BB34FB7D647A506DC292726F6E115041F5FFCWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5N c29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkg bGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24x PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz5KYW1lcyBzYWlkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsmZ3Q7IEkgd291bGQgYWxzbyBhcHByZWNpYXRl IHlvdXIgdGhvdWdodHMgb24gd2hldGhlciBzb21lb25lIGNhbiBleHRlbmQgSldTIGJ5IHNwZWNp Znlpbmc6IHdoZW4gdGhlIOKAnHppcOKAnSBmaWVsZCBpcyBwcmVzZW50IGluIGEgSldTIHRoZSBj b250ZW50IGlzIGNvbXByZXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhhdCBsb29rcyBsZWdpdGltYXRlIHdp dGggdGhlIGN1cnJlbnQg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxlLiBJIHRo aW5rIGl0IGlzIGxpa2VseSwgaG93ZXZlciwgdGhhdCBzdWNoIGFuIGV4dGVuc2lvbiB3aWxsIGNh dXNlIHNlY3VyaXR5IHByb2JsZW1zLiBTb21lIGltcGxlbWVudGF0aW9ucyB3aWxsIGNvbmZpcm0g dGhhdCDigJx6aXDigJ0gaXMgb24gdGhlIGxpc3Qgb2Yga25vd24gc3RhbmRhcmQgZmllbGRzLCBi dXQgd2lsbCBpZ25vcmUgaXQgaW4gdGhlIEpXUyBwcm9jZXNzaW5nIGNvZGUuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk1pa2Ugc2FpZDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPiZndDsgT25lIHdvdWxkIGRlZmluZSDigJx6aXDigJ0gaW4gYSBKV1Mg aW4gdGhlIG5vcm1hbCB3YXkgdGhhdCBleHRlbnNpb25zIGFyZSBtYWRlIHRvIElFVEYgc3BlY3Mg 4oCTIHlvdeKAmWQgd3JpdGUgYSBzcGVjIGRlZmluaW5nIHRoZSBtZWFuaW5nIGZvciBpdCBhbmQg cmVnaXN0ZXIgdGhlIOKAnHppcOKAnSB2YWx1ZSBpbiB0aGUgSUFOQSBKU09OIFdlYiBTaWduYXR1 cmUgYW5kIEVuY3J5cHRpb24gSGVhZGVyIFBhcmFtZXRlcnMgcmVnaXN0cnkgZm9yIEpXUyB1c2Fn ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5MZXRzIGln bm9yZSB0aGUgcHJvY2VzcyBmb3Igbm93IChJRVRGLCBJQU5B4oCmKSwgdGhlIGlzc3VlIGlzIHdo ZXRoZXIgdGhpcyA8aT5zdHlsZTwvaT4gb2YgZXh0ZW5zaW9uIGlzIHNlbnNpYmxlOiBhbiBleHRl bnNpb24gdGhhdCBpbmRpY2F0ZXMgYSBjaGFuZ2Ugb2Ygc2VtYW50aWNzIGJ5IHRoZSBwcmVzZW5j ZSBvZiBhIG5ldyBmaWVsZC4gQSBzdHlsZSB0aGF0IHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgZXZl cnl0aGluZ+KAnSBydWxlIGVuY291cmFnZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+TXkgYXJndW1lbnQgaXMgdGhh dCB0aGlzIHN0eWxlIGlzIHRvbyBkYW5nZXJvdXMgYSB3YXkgdG8gaW5kaWNhdGUgbmV3IHNlbWFu dGljcy4gV2hlbiBjaGFuZ2luZyBzZW1hbnRpY3MgKGFzIOKAnHppcOKAnSBkb2VzKSBpdCB3b3Vs ZCBiZSBtdWNoIGJldHRlciB0byBjaGFuZ2UgYSBmaWVsZCB3ZSBhcmUgY29uZmlkZW50IGltcGxl bWVudGF0aW9ucyB3aWxsIGJlIGxvb2tpbmcgYXQsIGFzIG9wcG9zZWQgdG8gcmVseWluZyBvbiB0 aGVtIHRvIG5vdGljZSBhIG5ldyBmaWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E115041F5FFCWSMSG3153Vsrv_-- From djc.ochtman@gmail.com Wed Dec 19 00:25:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DAB21F8594 for ; Wed, 19 Dec 2012 00:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxy34y9nLQgt for ; Wed, 19 Dec 2012 00:25:03 -0800 (PST) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id A9FC821F8A94 for ; Wed, 19 Dec 2012 00:25:02 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id b23so1998838vbz.12 for ; Wed, 19 Dec 2012 00:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=bUZ5lULWZyOOalXbz/tOcOOtwnd4ZZBJmWZQWHqjWNw=; b=j8/10DzYTuvbvi8AqPlmSvXs2p99j26IGDQX2FwFlCujoTQGlyjW96iN1fZQfBAfce 8jOsoGkycswA1ueB98PvR/nrtdRF3GsBq4+ZNmtVM8qMTFvZ5N43mV7IN+y3Uyz38Mpp A0Wd0lC2tA9XNVHFAlDL2e+3dPjKTAPUB95uDW389FNkT11liQbExIs7P30oiWu6Jfeu kHI5kpF7mQZrQPxDEbEfEb9MbRiIZhcCjc7LU+KITr2GtSleLNg0Ss/34CWr5LGmwBwG oG6FYvGI2JZpcO3FUhIZ0+GmIDh91oxJPGHYz+gOpvF9N4EZSUTpxXYB7mcKZno7zlUQ qeeg== Received: by 10.52.35.4 with SMTP id d4mr6580954vdj.6.1355905502075; Wed, 19 Dec 2012 00:25:02 -0800 (PST) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.58.75.15 with HTTP; Wed, 19 Dec 2012 00:24:42 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Dirkjan Ochtman Date: Wed, 19 Dec 2012 09:24:42 +0100 X-Google-Sender-Auth: fYqKehN4RdaW9LGgkZ_jxIKl3vk Message-ID: To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 08:25:04 -0000 On Wed, Dec 19, 2012 at 3:26 AM, Mike Jones w= rote: > QUESTION TO WORKING GROUP: I'm curious whether people would like to see = us enable avoiding double base64encoding of JWS payloads when they are alre= ady URL-safe. The space savings are significant; they come at the cost of = the JWS parsing becoming [part before first period . part between first and= last period . part after last period] rather than the current [part before= first period . part between first and second period . part after second pe= riod (with no other periods allowed)]. Opinions? Personally, I think it would make sense to use a more orthogonal and general encoding of possible strategies, by doing something like HTTP's Transfer-Encoding. The transfer encoding could express any of 'deflate', 'non-b64u', 'b64u', 'deflate-b64u', and possibly other compression algorithms (snappy?). This allows flexibility for specific cases like a JWE value as JWS payload and larger payloads. Cheers, Dirkjan From djc.ochtman@gmail.com Wed Dec 19 00:29:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554AC21F852B for ; Wed, 19 Dec 2012 00:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJj0tsv9NpkL for ; Wed, 19 Dec 2012 00:29:57 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id B0E4A21F8528 for ; Wed, 19 Dec 2012 00:29:57 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so1967787vbb.16 for ; Wed, 19 Dec 2012 00:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=2KXSruG4C/0wEoJ323Xe1b0mZSMwdmOmq8X7NXbXCZo=; b=X1zKE8j2fAn3xGG/L4uNFoqJZ++w5wqqlkNNiTA9zVcneUfw5x4AvmLvR+lJYVph6U ZLSOSdRX1Q+q/avuJ3l/t2mYeLmWUl4ziMHT3e0JVTEc4JTq1Aeg1mGVVsAN9AM/hmul TZMnCyTDJQuIQTSQR7F9bQ6tnLA7bLW4T8X1CQ+uH22DKLjURhZ+XLjFeO871KMUYiQm Hqf4DmAR6sRn7IJLiu1PKCEwN7NUPC+Icxp2CU8r73v07GdhF1KNLdRJZKLlkR1trcSO T9ey91H2nAtS1MM1c6hHGFiEDNMALQ4mPw1WMYgpu8qoFiDHCg4p9lz0OVC8e12vvDJs xAVA== Received: by 10.52.90.241 with SMTP id bz17mr6616403vdb.40.1355905797061; Wed, 19 Dec 2012 00:29:57 -0800 (PST) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.58.75.15 with HTTP; Wed, 19 Dec 2012 00:29:36 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> From: Dirkjan Ochtman Date: Wed, 19 Dec 2012 09:29:36 +0100 X-Google-Sender-Auth: 2r3UsS6sOMQXTGWDqB-dVehzH80 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 08:29:58 -0000 On Wed, Dec 19, 2012 at 6:12 AM, Manger, James H wrote: > Lets ignore the process for now (IETF, IANA=E2=80=A6), the issue is wheth= er this > style of extension is sensible: an extension that indicates a change of > semantics by the presence of a new field. A style that the =E2=80=9CMUST = understand > everything=E2=80=9D rule encourages. > > My argument is that this style is too dangerous a way to indicate new > semantics. When changing semantics (as =E2=80=9Czip=E2=80=9D does) it wou= ld be much better > to change a field we are confident implementations will be looking at, as > opposed to relying on them to notice a new field. I fully agree with this. I think the better style is somewhat like this: implementation MUST use the value of the "alg" header to determine how to interpret the contents. Any possible alg value may have different header fields that are required to implement that algorithm. This may be too simplistic, but it's much more in line with what implementors are prone to doing, and closer to the expected semantics of JSON processing. Cheers, Dirkjan From dick.hardt@gmail.com Wed Dec 19 08:39:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1111B21F84DB for ; Wed, 19 Dec 2012 08:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eQRmMf68Elh for ; Wed, 19 Dec 2012 08:39:28 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9EE21F84D8 for ; Wed, 19 Dec 2012 08:39:28 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id rl6so1440945pac.29 for ; Wed, 19 Dec 2012 08:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=y6NQTW298LuvxIaFbWs4teDozq4JFJFjqXm3zbh20u8=; b=bO5gdOfn1Hg0290L27Q2WDIKgSr5dd7QGpaYJ+HajjcIKqXzYrKn/ThP8W86LN1OtV h01X5+OHhcGlaZtcqme+4vm3KflB4qT9FjANG7lyE3Oo5OJitSaAq4QkbZy9kdR9jcVk h9lkndzaoKtD4hhG0zBv6VKyNV6fmZkdTcu1yqnYqKxTJgpWLtL3BZnW2uvK/J5VWnaZ gIBABRk/2wyCot+b3fun2/Z2L6ccdTDSvZJnIl0pTsPI+BL5YfeVNXFscf8NBiLJKLHU 3U5YhGp0tsYCjJQGEITk2eyaAvv/l9qBpOej6fRiwGYXkppnFDyK0TXrok1aRUtOWnmi lclg== X-Received: by 10.66.82.67 with SMTP id g3mr18677627pay.58.1355935167871; Wed, 19 Dec 2012 08:39:27 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id gj1sm3372948pbc.11.2012.12.19.08.39.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 08:39:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <79f178fcdba34e6ea83635761d795178@BY2PR03MB041.namprd03.prod.outlook.com> Date: Wed, 19 Dec 2012 08:39:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9F135913-1D88-4842-B51E-C584D4510BF9@gmail.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <79f178fcdba34e6ea83635761d795178@BY2PR03MB041.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1499) Cc: Mike Jones , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:39:29 -0000 What "flexability" does it not allow? Seems more flexible to me.=20 On Dec 18, 2012, at 8:42 PM, Anthony Nadalin = wrote: > This forces a specific way and does not allow the flexability >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Tuesday, December 18, 2012 6:45 PM > To: Mike Jones > Cc: jose@ietf.org; Dick Hardt > Subject: Re: [jose] Reducing the size of JWS payloads >=20 > Hi Mike >=20 > Thanks for bringing this up again.=20 >=20 > An alternative approach I proposed was to have both the encryption and = signing information in one header, and to use the signing signature to = ensure integrity instead of having a separate encryption integrity = check. This would reduce the size of the token by the size of the = integrity value +1 bytes, as well as reduce the processing. >=20 > Given that header properties are overloaded now (they have different = meanings depending on being a JWE or JWS, we could put the encryption = header values into a sub object in the header. Perhaps call that 'enc'. >=20 > -- Dick >=20 > The process below has=20 > On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >=20 >> I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >>=20 >> Dick proposed one method below - have a header parameter to say that = the payload is already URL-safe and that base64url encoding is not to be = performed. Another way that people have proposed is to allow the use of = the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>=20 >> CURRENT SITUATION: The JWE is 526 characters in length. Currently, = when used as a JWS payload, base64url encoding it would increase its = size to 702 characters - an increase of 33% or 176 characters. >>=20 >> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter = "b64":false to indicate that no additional base64url encoding is to be = performed, the payload would be 176 characters smaller than the current = situation. The encoded header size would increase by 16 characters - = the number of characters needed to base64url encode this header = parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>=20 >> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on = this input results in a LARGER output - 536 bytes or a net increase of = 10 bytes. If you think about it, this isn't too surprising, as the = encrypted data should contain no usable predictability/redundancy. = Base64url encoding these 536 bytes results in a 715 character payload - = an increase of 189 characters or 36%. Plus, adding "zip":"DEF" to the = header adds 16 characters, for a total increase of 29 characters over = the current situation. Clearly a suboptimal choice! >>=20 >> CONCLUSION: Clearly, if we're going to enable reduction of the size = of JWS payloads, avoiding the double base64url encoding is preferable to = zip, which actually makes things worse. >>=20 >> QUESTION TO WORKING GROUP: I'm curious whether people would like to = see us enable avoiding double base64encoding of JWS payloads when they = are already URL-safe. The space savings are significant; they come at = the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt >> Sent: Monday, October 29, 2012 8:57 AM >> To: jose@ietf.org >> Subject: [jose] signing an existing JWT >>=20 >>=20 >> Let's say we have created a JWE as such: >> =09 >> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>=20 >> This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>=20 >> As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >>=20 >> The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate. >>=20 >> -- Dick >>=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 >=20 >=20 >=20 From rbarnes@bbn.com Wed Dec 19 09:48:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A5621F842C for ; Wed, 19 Dec 2012 09:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlXKGFPaFx-0 for ; Wed, 19 Dec 2012 09:48:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 002C921F8476 for ; Wed, 19 Dec 2012 09:48:43 -0800 (PST) Received: from dhcp-192-1-255-192.col.bbn.com ([192.1.255.192]:56040) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TlNl4-000OFa-4I; Wed, 19 Dec 2012 12:48:42 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 19 Dec 2012 12:48:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:48:45 -0000 Why is this a JOSE issue? It seems like an application could say, "the = thing you sign is a zipped form of the real thing". The only reason you = need the flag is if an application allows both zipped and unzipped. And = even then, if non-critical extensions are allows, applications could = define their own flags / encodings. On Dec 18, 2012, at 9:26 PM, Mike Jones = wrote: > I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >=20 > Dick proposed one method below - have a header parameter to say that = the payload is already URL-safe and that base64url encoding is not to be = performed. Another way that people have proposed is to allow the use of = the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >=20 > CURRENT SITUATION: The JWE is 526 characters in length. Currently, = when used as a JWS payload, base64url encoding it would increase its = size to 702 characters - an increase of 33% or 176 characters. >=20 > AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter = "b64":false to indicate that no additional base64url encoding is to be = performed, the payload would be 176 characters smaller than the current = situation. The encoded header size would increase by 16 characters - = the number of characters needed to base64url encode this header = parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >=20 > APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on = this input results in a LARGER output - 536 bytes or a net increase of = 10 bytes. If you think about it, this isn't too surprising, as the = encrypted data should contain no usable predictability/redundancy. = Base64url encoding these 536 bytes results in a 715 character payload - = an increase of 189 characters or 36%. Plus, adding "zip":"DEF" to the = header adds 16 characters, for a total increase of 29 characters over = the current situation. Clearly a suboptimal choice! >=20 > CONCLUSION: Clearly, if we're going to enable reduction of the size = of JWS payloads, avoiding the double base64url encoding is preferable to = zip, which actually makes things worse. >=20 > QUESTION TO WORKING GROUP: I'm curious whether people would like to = see us enable avoiding double base64encoding of JWS payloads when they = are already URL-safe. The space savings are significant; they come at = the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Monday, October 29, 2012 8:57 AM > To: jose@ietf.org > Subject: [jose] signing an existing JWT >=20 >=20 > Let's say we have created a JWE as such: > =09 > = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >=20 > This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >=20 > As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >=20 > The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate. >=20 > -- Dick >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Wed Dec 19 11:23:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4870921F8522 for ; Wed, 19 Dec 2012 11:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxB-2r111OTI for ; Wed, 19 Dec 2012 11:23:56 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3083921F845D for ; Wed, 19 Dec 2012 11:23:55 -0800 (PST) Received: from BY2FFO11FD008.protection.gbl (10.1.15.202) by BY2FFO11HUB014.protection.gbl (10.1.14.86) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 19 Dec 2012 19:23:46 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 19:23:46 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 19:23:08 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgAgNryAAAMsxkA= Date: Wed, 19 Dec 2012 19:23:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436697734F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(51704002)(24454001)(50986001)(49866001)(50466001)(44976002)(47976001)(46406002)(47736001)(23726001)(76482001)(16406001)(15202345001)(54316002)(59766001)(4396001)(56776001)(31966008)(77982001)(47446002)(51856001)(53806001)(56816002)(74502001)(54356001)(55846006)(46102001)(33656001)(550184003)(74662001)(47776002)(5343655001)(5343635001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB014; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 070092A9D3 Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 19:23:57 -0000 It's a JWS issue because the flag would affect parsing. Yes, applications = could, for instance, choose to apply compression, but in the particular cas= e we're discussing, compression actually doesn't work at all. It's a demon= stration that encryption really does apply entropy to the input. ;-) -- Mike -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Wednesday, December 19, 2012 9:49 AM To: Mike Jones Cc: jose@ietf.org; Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads Why is this a JOSE issue? It seems like an application could say, "the thi= ng you sign is a zipped form of the real thing". The only reason you need = the flag is if an application allows both zipped and unzipped. And even th= en, if non-critical extensions are allows, applications could define their = own flags / encodings. On Dec 18, 2012, at 9:26 PM, Mike Jones wrote= : > I've noticed that more than one person has expressed a desire to reduce t= he size of JWS payloads before signing. This especially comes up when nest= ed encryption and signing is being performed. This note contains a quantit= ative evaluation of some possible methods of reducing JWS payload size and = asks for working group input based upon the data. >=20 > Dick proposed one method below - have a header parameter to say that the = payload is already URL-safe and that base64url encoding is not to be perfor= med. Another way that people have proposed is to allow the use of the "zip= " parameter to compress the JWS payload before base64url encoding. To get = some initial data on how the solutions compare, I tried both methods using = the sample JWE value in http://tools.ietf.org/html/draft-ietf-jose-json-web= -encryption-07#appendix-A.2 as the JWS payload. >=20 > CURRENT SITUATION: The JWE is 526 characters in length. Currently, when= used as a JWS payload, base64url encoding it would increase its size to 70= 2 characters - an increase of 33% or 176 characters. >=20 > AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter "b64":= false to indicate that no additional base64url encoding is to be performed,= the payload would be 176 characters smaller than the current situation. T= he encoded header size would increase by 16 characters - the number of char= acters needed to base64url encode this header parameter value and a comma, = for a net decrease in size of 160 characters. (Yes, parsing the three piec= es would be slightly more difficult.) >=20 > APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on thi= s input results in a LARGER output - 536 bytes or a net increase of 10 byte= s. If you think about it, this isn't too surprising, as the encrypted data= should contain no usable predictability/redundancy. Base64url encoding th= ese 536 bytes results in a 715 character payload - an increase of 189 chara= cters or 36%. Plus, adding "zip":"DEF" to the header adds 16 characters, f= or a total increase of 29 characters over the current situation. Clearly a= suboptimal choice! >=20 > CONCLUSION: Clearly, if we're going to enable reduction of the size of J= WS payloads, avoiding the double base64url encoding is preferable to zip, w= hich actually makes things worse. >=20 > QUESTION TO WORKING GROUP: I'm curious whether people would like to see = us enable avoiding double base64encoding of JWS payloads when they are alre= ady URL-safe. The space savings are significant; they come at the cost of = the JWS parsing becoming [part before first period . part between first and= last period . part after last period] rather than the current [part before= first period . part between first and second period . part after second pe= riod (with no other periods allowed)]. Opinions? >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of D= ick Hardt > Sent: Monday, October 29, 2012 8:57 AM > To: jose@ietf.org > Subject: [jose] signing an existing JWT >=20 >=20 > Let's say we have created a JWE as such: > =09 > headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integrit= ityVectorOne >=20 > This is now the payload to a JWS. Rather than increasing the token size b= y 4/3 by URL safe base 64 encoding the payload (since it is already URL saf= e), it would be useful to have a JWS header parameter that indicates the pa= yload was not re-encoded and does not need to be URL safe base 64 decoded. >=20 > As there are more periods than expected in a JWS, decoding would ignore a= ll periods except the first and last one for separating out the header, pay= load and signature. >=20 > The indicating parameter would seem to be either "tip" or "cty". I'm stil= l confused about the difference between the two parameters, so not sure whi= ch one is appropriate. >=20 > -- Dick >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Wed Dec 19 11:36:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48DB21F8777 for ; Wed, 19 Dec 2012 11:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsClbm3ZjHg8 for ; Wed, 19 Dec 2012 11:36:41 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAD21F8689 for ; Wed, 19 Dec 2012 11:36:40 -0800 (PST) Received: from BL2FFO11FD006.protection.gbl (10.173.161.203) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 19 Dec 2012 19:36:38 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 19:36:38 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 19:36:11 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [jose] Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgAAqR2AACLdd6A= Date: Wed, 19 Dec 2012 19:36:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(377454001)(52604002)(51704002)(13464002)(33656001)(56816002)(56776001)(51856001)(54316002)(77982001)(55846006)(76482001)(59766001)(5343635001)(5343655001)(53806001)(23726001)(54356001)(74662001)(44976002)(31966008)(47776002)(50466001)(50986001)(49866001)(15202345001)(74502001)(47446002)(47976001)(16406001)(47736001)(4396001)(46102001)(550184003)(46406002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB024; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 070092A9D3 Cc: "jose@ietf.org" Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 19:36:42 -0000 Hi Dick, The way to do that with the current spec is to define a new composite encry= ption/integrity algorithm that does what you want. For instance, the "A128= CBC+HS256" composite algorithm performs encryption with AES CBC and the int= egrity check with HMAC SHA-256. I could imagine an "A128CBC+ES256" algorit= hm that performs the encryption with AES CBC and the integrity calculation = with ECDSA P-256 SHA-256. The key for that composite algorithm could be th= e concatenation of a 128-bit CBC key and the ECDSA key. For what it's worth, until draft -06, the block encryption algorithm and th= e integrity algorithm were separately specified (in "enc" and "int") parame= ters. The working group made a decision to only support encryption algorit= hms that provided integrity - hence the use of composite algorithms when us= ing CBC (which doesn't provide integrity itself. However, you still would = have had to define a new "int" algorithm even when they were separate, beca= use the only integrity algorithms specified were HS256, HS384, and HS512. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Tuesday, December 18, 2012 6:45 PM To: Mike Jones Cc: jose@ietf.org; Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads Hi Mike Thanks for bringing this up again.=20 An alternative approach I proposed was to have both the encryption and sign= ing information in one header, and to use the signing signature to ensure i= ntegrity instead of having a separate encryption integrity check. This woul= d reduce the size of the token by the size of the integrity value +1 bytes,= as well as reduce the processing. Given that header properties are overloaded now (they have different meanin= gs depending on being a JWE or JWS, we could put the encryption header valu= es into a sub object in the header. Perhaps call that 'enc'. -- Dick The process below has=20 On Dec 18, 2012, at 6:26 PM, Mike Jones wrote= : > I've noticed that more than one person has expressed a desire to reduce t= he size of JWS payloads before signing. This especially comes up when nest= ed encryption and signing is being performed. This note contains a quantit= ative evaluation of some possible methods of reducing JWS payload size and = asks for working group input based upon the data. >=20 > Dick proposed one method below - have a header parameter to say that the = payload is already URL-safe and that base64url encoding is not to be perfor= med. Another way that people have proposed is to allow the use of the "zip= " parameter to compress the JWS payload before base64url encoding. To get = some initial data on how the solutions compare, I tried both methods using = the sample JWE value in http://tools.ietf.org/html/draft-ietf-jose-json-web= -encryption-07#appendix-A.2 as the JWS payload. >=20 > CURRENT SITUATION: The JWE is 526 characters in length. Currently, when= used as a JWS payload, base64url encoding it would increase its size to 70= 2 characters - an increase of 33% or 176 characters. >=20 > AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter "b64":= false to indicate that no additional base64url encoding is to be performed,= the payload would be 176 characters smaller than the current situation. T= he encoded header size would increase by 16 characters - the number of char= acters needed to base64url encode this header parameter value and a comma, = for a net decrease in size of 160 characters. (Yes, parsing the three piec= es would be slightly more difficult.) >=20 > APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on thi= s input results in a LARGER output - 536 bytes or a net increase of 10 byte= s. If you think about it, this isn't too surprising, as the encrypted data= should contain no usable predictability/redundancy. Base64url encoding th= ese 536 bytes results in a 715 character payload - an increase of 189 chara= cters or 36%. Plus, adding "zip":"DEF" to the header adds 16 characters, f= or a total increase of 29 characters over the current situation. Clearly a= suboptimal choice! >=20 > CONCLUSION: Clearly, if we're going to enable reduction of the size of J= WS payloads, avoiding the double base64url encoding is preferable to zip, w= hich actually makes things worse. >=20 > QUESTION TO WORKING GROUP: I'm curious whether people would like to see = us enable avoiding double base64encoding of JWS payloads when they are alre= ady URL-safe. The space savings are significant; they come at the cost of = the JWS parsing becoming [part before first period . part between first and= last period . part after last period] rather than the current [part before= first period . part between first and second period . part after second pe= riod (with no other periods allowed)]. Opinions? >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of D= ick Hardt > Sent: Monday, October 29, 2012 8:57 AM > To: jose@ietf.org > Subject: [jose] signing an existing JWT >=20 >=20 > Let's say we have created a JWE as such: > =09 > headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integrit= ityVectorOne >=20 > This is now the payload to a JWS. Rather than increasing the token size b= y 4/3 by URL safe base 64 encoding the payload (since it is already URL saf= e), it would be useful to have a JWS header parameter that indicates the pa= yload was not re-encoded and does not need to be URL safe base 64 decoded. >=20 > As there are more periods than expected in a JWS, decoding would ignore a= ll periods except the first and last one for separating out the header, pay= load and signature. >=20 > The indicating parameter would seem to be either "tip" or "cty". I'm stil= l confused about the difference between the two parameters, so not sure whi= ch one is appropriate. >=20 > -- Dick >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Wed Dec 19 11:42:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9A21F886B for ; Wed, 19 Dec 2012 11:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7OafgP4Hf-A for ; Wed, 19 Dec 2012 11:42:19 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22F21F8801 for ; Wed, 19 Dec 2012 11:42:19 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id bh2so1533982pad.5 for ; Wed, 19 Dec 2012 11:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=U8Dqv9xROm2HnIhWlksFNX5yA8NyN4WRtvCIUtEIc/Y=; b=XRIkTHCW0rzjBiQl9zJaOFOFPWwjIcWQsZM+GgZuBpvYcrXviuoOo+YdfZpedxGN/5 apPiU2+i00KaPbOS19KdXHPtjhkbJKN+gnHeD/sPJgqdtGDmj4/TFmomFT+x4DkfZAj/ V8/bewrRvPRZSOvjxd89+12yZANN9djyO7G2zwdEbu0KyH+Ut70d0QLwgzT08OL6gYpD gScA0ciB/pucgiYddGCOX60GlObio8wpCkUOj+4d8SyLsz4qpYcvTNz1iRFxPPaGRAP1 V2yksgHV1I34mVZlzi00RsmghHnGZI+yrNS/JsbejKVjrO0txHVR+XHmGSUF10MmdBBJ hgEQ== X-Received: by 10.66.90.72 with SMTP id bu8mr20058905pab.69.1355946138916; Wed, 19 Dec 2012 11:42:18 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ug6sm3595817pbc.4.2012.12.19.11.42.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 11:42:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 19 Dec 2012 11:42:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 19:42:20 -0000 Hi Mike Either I don't understand your answer or you don't understand what I was = saying, so let me elaborate. If I am signing with the recipients public key and encrypting with my = private key, I need to have two 'kid' values and possible other = cryptography header values. -- Dick On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: > Hi Dick, >=20 > The way to do that with the current spec is to define a new composite = encryption/integrity algorithm that does what you want. For instance, = the "A128CBC+HS256" composite algorithm performs encryption with AES CBC = and the integrity check with HMAC SHA-256. I could imagine an = "A128CBC+ES256" algorithm that performs the encryption with AES CBC and = the integrity calculation with ECDSA P-256 SHA-256. The key for that = composite algorithm could be the concatenation of a 128-bit CBC key and = the ECDSA key. >=20 > For what it's worth, until draft -06, the block encryption algorithm = and the integrity algorithm were separately specified (in "enc" and = "int") parameters. The working group made a decision to only support = encryption algorithms that provided integrity - hence the use of = composite algorithms when using CBC (which doesn't provide integrity = itself. However, you still would have had to define a new "int" = algorithm even when they were separate, because the only integrity = algorithms specified were HS256, HS384, and HS512. >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Tuesday, December 18, 2012 6:45 PM > To: Mike Jones > Cc: jose@ietf.org; Dick Hardt > Subject: Re: [jose] Reducing the size of JWS payloads >=20 > Hi Mike >=20 > Thanks for bringing this up again.=20 >=20 > An alternative approach I proposed was to have both the encryption and = signing information in one header, and to use the signing signature to = ensure integrity instead of having a separate encryption integrity = check. This would reduce the size of the token by the size of the = integrity value +1 bytes, as well as reduce the processing. >=20 > Given that header properties are overloaded now (they have different = meanings depending on being a JWE or JWS, we could put the encryption = header values into a sub object in the header. Perhaps call that 'enc'. >=20 > -- Dick >=20 > The process below has=20 > On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >=20 >> I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >>=20 >> Dick proposed one method below - have a header parameter to say that = the payload is already URL-safe and that base64url encoding is not to be = performed. Another way that people have proposed is to allow the use of = the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>=20 >> CURRENT SITUATION: The JWE is 526 characters in length. Currently, = when used as a JWS payload, base64url encoding it would increase its = size to 702 characters - an increase of 33% or 176 characters. >>=20 >> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter = "b64":false to indicate that no additional base64url encoding is to be = performed, the payload would be 176 characters smaller than the current = situation. The encoded header size would increase by 16 characters - = the number of characters needed to base64url encode this header = parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>=20 >> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on = this input results in a LARGER output - 536 bytes or a net increase of = 10 bytes. If you think about it, this isn't too surprising, as the = encrypted data should contain no usable predictability/redundancy. = Base64url encoding these 536 bytes results in a 715 character payload - = an increase of 189 characters or 36%. Plus, adding "zip":"DEF" to the = header adds 16 characters, for a total increase of 29 characters over = the current situation. Clearly a suboptimal choice! >>=20 >> CONCLUSION: Clearly, if we're going to enable reduction of the size = of JWS payloads, avoiding the double base64url encoding is preferable to = zip, which actually makes things worse. >>=20 >> QUESTION TO WORKING GROUP: I'm curious whether people would like to = see us enable avoiding double base64encoding of JWS payloads when they = are already URL-safe. The space savings are significant; they come at = the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt >> Sent: Monday, October 29, 2012 8:57 AM >> To: jose@ietf.org >> Subject: [jose] signing an existing JWT >>=20 >>=20 >> Let's say we have created a JWE as such: >> =09 >> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>=20 >> This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>=20 >> As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >>=20 >> The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate. >>=20 >> -- Dick >>=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 From Michael.Jones@microsoft.com Wed Dec 19 11:49:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0421F8742 for ; Wed, 19 Dec 2012 11:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgVnSyqMRHrX for ; Wed, 19 Dec 2012 11:49:03 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9085421F85FC for ; Wed, 19 Dec 2012 11:49:02 -0800 (PST) Received: from BY2FFO11FD008.protection.gbl (10.1.15.201) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 19 Dec 2012 19:48:53 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 19:48:52 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 19:48:24 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sAAkEbRA Date: Wed, 19 Dec 2012 19:48:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115041F5FFC@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.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366977627TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(512874001)(46102001)(77982001)(54316002)(59766001)(56776001)(47736001)(47976001)(55846006)(74502001)(15202345001)(53806001)(4396001)(56816002)(33656001)(51856001)(47446002)(76482001)(49866001)(5343635001)(5343655001)(16236675001)(44976002)(16406001)(50986001)(54356001)(74662001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 070092A9D3 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 19:49:04 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366977627TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcemlw4oCdIGlzIGEgcGVyZmVjdCBleGFtcGxlIG9mIGluZGljYXRpbmcgYSBjaGFuZ2Ugb2Yg c2VtYW50aWNzIHdpdGggdGhlIHByZXNlbmNlIG9mIGEgbmV3IGZpZWxkLiAgVGhlIHByb2Nlc3Np bmcgb2YgYSBKV0Ugd2l0aG91dCBhIOKAnHppcOKAnSBmaWVsZCBpcyBkaWZmZXJlbnQgdGhhbiB0 aGUgcHJvY2Vzc2luZyBvZiBpdCB3aXRoIG9uZS4gIEFuIGltcGxlbWVudGF0aW9uIG11c3QgdW5k ZXJzdGFuZCB0aGUgZmllbGQgdG8gdXNlIHRoZSByZXN1bHRpbmcgSldFLiAgVGhlIHNhbWUgd291 bGQgYmUgdHJ1ZSBvZiBhbnkgSldTIHRoYXQgdXNlZCBhIOKAnHppcOKAnSBleHRlbnNpb24uDQoN Ckl0IHdvdWxkIG5ldmVyIGJlIHNhZmUgdG8gaWdub3JlIHRoaXMgZmllbGQsIHdoZXRoZXIgZGVm aW5lZCBhcyBwYXJ0IG9mIHRoZSBiYXNlIHNwZWMsIG9yIGRlZmluZWQgYXMgYW4gZXh0ZW5zaW9u IGxhdGVyLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpQLlMuICBPbiBhIHJlbGF0ZWQgdG9waWMsIHNl ZSB0aGUgdGhyZWFkIOKAnFJlZHVjaW5nIHRoZSBzaXplIG9mIEpXUyBwYXlsb2Fkc+KAnSBmb3Ig YSBkaXNjdXNzaW9uIG9uIHdoeSBjb21wcmVzc2lvbiB3b27igJl0IHdvcmsgZm9yIEpXUyBwYXls b2FkcyB0aGF0IGFyZSBKV0VzLg0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1l cy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTgs IDIwMTIgOToxMiBQTQ0KVG86IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbam9zZV0gV2hldGhlciBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5kIGFsbCBKT1NF IGhlYWRlciBmaWVsZHMNCg0KSmFtZXMgc2FpZDoNCj4+IEkgd291bGQgYWxzbyBhcHByZWNpYXRl IHlvdXIgdGhvdWdodHMgb24gd2hldGhlciBzb21lb25lIGNhbiBleHRlbmQgSldTIGJ5IHNwZWNp Znlpbmc6IHdoZW4gdGhlIOKAnHppcOKAnSBmaWVsZCBpcyBwcmVzZW50IGluIGEgSldTIHRoZSBj b250ZW50IGlzIGNvbXByZXNzZWQuDQpUaGF0IGxvb2tzIGxlZ2l0aW1hdGUgd2l0aCB0aGUgY3Vy cmVudCDigJxNVVNUIHVuZGVyc3RhbmQgb3IgcmVqZWN04oCdIHJ1bGUuIEkgdGhpbmsgaXQgaXMg bGlrZWx5LCBob3dldmVyLCB0aGF0IHN1Y2ggYW4gZXh0ZW5zaW9uIHdpbGwgY2F1c2Ugc2VjdXJp dHkgcHJvYmxlbXMuIFNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwgY29uZmlybSB0aGF0IOKAnHpp cOKAnSBpcyBvbiB0aGUgbGlzdCBvZiBrbm93biBzdGFuZGFyZCBmaWVsZHMsIGJ1dCB3aWxsIGln bm9yZSBpdCBpbiB0aGUgSldTIHByb2Nlc3NpbmcgY29kZS4NCg0KTWlrZSBzYWlkOg0KPiBPbmUg d291bGQgZGVmaW5lIOKAnHppcOKAnSBpbiBhIEpXUyBpbiB0aGUgbm9ybWFsIHdheSB0aGF0IGV4 dGVuc2lvbnMgYXJlIG1hZGUgdG8gSUVURiBzcGVjcyDigJMgeW914oCZZCB3cml0ZSBhIHNwZWMg ZGVmaW5pbmcgdGhlIG1lYW5pbmcgZm9yIGl0IGFuZCByZWdpc3RlciB0aGUg4oCcemlw4oCdIHZh bHVlIGluIHRoZSBJQU5BIEpTT04gV2ViIFNpZ25hdHVyZSBhbmQgRW5jcnlwdGlvbiBIZWFkZXIg UGFyYW1ldGVycyByZWdpc3RyeSBmb3IgSldTIHVzYWdlLg0KDQoNCkxldHMgaWdub3JlIHRoZSBw cm9jZXNzIGZvciBub3cgKElFVEYsIElBTkHigKYpLCB0aGUgaXNzdWUgaXMgd2hldGhlciB0aGlz IHN0eWxlIG9mIGV4dGVuc2lvbiBpcyBzZW5zaWJsZTogYW4gZXh0ZW5zaW9uIHRoYXQgaW5kaWNh dGVzIGEgY2hhbmdlIG9mIHNlbWFudGljcyBieSB0aGUgcHJlc2VuY2Ugb2YgYSBuZXcgZmllbGQu IEEgc3R5bGUgdGhhdCB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcnVsZSBl bmNvdXJhZ2VzLg0KTXkgYXJndW1lbnQgaXMgdGhhdCB0aGlzIHN0eWxlIGlzIHRvbyBkYW5nZXJv dXMgYSB3YXkgdG8gaW5kaWNhdGUgbmV3IHNlbWFudGljcy4gV2hlbiBjaGFuZ2luZyBzZW1hbnRp Y3MgKGFzIOKAnHppcOKAnSBkb2VzKSBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBjaGFuZ2Ug YSBmaWVsZCB3ZSBhcmUgY29uZmlkZW50IGltcGxlbWVudGF0aW9ucyB3aWxsIGJlIGxvb2tpbmcg YXQsIGFzIG9wcG9zZWQgdG8gcmVseWluZyBvbiB0aGVtIHRvIG5vdGljZSBhIG5ldyBmaWVsZC4N Cg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_4E1F6AAD24975D4BA5B168042967394366977627TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj7igJx6aXDigJ0gaXMgYSBw ZXJmZWN0IGV4YW1wbGUgb2YgaW5kaWNhdGluZyBhIGNoYW5nZSBvZiBzZW1hbnRpY3Mgd2l0aCB0 aGUgcHJlc2VuY2Ugb2YgYSBuZXcgZmllbGQuJm5ic3A7IFRoZSBwcm9jZXNzaW5nIG9mIGEgSldF IHdpdGhvdXQgYSDigJx6aXDigJ0gZmllbGQgaXMgZGlmZmVyZW50IHRoYW4gdGhlIHByb2Nlc3Np bmcgb2YgaXQgd2l0aCBvbmUuJm5ic3A7IEFuIGltcGxlbWVudGF0aW9uDQogbXVzdCB1bmRlcnN0 YW5kIHRoZSBmaWVsZCB0byB1c2UgdGhlIHJlc3VsdGluZyBKV0UuJm5ic3A7IFRoZSBzYW1lIHdv dWxkIGJlIHRydWUgb2YgYW55IEpXUyB0aGF0IHVzZWQgYSDigJx6aXDigJ0gZXh0ZW5zaW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SXQgd291bGQgbmV2ZXIgYmUgc2Fm ZSB0byBpZ25vcmUgdGhpcyBmaWVsZCwgd2hldGhlciBkZWZpbmVkIGFzIHBhcnQgb2YgdGhlIGJh c2Ugc3BlYywgb3IgZGVmaW5lZCBhcyBhbiBleHRlbnNpb24gbGF0ZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UC5TLiZuYnNw OyBPbiBhIHJlbGF0ZWQgdG9waWMsIHNlZSB0aGUgdGhyZWFkIOKAnFJlZHVjaW5nIHRoZSBzaXpl IG9mIEpXUyBwYXlsb2Fkc+KAnSBmb3IgYSBkaXNjdXNzaW9uIG9uIHdoeSBjb21wcmVzc2lvbiB3 b27igJl0IHdvcmsgZm9yIEpXUyBwYXlsb2FkcyB0aGF0IGFyZSBKV0VzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hbmdlciwg SmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMTgsIDIwMTIgOToxMiBQTTxicj4NCjxiPlRv OjwvYj4gTWlrZSBKb25lczsgam9zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W2pvc2VdIFdoZXRoZXIgaW1wbGVtZW50YXRpb25zIG11c3QgdW5kZXJzdGFuZCBhbGwgSk9TRSBo ZWFkZXIgZmllbGRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkphbWVzIHNhaWQ6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBJIHdvdWxkIGFsc28gYXBwcmVjaWF0ZSB5b3VyIHRob3Vn aHRzIG9uIHdoZXRoZXIgc29tZW9uZSBjYW4gZXh0ZW5kIEpXUyBieSBzcGVjaWZ5aW5nOiB3aGVu IHRoZSDigJx6aXDigJ0gZmllbGQgaXMgcHJlc2VudCBpbiBhIEpXUyB0aGUgY29udGVudCBpcyBj b21wcmVzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhdCBsb29rcyBsZWdpdGlt YXRlIHdpdGggdGhlIGN1cnJlbnQg4oCcTVVTVCB1bmRlcnN0YW5kIG9yIHJlamVjdOKAnSBydWxl LiBJIHRoaW5rIGl0IGlzIGxpa2VseSwgaG93ZXZlciwgdGhhdCBzdWNoIGFuIGV4dGVuc2lvbiB3 aWxsIGNhdXNlIHNlY3VyaXR5IHByb2JsZW1zLiBTb21lIGltcGxlbWVudGF0aW9ucyB3aWxsIGNv bmZpcm0gdGhhdA0KIOKAnHppcOKAnSBpcyBvbiB0aGUgbGlzdCBvZiBrbm93biBzdGFuZGFyZCBm aWVsZHMsIGJ1dCB3aWxsIGlnbm9yZSBpdCBpbiB0aGUgSldTIHByb2Nlc3NpbmcgY29kZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1pa2Ugc2FpZDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jmd0OyBPbmUgd291bGQgZGVmaW5lIOKAnHppcOKAnSBpbiBhIEpXUyBpbiB0aGUgbm9ybWFs IHdheSB0aGF0IGV4dGVuc2lvbnMgYXJlIG1hZGUgdG8gSUVURiBzcGVjcyDigJMgeW914oCZZCB3 cml0ZSBhIHNwZWMgZGVmaW5pbmcgdGhlIG1lYW5pbmcgZm9yIGl0IGFuZCByZWdpc3RlciB0aGUg 4oCcemlw4oCdIHZhbHVlIGluIHRoZSBJQU5BIEpTT04gV2ViIFNpZ25hdHVyZSBhbmQgRW5jcnlw dGlvbg0KIEhlYWRlciBQYXJhbWV0ZXJzIHJlZ2lzdHJ5IGZvciBKV1MgdXNhZ2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGV0cyBpZ25vcmUgdGhlIHByb2Nlc3Mg Zm9yIG5vdyAoSUVURiwgSUFOQeKApiksIHRoZSBpc3N1ZSBpcyB3aGV0aGVyIHRoaXMNCjxpPnN0 eWxlPC9pPiBvZiBleHRlbnNpb24gaXMgc2Vuc2libGU6IGFuIGV4dGVuc2lvbiB0aGF0IGluZGlj YXRlcyBhIGNoYW5nZSBvZiBzZW1hbnRpY3MgYnkgdGhlIHByZXNlbmNlIG9mIGEgbmV3IGZpZWxk LiBBIHN0eWxlIHRoYXQgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBldmVyeXRoaW5n4oCdIHJ1bGUg ZW5jb3VyYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk15IGFyZ3VtZW50IGlzIHRo YXQgdGhpcyBzdHlsZSBpcyB0b28gZGFuZ2Vyb3VzIGEgd2F5IHRvIGluZGljYXRlIG5ldyBzZW1h bnRpY3MuIFdoZW4gY2hhbmdpbmcgc2VtYW50aWNzIChhcyDigJx6aXDigJ0gZG9lcykgaXQgd291 bGQgYmUgbXVjaCBiZXR0ZXIgdG8gY2hhbmdlIGEgZmllbGQgd2UgYXJlIGNvbmZpZGVudCBpbXBs ZW1lbnRhdGlvbnMNCiB3aWxsIGJlIGxvb2tpbmcgYXQsIGFzIG9wcG9zZWQgdG8gcmVseWluZyBv biB0aGVtIHRvIG5vdGljZSBhIG5ldyBmaWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B168042967394366977627TK5EX14MBXC283r_-- From dick.hardt@gmail.com Wed Dec 19 12:03:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424B121F878F for ; Wed, 19 Dec 2012 12:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2AzIs+EObXk for ; Wed, 19 Dec 2012 12:03:17 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 55EC221F84C7 for ; Wed, 19 Dec 2012 12:03:17 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so1102461dak.16 for ; Wed, 19 Dec 2012 12:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ZRMMWbQhTePvHYZlcQ2fLpNtGdyB7TnsexWZsKWhLu8=; b=q4vhHIgiSivY2q8raveNC9eRsFFHF+2AC5SZorfJ9U22OvS3U68jTcjoqAeskZAqWq HcrtTrqA4xmk1GWROABDN3IXkXcvHgOGKN3at9ycBxx+M98icR/ifhnU+A3MFndyfVRg hjUDdthTpb+RPSYBeEtk64IB4mrBLjtuzwMpMwm/bLkkkYt8yoCJgs3PhnEAo278vpFb z9EC2FF7H6yLh2esMcNrTr2NNkkS/XAwNFmbfEvBBzjzTiYw4SJ4eoQa/vZD4WTzS++V i2mFVPlx2YV/5HoDeadVds0N85ZhtDCuO5H6i8qKlNCyD95Qeu05bx3cXuT9r8nRbUpj ih4g== X-Received: by 10.66.87.133 with SMTP id ay5mr20286078pab.59.1355947397001; Wed, 19 Dec 2012 12:03:17 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id bc1sm3951628pab.3.2012.12.19.12.03.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 12:03:15 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Wed, 19 Dec 2012 12:02:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 20:03:18 -0000 Um, yeah. I have the keys backwards. If I am signing with my private key and encrypting with the recipients = public key =85=20 On Dec 19, 2012, at 11:42 AM, Dick Hardt wrote: > Hi Mike >=20 > Either I don't understand your answer or you don't understand what I = was saying, so let me elaborate. >=20 > If I am signing with the recipients public key and encrypting with my = private key, I need to have two 'kid' values and possible other = cryptography header values. >=20 > -- Dick >=20 > On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: >=20 >> Hi Dick, >>=20 >> The way to do that with the current spec is to define a new composite = encryption/integrity algorithm that does what you want. For instance, = the "A128CBC+HS256" composite algorithm performs encryption with AES CBC = and the integrity check with HMAC SHA-256. I could imagine an = "A128CBC+ES256" algorithm that performs the encryption with AES CBC and = the integrity calculation with ECDSA P-256 SHA-256. The key for that = composite algorithm could be the concatenation of a 128-bit CBC key and = the ECDSA key. >>=20 >> For what it's worth, until draft -06, the block encryption algorithm = and the integrity algorithm were separately specified (in "enc" and = "int") parameters. The working group made a decision to only support = encryption algorithms that provided integrity - hence the use of = composite algorithms when using CBC (which doesn't provide integrity = itself. However, you still would have had to define a new "int" = algorithm even when they were separate, because the only integrity = algorithms specified were HS256, HS384, and HS512. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt >> Sent: Tuesday, December 18, 2012 6:45 PM >> To: Mike Jones >> Cc: jose@ietf.org; Dick Hardt >> Subject: Re: [jose] Reducing the size of JWS payloads >>=20 >> Hi Mike >>=20 >> Thanks for bringing this up again.=20 >>=20 >> An alternative approach I proposed was to have both the encryption = and signing information in one header, and to use the signing signature = to ensure integrity instead of having a separate encryption integrity = check. This would reduce the size of the token by the size of the = integrity value +1 bytes, as well as reduce the processing. >>=20 >> Given that header properties are overloaded now (they have different = meanings depending on being a JWE or JWS, we could put the encryption = header values into a sub object in the header. Perhaps call that 'enc'. >>=20 >> -- Dick >>=20 >> The process below has=20 >> On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >>=20 >>> I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >>>=20 >>> Dick proposed one method below - have a header parameter to say that = the payload is already URL-safe and that base64url encoding is not to be = performed. Another way that people have proposed is to allow the use of = the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>>=20 >>> CURRENT SITUATION: The JWE is 526 characters in length. Currently, = when used as a JWS payload, base64url encoding it would increase its = size to 702 characters - an increase of 33% or 176 characters. >>>=20 >>> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter = "b64":false to indicate that no additional base64url encoding is to be = performed, the payload would be 176 characters smaller than the current = situation. The encoded header size would increase by 16 characters - = the number of characters needed to base64url encode this header = parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>>=20 >>> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE = on this input results in a LARGER output - 536 bytes or a net increase = of 10 bytes. If you think about it, this isn't too surprising, as the = encrypted data should contain no usable predictability/redundancy. = Base64url encoding these 536 bytes results in a 715 character payload - = an increase of 189 characters or 36%. Plus, adding "zip":"DEF" to the = header adds 16 characters, for a total increase of 29 characters over = the current situation. Clearly a suboptimal choice! >>>=20 >>> CONCLUSION: Clearly, if we're going to enable reduction of the size = of JWS payloads, avoiding the double base64url encoding is preferable to = zip, which actually makes things worse. >>>=20 >>> QUESTION TO WORKING GROUP: I'm curious whether people would like to = see us enable avoiding double base64encoding of JWS payloads when they = are already URL-safe. The space savings are significant; they come at = the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt >>> Sent: Monday, October 29, 2012 8:57 AM >>> To: jose@ietf.org >>> Subject: [jose] signing an existing JWT >>>=20 >>>=20 >>> Let's say we have created a JWE as such: >>> =09 >>> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>>=20 >>> This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>>=20 >>> As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >>>=20 >>> The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate. >>>=20 >>> -- Dick >>>=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 >=20 From rbarnes@bbn.com Wed Dec 19 13:31:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096F321F85A7 for ; Wed, 19 Dec 2012 13:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS5DisHhOML0 for ; Wed, 19 Dec 2012 13:31:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B342B21F85BA for ; Wed, 19 Dec 2012 13:31:56 -0800 (PST) Received: from dhcp-192-1-255-192.col.bbn.com ([192.1.255.192]:57202) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TlRF4-000OTC-0H; Wed, 19 Dec 2012 16:31:54 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: Date: Wed, 19 Dec 2012 16:31:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 21:31:58 -0000 In which order? Just having two "kid" values seems ambiguous. On Dec 19, 2012, at 3:02 PM, Dick Hardt wrote: > Um, yeah. >=20 > I have the keys backwards. >=20 > If I am signing with my private key and encrypting with the recipients = public key =85=20 >=20 > On Dec 19, 2012, at 11:42 AM, Dick Hardt wrote: >=20 >> Hi Mike >>=20 >> Either I don't understand your answer or you don't understand what I = was saying, so let me elaborate. >>=20 >> If I am signing with the recipients public key and encrypting with my = private key, I need to have two 'kid' values and possible other = cryptography header values. >>=20 >> -- Dick >>=20 >> On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: >>=20 >>> Hi Dick, >>>=20 >>> The way to do that with the current spec is to define a new = composite encryption/integrity algorithm that does what you want. For = instance, the "A128CBC+HS256" composite algorithm performs encryption = with AES CBC and the integrity check with HMAC SHA-256. I could imagine = an "A128CBC+ES256" algorithm that performs the encryption with AES CBC = and the integrity calculation with ECDSA P-256 SHA-256. The key for = that composite algorithm could be the concatenation of a 128-bit CBC key = and the ECDSA key. >>>=20 >>> For what it's worth, until draft -06, the block encryption algorithm = and the integrity algorithm were separately specified (in "enc" and = "int") parameters. The working group made a decision to only support = encryption algorithms that provided integrity - hence the use of = composite algorithms when using CBC (which doesn't provide integrity = itself. However, you still would have had to define a new "int" = algorithm even when they were separate, because the only integrity = algorithms specified were HS256, HS384, and HS512. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt >>> Sent: Tuesday, December 18, 2012 6:45 PM >>> To: Mike Jones >>> Cc: jose@ietf.org; Dick Hardt >>> Subject: Re: [jose] Reducing the size of JWS payloads >>>=20 >>> Hi Mike >>>=20 >>> Thanks for bringing this up again.=20 >>>=20 >>> An alternative approach I proposed was to have both the encryption = and signing information in one header, and to use the signing signature = to ensure integrity instead of having a separate encryption integrity = check. This would reduce the size of the token by the size of the = integrity value +1 bytes, as well as reduce the processing. >>>=20 >>> Given that header properties are overloaded now (they have different = meanings depending on being a JWE or JWS, we could put the encryption = header values into a sub object in the header. Perhaps call that 'enc'. >>>=20 >>> -- Dick >>>=20 >>> The process below has=20 >>> On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >>>=20 >>>> I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >>>>=20 >>>> Dick proposed one method below - have a header parameter to say = that the payload is already URL-safe and that base64url encoding is not = to be performed. Another way that people have proposed is to allow the = use of the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>>>=20 >>>> CURRENT SITUATION: The JWE is 526 characters in length. = Currently, when used as a JWS payload, base64url encoding it would = increase its size to 702 characters - an increase of 33% or 176 = characters. >>>>=20 >>>> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter = "b64":false to indicate that no additional base64url encoding is to be = performed, the payload would be 176 characters smaller than the current = situation. The encoded header size would increase by 16 characters - = the number of characters needed to base64url encode this header = parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>>>=20 >>>> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE = on this input results in a LARGER output - 536 bytes or a net increase = of 10 bytes. If you think about it, this isn't too surprising, as the = encrypted data should contain no usable predictability/redundancy. = Base64url encoding these 536 bytes results in a 715 character payload - = an increase of 189 characters or 36%. Plus, adding "zip":"DEF" to the = header adds 16 characters, for a total increase of 29 characters over = the current situation. Clearly a suboptimal choice! >>>>=20 >>>> CONCLUSION: Clearly, if we're going to enable reduction of the = size of JWS payloads, avoiding the double base64url encoding is = preferable to zip, which actually makes things worse. >>>>=20 >>>> QUESTION TO WORKING GROUP: I'm curious whether people would like = to see us enable avoiding double base64encoding of JWS payloads when = they are already URL-safe. The space savings are significant; they come = at the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>> Sent: Monday, October 29, 2012 8:57 AM >>>> To: jose@ietf.org >>>> Subject: [jose] signing an existing JWT >>>>=20 >>>>=20 >>>> Let's say we have created a JWE as such: >>>> =09 >>>> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>>>=20 >>>> This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>>>=20 >>>> As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >>>>=20 >>>> The indicating parameter would seem to be either "tip" or "cty". = I'm still confused about the difference between the two parameters, so = not sure which one is appropriate. >>>>=20 >>>> -- Dick >>>>=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 >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Wed Dec 19 13:45:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0415221F87BD for ; Wed, 19 Dec 2012 13:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrHD9izKjdGu for ; Wed, 19 Dec 2012 13:45:38 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0481321F853E for ; Wed, 19 Dec 2012 13:45:37 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id xa7so1497269pbc.14 for ; Wed, 19 Dec 2012 13:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=jSxkcHdH9I/TjG7yQ2iKVMkbOIjZai4RiWhabWTFin8=; b=Qbo89x4BQLq8QNSZmtKJ9YQJ/YpZeNqgrlJJ2UJ1KL7fuV2EL62JHwiEq5txPNDRN8 8ScDSSa/RqGY3oFIXqcfoaSdBkW/1rGu/eFA4qI4Z46Kc94xhtnuog2j4vqgkRkkm6kW hBeSwvE3CrdMKxTr5O/yllV0LMjHE2kyT9GzkKp7Ghvwe4kPoyYr9v9p+DA7riddBU5i 0dzfJQQn+TVnWonZjjOraluPGXZepbKdhI+4b/xwMuesGo62GGQ5W/oPPbVO7I9oeTaQ ANM36z/wliipbY5jHSYfGuQMVoqYEEnSoX4MQfASWNcu1RBz+V2V6aF8ufXLdH1STXwB CC9Q== X-Received: by 10.66.83.136 with SMTP id q8mr20924374pay.83.1355953537722; Wed, 19 Dec 2012 13:45:37 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id j1sm4071231pax.10.2012.12.19.13.45.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 13:45:36 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Wed, 19 Dec 2012 13:45:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Richard Barnes X-Mailer: Apple Mail (2.1499) Cc: Mike Jones , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 21:45:39 -0000 That is why one would be in the 'enc' sub-object, something like this: {=20 , 'kid': // signing key id , 'alg': // signing algorithm , 'enc':=20 { 'kid': // encryption key id , 'alg': // encryption algorithm } } On Dec 19, 2012, at 1:31 PM, Richard Barnes wrote: > In which order? Just having two "kid" values seems ambiguous. >=20 >=20 > On Dec 19, 2012, at 3:02 PM, Dick Hardt wrote: >=20 >> Um, yeah. >>=20 >> I have the keys backwards. >>=20 >> If I am signing with my private key and encrypting with the = recipients public key =85=20 >>=20 >> On Dec 19, 2012, at 11:42 AM, Dick Hardt = wrote: >>=20 >>> Hi Mike >>>=20 >>> Either I don't understand your answer or you don't understand what I = was saying, so let me elaborate. >>>=20 >>> If I am signing with the recipients public key and encrypting with = my private key, I need to have two 'kid' values and possible other = cryptography header values. >>>=20 >>> -- Dick >>>=20 >>> On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: >>>=20 >>>> Hi Dick, >>>>=20 >>>> The way to do that with the current spec is to define a new = composite encryption/integrity algorithm that does what you want. For = instance, the "A128CBC+HS256" composite algorithm performs encryption = with AES CBC and the integrity check with HMAC SHA-256. I could imagine = an "A128CBC+ES256" algorithm that performs the encryption with AES CBC = and the integrity calculation with ECDSA P-256 SHA-256. The key for = that composite algorithm could be the concatenation of a 128-bit CBC key = and the ECDSA key. >>>>=20 >>>> For what it's worth, until draft -06, the block encryption = algorithm and the integrity algorithm were separately specified (in = "enc" and "int") parameters. The working group made a decision to only = support encryption algorithms that provided integrity - hence the use of = composite algorithms when using CBC (which doesn't provide integrity = itself. However, you still would have had to define a new "int" = algorithm even when they were separate, because the only integrity = algorithms specified were HS256, HS384, and HS512. >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>> Sent: Tuesday, December 18, 2012 6:45 PM >>>> To: Mike Jones >>>> Cc: jose@ietf.org; Dick Hardt >>>> Subject: Re: [jose] Reducing the size of JWS payloads >>>>=20 >>>> Hi Mike >>>>=20 >>>> Thanks for bringing this up again.=20 >>>>=20 >>>> An alternative approach I proposed was to have both the encryption = and signing information in one header, and to use the signing signature = to ensure integrity instead of having a separate encryption integrity = check. This would reduce the size of the token by the size of the = integrity value +1 bytes, as well as reduce the processing. >>>>=20 >>>> Given that header properties are overloaded now (they have = different meanings depending on being a JWE or JWS, we could put the = encryption header values into a sub object in the header. Perhaps call = that 'enc'. >>>>=20 >>>> -- Dick >>>>=20 >>>> The process below has=20 >>>> On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >>>>=20 >>>>> I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >>>>>=20 >>>>> Dick proposed one method below - have a header parameter to say = that the payload is already URL-safe and that base64url encoding is not = to be performed. Another way that people have proposed is to allow the = use of the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>>>>=20 >>>>> CURRENT SITUATION: The JWE is 526 characters in length. = Currently, when used as a JWS payload, base64url encoding it would = increase its size to 702 characters - an increase of 33% or 176 = characters. >>>>>=20 >>>>> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter = "b64":false to indicate that no additional base64url encoding is to be = performed, the payload would be 176 characters smaller than the current = situation. The encoded header size would increase by 16 characters - = the number of characters needed to base64url encode this header = parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>>>>=20 >>>>> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE = on this input results in a LARGER output - 536 bytes or a net increase = of 10 bytes. If you think about it, this isn't too surprising, as the = encrypted data should contain no usable predictability/redundancy. = Base64url encoding these 536 bytes results in a 715 character payload - = an increase of 189 characters or 36%. Plus, adding "zip":"DEF" to the = header adds 16 characters, for a total increase of 29 characters over = the current situation. Clearly a suboptimal choice! >>>>>=20 >>>>> CONCLUSION: Clearly, if we're going to enable reduction of the = size of JWS payloads, avoiding the double base64url encoding is = preferable to zip, which actually makes things worse. >>>>>=20 >>>>> QUESTION TO WORKING GROUP: I'm curious whether people would like = to see us enable avoiding double base64encoding of JWS payloads when = they are already URL-safe. The space savings are significant; they come = at the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>>> Sent: Monday, October 29, 2012 8:57 AM >>>>> To: jose@ietf.org >>>>> Subject: [jose] signing an existing JWT >>>>>=20 >>>>>=20 >>>>> Let's say we have created a JWE as such: >>>>> =09 >>>>> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>>>>=20 >>>>> This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>>>>=20 >>>>> As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >>>>>=20 >>>>> The indicating parameter would seem to be either "tip" or "cty". = I'm still confused about the difference between the two parameters, so = not sure which one is appropriate. >>>>>=20 >>>>> -- Dick >>>>>=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 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From Michael.Jones@microsoft.com Wed Dec 19 14:06:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3E021F8577 for ; Wed, 19 Dec 2012 14:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.783 X-Spam-Level: X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D84-dCClybZ1 for ; Wed, 19 Dec 2012 14:06:59 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id BA3EB21F854F for ; Wed, 19 Dec 2012 14:06:58 -0800 (PST) Received: from BL2FFO11FD015.protection.gbl (10.173.161.204) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.578.12; Wed, 19 Dec 2012 22:06:55 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 22:06:55 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 22:06:08 +0000 From: Mike Jones To: Dick Hardt , Richard Barnes Thread-Topic: [jose] Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgAAqR2AACLdd6AAAKdfAAAAs7UAAAMgpIAAAHm+AAAAiHNQ Date: Wed, 19 Dec 2012 22:06:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366977921@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52604002)(51704002)(377454001)(24454001)(13464002)(15202345001)(56776001)(47776002)(47446002)(74662001)(5343635001)(53806001)(33656001)(51856001)(55846006)(76482001)(44976002)(56816002)(54356001)(16406001)(46406002)(23726001)(59766001)(550184003)(54316002)(77982001)(49866001)(31966008)(5343655001)(50986001)(4396001)(47976001)(74502001)(50466001)(47736001)(46102001)(503574001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 070092A9D3 Cc: "jose@ietf.org" Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 22:07:00 -0000 That's a much bigger structural change. If what you're trying to do is to = avoid the overhead of integrity protecting the content twice, instead, whil= e this may be heretical to some, you could create a JWE with AES CBC and an= empty integrity check value ("enc":"A128CBC") and then use that as a JWS p= ayload. It would mean that we would once again have an encryption algorith= m with no integrity check. That could be accompanied with Security Conside= rations caveats that this algorithm MAY NOT be used unless the resulting JW= E was integrity checked through other means, such as being used as the payl= oad of a JWS with an appropriate signature/MAC algorithm. The upside of that approach is that you'd have two separate sets of headers= for the two different operations without making significant syntax changes= to the JWE header format. -- Mike -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Wednesday, December 19, 2012 1:46 PM To: Richard Barnes Cc: Dick Hardt; Mike Jones; jose@ietf.org Subject: Re: [jose] Reducing the size of JWS payloads That is why one would be in the 'enc' sub-object, something like this: {=20 , 'kid': // signing key id , 'alg': // signing algorithm , 'enc':=20 { 'kid': // encryption key id , 'alg': // encryption algorithm } } On Dec 19, 2012, at 1:31 PM, Richard Barnes wrote: > In which order? Just having two "kid" values seems ambiguous. >=20 >=20 > On Dec 19, 2012, at 3:02 PM, Dick Hardt wrote: >=20 >> Um, yeah. >>=20 >> I have the keys backwards. >>=20 >> If I am signing with my private key and encrypting with the recipients p= ublic key ...=20 >>=20 >> On Dec 19, 2012, at 11:42 AM, Dick Hardt wrote: >>=20 >>> Hi Mike >>>=20 >>> Either I don't understand your answer or you don't understand what I wa= s saying, so let me elaborate. >>>=20 >>> If I am signing with the recipients public key and encrypting with my p= rivate key, I need to have two 'kid' values and possible other cryptography= header values. >>>=20 >>> -- Dick >>>=20 >>> On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: >>>=20 >>>> Hi Dick, >>>>=20 >>>> The way to do that with the current spec is to define a new composite = encryption/integrity algorithm that does what you want. For instance, the = "A128CBC+HS256" composite algorithm performs encryption with AES CBC and th= e integrity check with HMAC SHA-256. I could imagine an "A128CBC+ES256" al= gorithm that performs the encryption with AES CBC and the integrity calcula= tion with ECDSA P-256 SHA-256. The key for that composite algorithm could = be the concatenation of a 128-bit CBC key and the ECDSA key. >>>>=20 >>>> For what it's worth, until draft -06, the block encryption algorithm a= nd the integrity algorithm were separately specified (in "enc" and "int") p= arameters. The working group made a decision to only support encryption al= gorithms that provided integrity - hence the use of composite algorithms wh= en using CBC (which doesn't provide integrity itself. However, you still w= ould have had to define a new "int" algorithm even when they were separate,= because the only integrity algorithms specified were HS256, HS384, and HS5= 12. >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf O= f Dick Hardt >>>> Sent: Tuesday, December 18, 2012 6:45 PM >>>> To: Mike Jones >>>> Cc: jose@ietf.org; Dick Hardt >>>> Subject: Re: [jose] Reducing the size of JWS payloads >>>>=20 >>>> Hi Mike >>>>=20 >>>> Thanks for bringing this up again.=20 >>>>=20 >>>> An alternative approach I proposed was to have both the encryption and= signing information in one header, and to use the signing signature to ens= ure integrity instead of having a separate encryption integrity check. This= would reduce the size of the token by the size of the integrity value +1 b= ytes, as well as reduce the processing. >>>>=20 >>>> Given that header properties are overloaded now (they have different m= eanings depending on being a JWE or JWS, we could put the encryption header= values into a sub object in the header. Perhaps call that 'enc'. >>>>=20 >>>> -- Dick >>>>=20 >>>> The process below has=20 >>>> On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >>>>=20 >>>>> I've noticed that more than one person has expressed a desire to redu= ce the size of JWS payloads before signing. This especially comes up when = nested encryption and signing is being performed. This note contains a qua= ntitative evaluation of some possible methods of reducing JWS payload size = and asks for working group input based upon the data. >>>>>=20 >>>>> Dick proposed one method below - have a header parameter to say that = the payload is already URL-safe and that base64url encoding is not to be pe= rformed. Another way that people have proposed is to allow the use of the = "zip" parameter to compress the JWS payload before base64url encoding. To = get some initial data on how the solutions compare, I tried both methods us= ing the sample JWE value in http://tools.ietf.org/html/draft-ietf-jose-json= -web-encryption-07#appendix-A.2 as the JWS payload. >>>>>=20 >>>>> CURRENT SITUATION: The JWE is 526 characters in length. Currently, = when used as a JWS payload, base64url encoding it would increase its size t= o 702 characters - an increase of 33% or 176 characters. >>>>>=20 >>>>> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter "b= 64":false to indicate that no additional base64url encoding is to be perfor= med, the payload would be 176 characters smaller than the current situation= . The encoded header size would increase by 16 characters - the number of = characters needed to base64url encode this header parameter value and a com= ma, for a net decrease in size of 160 characters. (Yes, parsing the three = pieces would be slightly more difficult.) >>>>>=20 >>>>> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on= this input results in a LARGER output - 536 bytes or a net increase of 10 = bytes. If you think about it, this isn't too surprising, as the encrypted = data should contain no usable predictability/redundancy. Base64url encodin= g these 536 bytes results in a 715 character payload - an increase of 189 c= haracters or 36%. Plus, adding "zip":"DEF" to the header adds 16 character= s, for a total increase of 29 characters over the current situation. Clear= ly a suboptimal choice! >>>>>=20 >>>>> CONCLUSION: Clearly, if we're going to enable reduction of the size = of JWS payloads, avoiding the double base64url encoding is preferable to zi= p, which actually makes things worse. >>>>>=20 >>>>> QUESTION TO WORKING GROUP: I'm curious whether people would like to = see us enable avoiding double base64encoding of JWS payloads when they are = already URL-safe. The space savings are significant; they come at the cost= of the JWS parsing becoming [part before first period . part between first= and last period . part after last period] rather than the current [part be= fore first period . part between first and second period . part after secon= d period (with no other periods allowed)]. Opinions? >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt >>>>> Sent: Monday, October 29, 2012 8:57 AM >>>>> To: jose@ietf.org >>>>> Subject: [jose] signing an existing JWT >>>>>=20 >>>>>=20 >>>>> Let's say we have created a JWE as such: >>>>> =09 >>>>> headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.inte= gritityVectorOne >>>>>=20 >>>>> This is now the payload to a JWS. Rather than increasing the token si= ze by 4/3 by URL safe base 64 encoding the payload (since it is already URL= safe), it would be useful to have a JWS header parameter that indicates th= e payload was not re-encoded and does not need to be URL safe base 64 decod= ed. >>>>>=20 >>>>> As there are more periods than expected in a JWS, decoding would igno= re all periods except the first and last one for separating out the header,= payload and signature. >>>>>=20 >>>>> The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not sure= which one is appropriate. >>>>>=20 >>>>> -- Dick >>>>>=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 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From ve7jtb@ve7jtb.com Wed Dec 19 14:28:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8500921F8421 for ; Wed, 19 Dec 2012 14:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hFSFHUFLqXi for ; Wed, 19 Dec 2012 14:28:25 -0800 (PST) Received: from mail-ye0-f174.google.com (mail-ye0-f174.google.com [209.85.213.174]) by ietfa.amsl.com (Postfix) with ESMTP id CAD9621F859A for ; Wed, 19 Dec 2012 14:28:24 -0800 (PST) Received: by mail-ye0-f174.google.com with SMTP id m6so600128yen.5 for ; Wed, 19 Dec 2012 14:28:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=J4J30Er5XKh4PkKXhwhISmM8hxM9oDsmNq66PnB3aO4=; b=TmaD0cPzxMiCtMu52JeyYeq8WNFWva1GvK45pFNOg3IL0uuyN0FmHi+oI3km9MwjaO gxwZOxirLrAjRpgtgyJHvwaXx9+iAZUOYo5iDgS7iC7ZrExgRt1svB2TFhDwoKe49Rch 4uF0jxUfdLwBGe81B/4Zgv9O8FqFOH2xaTJS9L8yczE7Q0icATCbQXn57kQzRt5qMi6j Ysd9Wgv2GByQOXpLHW1JCpcL4T9+28XPkcHa0YhrHj4F2FgBDD3/qEOgG5wRmcqnHyC2 ianeZH6zzPvSTZWe8i7XZA4AQ/plzcXApaV6Fq9QdH6kh8fx1pVln3Wvqto/MODSozcp Vi9Q== X-Received: by 10.236.204.72 with SMTP id g48mr7286220yho.102.1355956104142; Wed, 19 Dec 2012 14:28:24 -0800 (PST) Received: from [192.168.1.211] (190-20-21-85.baf.movistar.cl. [190.20.21.85]) by mx.google.com with ESMTPS id g77sm5831064yhi.14.2012.12.19.14.28.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 14:28:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366977921@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 19 Dec 2012 19:28:14 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8B456AF9-A6BE-447D-B256-4C197CF8F9D9@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366977921@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQl2k8ziPWJcZNjFPgTfd1GvA1tLqjlycSighdaU7mwqx/zAoZI8Su9/VVnogxm+voIbT8Ds Cc: Richard Barnes , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 22:28:26 -0000 If you are using a asymmetric signature for any sort of non repudiation = you generally do the signature before encryption. =20 Most regulations don't recognize signatures over encrypted data as = enforcable. Signing and then encrypting with compression and integrity is I think a = more common use case that you didn't test for size. The signed body shield compress just fine, while the RSA signature = itself I admit won't be compressed. If you are using RSA with a 2048 bit key to sign and another 2048 bit = key to encrypt, most of the message will be key material/padding. If you want small with asymmetric signatures EC algs will save you = significantly more unless you have a huge payload. I am not against finding an optimization, but we need to look at all of = the things that impact size. John B. On 2012-12-19, at 7:06 PM, Mike Jones = wrote: > That's a much bigger structural change. If what you're trying to do = is to avoid the overhead of integrity protecting the content twice, = instead, while this may be heretical to some, you could create a JWE = with AES CBC and an empty integrity check value ("enc":"A128CBC") and = then use that as a JWS payload. It would mean that we would once again = have an encryption algorithm with no integrity check. That could be = accompanied with Security Considerations caveats that this algorithm MAY = NOT be used unless the resulting JWE was integrity checked through other = means, such as being used as the payload of a JWS with an appropriate = signature/MAC algorithm. >=20 > The upside of that approach is that you'd have two separate sets of = headers for the two different operations without making significant = syntax changes to the JWE header format. >=20 > -- Mike >=20 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Wednesday, December 19, 2012 1:46 PM > To: Richard Barnes > Cc: Dick Hardt; Mike Jones; jose@ietf.org > Subject: Re: [jose] Reducing the size of JWS payloads >=20 > That is why one would be in the 'enc' sub-object, something like this: >=20 > {=20 > , 'kid': // signing key id > , 'alg': // signing algorithm > , 'enc':=20 > { 'kid': // encryption key id > , 'alg': // encryption algorithm > } > } >=20 >=20 > On Dec 19, 2012, at 1:31 PM, Richard Barnes wrote: >=20 >> In which order? Just having two "kid" values seems ambiguous. >>=20 >>=20 >> On Dec 19, 2012, at 3:02 PM, Dick Hardt wrote: >>=20 >>> Um, yeah. >>>=20 >>> I have the keys backwards. >>>=20 >>> If I am signing with my private key and encrypting with the = recipients public key ...=20 >>>=20 >>> On Dec 19, 2012, at 11:42 AM, Dick Hardt = wrote: >>>=20 >>>> Hi Mike >>>>=20 >>>> Either I don't understand your answer or you don't understand what = I was saying, so let me elaborate. >>>>=20 >>>> If I am signing with the recipients public key and encrypting with = my private key, I need to have two 'kid' values and possible other = cryptography header values. >>>>=20 >>>> -- Dick >>>>=20 >>>> On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: >>>>=20 >>>>> Hi Dick, >>>>>=20 >>>>> The way to do that with the current spec is to define a new = composite encryption/integrity algorithm that does what you want. For = instance, the "A128CBC+HS256" composite algorithm performs encryption = with AES CBC and the integrity check with HMAC SHA-256. I could imagine = an "A128CBC+ES256" algorithm that performs the encryption with AES CBC = and the integrity calculation with ECDSA P-256 SHA-256. The key for = that composite algorithm could be the concatenation of a 128-bit CBC key = and the ECDSA key. >>>>>=20 >>>>> For what it's worth, until draft -06, the block encryption = algorithm and the integrity algorithm were separately specified (in = "enc" and "int") parameters. The working group made a decision to only = support encryption algorithms that provided integrity - hence the use of = composite algorithms when using CBC (which doesn't provide integrity = itself. However, you still would have had to define a new "int" = algorithm even when they were separate, because the only integrity = algorithms specified were HS256, HS384, and HS512. >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>>> Sent: Tuesday, December 18, 2012 6:45 PM >>>>> To: Mike Jones >>>>> Cc: jose@ietf.org; Dick Hardt >>>>> Subject: Re: [jose] Reducing the size of JWS payloads >>>>>=20 >>>>> Hi Mike >>>>>=20 >>>>> Thanks for bringing this up again.=20 >>>>>=20 >>>>> An alternative approach I proposed was to have both the encryption = and signing information in one header, and to use the signing signature = to ensure integrity instead of having a separate encryption integrity = check. This would reduce the size of the token by the size of the = integrity value +1 bytes, as well as reduce the processing. >>>>>=20 >>>>> Given that header properties are overloaded now (they have = different meanings depending on being a JWE or JWS, we could put the = encryption header values into a sub object in the header. Perhaps call = that 'enc'. >>>>>=20 >>>>> -- Dick >>>>>=20 >>>>> The process below has=20 >>>>> On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >>>>>=20 >>>>>> I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >>>>>>=20 >>>>>> Dick proposed one method below - have a header parameter to say = that the payload is already URL-safe and that base64url encoding is not = to be performed. Another way that people have proposed is to allow the = use of the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>>>>>=20 >>>>>> CURRENT SITUATION: The JWE is 526 characters in length. = Currently, when used as a JWS payload, base64url encoding it would = increase its size to 702 characters - an increase of 33% or 176 = characters. >>>>>>=20 >>>>>> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header = parameter "b64":false to indicate that no additional base64url encoding = is to be performed, the payload would be 176 characters smaller than the = current situation. The encoded header size would increase by 16 = characters - the number of characters needed to base64url encode this = header parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>>>>>=20 >>>>>> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using = DEFLATE on this input results in a LARGER output - 536 bytes or a net = increase of 10 bytes. If you think about it, this isn't too surprising, = as the encrypted data should contain no usable = predictability/redundancy. Base64url encoding these 536 bytes results = in a 715 character payload - an increase of 189 characters or 36%. = Plus, adding "zip":"DEF" to the header adds 16 characters, for a total = increase of 29 characters over the current situation. Clearly a = suboptimal choice! >>>>>>=20 >>>>>> CONCLUSION: Clearly, if we're going to enable reduction of the = size of JWS payloads, avoiding the double base64url encoding is = preferable to zip, which actually makes things worse. >>>>>>=20 >>>>>> QUESTION TO WORKING GROUP: I'm curious whether people would like = to see us enable avoiding double base64encoding of JWS payloads when = they are already URL-safe. The space savings are significant; they come = at the cost of the JWS parsing becoming [part before first period . part = between first and last period . part after last period] rather than the = current [part before first period . part between first and second period = . part after second period (with no other periods allowed)]. Opinions? >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>>>> Sent: Monday, October 29, 2012 8:57 AM >>>>>> To: jose@ietf.org >>>>>> Subject: [jose] signing an existing JWT >>>>>>=20 >>>>>>=20 >>>>>> Let's say we have created a JWE as such: >>>>>> =09 >>>>>> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>>>>>=20 >>>>>> This is now the payload to a JWS. Rather than increasing the = token size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>>>>>=20 >>>>>> As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >>>>>>=20 >>>>>> The indicating parameter would seem to be either "tip" or "cty". = I'm still confused about the difference between the two parameters, so = not sure which one is appropriate. >>>>>>=20 >>>>>> -- Dick >>>>>>=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 >>>>=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 From dick.hardt@gmail.com Wed Dec 19 15:02:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA98E21F8932 for ; Wed, 19 Dec 2012 15:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjJckzdTKi7w for ; Wed, 19 Dec 2012 15:02:13 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5548421F892A for ; Wed, 19 Dec 2012 15:02:13 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id un15so1522381pbc.22 for ; Wed, 19 Dec 2012 15:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=Nq58omfe9EAVBLTBnkzA6SmS7DIKS0spT+xSpnXmCmU=; b=sjkpdp12qschnii4+PKbyjGpLed3l+uCfrHM5veaR1FBzGPH+5Do2WxLS3ehJXuGaO qx8DP2mSDcM8ONceSKfVVpcjsftcQYcfPi06amYyaU4vphc2R1c+Eq1zxMMDtIE1+XIY p3hBHrkVK/hCCeplif+U/Ak09kBHSV4bWB2Jsmxq9sbiryXKQofD6GXOCautUbdiTX1r AvUEayCjvdeg5BtlVQPE9u4FVD4GV0zK+sksLFUj6c3GY0c2hMzAYhuNg1s6NXaM8tSC j/ExytxUcaPsGU3jfUBjoyoPhAjYm03t8q54faCI8cD1zwu9qZ8qGnRJfviqhcVKWJZv C7+w== X-Received: by 10.68.130.161 with SMTP id of1mr2082612pbb.32.1355958131908; Wed, 19 Dec 2012 15:02:11 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id gu5sm3831364pbc.10.2012.12.19.15.02.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 15:02:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <8B456AF9-A6BE-447D-B256-4C197CF8F9D9@ve7jtb.com> Date: Wed, 19 Dec 2012 15:02:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366977921@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B456AF9-A6BE-447D-B256-4C197CF8F9D9@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1499) Cc: Richard Barnes , Mike Jones , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:02:15 -0000 I had not thought about what the regulators would think, but that makes = sense. Currently in the work I am doing, I am using 512 bit symmetric keys and = doing either signing or encrypting. Resulting tokens are 400 - 1700 = bytes which is reasonable. I have not investigated using compression. My larger tokens are due to them containing another, encrypted token. I = doubt if compression would help, and the token size is acceptable for = what is currently envisioned. So I guess I'll can drop this topic. -- Dick On Dec 19, 2012, at 2:28 PM, John Bradley wrote: > If you are using a asymmetric signature for any sort of non = repudiation you generally do the signature before encryption. =20 > Most regulations don't recognize signatures over encrypted data as = enforcable. >=20 > Signing and then encrypting with compression and integrity is I think = a more common use case that you didn't test for size. > The signed body shield compress just fine, while the RSA signature = itself I admit won't be compressed. > If you are using RSA with a 2048 bit key to sign and another 2048 bit = key to encrypt, most of the message will be key material/padding. >=20 > If you want small with asymmetric signatures EC algs will save you = significantly more unless you have a huge payload. >=20 > I am not against finding an optimization, but we need to look at all = of the things that impact size. >=20 > John B. >=20 >=20 > On 2012-12-19, at 7:06 PM, Mike Jones = wrote: >=20 >> That's a much bigger structural change. If what you're trying to do = is to avoid the overhead of integrity protecting the content twice, = instead, while this may be heretical to some, you could create a JWE = with AES CBC and an empty integrity check value ("enc":"A128CBC") and = then use that as a JWS payload. It would mean that we would once again = have an encryption algorithm with no integrity check. That could be = accompanied with Security Considerations caveats that this algorithm MAY = NOT be used unless the resulting JWE was integrity checked through other = means, such as being used as the payload of a JWS with an appropriate = signature/MAC algorithm. >>=20 >> The upside of that approach is that you'd have two separate sets of = headers for the two different operations without making significant = syntax changes to the JWE header format. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >> Sent: Wednesday, December 19, 2012 1:46 PM >> To: Richard Barnes >> Cc: Dick Hardt; Mike Jones; jose@ietf.org >> Subject: Re: [jose] Reducing the size of JWS payloads >>=20 >> That is why one would be in the 'enc' sub-object, something like = this: >>=20 >> {=20 >> , 'kid': // signing key id >> , 'alg': // signing algorithm >> , 'enc':=20 >> { 'kid': // encryption key id >> , 'alg': // encryption algorithm >> } >> } >>=20 >>=20 >> On Dec 19, 2012, at 1:31 PM, Richard Barnes wrote: >>=20 >>> In which order? Just having two "kid" values seems ambiguous. >>>=20 >>>=20 >>> On Dec 19, 2012, at 3:02 PM, Dick Hardt = wrote: >>>=20 >>>> Um, yeah. >>>>=20 >>>> I have the keys backwards. >>>>=20 >>>> If I am signing with my private key and encrypting with the = recipients public key ...=20 >>>>=20 >>>> On Dec 19, 2012, at 11:42 AM, Dick Hardt = wrote: >>>>=20 >>>>> Hi Mike >>>>>=20 >>>>> Either I don't understand your answer or you don't understand what = I was saying, so let me elaborate. >>>>>=20 >>>>> If I am signing with the recipients public key and encrypting with = my private key, I need to have two 'kid' values and possible other = cryptography header values. >>>>>=20 >>>>> -- Dick >>>>>=20 >>>>> On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: >>>>>=20 >>>>>> Hi Dick, >>>>>>=20 >>>>>> The way to do that with the current spec is to define a new = composite encryption/integrity algorithm that does what you want. For = instance, the "A128CBC+HS256" composite algorithm performs encryption = with AES CBC and the integrity check with HMAC SHA-256. I could imagine = an "A128CBC+ES256" algorithm that performs the encryption with AES CBC = and the integrity calculation with ECDSA P-256 SHA-256. The key for = that composite algorithm could be the concatenation of a 128-bit CBC key = and the ECDSA key. >>>>>>=20 >>>>>> For what it's worth, until draft -06, the block encryption = algorithm and the integrity algorithm were separately specified (in = "enc" and "int") parameters. The working group made a decision to only = support encryption algorithms that provided integrity - hence the use of = composite algorithms when using CBC (which doesn't provide integrity = itself. However, you still would have had to define a new "int" = algorithm even when they were separate, because the only integrity = algorithms specified were HS256, HS384, and HS512. >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>>>> Sent: Tuesday, December 18, 2012 6:45 PM >>>>>> To: Mike Jones >>>>>> Cc: jose@ietf.org; Dick Hardt >>>>>> Subject: Re: [jose] Reducing the size of JWS payloads >>>>>>=20 >>>>>> Hi Mike >>>>>>=20 >>>>>> Thanks for bringing this up again.=20 >>>>>>=20 >>>>>> An alternative approach I proposed was to have both the = encryption and signing information in one header, and to use the signing = signature to ensure integrity instead of having a separate encryption = integrity check. This would reduce the size of the token by the size of = the integrity value +1 bytes, as well as reduce the processing. >>>>>>=20 >>>>>> Given that header properties are overloaded now (they have = different meanings depending on being a JWE or JWS, we could put the = encryption header values into a sub object in the header. Perhaps call = that 'enc'. >>>>>>=20 >>>>>> -- Dick >>>>>>=20 >>>>>> The process below has=20 >>>>>> On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >>>>>>=20 >>>>>>> I've noticed that more than one person has expressed a desire to = reduce the size of JWS payloads before signing. This especially comes = up when nested encryption and signing is being performed. This note = contains a quantitative evaluation of some possible methods of reducing = JWS payload size and asks for working group input based upon the data. >>>>>>>=20 >>>>>>> Dick proposed one method below - have a header parameter to say = that the payload is already URL-safe and that base64url encoding is not = to be performed. Another way that people have proposed is to allow the = use of the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>>>>>>=20 >>>>>>> CURRENT SITUATION: The JWE is 526 characters in length. = Currently, when used as a JWS payload, base64url encoding it would = increase its size to 702 characters - an increase of 33% or 176 = characters. >>>>>>>=20 >>>>>>> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header = parameter "b64":false to indicate that no additional base64url encoding = is to be performed, the payload would be 176 characters smaller than the = current situation. The encoded header size would increase by 16 = characters - the number of characters needed to base64url encode this = header parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>>>>>>=20 >>>>>>> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using = DEFLATE on this input results in a LARGER output - 536 bytes or a net = increase of 10 bytes. If you think about it, this isn't too surprising, = as the encrypted data should contain no usable = predictability/redundancy. Base64url encoding these 536 bytes results = in a 715 character payload - an increase of 189 characters or 36%. = Plus, adding "zip":"DEF" to the header adds 16 characters, for a total = increase of 29 characters over the current situation. Clearly a = suboptimal choice! >>>>>>>=20 >>>>>>> CONCLUSION: Clearly, if we're going to enable reduction of the = size of JWS payloads, avoiding the double base64url encoding is = preferable to zip, which actually makes things worse. >>>>>>>=20 >>>>>>> QUESTION TO WORKING GROUP: I'm curious whether people would = like to see us enable avoiding double base64encoding of JWS payloads = when they are already URL-safe. The space savings are significant; they = come at the cost of the JWS parsing becoming [part before first period . = part between first and last period . part after last period] rather than = the current [part before first period . part between first and second = period . part after second period (with no other periods allowed)]. = Opinions? >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>>>>> Sent: Monday, October 29, 2012 8:57 AM >>>>>>> To: jose@ietf.org >>>>>>> Subject: [jose] signing an existing JWT >>>>>>>=20 >>>>>>>=20 >>>>>>> Let's say we have created a JWE as such: >>>>>>> =09 >>>>>>> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>>>>>>=20 >>>>>>> This is now the payload to a JWS. Rather than increasing the = token size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>>>>>>=20 >>>>>>> As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >>>>>>>=20 >>>>>>> The indicating parameter would seem to be either "tip" or "cty". = I'm still confused about the difference between the two parameters, so = not sure which one is appropriate. >>>>>>>=20 >>>>>>> -- Dick >>>>>>>=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 >>>>>=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 >=20 From James.H.Manger@team.telstra.com Wed Dec 19 15:40:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB2C21F88A2 for ; Wed, 19 Dec 2012 15:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0etbXDiLTGA for ; Wed, 19 Dec 2012 15:40:13 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3287B21F8898 for ; Wed, 19 Dec 2012 15:40:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,320,1355058000"; d="scan'208";a="109151396" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 10:40:11 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6931"; a="103055968" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 10:40:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 20 Dec 2012 10:40:10 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 20 Dec 2012 10:40:09 +1100 Thread-Topic: Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgArYb9Q Message-ID: <255B9BB34FB7D647A506DC292726F6E115041F65F9@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:40:14 -0000 SSBkb24ndCB0aGluayB5b3VyIGNhbGN1bGF0aW9ucyBhcmUgbm90IHF1aXRlIHJpZ2h0LCBNaWtl Lg0KDQpEZWZsYXRpbmcgdGhlIDUyNiBjaGFyYWN0ZXIgSldFIGV4YW1wbGUgZnJvbSBhcHBlbmRp eCAyIGdpdmVzIDQyNyBieXRlcywgbm90IHRoZSA1MzYgeW91IHN0YXRlLg0KDQpBc3N1bWluZyBh IEpXUyBoZWFkZXIgYW5kIHNpZ25hdHVyZSBpcyAzNjUgY2hhcnMgKDIwNDgtYml0IFJTQSBrZXks IGFzIHBlciBKV1MgYXBwZW5kaXggMikuDQoNCkpXU190b2RheShKV0UpID0gMzY1ICsgQjY0KDUy NikgPSAxMDY3DQpKV1NfemlwKEpXRSkgPSAzNjUgKyAxNSArIEI2NCg0MjcpID0gOTUwID0gc2F2 ZSAxMTcgY2hhcnMgKDExJSkNCkpXU19ub19iNjQoSldFKSA9IDM2NSArIDE1ICsgNTI2ID0gOTA2 ID0gc2F2ZSAxNjEgY2hhcnMgKDE1JSkNCg0KU28gIkFQUExZSU5HIERFRkxBVEUgVE8gVEhFIFBB WUxPQUQiIGRvZXMgbm90IG1ha2UgdGhpbmdzIHdvcnNlLCBpdCBnaXZlcyBhIDExJSBzYXZpbmcu DQoNClRoZXNlIG51bWJlcnMgYXJlIG5vdCB0aGF0IHJlbGV2YW50IGFzIEkgYWdyZWUgd2l0aCBK b2huIEJyYWRsZXkgdGhhdCBhbiBhc3ltbWV0cmljIHNpZ25hdHVyZSBpcyBtb3JlIGxpa2VseSB0 byBiZSBhcHBsaWVkIGJlZm9yZSB0aGUgZW5jcnlwdGlvbi4NCg0KSSBzdXNwZWN0IEpPU0Ugd291 bGQgYmUgYmV0dGVyIG9mZiBkZWZpbmluZyBpdHMgb3BlcmF0aW9ucyBvbiBieXRlIGFycmF5czog dGhlIGZpcnN0IGJ5dGUgYXJyYXkgaXMgYSBKU09OIG9iamVjdCwgYW5vdGhlciBieXRlIGFycmF5 IGlzIHRoZSBjb250ZW50OyBzaWduaW5nIGNvdmVycyB0aGVzZSBieXRlIGFycmF5cyAod2l0aCBh IGxlbmd0aCkgZXRjLiBUaGVuIGxlYXZlIHRoZSBiYXNlNjR1cmwgZW5jb2RpbmcgdG8gdGhlIHZl cnkgbGFzdCBzdGVwIChhZnRlciBhbnkgY3J5cHRvKS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IE1pa2UgSm9u ZXMNCj4gU2VudDogV2VkbmVzZGF5LCAxOSBEZWNlbWJlciAyMDEyIDE6MjYgUE0NCj4gVG86IGpv c2VAaWV0Zi5vcmcNCj4gQ2M6IERpY2sgSGFyZHQNCj4gU3ViamVjdDogW2pvc2VdIFJlZHVjaW5n IHRoZSBzaXplIG9mIEpXUyBwYXlsb2Fkcw0KPiANCj4gSSd2ZSBub3RpY2VkIHRoYXQgbW9yZSB0 aGFuIG9uZSBwZXJzb24gaGFzIGV4cHJlc3NlZCBhIGRlc2lyZSB0byByZWR1Y2UNCj4gdGhlIHNp emUgb2YgSldTIHBheWxvYWRzIGJlZm9yZSBzaWduaW5nLiAgVGhpcyBlc3BlY2lhbGx5IGNvbWVz IHVwIHdoZW4NCj4gbmVzdGVkIGVuY3J5cHRpb24gYW5kIHNpZ25pbmcgaXMgYmVpbmcgcGVyZm9y bWVkLiAgVGhpcyBub3RlIGNvbnRhaW5zIGENCj4gcXVhbnRpdGF0aXZlIGV2YWx1YXRpb24gb2Yg c29tZSBwb3NzaWJsZSBtZXRob2RzIG9mIHJlZHVjaW5nIEpXUw0KPiBwYXlsb2FkIHNpemUgYW5k IGFza3MgZm9yIHdvcmtpbmcgZ3JvdXAgaW5wdXQgYmFzZWQgdXBvbiB0aGUgZGF0YS4NCj4gDQo+ IERpY2sgcHJvcG9zZWQgb25lIG1ldGhvZCBiZWxvdyAtIGhhdmUgYSBoZWFkZXIgcGFyYW1ldGVy IHRvIHNheSB0aGF0DQo+IHRoZSBwYXlsb2FkIGlzIGFscmVhZHkgVVJMLXNhZmUgYW5kIHRoYXQg YmFzZTY0dXJsIGVuY29kaW5nIGlzIG5vdCB0bw0KPiBiZSBwZXJmb3JtZWQuICBBbm90aGVyIHdh eSB0aGF0IHBlb3BsZSBoYXZlIHByb3Bvc2VkIGlzIHRvIGFsbG93IHRoZQ0KPiB1c2Ugb2YgdGhl ICJ6aXAiIHBhcmFtZXRlciB0byBjb21wcmVzcyB0aGUgSldTIHBheWxvYWQgYmVmb3JlIGJhc2U2 NHVybA0KPiBlbmNvZGluZy4gIFRvIGdldCBzb21lIGluaXRpYWwgZGF0YSBvbiBob3cgdGhlIHNv bHV0aW9ucyBjb21wYXJlLCBJDQo+IHRyaWVkIGJvdGggbWV0aG9kcyB1c2luZyB0aGUgc2FtcGxl IEpXRSB2YWx1ZSBpbg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpv c2UtanNvbi13ZWItZW5jcnlwdGlvbi0NCj4gMDcjYXBwZW5kaXgtQS4yIGFzIHRoZSBKV1MgcGF5 bG9hZC4NCj4gDQo+IENVUlJFTlQgU0lUVUFUSU9OOiAgVGhlIEpXRSBpcyA1MjYgY2hhcmFjdGVy cyBpbiBsZW5ndGguICBDdXJyZW50bHksDQo+IHdoZW4gdXNlZCBhcyBhIEpXUyBwYXlsb2FkLCBi YXNlNjR1cmwgZW5jb2RpbmcgaXQgd291bGQgaW5jcmVhc2UgaXRzDQo+IHNpemUgdG8gNzAyIGNo YXJhY3RlcnMgLSBhbiBpbmNyZWFzZSBvZiAzMyUgb3IgMTc2IGNoYXJhY3RlcnMuDQo+IA0KPiBB Vk9JRElORyBET1VCTEUgQkFTRTY0VVJMIEVOQ09ESU5HOiAgSWYgd2UgdXNlZCBhIGhlYWRlciBw YXJhbWV0ZXINCj4gImI2NCI6ZmFsc2UgdG8gaW5kaWNhdGUgdGhhdCBubyBhZGRpdGlvbmFsIGJh c2U2NHVybCBlbmNvZGluZyBpcyB0byBiZQ0KPiBwZXJmb3JtZWQsIHRoZSBwYXlsb2FkIHdvdWxk IGJlIDE3NiBjaGFyYWN0ZXJzIHNtYWxsZXIgdGhhbiB0aGUgY3VycmVudA0KPiBzaXR1YXRpb24u ICBUaGUgZW5jb2RlZCBoZWFkZXIgc2l6ZSB3b3VsZCBpbmNyZWFzZSBieSAxNiBjaGFyYWN0ZXJz IC0NCj4gdGhlIG51bWJlciBvZiBjaGFyYWN0ZXJzIG5lZWRlZCB0byBiYXNlNjR1cmwgZW5jb2Rl IHRoaXMgaGVhZGVyDQo+IHBhcmFtZXRlciB2YWx1ZSBhbmQgYSBjb21tYSwgZm9yIGEgbmV0IGRl Y3JlYXNlIGluIHNpemUgb2YgMTYwDQo+IGNoYXJhY3RlcnMuICAoWWVzLCBwYXJzaW5nIHRoZSB0 aHJlZSBwaWVjZXMgd291bGQgYmUgc2xpZ2h0bHkgbW9yZQ0KPiBkaWZmaWN1bHQuKQ0KPiANCj4g QVBQTFlJTkcgREVGTEFURSBUTyBUSEUgUEFZTE9BRDogIEJlbGlldmUgaXQgb3Igbm90LCB1c2lu ZyBERUZMQVRFIG9uDQo+IHRoaXMgaW5wdXQgcmVzdWx0cyBpbiBhIExBUkdFUiBvdXRwdXQgLSA1 MzYgYnl0ZXMgb3IgYSBuZXQgaW5jcmVhc2Ugb2YNCj4gMTAgYnl0ZXMuICBJZiB5b3UgdGhpbmsg YWJvdXQgaXQsIHRoaXMgaXNuJ3QgdG9vIHN1cnByaXNpbmcsIGFzIHRoZQ0KPiBlbmNyeXB0ZWQg ZGF0YSBzaG91bGQgY29udGFpbiBubyB1c2FibGUgcHJlZGljdGFiaWxpdHkvcmVkdW5kYW5jeS4N Cj4gQmFzZTY0dXJsIGVuY29kaW5nIHRoZXNlIDUzNiBieXRlcyByZXN1bHRzIGluIGEgNzE1IGNo YXJhY3RlciBwYXlsb2FkIC0NCj4gYW4gaW5jcmVhc2Ugb2YgMTg5IGNoYXJhY3RlcnMgb3IgMzYl LiAgUGx1cywgYWRkaW5nICJ6aXAiOiJERUYiIHRvIHRoZQ0KPiBoZWFkZXIgYWRkcyAxNiBjaGFy YWN0ZXJzLCBmb3IgYSB0b3RhbCBpbmNyZWFzZSBvZiAyOSBjaGFyYWN0ZXJzIG92ZXINCj4gdGhl IGN1cnJlbnQgc2l0dWF0aW9uLiAgQ2xlYXJseSBhIHN1Ym9wdGltYWwgY2hvaWNlIQ0KPiANCj4g Q09OQ0xVU0lPTjogIENsZWFybHksIGlmIHdlJ3JlIGdvaW5nIHRvIGVuYWJsZSByZWR1Y3Rpb24g b2YgdGhlIHNpemUgb2YNCj4gSldTIHBheWxvYWRzLCBhdm9pZGluZyB0aGUgZG91YmxlIGJhc2U2 NHVybCBlbmNvZGluZyBpcyBwcmVmZXJhYmxlIHRvDQo+IHppcCwgd2hpY2ggYWN0dWFsbHkgbWFr ZXMgdGhpbmdzIHdvcnNlLg0KPiANCj4gUVVFU1RJT04gVE8gV09SS0lORyBHUk9VUDogIEknbSBj dXJpb3VzIHdoZXRoZXIgcGVvcGxlIHdvdWxkIGxpa2UgdG8NCj4gc2VlIHVzIGVuYWJsZSBhdm9p ZGluZyBkb3VibGUgYmFzZTY0ZW5jb2Rpbmcgb2YgSldTIHBheWxvYWRzIHdoZW4gdGhleQ0KPiBh cmUgYWxyZWFkeSBVUkwtc2FmZS4gIFRoZSBzcGFjZSBzYXZpbmdzIGFyZSBzaWduaWZpY2FudDsg dGhleSBjb21lIGF0DQo+IHRoZSBjb3N0IG9mIHRoZSBKV1MgcGFyc2luZyBiZWNvbWluZyBbcGFy dCBiZWZvcmUgZmlyc3QgcGVyaW9kIC4gcGFydA0KPiBiZXR3ZWVuIGZpcnN0IGFuZCBsYXN0IHBl cmlvZCAuIHBhcnQgYWZ0ZXIgbGFzdCBwZXJpb2RdIHJhdGhlciB0aGFuIHRoZQ0KPiBjdXJyZW50 IFtwYXJ0IGJlZm9yZSBmaXJzdCBwZXJpb2QgLiBwYXJ0IGJldHdlZW4gZmlyc3QgYW5kIHNlY29u ZA0KPiBwZXJpb2QgLiBwYXJ0IGFmdGVyIHNlY29uZCBwZXJpb2QgKHdpdGggbm8gb3RoZXIgcGVy aW9kcyBhbGxvd2VkKV0uDQo+IE9waW5pb25zPw0KDQo= From ve7jtb@ve7jtb.com Wed Dec 19 15:44:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA7D21F84E6 for ; Wed, 19 Dec 2012 15:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMVsXMslC0iH for ; Wed, 19 Dec 2012 15:44:29 -0800 (PST) Received: from mail-gg0-f181.google.com (mail-gg0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA7621F845F for ; Wed, 19 Dec 2012 15:44:28 -0800 (PST) Received: by mail-gg0-f181.google.com with SMTP id s6so595678ggc.26 for ; Wed, 19 Dec 2012 15:44:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QfbQ+4Z+Ft/anDB5oXZ3KSZExSPAL7HBp8L/ov9pOZ4=; b=EomOx09vKsGQJ+H6fIiEiQ+cArpjOoLjFYaxMU6wSXTFMtQzyLkApPr3h2H0EICeLH 3uUWeRc3Q2AMvJrd0dGyOkS5N4bXLeq08siHlkhHM2BzjPPS/VZIHMc4hTisGxUZiAkN uN3+Dg925JG3mDQpp24LdBiN2BZSFg0CiNSsabVvNkKoEvIPkcpFkaljQZYTCIhheE9c wItAZ3BoQlI/wHuyvGafcpd/eUa8uI0kiijMLR574QTjzgBtVipVR74o2bGadgZQKvc1 5SZ5zWWzjx2ukhaYP97kxKjMAeamRPiJljF+GQ3hz0I907qlvnpsNHyDz9kHHqYpFDRd FFBQ== X-Received: by 10.101.165.2 with SMTP id s2mr2093171ano.33.1355960668457; Wed, 19 Dec 2012 15:44:28 -0800 (PST) Received: from [192.168.1.211] (190-20-21-85.baf.movistar.cl. [190.20.21.85]) by mx.google.com with ESMTPS id t2sm5615583anj.3.2012.12.19.15.44.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 15:44:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Wed, 19 Dec 2012 20:44:18 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366977921@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B456AF9-A6BE-447D-B256-4C197CF8F9D9@ve7jtb.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmTsT5KC7DynN2PRgXGcjImAWRBVNsT4ExQYzhQ2aSQWf3S4QOE56WsZ3z5+CFj1NwDETyz Cc: Richard Barnes , Mike Jones , "jose@ietf.org" Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:44:30 -0000 If you are using symmetric keys then encryption with a AEAD algorithm = gets you integrity and encryption without double encoding. I think I mentioned that earlier but I put the words signing and = symmetric in the same email and started a small war. Strictly speaking there is no such thing as a symmetric signature only = symmetric integrity. ( Perhaps nets out to being the same thing if there = are only two parties with the shared secret). In OAuth 2 many people use the fact that only the sender and receiver = have the the secret and use HMAC to guarantee the integrity and by = inference know who sent it. If you use AEAD encryption then you get the same thing only a party with = the shared secret could have sent it and generated the integrity check. So I think foe symmetric keys we already have a composite integrity and = encryption option, there is no need for extra headers etc. For asymmetric the best practice is to sign then encrypt with integrity. = The case of encrypting and then signing is problematic but I don't = think it is the normal case. John B. On 2012-12-19, at 8:02 PM, Dick Hardt wrote: > I had not thought about what the regulators would think, but that = makes sense. >=20 > Currently in the work I am doing, I am using 512 bit symmetric keys = and doing either signing or encrypting. Resulting tokens are 400 - 1700 = bytes which is reasonable. I have not investigated using compression. >=20 > My larger tokens are due to them containing another, encrypted token. = I doubt if compression would help, and the token size is acceptable for = what is currently envisioned. >=20 > So I guess I'll can drop this topic. >=20 > -- Dick >=20 > On Dec 19, 2012, at 2:28 PM, John Bradley wrote: >=20 >> If you are using a asymmetric signature for any sort of non = repudiation you generally do the signature before encryption. =20 >> Most regulations don't recognize signatures over encrypted data as = enforcable. >>=20 >> Signing and then encrypting with compression and integrity is I think = a more common use case that you didn't test for size. >> The signed body shield compress just fine, while the RSA signature = itself I admit won't be compressed. >> If you are using RSA with a 2048 bit key to sign and another 2048 bit = key to encrypt, most of the message will be key material/padding. >>=20 >> If you want small with asymmetric signatures EC algs will save you = significantly more unless you have a huge payload. >>=20 >> I am not against finding an optimization, but we need to look at all = of the things that impact size. >>=20 >> John B. >>=20 >>=20 >> On 2012-12-19, at 7:06 PM, Mike Jones = wrote: >>=20 >>> That's a much bigger structural change. If what you're trying to do = is to avoid the overhead of integrity protecting the content twice, = instead, while this may be heretical to some, you could create a JWE = with AES CBC and an empty integrity check value ("enc":"A128CBC") and = then use that as a JWS payload. It would mean that we would once again = have an encryption algorithm with no integrity check. That could be = accompanied with Security Considerations caveats that this algorithm MAY = NOT be used unless the resulting JWE was integrity checked through other = means, such as being used as the payload of a JWS with an appropriate = signature/MAC algorithm. >>>=20 >>> The upside of that approach is that you'd have two separate sets of = headers for the two different operations without making significant = syntax changes to the JWE header format. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>> Sent: Wednesday, December 19, 2012 1:46 PM >>> To: Richard Barnes >>> Cc: Dick Hardt; Mike Jones; jose@ietf.org >>> Subject: Re: [jose] Reducing the size of JWS payloads >>>=20 >>> That is why one would be in the 'enc' sub-object, something like = this: >>>=20 >>> {=20 >>> , 'kid': // signing key id >>> , 'alg': // signing algorithm >>> , 'enc':=20 >>> { 'kid': // encryption key id >>> , 'alg': // encryption algorithm >>> } >>> } >>>=20 >>>=20 >>> On Dec 19, 2012, at 1:31 PM, Richard Barnes wrote: >>>=20 >>>> In which order? Just having two "kid" values seems ambiguous. >>>>=20 >>>>=20 >>>> On Dec 19, 2012, at 3:02 PM, Dick Hardt = wrote: >>>>=20 >>>>> Um, yeah. >>>>>=20 >>>>> I have the keys backwards. >>>>>=20 >>>>> If I am signing with my private key and encrypting with the = recipients public key ...=20 >>>>>=20 >>>>> On Dec 19, 2012, at 11:42 AM, Dick Hardt = wrote: >>>>>=20 >>>>>> Hi Mike >>>>>>=20 >>>>>> Either I don't understand your answer or you don't understand = what I was saying, so let me elaborate. >>>>>>=20 >>>>>> If I am signing with the recipients public key and encrypting = with my private key, I need to have two 'kid' values and possible other = cryptography header values. >>>>>>=20 >>>>>> -- Dick >>>>>>=20 >>>>>> On Dec 19, 2012, at 11:36 AM, Mike Jones = wrote: >>>>>>=20 >>>>>>> Hi Dick, >>>>>>>=20 >>>>>>> The way to do that with the current spec is to define a new = composite encryption/integrity algorithm that does what you want. For = instance, the "A128CBC+HS256" composite algorithm performs encryption = with AES CBC and the integrity check with HMAC SHA-256. I could imagine = an "A128CBC+ES256" algorithm that performs the encryption with AES CBC = and the integrity calculation with ECDSA P-256 SHA-256. The key for = that composite algorithm could be the concatenation of a 128-bit CBC key = and the ECDSA key. >>>>>>>=20 >>>>>>> For what it's worth, until draft -06, the block encryption = algorithm and the integrity algorithm were separately specified (in = "enc" and "int") parameters. The working group made a decision to only = support encryption algorithms that provided integrity - hence the use of = composite algorithms when using CBC (which doesn't provide integrity = itself. However, you still would have had to define a new "int" = algorithm even when they were separate, because the only integrity = algorithms specified were HS256, HS384, and HS512. >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>>>>> Sent: Tuesday, December 18, 2012 6:45 PM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org; Dick Hardt >>>>>>> Subject: Re: [jose] Reducing the size of JWS payloads >>>>>>>=20 >>>>>>> Hi Mike >>>>>>>=20 >>>>>>> Thanks for bringing this up again.=20 >>>>>>>=20 >>>>>>> An alternative approach I proposed was to have both the = encryption and signing information in one header, and to use the signing = signature to ensure integrity instead of having a separate encryption = integrity check. This would reduce the size of the token by the size of = the integrity value +1 bytes, as well as reduce the processing. >>>>>>>=20 >>>>>>> Given that header properties are overloaded now (they have = different meanings depending on being a JWE or JWS, we could put the = encryption header values into a sub object in the header. Perhaps call = that 'enc'. >>>>>>>=20 >>>>>>> -- Dick >>>>>>>=20 >>>>>>> The process below has=20 >>>>>>> On Dec 18, 2012, at 6:26 PM, Mike Jones = wrote: >>>>>>>=20 >>>>>>>> I've noticed that more than one person has expressed a desire = to reduce the size of JWS payloads before signing. This especially = comes up when nested encryption and signing is being performed. This = note contains a quantitative evaluation of some possible methods of = reducing JWS payload size and asks for working group input based upon = the data. >>>>>>>>=20 >>>>>>>> Dick proposed one method below - have a header parameter to say = that the payload is already URL-safe and that base64url encoding is not = to be performed. Another way that people have proposed is to allow the = use of the "zip" parameter to compress the JWS payload before base64url = encoding. To get some initial data on how the solutions compare, I = tried both methods using the sample JWE value in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix= -A.2 as the JWS payload. >>>>>>>>=20 >>>>>>>> CURRENT SITUATION: The JWE is 526 characters in length. = Currently, when used as a JWS payload, base64url encoding it would = increase its size to 702 characters - an increase of 33% or 176 = characters. >>>>>>>>=20 >>>>>>>> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header = parameter "b64":false to indicate that no additional base64url encoding = is to be performed, the payload would be 176 characters smaller than the = current situation. The encoded header size would increase by 16 = characters - the number of characters needed to base64url encode this = header parameter value and a comma, for a net decrease in size of 160 = characters. (Yes, parsing the three pieces would be slightly more = difficult.) >>>>>>>>=20 >>>>>>>> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using = DEFLATE on this input results in a LARGER output - 536 bytes or a net = increase of 10 bytes. If you think about it, this isn't too surprising, = as the encrypted data should contain no usable = predictability/redundancy. Base64url encoding these 536 bytes results = in a 715 character payload - an increase of 189 characters or 36%. = Plus, adding "zip":"DEF" to the header adds 16 characters, for a total = increase of 29 characters over the current situation. Clearly a = suboptimal choice! >>>>>>>>=20 >>>>>>>> CONCLUSION: Clearly, if we're going to enable reduction of the = size of JWS payloads, avoiding the double base64url encoding is = preferable to zip, which actually makes things worse. >>>>>>>>=20 >>>>>>>> QUESTION TO WORKING GROUP: I'm curious whether people would = like to see us enable avoiding double base64encoding of JWS payloads = when they are already URL-safe. The space savings are significant; they = come at the cost of the JWS parsing becoming [part before first period . = part between first and last period . part after last period] rather than = the current [part before first period . part between first and second = period . part after second period (with no other periods allowed)]. = Opinions? >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of Dick Hardt >>>>>>>> Sent: Monday, October 29, 2012 8:57 AM >>>>>>>> To: jose@ietf.org >>>>>>>> Subject: [jose] signing an existing JWT >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Let's say we have created a JWE as such: >>>>>>>> =09 >>>>>>>> = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >>>>>>>>=20 >>>>>>>> This is now the payload to a JWS. Rather than increasing the = token size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >>>>>>>>=20 >>>>>>>> As there are more periods than expected in a JWS, decoding = would ignore all periods except the first and last one for separating = out the header, payload and signature. >>>>>>>>=20 >>>>>>>> The indicating parameter would seem to be either "tip" or = "cty". I'm still confused about the difference between the two = parameters, so not sure which one is appropriate. >>>>>>>>=20 >>>>>>>> -- Dick >>>>>>>>=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 >>>>>>=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 >>=20 >=20 From Michael.Jones@microsoft.com Wed Dec 19 15:54:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0370B21F8441 for ; Wed, 19 Dec 2012 15:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+mAuAIho85v for ; Wed, 19 Dec 2012 15:54:27 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id D043021F8422 for ; Wed, 19 Dec 2012 15:54:25 -0800 (PST) Received: from BY2FFO11FD001.protection.gbl (10.1.15.203) by BY2FFO11HUB007.protection.gbl (10.1.14.165) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 19 Dec 2012 23:54:22 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 23:54:22 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 23:53:53 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgArYb9QAAEkkLA= Date: Wed, 19 Dec 2012 23:53:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366977C74@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F65F9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115041F65F9@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.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366977C74TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(60454001)(13464002)(54356001)(44976002)(74662001)(76482001)(55846006)(54316002)(47446002)(77982001)(53806001)(59766001)(15202345001)(74502001)(51856001)(47976001)(47736001)(512874001)(16406001)(5343655001)(50986001)(49866001)(46102001)(33656001)(16236675001)(56776001)(31966008)(56816002)(4396001)(5343635001)(383094001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB007; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 070092A9D3 Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:54:30 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366977C74TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNCg0KDQpIbW1tIC0gbXkgcXVpY2stYW5kLWRpcnR5IHRlc3QgY29kZSB1c2Vk IHRoZSAuTkVUIFN5c3RlbS5JTy5Db21wcmVzc2lvbi5EZWZsYXRlU3RyZWFtPGh0dHA6Ly9tc2Ru Lm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9zeXN0ZW0uaW8uY29tcHJlc3Npb24uZGVmbGF0 ZXN0cmVhbSh2PVZTLjkwKS5hc3B4PiBjbGFzcyBhbmQgQ29tcHJlc3Npb25Nb2RlLkNvbXByZXNz IHRvIGRvIHRoZSBjb21wcmVzc2lvbi4gIFRoZSBkb2N1bWVudGF0aW9uIHNheXMgdGhhdCBpdCBp bXBsZW1lbnRzIFJGQyAxOTUxIERFRkxBVEUuICBUaGF0IGJlaW5nIHNhaWQsIEkga25vdyB0aGF0 IG9uZSBjYW4gdXNlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHNhbWUgY29tcHJl c3Npb24gYWxnb3JpdGhtIGFuZCBnZXQgZGlmZmVyZW50IHJlc3VsdHMsIGRlcGVuZGluZyB1cG9u IHRoZSBtYXRjaGVzIGFuZCBzdWJzdGl0dXRpb25zIHVzZWQg4oCTIGFsbCBvZiB3aGljaCB3aWxs IHVuY29tcHJlc3MgdG8gdGhlIG9yaWdpbmFsIHZhbHVlLiAgRG8geW91IHdhbnQgdG8gc3dhcCBk YXRhIHRvIGNvbmZpcm0gdGhhdCB3ZeKAmXJlIHVzaW5nIHRoZSBzYW1lIGNvbXByZXNzaW9uIGZv cm1hdD8NCg0KDQoNCkkgY29tcHJlc3NlZCB0aGVzZSBieXRlczoNCg0KMTAxIDEyMSA3NCAxMDQg OTggNzEgOTkgMTA1IDc5IDEwNSA3NCA4MyA4NSA0OCA2OSAxMjAgODggMTIyIDg1IDEwNSA3NiA2 NyA3NCAxMDggOTggMTA5IDc3IDEwNSA3OSAxMDUgNzQgNjYgNzcgODQgNzMgNTIgODEgNDggNzQg NjggNzUgNDggMTA0IDg0IDc3IDEwNiA4NSA1MCA3MyAxMTAgNDggNDYgOTAgMTA5IDExMCAxMDgg MTEzIDg3IDEwMyAxMDYgODggMTIxIDExMyAxMTkgMTA2IDExNCA1NSA5OSA4OCA3MiAxMjEgMTE1 IDU2IDcwIDU1IDU3IDk3IDExMCA3MyA4NSA3MyA1NCA3NCA1MCA4NSA4NyAxMDAgNjUgMTIxIDgy IDgxIDY5IDk5IDcxIDY2IDg1IDQ1IDc1IDgwIDcyIDExNSAxMDEgODAgNzcgNTcgNDkgNDggOTUg ODIgMTExIDg0IDY4IDcxIDExNyA0OSA3MyA4NyA1MiA0OCA2OCAxMTAgNDggMTAwIDExOCA5OSAx MDAgODYgNjkgMTA2IDExMiA3NCA5OSA4MCA4MCA3OCA3MyA5OCAxMjIgODcgOTkgNzcgMTIwIDY4 IDEwNSA0OSA1MSA0OSA2OSAxMDYgMTAxIDEwMyA0NSA5OCA1NiA4NiAxMDUgODcgNTMgODkgODgg NTMgMTExIDgyIDEwMCA4OSAxMDAgMTA1IDgyIDUyIDEwMyA3NyA4MyA2OCA2OCA2NiA1MSAxMDkg OTggMTA3IDczIDExMCA3NyA3OCA4NSA3MCA4NCA0NSA4MCA3NSA1MyA2NyAxMTcgOTAgODIgMTEw IDcyIDY2IDUwIDExNCA4NSA3NSA1MyAxMDIgMTA0IDgwIDExNyA3MCA1NCA4OCA3MCAxMTMgNzYg NzYgOTAgNjcgNzEgNTMgODEgOTUgMTE0IDc0IDEwOSA1NCA2OSAxMTggMTAxIDEyMCA0NSA4OCA3 NiA5OSA3OCA4MSA2NSA3NCA3OCA5NyA0OSA0NSA1NCA2NyA3MyA4NSA0OSA1MCA4NyAxMDYgNTEg MTA5IDgwIDY5IDEyMCAxMjAgMTE5IDU3IDExOCA5OCAxMTAgMTE1IDgxIDY4IDg1IDU1IDY2IDUy IDY2IDEwMiAxMDkgMTA0IDEwMCAxMjEgMTA1IDEwMiAxMDggNzYgNjUgNTUgNjUgMTAxIDUzIDkw IDcxIDExMSA4NiA4MiAxMDggNTEgNjUgOTUgOTUgMTIxIDc2IDgwIDg4IDEyMCA4MiAxMDYgNzIg NzAgMTA0IDExMiA3OSAxMDEgNjggMTEyIDk1IDk3IDEwMCAxMjAgNTYgNzggMTIxIDEwMSAxMDYg NzAgNTMgOTkgMTIyIDU3IDEyMSA2OCA3NSA4NSA3NiAxMTcgMTAzIDc4IDExNSA2OCA3NyAxMDAg MTA4IDcyIDEwMSA3NCA4MSA3OSA3NyA3MSA4NiA3NiA4OSA5NyA4MyA5MCAxMTYgNTEgNzUgODAg NTQgOTcgODcgNzggODMgMTEzIDcwIDY1IDQ5IDgwIDcyIDY4IDEwMyA0NSA0OSA0OCA5OSAxMDEg MTE3IDg0IDY5IDExNiAxMTMgOTUgMTE4IDgwIDY5IDUyIDQ1IDcxIDExNiAxMDEgMTE4IDUyIDc4 IDUyIDc1IDUyIDY5IDExNyAxMDAgMTA4IDEwNiA1MiA4MSA0NiA2NSAxMjAgODkgNTYgNjggNjcg MTE2IDY4IDk3IDcxIDEwOCAxMTUgOTggNzEgMTA4IDEwNiA5OCA1MSA4MiAxMTEgOTAgODEgNDYg ODIgMTIwIDExNSAxMDYgMTAzIDU0IDgwIDczIDY5IDEyMCA5OSAxMDkgNzEgODMgNzAgNTUgNzYg MTEwIDgzIDY5IDEwNyA2OCAxMTMgODcgNzMgNzUgMTAyIDY1IDExOSA0OSAxMTkgOTAgMTIyIDUw IDg4IDExMiA5NyA5OCA4NiA1MyA4MCAxMTkgODEgMTE1IDExMSAxMDggNzUgMTE5IDY5IDk3IDEx NyA4NyA4OSA5MCA3OCA2OSA1NyA4MSA0OSAxMDQgOTAgNzQgNjkgOTAgNDYgNTYgNzYgODggMTEz IDc3IDEwMCA0OCA3NCA3NiA3MSAxMTUgMTIwIDc3IDk3IDY2IDUzIDExNyAxMTEgNzggOTcgNzcg MTEyIDEwMyA1NSAxMTcgODUgODcgOTUgMTEyIDUyIDQ4IDgyIDEwOCA5NyA5MCA3MiA2NyAxMTkg NzcgNzMgMTIxIDEyMiAxMDcNCg0KDQoNCmFuZCBvYnRhaW5lZCB0aGlzIG91dHB1dDoNCg0KMCAx NCAyIDI0MSAyNTMgMTAxIDEyMSA3NCAxMDQgOTggNzEgOTkgMTA1IDc5IDEwNSA3NCA4MyA4NSA0 OCA2OSAxMjAgODggMTIyIDg1IDEwNSA3NiA2NyA3NCAxMDggOTggMTA5IDc3IDEwNSA3OSAxMDUg NzQgNjYgNzcgODQgNzMgNTIgODEgNDggNzQgNjggNzUgNDggMTA0IDg0IDc3IDEwNiA4NSA1MCA3 MyAxMTAgNDggNDYgOTAgMTA5IDExMCAxMDggMTEzIDg3IDEwMyAxMDYgODggMTIxIDExMyAxMTkg MTA2IDExNCA1NSA5OSA4OCA3MiAxMjEgMTE1IDU2IDcwIDU1IDU3IDk3IDExMCA3MyA4NSA3MyA1 NCA3NCA1MCA4NSA4NyAxMDAgNjUgMTIxIDgyIDgxIDY5IDk5IDcxIDY2IDg1IDQ1IDc1IDgwIDcy IDExNSAxMDEgODAgNzcgNTcgNDkgNDggOTUgODIgMTExIDg0IDY4IDcxIDExNyA0OSA3MyA4NyA1 MiA0OCA2OCAxMTAgNDggMTAwIDExOCA5OSAxMDAgODYgNjkgMTA2IDExMiA3NCA5OSA4MCA4MCA3 OCA3MyA5OCAxMjIgODcgOTkgNzcgMTIwIDY4IDEwNSA0OSA1MSA0OSA2OSAxMDYgMTAxIDEwMyA0 NSA5OCA1NiA4NiAxMDUgODcgNTMgODkgODggNTMgMTExIDgyIDEwMCA4OSAxMDAgMTA1IDgyIDUy IDEwMyA3NyA4MyA2OCA2OCA2NiA1MSAxMDkgOTggMTA3IDczIDExMCA3NyA3OCA4NSA3MCA4NCA0 NSA4MCA3NSA1MyA2NyAxMTcgOTAgODIgMTEwIDcyIDY2IDUwIDExNCA4NSA3NSA1MyAxMDIgMTA0 IDgwIDExNyA3MCA1NCA4OCA3MCAxMTMgNzYgNzYgOTAgNjcgNzEgNTMgODEgOTUgMTE0IDc0IDEw OSA1NCA2OSAxMTggMTAxIDEyMCA0NSA4OCA3NiA5OSA3OCA4MSA2NSA3NCA3OCA5NyA0OSA0NSA1 NCA2NyA3MyA4NSA0OSA1MCA4NyAxMDYgNTEgMTA5IDgwIDY5IDEyMCAxMjAgMTE5IDU3IDExOCA5 OCAxMTAgMTE1IDgxIDY4IDg1IDU1IDY2IDUyIDY2IDEwMiAxMDkgMTA0IDEwMCAxMjEgMTA1IDEw MiAxMDggNzYgNjUgNTUgNjUgMTAxIDUzIDkwIDcxIDExMSA4NiA4MiAxMDggNTEgNjUgOTUgOTUg MTIxIDc2IDgwIDg4IDEyMCA4MiAxMDYgNzIgNzAgMTA0IDExMiA3OSAxMDEgNjggMTEyIDk1IDk3 IDEwMCAxMjAgNTYgNzggMTIxIDEwMSAxMDYgNzAgNTMgOTkgMTIyIDU3IDEyMSA2OCA3NSA4NSA3 NiAxMTcgMTAzIDc4IDExNSA2OCA3NyAxMDAgMTA4IDcyIDEwMSA3NCA4MSA3OSA3NyA3MSA4NiA3 NiA4OSA5NyA4MyA5MCAxMTYgNTEgNzUgODAgNTQgOTcgODcgNzggODMgMTEzIDcwIDY1IDQ5IDgw IDcyIDY4IDEwMyA0NSA0OSA0OCA5OSAxMDEgMTE3IDg0IDY5IDExNiAxMTMgOTUgMTE4IDgwIDY5 IDUyIDQ1IDcxIDExNiAxMDEgMTE4IDUyIDc4IDUyIDc1IDUyIDY5IDExNyAxMDAgMTA4IDEwNiA1 MiA4MSA0NiA2NSAxMjAgODkgNTYgNjggNjcgMTE2IDY4IDk3IDcxIDEwOCAxMTUgOTggNzEgMTA4 IDEwNiA5OCA1MSA4MiAxMTEgOTAgODEgNDYgODIgMTIwIDExNSAxMDYgMTAzIDU0IDgwIDczIDY5 IDEyMCA5OSAxMDkgNzEgODMgNzAgNTUgNzYgMTEwIDgzIDY5IDEwNyA2OCAxMTMgODcgNzMgNzUg MTAyIDY1IDExOSA0OSAxMTkgOTAgMTIyIDUwIDg4IDExMiA5NyA5OCA4NiA1MyA4MCAxMTkgODEg MTE1IDExMSAxMDggNzUgMTE5IDY5IDk3IDExNyA4NyA4OSA5MCA3OCA2OSA1NyA4MSA0OSAxMDQg OTAgNzQgNjkgOTAgNDYgNTYgNzYgODggMTEzIDc3IDEwMCA0OCA3NCA3NiA3MSAxMTUgMTIwIDc3 IDk3IDY2IDUzIDExNyAxMTEgNzggOTcgNzcgMTEyIDEwMyA1NSAxMTcgODUgODcgOTUgMTEyIDUy IDQ4IDgyIDEwOCA5NyA5MCA3MiA2NyAxMTkgNzcgNzMgMTIxIDEyMiAxMDcgMSAwIDAgMjU1IDI1 NQ0KDQoNCg0KQ2FuIHlvdSBkZWNvbXByZXNzIG15IG91dHB1dCBhbmQgb2J0YWluIHRoZSBvcmln aW5hbCB0ZXh0PyAgQ2FuIHlvdSBzZW5kIG1lIHlvdXIgY29tcHJlc3Npb24gb3V0cHV0PyAgSeKA mWxsIHRoZW4gdHJ5IHRvIHVuY29tcHJlc3MgaXQuDQoNCg0KDQpUaGFua3MgZm9yIGRvdWJsZS1j aGVja2luZyB0aGlzIQ0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxOSwgMjAxMiAz OjQwIFBNDQpUbzogTWlrZSBKb25lczsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFJlZHVj aW5nIHRoZSBzaXplIG9mIEpXUyBwYXlsb2Fkcw0KDQoNCg0KSSBkb24ndCB0aGluayB5b3VyIGNh bGN1bGF0aW9ucyBhcmUgbm90IHF1aXRlIHJpZ2h0LCBNaWtlLg0KDQoNCg0KRGVmbGF0aW5nIHRo ZSA1MjYgY2hhcmFjdGVyIEpXRSBleGFtcGxlIGZyb20gYXBwZW5kaXggMiBnaXZlcyA0MjcgYnl0 ZXMsIG5vdCB0aGUgNTM2IHlvdSBzdGF0ZS4NCg0KDQoNCkFzc3VtaW5nIGEgSldTIGhlYWRlciBh bmQgc2lnbmF0dXJlIGlzIDM2NSBjaGFycyAoMjA0OC1iaXQgUlNBIGtleSwgYXMgcGVyIEpXUyBh cHBlbmRpeCAyKS4NCg0KDQoNCkpXU190b2RheShKV0UpID0gMzY1ICsgQjY0KDUyNikgPSAxMDY3 DQoNCkpXU196aXAoSldFKSA9IDM2NSArIDE1ICsgQjY0KDQyNykgPSA5NTAgPSBzYXZlIDExNyBj aGFycyAoMTElKQ0KDQpKV1Nfbm9fYjY0KEpXRSkgPSAzNjUgKyAxNSArIDUyNiA9IDkwNiA9IHNh dmUgMTYxIGNoYXJzICgxNSUpDQoNCg0KDQpTbyAiQVBQTFlJTkcgREVGTEFURSBUTyBUSEUgUEFZ TE9BRCIgZG9lcyBub3QgbWFrZSB0aGluZ3Mgd29yc2UsIGl0IGdpdmVzIGEgMTElIHNhdmluZy4N Cg0KDQoNClRoZXNlIG51bWJlcnMgYXJlIG5vdCB0aGF0IHJlbGV2YW50IGFzIEkgYWdyZWUgd2l0 aCBKb2huIEJyYWRsZXkgdGhhdCBhbiBhc3ltbWV0cmljIHNpZ25hdHVyZSBpcyBtb3JlIGxpa2Vs eSB0byBiZSBhcHBsaWVkIGJlZm9yZSB0aGUgZW5jcnlwdGlvbi4NCg0KDQoNCkkgc3VzcGVjdCBK T1NFIHdvdWxkIGJlIGJldHRlciBvZmYgZGVmaW5pbmcgaXRzIG9wZXJhdGlvbnMgb24gYnl0ZSBh cnJheXM6IHRoZSBmaXJzdCBieXRlIGFycmF5IGlzIGEgSlNPTiBvYmplY3QsIGFub3RoZXIgYnl0 ZSBhcnJheSBpcyB0aGUgY29udGVudDsgc2lnbmluZyBjb3ZlcnMgdGhlc2UgYnl0ZSBhcnJheXMg KHdpdGggYSBsZW5ndGgpIGV0Yy4gVGhlbiBsZWF2ZSB0aGUgYmFzZTY0dXJsIGVuY29kaW5nIHRv IHRoZSB2ZXJ5IGxhc3Qgc3RlcCAoYWZ0ZXIgYW55IGNyeXB0bykuDQoNCg0KDQotLQ0KDQpKYW1l cyBNYW5nZXINCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiBGcm9tOiBq b3NlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KDQo+IE9mIE1pa2UgSm9uZXMNCg0K PiBTZW50OiBXZWRuZXNkYXksIDE5IERlY2VtYmVyIDIwMTIgMToyNiBQTQ0KDQo+IFRvOiBqb3Nl QGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KDQo+IENjOiBEaWNrIEhhcmR0DQoNCj4g U3ViamVjdDogW2pvc2VdIFJlZHVjaW5nIHRoZSBzaXplIG9mIEpXUyBwYXlsb2Fkcw0KDQo+DQoN Cj4gSSd2ZSBub3RpY2VkIHRoYXQgbW9yZSB0aGFuIG9uZSBwZXJzb24gaGFzIGV4cHJlc3NlZCBh IGRlc2lyZSB0bw0KDQo+IHJlZHVjZSB0aGUgc2l6ZSBvZiBKV1MgcGF5bG9hZHMgYmVmb3JlIHNp Z25pbmcuICBUaGlzIGVzcGVjaWFsbHkgY29tZXMNCg0KPiB1cCB3aGVuIG5lc3RlZCBlbmNyeXB0 aW9uIGFuZCBzaWduaW5nIGlzIGJlaW5nIHBlcmZvcm1lZC4gIFRoaXMgbm90ZQ0KDQo+IGNvbnRh aW5zIGEgcXVhbnRpdGF0aXZlIGV2YWx1YXRpb24gb2Ygc29tZSBwb3NzaWJsZSBtZXRob2RzIG9m DQoNCj4gcmVkdWNpbmcgSldTIHBheWxvYWQgc2l6ZSBhbmQgYXNrcyBmb3Igd29ya2luZyBncm91 cCBpbnB1dCBiYXNlZCB1cG9uIHRoZSBkYXRhLg0KDQo+DQoNCj4gRGljayBwcm9wb3NlZCBvbmUg bWV0aG9kIGJlbG93IC0gaGF2ZSBhIGhlYWRlciBwYXJhbWV0ZXIgdG8gc2F5IHRoYXQNCg0KPiB0 aGUgcGF5bG9hZCBpcyBhbHJlYWR5IFVSTC1zYWZlIGFuZCB0aGF0IGJhc2U2NHVybCBlbmNvZGlu ZyBpcyBub3QgdG8NCg0KPiBiZSBwZXJmb3JtZWQuICBBbm90aGVyIHdheSB0aGF0IHBlb3BsZSBo YXZlIHByb3Bvc2VkIGlzIHRvIGFsbG93IHRoZQ0KDQo+IHVzZSBvZiB0aGUgInppcCIgcGFyYW1l dGVyIHRvIGNvbXByZXNzIHRoZSBKV1MgcGF5bG9hZCBiZWZvcmUNCg0KPiBiYXNlNjR1cmwgZW5j b2RpbmcuICBUbyBnZXQgc29tZSBpbml0aWFsIGRhdGEgb24gaG93IHRoZSBzb2x1dGlvbnMNCg0K PiBjb21wYXJlLCBJIHRyaWVkIGJvdGggbWV0aG9kcyB1c2luZyB0aGUgc2FtcGxlIEpXRSB2YWx1 ZSBpbg0KDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29u LXdlYi1lbmNyeXB0aW9uLQ0KDQo+IDA3I2FwcGVuZGl4LUEuMiBhcyB0aGUgSldTIHBheWxvYWQu DQoNCj4NCg0KPiBDVVJSRU5UIFNJVFVBVElPTjogIFRoZSBKV0UgaXMgNTI2IGNoYXJhY3RlcnMg aW4gbGVuZ3RoLiAgQ3VycmVudGx5LA0KDQo+IHdoZW4gdXNlZCBhcyBhIEpXUyBwYXlsb2FkLCBi YXNlNjR1cmwgZW5jb2RpbmcgaXQgd291bGQgaW5jcmVhc2UgaXRzDQoNCj4gc2l6ZSB0byA3MDIg Y2hhcmFjdGVycyAtIGFuIGluY3JlYXNlIG9mIDMzJSBvciAxNzYgY2hhcmFjdGVycy4NCg0KPg0K DQo+IEFWT0lESU5HIERPVUJMRSBCQVNFNjRVUkwgRU5DT0RJTkc6ICBJZiB3ZSB1c2VkIGEgaGVh ZGVyIHBhcmFtZXRlcg0KDQo+ICJiNjQiOmZhbHNlIHRvIGluZGljYXRlIHRoYXQgbm8gYWRkaXRp b25hbCBiYXNlNjR1cmwgZW5jb2RpbmcgaXMgdG8gYmUNCg0KPiBwZXJmb3JtZWQsIHRoZSBwYXls b2FkIHdvdWxkIGJlIDE3NiBjaGFyYWN0ZXJzIHNtYWxsZXIgdGhhbiB0aGUNCg0KPiBjdXJyZW50 IHNpdHVhdGlvbi4gIFRoZSBlbmNvZGVkIGhlYWRlciBzaXplIHdvdWxkIGluY3JlYXNlIGJ5IDE2 DQoNCj4gY2hhcmFjdGVycyAtIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBuZWVkZWQgdG8gYmFz ZTY0dXJsIGVuY29kZSB0aGlzDQoNCj4gaGVhZGVyIHBhcmFtZXRlciB2YWx1ZSBhbmQgYSBjb21t YSwgZm9yIGEgbmV0IGRlY3JlYXNlIGluIHNpemUgb2YgMTYwDQoNCj4gY2hhcmFjdGVycy4gIChZ ZXMsIHBhcnNpbmcgdGhlIHRocmVlIHBpZWNlcyB3b3VsZCBiZSBzbGlnaHRseSBtb3JlDQoNCj4g ZGlmZmljdWx0LikNCg0KPg0KDQo+IEFQUExZSU5HIERFRkxBVEUgVE8gVEhFIFBBWUxPQUQ6ICBC ZWxpZXZlIGl0IG9yIG5vdCwgdXNpbmcgREVGTEFURSBvbg0KDQo+IHRoaXMgaW5wdXQgcmVzdWx0 cyBpbiBhIExBUkdFUiBvdXRwdXQgLSA1MzYgYnl0ZXMgb3IgYSBuZXQgaW5jcmVhc2Ugb2YNCg0K PiAxMCBieXRlcy4gIElmIHlvdSB0aGluayBhYm91dCBpdCwgdGhpcyBpc24ndCB0b28gc3VycHJp c2luZywgYXMgdGhlDQoNCj4gZW5jcnlwdGVkIGRhdGEgc2hvdWxkIGNvbnRhaW4gbm8gdXNhYmxl IHByZWRpY3RhYmlsaXR5L3JlZHVuZGFuY3kuDQoNCj4gQmFzZTY0dXJsIGVuY29kaW5nIHRoZXNl IDUzNiBieXRlcyByZXN1bHRzIGluIGEgNzE1IGNoYXJhY3RlciBwYXlsb2FkDQoNCj4gLSBhbiBp bmNyZWFzZSBvZiAxODkgY2hhcmFjdGVycyBvciAzNiUuICBQbHVzLCBhZGRpbmcgInppcCI6IkRF RiIgdG8NCg0KPiB0aGUgaGVhZGVyIGFkZHMgMTYgY2hhcmFjdGVycywgZm9yIGEgdG90YWwgaW5j cmVhc2Ugb2YgMjkgY2hhcmFjdGVycw0KDQo+IG92ZXIgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLiAg Q2xlYXJseSBhIHN1Ym9wdGltYWwgY2hvaWNlIQ0KDQo+DQoNCj4gQ09OQ0xVU0lPTjogIENsZWFy bHksIGlmIHdlJ3JlIGdvaW5nIHRvIGVuYWJsZSByZWR1Y3Rpb24gb2YgdGhlIHNpemUNCg0KPiBv ZiBKV1MgcGF5bG9hZHMsIGF2b2lkaW5nIHRoZSBkb3VibGUgYmFzZTY0dXJsIGVuY29kaW5nIGlz IHByZWZlcmFibGUNCg0KPiB0byB6aXAsIHdoaWNoIGFjdHVhbGx5IG1ha2VzIHRoaW5ncyB3b3Jz ZS4NCg0KPg0KDQo+IFFVRVNUSU9OIFRPIFdPUktJTkcgR1JPVVA6ICBJJ20gY3VyaW91cyB3aGV0 aGVyIHBlb3BsZSB3b3VsZCBsaWtlIHRvDQoNCj4gc2VlIHVzIGVuYWJsZSBhdm9pZGluZyBkb3Vi bGUgYmFzZTY0ZW5jb2Rpbmcgb2YgSldTIHBheWxvYWRzIHdoZW4gdGhleQ0KDQo+IGFyZSBhbHJl YWR5IFVSTC1zYWZlLiAgVGhlIHNwYWNlIHNhdmluZ3MgYXJlIHNpZ25pZmljYW50OyB0aGV5IGNv bWUgYXQNCg0KPiB0aGUgY29zdCBvZiB0aGUgSldTIHBhcnNpbmcgYmVjb21pbmcgW3BhcnQgYmVm b3JlIGZpcnN0IHBlcmlvZCAuIHBhcnQNCg0KPiBiZXR3ZWVuIGZpcnN0IGFuZCBsYXN0IHBlcmlv ZCAuIHBhcnQgYWZ0ZXIgbGFzdCBwZXJpb2RdIHJhdGhlciB0aGFuDQoNCj4gdGhlIGN1cnJlbnQg W3BhcnQgYmVmb3JlIGZpcnN0IHBlcmlvZCAuIHBhcnQgYmV0d2VlbiBmaXJzdCBhbmQgc2Vjb25k DQoNCj4gcGVyaW9kIC4gcGFydCBhZnRlciBzZWNvbmQgcGVyaW9kICh3aXRoIG5vIG90aGVyIHBl cmlvZHMgYWxsb3dlZCldLg0KDQo+IE9waW5pb25zPw0KDQoNCg== --_000_4E1F6AAD24975D4BA5B168042967394366977C74TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkgSmFtZXMsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhtbW0gLSBteSBxdWljay1hbmQtZGlydHkgdGVz dCBjb2RlIHVzZWQgdGhlIC5ORVQgPGEgaHJlZj0iaHR0cDovL21zZG4ubWljcm9zb2Z0LmNvbS9l bi11cy9saWJyYXJ5L3N5c3RlbS5pby5jb21wcmVzc2lvbi5kZWZsYXRlc3RyZWFtKHY9VlMuOTAp LmFzcHgiPg0KU3lzdGVtLklPLkNvbXByZXNzaW9uLkRlZmxhdGVTdHJlYW08L2E+IGNsYXNzIGFu ZCBDb21wcmVzc2lvbk1vZGUuQ29tcHJlc3MgdG8gZG8gdGhlIGNvbXByZXNzaW9uLiZuYnNwOyBU aGUgZG9jdW1lbnRhdGlvbiBzYXlzIHRoYXQgaXQgaW1wbGVtZW50cyBSRkMgMTk1MSBERUZMQVRF LiZuYnNwOyBUaGF0IGJlaW5nIHNhaWQsIEkga25vdyB0aGF0IG9uZSBjYW4gdXNlIGRpZmZlcmVu dCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHNhbWUgY29tcHJlc3Npb24gYWxnb3JpdGhtDQogYW5k IGdldCBkaWZmZXJlbnQgcmVzdWx0cywgZGVwZW5kaW5nIHVwb24gdGhlIG1hdGNoZXMgYW5kIHN1 YnN0aXR1dGlvbnMgdXNlZCDigJMgYWxsIG9mIHdoaWNoIHdpbGwgdW5jb21wcmVzcyB0byB0aGUg b3JpZ2luYWwgdmFsdWUuJm5ic3A7IERvIHlvdSB3YW50IHRvIHN3YXAgZGF0YSB0byBjb25maXJt IHRoYXQgd2XigJlyZSB1c2luZyB0aGUgc2FtZSBjb21wcmVzc2lvbiBmb3JtYXQ/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkkgY29tcHJlc3NlZCB0aGVzZSBieXRlczo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjEwMSAxMjEgNzQgMTA0IDk4IDcxIDk5IDEw NSA3OSAxMDUgNzQgODMgODUgNDggNjkgMTIwIDg4IDEyMiA4NSAxMDUgNzYgNjcgNzQgMTA4IDk4 IDEwOSA3NyAxMDUgNzkgMTA1IDc0IDY2IDc3IDg0IDczIDUyIDgxIDQ4IDc0IDY4IDc1IDQ4IDEw NCA4NCA3NyAxMDYgODUgNTAgNzMgMTEwIDQ4IDQ2IDkwIDEwOSAxMTAgMTA4IDExMyA4NyAxMDMg MTA2IDg4IDEyMSAxMTMgMTE5IDEwNiAxMTQgNTUgOTkgODgNCiA3MiAxMjEgMTE1IDU2IDcwIDU1 IDU3IDk3IDExMCA3MyA4NSA3MyA1NCA3NCA1MCA4NSA4NyAxMDAgNjUgMTIxIDgyIDgxIDY5IDk5 IDcxIDY2IDg1IDQ1IDc1IDgwIDcyIDExNSAxMDEgODAgNzcgNTcgNDkgNDggOTUgODIgMTExIDg0 IDY4IDcxIDExNyA0OSA3MyA4NyA1MiA0OCA2OCAxMTAgNDggMTAwIDExOCA5OSAxMDAgODYgNjkg MTA2IDExMiA3NCA5OSA4MCA4MCA3OCA3MyA5OCAxMjIgODcgOTkgNzcgMTIwIDY4IDEwNSA0OSA1 MSA0OSA2OSAxMDYNCiAxMDEgMTAzIDQ1IDk4IDU2IDg2IDEwNSA4NyA1MyA4OSA4OCA1MyAxMTEg ODIgMTAwIDg5IDEwMCAxMDUgODIgNTIgMTAzIDc3IDgzIDY4IDY4IDY2IDUxIDEwOSA5OCAxMDcg NzMgMTEwIDc3IDc4IDg1IDcwIDg0IDQ1IDgwIDc1IDUzIDY3IDExNyA5MCA4MiAxMTAgNzIgNjYg NTAgMTE0IDg1IDc1IDUzIDEwMiAxMDQgODAgMTE3IDcwIDU0IDg4IDcwIDExMyA3NiA3NiA5MCA2 NyA3MSA1MyA4MSA5NSAxMTQgNzQgMTA5IDU0IDY5IDExOCAxMDEgMTIwDQogNDUgODggNzYgOTkg NzggODEgNjUgNzQgNzggOTcgNDkgNDUgNTQgNjcgNzMgODUgNDkgNTAgODcgMTA2IDUxIDEwOSA4 MCA2OSAxMjAgMTIwIDExOSA1NyAxMTggOTggMTEwIDExNSA4MSA2OCA4NSA1NSA2NiA1MiA2NiAx MDIgMTA5IDEwNCAxMDAgMTIxIDEwNSAxMDIgMTA4IDc2IDY1IDU1IDY1IDEwMSA1MyA5MCA3MSAx MTEgODYgODIgMTA4IDUxIDY1IDk1IDk1IDEyMSA3NiA4MCA4OCAxMjAgODIgMTA2IDcyIDcwIDEw NCAxMTIgNzkgMTAxIDY4DQogMTEyIDk1IDk3IDEwMCAxMjAgNTYgNzggMTIxIDEwMSAxMDYgNzAg NTMgOTkgMTIyIDU3IDEyMSA2OCA3NSA4NSA3NiAxMTcgMTAzIDc4IDExNSA2OCA3NyAxMDAgMTA4 IDcyIDEwMSA3NCA4MSA3OSA3NyA3MSA4NiA3NiA4OSA5NyA4MyA5MCAxMTYgNTEgNzUgODAgNTQg OTcgODcgNzggODMgMTEzIDcwIDY1IDQ5IDgwIDcyIDY4IDEwMyA0NSA0OSA0OCA5OSAxMDEgMTE3 IDg0IDY5IDExNiAxMTMgOTUgMTE4IDgwIDY5IDUyIDQ1IDcxIDExNiAxMDEgMTE4DQogNTIgNzgg NTIgNzUgNTIgNjkgMTE3IDEwMCAxMDggMTA2IDUyIDgxIDQ2IDY1IDEyMCA4OSA1NiA2OCA2NyAx MTYgNjggOTcgNzEgMTA4IDExNSA5OCA3MSAxMDggMTA2IDk4IDUxIDgyIDExMSA5MCA4MSA0NiA4 MiAxMjAgMTE1IDEwNiAxMDMgNTQgODAgNzMgNjkgMTIwIDk5IDEwOSA3MSA4MyA3MCA1NSA3NiAx MTAgODMgNjkgMTA3IDY4IDExMyA4NyA3MyA3NSAxMDIgNjUgMTE5IDQ5IDExOSA5MCAxMjIgNTAg ODggMTEyIDk3IDk4IDg2IDUzIDgwDQogMTE5IDgxIDExNSAxMTEgMTA4IDc1IDExOSA2OSA5NyAx MTcgODcgODkgOTAgNzggNjkgNTcgODEgNDkgMTA0IDkwIDc0IDY5IDkwIDQ2IDU2IDc2IDg4IDEx MyA3NyAxMDAgNDggNzQgNzYgNzEgMTE1IDEyMCA3NyA5NyA2NiA1MyAxMTcgMTExIDc4IDk3IDc3 IDExMiAxMDMgNTUgMTE3IDg1IDg3IDk1IDExMiA1MiA0OCA4MiAxMDggOTcgOTAgNzIgNjcgMTE5 IDc3IDczIDEyMSAxMjIgMTA3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmFuZCBvYnRh aW5lZCB0aGlzIG91dHB1dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjAgMTQgMiAyNDEgMjUzIDEwMSAxMjEgNzQgMTA0IDk4IDcxIDk5IDEwNSA3OSAxMDUgNzQgODMg ODUgNDggNjkgMTIwIDg4IDEyMiA4NSAxMDUgNzYgNjcgNzQgMTA4IDk4IDEwOSA3NyAxMDUgNzkg MTA1IDc0IDY2IDc3IDg0IDczIDUyIDgxIDQ4IDc0IDY4IDc1IDQ4IDEwNCA4NCA3NyAxMDYgODUg NTAgNzMgMTEwIDQ4IDQ2IDkwIDEwOSAxMTAgMTA4IDExMyA4NyAxMDMgMTA2IDg4IDEyMSAxMTMg MTE5IDEwNg0KIDExNCA1NSA5OSA4OCA3MiAxMjEgMTE1IDU2IDcwIDU1IDU3IDk3IDExMCA3MyA4 NSA3MyA1NCA3NCA1MCA4NSA4NyAxMDAgNjUgMTIxIDgyIDgxIDY5IDk5IDcxIDY2IDg1IDQ1IDc1 IDgwIDcyIDExNSAxMDEgODAgNzcgNTcgNDkgNDggOTUgODIgMTExIDg0IDY4IDcxIDExNyA0OSA3 MyA4NyA1MiA0OCA2OCAxMTAgNDggMTAwIDExOCA5OSAxMDAgODYgNjkgMTA2IDExMiA3NCA5OSA4 MCA4MCA3OCA3MyA5OCAxMjIgODcgOTkgNzcgMTIwIDY4IDEwNQ0KIDQ5IDUxIDQ5IDY5IDEwNiAx MDEgMTAzIDQ1IDk4IDU2IDg2IDEwNSA4NyA1MyA4OSA4OCA1MyAxMTEgODIgMTAwIDg5IDEwMCAx MDUgODIgNTIgMTAzIDc3IDgzIDY4IDY4IDY2IDUxIDEwOSA5OCAxMDcgNzMgMTEwIDc3IDc4IDg1 IDcwIDg0IDQ1IDgwIDc1IDUzIDY3IDExNyA5MCA4MiAxMTAgNzIgNjYgNTAgMTE0IDg1IDc1IDUz IDEwMiAxMDQgODAgMTE3IDcwIDU0IDg4IDcwIDExMyA3NiA3NiA5MCA2NyA3MSA1MyA4MSA5NSAx MTQgNzQgMTA5IDU0DQogNjkgMTE4IDEwMSAxMjAgNDUgODggNzYgOTkgNzggODEgNjUgNzQgNzgg OTcgNDkgNDUgNTQgNjcgNzMgODUgNDkgNTAgODcgMTA2IDUxIDEwOSA4MCA2OSAxMjAgMTIwIDEx OSA1NyAxMTggOTggMTEwIDExNSA4MSA2OCA4NSA1NSA2NiA1MiA2NiAxMDIgMTA5IDEwNCAxMDAg MTIxIDEwNSAxMDIgMTA4IDc2IDY1IDU1IDY1IDEwMSA1MyA5MCA3MSAxMTEgODYgODIgMTA4IDUx IDY1IDk1IDk1IDEyMSA3NiA4MCA4OCAxMjAgODIgMTA2IDcyIDcwIDEwNA0KIDExMiA3OSAxMDEg NjggMTEyIDk1IDk3IDEwMCAxMjAgNTYgNzggMTIxIDEwMSAxMDYgNzAgNTMgOTkgMTIyIDU3IDEy MSA2OCA3NSA4NSA3NiAxMTcgMTAzIDc4IDExNSA2OCA3NyAxMDAgMTA4IDcyIDEwMSA3NCA4MSA3 OSA3NyA3MSA4NiA3NiA4OSA5NyA4MyA5MCAxMTYgNTEgNzUgODAgNTQgOTcgODcgNzggODMgMTEz IDcwIDY1IDQ5IDgwIDcyIDY4IDEwMyA0NSA0OSA0OCA5OSAxMDEgMTE3IDg0IDY5IDExNiAxMTMg OTUgMTE4IDgwIDY5IDUyIDQ1DQogNzEgMTE2IDEwMSAxMTggNTIgNzggNTIgNzUgNTIgNjkgMTE3 IDEwMCAxMDggMTA2IDUyIDgxIDQ2IDY1IDEyMCA4OSA1NiA2OCA2NyAxMTYgNjggOTcgNzEgMTA4 IDExNSA5OCA3MSAxMDggMTA2IDk4IDUxIDgyIDExMSA5MCA4MSA0NiA4MiAxMjAgMTE1IDEwNiAx MDMgNTQgODAgNzMgNjkgMTIwIDk5IDEwOSA3MSA4MyA3MCA1NSA3NiAxMTAgODMgNjkgMTA3IDY4 IDExMyA4NyA3MyA3NSAxMDIgNjUgMTE5IDQ5IDExOSA5MCAxMjIgNTAgODggMTEyDQogOTcgOTgg ODYgNTMgODAgMTE5IDgxIDExNSAxMTEgMTA4IDc1IDExOSA2OSA5NyAxMTcgODcgODkgOTAgNzgg NjkgNTcgODEgNDkgMTA0IDkwIDc0IDY5IDkwIDQ2IDU2IDc2IDg4IDExMyA3NyAxMDAgNDggNzQg NzYgNzEgMTE1IDEyMCA3NyA5NyA2NiA1MyAxMTcgMTExIDc4IDk3IDc3IDExMiAxMDMgNTUgMTE3 IDg1IDg3IDk1IDExMiA1MiA0OCA4MiAxMDggOTcgOTAgNzIgNjcgMTE5IDc3IDczIDEyMSAxMjIg MTA3IDEgMCAwIDI1NSAyNTU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2FuIHlvdSBk ZWNvbXByZXNzIG15IG91dHB1dCBhbmQgb2J0YWluIHRoZSBvcmlnaW5hbCB0ZXh0PyZuYnNwOyBD YW4geW91IHNlbmQgbWUgeW91ciBjb21wcmVzc2lvbiBvdXRwdXQ/ICZuYnNwO0nigJlsbCB0aGVu IHRyeSB0byB1bmNvbXByZXNzIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFu a3MgZm9yIGRvdWJsZS1jaGVja2luZyB0aGlzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21d IDxicj4NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTksIDIwMTIgMzo0MCBQTTxicj4NClRv OiBNaWtlIEpvbmVzOyBqb3NlQGlldGYub3JnPGJyPg0KU3ViamVjdDogUkU6IFJlZHVjaW5nIHRo ZSBzaXplIG9mIEpXUyBwYXlsb2FkczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBkb24ndCB0aGluayB5 b3VyIGNhbGN1bGF0aW9ucyBhcmUgbm90IHF1aXRlIHJpZ2h0LCBNaWtlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5EZWZsYXRpbmcgdGhlIDUyNiBjaGFyYWN0ZXIgSldFIGV4YW1wbGUg ZnJvbSBhcHBlbmRpeCAyIGdpdmVzIDQyNyBieXRlcywgbm90IHRoZSA1MzYgeW91IHN0YXRlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Bc3N1bWluZyBhIEpXUyBoZWFkZXIgYW5kIHNp Z25hdHVyZSBpcyAzNjUgY2hhcnMgKDIwNDgtYml0IFJTQSBrZXksIGFzIHBlciBKV1MgYXBwZW5k aXggMikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkpXU190b2RheShKV0UpID0gMzY1 ICYjNDM7IEI2NCg1MjYpID0gMTA2NzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SldTX3ppcChKV0UpID0gMzY1ICYjNDM7IDE1ICYjNDM7IEI2NCg0MjcpID0gOTUwID0g c2F2ZSAxMTcgY2hhcnMgKDExJSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkpXU19ub19iNjQoSldFKSA9IDM2NSAmIzQzOyAxNSAmIzQzOyA1MjYgPSA5MDYgPSBzYXZl IDE2MSBjaGFycyAoMTUlKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TbyAmcXVvdDtB UFBMWUlORyBERUZMQVRFIFRPIFRIRSBQQVlMT0FEJnF1b3Q7IGRvZXMgbm90IG1ha2UgdGhpbmdz IHdvcnNlLCBpdCBnaXZlcyBhIDExJSBzYXZpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlRoZXNlIG51bWJlcnMgYXJlIG5vdCB0aGF0IHJlbGV2YW50IGFzIEkgYWdyZWUgd2l0aCBK b2huIEJyYWRsZXkgdGhhdCBhbiBhc3ltbWV0cmljIHNpZ25hdHVyZSBpcyBtb3JlIGxpa2VseSB0 byBiZSBhcHBsaWVkIGJlZm9yZSB0aGUgZW5jcnlwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SSBzdXNwZWN0IEpPU0Ugd291bGQgYmUgYmV0dGVyIG9mZiBkZWZpbmluZyBpdHMg b3BlcmF0aW9ucyBvbiBieXRlIGFycmF5czogdGhlIGZpcnN0IGJ5dGUgYXJyYXkgaXMgYSBKU09O IG9iamVjdCwgYW5vdGhlciBieXRlIGFycmF5IGlzIHRoZSBjb250ZW50OyBzaWduaW5nIGNvdmVy cyB0aGVzZSBieXRlIGFycmF5cyAod2l0aCBhIGxlbmd0aCkgZXRjLiBUaGVuIGxlYXZlIHRoZSBi YXNlNjR1cmwgZW5jb2RpbmcNCiB0byB0aGUgdmVyeSBsYXN0IHN0ZXAgKGFmdGVyIGFueSBjcnlw dG8pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91 bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IFs8YSBocmVmPSJtYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+XQ0KIE9uIEJlaGFsZiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgT2YgTWlrZSBKb25lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBTZW50OiBXZWRuZXNkYXksIDE5IERlY2VtYmVyIDIwMTIgMToyNiBQTTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRv Ompvc2VAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5qb3NlQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2M6IERpY2sgSGFyZHQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU3ViamVjdDogW2pvc2VdIFJlZHVjaW5nIHRoZSBz aXplIG9mIEpXUyBwYXlsb2FkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSSd2 ZSBub3RpY2VkIHRoYXQgbW9yZSB0aGFuIG9uZSBwZXJzb24gaGFzIGV4cHJlc3NlZCBhIGRlc2ly ZSB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJlZHVj ZSB0aGUgc2l6ZSBvZiBKV1MgcGF5bG9hZHMgYmVmb3JlIHNpZ25pbmcuJm5ic3A7IFRoaXMgZXNw ZWNpYWxseSBjb21lcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IHVwIHdoZW4gbmVzdGVkIGVuY3J5cHRpb24gYW5kIHNpZ25pbmcgaXMgYmVpbmcgcGVyZm9y bWVkLiZuYnNwOyBUaGlzIG5vdGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBjb250YWlucyBhIHF1YW50aXRhdGl2ZSBldmFsdWF0aW9uIG9mIHNvbWUgcG9z c2libGUgbWV0aG9kcyBvZg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHJlZHVjaW5nIEpXUyBwYXlsb2FkIHNpemUgYW5kIGFza3MgZm9yIHdvcmtpbmcgZ3Jv dXAgaW5wdXQgYmFzZWQgdXBvbiB0aGUgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IERpY2sgcHJvcG9zZWQgb25lIG1ldGhvZCBiZWxvdyAtIGhhdmUgYSBoZWFkZXIgcGFy YW1ldGVyIHRvIHNheSB0aGF0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgdGhlIHBheWxvYWQgaXMgYWxyZWFkeSBVUkwtc2FmZSBhbmQgdGhhdCBiYXNlNjR1 cmwgZW5jb2RpbmcgaXMgbm90IHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgYmUgcGVyZm9ybWVkLiZuYnNwOyBBbm90aGVyIHdheSB0aGF0IHBlb3BsZSBo YXZlIHByb3Bvc2VkIGlzIHRvIGFsbG93IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IHVzZSBvZiB0aGUgJnF1b3Q7emlwJnF1b3Q7IHBhcmFtZXRlciB0 byBjb21wcmVzcyB0aGUgSldTIHBheWxvYWQgYmVmb3JlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgYmFzZTY0dXJsIGVuY29kaW5nLiZuYnNwOyBUbyBnZXQg c29tZSBpbml0aWFsIGRhdGEgb24gaG93IHRoZSBzb2x1dGlvbnMNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjb21wYXJlLCBJIHRyaWVkIGJvdGggbWV0aG9k cyB1c2luZyB0aGUgc2FtcGxlIEpXRSB2YWx1ZSBpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi0iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDA3I2FwcGVuZGl4LUEuMiBh cyB0aGUgSldTIHBheWxvYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBDVVJS RU5UIFNJVFVBVElPTjombmJzcDsgVGhlIEpXRSBpcyA1MjYgY2hhcmFjdGVycyBpbiBsZW5ndGgu Jm5ic3A7IEN1cnJlbnRseSwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyB3aGVuIHVzZWQgYXMgYSBKV1MgcGF5bG9hZCwgYmFzZTY0dXJsIGVuY29kaW5nIGl0 IHdvdWxkIGluY3JlYXNlIGl0cw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IHNpemUgdG8gNzAyIGNoYXJhY3RlcnMgLSBhbiBpbmNyZWFzZSBvZiAzMyUgb3Ig MTc2IGNoYXJhY3RlcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBVk9JRElO RyBET1VCTEUgQkFTRTY0VVJMIEVOQ09ESU5HOiZuYnNwOyBJZiB3ZSB1c2VkIGEgaGVhZGVyIHBh cmFtZXRlcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZx dW90O2I2NCZxdW90OzpmYWxzZSB0byBpbmRpY2F0ZSB0aGF0IG5vIGFkZGl0aW9uYWwgYmFzZTY0 dXJsIGVuY29kaW5nIGlzIHRvIGJlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgcGVyZm9ybWVkLCB0aGUgcGF5bG9hZCB3b3VsZCBiZSAxNzYgY2hhcmFjdGVy cyBzbWFsbGVyIHRoYW4gdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgY3VycmVudCBzaXR1YXRpb24uJm5ic3A7IFRoZSBlbmNvZGVkIGhlYWRlciBzaXpl IHdvdWxkIGluY3JlYXNlIGJ5IDE2DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgY2hhcmFjdGVycyAtIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBuZWVkZWQg dG8gYmFzZTY0dXJsIGVuY29kZSB0aGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgaGVhZGVyIHBhcmFtZXRlciB2YWx1ZSBhbmQgYSBjb21tYSwgZm9yIGEg bmV0IGRlY3JlYXNlIGluIHNpemUgb2YgMTYwDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgY2hhcmFjdGVycy4mbmJzcDsgKFllcywgcGFyc2luZyB0aGUgdGhy ZWUgcGllY2VzIHdvdWxkIGJlIHNsaWdodGx5IG1vcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgZGlmZmljdWx0Lik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IEFQUExZSU5HIERFRkxBVEUgVE8gVEhFIFBBWUxPQUQ6Jm5ic3A7IEJlbGlldmUg aXQgb3Igbm90LCB1c2luZyBERUZMQVRFIG9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdGhpcyBpbnB1dCByZXN1bHRzIGluIGEgTEFSR0VSIG91dHB1dCAt IDUzNiBieXRlcyBvciBhIG5ldCBpbmNyZWFzZSBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAxMCBieXRlcy4mbmJzcDsgSWYgeW91IHRoaW5rIGFib3V0IGl0 LCB0aGlzIGlzbid0IHRvbyBzdXJwcmlzaW5nLCBhcyB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBlbmNyeXB0ZWQgZGF0YSBzaG91bGQgY29udGFpbiBu byB1c2FibGUgcHJlZGljdGFiaWxpdHkvcmVkdW5kYW5jeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgQmFzZTY0dXJsIGVuY29kaW5nIHRoZXNlIDUzNiBieXRl cyByZXN1bHRzIGluIGEgNzE1IGNoYXJhY3RlciBwYXlsb2FkDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLSBhbiBpbmNyZWFzZSBvZiAxODkgY2hhcmFjdGVy cyBvciAzNiUuJm5ic3A7IFBsdXMsIGFkZGluZyAmcXVvdDt6aXAmcXVvdDs6JnF1b3Q7REVGJnF1 b3Q7IHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhl IGhlYWRlciBhZGRzIDE2IGNoYXJhY3RlcnMsIGZvciBhIHRvdGFsIGluY3JlYXNlIG9mIDI5IGNo YXJhY3RlcnMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBv dmVyIHRoZSBjdXJyZW50IHNpdHVhdGlvbi4mbmJzcDsgQ2xlYXJseSBhIHN1Ym9wdGltYWwgY2hv aWNlITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ09OQ0xVU0lPTjombmJzcDsg Q2xlYXJseSwgaWYgd2UncmUgZ29pbmcgdG8gZW5hYmxlIHJlZHVjdGlvbiBvZiB0aGUgc2l6ZQ0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG9mIEpXUyBwYXls b2FkcywgYXZvaWRpbmcgdGhlIGRvdWJsZSBiYXNlNjR1cmwgZW5jb2RpbmcgaXMgcHJlZmVyYWJs ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRvIHppcCwg d2hpY2ggYWN0dWFsbHkgbWFrZXMgdGhpbmdzIHdvcnNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgUVVFU1RJT04gVE8gV09SS0lORyBHUk9VUDombmJzcDsgSSdtIGN1cmlvdXMg d2hldGhlciBwZW9wbGUgd291bGQgbGlrZSB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IHNlZSB1cyBlbmFibGUgYXZvaWRpbmcgZG91YmxlIGJhc2U2NGVu Y29kaW5nIG9mIEpXUyBwYXlsb2FkcyB3aGVuIHRoZXkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcmUgYWxyZWFkeSBVUkwtc2FmZS4mbmJzcDsgVGhlIHNw YWNlIHNhdmluZ3MgYXJlIHNpZ25pZmljYW50OyB0aGV5IGNvbWUgYXQNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgY29zdCBvZiB0aGUgSldTIHBhcnNp bmcgYmVjb21pbmcgW3BhcnQgYmVmb3JlIGZpcnN0IHBlcmlvZCAuIHBhcnQNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBiZXR3ZWVuIGZpcnN0IGFuZCBsYXN0 IHBlcmlvZCAuIHBhcnQgYWZ0ZXIgbGFzdCBwZXJpb2RdIHJhdGhlciB0aGFuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIGN1cnJlbnQgW3BhcnQgYmVm b3JlIGZpcnN0IHBlcmlvZCAuIHBhcnQgYmV0d2VlbiBmaXJzdCBhbmQgc2Vjb25kDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcGVyaW9kIC4gcGFydCBhZnRl ciBzZWNvbmQgcGVyaW9kICh3aXRoIG5vIG90aGVyIHBlcmlvZHMgYWxsb3dlZCldLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPcGluaW9ucz88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B168042967394366977C74TK5EX14MBXC283r_-- From James.H.Manger@team.telstra.com Wed Dec 19 16:39:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD99E21F8831 for ; Wed, 19 Dec 2012 16:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOxOLshCE--5 for ; Wed, 19 Dec 2012 16:39:07 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id CEAA621F8739 for ; Wed, 19 Dec 2012 16:39:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,320,1355058000"; d="scan'208,217";a="106727363" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 20 Dec 2012 11:39:06 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6931"; a="52791810" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcani.tcif.telstra.com.au with ESMTP; 20 Dec 2012 11:39:05 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Thu, 20 Dec 2012 11:39:04 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 20 Dec 2012 11:39:02 +1100 Thread-Topic: Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgArYb9QAAEkkLAAAb5OYA== Message-ID: <255B9BB34FB7D647A506DC292726F6E115041F6786@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F65F9@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977C74@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366977C74@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115041F6786WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 00:39:08 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115041F6786WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCg0KWW91ciBERUZBTFRFIG91dHB1dCBpcyBub3QgZG9pbmcgYW55IGNvbXByZXNzaW9u LiBJdCBpcyB0aGUgb3JpZ2luYWwgSldFIGNvbnRlbnQgd2l0aCBhIDUtYnl0ZSBwcmVmaXggKDAw IDBFIDAyIEYxIEZEKSBhbmQgNS1ieXRlIHN1ZmZpeCAoMDEgMDAgMDAgRkYgRkYpLg0KVGhlIGZp cnN0IGJ5dGUgMDAgbWVhbnMgTk8gQ09NUFJFU1NJT04gYW5kIE5PVCBUSEUgTEFTVCBCTE9DSzsg MEUgMDIgaXMgdGhlIGxlbmd0aCAoMHgyMEUgPSA1MjYpOyBGMSBGRCBpcyB0aGUgaW52ZXJzZSBv ZiAwRSAwMi4NCkluIHRoZSBsYXN0IDUgYnl0ZXMsIDAxIG1lYW4gTk8gQ09NUFJFU1NJT04gYW5k IExBU1QgQkxPQ0s7IHRoZSBsZW5ndGggb2YgdGhpcyBibG9jayBpcyAwLg0KDQpQZXJoYXBzIHlv dXIgY29tcHJlc3Npb24gbGlicmFyeSBkb2VzbuKAmXQgYm90aGVyIHRvIHRyeSB0byBjb21wcmVz cyBpZiB0aGUgY29udGVudCBpcyBmYWlybHkgc2hvcnQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K RnJvbTogTWlrZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0NClNl bnQ6IFRodXJzZGF5LCAyMCBEZWNlbWJlciAyMDEyIDEwOjU0IEFNDQpUbzogTWFuZ2VyLCBKYW1l cyBIOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogUmVkdWNpbmcgdGhlIHNpemUgb2YgSldT IHBheWxvYWRzDQoNCg0KSGkgSmFtZXMsDQoNCg0KDQpIbW1tIC0gbXkgcXVpY2stYW5kLWRpcnR5 IHRlc3QgY29kZSB1c2VkIHRoZSAuTkVUIFN5c3RlbS5JTy5Db21wcmVzc2lvbi5EZWZsYXRlU3Ry ZWFtPGh0dHA6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9zeXN0ZW0uaW8uY29t cHJlc3Npb24uZGVmbGF0ZXN0cmVhbSh2PVZTLjkwKS5hc3B4PiBjbGFzcyBhbmQgQ29tcHJlc3Np b25Nb2RlLkNvbXByZXNzIHRvIGRvIHRoZSBjb21wcmVzc2lvbi4gIFRoZSBkb2N1bWVudGF0aW9u IHNheXMgdGhhdCBpdCBpbXBsZW1lbnRzIFJGQyAxOTUxIERFRkxBVEUuICBUaGF0IGJlaW5nIHNh aWQsIEkga25vdyB0aGF0IG9uZSBjYW4gdXNlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgb2Yg dGhlIHNhbWUgY29tcHJlc3Npb24gYWxnb3JpdGhtIGFuZCBnZXQgZGlmZmVyZW50IHJlc3VsdHMs IGRlcGVuZGluZyB1cG9uIHRoZSBtYXRjaGVzIGFuZCBzdWJzdGl0dXRpb25zIHVzZWQg4oCTIGFs bCBvZiB3aGljaCB3aWxsIHVuY29tcHJlc3MgdG8gdGhlIG9yaWdpbmFsIHZhbHVlLiAgRG8geW91 IHdhbnQgdG8gc3dhcCBkYXRhIHRvIGNvbmZpcm0gdGhhdCB3ZeKAmXJlIHVzaW5nIHRoZSBzYW1l IGNvbXByZXNzaW9uIGZvcm1hdD8NCg0KDQoNCkkgY29tcHJlc3NlZCB0aGVzZSBieXRlczoNCg0K MTAxIDEyMSA3NCAxMDQgOTggNzEgOTkgMTA1IDc5IDEwNSA3NCA4MyA4NSA0OCA2OSAxMjAgODgg MTIyIDg1IDEwNSA3NiA2NyA3NCAxMDggOTggMTA5IDc3IDEwNSA3OSAxMDUgNzQgNjYgNzcgODQg NzMgNTIgODEgNDggNzQgNjggNzUgNDggMTA0IDg0IDc3IDEwNiA4NSA1MCA3MyAxMTAgNDggNDYg OTAgMTA5IDExMCAxMDggMTEzIDg3IDEwMyAxMDYgODggMTIxIDExMyAxMTkgMTA2IDExNCA1NSA5 OSA4OCA3MiAxMjEgMTE1IDU2IDcwIDU1IDU3IDk3IDExMCA3MyA4NSA3MyA1NCA3NCA1MCA4NSA4 NyAxMDAgNjUgMTIxIDgyIDgxIDY5IDk5IDcxIDY2IDg1IDQ1IDc1IDgwIDcyIDExNSAxMDEgODAg NzcgNTcgNDkgNDggOTUgODIgMTExIDg0IDY4IDcxIDExNyA0OSA3MyA4NyA1MiA0OCA2OCAxMTAg NDggMTAwIDExOCA5OSAxMDAgODYgNjkgMTA2IDExMiA3NCA5OSA4MCA4MCA3OCA3MyA5OCAxMjIg ODcgOTkgNzcgMTIwIDY4IDEwNSA0OSA1MSA0OSA2OSAxMDYgMTAxIDEwMyA0NSA5OCA1NiA4NiAx MDUgODcgNTMgODkgODggNTMgMTExIDgyIDEwMCA4OSAxMDAgMTA1IDgyIDUyIDEwMyA3NyA4MyA2 OCA2OCA2NiA1MSAxMDkgOTggMTA3IDczIDExMCA3NyA3OCA4NSA3MCA4NCA0NSA4MCA3NSA1MyA2 NyAxMTcgOTAgODIgMTEwIDcyIDY2IDUwIDExNCA4NSA3NSA1MyAxMDIgMTA0IDgwIDExNyA3MCA1 NCA4OCA3MCAxMTMgNzYgNzYgOTAgNjcgNzEgNTMgODEgOTUgMTE0IDc0IDEwOSA1NCA2OSAxMTgg MTAxIDEyMCA0NSA4OCA3NiA5OSA3OCA4MSA2NSA3NCA3OCA5NyA0OSA0NSA1NCA2NyA3MyA4NSA0 OSA1MCA4NyAxMDYgNTEgMTA5IDgwIDY5IDEyMCAxMjAgMTE5IDU3IDExOCA5OCAxMTAgMTE1IDgx IDY4IDg1IDU1IDY2IDUyIDY2IDEwMiAxMDkgMTA0IDEwMCAxMjEgMTA1IDEwMiAxMDggNzYgNjUg NTUgNjUgMTAxIDUzIDkwIDcxIDExMSA4NiA4MiAxMDggNTEgNjUgOTUgOTUgMTIxIDc2IDgwIDg4 IDEyMCA4MiAxMDYgNzIgNzAgMTA0IDExMiA3OSAxMDEgNjggMTEyIDk1IDk3IDEwMCAxMjAgNTYg NzggMTIxIDEwMSAxMDYgNzAgNTMgOTkgMTIyIDU3IDEyMSA2OCA3NSA4NSA3NiAxMTcgMTAzIDc4 IDExNSA2OCA3NyAxMDAgMTA4IDcyIDEwMSA3NCA4MSA3OSA3NyA3MSA4NiA3NiA4OSA5NyA4MyA5 MCAxMTYgNTEgNzUgODAgNTQgOTcgODcgNzggODMgMTEzIDcwIDY1IDQ5IDgwIDcyIDY4IDEwMyA0 NSA0OSA0OCA5OSAxMDEgMTE3IDg0IDY5IDExNiAxMTMgOTUgMTE4IDgwIDY5IDUyIDQ1IDcxIDEx NiAxMDEgMTE4IDUyIDc4IDUyIDc1IDUyIDY5IDExNyAxMDAgMTA4IDEwNiA1MiA4MSA0NiA2NSAx MjAgODkgNTYgNjggNjcgMTE2IDY4IDk3IDcxIDEwOCAxMTUgOTggNzEgMTA4IDEwNiA5OCA1MSA4 MiAxMTEgOTAgODEgNDYgODIgMTIwIDExNSAxMDYgMTAzIDU0IDgwIDczIDY5IDEyMCA5OSAxMDkg NzEgODMgNzAgNTUgNzYgMTEwIDgzIDY5IDEwNyA2OCAxMTMgODcgNzMgNzUgMTAyIDY1IDExOSA0 OSAxMTkgOTAgMTIyIDUwIDg4IDExMiA5NyA5OCA4NiA1MyA4MCAxMTkgODEgMTE1IDExMSAxMDgg NzUgMTE5IDY5IDk3IDExNyA4NyA4OSA5MCA3OCA2OSA1NyA4MSA0OSAxMDQgOTAgNzQgNjkgOTAg NDYgNTYgNzYgODggMTEzIDc3IDEwMCA0OCA3NCA3NiA3MSAxMTUgMTIwIDc3IDk3IDY2IDUzIDEx NyAxMTEgNzggOTcgNzcgMTEyIDEwMyA1NSAxMTcgODUgODcgOTUgMTEyIDUyIDQ4IDgyIDEwOCA5 NyA5MCA3MiA2NyAxMTkgNzcgNzMgMTIxIDEyMiAxMDcNCg0KDQoNCmFuZCBvYnRhaW5lZCB0aGlz IG91dHB1dDoNCg0KMCAxNCAyIDI0MSAyNTMgMTAxIDEyMSA3NCAxMDQgOTggNzEgOTkgMTA1IDc5 IDEwNSA3NCA4MyA4NSA0OCA2OSAxMjAgODggMTIyIDg1IDEwNSA3NiA2NyA3NCAxMDggOTggMTA5 IDc3IDEwNSA3OSAxMDUgNzQgNjYgNzcgODQgNzMgNTIgODEgNDggNzQgNjggNzUgNDggMTA0IDg0 IDc3IDEwNiA4NSA1MCA3MyAxMTAgNDggNDYgOTAgMTA5IDExMCAxMDggMTEzIDg3IDEwMyAxMDYg ODggMTIxIDExMyAxMTkgMTA2IDExNCA1NSA5OSA4OCA3MiAxMjEgMTE1IDU2IDcwIDU1IDU3IDk3 IDExMCA3MyA4NSA3MyA1NCA3NCA1MCA4NSA4NyAxMDAgNjUgMTIxIDgyIDgxIDY5IDk5IDcxIDY2 IDg1IDQ1IDc1IDgwIDcyIDExNSAxMDEgODAgNzcgNTcgNDkgNDggOTUgODIgMTExIDg0IDY4IDcx IDExNyA0OSA3MyA4NyA1MiA0OCA2OCAxMTAgNDggMTAwIDExOCA5OSAxMDAgODYgNjkgMTA2IDEx MiA3NCA5OSA4MCA4MCA3OCA3MyA5OCAxMjIgODcgOTkgNzcgMTIwIDY4IDEwNSA0OSA1MSA0OSA2 OSAxMDYgMTAxIDEwMyA0NSA5OCA1NiA4NiAxMDUgODcgNTMgODkgODggNTMgMTExIDgyIDEwMCA4 OSAxMDAgMTA1IDgyIDUyIDEwMyA3NyA4MyA2OCA2OCA2NiA1MSAxMDkgOTggMTA3IDczIDExMCA3 NyA3OCA4NSA3MCA4NCA0NSA4MCA3NSA1MyA2NyAxMTcgOTAgODIgMTEwIDcyIDY2IDUwIDExNCA4 NSA3NSA1MyAxMDIgMTA0IDgwIDExNyA3MCA1NCA4OCA3MCAxMTMgNzYgNzYgOTAgNjcgNzEgNTMg ODEgOTUgMTE0IDc0IDEwOSA1NCA2OSAxMTggMTAxIDEyMCA0NSA4OCA3NiA5OSA3OCA4MSA2NSA3 NCA3OCA5NyA0OSA0NSA1NCA2NyA3MyA4NSA0OSA1MCA4NyAxMDYgNTEgMTA5IDgwIDY5IDEyMCAx MjAgMTE5IDU3IDExOCA5OCAxMTAgMTE1IDgxIDY4IDg1IDU1IDY2IDUyIDY2IDEwMiAxMDkgMTA0 IDEwMCAxMjEgMTA1IDEwMiAxMDggNzYgNjUgNTUgNjUgMTAxIDUzIDkwIDcxIDExMSA4NiA4MiAx MDggNTEgNjUgOTUgOTUgMTIxIDc2IDgwIDg4IDEyMCA4MiAxMDYgNzIgNzAgMTA0IDExMiA3OSAx MDEgNjggMTEyIDk1IDk3IDEwMCAxMjAgNTYgNzggMTIxIDEwMSAxMDYgNzAgNTMgOTkgMTIyIDU3 IDEyMSA2OCA3NSA4NSA3NiAxMTcgMTAzIDc4IDExNSA2OCA3NyAxMDAgMTA4IDcyIDEwMSA3NCA4 MSA3OSA3NyA3MSA4NiA3NiA4OSA5NyA4MyA5MCAxMTYgNTEgNzUgODAgNTQgOTcgODcgNzggODMg MTEzIDcwIDY1IDQ5IDgwIDcyIDY4IDEwMyA0NSA0OSA0OCA5OSAxMDEgMTE3IDg0IDY5IDExNiAx MTMgOTUgMTE4IDgwIDY5IDUyIDQ1IDcxIDExNiAxMDEgMTE4IDUyIDc4IDUyIDc1IDUyIDY5IDEx NyAxMDAgMTA4IDEwNiA1MiA4MSA0NiA2NSAxMjAgODkgNTYgNjggNjcgMTE2IDY4IDk3IDcxIDEw OCAxMTUgOTggNzEgMTA4IDEwNiA5OCA1MSA4MiAxMTEgOTAgODEgNDYgODIgMTIwIDExNSAxMDYg MTAzIDU0IDgwIDczIDY5IDEyMCA5OSAxMDkgNzEgODMgNzAgNTUgNzYgMTEwIDgzIDY5IDEwNyA2 OCAxMTMgODcgNzMgNzUgMTAyIDY1IDExOSA0OSAxMTkgOTAgMTIyIDUwIDg4IDExMiA5NyA5OCA4 NiA1MyA4MCAxMTkgODEgMTE1IDExMSAxMDggNzUgMTE5IDY5IDk3IDExNyA4NyA4OSA5MCA3OCA2 OSA1NyA4MSA0OSAxMDQgOTAgNzQgNjkgOTAgNDYgNTYgNzYgODggMTEzIDc3IDEwMCA0OCA3NCA3 NiA3MSAxMTUgMTIwIDc3IDk3IDY2IDUzIDExNyAxMTEgNzggOTcgNzcgMTEyIDEwMyA1NSAxMTcg ODUgODcgOTUgMTEyIDUyIDQ4IDgyIDEwOCA5NyA5MCA3MiA2NyAxMTkgNzcgNzMgMTIxIDEyMiAx MDcgMSAwIDAgMjU1IDI1NQ0KDQoNCg0KQ2FuIHlvdSBkZWNvbXByZXNzIG15IG91dHB1dCBhbmQg b2J0YWluIHRoZSBvcmlnaW5hbCB0ZXh0PyAgQ2FuIHlvdSBzZW5kIG1lIHlvdXIgY29tcHJlc3Np b24gb3V0cHV0PyAgSeKAmWxsIHRoZW4gdHJ5IHRvIHVuY29tcHJlc3MgaXQuDQoNCg0KDQpUaGFu a3MgZm9yIGRvdWJsZS1jaGVja2luZyB0aGlzIQ0K --_000_255B9BB34FB7D647A506DC292726F6E115041F6786WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5N c29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9 RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk1pa2UsPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+WW91ciBERUZBTFRFIG91dHB1dCBpcyBub3QgZG9pbmcgYW55 IGNvbXByZXNzaW9uLiBJdCBpcyB0aGUgb3JpZ2luYWwgSldFIGNvbnRlbnQgd2l0aCBhIDUtYnl0 ZSBwcmVmaXggKDAwIDBFIDAyIEYxIEZEKSBhbmQgNS1ieXRlIHN1ZmZpeCAoMDEgMDAgMDAgRkYg RkYpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPlRoZSBmaXJzdCBieXRlIDAwIG1lYW5zIE5PIENPTVBSRVNTSU9OIGFu ZCBOT1QgVEhFIExBU1QgQkxPQ0s7IDBFIDAyIGlzIHRoZSBsZW5ndGggKDB4MjBFID0gNTI2KTsg RjEgRkQgaXMgdGhlIGludmVyc2Ugb2YgMEUgMDIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SW4gdGhlIGxhc3QgNSBi eXRlcywgMDEgbWVhbiBOTyBDT01QUkVTU0lPTiBhbmQgTEFTVCBCTE9DSzsgdGhlIGxlbmd0aCBv ZiB0aGlzIGJsb2NrIGlzIDAuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UGVyaGFwcyB5 b3VyIGNvbXByZXNzaW9uIGxpYnJhcnkgZG9lc27igJl0IGJvdGhlciB0byB0cnkgdG8gY29tcHJl c3MgaWYgdGhlIGNvbnRlbnQgaXMgZmFpcmx5IHNob3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2Pjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1pa2UgSm9uZXMgW21h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNk YXksIDIwIERlY2VtYmVyIDIwMTIgMTA6NTQgQU08YnI+PGI+VG86PC9iPiBNYW5nZXIsIEphbWVz IEg7IGpvc2VAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBSZWR1Y2luZyB0aGUgc2l6 ZSBvZiBKV1MgcGF5bG9hZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBsYW5nPUVOLVVTPkhpIEphbWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+SG1tbSAtIG15IHF1aWNrLWFu ZC1kaXJ0eSB0ZXN0IGNvZGUgdXNlZCB0aGUgLk5FVCA8YSBocmVmPSJodHRwOi8vbXNkbi5taWNy b3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvc3lzdGVtLmlvLmNvbXByZXNzaW9uLmRlZmxhdGVzdHJl YW0odj1WUy45MCkuYXNweCI+U3lzdGVtLklPLkNvbXByZXNzaW9uLkRlZmxhdGVTdHJlYW08L2E+ IGNsYXNzIGFuZCBDb21wcmVzc2lvbk1vZGUuQ29tcHJlc3MgdG8gZG8gdGhlIGNvbXByZXNzaW9u LiZuYnNwOyBUaGUgZG9jdW1lbnRhdGlvbiBzYXlzIHRoYXQgaXQgaW1wbGVtZW50cyBSRkMgMTk1 MSBERUZMQVRFLiZuYnNwOyBUaGF0IGJlaW5nIHNhaWQsIEkga25vdyB0aGF0IG9uZSBjYW4gdXNl IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHNhbWUgY29tcHJlc3Npb24gYWxnb3Jp dGhtIGFuZCBnZXQgZGlmZmVyZW50IHJlc3VsdHMsIGRlcGVuZGluZyB1cG9uIHRoZSBtYXRjaGVz IGFuZCBzdWJzdGl0dXRpb25zIHVzZWQg4oCTIGFsbCBvZiB3aGljaCB3aWxsIHVuY29tcHJlc3Mg dG8gdGhlIG9yaWdpbmFsIHZhbHVlLiZuYnNwOyBEbyB5b3Ugd2FudCB0byBzd2FwIGRhdGEgdG8g Y29uZmlybSB0aGF0IHdl4oCZcmUgdXNpbmcgdGhlIHNhbWUgY29tcHJlc3Npb24gZm9ybWF0Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVM+SSBjb21wcmVzc2VkIHRoZXNlIGJ5dGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz4xMDEgMTIxIDc0IDEwNCA5 OCA3MSA5OSAxMDUgNzkgMTA1IDc0IDgzIDg1IDQ4IDY5IDEyMCA4OCAxMjIgODUgMTA1IDc2IDY3 IDc0IDEwOCA5OCAxMDkgNzcgMTA1IDc5IDEwNSA3NCA2NiA3NyA4NCA3MyA1MiA4MSA0OCA3NCA2 OCA3NSA0OCAxMDQgODQgNzcgMTA2IDg1IDUwIDczIDExMCA0OCA0NiA5MCAxMDkgMTEwIDEwOCAx MTMgODcgMTAzIDEwNiA4OCAxMjEgMTEzIDExOSAxMDYgMTE0IDU1IDk5IDg4IDcyIDEyMSAxMTUg NTYgNzAgNTUgNTcgOTcgMTEwIDczIDg1IDczIDU0IDc0IDUwIDg1IDg3IDEwMCA2NSAxMjEgODIg ODEgNjkgOTkgNzEgNjYgODUgNDUgNzUgODAgNzIgMTE1IDEwMSA4MCA3NyA1NyA0OSA0OCA5NSA4 MiAxMTEgODQgNjggNzEgMTE3IDQ5IDczIDg3IDUyIDQ4IDY4IDExMCA0OCAxMDAgMTE4IDk5IDEw MCA4NiA2OSAxMDYgMTEyIDc0IDk5IDgwIDgwIDc4IDczIDk4IDEyMiA4NyA5OSA3NyAxMjAgNjgg MTA1IDQ5IDUxIDQ5IDY5IDEwNiAxMDEgMTAzIDQ1IDk4IDU2IDg2IDEwNSA4NyA1MyA4OSA4OCA1 MyAxMTEgODIgMTAwIDg5IDEwMCAxMDUgODIgNTIgMTAzIDc3IDgzIDY4IDY4IDY2IDUxIDEwOSA5 OCAxMDcgNzMgMTEwIDc3IDc4IDg1IDcwIDg0IDQ1IDgwIDc1IDUzIDY3IDExNyA5MCA4MiAxMTAg NzIgNjYgNTAgMTE0IDg1IDc1IDUzIDEwMiAxMDQgODAgMTE3IDcwIDU0IDg4IDcwIDExMyA3NiA3 NiA5MCA2NyA3MSA1MyA4MSA5NSAxMTQgNzQgMTA5IDU0IDY5IDExOCAxMDEgMTIwIDQ1IDg4IDc2 IDk5IDc4IDgxIDY1IDc0IDc4IDk3IDQ5IDQ1IDU0IDY3IDczIDg1IDQ5IDUwIDg3IDEwNiA1MSAx MDkgODAgNjkgMTIwIDEyMCAxMTkgNTcgMTE4IDk4IDExMCAxMTUgODEgNjggODUgNTUgNjYgNTIg NjYgMTAyIDEwOSAxMDQgMTAwIDEyMSAxMDUgMTAyIDEwOCA3NiA2NSA1NSA2NSAxMDEgNTMgOTAg NzEgMTExIDg2IDgyIDEwOCA1MSA2NSA5NSA5NSAxMjEgNzYgODAgODggMTIwIDgyIDEwNiA3MiA3 MCAxMDQgMTEyIDc5IDEwMSA2OCAxMTIgOTUgOTcgMTAwIDEyMCA1NiA3OCAxMjEgMTAxIDEwNiA3 MCA1MyA5OSAxMjIgNTcgMTIxIDY4IDc1IDg1IDc2IDExNyAxMDMgNzggMTE1IDY4IDc3IDEwMCAx MDggNzIgMTAxIDc0IDgxIDc5IDc3IDcxIDg2IDc2IDg5IDk3IDgzIDkwIDExNiA1MSA3NSA4MCA1 NCA5NyA4NyA3OCA4MyAxMTMgNzAgNjUgNDkgODAgNzIgNjggMTAzIDQ1IDQ5IDQ4IDk5IDEwMSAx MTcgODQgNjkgMTE2IDExMyA5NSAxMTggODAgNjkgNTIgNDUgNzEgMTE2IDEwMSAxMTggNTIgNzgg NTIgNzUgNTIgNjkgMTE3IDEwMCAxMDggMTA2IDUyIDgxIDQ2IDY1IDEyMCA4OSA1NiA2OCA2NyAx MTYgNjggOTcgNzEgMTA4IDExNSA5OCA3MSAxMDggMTA2IDk4IDUxIDgyIDExMSA5MCA4MSA0NiA4 MiAxMjAgMTE1IDEwNiAxMDMgNTQgODAgNzMgNjkgMTIwIDk5IDEwOSA3MSA4MyA3MCA1NSA3NiAx MTAgODMgNjkgMTA3IDY4IDExMyA4NyA3MyA3NSAxMDIgNjUgMTE5IDQ5IDExOSA5MCAxMjIgNTAg ODggMTEyIDk3IDk4IDg2IDUzIDgwIDExOSA4MSAxMTUgMTExIDEwOCA3NSAxMTkgNjkgOTcgMTE3 IDg3IDg5IDkwIDc4IDY5IDU3IDgxIDQ5IDEwNCA5MCA3NCA2OSA5MCA0NiA1NiA3NiA4OCAxMTMg NzcgMTAwIDQ4IDc0IDc2IDcxIDExNSAxMjAgNzcgOTcgNjYgNTMgMTE3IDExMSA3OCA5NyA3NyAx MTIgMTAzIDU1IDExNyA4NSA4NyA5NSAxMTIgNTIgNDggODIgMTA4IDk3IDkwIDcyIDY3IDExOSA3 NyA3MyAxMjEgMTIyIDEwNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+YW5kIG9idGFpbmVkIHRoaXMgb3V0cHV0Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V Uz4wIDE0IDIgMjQxIDI1MyAxMDEgMTIxIDc0IDEwNCA5OCA3MSA5OSAxMDUgNzkgMTA1IDc0IDgz IDg1IDQ4IDY5IDEyMCA4OCAxMjIgODUgMTA1IDc2IDY3IDc0IDEwOCA5OCAxMDkgNzcgMTA1IDc5 IDEwNSA3NCA2NiA3NyA4NCA3MyA1MiA4MSA0OCA3NCA2OCA3NSA0OCAxMDQgODQgNzcgMTA2IDg1 IDUwIDczIDExMCA0OCA0NiA5MCAxMDkgMTEwIDEwOCAxMTMgODcgMTAzIDEwNiA4OCAxMjEgMTEz IDExOSAxMDYgMTE0IDU1IDk5IDg4IDcyIDEyMSAxMTUgNTYgNzAgNTUgNTcgOTcgMTEwIDczIDg1 IDczIDU0IDc0IDUwIDg1IDg3IDEwMCA2NSAxMjEgODIgODEgNjkgOTkgNzEgNjYgODUgNDUgNzUg ODAgNzIgMTE1IDEwMSA4MCA3NyA1NyA0OSA0OCA5NSA4MiAxMTEgODQgNjggNzEgMTE3IDQ5IDcz IDg3IDUyIDQ4IDY4IDExMCA0OCAxMDAgMTE4IDk5IDEwMCA4NiA2OSAxMDYgMTEyIDc0IDk5IDgw IDgwIDc4IDczIDk4IDEyMiA4NyA5OSA3NyAxMjAgNjggMTA1IDQ5IDUxIDQ5IDY5IDEwNiAxMDEg MTAzIDQ1IDk4IDU2IDg2IDEwNSA4NyA1MyA4OSA4OCA1MyAxMTEgODIgMTAwIDg5IDEwMCAxMDUg ODIgNTIgMTAzIDc3IDgzIDY4IDY4IDY2IDUxIDEwOSA5OCAxMDcgNzMgMTEwIDc3IDc4IDg1IDcw IDg0IDQ1IDgwIDc1IDUzIDY3IDExNyA5MCA4MiAxMTAgNzIgNjYgNTAgMTE0IDg1IDc1IDUzIDEw MiAxMDQgODAgMTE3IDcwIDU0IDg4IDcwIDExMyA3NiA3NiA5MCA2NyA3MSA1MyA4MSA5NSAxMTQg NzQgMTA5IDU0IDY5IDExOCAxMDEgMTIwIDQ1IDg4IDc2IDk5IDc4IDgxIDY1IDc0IDc4IDk3IDQ5 IDQ1IDU0IDY3IDczIDg1IDQ5IDUwIDg3IDEwNiA1MSAxMDkgODAgNjkgMTIwIDEyMCAxMTkgNTcg MTE4IDk4IDExMCAxMTUgODEgNjggODUgNTUgNjYgNTIgNjYgMTAyIDEwOSAxMDQgMTAwIDEyMSAx MDUgMTAyIDEwOCA3NiA2NSA1NSA2NSAxMDEgNTMgOTAgNzEgMTExIDg2IDgyIDEwOCA1MSA2NSA5 NSA5NSAxMjEgNzYgODAgODggMTIwIDgyIDEwNiA3MiA3MCAxMDQgMTEyIDc5IDEwMSA2OCAxMTIg OTUgOTcgMTAwIDEyMCA1NiA3OCAxMjEgMTAxIDEwNiA3MCA1MyA5OSAxMjIgNTcgMTIxIDY4IDc1 IDg1IDc2IDExNyAxMDMgNzggMTE1IDY4IDc3IDEwMCAxMDggNzIgMTAxIDc0IDgxIDc5IDc3IDcx IDg2IDc2IDg5IDk3IDgzIDkwIDExNiA1MSA3NSA4MCA1NCA5NyA4NyA3OCA4MyAxMTMgNzAgNjUg NDkgODAgNzIgNjggMTAzIDQ1IDQ5IDQ4IDk5IDEwMSAxMTcgODQgNjkgMTE2IDExMyA5NSAxMTgg ODAgNjkgNTIgNDUgNzEgMTE2IDEwMSAxMTggNTIgNzggNTIgNzUgNTIgNjkgMTE3IDEwMCAxMDgg MTA2IDUyIDgxIDQ2IDY1IDEyMCA4OSA1NiA2OCA2NyAxMTYgNjggOTcgNzEgMTA4IDExNSA5OCA3 MSAxMDggMTA2IDk4IDUxIDgyIDExMSA5MCA4MSA0NiA4MiAxMjAgMTE1IDEwNiAxMDMgNTQgODAg NzMgNjkgMTIwIDk5IDEwOSA3MSA4MyA3MCA1NSA3NiAxMTAgODMgNjkgMTA3IDY4IDExMyA4NyA3 MyA3NSAxMDIgNjUgMTE5IDQ5IDExOSA5MCAxMjIgNTAgODggMTEyIDk3IDk4IDg2IDUzIDgwIDEx OSA4MSAxMTUgMTExIDEwOCA3NSAxMTkgNjkgOTcgMTE3IDg3IDg5IDkwIDc4IDY5IDU3IDgxIDQ5 IDEwNCA5MCA3NCA2OSA5MCA0NiA1NiA3NiA4OCAxMTMgNzcgMTAwIDQ4IDc0IDc2IDcxIDExNSAx MjAgNzcgOTcgNjYgNTMgMTE3IDExMSA3OCA5NyA3NyAxMTIgMTAzIDU1IDExNyA4NSA4NyA5NSAx MTIgNTIgNDggODIgMTA4IDk3IDkwIDcyIDY3IDExOSA3NyA3MyAxMjEgMTIyIDEwNyAxIDAgMCAy NTUgMjU1PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gbGFuZz1FTi1VUz5DYW4geW91IGRlY29tcHJlc3MgbXkgb3V0cHV0IGFuZCBvYnRh aW4gdGhlIG9yaWdpbmFsIHRleHQ/Jm5ic3A7IENhbiB5b3Ugc2VuZCBtZSB5b3VyIGNvbXByZXNz aW9uIG91dHB1dD8gJm5ic3A7SeKAmWxsIHRoZW4gdHJ5IHRvIHVuY29tcHJlc3MgaXQuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFu Zz1FTi1VUz5UaGFua3MgZm9yIGRvdWJsZS1jaGVja2luZyB0aGlzITxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E115041F6786WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Wed Dec 19 16:56:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467CC21F84D0 for ; Wed, 19 Dec 2012 16:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07hRRNZLRCZr for ; Wed, 19 Dec 2012 16:56:46 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id C56B721F8831 for ; Wed, 19 Dec 2012 16:56:45 -0800 (PST) Received: from BL2FFO11FD003.protection.gbl (10.173.161.203) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 00:56:42 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 00:56:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 00:56:37 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgArYb9QAAEkkLAAAb5OYAAApjQQ Date: Thu, 20 Dec 2012 00:56:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436697A5D4@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F65F9@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977C74@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F6786@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115041F6786@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_4E1F6AAD24975D4BA5B16804296739436697A5D4TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(60454001)(377454001)(69234002)(52314002)(15202345001)(74502001)(47446002)(46102001)(54316002)(16236675001)(56776001)(5343635001)(5343655001)(51856001)(33656001)(512874001)(55846006)(44976002)(74662001)(31966008)(47976001)(47736001)(16406001)(4396001)(50986001)(49866001)(54356001)(59766001)(56816002)(77982001)(53806001)(76482001)(383094001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07013D7479 Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 00:56:47 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436697A5D4TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNCkkgc3VzcGVjdCBpdOKAmXMgYWN0dWFsbHkgYSBmYWxsYmFjayB0byBlbWl0 IHRoZSBvcmlnaW5hbCBpZiB0aGUgdGVudGF0aXZlIGNvbXByZXNzZWQgZm9ybSBlbmRzIHVwIGJl aW5nIGxvbmdlciB0aGFuIHRoZSBvcmlnaW5hbC4gIEZZSSwgSSB3YXMgYWJsZSB0byBkZWZsYXRl IHRoZSA0MjcgY29tcHJlc3NlZCBieXRlcyB5b3Ugc2VudCBtZSBwcml2YXRlbHkgdG8gb2J0YWlu IHRoZSBvcmlnaW5hbCwgc28gSeKAmW0gdXNpbmcgdGhlIHNhbWUgYWxnb3JpdGhtIGFzIHlvdS4g IEl0IGp1c3Qgc2VlbXMgdGhhdCB0aGUgY29tcHJlc3Npb24gaW1wbGVtZW50YXRpb24gSSB1c2Vk IGlzbuKAmXQgZG9pbmcgYXMgZ29vZCBhIGpvYiBhcyB5b3VycyBhdCBmaW5kaW5nIGV4cGxvaXRh YmxlIHJlZHVuZGFuY3kgZHVyaW5nIHRoZSBjb21wcmVzc2lvbiBwcm9jZXNzLg0KDQpBbnl3YXks IGFzIHdlIGFsc28gYWdyZWVkIGluIG91ciBwcml2YXRlIHRocmVhZCwgdGhlc2UgbnVtYmVycyBw cm9iYWJseSBhcmVu4oCZdCBoaWdobHkgcmVsZXZhbnQsIGZvciB0aGUgcmVhc29ucyBKb2huIGFu ZCB5b3UgY2l0ZWQg4oCTIHRoYXQgYW4gYXN5bW1ldHJpYyBzaWduYXR1cmUgaXMgbW9yZSBsaWtl bHkgdG8gYmUgYXBwbGllZCBiZWZvcmUgdGhlIGVuY3J5cHRpb24uICBUaGV5IHdvdWxkIGxpa2Vs eSBvbmx5IGJlY29tZSByZWxldmFudCBpZiBmb3Igc29tZSByZWFzb24gcGVvcGxlIHdhbnRlZCB0 byBkbyBTaWduLUVuY3J5cHQtU2lnbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWFuZ2Vy LCBKYW1lcyBIIFttYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgRGVjZW1iZXIgMTksIDIwMTIgNDozOSBQTQ0KVG86IE1pa2UgSm9uZXM7IGpv c2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBSZWR1Y2luZyB0aGUgc2l6ZSBvZiBKV1MgcGF5bG9h ZHMNCg0KTWlrZSwNCg0KWW91ciBERUZBTFRFIG91dHB1dCBpcyBub3QgZG9pbmcgYW55IGNvbXBy ZXNzaW9uLiBJdCBpcyB0aGUgb3JpZ2luYWwgSldFIGNvbnRlbnQgd2l0aCBhIDUtYnl0ZSBwcmVm aXggKDAwIDBFIDAyIEYxIEZEKSBhbmQgNS1ieXRlIHN1ZmZpeCAoMDEgMDAgMDAgRkYgRkYpLg0K VGhlIGZpcnN0IGJ5dGUgMDAgbWVhbnMgTk8gQ09NUFJFU1NJT04gYW5kIE5PVCBUSEUgTEFTVCBC TE9DSzsgMEUgMDIgaXMgdGhlIGxlbmd0aCAoMHgyMEUgPSA1MjYpOyBGMSBGRCBpcyB0aGUgaW52 ZXJzZSBvZiAwRSAwMi4NCkluIHRoZSBsYXN0IDUgYnl0ZXMsIDAxIG1lYW4gTk8gQ09NUFJFU1NJ T04gYW5kIExBU1QgQkxPQ0s7IHRoZSBsZW5ndGggb2YgdGhpcyBibG9jayBpcyAwLg0KDQpQZXJo YXBzIHlvdXIgY29tcHJlc3Npb24gbGlicmFyeSBkb2VzbuKAmXQgYm90aGVyIHRvIHRyeSB0byBj b21wcmVzcyBpZiB0aGUgY29udGVudCBpcyBmYWlybHkgc2hvcnQuDQoNCi0tDQpKYW1lcyBNYW5n ZXINCg0KRnJvbTogTWlrZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bV0NClNlbnQ6IFRodXJzZGF5LCAyMCBEZWNlbWJlciAyMDEyIDEwOjU0IEFNDQpUbzogTWFuZ2Vy LCBKYW1lcyBIOyBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFJlZHVjaW5nIHRoZSBzaXplIG9mIEpXUyBwYXlsb2Fkcw0KDQoNCkhpIEphbWVzLA0KDQoN Cg0KSG1tbSAtIG15IHF1aWNrLWFuZC1kaXJ0eSB0ZXN0IGNvZGUgdXNlZCB0aGUgLk5FVCBTeXN0 ZW0uSU8uQ29tcHJlc3Npb24uRGVmbGF0ZVN0cmVhbTxodHRwOi8vbXNkbi5taWNyb3NvZnQuY29t L2VuLXVzL2xpYnJhcnkvc3lzdGVtLmlvLmNvbXByZXNzaW9uLmRlZmxhdGVzdHJlYW0odj1WUy45 MCkuYXNweD4gY2xhc3MgYW5kIENvbXByZXNzaW9uTW9kZS5Db21wcmVzcyB0byBkbyB0aGUgY29t cHJlc3Npb24uICBUaGUgZG9jdW1lbnRhdGlvbiBzYXlzIHRoYXQgaXQgaW1wbGVtZW50cyBSRkMg MTk1MSBERUZMQVRFLiAgVGhhdCBiZWluZyBzYWlkLCBJIGtub3cgdGhhdCBvbmUgY2FuIHVzZSBk aWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBzYW1lIGNvbXByZXNzaW9uIGFsZ29yaXRo bSBhbmQgZ2V0IGRpZmZlcmVudCByZXN1bHRzLCBkZXBlbmRpbmcgdXBvbiB0aGUgbWF0Y2hlcyBh bmQgc3Vic3RpdHV0aW9ucyB1c2VkIOKAkyBhbGwgb2Ygd2hpY2ggd2lsbCB1bmNvbXByZXNzIHRv IHRoZSBvcmlnaW5hbCB2YWx1ZS4gIERvIHlvdSB3YW50IHRvIHN3YXAgZGF0YSB0byBjb25maXJt IHRoYXQgd2XigJlyZSB1c2luZyB0aGUgc2FtZSBjb21wcmVzc2lvbiBmb3JtYXQ/DQoNCg0KDQpJ IGNvbXByZXNzZWQgdGhlc2UgYnl0ZXM6DQoNCjEwMSAxMjEgNzQgMTA0IDk4IDcxIDk5IDEwNSA3 OSAxMDUgNzQgODMgODUgNDggNjkgMTIwIDg4IDEyMiA4NSAxMDUgNzYgNjcgNzQgMTA4IDk4IDEw OSA3NyAxMDUgNzkgMTA1IDc0IDY2IDc3IDg0IDczIDUyIDgxIDQ4IDc0IDY4IDc1IDQ4IDEwNCA4 NCA3NyAxMDYgODUgNTAgNzMgMTEwIDQ4IDQ2IDkwIDEwOSAxMTAgMTA4IDExMyA4NyAxMDMgMTA2 IDg4IDEyMSAxMTMgMTE5IDEwNiAxMTQgNTUgOTkgODggNzIgMTIxIDExNSA1NiA3MCA1NSA1NyA5 NyAxMTAgNzMgODUgNzMgNTQgNzQgNTAgODUgODcgMTAwIDY1IDEyMSA4MiA4MSA2OSA5OSA3MSA2 NiA4NSA0NSA3NSA4MCA3MiAxMTUgMTAxIDgwIDc3IDU3IDQ5IDQ4IDk1IDgyIDExMSA4NCA2OCA3 MSAxMTcgNDkgNzMgODcgNTIgNDggNjggMTEwIDQ4IDEwMCAxMTggOTkgMTAwIDg2IDY5IDEwNiAx MTIgNzQgOTkgODAgODAgNzggNzMgOTggMTIyIDg3IDk5IDc3IDEyMCA2OCAxMDUgNDkgNTEgNDkg NjkgMTA2IDEwMSAxMDMgNDUgOTggNTYgODYgMTA1IDg3IDUzIDg5IDg4IDUzIDExMSA4MiAxMDAg ODkgMTAwIDEwNSA4MiA1MiAxMDMgNzcgODMgNjggNjggNjYgNTEgMTA5IDk4IDEwNyA3MyAxMTAg NzcgNzggODUgNzAgODQgNDUgODAgNzUgNTMgNjcgMTE3IDkwIDgyIDExMCA3MiA2NiA1MCAxMTQg ODUgNzUgNTMgMTAyIDEwNCA4MCAxMTcgNzAgNTQgODggNzAgMTEzIDc2IDc2IDkwIDY3IDcxIDUz IDgxIDk1IDExNCA3NCAxMDkgNTQgNjkgMTE4IDEwMSAxMjAgNDUgODggNzYgOTkgNzggODEgNjUg NzQgNzggOTcgNDkgNDUgNTQgNjcgNzMgODUgNDkgNTAgODcgMTA2IDUxIDEwOSA4MCA2OSAxMjAg MTIwIDExOSA1NyAxMTggOTggMTEwIDExNSA4MSA2OCA4NSA1NSA2NiA1MiA2NiAxMDIgMTA5IDEw NCAxMDAgMTIxIDEwNSAxMDIgMTA4IDc2IDY1IDU1IDY1IDEwMSA1MyA5MCA3MSAxMTEgODYgODIg MTA4IDUxIDY1IDk1IDk1IDEyMSA3NiA4MCA4OCAxMjAgODIgMTA2IDcyIDcwIDEwNCAxMTIgNzkg MTAxIDY4IDExMiA5NSA5NyAxMDAgMTIwIDU2IDc4IDEyMSAxMDEgMTA2IDcwIDUzIDk5IDEyMiA1 NyAxMjEgNjggNzUgODUgNzYgMTE3IDEwMyA3OCAxMTUgNjggNzcgMTAwIDEwOCA3MiAxMDEgNzQg ODEgNzkgNzcgNzEgODYgNzYgODkgOTcgODMgOTAgMTE2IDUxIDc1IDgwIDU0IDk3IDg3IDc4IDgz IDExMyA3MCA2NSA0OSA4MCA3MiA2OCAxMDMgNDUgNDkgNDggOTkgMTAxIDExNyA4NCA2OSAxMTYg MTEzIDk1IDExOCA4MCA2OSA1MiA0NSA3MSAxMTYgMTAxIDExOCA1MiA3OCA1MiA3NSA1MiA2OSAx MTcgMTAwIDEwOCAxMDYgNTIgODEgNDYgNjUgMTIwIDg5IDU2IDY4IDY3IDExNiA2OCA5NyA3MSAx MDggMTE1IDk4IDcxIDEwOCAxMDYgOTggNTEgODIgMTExIDkwIDgxIDQ2IDgyIDEyMCAxMTUgMTA2 IDEwMyA1NCA4MCA3MyA2OSAxMjAgOTkgMTA5IDcxIDgzIDcwIDU1IDc2IDExMCA4MyA2OSAxMDcg NjggMTEzIDg3IDczIDc1IDEwMiA2NSAxMTkgNDkgMTE5IDkwIDEyMiA1MCA4OCAxMTIgOTcgOTgg ODYgNTMgODAgMTE5IDgxIDExNSAxMTEgMTA4IDc1IDExOSA2OSA5NyAxMTcgODcgODkgOTAgNzgg NjkgNTcgODEgNDkgMTA0IDkwIDc0IDY5IDkwIDQ2IDU2IDc2IDg4IDExMyA3NyAxMDAgNDggNzQg NzYgNzEgMTE1IDEyMCA3NyA5NyA2NiA1MyAxMTcgMTExIDc4IDk3IDc3IDExMiAxMDMgNTUgMTE3 IDg1IDg3IDk1IDExMiA1MiA0OCA4MiAxMDggOTcgOTAgNzIgNjcgMTE5IDc3IDczIDEyMSAxMjIg MTA3DQoNCg0KDQphbmQgb2J0YWluZWQgdGhpcyBvdXRwdXQ6DQoNCjAgMTQgMiAyNDEgMjUzIDEw MSAxMjEgNzQgMTA0IDk4IDcxIDk5IDEwNSA3OSAxMDUgNzQgODMgODUgNDggNjkgMTIwIDg4IDEy MiA4NSAxMDUgNzYgNjcgNzQgMTA4IDk4IDEwOSA3NyAxMDUgNzkgMTA1IDc0IDY2IDc3IDg0IDcz IDUyIDgxIDQ4IDc0IDY4IDc1IDQ4IDEwNCA4NCA3NyAxMDYgODUgNTAgNzMgMTEwIDQ4IDQ2IDkw IDEwOSAxMTAgMTA4IDExMyA4NyAxMDMgMTA2IDg4IDEyMSAxMTMgMTE5IDEwNiAxMTQgNTUgOTkg ODggNzIgMTIxIDExNSA1NiA3MCA1NSA1NyA5NyAxMTAgNzMgODUgNzMgNTQgNzQgNTAgODUgODcg MTAwIDY1IDEyMSA4MiA4MSA2OSA5OSA3MSA2NiA4NSA0NSA3NSA4MCA3MiAxMTUgMTAxIDgwIDc3 IDU3IDQ5IDQ4IDk1IDgyIDExMSA4NCA2OCA3MSAxMTcgNDkgNzMgODcgNTIgNDggNjggMTEwIDQ4 IDEwMCAxMTggOTkgMTAwIDg2IDY5IDEwNiAxMTIgNzQgOTkgODAgODAgNzggNzMgOTggMTIyIDg3 IDk5IDc3IDEyMCA2OCAxMDUgNDkgNTEgNDkgNjkgMTA2IDEwMSAxMDMgNDUgOTggNTYgODYgMTA1 IDg3IDUzIDg5IDg4IDUzIDExMSA4MiAxMDAgODkgMTAwIDEwNSA4MiA1MiAxMDMgNzcgODMgNjgg NjggNjYgNTEgMTA5IDk4IDEwNyA3MyAxMTAgNzcgNzggODUgNzAgODQgNDUgODAgNzUgNTMgNjcg MTE3IDkwIDgyIDExMCA3MiA2NiA1MCAxMTQgODUgNzUgNTMgMTAyIDEwNCA4MCAxMTcgNzAgNTQg ODggNzAgMTEzIDc2IDc2IDkwIDY3IDcxIDUzIDgxIDk1IDExNCA3NCAxMDkgNTQgNjkgMTE4IDEw MSAxMjAgNDUgODggNzYgOTkgNzggODEgNjUgNzQgNzggOTcgNDkgNDUgNTQgNjcgNzMgODUgNDkg NTAgODcgMTA2IDUxIDEwOSA4MCA2OSAxMjAgMTIwIDExOSA1NyAxMTggOTggMTEwIDExNSA4MSA2 OCA4NSA1NSA2NiA1MiA2NiAxMDIgMTA5IDEwNCAxMDAgMTIxIDEwNSAxMDIgMTA4IDc2IDY1IDU1 IDY1IDEwMSA1MyA5MCA3MSAxMTEgODYgODIgMTA4IDUxIDY1IDk1IDk1IDEyMSA3NiA4MCA4OCAx MjAgODIgMTA2IDcyIDcwIDEwNCAxMTIgNzkgMTAxIDY4IDExMiA5NSA5NyAxMDAgMTIwIDU2IDc4 IDEyMSAxMDEgMTA2IDcwIDUzIDk5IDEyMiA1NyAxMjEgNjggNzUgODUgNzYgMTE3IDEwMyA3OCAx MTUgNjggNzcgMTAwIDEwOCA3MiAxMDEgNzQgODEgNzkgNzcgNzEgODYgNzYgODkgOTcgODMgOTAg MTE2IDUxIDc1IDgwIDU0IDk3IDg3IDc4IDgzIDExMyA3MCA2NSA0OSA4MCA3MiA2OCAxMDMgNDUg NDkgNDggOTkgMTAxIDExNyA4NCA2OSAxMTYgMTEzIDk1IDExOCA4MCA2OSA1MiA0NSA3MSAxMTYg MTAxIDExOCA1MiA3OCA1MiA3NSA1MiA2OSAxMTcgMTAwIDEwOCAxMDYgNTIgODEgNDYgNjUgMTIw IDg5IDU2IDY4IDY3IDExNiA2OCA5NyA3MSAxMDggMTE1IDk4IDcxIDEwOCAxMDYgOTggNTEgODIg MTExIDkwIDgxIDQ2IDgyIDEyMCAxMTUgMTA2IDEwMyA1NCA4MCA3MyA2OSAxMjAgOTkgMTA5IDcx IDgzIDcwIDU1IDc2IDExMCA4MyA2OSAxMDcgNjggMTEzIDg3IDczIDc1IDEwMiA2NSAxMTkgNDkg MTE5IDkwIDEyMiA1MCA4OCAxMTIgOTcgOTggODYgNTMgODAgMTE5IDgxIDExNSAxMTEgMTA4IDc1 IDExOSA2OSA5NyAxMTcgODcgODkgOTAgNzggNjkgNTcgODEgNDkgMTA0IDkwIDc0IDY5IDkwIDQ2 IDU2IDc2IDg4IDExMyA3NyAxMDAgNDggNzQgNzYgNzEgMTE1IDEyMCA3NyA5NyA2NiA1MyAxMTcg MTExIDc4IDk3IDc3IDExMiAxMDMgNTUgMTE3IDg1IDg3IDk1IDExMiA1MiA0OCA4MiAxMDggOTcg OTAgNzIgNjcgMTE5IDc3IDczIDEyMSAxMjIgMTA3IDEgMCAwIDI1NSAyNTUNCg0KDQoNCkNhbiB5 b3UgZGVjb21wcmVzcyBteSBvdXRwdXQgYW5kIG9idGFpbiB0aGUgb3JpZ2luYWwgdGV4dD8gIENh biB5b3Ugc2VuZCBtZSB5b3VyIGNvbXByZXNzaW9uIG91dHB1dD8gIEnigJlsbCB0aGVuIHRyeSB0 byB1bmNvbXByZXNzIGl0Lg0KDQoNCg0KVGhhbmtzIGZvciBkb3VibGUtY2hlY2tpbmcgdGhpcyEN Cg== --_000_4E1F6AAD24975D4BA5B16804296739436697A5D4TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgSmFtZXMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIHN1c3BlY3QgaXTigJlzIGFjdHVhbGx5IGEgZmFs bGJhY2sgdG8gZW1pdCB0aGUgb3JpZ2luYWwgaWYgdGhlIHRlbnRhdGl2ZSBjb21wcmVzc2VkIGZv cm0gZW5kcyB1cCBiZWluZyBsb25nZXIgdGhhbiB0aGUgb3JpZ2luYWwuJm5ic3A7IEZZSSwgSSB3 YXMgYWJsZSB0byBkZWZsYXRlIHRoZSA0MjcgY29tcHJlc3NlZCBieXRlcyB5b3Ugc2VudCBtZSBw cml2YXRlbHkgdG8gb2J0YWluDQogdGhlIG9yaWdpbmFsLCBzbyBJ4oCZbSB1c2luZyB0aGUgc2Ft ZSBhbGdvcml0aG0gYXMgeW91LiZuYnNwOyBJdCBqdXN0IHNlZW1zIHRoYXQgdGhlIGNvbXByZXNz aW9uIGltcGxlbWVudGF0aW9uIEkgdXNlZCBpc27igJl0IGRvaW5nIGFzIGdvb2QgYSBqb2IgYXMg eW91cnMgYXQgZmluZGluZyBleHBsb2l0YWJsZSByZWR1bmRhbmN5IGR1cmluZyB0aGUgY29tcHJl c3Npb24gcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFueXdh eSwgYXMgd2UgYWxzbyBhZ3JlZWQgaW4gb3VyIHByaXZhdGUgdGhyZWFkLA0KPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj50aGVzZSBudW1iZXJzIHByb2JhYmx5IGFyZW7igJl0IGhp Z2hseSByZWxldmFudCwgZm9yIHRoZSByZWFzb25zIEpvaG4gYW5kIHlvdSBjaXRlZCDigJMgdGhh dCBhbiBhc3ltbWV0cmljIHNpZ25hdHVyZSBpcyBtb3JlIGxpa2VseSB0byBiZSBhcHBsaWVkIGJl Zm9yZSB0aGUgZW5jcnlwdGlvbi4mbmJzcDsgVGhleSB3b3VsZCBsaWtlbHkgb25seSBiZWNvbWUg cmVsZXZhbnQgaWYgZm9yIHNvbWUgcmVhc29uDQogcGVvcGxlIHdhbnRlZCB0byBkbyBTaWduLUVu Y3J5cHQtU2lnbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFuZ2VyLCBKYW1lcyBI IFttYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIERlY2VtYmVyIDE5LCAyMDEyIDQ6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+ IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFJlZHVj aW5nIHRoZSBzaXplIG9mIEpXUyBwYXlsb2FkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+TWlrZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+WW91ciBERUZBTFRFIG91dHB1dCBpcyBub3QgZG9pbmcgYW55IGNvbXBy ZXNzaW9uLiBJdCBpcyB0aGUgb3JpZ2luYWwgSldFIGNvbnRlbnQgd2l0aCBhIDUtYnl0ZSBwcmVm aXggKDAwIDBFIDAyIEYxIEZEKSBhbmQgNS1ieXRlIHN1ZmZpeCAoMDEgMDAgMDAgRkYgRkYpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGZpcnN0IGJ5dGUgMDAgbWVhbnMgTk8gQ09N UFJFU1NJT04gYW5kIE5PVCBUSEUgTEFTVCBCTE9DSzsgMEUgMDIgaXMgdGhlIGxlbmd0aCAoMHgy MEUgPSA1MjYpOyBGMSBGRCBpcyB0aGUgaW52ZXJzZSBvZiAwRSAwMi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkluIHRoZSBsYXN0IDUgYnl0ZXMsIDAxIG1lYW4gTk8gQ09NUFJFU1NJT04g YW5kIExBU1QgQkxPQ0s7IHRoZSBsZW5ndGggb2YgdGhpcyBibG9jayBpcyAwLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QZXJo YXBzIHlvdXIgY29tcHJlc3Npb24gbGlicmFyeSBkb2VzbuKAmXQgYm90aGVyIHRvIHRyeSB0byBj b21wcmVzcyBpZiB0aGUgY29udGVudCBpcyBmYWlybHkgc2hvcnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2UgSm9uZXMgWzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPm1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCAyMCBEZWNlbWJl ciAyMDEyIDEwOjU0IEFNPGJyPg0KPGI+VG86PC9iPiBNYW5nZXIsIEphbWVzIEg7IDxhIGhyZWY9 Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogUmVkdWNpbmcgdGhlIHNpemUgb2YgSldTIHBheWxvYWRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUFVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5IaSBKYW1lcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SG1tbSAtIG15IHF1 aWNrLWFuZC1kaXJ0eSB0ZXN0IGNvZGUgdXNlZCB0aGUgLk5FVCA8YSBocmVmPSJodHRwOi8vbXNk bi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvc3lzdGVtLmlvLmNvbXByZXNzaW9uLmRlZmxh dGVzdHJlYW0odj1WUy45MCkuYXNweCI+DQpTeXN0ZW0uSU8uQ29tcHJlc3Npb24uRGVmbGF0ZVN0 cmVhbTwvYT4gY2xhc3MgYW5kIENvbXByZXNzaW9uTW9kZS5Db21wcmVzcyB0byBkbyB0aGUgY29t cHJlc3Npb24uJm5ic3A7IFRoZSBkb2N1bWVudGF0aW9uIHNheXMgdGhhdCBpdCBpbXBsZW1lbnRz IFJGQyAxOTUxIERFRkxBVEUuJm5ic3A7IFRoYXQgYmVpbmcgc2FpZCwgSSBrbm93IHRoYXQgb25l IGNhbiB1c2UgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgc2FtZSBjb21wcmVzc2lv biBhbGdvcml0aG0NCiBhbmQgZ2V0IGRpZmZlcmVudCByZXN1bHRzLCBkZXBlbmRpbmcgdXBvbiB0 aGUgbWF0Y2hlcyBhbmQgc3Vic3RpdHV0aW9ucyB1c2VkIOKAkyBhbGwgb2Ygd2hpY2ggd2lsbCB1 bmNvbXByZXNzIHRvIHRoZSBvcmlnaW5hbCB2YWx1ZS4mbmJzcDsgRG8geW91IHdhbnQgdG8gc3dh cCBkYXRhIHRvIGNvbmZpcm0gdGhhdCB3ZeKAmXJlIHVzaW5nIHRoZSBzYW1lIGNvbXByZXNzaW9u IGZvcm1hdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBjb21wcmVzc2VkIHRoZXNl IGJ5dGVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MTAxIDEyMSA3 NCAxMDQgOTggNzEgOTkgMTA1IDc5IDEwNSA3NCA4MyA4NSA0OCA2OSAxMjAgODggMTIyIDg1IDEw NSA3NiA2NyA3NCAxMDggOTggMTA5IDc3IDEwNSA3OSAxMDUgNzQgNjYgNzcgODQgNzMgNTIgODEg NDggNzQgNjggNzUgNDggMTA0IDg0IDc3IDEwNiA4NSA1MCA3MyAxMTAgNDggNDYgOTAgMTA5IDEx MCAxMDggMTEzIDg3IDEwMyAxMDYgODggMTIxIDExMyAxMTkgMTA2IDExNCA1NSA5OSA4OA0KIDcy IDEyMSAxMTUgNTYgNzAgNTUgNTcgOTcgMTEwIDczIDg1IDczIDU0IDc0IDUwIDg1IDg3IDEwMCA2 NSAxMjEgODIgODEgNjkgOTkgNzEgNjYgODUgNDUgNzUgODAgNzIgMTE1IDEwMSA4MCA3NyA1NyA0 OSA0OCA5NSA4MiAxMTEgODQgNjggNzEgMTE3IDQ5IDczIDg3IDUyIDQ4IDY4IDExMCA0OCAxMDAg MTE4IDk5IDEwMCA4NiA2OSAxMDYgMTEyIDc0IDk5IDgwIDgwIDc4IDczIDk4IDEyMiA4NyA5OSA3 NyAxMjAgNjggMTA1IDQ5IDUxIDQ5IDY5IDEwNg0KIDEwMSAxMDMgNDUgOTggNTYgODYgMTA1IDg3 IDUzIDg5IDg4IDUzIDExMSA4MiAxMDAgODkgMTAwIDEwNSA4MiA1MiAxMDMgNzcgODMgNjggNjgg NjYgNTEgMTA5IDk4IDEwNyA3MyAxMTAgNzcgNzggODUgNzAgODQgNDUgODAgNzUgNTMgNjcgMTE3 IDkwIDgyIDExMCA3MiA2NiA1MCAxMTQgODUgNzUgNTMgMTAyIDEwNCA4MCAxMTcgNzAgNTQgODgg NzAgMTEzIDc2IDc2IDkwIDY3IDcxIDUzIDgxIDk1IDExNCA3NCAxMDkgNTQgNjkgMTE4IDEwMSAx MjANCiA0NSA4OCA3NiA5OSA3OCA4MSA2NSA3NCA3OCA5NyA0OSA0NSA1NCA2NyA3MyA4NSA0OSA1 MCA4NyAxMDYgNTEgMTA5IDgwIDY5IDEyMCAxMjAgMTE5IDU3IDExOCA5OCAxMTAgMTE1IDgxIDY4 IDg1IDU1IDY2IDUyIDY2IDEwMiAxMDkgMTA0IDEwMCAxMjEgMTA1IDEwMiAxMDggNzYgNjUgNTUg NjUgMTAxIDUzIDkwIDcxIDExMSA4NiA4MiAxMDggNTEgNjUgOTUgOTUgMTIxIDc2IDgwIDg4IDEy MCA4MiAxMDYgNzIgNzAgMTA0IDExMiA3OSAxMDEgNjgNCiAxMTIgOTUgOTcgMTAwIDEyMCA1NiA3 OCAxMjEgMTAxIDEwNiA3MCA1MyA5OSAxMjIgNTcgMTIxIDY4IDc1IDg1IDc2IDExNyAxMDMgNzgg MTE1IDY4IDc3IDEwMCAxMDggNzIgMTAxIDc0IDgxIDc5IDc3IDcxIDg2IDc2IDg5IDk3IDgzIDkw IDExNiA1MSA3NSA4MCA1NCA5NyA4NyA3OCA4MyAxMTMgNzAgNjUgNDkgODAgNzIgNjggMTAzIDQ1 IDQ5IDQ4IDk5IDEwMSAxMTcgODQgNjkgMTE2IDExMyA5NSAxMTggODAgNjkgNTIgNDUgNzEgMTE2 IDEwMSAxMTgNCiA1MiA3OCA1MiA3NSA1MiA2OSAxMTcgMTAwIDEwOCAxMDYgNTIgODEgNDYgNjUg MTIwIDg5IDU2IDY4IDY3IDExNiA2OCA5NyA3MSAxMDggMTE1IDk4IDcxIDEwOCAxMDYgOTggNTEg ODIgMTExIDkwIDgxIDQ2IDgyIDEyMCAxMTUgMTA2IDEwMyA1NCA4MCA3MyA2OSAxMjAgOTkgMTA5 IDcxIDgzIDcwIDU1IDc2IDExMCA4MyA2OSAxMDcgNjggMTEzIDg3IDczIDc1IDEwMiA2NSAxMTkg NDkgMTE5IDkwIDEyMiA1MCA4OCAxMTIgOTcgOTggODYgNTMgODANCiAxMTkgODEgMTE1IDExMSAx MDggNzUgMTE5IDY5IDk3IDExNyA4NyA4OSA5MCA3OCA2OSA1NyA4MSA0OSAxMDQgOTAgNzQgNjkg OTAgNDYgNTYgNzYgODggMTEzIDc3IDEwMCA0OCA3NCA3NiA3MSAxMTUgMTIwIDc3IDk3IDY2IDUz IDExNyAxMTEgNzggOTcgNzcgMTEyIDEwMyA1NSAxMTcgODUgODcgOTUgMTEyIDUyIDQ4IDgyIDEw OCA5NyA5MCA3MiA2NyAxMTkgNzcgNzMgMTIxIDEyMiAxMDc8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+YW5kIG9idGFpbmVkIHRoaXMgb3V0cHV0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+MCAxNCAyIDI0MSAyNTMgMTAxIDEyMSA3NCAxMDQgOTggNzEgOTkg MTA1IDc5IDEwNSA3NCA4MyA4NSA0OCA2OSAxMjAgODggMTIyIDg1IDEwNSA3NiA2NyA3NCAxMDgg OTggMTA5IDc3IDEwNSA3OSAxMDUgNzQgNjYgNzcgODQgNzMgNTIgODEgNDggNzQgNjggNzUgNDgg MTA0IDg0IDc3IDEwNiA4NSA1MCA3MyAxMTAgNDggNDYgOTAgMTA5IDExMCAxMDggMTEzIDg3IDEw MyAxMDYgODggMTIxIDExMyAxMTkgMTA2DQogMTE0IDU1IDk5IDg4IDcyIDEyMSAxMTUgNTYgNzAg NTUgNTcgOTcgMTEwIDczIDg1IDczIDU0IDc0IDUwIDg1IDg3IDEwMCA2NSAxMjEgODIgODEgNjkg OTkgNzEgNjYgODUgNDUgNzUgODAgNzIgMTE1IDEwMSA4MCA3NyA1NyA0OSA0OCA5NSA4MiAxMTEg ODQgNjggNzEgMTE3IDQ5IDczIDg3IDUyIDQ4IDY4IDExMCA0OCAxMDAgMTE4IDk5IDEwMCA4NiA2 OSAxMDYgMTEyIDc0IDk5IDgwIDgwIDc4IDczIDk4IDEyMiA4NyA5OSA3NyAxMjAgNjggMTA1DQog NDkgNTEgNDkgNjkgMTA2IDEwMSAxMDMgNDUgOTggNTYgODYgMTA1IDg3IDUzIDg5IDg4IDUzIDEx MSA4MiAxMDAgODkgMTAwIDEwNSA4MiA1MiAxMDMgNzcgODMgNjggNjggNjYgNTEgMTA5IDk4IDEw NyA3MyAxMTAgNzcgNzggODUgNzAgODQgNDUgODAgNzUgNTMgNjcgMTE3IDkwIDgyIDExMCA3MiA2 NiA1MCAxMTQgODUgNzUgNTMgMTAyIDEwNCA4MCAxMTcgNzAgNTQgODggNzAgMTEzIDc2IDc2IDkw IDY3IDcxIDUzIDgxIDk1IDExNCA3NCAxMDkgNTQNCiA2OSAxMTggMTAxIDEyMCA0NSA4OCA3NiA5 OSA3OCA4MSA2NSA3NCA3OCA5NyA0OSA0NSA1NCA2NyA3MyA4NSA0OSA1MCA4NyAxMDYgNTEgMTA5 IDgwIDY5IDEyMCAxMjAgMTE5IDU3IDExOCA5OCAxMTAgMTE1IDgxIDY4IDg1IDU1IDY2IDUyIDY2 IDEwMiAxMDkgMTA0IDEwMCAxMjEgMTA1IDEwMiAxMDggNzYgNjUgNTUgNjUgMTAxIDUzIDkwIDcx IDExMSA4NiA4MiAxMDggNTEgNjUgOTUgOTUgMTIxIDc2IDgwIDg4IDEyMCA4MiAxMDYgNzIgNzAg MTA0DQogMTEyIDc5IDEwMSA2OCAxMTIgOTUgOTcgMTAwIDEyMCA1NiA3OCAxMjEgMTAxIDEwNiA3 MCA1MyA5OSAxMjIgNTcgMTIxIDY4IDc1IDg1IDc2IDExNyAxMDMgNzggMTE1IDY4IDc3IDEwMCAx MDggNzIgMTAxIDc0IDgxIDc5IDc3IDcxIDg2IDc2IDg5IDk3IDgzIDkwIDExNiA1MSA3NSA4MCA1 NCA5NyA4NyA3OCA4MyAxMTMgNzAgNjUgNDkgODAgNzIgNjggMTAzIDQ1IDQ5IDQ4IDk5IDEwMSAx MTcgODQgNjkgMTE2IDExMyA5NSAxMTggODAgNjkgNTIgNDUNCiA3MSAxMTYgMTAxIDExOCA1MiA3 OCA1MiA3NSA1MiA2OSAxMTcgMTAwIDEwOCAxMDYgNTIgODEgNDYgNjUgMTIwIDg5IDU2IDY4IDY3 IDExNiA2OCA5NyA3MSAxMDggMTE1IDk4IDcxIDEwOCAxMDYgOTggNTEgODIgMTExIDkwIDgxIDQ2 IDgyIDEyMCAxMTUgMTA2IDEwMyA1NCA4MCA3MyA2OSAxMjAgOTkgMTA5IDcxIDgzIDcwIDU1IDc2 IDExMCA4MyA2OSAxMDcgNjggMTEzIDg3IDczIDc1IDEwMiA2NSAxMTkgNDkgMTE5IDkwIDEyMiA1 MCA4OCAxMTINCiA5NyA5OCA4NiA1MyA4MCAxMTkgODEgMTE1IDExMSAxMDggNzUgMTE5IDY5IDk3 IDExNyA4NyA4OSA5MCA3OCA2OSA1NyA4MSA0OSAxMDQgOTAgNzQgNjkgOTAgNDYgNTYgNzYgODgg MTEzIDc3IDEwMCA0OCA3NCA3NiA3MSAxMTUgMTIwIDc3IDk3IDY2IDUzIDExNyAxMTEgNzggOTcg NzcgMTEyIDEwMyA1NSAxMTcgODUgODcgOTUgMTEyIDUyIDQ4IDgyIDEwOCA5NyA5MCA3MiA2NyAx MTkgNzcgNzMgMTIxIDEyMiAxMDcgMSAwIDAgMjU1IDI1NTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5DYW4geW91IGRlY29tcHJlc3MgbXkgb3V0cHV0IGFuZCBvYnRhaW4gdGhlIG9yaWdp bmFsIHRleHQ/Jm5ic3A7IENhbiB5b3Ugc2VuZCBtZSB5b3VyIGNvbXByZXNzaW9uIG91dHB1dD8g Jm5ic3A7SeKAmWxsIHRoZW4gdHJ5IHRvIHVuY29tcHJlc3MgaXQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoYW5rcyBmb3IgZG91YmxlLWNoZWNraW5nIHRoaXMhPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739436697A5D4TK5EX14MBXC283r_-- From James.H.Manger@team.telstra.com Wed Dec 19 17:03:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D12321F85E6 for ; Wed, 19 Dec 2012 17:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr4gjCj+xNzE for ; Wed, 19 Dec 2012 17:03:02 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id BC7DE21F8831 for ; Wed, 19 Dec 2012 17:03:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,320,1355058000"; d="scan'208,217";a="107165097" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 20 Dec 2012 12:02:58 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6931"; a="96301801" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdni.tcif.telstra.com.au with ESMTP; 20 Dec 2012 12:02:58 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 20 Dec 2012 12:02:57 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 20 Dec 2012 12:02:56 +1100 Thread-Topic: Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgArYb9QAAEkkLAAAb5OYAAApjQQAABZXTA= Message-ID: <255B9BB34FB7D647A506DC292726F6E115042EDA63@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F65F9@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977C74@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F6786@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436697A5D4@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697A5D4@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115042EDA63WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 01:03:03 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115042EDA63WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGWUksIEkgd2FzIGFibGUgdG8gZGVmbGF0ZSB0aGUgNDI3IGNvbXByZXNzZWQgYnl0ZXMgeW91 IHNlbnQgbWUgcHJpdmF0ZWx5DQoNCk9wcHMsIGl0IHdhc27igJl0IG1lYW50IHRvIGJlIHByaXZh dGU7IGhpdCB0aGUgd3Jvbmcg4oCccmVwbHnigJ0gYnV0dG9uIEkgZ3Vlc3MuIEphdmHigJlzIERF RkFMVEUgb3V0cHV0IGlzIGJlbG93IGp1c3QgZm9yIGNvbXBsZXRlbmVzcy4NCg0KLS0NCkphbWVz IE1hbmdlcg0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEgNClNlbnQ6IFRodXJzZGF5LCAyMCBEZWNl bWJlciAyMDEyIDExOjI2IEFNDQpUbzogJ01pa2UgSm9uZXMnDQpTdWJqZWN0OiBSRTogUmVkdWNp bmcgdGhlIHNpemUgb2YgSldTIHBheWxvYWRzDQoNCkhpIE1pa2UsDQoNCkhlcmUgYXJlIHRoZSA0 MjcgY29tcHJlc3NlZCBieXRlcyBJIGdldCAoZnJvbSBKYXZh4oCZcyBqYXZhLnV0aWwuemlwLkRl ZmxhdGVyIGNsYXNzLCBhcyBpbXBsZW1lbnRlZCBieSBPcmFjbGUpOg0KMjEgMjAwIDIwMSAxNzgg MTA3IDY0IDAgMCAyMDggNDcgMTQ2IDM0IDE2NiAxMDAgMTM3IDExMCA2NyAyMTEgMjEwIDcyIDEz NSAyMTYgNDAgODMgMTIgNDkgOTQgMTcgMjI4IDIzNSA5NSAxODkgMTc5IDYwIDIyOSAxMjkgMjM0 IDIwNCAyMDAgMTU1IDkxIDEzMSAyIDIwMiAxOTQgNjEgMjUwIDIwOSAxOTggMjA5IDgwIDE1MSAy NDUgMjQ4IDI1NSAxNjkgMjQ4IDExMCA5IDMwIDEzOSAxMjggMjA1IDIxNCAxMTkgMjIwIDIxMCAx NzkgNTMgMTc2IDE2NyAxODQgMzEgMTg2IDU3IDE3MiAyMTggMjMyIDE1MiAxODMgMjQ2IDc5IDIw NiAzNSAyNDMgODggNDYgMTg2IDEyNCA3NyA3IDEzOSA5MCAxOCA1OCAyMTEgMTc2IDgwIDE0IDIy MyAxMzEgMTg1IDE2MSA4MiAxOTggMzggMjMwIDgyIDE4IDEyNCAyMjkgMjE2IDE5NiAzMSAyMzkg MTkyIDg4IDU3IDQzIDIwIDg4IDQ4IDE3NiAxOTcgNTUgNDcgMzAgMTc2IDE1NyA4MCA3OCAxMzYg MTA3IDEwMSAxOTEgNDggMTk5IDU5IDEwNCA1NiAxNTggMTMxIDEwOSA4OSA0OSAyMTcgMjI5IDIw OSAxMzIgMjI2IDUxIDE4IDcxIDE5MSAxMjAgMjIgMTQxIDQ3IDg0IDU2IDAgNjQgMjI5IDI1MSAy MzYgMTA5IDEzIDIxNiAxNjUgMjUwIDE1NyAzMyAxODIgMTY4IDE3MyAxNzcgNjMgMTUyIDIzNCAy NDkgMTQzIDIxOCAyMjYgMTcxIDM4IDE3MSA0NiA2OSAyNTAgMjM2IDU2IDE3NyAxMDIgMTM2IDk0 IDI0MiAxMzUgMTIyIDkgMTI2IDIwMyAxNTcgMTM3IDE1NiAyMjAgMjQ1IDIwIDIyOCAxNjYgMjgg MzUgMTA1IDIyIDIyOSAyMDYgOTcgMjAzIDI0NyA0IDIzOCAyNTEgMTE4IDI1MyAxMDIgMTk1IDIy NiAxIDQyIDE3MSAxMzAgMjUwIDIzNCAyMzUgMjI2IDEwNCA5NCAxNTcgMTYzIDIwMCA3NCA0MSAx OTggMTk4IDI0OCAyNDAgNTkgOTQgNzMgMTQ2IDE5NSAzMyAyMDkgMjM4IDE4MyAxNjYgOTQgNzkg MTgzIDE4IDc2IDczIDkwIDIzNiAyMyAyNDcgNDAgOTEgOTMgMjA0IDEyNyAyMTUgMyAyMTYgMjEy IDg5IDQzIDExOSAxIDE4NCAyMzIgMjA0IDE4IDEyMSA1NSAxMDggNjAgMTU2IDEwMyAyNiAxOTYg MzEgMjIyIDM4IDgyIDI2IDE4NiAxOTMgMTcyIDQzIDI4IDQ5IDY1IDE5NyAxMTIgMTA4IDk0IDE3 NCAxMTkgMjQ4IDE1MyAxNDcgNDcgMTI5IDIgOTkgMTI0IDIwMiAxNzUgMjI0IDEwIDE4MiAwIDIx NSAxNjIgMTA3IDUgMjM5IDE2NCAyMzYgMjA3IDExIDIwOCA2MiAzMiA1MyAxODYgMzcgNTEgMTg2 IDU0IDIyNyAyNTMgNDkgMjQ2IDc4IDI1NCAxOTAgMTgwIDE0OSA2OCA0NCAxODQgMjMxIDE4OSAx NyAyMzIgMTc4IDUxIDQgMjQwIDEzIDIzMCAyMDggMTc4IDk1IDIwMiAxOTggMTA5IDI0MSAyMzkg MjggNzcgMTA1IDI0NiAxNiAyMDEgMjMwIDQ1IDk5IDEwMyAxMTEgNDggOTMgMTk1IDEwMyAyMzYg MTk0IDE3MSAxOTkgMjEzIDQ5IDEzMCAyNDEgMjMzIDIyNiA2OCA1MSA0NiA4OCAyMjggMjQgMjAz IDE0MiA4MyA4NSA5MiA3MSA1NSAxOTcgODMgMzcgMTc1IDUyIDc2IDM4IDEyOSAyNDUgMTg3IDUy IDU0IDE4MSAxMyA5MSAxOTkgMjM5IDI1MyAxNQ0KDQpJIGNhbiB1bmNvbXByZXNzIHlvdXIgNTM2 IGJ5dGVzIHRvIHRoZSBvcmlnaW5hbCA1MjYuDQoNCg0KUC5TLiBJIHBlcnNvbmFsbHkgZmluZCBp dCBtdWNoIGVhc2llciB0byBoYW5kbGUgYmluYXJ5IGRhdGEgaW4gaGV4IHRoYW4gYXMgZGVjaW1h bCBpbnRlZ2Vycy4gUGVyaGFwcyBkZWNpbWFsIGlzIHVzZWQgaW4gdGhlIEpPU0Ugc3BlY3Mgc28g YSBKU09OIGFycmF5IG9mIG51bWJlcnMgY2FuIGJlIHVzZWQgdG8gcmVwcmVzZW50IHRoZSBiaW5h cnkgZGF0YSwgdGhvdWdoIHRoYXQgZG9lc27igJl0IHNlZW0gcGFydGljdWxhcmx5IHVzZWZ1bC4N Cg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E115042EDA63WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5N c29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9 cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+RllJLCBJIHdhcyBhYmxlIHRvIGRlZmxhdGUgdGhlIDQyNyBjb21wcmVz c2VkIGJ5dGVzIHlvdSBzZW50IG1lIHByaXZhdGVseTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+T3BwcywgaXQgd2FzbuKAmXQg bWVhbnQgdG8gYmUgcHJpdmF0ZTsgaGl0IHRoZSB3cm9uZyDigJxyZXBseeKAnSBidXR0b24gSSBn dWVzcy4gSmF2YeKAmXMgREVGQUxURSBvdXRwdXQgaXMgYmVsb3cganVzdCBmb3IgY29tcGxldGVu ZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5KYW1l cyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1hbmdlciwgSmFtZXMgSCA8 YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCAyMCBEZWNlbWJlciAyMDEyIDExOjI2IEFNPGJyPjxi PlRvOjwvYj4gJ01pa2UgSm9uZXMnPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogUmVkdWNpbmcgdGhl IHNpemUgb2YgSldTIHBheWxvYWRzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPkhpIE1pa2UsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SGVy ZSBhcmUgdGhlIDQyNyBjb21wcmVzc2VkIGJ5dGVzIEkgZ2V0IChmcm9tIEphdmHigJlzIGphdmEu dXRpbC56aXAuRGVmbGF0ZXIgY2xhc3MsIGFzIGltcGxlbWVudGVkIGJ5IE9yYWNsZSk6PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+MjEgMjAwIDIwMSAxNzggMTA3IDY0IDAgMCAyMDggNDcgMTQ2IDM0IDE2NiAxMDAgMTM3 IDExMCA2NyAyMTEgMjEwIDcyIDEzNSAyMTYgNDAgODMgMTIgNDkgOTQgMTcgMjI4IDIzNSA5NSAx ODkgMTc5IDYwIDIyOSAxMjkgMjM0IDIwNCAyMDAgMTU1IDkxIDEzMSAyIDIwMiAxOTQgNjEgMjUw IDIwOSAxOTggMjA5IDgwIDE1MSAyNDUgMjQ4IDI1NSAxNjkgMjQ4IDExMCA5IDMwIDEzOSAxMjgg MjA1IDIxNCAxMTkgMjIwIDIxMCAxNzkgNTMgMTc2IDE2NyAxODQgMzEgMTg2IDU3IDE3MiAyMTgg MjMyIDE1MiAxODMgMjQ2IDc5IDIwNiAzNSAyNDMgODggNDYgMTg2IDEyNCA3NyA3IDEzOSA5MCAx OCA1OCAyMTEgMTc2IDgwIDE0IDIyMyAxMzEgMTg1IDE2MSA4MiAxOTggMzggMjMwIDgyIDE4IDEy NCAyMjkgMjE2IDE5NiAzMSAyMzkgMTkyIDg4IDU3IDQzIDIwIDg4IDQ4IDE3NiAxOTcgNTUgNDcg MzAgMTc2IDE1NyA4MCA3OCAxMzYgMTA3IDEwMSAxOTEgNDggMTk5IDU5IDEwNCA1NiAxNTggMTMx IDEwOSA4OSA0OSAyMTcgMjI5IDIwOSAxMzIgMjI2IDUxIDE4IDcxIDE5MSAxMjAgMjIgMTQxIDQ3 IDg0IDU2IDAgNjQgMjI5IDI1MSAyMzYgMTA5IDEzIDIxNiAxNjUgMjUwIDE1NyAzMyAxODIgMTY4 IDE3MyAxNzcgNjMgMTUyIDIzNCAyNDkgMTQzIDIxOCAyMjYgMTcxIDM4IDE3MSA0NiA2OSAyNTAg MjM2IDU2IDE3NyAxMDIgMTM2IDk0IDI0MiAxMzUgMTIyIDkgMTI2IDIwMyAxNTcgMTM3IDE1NiAy MjAgMjQ1IDIwIDIyOCAxNjYgMjggMzUgMTA1IDIyIDIyOSAyMDYgOTcgMjAzIDI0NyA0IDIzOCAy NTEgMTE4IDI1MyAxMDIgMTk1IDIyNiAxIDQyIDE3MSAxMzAgMjUwIDIzNCAyMzUgMjI2IDEwNCA5 NCAxNTcgMTYzIDIwMCA3NCA0MSAxOTggMTk4IDI0OCAyNDAgNTkgOTQgNzMgMTQ2IDE5NSAzMyAy MDkgMjM4IDE4MyAxNjYgOTQgNzkgMTgzIDE4IDc2IDczIDkwIDIzNiAyMyAyNDcgNDAgOTEgOTMg MjA0IDEyNyAyMTUgMyAyMTYgMjEyIDg5IDQzIDExOSAxIDE4NCAyMzIgMjA0IDE4IDEyMSA1NSAx MDggNjAgMTU2IDEwMyAyNiAxOTYgMzEgMjIyIDM4IDgyIDI2IDE4NiAxOTMgMTcyIDQzIDI4IDQ5 IDY1IDE5NyAxMTIgMTA4IDk0IDE3NCAxMTkgMjQ4IDE1MyAxNDcgNDcgMTI5IDIgOTkgMTI0IDIw MiAxNzUgMjI0IDEwIDE4MiAwIDIxNSAxNjIgMTA3IDUgMjM5IDE2NCAyMzYgMjA3IDExIDIwOCA2 MiAzMiA1MyAxODYgMzcgNTEgMTg2IDU0IDIyNyAyNTMgNDkgMjQ2IDc4IDI1NCAxOTAgMTgwIDE0 OSA2OCA0NCAxODQgMjMxIDE4OSAxNyAyMzIgMTc4IDUxIDQgMjQwIDEzIDIzMCAyMDggMTc4IDk1 IDIwMiAxOTggMTA5IDI0MSAyMzkgMjggNzcgMTA1IDI0NiAxNiAyMDEgMjMwIDQ1IDk5IDEwMyAx MTEgNDggOTMgMTk1IDEwMyAyMzYgMTk0IDE3MSAxOTkgMjEzIDQ5IDEzMCAyNDEgMjMzIDIyNiA2 OCA1MSA0NiA4OCAyMjggMjQgMjAzIDE0MiA4MyA4NSA5MiA3MSA1NSAxOTcgODMgMzcgMTc1IDUy IDc2IDM4IDEyOSAyNDUgMTg3IDUyIDU0IDE4MSAxMyA5MSAxOTkgMjM5IDI1MyAxNTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgY2FuIHVuY29tcHJlc3MgeW91ciA1MzYgYnl0ZXMgdG8g dGhlIG9yaWdpbmFsIDUyNi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz5QLlMuIEkgcGVyc29uYWxseSBmaW5kIGl0IG11Y2ggZWFzaWVyIHRvIGhhbmRsZSBi aW5hcnkgZGF0YSBpbiBoZXggdGhhbiBhcyBkZWNpbWFsIGludGVnZXJzLiBQZXJoYXBzIGRlY2lt YWwgaXMgdXNlZCBpbiB0aGUgSk9TRSBzcGVjcyBzbyBhIEpTT04gYXJyYXkgb2YgbnVtYmVycyBj YW4gYmUgdXNlZCB0byByZXByZXNlbnQgdGhlIGJpbmFyeSBkYXRhLCB0aG91Z2ggdGhhdCBkb2Vz buKAmXQgc2VlbSBwYXJ0aWN1bGFybHkgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E115042EDA63WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Wed Dec 19 17:39:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3240B21F8A5D for ; Wed, 19 Dec 2012 17:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFakBLFHVv-I for ; Wed, 19 Dec 2012 17:39:29 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25821F8A3E for ; Wed, 19 Dec 2012 17:39:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,321,1355058000"; d="scan'208,217";a="107174197" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 20 Dec 2012 12:39:25 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6931"; a="52802518" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcani.tcif.telstra.com.au with ESMTP; 20 Dec 2012 12:39:24 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 20 Dec 2012 12:39:24 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 20 Dec 2012 12:39:21 +1100 Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sAAkEbRAAApz+pA= Message-ID: <255B9BB34FB7D647A506DC292726F6E115042EDB0C@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115042EDB0CWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 01:39:30 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115042EDB0CWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiDigJx6aXDigJ0gaXMgYSBwZXJmZWN0IGV4YW1wbGUgb2YgaW5kaWNhdGluZyBhIGNoYW5nZSBv ZiBzZW1hbnRpY3Mgd2l0aCB0aGUgcHJlc2VuY2Ugb2YgYSBuZXcgZmllbGQuICBUaGUgcHJvY2Vz c2luZyBvZiBhIEpXRSB3aXRob3V0IGEg4oCcemlw4oCdIGZpZWxkIGlzIGRpZmZlcmVudCB0aGFu IHRoZSBwcm9jZXNzaW5nIG9mIGl0IHdpdGggb25lLiAgQW4gaW1wbGVtZW50YXRpb24gbXVzdCB1 bmRlcnN0YW5kIHRoZSBmaWVsZCB0byB1c2UgdGhlIHJlc3VsdGluZyBKV0UuICBUaGUgc2FtZSB3 b3VsZCBiZSB0cnVlIG9mIGFueSBKV1MgdGhhdCB1c2VkIGEg4oCcemlw4oCdIGV4dGVuc2lvbi4N Cj4NCj4gSXQgd291bGQgbmV2ZXIgYmUgc2FmZSB0byBpZ25vcmUgdGhpcyBmaWVsZCwgd2hldGhl ciBkZWZpbmVkIGFzIHBhcnQgb2YgdGhlIGJhc2Ugc3BlYywgb3IgZGVmaW5lZCBhcyBhbiBleHRl bnNpb24gbGF0ZXIuDQoNCkkgYWdyZWUuDQpXaGVuIEkgbG9va2VkIGF0IGEgaGFuZGZ1bCBvZiBw dWJsaWNseSBhdmFpbGFibGUgSk9TRSBpbXBsZW1lbnRhdGlvbnMgcXVpdGUgYSB3aGlsZSBhZ28g bm9uZSBlbmZvcmNlZCB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcnVsZSDi gJQgc28gYSB6aXAtZm9yLUpXUyBleHRlbnNpb24gd291bGQgYmUgZGFuZ2Vyb3VzIGZvciB0aGVt LiBPbmUgaW1wbGVtZW50YXRpb24gbGF0ZXIgYWRkZWQgY29kZSB0byBlbmZvcmNlIHRoZSBydWxl IHVzaW5nIG9uZSBmaXhlZCBsaXN0IG9mIGFsbCBoZWFkZXIgZmllbGRzIGRlZmluZWQgaW4gSlcq IOKAlCBzbyBhIHppcC1mb3ItSldTIGV4dGVuc2lvbiB3b3VsZCBiZSBkYW5nZXJvdXMgZm9yIHRo YXQgdG9vLg0KDQpXZSBrbm93IHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZ+KAnSBy dWxlIG1ha2VzIGl0IGhhcmQgdG8gZGVwbG95IG5vbi1jcml0aWNhbCBleHRlbnNpb25zLg0KSXQg c2VlbXMgdG8gbWUgdGhhdCB0aGUgcnVsZSBhbHNvIG1ha2VzIGl0IGRhbmdlcm91cyB0byBkZXBs b3kgY3JpdGljYWwgZXh0ZW5zaW9ucy4NCkFib3V0IHRoZSBvbmx5IHNhZmUgd2F5IHRvIGRlZmlu ZSBhIGNyaXRpY2FsIGV4dGVuc2lvbiB3aWxsIGJlIHRvIGRlZmluZSBhIHByZWZpeCBmb3Ig4oCc YWxn4oCdIHZhbHVlcyAoZWcgImFsZyI6ICJ6aXA7UlNBMV81IikuIEkgaG9wZSB0aGF0IGlzbuKA mXQgdGhlIG1vc3QgcHJhY3RpY2FsIG9wdGlvbiB3ZSBsZWF2ZSBmb3IgYW55b25lIHdhbnRpbmcg dG8gZXh0ZW5kIEpPU0UuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== --_000_255B9BB34FB7D647A506DC292726F6E115042EDB0CWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5N c29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2 bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsg4oCcemlw4oCdIGlzIGEg cGVyZmVjdCBleGFtcGxlIG9mIGluZGljYXRpbmcgYSBjaGFuZ2Ugb2Ygc2VtYW50aWNzIHdpdGgg dGhlIHByZXNlbmNlIG9mIGEgbmV3IGZpZWxkLiZuYnNwOyBUaGUgcHJvY2Vzc2luZyBvZiBhIEpX RSB3aXRob3V0IGEg4oCcemlw4oCdIGZpZWxkIGlzIGRpZmZlcmVudCB0aGFuIHRoZSBwcm9jZXNz aW5nIG9mIGl0IHdpdGggb25lLiZuYnNwOyBBbiBpbXBsZW1lbnRhdGlvbiBtdXN0IHVuZGVyc3Rh bmQgdGhlIGZpZWxkIHRvIHVzZSB0aGUgcmVzdWx0aW5nIEpXRS4mbmJzcDsgVGhlIHNhbWUgd291 bGQgYmUgdHJ1ZSBvZiBhbnkgSldTIHRoYXQgdXNlZCBhIOKAnHppcOKAnSBleHRlbnNpb24uPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7 IEl0IHdvdWxkIG5ldmVyIGJlIHNhZmUgdG8gaWdub3JlIHRoaXMgZmllbGQsIHdoZXRoZXIgZGVm aW5lZCBhcyBwYXJ0IG9mIHRoZSBiYXNlIHNwZWMsIG9yIGRlZmluZWQgYXMgYW4gZXh0ZW5zaW9u IGxhdGVyLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+SSBhZ3JlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5XaGVuIEkgbG9va2VkIGF0IGEgaGFu ZGZ1bCBvZiBwdWJsaWNseSBhdmFpbGFibGUgSk9TRSBpbXBsZW1lbnRhdGlvbnMgcXVpdGUgYSB3 aGlsZSBhZ28gbm9uZSBlbmZvcmNlZCB0aGUg4oCcTVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmfi gJ0gcnVsZSDigJQgc28gYSB6aXAtZm9yLUpXUyBleHRlbnNpb24gd291bGQgYmUgZGFuZ2Vyb3Vz IGZvciB0aGVtLiBPbmUgaW1wbGVtZW50YXRpb24gbGF0ZXIgYWRkZWQgY29kZSB0byBlbmZvcmNl IHRoZSBydWxlIHVzaW5nIG9uZSBmaXhlZCBsaXN0IG9mIGFsbCBoZWFkZXIgZmllbGRzIGRlZmlu ZWQgaW4gSlcqIOKAlCBzbyBhIHppcC1mb3ItSldTIGV4dGVuc2lvbiB3b3VsZCBiZSBkYW5nZXJv dXMgZm9yIHRoYXQgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPldlIGtub3cgdGhl IOKAnE1VU1QgdW5kZXJzdGFuZCBldmVyeXRoaW5n4oCdIHJ1bGUgbWFrZXMgaXQgaGFyZCB0byBk ZXBsb3kgbm9uLWNyaXRpY2FsIGV4dGVuc2lvbnMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SXQgc2VlbXMgdG8gbWUg dGhhdCB0aGUgcnVsZSBhbHNvIG1ha2VzIGl0IGRhbmdlcm91cyB0byBkZXBsb3kgY3JpdGljYWwg ZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BYm91dCB0aGUgb25seSBzYWZlIHdheSB0byBkZWZpbmUg YSBjcml0aWNhbCBleHRlbnNpb24gd2lsbCBiZSB0byBkZWZpbmUgYSBwcmVmaXggZm9yIOKAnGFs Z+KAnSB2YWx1ZXMgKGVnICZxdW90O2FsZyZxdW90OzogJnF1b3Q7emlwO1JTQTFfNSZxdW90Oyku IEkgaG9wZSB0aGF0IGlzbuKAmXQgdGhlIG1vc3QgcHJhY3RpY2FsIG9wdGlvbiB3ZSBsZWF2ZSBm b3IgYW55b25lIHdhbnRpbmcgdG8gZXh0ZW5kIEpPU0UuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E115042EDB0CWSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Wed Dec 19 17:51:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E324621F8A09 for ; Wed, 19 Dec 2012 17:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsTAOloec8w1 for ; Wed, 19 Dec 2012 17:51:31 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 722FF21F89CB for ; Wed, 19 Dec 2012 17:51:29 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.200) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 01:51:22 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 01:51:21 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 01:51:21 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sAAkEbRAAApz+pAAAl46sA== Date: Thu, 20 Dec 2012 01:51:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436697AEE2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115042EDB0C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115042EDB0C@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.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436697AEE2TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(5343635001)(54356001)(74662001)(5343655001)(49866001)(77982001)(50986001)(16236675001)(44976002)(31966008)(59766001)(33656001)(56776001)(47446002)(51856001)(16406001)(55846006)(15202345001)(47736001)(512874001)(74502001)(46102001)(47976001)(56816002)(53806001)(54316002)(4396001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07013D7479 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 01:51:32 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436697AEE2TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByZWZpeCBmb3Ig4oCcYWxn4oCdIHZhbHVlcyB3b3VsZCBoYXZlIGV4YWN0bHkgdGhlIHNh bWUgcHJvcGVydHkgYXMgYWRkaW5nIGEgbmV3IGhlYWRlciBwYXJhbWV0ZXIuICBJZiB0aGUgbmV3 IGFsZyB2YWx1ZSB3YXMgbm90IHVuZGVyc3Rvb2QsIHRoZSBKV1Mgd291bGQgYmUgdXNlbGVzcyB0 byB0aGUgcmVjZWl2ZXIuICAoSnVzdCBhcyBpdCB3b3VsZCBiZSB1c2VsZXNzIGlmIGEgbmV3IGhl YWRlciB2YWx1ZSB3YXMgdXNlZCwgaWYgbm90IHVuZGVyc3Rvb2QuKSAgSeKAmW0gbm90IHN1cmUg d2h5IHRoZSBmb3JtZXIgaXMgYW55IG1vcmUgdXNhYmxlIHRoYW4gdGhlIGxhdHRlci4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIENoZWVycywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE1hbmdlciwgSmFtZXMgSCBbbWFp bHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dDQpTZW50OiBXZWRuZXNkYXksIERl Y2VtYmVyIDE5LCAyMDEyIDU6MzkgUE0NClRvOiBNaWtlIEpvbmVzOyBqb3NlQGlldGYub3JnDQpT dWJqZWN0OiBSRTogW2pvc2VdIFdoZXRoZXIgaW1wbGVtZW50YXRpb25zIG11c3QgdW5kZXJzdGFu ZCBhbGwgSk9TRSBoZWFkZXIgZmllbGRzDQoNCj4g4oCcemlw4oCdIGlzIGEgcGVyZmVjdCBleGFt cGxlIG9mIGluZGljYXRpbmcgYSBjaGFuZ2Ugb2Ygc2VtYW50aWNzIHdpdGggdGhlIHByZXNlbmNl IG9mIGEgbmV3IGZpZWxkLiAgVGhlIHByb2Nlc3Npbmcgb2YgYSBKV0Ugd2l0aG91dCBhIOKAnHpp cOKAnSBmaWVsZCBpcyBkaWZmZXJlbnQgdGhhbiB0aGUgcHJvY2Vzc2luZyBvZiBpdCB3aXRoIG9u ZS4gIEFuIGltcGxlbWVudGF0aW9uIG11c3QgdW5kZXJzdGFuZCB0aGUgZmllbGQgdG8gdXNlIHRo ZSByZXN1bHRpbmcgSldFLiAgVGhlIHNhbWUgd291bGQgYmUgdHJ1ZSBvZiBhbnkgSldTIHRoYXQg dXNlZCBhIOKAnHppcOKAnSBleHRlbnNpb24uDQo+DQo+IEl0IHdvdWxkIG5ldmVyIGJlIHNhZmUg dG8gaWdub3JlIHRoaXMgZmllbGQsIHdoZXRoZXIgZGVmaW5lZCBhcyBwYXJ0IG9mIHRoZSBiYXNl IHNwZWMsIG9yIGRlZmluZWQgYXMgYW4gZXh0ZW5zaW9uIGxhdGVyLg0KDQpJIGFncmVlLg0KV2hl biBJIGxvb2tlZCBhdCBhIGhhbmRmdWwgb2YgcHVibGljbHkgYXZhaWxhYmxlIEpPU0UgaW1wbGVt ZW50YXRpb25zIHF1aXRlIGEgd2hpbGUgYWdvIG5vbmUgZW5mb3JjZWQgdGhlIOKAnE1VU1QgdW5k ZXJzdGFuZCBldmVyeXRoaW5n4oCdIHJ1bGUg4oCUIHNvIGEgemlwLWZvci1KV1MgZXh0ZW5zaW9u IHdvdWxkIGJlIGRhbmdlcm91cyBmb3IgdGhlbS4gT25lIGltcGxlbWVudGF0aW9uIGxhdGVyIGFk ZGVkIGNvZGUgdG8gZW5mb3JjZSB0aGUgcnVsZSB1c2luZyBvbmUgZml4ZWQgbGlzdCBvZiBhbGwg aGVhZGVyIGZpZWxkcyBkZWZpbmVkIGluIEpXKiDigJQgc28gYSB6aXAtZm9yLUpXUyBleHRlbnNp b24gd291bGQgYmUgZGFuZ2Vyb3VzIGZvciB0aGF0IHRvby4NCg0KV2Uga25vdyB0aGUg4oCcTVVT VCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcnVsZSBtYWtlcyBpdCBoYXJkIHRvIGRlcGxveSBu b24tY3JpdGljYWwgZXh0ZW5zaW9ucy4NCkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHJ1bGUgYWxz byBtYWtlcyBpdCBkYW5nZXJvdXMgdG8gZGVwbG95IGNyaXRpY2FsIGV4dGVuc2lvbnMuDQpBYm91 dCB0aGUgb25seSBzYWZlIHdheSB0byBkZWZpbmUgYSBjcml0aWNhbCBleHRlbnNpb24gd2lsbCBi ZSB0byBkZWZpbmUgYSBwcmVmaXggZm9yIOKAnGFsZ+KAnSB2YWx1ZXMgKGVnICJhbGciOiAiemlw O1JTQTFfNSIpLiBJIGhvcGUgdGhhdCBpc27igJl0IHRoZSBtb3N0IHByYWN0aWNhbCBvcHRpb24g d2UgbGVhdmUgZm9yIGFueW9uZSB3YW50aW5nIHRvIGV4dGVuZCBKT1NFLg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQo= --_000_4E1F6AAD24975D4BA5B16804296739436697AEE2TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBwcmVmaXggZm9yIOKAnGFsZ+KAnSB2YWx1ZXMgd291bGQg aGF2ZSBleGFjdGx5IHRoZSBzYW1lIHByb3BlcnR5IGFzIGFkZGluZyBhIG5ldyBoZWFkZXIgcGFy YW1ldGVyLiZuYnNwOyBJZiB0aGUgbmV3IGFsZyB2YWx1ZSB3YXMgbm90IHVuZGVyc3Rvb2QsIHRo ZSBKV1Mgd291bGQgYmUgdXNlbGVzcyB0byB0aGUgcmVjZWl2ZXIuJm5ic3A7IChKdXN0IGFzIGl0 IHdvdWxkIGJlIHVzZWxlc3MNCiBpZiBhIG5ldyBoZWFkZXIgdmFsdWUgd2FzIHVzZWQsIGlmIG5v dCB1bmRlcnN0b29kLikmbmJzcDsgSeKAmW0gbm90IHN1cmUgd2h5IHRoZSBmb3JtZXIgaXMgYW55 IG1vcmUgdXNhYmxlIHRoYW4gdGhlIGxhdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGVlcnMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gTWFuZ2VyLCBKYW1lcyBIIFttYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJh LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVyIDE5LCAyMDEyIDU6 MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtqb3NlXSBXaGV0aGVyIGltcGxlbWVudGF0aW9ucyBtdXN0IHVuZGVy c3RhbmQgYWxsIEpPU0UgaGVhZGVyIGZpZWxkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7IOKAnHpp cOKAnSBpcyBhIHBlcmZlY3QgZXhhbXBsZSBvZiBpbmRpY2F0aW5nIGEgY2hhbmdlIG9mIHNlbWFu dGljcyB3aXRoIHRoZSBwcmVzZW5jZSBvZiBhIG5ldyBmaWVsZC4mbmJzcDsgVGhlIHByb2Nlc3Np bmcgb2YgYSBKV0Ugd2l0aG91dCBhIOKAnHppcOKAnSBmaWVsZCBpcyBkaWZmZXJlbnQgdGhhbiB0 aGUgcHJvY2Vzc2luZyBvZiBpdCB3aXRoIG9uZS4mbmJzcDsgQW4gaW1wbGVtZW50YXRpb24NCiBt dXN0IHVuZGVyc3RhbmQgdGhlIGZpZWxkIHRvIHVzZSB0aGUgcmVzdWx0aW5nIEpXRS4mbmJzcDsg VGhlIHNhbWUgd291bGQgYmUgdHJ1ZSBvZiBhbnkgSldTIHRoYXQgdXNlZCBhIOKAnHppcOKAnSBl eHRlbnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0OyBJ dCB3b3VsZCBuZXZlciBiZSBzYWZlIHRvIGlnbm9yZSB0aGlzIGZpZWxkLCB3aGV0aGVyIGRlZmlu ZWQgYXMgcGFydCBvZiB0aGUgYmFzZSBzcGVjLCBvciBkZWZpbmVkIGFzIGFuIGV4dGVuc2lvbiBs YXRlci48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1B VSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SSBhZ3JlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldoZW4gSSBsb29rZWQgYXQg YSBoYW5kZnVsIG9mIHB1YmxpY2x5IGF2YWlsYWJsZSBKT1NFIGltcGxlbWVudGF0aW9ucyBxdWl0 ZSBhIHdoaWxlIGFnbyBub25lIGVuZm9yY2VkIHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgZXZlcnl0 aGluZ+KAnSBydWxlIOKAlCBzbyBhIHppcC1mb3ItSldTIGV4dGVuc2lvbiB3b3VsZCBiZSBkYW5n ZXJvdXMgZm9yIHRoZW0uDQogT25lIGltcGxlbWVudGF0aW9uIGxhdGVyIGFkZGVkIGNvZGUgdG8g ZW5mb3JjZSB0aGUgcnVsZSB1c2luZyBvbmUgZml4ZWQgbGlzdCBvZiBhbGwgaGVhZGVyIGZpZWxk cyBkZWZpbmVkIGluIEpXKiDigJQgc28gYSB6aXAtZm9yLUpXUyBleHRlbnNpb24gd291bGQgYmUg ZGFuZ2Vyb3VzIGZvciB0aGF0IHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2Uga25vdyB0aGUg4oCcTVVTVCB1bmRlcnN0 YW5kIGV2ZXJ5dGhpbmfigJ0gcnVsZSBtYWtlcyBpdCBoYXJkIHRvIGRlcGxveSBub24tY3JpdGlj YWwgZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IHNlZW1zIHRvIG1l IHRoYXQgdGhlIHJ1bGUgYWxzbyBtYWtlcyBpdCBkYW5nZXJvdXMgdG8gZGVwbG95IGNyaXRpY2Fs IGV4dGVuc2lvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BYm91dCB0aGUgb25seSBz YWZlIHdheSB0byBkZWZpbmUgYSBjcml0aWNhbCBleHRlbnNpb24gd2lsbCBiZSB0byBkZWZpbmUg YSBwcmVmaXggZm9yIOKAnGFsZ+KAnSB2YWx1ZXMgKGVnICZxdW90O2FsZyZxdW90OzogJnF1b3Q7 emlwO1JTQTFfNSZxdW90OykuIEkgaG9wZSB0aGF0IGlzbuKAmXQgdGhlIG1vc3QgcHJhY3RpY2Fs IG9wdGlvbiB3ZSBsZWF2ZSBmb3IgYW55b25lIHdhbnRpbmcNCiB0byBleHRlbmQgSk9TRS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1B VSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5KYW1lcyBNYW5nZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739436697AEE2TK5EX14MBXC283r_-- From James.H.Manger@team.telstra.com Wed Dec 19 18:08:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C883B21F84D8 for ; Wed, 19 Dec 2012 18:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwQm5ci67bKT for ; Wed, 19 Dec 2012 18:08:32 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id E9B6E21F843E for ; Wed, 19 Dec 2012 18:08:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,321,1355058000"; d="scan'208,217";a="109188715" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 13:08:22 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6931"; a="154977373" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 13:08:22 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 20 Dec 2012 13:08:21 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 20 Dec 2012 13:08:20 +1100 Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sAAkEbRAAApz+pAAAl46sAAAXPvw Message-ID: <255B9BB34FB7D647A506DC292726F6E115042EDB85@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115042EDB0C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436697AEE2@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697AEE2@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115042EDB85WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:08:32 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115042EDB85WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgcHJlZml4IGZvciDigJxhbGfigJ0gdmFsdWVzIHdvdWxkIGhhdmUgZXhhY3RseSB0aGUg c2FtZSBwcm9wZXJ0eSBhcyBhZGRpbmcgYSBuZXcgaGVhZGVyIHBhcmFtZXRlci4gSWYgdGhlIG5l dyBhbGcgdmFsdWUgd2FzIG5vdCB1bmRlcnN0b29kLCB0aGUgSldTIHdvdWxkIGJlIHVzZWxlc3Mg dG8gdGhlIHJlY2VpdmVyLg0KDQpJIGFtIHZlcnkgY29uZmlkZW50IHRoYXQgZXZlcnkgKHJlYXNv bmFibGUpIEpPU0UgaW1wbGVtZW50YXRpb24gd2lsbCBub3RpY2UgdGhlIOKAnGFsZ+KAnSB2YWx1 ZSwgaWUgZmFpbC1zYWZlIG9uIGFuIHVucmVjb2duaXplZCDigJxhbGfigJ0gdmFsdWUuDQoNCj4g KEp1c3QgYXMgaXQgd291bGQgYmUgdXNlbGVzcyBpZiBhIG5ldyBoZWFkZXIgdmFsdWUgd2FzIHVz ZWQsIGlmIG5vdCB1bmRlcnN0b29kLikgIEnigJltIG5vdCBzdXJlIHdoeSB0aGUgZm9ybWVyIGlz IGFueSBtb3JlIHVzYWJsZSB0aGFuIHRoZSBsYXR0ZXIuDQoNCkkgaGF2ZSBmYXIgZmFyIGxlc3Mg Y29uZmlkZW5jZSB0aGF0IGV2ZXJ5IChyZWFzb25hYmxlKSBKT1NFIGltcGxlbWVudGF0aW9uIHdp bGwgbm90aWNlIGFuIHVuZXhwZWN0ZWQgZmllbGQsIHBhcnRpY3VsYXJseSBhIGtub3duIGZpZWxk IGluIGFuIHVuZXhwZWN0ZWQgY29udGV4dC4NCg0KLS0NCkphbWVzIE1hbmdlcg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENo ZWVycywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkph bWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVy IDE5LCAyMDEyIDU6MzkgUE0NClRvOiBNaWtlIEpvbmVzOyBqb3NlQGlldGYub3JnPG1haWx0bzpq b3NlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtqb3NlXSBXaGV0aGVyIGltcGxlbWVudGF0aW9u cyBtdXN0IHVuZGVyc3RhbmQgYWxsIEpPU0UgaGVhZGVyIGZpZWxkcw0KDQo+IOKAnHppcOKAnSBp cyBhIHBlcmZlY3QgZXhhbXBsZSBvZiBpbmRpY2F0aW5nIGEgY2hhbmdlIG9mIHNlbWFudGljcyB3 aXRoIHRoZSBwcmVzZW5jZSBvZiBhIG5ldyBmaWVsZC4gIFRoZSBwcm9jZXNzaW5nIG9mIGEgSldF IHdpdGhvdXQgYSDigJx6aXDigJ0gZmllbGQgaXMgZGlmZmVyZW50IHRoYW4gdGhlIHByb2Nlc3Np bmcgb2YgaXQgd2l0aCBvbmUuICBBbiBpbXBsZW1lbnRhdGlvbiBtdXN0IHVuZGVyc3RhbmQgdGhl IGZpZWxkIHRvIHVzZSB0aGUgcmVzdWx0aW5nIEpXRS4gIFRoZSBzYW1lIHdvdWxkIGJlIHRydWUg b2YgYW55IEpXUyB0aGF0IHVzZWQgYSDigJx6aXDigJ0gZXh0ZW5zaW9uLg0KPg0KPiBJdCB3b3Vs ZCBuZXZlciBiZSBzYWZlIHRvIGlnbm9yZSB0aGlzIGZpZWxkLCB3aGV0aGVyIGRlZmluZWQgYXMg cGFydCBvZiB0aGUgYmFzZSBzcGVjLCBvciBkZWZpbmVkIGFzIGFuIGV4dGVuc2lvbiBsYXRlci4N Cg0KSSBhZ3JlZS4NCldoZW4gSSBsb29rZWQgYXQgYSBoYW5kZnVsIG9mIHB1YmxpY2x5IGF2YWls YWJsZSBKT1NFIGltcGxlbWVudGF0aW9ucyBxdWl0ZSBhIHdoaWxlIGFnbyBub25lIGVuZm9yY2Vk IHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZ+KAnSBydWxlIOKAlCBzbyBhIHppcC1m b3ItSldTIGV4dGVuc2lvbiB3b3VsZCBiZSBkYW5nZXJvdXMgZm9yIHRoZW0uIE9uZSBpbXBsZW1l bnRhdGlvbiBsYXRlciBhZGRlZCBjb2RlIHRvIGVuZm9yY2UgdGhlIHJ1bGUgdXNpbmcgb25lIGZp eGVkIGxpc3Qgb2YgYWxsIGhlYWRlciBmaWVsZHMgZGVmaW5lZCBpbiBKVyog4oCUIHNvIGEgemlw LWZvci1KV1MgZXh0ZW5zaW9uIHdvdWxkIGJlIGRhbmdlcm91cyBmb3IgdGhhdCB0b28uDQoNCldl IGtub3cgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBldmVyeXRoaW5n4oCdIHJ1bGUgbWFrZXMgaXQg aGFyZCB0byBkZXBsb3kgbm9uLWNyaXRpY2FsIGV4dGVuc2lvbnMuDQpJdCBzZWVtcyB0byBtZSB0 aGF0IHRoZSBydWxlIGFsc28gbWFrZXMgaXQgZGFuZ2Vyb3VzIHRvIGRlcGxveSBjcml0aWNhbCBl eHRlbnNpb25zLg0KQWJvdXQgdGhlIG9ubHkgc2FmZSB3YXkgdG8gZGVmaW5lIGEgY3JpdGljYWwg ZXh0ZW5zaW9uIHdpbGwgYmUgdG8gZGVmaW5lIGEgcHJlZml4IGZvciDigJxhbGfigJ0gdmFsdWVz IChlZyAiYWxnIjogInppcDtSU0ExXzUiKS4gSSBob3BlIHRoYXQgaXNu4oCZdCB0aGUgbW9zdCBw cmFjdGljYWwgb3B0aW9uIHdlIGxlYXZlIGZvciBhbnlvbmUgd2FudGluZyB0byBleHRlbmQgSk9T RS4NCg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_255B9BB34FB7D647A506DC292726F6E115042EDB85WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5N c29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNz PVdvcmRTZWN0aW9uMT48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGUgcHJlZml4IGZvciDigJxhbGfigJ0g dmFsdWVzIHdvdWxkIGhhdmUgZXhhY3RseSB0aGUgc2FtZSBwcm9wZXJ0eSBhcyBhZGRpbmcgYSBu ZXcgaGVhZGVyIHBhcmFtZXRlci4gSWYgdGhlIG5ldyBhbGcgdmFsdWUgd2FzIG5vdCB1bmRlcnN0 b29kLCB0aGUgSldTIHdvdWxkIGJlIHVzZWxlc3MgdG8gdGhlIHJlY2VpdmVyLjwvc3Bhbj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz5JIGFtIHZlcnkgY29uZmlkZW50IHRoYXQgZXZlcnkg KHJlYXNvbmFibGUpIEpPU0UgaW1wbGVtZW50YXRpb24gd2lsbCBub3RpY2UgdGhlIOKAnGFsZ+KA nSB2YWx1ZSwgaWUgZmFpbC1zYWZlIG9uIGFuIHVucmVjb2duaXplZCDigJxhbGfigJ0gdmFsdWUu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsg PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPihKdXN0IGFzIGl0 IHdvdWxkIGJlIHVzZWxlc3MgaWYgYSBuZXcgaGVhZGVyIHZhbHVlIHdhcyB1c2VkLCBpZiBub3Qg dW5kZXJzdG9vZC4pJm5ic3A7IEnigJltIG5vdCBzdXJlIHdoeSB0aGUgZm9ybWVyIGlzIGFueSBt b3JlIHVzYWJsZSB0aGFuIHRoZSBsYXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2NvbG9yOnJlZCc+SSBoYXZlIGZhciBmYXIgbGVzcyBjb25maWRlbmNlIHRoYXQgZXZl cnkgKHJlYXNvbmFibGUpIEpPU0UgaW1wbGVtZW50YXRpb24gd2lsbCBub3RpY2UgYW4gdW5leHBl Y3RlZCBmaWVsZCwgcGFydGljdWxhcmx5IGEga25vd24gZmllbGQgaW4gYW4gdW5leHBlY3RlZCBj b250ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nY29sb3I6cmVkJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnJlZCc+LS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2NvbG9yOnJlZCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1hbmdlciwgSmFtZXMgSCBbPGEgaHJl Zj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iPm1haWx0bzpKYW1lcy5I Lk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IERlY2VtYmVyIDE5LCAyMDEyIDU6MzkgUE08YnI+PGI+VG86PC9iPiBNaWtlIEpvbmVzOyA8YSBo cmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVj dDo8L2I+IFJFOiBbam9zZV0gV2hldGhlciBpbXBsZW1lbnRhdGlvbnMgbXVzdCB1bmRlcnN0YW5k IGFsbCBKT1NFIGhlYWRlciBmaWVsZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz4mZ3Q7IOKAnHppcOKAnSBpcyBhIHBlcmZlY3QgZXhhbXBsZSBvZiBpbmRpY2F0aW5n IGEgY2hhbmdlIG9mIHNlbWFudGljcyB3aXRoIHRoZSBwcmVzZW5jZSBvZiBhIG5ldyBmaWVsZC4m bmJzcDsgVGhlIHByb2Nlc3Npbmcgb2YgYSBKV0Ugd2l0aG91dCBhIOKAnHppcOKAnSBmaWVsZCBp cyBkaWZmZXJlbnQgdGhhbiB0aGUgcHJvY2Vzc2luZyBvZiBpdCB3aXRoIG9uZS4mbmJzcDsgQW4g aW1wbGVtZW50YXRpb24gbXVzdCB1bmRlcnN0YW5kIHRoZSBmaWVsZCB0byB1c2UgdGhlIHJlc3Vs dGluZyBKV0UuJm5ic3A7IFRoZSBzYW1lIHdvdWxkIGJlIHRydWUgb2YgYW55IEpXUyB0aGF0IHVz ZWQgYSDigJx6aXDigJ0gZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OyBJdCB3b3VsZCBuZXZlciBiZSBzYWZlIHRvIGln bm9yZSB0aGlzIGZpZWxkLCB3aGV0aGVyIGRlZmluZWQgYXMgcGFydCBvZiB0aGUgYmFzZSBzcGVj LCBvciBkZWZpbmVkIGFzIGFuIGV4dGVuc2lvbiBsYXRlci48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgYWdyZWUuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+V2hlbiBJIGxvb2tlZCBhdCBhIGhhbmRmdWwgb2YgcHVibGljbHkgYXZhaWxhYmxlIEpP U0UgaW1wbGVtZW50YXRpb25zIHF1aXRlIGEgd2hpbGUgYWdvIG5vbmUgZW5mb3JjZWQgdGhlIOKA nE1VU1QgdW5kZXJzdGFuZCBldmVyeXRoaW5n4oCdIHJ1bGUg4oCUIHNvIGEgemlwLWZvci1KV1Mg ZXh0ZW5zaW9uIHdvdWxkIGJlIGRhbmdlcm91cyBmb3IgdGhlbS4gT25lIGltcGxlbWVudGF0aW9u IGxhdGVyIGFkZGVkIGNvZGUgdG8gZW5mb3JjZSB0aGUgcnVsZSB1c2luZyBvbmUgZml4ZWQgbGlz dCBvZiBhbGwgaGVhZGVyIGZpZWxkcyBkZWZpbmVkIGluIEpXKiDigJQgc28gYSB6aXAtZm9yLUpX UyBleHRlbnNpb24gd291bGQgYmUgZGFuZ2Vyb3VzIGZvciB0aGF0IHRvby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5XZSBrbm93IHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGlu Z+KAnSBydWxlIG1ha2VzIGl0IGhhcmQgdG8gZGVwbG95IG5vbi1jcml0aWNhbCBleHRlbnNpb25z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHJ1bGUgYWxzbyBtYWtlcyBpdCBk YW5nZXJvdXMgdG8gZGVwbG95IGNyaXRpY2FsIGV4dGVuc2lvbnMuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QWJvdXQg dGhlIG9ubHkgc2FmZSB3YXkgdG8gZGVmaW5lIGEgY3JpdGljYWwgZXh0ZW5zaW9uIHdpbGwgYmUg dG8gZGVmaW5lIGEgcHJlZml4IGZvciDigJxhbGfigJ0gdmFsdWVzIChlZyAmcXVvdDthbGcmcXVv dDs6ICZxdW90O3ppcDtSU0ExXzUmcXVvdDspLiBJIGhvcGUgdGhhdCBpc27igJl0IHRoZSBtb3N0 IHByYWN0aWNhbCBvcHRpb24gd2UgbGVhdmUgZm9yIGFueW9uZSB3YW50aW5nIHRvIGV4dGVuZCBK T1NFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5KYW1l cyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5Pjwv aHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E115042EDB85WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Wed Dec 19 18:12:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BF721F858C for ; Wed, 19 Dec 2012 18:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-tHxSPHuMVX for ; Wed, 19 Dec 2012 18:12:42 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 99D7721F84DE for ; Wed, 19 Dec 2012 18:12:42 -0800 (PST) Received: from BY2FFO11FD007.protection.gbl (10.1.15.203) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 02:12:40 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 02:12:40 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 02:12:03 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sAAkEbRAAApz+pAAAl46sAAAXPvwAABfavA= Date: Thu, 20 Dec 2012 02:12:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436697B301@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115042EDB0C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436697AEE2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115042EDB85@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115042EDB85@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_4E1F6AAD24975D4BA5B16804296739436697B301TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(44976002)(74662001)(15202345001)(74502001)(47446002)(49866001)(31966008)(16236675001)(50986001)(51856001)(47976001)(4396001)(56816002)(47736001)(53806001)(77982001)(76482001)(59766001)(55846006)(5343655001)(16406001)(46102001)(5343635001)(512874001)(33656001)(54356001)(56776001)(54316002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07013D7479 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:12:43 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436697B301TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2gsIGJ1dCBJIGFtIGFsc28gdmVyeSBjb25maWRlbnQgdGhhdCBldmVyeSBpbXBs ZW1lbnRhdGlvbiB0cnlpbmcgdG8gdXNlIGEgY29tcHJlc3NlZCBwYXlsb2FkIHdoZXJlIGl0IHdh cyBleHBlY3RpbmcgYW4gdW5jb21wcmVzc2VkIG9uZSB3b3VsZCBxdWlja2x5IG5vdGljZSB0aGUg ZGlmZmVyZW5jZSBhbmQgdGhlbiBkbyB3aGF0IGl0IHRha2VzIHRvIGdldCB0aGVpciBpbXBsZW1l bnRhdGlvbiBmaXhlZC91cGRhdGVkLiDimLoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYW5nZXIs IEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KU2VudDog V2VkbmVzZGF5LCBEZWNlbWJlciAxOSwgMjAxMiA2OjA4IFBNDQpUbzogTWlrZSBKb25lczsgam9z ZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtqb3NlXSBXaGV0aGVyIGltcGxlbWVudGF0aW9ucyBt dXN0IHVuZGVyc3RhbmQgYWxsIEpPU0UgaGVhZGVyIGZpZWxkcw0KDQo+IFRoZSBwcmVmaXggZm9y IOKAnGFsZ+KAnSB2YWx1ZXMgd291bGQgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIHByb3BlcnR5IGFz IGFkZGluZyBhIG5ldyBoZWFkZXIgcGFyYW1ldGVyLiBJZiB0aGUgbmV3IGFsZyB2YWx1ZSB3YXMg bm90IHVuZGVyc3Rvb2QsIHRoZSBKV1Mgd291bGQgYmUgdXNlbGVzcyB0byB0aGUgcmVjZWl2ZXIu DQoNCkkgYW0gdmVyeSBjb25maWRlbnQgdGhhdCBldmVyeSAocmVhc29uYWJsZSkgSk9TRSBpbXBs ZW1lbnRhdGlvbiB3aWxsIG5vdGljZSB0aGUg4oCcYWxn4oCdIHZhbHVlLCBpZSBmYWlsLXNhZmUg b24gYW4gdW5yZWNvZ25pemVkIOKAnGFsZ+KAnSB2YWx1ZS4NCg0KPiAoSnVzdCBhcyBpdCB3b3Vs ZCBiZSB1c2VsZXNzIGlmIGEgbmV3IGhlYWRlciB2YWx1ZSB3YXMgdXNlZCwgaWYgbm90IHVuZGVy c3Rvb2QuKSAgSeKAmW0gbm90IHN1cmUgd2h5IHRoZSBmb3JtZXIgaXMgYW55IG1vcmUgdXNhYmxl IHRoYW4gdGhlIGxhdHRlci4NCg0KSSBoYXZlIGZhciBmYXIgbGVzcyBjb25maWRlbmNlIHRoYXQg ZXZlcnkgKHJlYXNvbmFibGUpIEpPU0UgaW1wbGVtZW50YXRpb24gd2lsbCBub3RpY2UgYW4gdW5l eHBlY3RlZCBmaWVsZCwgcGFydGljdWxhcmx5IGEga25vd24gZmllbGQgaW4gYW4gdW5leHBlY3Rl ZCBjb250ZXh0Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogTWFuZ2VyLCBKYW1lcyBIIFttYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTksIDIwMTIgNTozOSBQ TQ0KVG86IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSRTogW2pvc2VdIFdoZXRoZXIgaW1wbGVtZW50YXRpb25zIG11c3QgdW5kZXJzdGFu ZCBhbGwgSk9TRSBoZWFkZXIgZmllbGRzDQoNCj4g4oCcemlw4oCdIGlzIGEgcGVyZmVjdCBleGFt cGxlIG9mIGluZGljYXRpbmcgYSBjaGFuZ2Ugb2Ygc2VtYW50aWNzIHdpdGggdGhlIHByZXNlbmNl IG9mIGEgbmV3IGZpZWxkLiAgVGhlIHByb2Nlc3Npbmcgb2YgYSBKV0Ugd2l0aG91dCBhIOKAnHpp cOKAnSBmaWVsZCBpcyBkaWZmZXJlbnQgdGhhbiB0aGUgcHJvY2Vzc2luZyBvZiBpdCB3aXRoIG9u ZS4gIEFuIGltcGxlbWVudGF0aW9uIG11c3QgdW5kZXJzdGFuZCB0aGUgZmllbGQgdG8gdXNlIHRo ZSByZXN1bHRpbmcgSldFLiAgVGhlIHNhbWUgd291bGQgYmUgdHJ1ZSBvZiBhbnkgSldTIHRoYXQg dXNlZCBhIOKAnHppcOKAnSBleHRlbnNpb24uDQo+DQo+IEl0IHdvdWxkIG5ldmVyIGJlIHNhZmUg dG8gaWdub3JlIHRoaXMgZmllbGQsIHdoZXRoZXIgZGVmaW5lZCBhcyBwYXJ0IG9mIHRoZSBiYXNl IHNwZWMsIG9yIGRlZmluZWQgYXMgYW4gZXh0ZW5zaW9uIGxhdGVyLg0KDQpJIGFncmVlLg0KV2hl biBJIGxvb2tlZCBhdCBhIGhhbmRmdWwgb2YgcHVibGljbHkgYXZhaWxhYmxlIEpPU0UgaW1wbGVt ZW50YXRpb25zIHF1aXRlIGEgd2hpbGUgYWdvIG5vbmUgZW5mb3JjZWQgdGhlIOKAnE1VU1QgdW5k ZXJzdGFuZCBldmVyeXRoaW5n4oCdIHJ1bGUg4oCUIHNvIGEgemlwLWZvci1KV1MgZXh0ZW5zaW9u IHdvdWxkIGJlIGRhbmdlcm91cyBmb3IgdGhlbS4gT25lIGltcGxlbWVudGF0aW9uIGxhdGVyIGFk ZGVkIGNvZGUgdG8gZW5mb3JjZSB0aGUgcnVsZSB1c2luZyBvbmUgZml4ZWQgbGlzdCBvZiBhbGwg aGVhZGVyIGZpZWxkcyBkZWZpbmVkIGluIEpXKiDigJQgc28gYSB6aXAtZm9yLUpXUyBleHRlbnNp b24gd291bGQgYmUgZGFuZ2Vyb3VzIGZvciB0aGF0IHRvby4NCg0KV2Uga25vdyB0aGUg4oCcTVVT VCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcnVsZSBtYWtlcyBpdCBoYXJkIHRvIGRlcGxveSBu b24tY3JpdGljYWwgZXh0ZW5zaW9ucy4NCkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHJ1bGUgYWxz byBtYWtlcyBpdCBkYW5nZXJvdXMgdG8gZGVwbG95IGNyaXRpY2FsIGV4dGVuc2lvbnMuDQpBYm91 dCB0aGUgb25seSBzYWZlIHdheSB0byBkZWZpbmUgYSBjcml0aWNhbCBleHRlbnNpb24gd2lsbCBi ZSB0byBkZWZpbmUgYSBwcmVmaXggZm9yIOKAnGFsZ+KAnSB2YWx1ZXMgKGVnICJhbGciOiAiemlw O1JTQTFfNSIpLiBJIGhvcGUgdGhhdCBpc27igJl0IHRoZSBtb3N0IHByYWN0aWNhbCBvcHRpb24g d2UgbGVhdmUgZm9yIGFueW9uZSB3YW50aW5nIHRvIGV4dGVuZCBKT1NFLg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQo= --_000_4E1F6AAD24975D4BA5B16804296739436697B301TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQ bGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZhaXIgZW5vdWdoLCBidXQgSSBhbSBhbHNvIHZlcnkg Y29uZmlkZW50IHRoYXQgZXZlcnkgaW1wbGVtZW50YXRpb24gdHJ5aW5nIHRvIHVzZSBhIGNvbXBy ZXNzZWQgcGF5bG9hZCB3aGVyZSBpdCB3YXMgZXhwZWN0aW5nIGFuIHVuY29tcHJlc3NlZCBvbmUg d291bGQgcXVpY2tseSBub3RpY2UgdGhlIGRpZmZlcmVuY2UgYW5kIHRoZW4gZG8gd2hhdCBpdCB0 YWtlcw0KIHRvIGdldCB0aGVpciBpbXBsZW1lbnRhdGlvbiBmaXhlZC91cGRhdGVkLiA8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFuZ2VyLCBKYW1lcyBIIFttYWls dG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIERlY2VtYmVyIDE5LCAyMDEyIDY6MDggUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2Ug Sm9uZXM7IGpvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtqb3NlXSBXaGV0 aGVyIGltcGxlbWVudGF0aW9ucyBtdXN0IHVuZGVyc3RhbmQgYWxsIEpPU0UgaGVhZGVyIGZpZWxk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0OyBUaGUgcHJl Zml4IGZvciDigJxhbGfigJ0gdmFsdWVzIHdvdWxkIGhhdmUgZXhhY3RseSB0aGUgc2FtZSBwcm9w ZXJ0eSBhcyBhZGRpbmcgYSBuZXcgaGVhZGVyIHBhcmFtZXRlci4gSWYgdGhlIG5ldyBhbGcgdmFs dWUgd2FzIG5vdCB1bmRlcnN0b29kLCB0aGUgSldTIHdvdWxkIGJlIHVzZWxlc3MgdG8gdGhlIHJl Y2VpdmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5JIGFtIHZlcnkgY29uZmlk ZW50IHRoYXQgZXZlcnkgKHJlYXNvbmFibGUpIEpPU0UgaW1wbGVtZW50YXRpb24gd2lsbCBub3Rp Y2UgdGhlIOKAnGFsZ+KAnSB2YWx1ZSwgaWUgZmFpbC1zYWZlIG9uIGFuIHVucmVjb2duaXplZCDi gJxhbGfigJ0gdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7 IChKdXN0IGFzIGl0IHdvdWxkIGJlIHVzZWxlc3MgaWYgYSBuZXcgaGVhZGVyIHZhbHVlIHdhcyB1 c2VkLCBpZiBub3QgdW5kZXJzdG9vZC4pJm5ic3A7IEnigJltIG5vdCBzdXJlIHdoeSB0aGUgZm9y bWVyIGlzIGFueSBtb3JlIHVzYWJsZSB0aGFuIHRoZSBsYXR0ZXIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpyZWQiPkkgaGF2ZSBmYXIgZmFyIGxlc3MgY29uZmlkZW5jZSB0aGF0IGV2ZXJ5 IChyZWFzb25hYmxlKSBKT1NFIGltcGxlbWVudGF0aW9uIHdpbGwgbm90aWNlIGFuIHVuZXhwZWN0 ZWQgZmllbGQsIHBhcnRpY3VsYXJseSBhIGtub3duIGZpZWxkIGluIGFuIHVuZXhwZWN0ZWQgY29u dGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkphbWVzIE1h bmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IE1hbmdlciwgSmFtZXMgSCBbPGEgaHJlZj0ibWFpbHRvOkphbWVzLkgu TWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iPm1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0 cmEuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVyIDE5LCAy MDEyIDU6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IDxhIGhyZWY9Im1haWx0bzpq b3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W2pvc2VdIFdoZXRoZXIgaW1wbGVtZW50YXRpb25zIG11c3QgdW5kZXJzdGFuZCBhbGwgSk9TRSBo ZWFkZXIgZmllbGRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDsg4oCcemlw4oCdIGlzIGEgcGVyZmVj dCBleGFtcGxlIG9mIGluZGljYXRpbmcgYSBjaGFuZ2Ugb2Ygc2VtYW50aWNzIHdpdGggdGhlIHBy ZXNlbmNlIG9mIGEgbmV3IGZpZWxkLiZuYnNwOyBUaGUgcHJvY2Vzc2luZyBvZiBhIEpXRSB3aXRo b3V0IGEg4oCcemlw4oCdIGZpZWxkIGlzIGRpZmZlcmVudCB0aGFuIHRoZSBwcm9jZXNzaW5nIG9m IGl0IHdpdGggb25lLiZuYnNwOyBBbiBpbXBsZW1lbnRhdGlvbg0KIG11c3QgdW5kZXJzdGFuZCB0 aGUgZmllbGQgdG8gdXNlIHRoZSByZXN1bHRpbmcgSldFLiZuYnNwOyBUaGUgc2FtZSB3b3VsZCBi ZSB0cnVlIG9mIGFueSBKV1MgdGhhdCB1c2VkIGEg4oCcemlw4oCdIGV4dGVuc2lvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7IEl0IHdvdWxkIG5ldmVyIGJl IHNhZmUgdG8gaWdub3JlIHRoaXMgZmllbGQsIHdoZXRoZXIgZGVmaW5lZCBhcyBwYXJ0IG9mIHRo ZSBiYXNlIHNwZWMsIG9yIGRlZmluZWQgYXMgYW4gZXh0ZW5zaW9uIGxhdGVyLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFV IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hlbiBJIGxvb2tlZCBhdCBhIGhhbmRmdWwgb2YgcHVi bGljbHkgYXZhaWxhYmxlIEpPU0UgaW1wbGVtZW50YXRpb25zIHF1aXRlIGEgd2hpbGUgYWdvIG5v bmUgZW5mb3JjZWQgdGhlIOKAnE1VU1QgdW5kZXJzdGFuZCBldmVyeXRoaW5n4oCdIHJ1bGUg4oCU IHNvIGEgemlwLWZvci1KV1MgZXh0ZW5zaW9uIHdvdWxkIGJlIGRhbmdlcm91cyBmb3IgdGhlbS4N CiBPbmUgaW1wbGVtZW50YXRpb24gbGF0ZXIgYWRkZWQgY29kZSB0byBlbmZvcmNlIHRoZSBydWxl IHVzaW5nIG9uZSBmaXhlZCBsaXN0IG9mIGFsbCBoZWFkZXIgZmllbGRzIGRlZmluZWQgaW4gSlcq IOKAlCBzbyBhIHppcC1mb3ItSldTIGV4dGVuc2lvbiB3b3VsZCBiZSBkYW5nZXJvdXMgZm9yIHRo YXQgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5XZSBrbm93IHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZ+KA nSBydWxlIG1ha2VzIGl0IGhhcmQgdG8gZGVwbG95IG5vbi1jcml0aWNhbCBleHRlbnNpb25zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgcnVsZSBh bHNvIG1ha2VzIGl0IGRhbmdlcm91cyB0byBkZXBsb3kgY3JpdGljYWwgZXh0ZW5zaW9ucy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1B VSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFib3V0IHRoZSBvbmx5IHNhZmUgd2F5IHRvIGRlZmlu ZSBhIGNyaXRpY2FsIGV4dGVuc2lvbiB3aWxsIGJlIHRvIGRlZmluZSBhIHByZWZpeCBmb3Ig4oCc YWxn4oCdIHZhbHVlcyAoZWcgJnF1b3Q7YWxnJnF1b3Q7OiAmcXVvdDt6aXA7UlNBMV81JnF1b3Q7 KS4gSSBob3BlIHRoYXQgaXNu4oCZdCB0aGUgbW9zdCBwcmFjdGljYWwgb3B0aW9uIHdlIGxlYXZl IGZvciBhbnlvbmUgd2FudGluZw0KIHRvIGV4dGVuZCBKT1NFLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1B VSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739436697B301TK5EX14MBXC283r_-- From djc.ochtman@gmail.com Wed Dec 19 23:47:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BDA21F8A87 for ; Wed, 19 Dec 2012 23:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df0O3zEozByn for ; Wed, 19 Dec 2012 23:47:22 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id ACC3721F8A85 for ; Wed, 19 Dec 2012 23:47:22 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id r4so4972608qaq.5 for ; Wed, 19 Dec 2012 23:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TFV2Wue9TBtClyUaaBRKvs9HnZQCIMNhwTmdgV0dDrM=; b=nFxcPNQf/rzng0ovriyLvICleDOWRmEa8aPZkwRw/lCy2wXo0DO5r8LGRcRzGHirdL wv3DY2SEkM9sGkjnnuItzxn4J/6hwi80EffL8bBeYobF1DTxcYfDDlmRarwvb6l0l0MX y4x0g30SFqevgOl8DCrLMKTcb2gPrv6eSLv/VYvWSFSWwUS+cel+j46ZugK8YaqJa54x y6QQkvKGx5KAeM6IrIUZFZN4mUOfZdlTUt1r8iIl9Kv0DtEs5gZAf+0gL0/6QPcZkWlZ GF8KA+4pCs97JWuQfAgMDiJoC8F5BtseRK8l1YRiGMgXXwab2o/pdIfGTRN4PHxrcDhs Gm2Q== Received: by 10.49.96.1 with SMTP id do1mr4768936qeb.26.1355989642124; Wed, 19 Dec 2012 23:47:22 -0800 (PST) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.49.1.17 with HTTP; Wed, 19 Dec 2012 23:47:02 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697B301@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115042EDB0C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436697AEE2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115042EDB85@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436697B301@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Dirkjan Ochtman Date: Thu, 20 Dec 2012 08:47:02 +0100 X-Google-Sender-Auth: bXeC4wAuiIcFcFtH6QGdazSZ2Rc Message-ID: To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 07:47:23 -0000 Yeah, that makes sense to me. Also, even having a small set of must-understand fields (alg and zip and maybe 1 or 2 others) is very different from having a must-understand-all policy. Cheers, Dirkjan On Thu, Dec 20, 2012 at 3:12 AM, Mike Jones w= rote: > Fair enough, but I am also very confident that every implementation tryin= g > to use a compressed payload where it was expecting an uncompressed one wo= uld > quickly notice the difference and then do what it takes to get their > implementation fixed/updated. J > > > > -- Mike > > > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Wednesday, December 19, 2012 6:08 PM > > > To: Mike Jones; jose@ietf.org > Subject: RE: [jose] Whether implementations must understand all JOSE head= er > fields > > > >> The prefix for =E2=80=9Calg=E2=80=9D values would have exactly the same = property as adding >> a new header parameter. If the new alg value was not understood, the JWS >> would be useless to the receiver. > > > > I am very confident that every (reasonable) JOSE implementation will noti= ce > the =E2=80=9Calg=E2=80=9D value, ie fail-safe on an unrecognized =E2=80= =9Calg=E2=80=9D value. > > > >> (Just as it would be useless if a new header value was used, if not >> understood.) I=E2=80=99m not sure why the former is any more usable tha= n the >> latter. > > > > I have far far less confidence that every (reasonable) JOSE implementatio= n > will notice an unexpected field, particularly a known field in an unexpec= ted > context. > > > > -- > > James Manger > > Cheers, > > -- Mike > > > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Wednesday, December 19, 2012 5:39 PM > To: Mike Jones; jose@ietf.org > Subject: RE: [jose] Whether implementations must understand all JOSE head= er > fields > > > >> =E2=80=9Czip=E2=80=9D is a perfect example of indicating a change of sem= antics with the >> presence of a new field. The processing of a JWE without a =E2=80=9Czip= =E2=80=9D field is >> different than the processing of it with one. An implementation must >> understand the field to use the resulting JWE. The same would be true o= f >> any JWS that used a =E2=80=9Czip=E2=80=9D extension. > >> > >> It would never be safe to ignore this field, whether defined as part of >> the base spec, or defined as an extension later. > > > > I agree. > > When I looked at a handful of publicly available JOSE implementations qui= te > a while ago none enforced the =E2=80=9CMUST understand everything=E2=80= =9D rule =E2=80=94 so a > zip-for-JWS extension would be dangerous for them. One implementation lat= er > added code to enforce the rule using one fixed list of all header fields > defined in JW* =E2=80=94 so a zip-for-JWS extension would be dangerous fo= r that too. > > > > We know the =E2=80=9CMUST understand everything=E2=80=9D rule makes it ha= rd to deploy > non-critical extensions. > > It seems to me that the rule also makes it dangerous to deploy critical > extensions. > > About the only safe way to define a critical extension will be to define = a > prefix for =E2=80=9Calg=E2=80=9D values (eg "alg": "zip;RSA1_5"). I hope = that isn=E2=80=99t the most > practical option we leave for anyone wanting to extend JOSE. > > > > -- > > James Manger > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From tonynad@microsoft.com Thu Dec 20 10:08:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7546B21F8473 for ; Thu, 20 Dec 2012 10:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.784 X-Spam-Level: * X-Spam-Status: No, score=1.784 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr93V75AZnSc for ; Thu, 20 Dec 2012 10:08:39 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3D21F8419 for ; Thu, 20 Dec 2012 10:08:39 -0800 (PST) Received: from BL2FFO11FD006.protection.gbl (10.173.161.202) by BL2FFO11HUB017.protection.gbl (10.173.160.109) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 18:08:36 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 18:08:35 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 20 Dec 2012 18:08:14 +0000 Received: from mail187-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Dec 2012 18:07:08 +0000 Received: from mail187-va3 (localhost [127.0.0.1]) by mail187-va3-R.bigfish.com (Postfix) with ESMTP id 0B8AA32015B for ; Thu, 20 Dec 2012 18:07:08 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371Id6eah148cI542I1432Izz1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h9a9j1155h) Received-SPF: softfail (mail187-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB041; LANG:en; Received: from mail187-va3 (localhost.localdomain [127.0.0.1]) by mail187-va3 (MessageSwitch) id 1356026825675612_17501; Thu, 20 Dec 2012 18:07:05 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.254]) by mail187-va3.bigfish.com (Postfix) with ESMTP id 8C47640091; Thu, 20 Dec 2012 18:07:05 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Dec 2012 18:07:05 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 20 Dec 2012 18:07:05 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 18:06:53 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Thu, 20 Dec 2012 18:06:53 +0000 From: Anthony Nadalin To: Dick Hardt Thread-Topic: [jose] Reducing the size of JWS payloads Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgAAqR2AAAQEvdAAGR1xAAA1UCtQ Date: Thu, 20 Dec 2012 18:06:52 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <79f178fcdba34e6ea83635761d795178@BY2PR03MB041.namprd03.prod.outlook.com> <9F135913-1D88-4842-B51E-C584D4510BF9@gmail.com> In-Reply-To: <9F135913-1D88-4842-B51E-C584D4510BF9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(52604002)(377454001)(51704002)(24454001)(23726001)(51856001)(54356001)(59766001)(550184003)(54316002)(46406002)(6806001)(15202345001)(56776001)(31966008)(44976002)(33646001)(77982001)(74662001)(74502001)(47446002)(56816002)(49866001)(5343655001)(47736001)(16676001)(50466001)(4396001)(76482001)(50986001)(46102001)(47776002)(5343635001)(53806001)(47976001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB017; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07013D7479 Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Reducing the size of JWS payloads X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:08:40 -0000 Your defining a new algorithm and not allowing ability to use others that m= ay prefer the integrity check -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Wednesday, December 19, 2012 8:39 AM To: Anthony Nadalin Cc: Dick Hardt; Mike Jones; jose@ietf.org Subject: Re: [jose] Reducing the size of JWS payloads What "flexability" does it not allow? Seems more flexible to me.=20 On Dec 18, 2012, at 8:42 PM, Anthony Nadalin wrote: > This forces a specific way and does not allow the flexability >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of D= ick Hardt > Sent: Tuesday, December 18, 2012 6:45 PM > To: Mike Jones > Cc: jose@ietf.org; Dick Hardt > Subject: Re: [jose] Reducing the size of JWS payloads >=20 > Hi Mike >=20 > Thanks for bringing this up again.=20 >=20 > An alternative approach I proposed was to have both the encryption and si= gning information in one header, and to use the signing signature to ensure= integrity instead of having a separate encryption integrity check. This wo= uld reduce the size of the token by the size of the integrity value +1 byte= s, as well as reduce the processing. >=20 > Given that header properties are overloaded now (they have different mean= ings depending on being a JWE or JWS, we could put the encryption header va= lues into a sub object in the header. Perhaps call that 'enc'. >=20 > -- Dick >=20 > The process below has=20 > On Dec 18, 2012, at 6:26 PM, Mike Jones wro= te: >=20 >> I've noticed that more than one person has expressed a desire to reduce = the size of JWS payloads before signing. This especially comes up when nes= ted encryption and signing is being performed. This note contains a quanti= tative evaluation of some possible methods of reducing JWS payload size and= asks for working group input based upon the data. >>=20 >> Dick proposed one method below - have a header parameter to say that the= payload is already URL-safe and that base64url encoding is not to be perfo= rmed. Another way that people have proposed is to allow the use of the "zi= p" parameter to compress the JWS payload before base64url encoding. To get= some initial data on how the solutions compare, I tried both methods using= the sample JWE value in http://tools.ietf.org/html/draft-ietf-jose-json-we= b-encryption-07#appendix-A.2 as the JWS payload. >>=20 >> CURRENT SITUATION: The JWE is 526 characters in length. Currently, whe= n used as a JWS payload, base64url encoding it would increase its size to 7= 02 characters - an increase of 33% or 176 characters. >>=20 >> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter "b64"= :false to indicate that no additional base64url encoding is to be performed= , the payload would be 176 characters smaller than the current situation. = The encoded header size would increase by 16 characters - the number of cha= racters needed to base64url encode this header parameter value and a comma,= for a net decrease in size of 160 characters. (Yes, parsing the three pie= ces would be slightly more difficult.) >>=20 >> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on th= is input results in a LARGER output - 536 bytes or a net increase of 10 byt= es. If you think about it, this isn't too surprising, as the encrypted dat= a should contain no usable predictability/redundancy. Base64url encoding t= hese 536 bytes results in a 715 character payload - an increase of 189 char= acters or 36%. Plus, adding "zip":"DEF" to the header adds 16 characters, = for a total increase of 29 characters over the current situation. Clearly = a suboptimal choice! >>=20 >> CONCLUSION: Clearly, if we're going to enable reduction of the size of = JWS payloads, avoiding the double base64url encoding is preferable to zip, = which actually makes things worse. >>=20 >> QUESTION TO WORKING GROUP: I'm curious whether people would like to see= us enable avoiding double base64encoding of JWS payloads when they are alr= eady URL-safe. The space savings are significant; they come at the cost of= the JWS parsing becoming [part before first period . part between first an= d last period . part after last period] rather than the current [part befor= e first period . part between first and second period . part after second p= eriod (with no other periods allowed)]. Opinions? >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Dick Hardt >> Sent: Monday, October 29, 2012 8:57 AM >> To: jose@ietf.org >> Subject: [jose] signing an existing JWT >>=20 >>=20 >> Let's say we have created a JWE as such: >> =09 >> headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integri= tityVectorOne >>=20 >> This is now the payload to a JWS. Rather than increasing the token size = by 4/3 by URL safe base 64 encoding the payload (since it is already URL sa= fe), it would be useful to have a JWS header parameter that indicates the p= ayload was not re-encoded and does not need to be URL safe base 64 decoded. >>=20 >> As there are more periods than expected in a JWS, decoding would ignore = all periods except the first and last one for separating out the header, pa= yload and signature. >>=20 >> The indicating parameter would seem to be either "tip" or "cty". I'm sti= ll confused about the difference between the two parameters, so not sure wh= ich one is appropriate. >>=20 >> -- Dick >>=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 >=20 >=20 >=20 From ietf@augustcellars.com Wed Dec 26 14:03:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B86721F8D0B for ; Wed, 26 Dec 2012 14:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZZxzaf1TLn3 for ; Wed, 26 Dec 2012 14:03:02 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9A40D21F8CE0 for ; Wed, 26 Dec 2012 14:03:02 -0800 (PST) Received: from Philemon (unknown [64.122.12.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id C0DB638EFD; Wed, 26 Dec 2012 14:03:01 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 26 Dec 2012 14:02:46 -0800 Message-ID: <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CDE371.AF2639E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu1NOwxvsFfhrE3kb42icQdthreZdpv7Gw Content-Language: en-us Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 22:03:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01CDE371.AF2639E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This does not include my recommended approach which is to punt the issue of required headers to the application rather than JOSE. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fields Currently the JOSE specs contain the following language declaring that all header (and some other) fields must be understood: "Implementations MUST understand the entire contents of the header; otherwise, the . MUST be rejected." There's currently an open issue about whether all header fields should be required to be understood by implementations using them or whether to relax this requirement in some circumstances. We would like the working group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be understood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties understand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be understood, but where an explicit list of fields can be designated as "may be ignored if not understood". For instance, an "ign" (may be ignored) member could be defined whose value is an array listing the member names that may be safely ignored if not understood. An example using this field in a JWS header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking implementations. It would maintain the current semantics, while allowing explicit exceptions to be made in cases where the fields are not security-critical and the structure has a meaningful interpretation without them. Representations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding some implementation complexity. 2B. Take an alternative approach where instead of one header object, there would be two header objects. Implementations would be required to understand all fields in the first header object. Implementations would be allowed to ignore fields in the second header object if not understood. An example of this approach, adding the second header object after the first in a JWS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9v biBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9p c19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current spec. The new second field is the base64url encoded representation of the string '{"notes":"This signature need not be checked when the moon is full"}'. PRO: May-be-ignored fields are easily distinguishable from must-be-understood fields. CON: Implementations must consult/merge two sets of headers to understand the meaning/structure of the object, adding some implementation complexity. Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chairs to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to understand? YES - All header fields must continue to be understood by implementations or the input must be rejected. NO - A means of listing that specific header fields may be safely ignored should be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax would you prefer for designating the header fields that may be ignored if not understood? A - Define a header field that explicitly lists the fields that may be safely ignored if not understood. B - Introduce a second header, where implementations must understand all fields in the first but they may ignore not-understood fields in the second. Thanks for considering these questions, Richard Barnes, John Bradley, Mike Jones ------=_NextPart_000_002E_01CDE371.AF2639E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This does not include my recommended approach = which is to punt the issue of required headers to the application rather = than JOSE.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Friday, December 14, 2012 10:17 = AM
To: jose@ietf.org
Subject: [jose] Whether = implementations must understand all JOSE header = fields

 

Currently = the JOSE specs contain the following language declaring that all header = (and some other) fields must be understood:  “Implementations = MUST understand the entire contents of the header; otherwise, the = … MUST be rejected.”  There's currently an open issue = about whether all header fields should be required to be understood by = implementations using them or whether to relax this requirement in some = circumstances.  We would like the working group to consider the = following potential resolutions to the issue.

 

1.  Maintain the current requirement that all = header fields must be understood by implementations using = them.

 

PRO:  This is a simple rule designed to result = in secure implementations.  Representations of existing JWS & = JWE objects are unchanged.

CON:  Extensibility is limited to cases where = all participating parties understand new fields that are = introduced.

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of = fields can be designated as “may be ignored if not = understood”.  For instance, an “ign” (may be = ignored) member could be defined whose value is an array listing the = member names that may be safely ignored if not understood.  An = example using this field in a JWS header is:

 

    = {"alg":"ES256",

     = "ign":["notes"],

     = "notes":"This signature need not be checked when the moon = is full"

    = }

 

(Obviously, the "ign" field MUST NOT = contain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain = the current semantics, while allowing explicit exceptions to be made in = cases where the fields are not security-critical and the structure has a = meaningful interpretation without them.  Representations of = existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names and = may-be-ignored list, adding some implementation = complexity.

 

2B.  Take an alternative approach where = instead of one header object, there would be two header objects.  = Implementations would be required to understand all fields in the first = header object.  Implementations would be allowed to ignore fields = in the second header object if not understood.  An example of this = approach, adding the second header object after the first in a JWS, = would be:

 

    = eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

    .

    = eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgb= W9vbiBpcyBmdWxsIn0

    .

    = eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvb= S9pc19yb290Ijp0cnVlfQ

    .

    = dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

 

The = first, third, and fourth fields are from the example JWS in the current = spec. The new second field is the base64url encoded representation of = the string '{"notes":"This signature need not be checked = when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily = distinguishable from must-be-understood fields.

CON:  Implementations must consult/merge two = sets of headers to understand the meaning/structure of the object, = adding some implementation complexity.  Existing JWS & JWE = object representations would become invalid.

 

After = a discussion period, we believe that it would be useful for the chairs = to make two formal consensus calls of the following = kind:

 

FIRST POLL:  Should all header fields be = critical for implementations to understand?

YES – All header fields must continue to be = understood by implementations or the input must be = rejected.

NO – A means of = listing that specific header fields may be safely ignored should be = defined.

 

SECOND POLL:  Should the result of the first = poll be "NO", which syntax would you prefer for designating = the header fields that may be ignored if not = understood?

A – Define a = header field that explicitly lists the fields that may be safely ignored = if not understood.

B – = Introduce a second header, where implementations must understand all = fields in the first but they may ignore not-understood fields in the = second.

 

        =             &= nbsp;           &n= bsp;           &nb= sp;   Thanks for considering these = questions,

        &nbs= p;            = ;            =             &= nbsp;  Richard Barnes, John Bradley, Mike Jones

 

 

------=_NextPart_000_002E_01CDE371.AF2639E0-- From Michael.Jones@microsoft.com Wed Dec 26 14:32:13 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1959B21F8D0D for ; Wed, 26 Dec 2012 14:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3nJiiK6jNwq for ; Wed, 26 Dec 2012 14:32:09 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id F3CD421F8D10 for ; Wed, 26 Dec 2012 14:32:08 -0800 (PST) Received: from BL2FFO11FD009.protection.gbl (10.173.161.204) by BL2FFO11HUB008.protection.gbl (10.173.160.228) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 26 Dec 2012 22:32:04 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 26 Dec 2012 22:32:04 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 26 Dec 2012 22:31:48 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: AQHN47TJUHIl1lr/KUqDZmvVcyHrR5grpn6A Date: Wed, 26 Dec 2012 22:31:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> In-Reply-To: <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669A869ETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52604002)(377454001)(54316002)(76482001)(49866001)(53806001)(47446002)(33656001)(46102001)(54356001)(55846006)(56776001)(31966008)(74662001)(47736001)(51856001)(47976001)(59766001)(16406001)(44976002)(512954001)(56816002)(77982001)(74502001)(5343655001)(4396001)(16236675001)(50986001)(5343635001)(15202345001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB008; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0707248B64 Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 22:32:13 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943669A869ETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That idea seems like it would (1) add to the overall complexity of implemen= tations, (2) would be counter the goal of interoperable implementations, an= d (3) would likely be counter to goal of security. (1) The way I see it, if an extension mechanism (other than having both par= ties understand the extension, which already works) is going to be defined,= we owe users of the specs a clear definition of how to do not-understood e= xtensions. Otherwise implementations of each profile will potentially have= to repeat the work of checking the fields used, rather than doing it in th= e JOSE libraries themselves, adding to overall implementation complexity. (2) Sometimes allowing fields to be not understood and sometimes requiring= them to be, and possibly using different extension mechanisms in different= profiles would definitely hurt interoperability. (3) If a profile decided that the "alg" field need not be understood, that= would definitely defeat the security purposes of the JOSE specs. The same= is true of many other fields. We owe it to users of the specs to be clear= that security-critical fields must be understood. "Punting" this to profi= les or just putting it in the security considerations unnecessarily risks h= aving profile writers get this wrong. Yes, in theory, we could include a consensus call question giving people th= is option as well, but unless support for it shows up on the list, it would= just seem (to me) to unnecessarily complicate the questions we're asking p= eople by including an option that's not actually viable from a complexity, = interoperability, or security point of view. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, December 26, 2012 2:03 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header= fields This does not include my recommended approach which is to punt the issue of= required headers to the application rather than JOSE. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fie= lds Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_4E1F6AAD24975D4BA5B1680429673943669A869ETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That idea seems like i= t would (1) add to the overall complexity of implementations, (2) would be = counter the goal of interoperable implementations, and (3) would likely be = counter to goal of security.

 

(1) The way I see it, = if an extension mechanism (other than having both parties understand the ex= tension, which already works) is going to be defined, we owe users of the s= pecs a clear definition of how to do not-understood extensions.  Otherwise implementations of each profile= will potentially have to repeat the work of checking the fields used, rath= er than doing it in the JOSE libraries themselves, adding to overall implem= entation complexity.

 

(2)  Sometimes al= lowing fields to be not understood and sometimes requiring them to be, and = possibly using different extension mechanisms in different profiles would d= efinitely hurt interoperability.

 

(3)  If a profile= decided that the “alg” field need not be understood, that woul= d definitely defeat the security purposes of the JOSE specs.  The same= is true of many other fields.  We owe it to users of the specs to be clear that security-critical fields must be understood.  = “Punting” this to profiles or just putting it in the security c= onsiderations unnecessarily risks having profile writers get this wrong.

 

Yes, in theory, we cou= ld include a consensus call question giving people this option as well, but= unless support for it shows up on the list, it would just seem (to me) to = unnecessarily complicate the questions we’re asking people by including an option that’s not actually= viable from a complexity, interoperability, or security point of view.

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Wednesday, December 26, 2012 2:03 PM
To: Mike Jones; jose@ietf.org
Subject: RE: [jose] Whether implementations must understand all JOSE= header fields

 

This does not include = my recommended approach which is to punt the issue of required headers to t= he application rather than JOSE.

 

Jim<= /p>

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE hea= der fields

 

Currently the JOSE specs contain the following la= nguage declaring that all header (and some other) fields must be understood= :  “Implementations MUST understand the entire contents of the h= eader; otherwise, the … MUST be rejected.”  There's currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that al= l header fields must be understood by implementations using them.

 

PRO:  This is a simple rule designed to resu= lt in secure implementations.  Representations of existing JWS & J= WE objects are unchanged.

CON:  Extensibility is limited to cases wher= e all participating parties understand new fields that are introduced.=

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of field= s can be designated as “may be ignored if not understood”. = ; For instance, an “ign” (may be ignored) member could be defined whose value is an array listing the member names that may be safel= y ignored if not understood.  An example using this field in a JWS hea= der is:

 

    {"alg":"ES256&q= uot;,

     "ign":["n= otes"],

     "notes":"= This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT co= ntain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain the= current semantics, while allowing explicit exceptions to be made in cases = where the fields are not security-critical and the structure has a meaningful interpretation without them.  Represen= tations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names a= nd may-be-ignored list, adding some implementation complexity.

 

2B.  Take an alternative approach where inst= ead of one header object, there would be two header objects.  Implemen= tations would be required to understand all fields in the first header obje= ct.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of = this approach, adding the second header object after the first in a JWS, wo= uld be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOi= JIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dX= JlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOj= EzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r= _wW1gFWFOEjXk

 

The first, third, and fourth fields are from the = example JWS in the current spec. The new second field is the base64url enco= ded representation of the string '{"notes":"This signature n= eed not be checked when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily disti= nguishable from must-be-understood fields.

CON:  Implementations must consult/merge two= sets of headers to understand the meaning/structure of the object, adding = some implementation complexity.  Existing JWS & JWE object represe= ntations would become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be cri= tical for implementations to understand?

YES – All header fields must continue to be= understood by implementations or the input must be rejected.

NO – A means of listing that specific heade= r fields may be safely ignored should be defined.

 

SECOND POLL:  Should the result of the first= poll be "NO", which syntax would you prefer for designating the = header fields that may be ignored if not understood?

A – Define a header field that explicitly l= ists the fields that may be safely ignored if not understood.

B – Introduce a second header, where implem= entations must understand all fields in the first but they may ignore not-u= nderstood fields in the second.

 

         =             &nb= sp;            =             &nb= sp; Thanks for considering these questions,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Richard Barnes, John Bradley, Mike Jones

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943669A869ETK5EX14MBXC283r_-- From internet-drafts@ietf.org Fri Dec 28 01:45:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0941321F8867; Fri, 28 Dec 2012 01:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6XpxBJMh3i8; Fri, 28 Dec 2012 01:45:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F54021F8D22; Fri, 28 Dec 2012 01:45:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121228094542.30231.55376.idtracker@ietfa.amsl.com> Date: Fri, 28 Dec 2012 01:45:42 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-08.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 09:45:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-08.txt Pages : 41 Date : 2012-12-28 Abstract: JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Dec 28 01:48:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A0C21F8867; Fri, 28 Dec 2012 01:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aHFwIWxUgCw; Fri, 28 Dec 2012 01:48:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C2621F8D44; Fri, 28 Dec 2012 01:48:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121228094830.5944.63578.idtracker@ietfa.amsl.com> Date: Fri, 28 Dec 2012 01:48:30 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-08.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 09:48:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-08.txt Pages : 52 Date : 2012-12-28 Abstract: JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Dec 28 01:50:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8E821F8D6E; Fri, 28 Dec 2012 01:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34QeP9blOkfS; Fri, 28 Dec 2012 01:50:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1721F8D7F; Fri, 28 Dec 2012 01:50:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121228095017.24882.82752.idtracker@ietfa.amsl.com> Date: Fri, 28 Dec 2012 01:50:17 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-08.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 09:50:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-08.txt Pages : 14 Date : 2012-12-28 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a public key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Dec 28 01:52:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85B21F8D7F; Fri, 28 Dec 2012 01:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXMEVAN6WrPN; Fri, 28 Dec 2012 01:52:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6B321F8DF5; Fri, 28 Dec 2012 01:52:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121228095213.28677.62310.idtracker@ietfa.amsl.com> Date: Fri, 28 Dec 2012 01:52:13 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-08.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 09:52:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-08.txt Pages : 42 Date : 2012-12-28 Abstract: The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Fri Dec 28 17:07:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C3A21F8E2B for ; Fri, 28 Dec 2012 17:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjeinvEG283n for ; Fri, 28 Dec 2012 17:07:41 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id B115721F8E2A for ; Fri, 28 Dec 2012 17:07:41 -0800 (PST) Received: from BY2FFO11FD016.protection.gbl (10.1.15.203) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:07:21 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.132) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:07:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:07:12 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: December 27, 2012 JOSE Release Thread-Index: Ac3lYNFRxgEleyiFSlaREDgDQTnutg== Date: Sat, 29 Dec 2012 01:07:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0A09@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669B0A09TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(50986001)(54316002)(49866001)(51856001)(77982001)(33656001)(5343635001)(47976001)(5343665001)(56816002)(4396001)(47736001)(76482001)(5343655001)(16406001)(53806001)(74662001)(55846006)(54356001)(56776001)(74502001)(59766001)(46102001)(512954001)(47446002)(15202345001)(16236675001)(44976002)(31966008)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07106EF9B9 Subject: [jose] December 27, 2012 JOSE Release X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 01:07:43 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943669B0A09TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New versions of the JOSE specs have been released incorporating feedback si= nce IETF 85 in Atlanta. The highlight of this release is the new JSON Priv= ate and Symmetric Key spec, which extends JWKs to be able to represent = private and symmetric keys. These sensitive keys can then be protected for= transmission and storage by JWE encryption of their JWK representations. One new feature added to JWK is the ability to optionally specify which spe= cific algorithm the key is intended to be used with. (This is already exis= ting practice for keys in X.509 format.) For instance, a symmetric key mig= ht be annotated to say that it is to be used with the "HS256" algorithm. B= ecause the natural field name for this functionality is "alg", the "alg" na= me is now used for this purpose (matching JWS and JWE) and the key type (fo= rmerly "alg") is now denoted by the "kty" field. This release incorporates editorial improvements suggested by Jeff Hodges a= nd Hannes Tschofenig in their reviews of the JWT specification. Many of th= ese simplified the terminology usage. See the Document History section of = each specification for more details about the changes made. This release is part of a coordinated release of JOSE, OAuth, and OpenID Co= nnect specifications. You can read about the other releases here: OAuth R= elease Notes, OpenID Connect Release Note= s. The new specification versions are: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08 * http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization= -04 * http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization= -04 * http://tools.ietf.org/html/draft-jones-jose-json-private-and-symme= tric-key-00 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-08= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0= 8.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-08.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0= 8.html * http://self-issued.info/docs/draft-jones-jose-jws-json-serializati= on-04.html * http://self-issued.info/docs/draft-jones-jose-jwe-json-serializati= on-04.html * http://self-issued.info/docs/draft-jones-jose-json-private-and-sym= metric-key-00.html -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943669B0A09TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New versions of the JOSE specs have been released in= corporating feedback since IETF 85 in Atlanta.  The highlight of this = release is the new JSON Private and Symmetric Key spec, which extends JWKs to be able to r= epresent private and symmetric keys.  These sensitive keys can then be= protected for transmission and storage by JWE encryption of their JWK repr= esentations.

 

One new feature added to JWK is the ability to optio= nally specify which specific algorithm the key is intended to be used with.=   (This is already existing practice for keys in X.509 format.)  = For instance, a symmetric key might be annotated to say that it is to be used with the “HS256” algorithm.  Because the nat= ural field name for this functionality is “alg”, the “alg” name is now used for this purpose (matching JWS and JWE) and the key type = (formerly “alg”) is now denoted by the “kty” field.

 

This release incorporates editorial improvements sug= gested by Jeff Hodges and Hannes Tschofenig in their reviews of the JWT spe= cification.  Many of these simplified the terminology usage.  See= the Document History section of each specification for more details about the changes made.

 

This release is part of a coordinated release of JOS= E, OAuth, and OpenID Connect specifications.  You can read about the o= ther releases here:  OAuth Release Notes, OpenID Connect Release Notes.

 

The new specification versions are:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-08

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-08

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-08

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-08

·        http://tools.ietf.org/html/draft-jone= s-jose-jws-json-serialization-04

·        http://tools.ietf.org/html/draft-jone= s-jose-jwe-json-serialization-04

·        http://tools.ietf.org/html/dr= aft-jones-jose-json-private-and-symmetric-key-00

 

HTML formatted versions are available at:=

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-08.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-08.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-08.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-08.html

·        http://self-issued.info/docs/d= raft-jones-jose-jws-json-serialization-04.html

·        http://self-issued.info/docs/d= raft-jones-jose-jwe-json-serialization-04.html

·        http://self-issued.inf= o/docs/draft-jones-jose-json-private-and-symmetric-key-00.html

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943669B0A09TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Dec 28 17:11:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5244E21F8E46 for ; Fri, 28 Dec 2012 17:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD1Lxu9RSUDS for ; Fri, 28 Dec 2012 17:11:17 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0E18921F8E44 for ; Fri, 28 Dec 2012 17:11:16 -0800 (PST) Received: from BL2FFO11FD015.protection.gbl (10.173.161.204) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:11:09 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:11:08 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:11:08 +0000 From: Mike Jones To: 'Hannes Tschofenig' , "'jose@ietf.org'" Thread-Topic: [jose] Extensibility (was "Criticality") Thread-Index: Ac3lYV4dSeIJBTB9S2ueBe/Iw5czLQ== Date: Sat, 29 Dec 2012 01:11:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0ADF@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(43784002)(13464002)(50986001)(49866001)(74662001)(46406002)(56816002)(44976002)(47736001)(55846006)(33656001)(47976001)(76482001)(16406001)(54316002)(50466001)(23726001)(46102001)(4396001)(550184003)(59766001)(53806001)(31966008)(56776001)(77982001)(47446002)(51856001)(54356001)(74502001)(47776002)(5343655001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07106EF9B9 Subject: Re: [jose] Extensibility (was "Criticality") X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 01:11:21 -0000 The clarification below has been applied in the latest versions of the spec= ifications. Thanks again, -- Mike -----Original Message----- From: Mike Jones=20 Sent: Monday, December 10, 2012 6:30 PM To: 'Hannes Tschofenig'; jose@ietf.org Subject: RE: [jose] Extensibility (was "Criticality") As I think you know, there's an open issue in the JOSE working group about = whether all header fields must be understood or whether a mechanism should = be defined to specify which header fields may be safely ignored if not unde= rstood. John Bradley and Richard Barnes and I have been drafting a note ab= out these choices to the JOSE working group, which I expect should go out a= ny day now. Per my reply to your note on the OAuth list, the intended meaning is "The u= se of this header parameter is OPTIONAL." I'll plan to clarify this in the= next version of the specifications. Thanks again, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Han= nes Tschofenig Sent: Monday, November 26, 2012 3:07 AM To: jose@ietf.org Cc: Hannes Tschofenig Subject: [jose] Extensibility (was "Criticality") Hi all,=20 doing my shepherd writeup of some of the OAuth WG documents I was wondering= how the extensibility story for these JSON-based documents should look lik= e given a statement like this: "Implementations MUST understand the entire= contents of the header; otherwise, the JWS MUST be rejected." Absent a "feature discovery" mechanism I am curious whether any extension i= s actually possible.=20 (Funny enough then all individual parameters then say "This header paramete= r is OPTIONAL.")=20 Since this type of extensibility feature does not seem to a be a new concep= t I am curious how it has been handled (successfully) in other specificatio= ns.=20 Ciao Hannes PS: I remember that this has been discussed during the meeting but I do not= know what the outcome of the discussion was. The meeting minutes do not se= em to be available yet. =20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Sat Dec 29 20:25:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E926921F886A for ; Sat, 29 Dec 2012 20:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfYYDx9X620P for ; Sat, 29 Dec 2012 20:25:21 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3D21F8864 for ; Sat, 29 Dec 2012 20:25:20 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 1AE572CA29; Sat, 29 Dec 2012 20:25:17 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 29 Dec 2012 20:24:57 -0800 Message-ID: <010d01cde645$a3ef3ff0$ebcdbfd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010E_01CDE602.95D093D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu1NOwxvsFfhrE3kb42icQdthreQEtjRp9ApbYxe6XUL420A== Content-Language: en-us Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 04:25:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010E_01CDE602.95D093D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, December 26, 2012 2:32 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header fields That idea seems like it would (1) add to the overall complexity of implementations, (2) would be counter the goal of interoperable implementations, and (3) would likely be counter to goal of security. (1) The way I see it, if an extension mechanism (other than having both parties understand the extension, which already works) is going to be defined, we owe users of the specs a clear definition of how to do not-understood extensions. Otherwise implementations of each profile will potentially have to repeat the work of checking the fields used, rather than doing it in the JOSE libraries themselves, adding to overall implementation complexity. (2) Sometimes allowing fields to be not understood and sometimes requiring them to be, and possibly using different extension mechanisms in different profiles would definitely hurt interoperability. (3) If a profile decided that the "alg" field need not be understood, that would definitely defeat the security purposes of the JOSE specs. The same is true of many other fields. We owe it to users of the specs to be clear that security-critical fields must be understood. "Punting" this to profiles or just putting it in the security considerations unnecessarily risks having profile writers get this wrong. [JLS] I would be shocked if a JWS implementation would report that the signature verified in this case. So I don't think that there is any security issue here. Yes, in theory, we could include a consensus call question giving people this option as well, but unless support for it shows up on the list, it would just seem (to me) to unnecessarily complicate the questions we're asking people by including an option that's not actually viable from a complexity, interoperability, or security point of view. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, December 26, 2012 2:03 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header fields This does not include my recommended approach which is to punt the issue of required headers to the application rather than JOSE. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fields Currently the JOSE specs contain the following language declaring that all header (and some other) fields must be understood: "Implementations MUST understand the entire contents of the header; otherwise, the . MUST be rejected." There's currently an open issue about whether all header fields should be required to be understood by implementations using them or whether to relax this requirement in some circumstances. We would like the working group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be understood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties understand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be understood, but where an explicit list of fields can be designated as "may be ignored if not understood". For instance, an "ign" (may be ignored) member could be defined whose value is an array listing the member names that may be safely ignored if not understood. An example using this field in a JWS header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking implementations. It would maintain the current semantics, while allowing explicit exceptions to be made in cases where the fields are not security-critical and the structure has a meaningful interpretation without them. Representations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding some implementation complexity. 2B. Take an alternative approach where instead of one header object, there would be two header objects. Implementations would be required to understand all fields in the first header object. Implementations would be allowed to ignore fields in the second header object if not understood. An example of this approach, adding the second header object after the first in a JWS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9v biBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9p c19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current spec. The new second field is the base64url encoded representation of the string '{"notes":"This signature need not be checked when the moon is full"}'. PRO: May-be-ignored fields are easily distinguishable from must-be-understood fields. CON: Implementations must consult/merge two sets of headers to understand the meaning/structure of the object, adding some implementation complexity. Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chairs to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to understand? YES - All header fields must continue to be understood by implementations or the input must be rejected. NO - A means of listing that specific header fields may be safely ignored should be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax would you prefer for designating the header fields that may be ignored if not understood? A - Define a header field that explicitly lists the fields that may be safely ignored if not understood. B - Introduce a second header, where implementations must understand all fields in the first but they may ignore not-understood fields in the second. Thanks for considering these questions, Richard Barnes, John Bradley, Mike Jones ------=_NextPart_000_010E_01CDE602.95D093D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Wednesday, December 26, 2012 2:32 = PM
To: Jim Schaad; jose@ietf.org
Subject: Re: [jose] = Whether implementations must understand all JOSE header = fields

 

That idea seems like it would (1) add to the = overall complexity of implementations, (2) would be counter the goal of = interoperable implementations, and (3) would likely be counter to goal = of security.

 

(1) The way I see it, if = an extension mechanism (other than having both parties understand the = extension, which already works) is going to be defined, we owe users of = the specs a clear definition of how to do not-understood = extensions.  Otherwise implementations of each profile will = potentially have to repeat the work of checking the fields used, rather = than doing it in the JOSE libraries themselves, adding to overall = implementation complexity.

 

(2)  Sometimes = allowing fields to be not understood and sometimes requiring them to be, = and possibly using different extension mechanisms in different profiles = would definitely hurt interoperability.

 

(3)  If a profile = decided that the “alg” field need not be understood, that = would definitely defeat the security purposes of the JOSE specs.  = The same is true of many other fields.  We owe it to users of the = specs to be clear that security-critical fields must be = understood.  “Punting” this to profiles or just putting = it in the security considerations unnecessarily risks having profile = writers get this wrong.

 

[JLS]  I would be = shocked if a JWS implementation would report that the signature verified = in this case.  So I don’t think that there is any security = issue here.

 

Yes, in theory, we could = include a consensus call question giving people this option as well, but = unless support for it shows up on the list, it would just seem (to me) = to unnecessarily complicate the questions we’re asking people by = including an option that’s not actually viable from a complexity, = interoperability, or security point of view.

 

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

 

From:= = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Wednesday, December 26, 2012 2:03 PM
To: = Mike Jones; jose@ietf.org
Subject: RE: = [jose] Whether implementations must understand all JOSE header = fields

 

This does not include my recommended approach = which is to punt the issue of required headers to the application rather = than JOSE.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 = 10:17 AM
To: jose@ietf.org
Subject: = [jose] Whether implementations must understand all JOSE header = fields

 

Currently = the JOSE specs contain the following language declaring that all header = (and some other) fields must be understood:  “Implementations = MUST understand the entire contents of the header; otherwise, the = … MUST be rejected.”  There's currently an open issue = about whether all header fields should be required to be understood by = implementations using them or whether to relax this requirement in some = circumstances.  We would like the working group to consider the = following potential resolutions to the issue.

 

1.  Maintain the current requirement that all = header fields must be understood by implementations using = them.

 

PRO:  This is a simple rule designed to result = in secure implementations.  Representations of existing JWS & = JWE objects are unchanged.

CON:  Extensibility is limited to cases where = all participating parties understand new fields that are = introduced.

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of = fields can be designated as “may be ignored if not = understood”.  For instance, an “ign” (may be = ignored) member could be defined whose value is an array listing the = member names that may be safely ignored if not understood.  An = example using this field in a JWS header is:

 

    = {"alg":"ES256",

     = "ign":["notes"],

     = "notes":"This signature need not be checked when the moon = is full"

    = }

 

(Obviously, the "ign" field MUST NOT = contain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain = the current semantics, while allowing explicit exceptions to be made in = cases where the fields are not security-critical and the structure has a = meaningful interpretation without them.  Representations of = existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names and = may-be-ignored list, adding some implementation = complexity.

 

2B.  Take an alternative approach where = instead of one header object, there would be two header objects.  = Implementations would be required to understand all fields in the first = header object.  Implementations would be allowed to ignore fields = in the second header object if not understood.  An example of this = approach, adding the second header object after the first in a JWS, = would be:

 

    = eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

    .

    = eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgb= W9vbiBpcyBmdWxsIn0

    .

    = eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvb= S9pc19yb290Ijp0cnVlfQ

    .

    = dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

 

The = first, third, and fourth fields are from the example JWS in the current = spec. The new second field is the base64url encoded representation of = the string '{"notes":"This signature need not be checked = when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily = distinguishable from must-be-understood fields.

CON:  Implementations must consult/merge two = sets of headers to understand the meaning/structure of the object, = adding some implementation complexity.  Existing JWS & JWE = object representations would become invalid.

 

After = a discussion period, we believe that it would be useful for the chairs = to make two formal consensus calls of the following = kind:

 

FIRST POLL:  Should all header fields be = critical for implementations to understand?

YES – All header fields must continue to be = understood by implementations or the input must be = rejected.

NO – A means of = listing that specific header fields may be safely ignored should be = defined.

 

SECOND POLL:  Should the result of the first = poll be "NO", which syntax would you prefer for designating = the header fields that may be ignored if not = understood?

A – Define a = header field that explicitly lists the fields that may be safely ignored = if not understood.

B – = Introduce a second header, where implementations must understand all = fields in the first but they may ignore not-understood fields in the = second.

 

        =             &= nbsp;           &n= bsp;           &nb= sp;   Thanks for considering these = questions,

        &nbs= p;            = ;            =             &= nbsp;  Richard Barnes, John Bradley, Mike Jones

 

 

------=_NextPart_000_010E_01CDE602.95D093D0-- From ietf@augustcellars.com Sat Dec 29 21:59:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763C221F88B5 for ; Sat, 29 Dec 2012 21:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aTwbg5LXGF4 for ; Sat, 29 Dec 2012 21:59:23 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2165121F88AC for ; Sat, 29 Dec 2012 21:59:23 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 431F42CA02; Sat, 29 Dec 2012 21:59:19 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com> <010d01cde645$a3ef3ff0$ebcdbfd0$@augustcellars.com> In-Reply-To: <010d01cde645$a3ef3ff0$ebcdbfd0$@augustcellars.com> Date: Sat, 29 Dec 2012 21:59:01 -0800 Message-ID: <011e01cde652$c6ea19f0$54be4dd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011F_01CDE60F.B8CDB7C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu1NOwxvsFfhrE3kb42icQdthreQEtjRp9ApbYxe4BR6pY8pdGjUkA Content-Language: en-us Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 05:59:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011F_01CDE60F.B8CDB7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am going to go into more detail than my last message The issue is a question of which part of the code is responsible for what set of processing. If a library says that an item is either encrypted or signed and it wasn't, or it was unable to apply those transformations on request, then you have a security problem. If you hand the library a piece of garbage and it says that it was not signed (or encrypted) then you do not have a security problem, you have a different type of problem. The same thing is true with the ZIP example you gave earlier. Is the application or the JW* library responsible for dealing with the question of zipping the content? If you say the application is responsible, then it does not matter of the JW* code does not recognize the ZIP parameter. If you say the JW* library is responsible, then it does matter if the JW* code does not recognize the ZIP parameter. You then also have the question should the JW* code have the "right" to apply a ZIP operation even if it was not asked for by the application. It is after all part of the library and thus could be applied at any time. The position of mandatory understanding of fields is much more justifiable if one states that the library is responsible for enforcing everything about the header. This would mean that the concept of a signing time field in the header would not make any sense. The JW* library has no way of knowing what the semantics of the field is going to mean to the application and thus has no method of enforcing it. (Does the object expire a specific amount of time after the signing time? Does there need to be some type of allowance for clock skews? Is there an interaction between a certificate if given and the signing time as a header field? Are there fields in the key container that say when a key can be used and thus need to be enforced?) If on the other hand one believes that there is a possibility that there is auxiliary data which is not part of the content but is part of the context in which the signature (or encryption) was applied, it is impossible for a JW* library to be able to enforce any of this context and it must be deferred to the application for enforcement. To directly address your points below: 1. We owe developers a clear description of what to do with the items that we defined. If an application defines another field, then it will defined what to do with that item and not the JW* code and the application would be expected to enforce the semantics and not the JW* code. It does mean that each application will have its own list of what items can appear, however it does not mean that the JW* code cannot supply a library routine for doing the field name checking. 2. I am completely unable to understand why allowing a field for one application and not for another application hurts interoperability or enforcement of the fields. But as I am doing this in the application, I only have one standard that I am working with (until such a time as the application is updated). 3. If a profile decides that the alg field need not be present, which is different that it's value not being understood, then that is up to the application. As long as the application does not make a security claim about the content that as transmitted that is a perfectly fine thing for it to do. It might just be transmitted as plain unsigned, unencrypted data in the same format as the current JW* formats. There is a different issue involved with the value of the alg field not being understood. That is something that the JW* libraries are perfectly competent to deal with and is not the same type of extension mechanism as we are discussing here. I completely disagree that the option is either not viable, or is a security problem. I think that this is your narrow view of the world affecting how you are evaluating the proposal that I have provided. However as long as you are going to stay in the camp that says there is no auxiliary data which is not part of the content of the message, then your view is a consistent one. I happen to strongly disagree with that view of the world. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Saturday, December 29, 2012 8:25 PM To: 'Mike Jones'; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header fields From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, December 26, 2012 2:32 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header fields That idea seems like it would (1) add to the overall complexity of implementations, (2) would be counter the goal of interoperable implementations, and (3) would likely be counter to goal of security. (1) The way I see it, if an extension mechanism (other than having both parties understand the extension, which already works) is going to be defined, we owe users of the specs a clear definition of how to do not-understood extensions. Otherwise implementations of each profile will potentially have to repeat the work of checking the fields used, rather than doing it in the JOSE libraries themselves, adding to overall implementation complexity. (2) Sometimes allowing fields to be not understood and sometimes requiring them to be, and possibly using different extension mechanisms in different profiles would definitely hurt interoperability. (3) If a profile decided that the "alg" field need not be understood, that would definitely defeat the security purposes of the JOSE specs. The same is true of many other fields. We owe it to users of the specs to be clear that security-critical fields must be understood. "Punting" this to profiles or just putting it in the security considerations unnecessarily risks having profile writers get this wrong. [JLS] I would be shocked if a JWS implementation would report that the signature verified in this case. So I don't think that there is any security issue here. Yes, in theory, we could include a consensus call question giving people this option as well, but unless support for it shows up on the list, it would just seem (to me) to unnecessarily complicate the questions we're asking people by including an option that's not actually viable from a complexity, interoperability, or security point of view. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, December 26, 2012 2:03 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header fields This does not include my recommended approach which is to punt the issue of required headers to the application rather than JOSE. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fields Currently the JOSE specs contain the following language declaring that all header (and some other) fields must be understood: "Implementations MUST understand the entire contents of the header; otherwise, the . MUST be rejected." There's currently an open issue about whether all header fields should be required to be understood by implementations using them or whether to relax this requirement in some circumstances. We would like the working group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be understood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties understand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be understood, but where an explicit list of fields can be designated as "may be ignored if not understood". For instance, an "ign" (may be ignored) member could be defined whose value is an array listing the member names that may be safely ignored if not understood. An example using this field in a JWS header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking implementations. It would maintain the current semantics, while allowing explicit exceptions to be made in cases where the fields are not security-critical and the structure has a meaningful interpretation without them. Representations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding some implementation complexity. 2B. Take an alternative approach where instead of one header object, there would be two header objects. Implementations would be required to understand all fields in the first header object. Implementations would be allowed to ignore fields in the second header object if not understood. An example of this approach, adding the second header object after the first in a JWS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9v biBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9p c19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current spec. The new second field is the base64url encoded representation of the string '{"notes":"This signature need not be checked when the moon is full"}'. PRO: May-be-ignored fields are easily distinguishable from must-be-understood fields. CON: Implementations must consult/merge two sets of headers to understand the meaning/structure of the object, adding some implementation complexity. Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chairs to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to understand? YES - All header fields must continue to be understood by implementations or the input must be rejected. NO - A means of listing that specific header fields may be safely ignored should be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax would you prefer for designating the header fields that may be ignored if not understood? A - Define a header field that explicitly lists the fields that may be safely ignored if not understood. B - Introduce a second header, where implementations must understand all fields in the first but they may ignore not-understood fields in the second. Thanks for considering these questions, Richard Barnes, John Bradley, Mike Jones ------=_NextPart_000_011F_01CDE60F.B8CDB7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am going to go into more detail than my last = message

 

The issue is a question = of which part of the code is responsible for what set of = processing.

 

If a library says that = an item is either encrypted or signed and it wasn’t, or it was = unable to apply those transformations on request, then you have a = security problem.  If you hand the library a piece of garbage and = it says that it was not signed (or encrypted) then you do not have a = security problem, you have a different type of = problem.

 

The same thing is true = with the ZIP example you gave earlier.  Is the application or the = JW* library responsible for dealing with the question of zipping the = content?  If you say the application is responsible, then it does = not matter of the JW* code does not recognize the ZIP parameter.  = If you say the JW* library is responsible, then it does matter if the = JW* code does not recognize the ZIP parameter.  You then also have = the question should the JW* code have the “right” to apply a = ZIP operation even if it was not asked for by the application.  It = is after all part of the library and thus could be applied at any = time.

 

The position of = mandatory understanding of fields is much more justifiable if one states = that the library is responsible for enforcing everything about the = header.  This would mean that the concept of a signing time field = in the header would not make any sense.  The JW* library has no way = of knowing what the semantics of the field is going to mean to the = application and thus has  no method of enforcing it.  (Does = the object expire a specific amount of time after the signing = time?  Does there need to be some type of allowance for clock = skews?  Is there an interaction between a certificate if given and = the signing time as a header field?  Are there fields in the key = container that say when a key can be used and thus need to be = enforced?) 

 

If on the other hand one = believes that there is a possibility that there is auxiliary data which = is not part of the content but is part of the context in which the = signature (or encryption) was applied, it is impossible for a JW* = library to be able to enforce any of this context and it must be = deferred to the application for enforcement.

 

To directly address your = points below:

 

1.       =  We = owe developers a clear description of what to do with the items that we = defined.  If an application defines another field, then it will = defined what to do with that item and not the JW* code and the = application would be expected to enforce the semantics and not the JW* = code.  It does mean that each application will have its own list of = what items can appear, however it does not mean that the JW* code cannot = supply a library routine for doing the field name = checking.

2.       = I am = completely unable to understand why allowing a field for one application = and not for another application hurts interoperability or enforcement of = the fields.   But as I am doing this in the application, I = only have one standard that I am working with (until such a time as the = application is updated). 

3.       = If a = profile decides that the alg field need not be present, which is = different that it’s value not being understood, then that is up to = the application.  As long as the application does not make a = security claim about the content that as transmitted that is a perfectly = fine thing for it to do.  It might just be transmitted as plain = unsigned, unencrypted data in the same format as the current JW* = formats.  There is a different issue involved with the value of the = alg field not being understood.  That is something that the JW* = libraries are perfectly competent to deal with and is not the same type = of extension mechanism as we are discussing = here.

 

I completely disagree = that the option is either  not viable, or is a security = problem.  I think that this is your narrow view of the world = affecting how you are evaluating the proposal that I have = provided.  However as long as you are going to stay in the camp = that says there is no auxiliary data which is not part of the content of = the message, then your view is a consistent one.  I happen to = strongly disagree with that view of the world.

 

Jim

 

 

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Jim Schaad
Sent: Saturday, December 29, 2012 8:25 = PM
To: 'Mike Jones'; jose@ietf.org
Subject: Re: = [jose] Whether implementations must understand all JOSE header = fields

 

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Wednesday, December 26, = 2012 2:32 PM
To: Jim Schaad; jose@ietf.org
Subject: Re: = [jose] Whether implementations must understand all JOSE header = fields

 

That idea seems like it would (1) add to the = overall complexity of implementations, (2) would be counter the goal of = interoperable implementations, and (3) would likely be counter to goal = of security.

 

(1) The way I see it, if = an extension mechanism (other than having both parties understand the = extension, which already works) is going to be defined, we owe users of = the specs a clear definition of how to do not-understood = extensions.  Otherwise implementations of each profile will = potentially have to repeat the work of checking the fields used, rather = than doing it in the JOSE libraries themselves, adding to overall = implementation complexity.

 

(2)  Sometimes = allowing fields to be not understood and sometimes requiring them to be, = and possibly using different extension mechanisms in different profiles = would definitely hurt interoperability.

 

(3)  If a profile = decided that the “alg” field need not be understood, that = would definitely defeat the security purposes of the JOSE specs.  = The same is true of many other fields.  We owe it to users of the = specs to be clear that security-critical fields must be = understood.  “Punting” this to profiles or just putting = it in the security considerations unnecessarily risks having profile = writers get this wrong.

 

[JLS]  I would be = shocked if a JWS implementation would report that the signature verified = in this case.  So I don’t think that there is any security = issue here.

 

Yes, in theory, we could = include a consensus call question giving people this option as well, but = unless support for it shows up on the list, it would just seem (to me) = to unnecessarily complicate the questions we’re asking people by = including an option that’s not actually viable from a complexity, = interoperability, or security point of view.

 

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

 

From:= = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Wednesday, December 26, 2012 2:03 PM
To: = Mike Jones; jose@ietf.org
Subject: RE: = [jose] Whether implementations must understand all JOSE header = fields

 

This does not include my recommended approach = which is to punt the issue of required headers to the application rather = than JOSE.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 = 10:17 AM
To: jose@ietf.org
Subject: = [jose] Whether implementations must understand all JOSE header = fields

 

Currently = the JOSE specs contain the following language declaring that all header = (and some other) fields must be understood:  “Implementations = MUST understand the entire contents of the header; otherwise, the = … MUST be rejected.”  There's currently an open issue = about whether all header fields should be required to be understood by = implementations using them or whether to relax this requirement in some = circumstances.  We would like the working group to consider the = following potential resolutions to the issue.

 

1.  Maintain the current requirement that all = header fields must be understood by implementations using = them.

 

PRO:  This is a simple rule designed to result = in secure implementations.  Representations of existing JWS & = JWE objects are unchanged.

CON:  Extensibility is limited to cases where = all participating parties understand new fields that are = introduced.

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of = fields can be designated as “may be ignored if not = understood”.  For instance, an “ign” (may be = ignored) member could be defined whose value is an array listing the = member names that may be safely ignored if not understood.  An = example using this field in a JWS header is:

 

    = {"alg":"ES256",

     = "ign":["notes"],

     = "notes":"This signature need not be checked when the moon = is full"

    = }

 

(Obviously, the "ign" field MUST NOT = contain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain = the current semantics, while allowing explicit exceptions to be made in = cases where the fields are not security-critical and the structure has a = meaningful interpretation without them.  Representations of = existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names and = may-be-ignored list, adding some implementation = complexity.

 

2B.  Take an alternative approach where = instead of one header object, there would be two header objects.  = Implementations would be required to understand all fields in the first = header object.  Implementations would be allowed to ignore fields = in the second header object if not understood.  An example of this = approach, adding the second header object after the first in a JWS, = would be:

 

    = eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

    .

    = eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgb= W9vbiBpcyBmdWxsIn0

    .

    = eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvb= S9pc19yb290Ijp0cnVlfQ

    .

    = dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

 

The = first, third, and fourth fields are from the example JWS in the current = spec. The new second field is the base64url encoded representation of = the string '{"notes":"This signature need not be checked = when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily = distinguishable from must-be-understood fields.

CON:  Implementations must consult/merge two = sets of headers to understand the meaning/structure of the object, = adding some implementation complexity.  Existing JWS & JWE = object representations would become invalid.

 

After = a discussion period, we believe that it would be useful for the chairs = to make two formal consensus calls of the following = kind:

 

FIRST POLL:  Should all header fields be = critical for implementations to understand?

YES – All header fields must continue to be = understood by implementations or the input must be = rejected.

NO – A means of = listing that specific header fields may be safely ignored should be = defined.

 

SECOND POLL:  Should the result of the first = poll be "NO", which syntax would you prefer for designating = the header fields that may be ignored if not = understood?

A – Define a = header field that explicitly lists the fields that may be safely ignored = if not understood.

B – = Introduce a second header, where implementations must understand all = fields in the first but they may ignore not-understood fields in the = second.

 

        =             &= nbsp;           &n= bsp;           &nb= sp;   Thanks for considering these = questions,

        &nbs= p;            = ;            =             &= nbsp;  Richard Barnes, John Bradley, Mike Jones

 

 

------=_NextPart_000_011F_01CDE60F.B8CDB7C0-- From Michael.Jones@microsoft.com Sun Dec 30 00:21:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53ED21F8890 for ; Sun, 30 Dec 2012 00:21:40 -0800 (PST) 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=[AWL=-0.955, BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UZgviUQavIs for ; Sun, 30 Dec 2012 00:21:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB3621F8871 for ; Sun, 30 Dec 2012 00:21:32 -0800 (PST) Received: from BY2FFO11FD008.protection.gbl (10.1.15.201) by BY2FFO11HUB009.protection.gbl (10.1.14.167) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 08:21:29 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 08:21:29 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Sun, 30 Dec 2012 08:21:28 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: AQHN5lLTvTbGY94AjEyPr63jCzzimJgw/b2w Date: Sun, 30 Dec 2012 08:21:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669E0A2A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com> <010d01cde645$a3ef3ff0$ebcdbfd0$@augustcellars.com> <011e01cde652$c6ea19f0$54be4dd0$@augustcellars.com> In-Reply-To: <011e01cde652$c6ea19f0$54be4dd0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669E0A2ATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(52604002)(51444002)(47736001)(46102001)(74502001)(47446002)(53806001)(54356001)(5343635001)(31966008)(49866001)(74662001)(55846006)(50986001)(51856001)(4396001)(44976002)(47976001)(56776001)(16236675001)(15202345001)(33656001)(16406001)(5343655001)(59766001)(77982001)(512954001)(76482001)(54316002)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB009; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 071156160B Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 08:21:40 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943669E0A2ATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Must understand" is a requirement on the system as a whole - not on a part= icular level of library software. It's perfectly fine for a JOSE library t= o process the headers that it understands and then leave the processing of = the rest of them up to the application - which I think is what you are advo= cating. For those headers that the JOSE library doesn't understand, the re= sponsibility for fulfilling the "must understand" requirement for the remai= ning headers would then fall to the application. I really don't think this is far from what you're thinking of. I completel= y agree with you that inflexible libraries that reject the input because th= ey don't understand all the header values in it without giving the applicat= ion a chance to weigh are probably not good software design. The spec intentionally doesn't say anything about implementation layering, = nor probably should it. It imposes requirements on the complete, end-to-en= d system - not particular implementation layers. At least as I see it, tha= t's an inclusive view of what we're trying to accomplish - not a narrow one= . Does that understanding move us closer to agreement? I hope so... Best wishes, -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, December 29, 2012 9:59 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header= fields I am going to go into more detail than my last message The issue is a question of which part of the code is responsible for what s= et of processing. If a library says that an item is either encrypted or signed and it wasn't,= or it was unable to apply those transformations on request, then you have = a security problem. If you hand the library a piece of garbage and it says= that it was not signed (or encrypted) then you do not have a security prob= lem, you have a different type of problem. The same thing is true with the ZIP example you gave earlier. Is the appli= cation or the JW* library responsible for dealing with the question of zipp= ing the content? If you say the application is responsible, then it does n= ot matter of the JW* code does not recognize the ZIP parameter. If you say= the JW* library is responsible, then it does matter if the JW* code does n= ot recognize the ZIP parameter. You then also have the question should the= JW* code have the "right" to apply a ZIP operation even if it was not aske= d for by the application. It is after all part of the library and thus cou= ld be applied at any time. The position of mandatory understanding of fields is much more justifiable = if one states that the library is responsible for enforcing everything abou= t the header. This would mean that the concept of a signing time field in = the header would not make any sense. The JW* library has no way of knowing= what the semantics of the field is going to mean to the application and th= us has no method of enforcing it. (Does the object expire a specific amou= nt of time after the signing time? Does there need to be some type of allo= wance for clock skews? Is there an interaction between a certificate if gi= ven and the signing time as a header field? Are there fields in the key co= ntainer that say when a key can be used and thus need to be enforced?) If on the other hand one believes that there is a possibility that there is= auxiliary data which is not part of the content but is part of the context= in which the signature (or encryption) was applied, it is impossible for a= JW* library to be able to enforce any of this context and it must be defer= red to the application for enforcement. To directly address your points below: 1. We owe developers a clear description of what to do with the items= that we defined. If an application defines another field, then it will de= fined what to do with that item and not the JW* code and the application wo= uld be expected to enforce the semantics and not the JW* code. It does mea= n that each application will have its own list of what items can appear, ho= wever it does not mean that the JW* code cannot supply a library routine fo= r doing the field name checking. 2. I am completely unable to understand why allowing a field for one a= pplication and not for another application hurts interoperability or enforc= ement of the fields. But as I am doing this in the application, I only ha= ve one standard that I am working with (until such a time as the applicatio= n is updated). 3. If a profile decides that the alg field need not be present, which = is different that it's value not being understood, then that is up to the a= pplication. As long as the application does not make a security claim abou= t the content that as transmitted that is a perfectly fine thing for it to = do. It might just be transmitted as plain unsigned, unencrypted data in th= e same format as the current JW* formats. There is a different issue invol= ved with the value of the alg field not being understood. That is somethin= g that the JW* libraries are perfectly competent to deal with and is not th= e same type of extension mechanism as we are discussing here. I completely disagree that the option is either not viable, or is a securi= ty problem. I think that this is your narrow view of the world affecting h= ow you are evaluating the proposal that I have provided. However as long a= s you are going to stay in the camp that says there is no auxiliary data wh= ich is not part of the content of the message, then your view is a consiste= nt one. I happen to strongly disagree with that view of the world. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Saturday, December 29, 2012 8:25 PM To: 'Mike Jones'; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header= fields From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, December 26, 2012 2:32 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header= fields That idea seems like it would (1) add to the overall complexity of implemen= tations, (2) would be counter the goal of interoperable implementations, an= d (3) would likely be counter to goal of security. (1) The way I see it, if an extension mechanism (other than having both par= ties understand the extension, which already works) is going to be defined,= we owe users of the specs a clear definition of how to do not-understood e= xtensions. Otherwise implementations of each profile will potentially have= to repeat the work of checking the fields used, rather than doing it in th= e JOSE libraries themselves, adding to overall implementation complexity. (2) Sometimes allowing fields to be not understood and sometimes requiring= them to be, and possibly using different extension mechanisms in different= profiles would definitely hurt interoperability. (3) If a profile decided that the "alg" field need not be understood, that= would definitely defeat the security purposes of the JOSE specs. The same= is true of many other fields. We owe it to users of the specs to be clear= that security-critical fields must be understood. "Punting" this to profi= les or just putting it in the security considerations unnecessarily risks h= aving profile writers get this wrong. [JLS] I would be shocked if a JWS implementation would report that the sig= nature verified in this case. So I don't think that there is any security = issue here. Yes, in theory, we could include a consensus call question giving people th= is option as well, but unless support for it shows up on the list, it would= just seem (to me) to unnecessarily complicate the questions we're asking p= eople by including an option that's not actually viable from a complexity, = interoperability, or security point of view. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, December 26, 2012 2:03 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header= fields This does not include my recommended approach which is to punt the issue of= required headers to the application rather than JOSE. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fie= lds Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_4E1F6AAD24975D4BA5B1680429673943669E0A2ATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“Must understand= ” is a requirement on the system as a whole – not on a particul= ar level of library software.  It’s perfectly fine for a JOSE li= brary to process the headers that it understands and then leave the processing of the rest of them up to the application – which I think= is what you are advocating.  For those headers that the JOSE library = doesn’t understand, the responsibility for fulfilling the “must= understand” requirement for the remaining headers would then fall to the application.

 

I really don’t t= hink this is far from what you’re thinking of.  I completely agr= ee with you that inflexible libraries that reject the input because they do= n’t understand all the header values in it without giving the application a chance to weigh are probably not good software design.

 

The spec intentionally= doesn’t say anything about implementation layering, nor probably sho= uld it.  It imposes requirements on the complete, end-to-end system &#= 8211; not particular implementation layers.  At least as I see it, that’s an inclusive view of what we’re trying to = accomplish – not a narrow one.

 

Does that understandin= g move us closer to agreement?  I hope so…

 

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

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Saturday, December 29, 2012 9:59 PM
To: Mike Jones; jose@ietf.org
Subject: RE: [jose] Whether implementations must understand all JOSE= header fields

 

I am going to go into = more detail than my last message

 

The issue is a questio= n of which part of the code is responsible for what set of processing.=

 

If a library says that= an item is either encrypted or signed and it wasn’t, or it was unabl= e to apply those transformations on request, then you have a security probl= em.  If you hand the library a piece of garbage and it says that it was not signed (or encrypted) then you do not have a s= ecurity problem, you have a different type of problem.

 

The same thing is true= with the ZIP example you gave earlier.  Is the application or the JW*= library responsible for dealing with the question of zipping the content? =  If you say the application is responsible, then it does not matter of the JW* code does not recognize the ZIP paramet= er.  If you say the JW* library is responsible, then it does matter if= the JW* code does not recognize the ZIP parameter.  You then also hav= e the question should the JW* code have the “right” to apply a ZIP operation even if it was not asked for = by the application.  It is after all part of the library and thus coul= d be applied at any time.

 

The position of mandat= ory understanding of fields is much more justifiable if one states that the= library is responsible for enforcing everything about the header.  Th= is would mean that the concept of a signing time field in the header would not make any sense.  The JW* library h= as no way of knowing what the semantics of the field is going to mean to th= e application and thus has  no method of enforcing it.  (Does the= object expire a specific amount of time after the signing time?  Does there need to be some type of allowance for c= lock skews?  Is there an interaction between a certificate if given an= d the signing time as a header field?  Are there fields in the key con= tainer that say when a key can be used and thus need to be enforced?) 

 

If on the other hand o= ne believes that there is a possibility that there is auxiliary data which = is not part of the content but is part of the context in which the signatur= e (or encryption) was applied, it is impossible for a JW* library to be able to enforce any of this context and= it must be deferred to the application for enforcement.<= /p>

 

To directly address yo= ur points below:

 

1.&n= bsp;      We owe d= evelopers a clear description of what to do with the items that we defined.=   If an application defines another field, then it will defined what t= o do with that item and not the JW* code and the application would be expected to enforce the semantics and not the JW*= code.  It does mean that each application will have its own list of w= hat items can appear, however it does not mean that the JW* code cannot sup= ply a library routine for doing the field name checking.

2.&n= bsp;     I am completel= y unable to understand why allowing a field for one application and not for= another application hurts interoperability or enforcement of the fields. &= nbsp; But as I am doing this in the application, I only have one standard that I am working with (until such a time as the = application is updated). 

3.&n= bsp;     If a profile d= ecides that the alg field need not be present, which is different that it&#= 8217;s value not being understood, then that is up to the application. = ; As long as the application does not make a security claim about the content that as transmitted that is a perfectly f= ine thing for it to do.  It might just be transmitted as plain unsigne= d, unencrypted data in the same format as the current JW* formats.  Th= ere is a different issue involved with the value of the alg field not being understood.  That is something that = the JW* libraries are perfectly competent to deal with and is not the same = type of extension mechanism as we are discussing here.

 

I completely disagree = that the option is either  not viable, or is a security problem. = I think that this is your narrow view of the world affecting how you are e= valuating the proposal that I have provided.  However as long as you are going to stay in the camp that says there is no= auxiliary data which is not part of the content of the message, then your = view is a consistent one.  I happen to strongly disagree with that vie= w of the world.

 

Jim<= /p>

 

 

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Saturday, December 29, 2012 8:25 PM
To: 'Mike Jones'; jose@ietf.org=
Subject: Re: [jose] Whether implementations must understand all JOSE= header fields

 

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, December 26, 2012 2:32 PM
To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE= header fields

 

That idea seems like i= t would (1) add to the overall complexity of implementations, (2) would be = counter the goal of interoperable implementations, and (3) would likely be = counter to goal of security.

 

(1) The way I see it, = if an extension mechanism (other than having both parties understand the ex= tension, which already works) is going to be defined, we owe users of the s= pecs a clear definition of how to do not-understood extensions.  Otherwise implementations of each profile= will potentially have to repeat the work of checking the fields used, rath= er than doing it in the JOSE libraries themselves, adding to overall implem= entation complexity.

 

(2)  Sometimes al= lowing fields to be not understood and sometimes requiring them to be, and = possibly using different extension mechanisms in different profiles would d= efinitely hurt interoperability.

 

(3)  If a profile= decided that the “alg” field need not be understood, that woul= d definitely defeat the security purposes of the JOSE specs.  The same= is true of many other fields.  We owe it to users of the specs to be clear that security-critical fields must be understood.  = “Punting” this to profiles or just putting it in the security c= onsiderations unnecessarily risks having profile writers get this wrong.

 

[JLS]  I would be= shocked if a JWS implementation would report that the signature verified i= n this case.  So I don’t think that there is any security issue = here.

 

Yes, in theory, we cou= ld include a consensus call question giving people this option as well, but= unless support for it shows up on the list, it would just seem (to me) to = unnecessarily complicate the questions we’re asking people by including an option that’s not actually= viable from a complexity, interoperability, or security point of view.

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com= ]
Sent: Wednesday, December 26, 2012 2:03 PM
To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE= header fields

 

This does not include = my recommended approach which is to punt the issue of required headers to t= he application rather than JOSE.

 

Jim<= /p>

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE hea= der fields

 

Currently the JOSE specs contain the following la= nguage declaring that all header (and some other) fields must be understood= :  “Implementations MUST understand the entire contents of the h= eader; otherwise, the … MUST be rejected.”  There's currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that al= l header fields must be understood by implementations using them.

 

PRO:  This is a simple rule designed to resu= lt in secure implementations.  Representations of existing JWS & J= WE objects are unchanged.

CON:  Extensibility is limited to cases wher= e all participating parties understand new fields that are introduced.=

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of field= s can be designated as “may be ignored if not understood”. = ; For instance, an “ign” (may be ignored) member could be defined whose value is an array listing the member names that may be safel= y ignored if not understood.  An example using this field in a JWS hea= der is:

 

    {"alg":"ES256&q= uot;,

     "ign":["n= otes"],

     "notes":"= This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT co= ntain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain the= current semantics, while allowing explicit exceptions to be made in cases = where the fields are not security-critical and the structure has a meaningful interpretation without them.  Represen= tations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names a= nd may-be-ignored list, adding some implementation complexity.

 

2B.  Take an alternative approach where inst= ead of one header object, there would be two header objects.  Implemen= tations would be required to understand all fields in the first header obje= ct.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of = this approach, adding the second header object after the first in a JWS, wo= uld be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOi= JIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dX= JlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOj= EzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r= _wW1gFWFOEjXk

 

The first, third, and fourth fields are from the = example JWS in the current spec. The new second field is the base64url enco= ded representation of the string '{"notes":"This signature n= eed not be checked when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily disti= nguishable from must-be-understood fields.

CON:  Implementations must consult/merge two= sets of headers to understand the meaning/structure of the object, adding = some implementation complexity.  Existing JWS & JWE object represe= ntations would become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be cri= tical for implementations to understand?

YES – All header fields must continue to be= understood by implementations or the input must be rejected.

NO – A means of listing that specific heade= r fields may be safely ignored should be defined.

 

SECOND POLL:  Should the result of the first= poll be "NO", which syntax would you prefer for designating the = header fields that may be ignored if not understood?

A – Define a header field that explicitly l= ists the fields that may be safely ignored if not understood.

B – Introduce a second header, where implem= entations must understand all fields in the first but they may ignore not-u= nderstood fields in the second.

 

         =             &nb= sp;            =             &nb= sp; Thanks for considering these questions,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Richard Barnes, John Bradley, Mike Jones

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943669E0A2ATK5EX14MBXC283r_-- From ietf@augustcellars.com Mon Dec 31 11:44:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4B021F878A for ; Mon, 31 Dec 2012 11:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5V4A683R5aB for ; Mon, 31 Dec 2012 11:44:30 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A489E21F8689 for ; Mon, 31 Dec 2012 11:44:30 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3CD612C9C5; Mon, 31 Dec 2012 11:44:29 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com> <010d01cde645$a3ef3ff0$ebcdbfd0$@augustcellars.com> <011e01cde652$c6ea19f0$54be4dd0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669E0A2A@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669E0A2A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 31 Dec 2012 11:44:11 -0800 Message-ID: <017001cde78f$35689b80$a039d280$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01CDE74C.274DE700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu1NOwxvsFfhrE3kb42icQdthreQEtjRp9ApbYxe4BR6pY8gDBz7r8AdH3xg+XNHXO4A== Content-Language: en-us Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 19:44:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0171_01CDE74C.274DE700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would say probably not. First, I would allow applications to state that it is not necessary for all header fields to be understood. Second, I don't believe that the text in the document matches what you have said below. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Sunday, December 30, 2012 12:21 AM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header fields "Must understand" is a requirement on the system as a whole - not on a particular level of library software. It's perfectly fine for a JOSE library to process the headers that it understands and then leave the processing of the rest of them up to the application - which I think is what you are advocating. For those headers that the JOSE library doesn't understand, the responsibility for fulfilling the "must understand" requirement for the remaining headers would then fall to the application. I really don't think this is far from what you're thinking of. I completely agree with you that inflexible libraries that reject the input because they don't understand all the header values in it without giving the application a chance to weigh are probably not good software design. The spec intentionally doesn't say anything about implementation layering, nor probably should it. It imposes requirements on the complete, end-to-end system - not particular implementation layers. At least as I see it, that's an inclusive view of what we're trying to accomplish - not a narrow one. Does that understanding move us closer to agreement? I hope so. Best wishes, -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, December 29, 2012 9:59 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header fields I am going to go into more detail than my last message The issue is a question of which part of the code is responsible for what set of processing. If a library says that an item is either encrypted or signed and it wasn't, or it was unable to apply those transformations on request, then you have a security problem. If you hand the library a piece of garbage and it says that it was not signed (or encrypted) then you do not have a security problem, you have a different type of problem. The same thing is true with the ZIP example you gave earlier. Is the application or the JW* library responsible for dealing with the question of zipping the content? If you say the application is responsible, then it does not matter of the JW* code does not recognize the ZIP parameter. If you say the JW* library is responsible, then it does matter if the JW* code does not recognize the ZIP parameter. You then also have the question should the JW* code have the "right" to apply a ZIP operation even if it was not asked for by the application. It is after all part of the library and thus could be applied at any time. The position of mandatory understanding of fields is much more justifiable if one states that the library is responsible for enforcing everything about the header. This would mean that the concept of a signing time field in the header would not make any sense. The JW* library has no way of knowing what the semantics of the field is going to mean to the application and thus has no method of enforcing it. (Does the object expire a specific amount of time after the signing time? Does there need to be some type of allowance for clock skews? Is there an interaction between a certificate if given and the signing time as a header field? Are there fields in the key container that say when a key can be used and thus need to be enforced?) If on the other hand one believes that there is a possibility that there is auxiliary data which is not part of the content but is part of the context in which the signature (or encryption) was applied, it is impossible for a JW* library to be able to enforce any of this context and it must be deferred to the application for enforcement. To directly address your points below: 1. We owe developers a clear description of what to do with the items that we defined. If an application defines another field, then it will defined what to do with that item and not the JW* code and the application would be expected to enforce the semantics and not the JW* code. It does mean that each application will have its own list of what items can appear, however it does not mean that the JW* code cannot supply a library routine for doing the field name checking. 2. I am completely unable to understand why allowing a field for one application and not for another application hurts interoperability or enforcement of the fields. But as I am doing this in the application, I only have one standard that I am working with (until such a time as the application is updated). 3. If a profile decides that the alg field need not be present, which is different that it's value not being understood, then that is up to the application. As long as the application does not make a security claim about the content that as transmitted that is a perfectly fine thing for it to do. It might just be transmitted as plain unsigned, unencrypted data in the same format as the current JW* formats. There is a different issue involved with the value of the alg field not being understood. That is something that the JW* libraries are perfectly competent to deal with and is not the same type of extension mechanism as we are discussing here. I completely disagree that the option is either not viable, or is a security problem. I think that this is your narrow view of the world affecting how you are evaluating the proposal that I have provided. However as long as you are going to stay in the camp that says there is no auxiliary data which is not part of the content of the message, then your view is a consistent one. I happen to strongly disagree with that view of the world. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Saturday, December 29, 2012 8:25 PM To: 'Mike Jones'; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header fields From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, December 26, 2012 2:32 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header fields That idea seems like it would (1) add to the overall complexity of implementations, (2) would be counter the goal of interoperable implementations, and (3) would likely be counter to goal of security. (1) The way I see it, if an extension mechanism (other than having both parties understand the extension, which already works) is going to be defined, we owe users of the specs a clear definition of how to do not-understood extensions. Otherwise implementations of each profile will potentially have to repeat the work of checking the fields used, rather than doing it in the JOSE libraries themselves, adding to overall implementation complexity. (2) Sometimes allowing fields to be not understood and sometimes requiring them to be, and possibly using different extension mechanisms in different profiles would definitely hurt interoperability. (3) If a profile decided that the "alg" field need not be understood, that would definitely defeat the security purposes of the JOSE specs. The same is true of many other fields. We owe it to users of the specs to be clear that security-critical fields must be understood. "Punting" this to profiles or just putting it in the security considerations unnecessarily risks having profile writers get this wrong. [JLS] I would be shocked if a JWS implementation would report that the signature verified in this case. So I don't think that there is any security issue here. Yes, in theory, we could include a consensus call question giving people this option as well, but unless support for it shows up on the list, it would just seem (to me) to unnecessarily complicate the questions we're asking people by including an option that's not actually viable from a complexity, interoperability, or security point of view. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, December 26, 2012 2:03 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header fields This does not include my recommended approach which is to punt the issue of required headers to the application rather than JOSE. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fields Currently the JOSE specs contain the following language declaring that all header (and some other) fields must be understood: "Implementations MUST understand the entire contents of the header; otherwise, the . MUST be rejected." There's currently an open issue about whether all header fields should be required to be understood by implementations using them or whether to relax this requirement in some circumstances. We would like the working group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be understood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties understand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be understood, but where an explicit list of fields can be designated as "may be ignored if not understood". For instance, an "ign" (may be ignored) member could be defined whose value is an array listing the member names that may be safely ignored if not understood. An example using this field in a JWS header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking implementations. It would maintain the current semantics, while allowing explicit exceptions to be made in cases where the fields are not security-critical and the structure has a meaningful interpretation without them. Representations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding some implementation complexity. 2B. Take an alternative approach where instead of one header object, there would be two header objects. Implementations would be required to understand all fields in the first header object. Implementations would be allowed to ignore fields in the second header object if not understood. An example of this approach, adding the second header object after the first in a JWS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9v biBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9p c19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current spec. The new second field is the base64url encoded representation of the string '{"notes":"This signature need not be checked when the moon is full"}'. PRO: May-be-ignored fields are easily distinguishable from must-be-understood fields. CON: Implementations must consult/merge two sets of headers to understand the meaning/structure of the object, adding some implementation complexity. Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chairs to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to understand? YES - All header fields must continue to be understood by implementations or the input must be rejected. NO - A means of listing that specific header fields may be safely ignored should be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax would you prefer for designating the header fields that may be ignored if not understood? A - Define a header field that explicitly lists the fields that may be safely ignored if not understood. B - Introduce a second header, where implementations must understand all fields in the first but they may ignore not-understood fields in the second. Thanks for considering these questions, Richard Barnes, John Bradley, Mike Jones ------=_NextPart_000_0171_01CDE74C.274DE700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would say probably = not.

 

First, I would allow = applications to state that it is not necessary for all header fields to = be understood.

 

Second, I don’t = believe that the text in the document matches what you have said = below.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Sunday, December 30, 2012 12:21 = AM
To: Jim Schaad; jose@ietf.org
Subject: Re: [jose] = Whether implementations must understand all JOSE header = fields

 

“Must understand” is a requirement = on the system as a whole – not on a particular level of library = software.  It’s perfectly fine for a JOSE library to process = the headers that it understands and then leave the processing of the = rest of them up to the application – which I think is what you are = advocating.  For those headers that the JOSE library doesn’t = understand, the responsibility for fulfilling the “must = understand” requirement for the remaining headers would then fall = to the application.

 

I really don’t = think this is far from what you’re thinking of.  I completely = agree with you that inflexible libraries that reject the input because = they don’t understand all the header values in it without giving = the application a chance to weigh are probably not good software = design.

 

The spec intentionally = doesn’t say anything about implementation layering, nor probably = should it.  It imposes requirements on the complete, end-to-end = system – not particular implementation layers.  At least as I = see it, that’s an inclusive view of what we’re trying to = accomplish – not a narrow one.

 

Does that understanding = move us closer to agreement?  I hope = so…

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;   Best wishes,

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

 

From:= = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Saturday, December 29, 2012 9:59 PM
To: Mike = Jones; jose@ietf.org
Subject: RE: = [jose] Whether implementations must understand all JOSE header = fields

 

I am going to go into more detail than my last = message

 

The issue is a question = of which part of the code is responsible for what set of = processing.

 

If a library says that = an item is either encrypted or signed and it wasn’t, or it was = unable to apply those transformations on request, then you have a = security problem.  If you hand the library a piece of garbage and = it says that it was not signed (or encrypted) then you do not have a = security problem, you have a different type of = problem.

 

The same thing is true = with the ZIP example you gave earlier.  Is the application or the = JW* library responsible for dealing with the question of zipping the = content?  If you say the application is responsible, then it does = not matter of the JW* code does not recognize the ZIP parameter.  = If you say the JW* library is responsible, then it does matter if the = JW* code does not recognize the ZIP parameter.  You then also have = the question should the JW* code have the “right” to apply a = ZIP operation even if it was not asked for by the application.  It = is after all part of the library and thus could be applied at any = time.

 

The position of = mandatory understanding of fields is much more justifiable if one states = that the library is responsible for enforcing everything about the = header.  This would mean that the concept of a signing time field = in the header would not make any sense.  The JW* library has no way = of knowing what the semantics of the field is going to mean to the = application and thus has  no method of enforcing it.  (Does = the object expire a specific amount of time after the signing = time?  Does there need to be some type of allowance for clock = skews?  Is there an interaction between a certificate if given and = the signing time as a header field?  Are there fields in the key = container that say when a key can be used and thus need to be = enforced?) 

 

If on the other hand one = believes that there is a possibility that there is auxiliary data which = is not part of the content but is part of the context in which the = signature (or encryption) was applied, it is impossible for a JW* = library to be able to enforce any of this context and it must be = deferred to the application for enforcement.

 

To directly address your = points below:

 

1.       =  We = owe developers a clear description of what to do with the items that we = defined.  If an application defines another field, then it will = defined what to do with that item and not the JW* code and the = application would be expected to enforce the semantics and not the JW* = code.  It does mean that each application will have its own list of = what items can appear, however it does not mean that the JW* code cannot = supply a library routine for doing the field name = checking.

2.       = I am = completely unable to understand why allowing a field for one application = and not for another application hurts interoperability or enforcement of = the fields.   But as I am doing this in the application, I = only have one standard that I am working with (until such a time as the = application is updated). 

3.       = If a = profile decides that the alg field need not be present, which is = different that it’s value not being understood, then that is up to = the application.  As long as the application does not make a = security claim about the content that as transmitted that is a perfectly = fine thing for it to do.  It might just be transmitted as plain = unsigned, unencrypted data in the same format as the current JW* = formats.  There is a different issue involved with the value of the = alg field not being understood.  That is something that the JW* = libraries are perfectly competent to deal with and is not the same type = of extension mechanism as we are discussing = here.

 

I completely disagree = that the option is either  not viable, or is a security = problem.  I think that this is your narrow view of the world = affecting how you are evaluating the proposal that I have = provided.  However as long as you are going to stay in the camp = that says there is no auxiliary data which is not part of the content of = the message, then your view is a consistent one.  I happen to = strongly disagree with that view of the world.

 

Jim

 

 

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Saturday, December 29, = 2012 8:25 PM
To: 'Mike Jones'; jose@ietf.org
Subject: Re: = [jose] Whether implementations must understand all JOSE header = fields

 

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Wednesday, December 26, = 2012 2:32 PM
To: Jim Schaad; jose@ietf.org
Subject: Re: = [jose] Whether implementations must understand all JOSE header = fields

 

That idea seems like it would (1) add to the = overall complexity of implementations, (2) would be counter the goal of = interoperable implementations, and (3) would likely be counter to goal = of security.

 

(1) The way I see it, if = an extension mechanism (other than having both parties understand the = extension, which already works) is going to be defined, we owe users of = the specs a clear definition of how to do not-understood = extensions.  Otherwise implementations of each profile will = potentially have to repeat the work of checking the fields used, rather = than doing it in the JOSE libraries themselves, adding to overall = implementation complexity.

 

(2)  Sometimes = allowing fields to be not understood and sometimes requiring them to be, = and possibly using different extension mechanisms in different profiles = would definitely hurt interoperability.

 

(3)  If a profile = decided that the “alg” field need not be understood, that = would definitely defeat the security purposes of the JOSE specs.  = The same is true of many other fields.  We owe it to users of the = specs to be clear that security-critical fields must be = understood.  “Punting” this to profiles or just putting = it in the security considerations unnecessarily risks having profile = writers get this wrong.

 

[JLS]  I would be = shocked if a JWS implementation would report that the signature verified = in this case.  So I don’t think that there is any security = issue here.

 

Yes, in theory, we could = include a consensus call question giving people this option as well, but = unless support for it shows up on the list, it would just seem (to me) = to unnecessarily complicate the questions we’re asking people by = including an option that’s not actually viable from a complexity, = interoperability, or security point of view.

 

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

 

From:= = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Wednesday, December 26, 2012 2:03 PM
To: = Mike Jones; jose@ietf.org
Subject: RE: = [jose] Whether implementations must understand all JOSE header = fields

 

This does not include my recommended approach = which is to punt the issue of required headers to the application rather = than JOSE.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 = 10:17 AM
To: jose@ietf.org
Subject: = [jose] Whether implementations must understand all JOSE header = fields

 

Currently = the JOSE specs contain the following language declaring that all header = (and some other) fields must be understood:  “Implementations = MUST understand the entire contents of the header; otherwise, the = … MUST be rejected.”  There's currently an open issue = about whether all header fields should be required to be understood by = implementations using them or whether to relax this requirement in some = circumstances.  We would like the working group to consider the = following potential resolutions to the issue.

 

1.  Maintain the current requirement that all = header fields must be understood by implementations using = them.

 

PRO:  This is a simple rule designed to result = in secure implementations.  Representations of existing JWS & = JWE objects are unchanged.

CON:  Extensibility is limited to cases where = all participating parties understand new fields that are = introduced.

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of = fields can be designated as “may be ignored if not = understood”.  For instance, an “ign” (may be = ignored) member could be defined whose value is an array listing the = member names that may be safely ignored if not understood.  An = example using this field in a JWS header is:

 

    = {"alg":"ES256",

     = "ign":["notes"],

     = "notes":"This signature need not be checked when the moon = is full"

    = }

 

(Obviously, the "ign" field MUST NOT = contain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain = the current semantics, while allowing explicit exceptions to be made in = cases where the fields are not security-critical and the structure has a = meaningful interpretation without them.  Representations of = existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names and = may-be-ignored list, adding some implementation = complexity.

 

2B.  Take an alternative approach where = instead of one header object, there would be two header objects.  = Implementations would be required to understand all fields in the first = header object.  Implementations would be allowed to ignore fields = in the second header object if not understood.  An example of this = approach, adding the second header object after the first in a JWS, = would be:

 

    = eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

    .

    = eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgb= W9vbiBpcyBmdWxsIn0

    .

    = eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvb= S9pc19yb290Ijp0cnVlfQ

    .

    = dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

 

The = first, third, and fourth fields are from the example JWS in the current = spec. The new second field is the base64url encoded representation of = the string '{"notes":"This signature need not be checked = when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily = distinguishable from must-be-understood fields.

CON:  Implementations must consult/merge two = sets of headers to understand the meaning/structure of the object, = adding some implementation complexity.  Existing JWS & JWE = object representations would become invalid.

 

After = a discussion period, we believe that it would be useful for the chairs = to make two formal consensus calls of the following = kind:

 

FIRST POLL:  Should all header fields be = critical for implementations to understand?

YES – All header fields must continue to be = understood by implementations or the input must be = rejected.

NO – A means of = listing that specific header fields may be safely ignored should be = defined.

 

SECOND POLL:  Should the result of the first = poll be "NO", which syntax would you prefer for designating = the header fields that may be ignored if not = understood?

A – Define a = header field that explicitly lists the fields that may be safely ignored = if not understood.

B – = Introduce a second header, where implementations must understand all = fields in the first but they may ignore not-understood fields in the = second.

 

        =             &= nbsp;           &n= bsp;           &nb= sp;   Thanks for considering these = questions,

        &nbs= p;            = ;            =             &= nbsp;  Richard Barnes, John Bradley, Mike Jones

 

 

------=_NextPart_000_0171_01CDE74C.274DE700-- From Michael.Jones@microsoft.com Mon Dec 31 12:54:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D55B21F8428 for ; Mon, 31 Dec 2012 12:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txN+9ZEV9Pgy for ; Mon, 31 Dec 2012 12:54:43 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id E07C221F8737 for ; Mon, 31 Dec 2012 12:54:42 -0800 (PST) Received: from BL2FFO11FD013.protection.gbl (10.173.161.204) by BL2FFO11HUB008.protection.gbl (10.173.160.228) with Microsoft SMTP Server (TLS) id 15.0.586.12; Mon, 31 Dec 2012 20:54:39 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Mon, 31 Dec 2012 20:54:38 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Mon, 31 Dec 2012 20:54:17 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Whether implementations must understand all JOSE header fields Thread-Index: AQHN549DdWjJrN6moUSJsIQyvmcQ25gzX3GA Date: Mon, 31 Dec 2012 20:54:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669F0EFA@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com> <010d01cde645$a3ef3ff0$ebcdbfd0$@augustcellars.com> <011e01cde652$c6ea19f0$54be4dd0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669E0A2A@TK5EX14MBXC283.redmond.corp.microsoft.com> <017001cde78f$35689b80$a039d280$@augustcellars.com> In-Reply-To: <017001cde78f$35689b80$a039d280$@augustcellars.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_4E1F6AAD24975D4BA5B1680429673943669F0EFATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(52604002)(51444002)(56776001)(54356001)(76482001)(16236675001)(54316002)(51856001)(512954001)(55846006)(47976001)(74502001)(56816002)(15202345001)(5343635001)(5343655001)(53806001)(47736001)(74662001)(4396001)(59766001)(47446002)(16406001)(49866001)(31966008)(33656001)(44976002)(77982001)(46102001)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB008; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07126E493C Subject: Re: [jose] Whether implementations must understand all JOSE header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 20:54:51 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943669F0EFATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable About your "first", I understand that we may personally disagree about what= the best answer to that question is. Richard, John, and I had proposed th= e following consensus call question to bring closure to that issue. FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. About your "second", I believe that the text in the document is aligned wit= h my statements, but it could be expanded upon if the working group believe= s that it would be useful. In particular, we could add something like this= in an appropriate place: The requirement that implementations must understand all header parameter v= alues is a requirement on the system as a whole - not on any particular com= ponent or layer of the implementation. Should part of the implementation b= e contained in a library, and if there are be header parameters that the li= brary doesn't understand, the responsibility for fulfilling the "must under= stand" requirement for the remaining header parameters would then fall to t= he application using that library. I believe that that clarification would narrow our disagreement to the cons= ensus call question above, which once posed the working group, we'll achiev= e closure on. Hopefully we can do that in the next week or so, once people= are likely to be back from their holiday break. Best wishes, -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, December 31, 2012 11:44 AM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header= fields I would say probably not. First, I would allow applications to state that it is not necessary for all= header fields to be understood. Second, I don't believe that the text in the document matches what you have= said below. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Sunday, December 30, 2012 12:21 AM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header= fields "Must understand" is a requirement on the system as a whole - not on a part= icular level of library software. It's perfectly fine for a JOSE library t= o process the headers that it understands and then leave the processing of = the rest of them up to the application - which I think is what you are advo= cating. For those headers that the JOSE library doesn't understand, the re= sponsibility for fulfilling the "must understand" requirement for the remai= ning headers would then fall to the application. I really don't think this is far from what you're thinking of. I completel= y agree with you that inflexible libraries that reject the input because th= ey don't understand all the header values in it without giving the applicat= ion a chance to weigh are probably not good software design. The spec intentionally doesn't say anything about implementation layering, = nor probably should it. It imposes requirements on the complete, end-to-en= d system - not particular implementation layers. At least as I see it, tha= t's an inclusive view of what we're trying to accomplish - not a narrow one= . Does that understanding move us closer to agreement? I hope so... Best wishes, -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, December 29, 2012 9:59 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header= fields I am going to go into more detail than my last message The issue is a question of which part of the code is responsible for what s= et of processing. If a library says that an item is either encrypted or signed and it wasn't,= or it was unable to apply those transformations on request, then you have = a security problem. If you hand the library a piece of garbage and it says= that it was not signed (or encrypted) then you do not have a security prob= lem, you have a different type of problem. The same thing is true with the ZIP example you gave earlier. Is the appli= cation or the JW* library responsible for dealing with the question of zipp= ing the content? If you say the application is responsible, then it does n= ot matter of the JW* code does not recognize the ZIP parameter. If you say= the JW* library is responsible, then it does matter if the JW* code does n= ot recognize the ZIP parameter. You then also have the question should the= JW* code have the "right" to apply a ZIP operation even if it was not aske= d for by the application. It is after all part of the library and thus cou= ld be applied at any time. The position of mandatory understanding of fields is much more justifiable = if one states that the library is responsible for enforcing everything abou= t the header. This would mean that the concept of a signing time field in = the header would not make any sense. The JW* library has no way of knowing= what the semantics of the field is going to mean to the application and th= us has no method of enforcing it. (Does the object expire a specific amou= nt of time after the signing time? Does there need to be some type of allo= wance for clock skews? Is there an interaction between a certificate if gi= ven and the signing time as a header field? Are there fields in the key co= ntainer that say when a key can be used and thus need to be enforced?) If on the other hand one believes that there is a possibility that there is= auxiliary data which is not part of the content but is part of the context= in which the signature (or encryption) was applied, it is impossible for a= JW* library to be able to enforce any of this context and it must be defer= red to the application for enforcement. To directly address your points below: 1. We owe developers a clear description of what to do with the items= that we defined. If an application defines another field, then it will de= fined what to do with that item and not the JW* code and the application wo= uld be expected to enforce the semantics and not the JW* code. It does mea= n that each application will have its own list of what items can appear, ho= wever it does not mean that the JW* code cannot supply a library routine fo= r doing the field name checking. 2. I am completely unable to understand why allowing a field for one a= pplication and not for another application hurts interoperability or enforc= ement of the fields. But as I am doing this in the application, I only ha= ve one standard that I am working with (until such a time as the applicatio= n is updated). 3. If a profile decides that the alg field need not be present, which = is different that it's value not being understood, then that is up to the a= pplication. As long as the application does not make a security claim abou= t the content that as transmitted that is a perfectly fine thing for it to = do. It might just be transmitted as plain unsigned, unencrypted data in th= e same format as the current JW* formats. There is a different issue invol= ved with the value of the alg field not being understood. That is somethin= g that the JW* libraries are perfectly competent to deal with and is not th= e same type of extension mechanism as we are discussing here. I completely disagree that the option is either not viable, or is a securi= ty problem. I think that this is your narrow view of the world affecting h= ow you are evaluating the proposal that I have provided. However as long a= s you are going to stay in the camp that says there is no auxiliary data wh= ich is not part of the content of the message, then your view is a consiste= nt one. I happen to strongly disagree with that view of the world. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Saturday, December 29, 2012 8:25 PM To: 'Mike Jones'; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header= fields From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, December 26, 2012 2:32 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header= fields That idea seems like it would (1) add to the overall complexity of implemen= tations, (2) would be counter the goal of interoperable implementations, an= d (3) would likely be counter to goal of security. (1) The way I see it, if an extension mechanism (other than having both par= ties understand the extension, which already works) is going to be defined,= we owe users of the specs a clear definition of how to do not-understood e= xtensions. Otherwise implementations of each profile will potentially have= to repeat the work of checking the fields used, rather than doing it in th= e JOSE libraries themselves, adding to overall implementation complexity. (2) Sometimes allowing fields to be not understood and sometimes requiring= them to be, and possibly using different extension mechanisms in different= profiles would definitely hurt interoperability. (3) If a profile decided that the "alg" field need not be understood, that= would definitely defeat the security purposes of the JOSE specs. The same= is true of many other fields. We owe it to users of the specs to be clear= that security-critical fields must be understood. "Punting" this to profi= les or just putting it in the security considerations unnecessarily risks h= aving profile writers get this wrong. [JLS] I would be shocked if a JWS implementation would report that the sig= nature verified in this case. So I don't think that there is any security = issue here. Yes, in theory, we could include a consensus call question giving people th= is option as well, but unless support for it shows up on the list, it would= just seem (to me) to unnecessarily complicate the questions we're asking p= eople by including an option that's not actually viable from a complexity, = interoperability, or security point of view. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, December 26, 2012 2:03 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header= fields This does not include my recommended approach which is to punt the issue of= required headers to the application rather than JOSE. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Friday, December 14, 2012 10:17 AM To: jose@ietf.org Subject: [jose] Whether implementations must understand all JOSE header fie= lds Currently the JOSE specs contain the following language declaring that all = header (and some other) fields must be understood: "Implementations MUST u= nderstand the entire contents of the header; otherwise, the ... MUST be rej= ected." There's currently an open issue about whether all header fields sh= ould be required to be understood by implementations using them or whether = to relax this requirement in some circumstances. We would like the working= group to consider the following potential resolutions to the issue. 1. Maintain the current requirement that all header fields must be underst= ood by implementations using them. PRO: This is a simple rule designed to result in secure implementations. = Representations of existing JWS & JWE objects are unchanged. CON: Extensibility is limited to cases where all participating parties und= erstand new fields that are introduced. 2A. Take an alternative approach where, by default, all fields must be und= erstood, but where an explicit list of fields can be designated as "may be = ignored if not understood". For instance, an "ign" (may be ignored) member= could be defined whose value is an array listing the member names that may= be safely ignored if not understood. An example using this field in a JWS= header is: {"alg":"ES256", "ign":["notes"], "notes":"This signature need not be checked when the moon is full" } (Obviously, the "ign" field MUST NOT contain the value "ign".) PRO: This would enable adding non-critical header fields without breaking = implementations. It would maintain the current semantics, while allowing e= xplicit exceptions to be made in cases where the fields are not security-cr= itical and the structure has a meaningful interpretation without them. Rep= resentations of existing JWS & JWE objects are unchanged. CON: Requires coordination of field names and may-be-ignored list, adding = some implementation complexity. 2B. Take an alternative approach where instead of one header object, there= would be two header objects. Implementations would be required to underst= and all fields in the first header object. Implementations would be allowe= d to ignore fields in the second header object if not understood. An examp= le of this approach, adding the second header object after the first in a J= WS, would be: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGU= gbW9vbiBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmN= vbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk The first, third, and fourth fields are from the example JWS in the current= spec. The new second field is the base64url encoded representation of the = string '{"notes":"This signature need not be checked when the moon is full"= }'. PRO: May-be-ignored fields are easily distinguishable from must-be-underst= ood fields. CON: Implementations must consult/merge two sets of headers to understand = the meaning/structure of the object, adding some implementation complexity.= Existing JWS & JWE object representations would become invalid. After a discussion period, we believe that it would be useful for the chair= s to make two formal consensus calls of the following kind: FIRST POLL: Should all header fields be critical for implementations to un= derstand? YES - All header fields must continue to be understood by implementations o= r the input must be rejected. NO - A means of listing that specific header fields may be safely ignored s= hould be defined. SECOND POLL: Should the result of the first poll be "NO", which syntax wou= ld you prefer for designating the header fields that may be ignored if not = understood? A - Define a header field that explicitly lists the fields that may be safe= ly ignored if not understood. B - Introduce a second header, where implementations must understand all fi= elds in the first but they may ignore not-understood fields in the second. Thanks for considering thes= e questions, Richard Barnes, John Bradle= y, Mike Jones --_000_4E1F6AAD24975D4BA5B1680429673943669F0EFATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

About your “firs= t”, I understand that we may personally disagree about what the best = answer to that question is.  Richard, John, and I had proposed the fol= lowing consensus call question to bring closure to that issue.

 

FIRST POLL:  Shou= ld all header fields be critical for implementations to understand?

YES – All header= fields must continue to be understood by implementations or the input must= be rejected.

NO – A means of = listing that specific header fields may be safely ignored should be defined= .

 

About your “seco= nd”, I believe that the text in the document is aligned with my state= ments, but it could be expanded upon if the working group believes that it = would be useful.  In particular, we could add something like this in an appropriate place:

 

The requirement that implementations must understand all header parameter values is a requi= rement on the system as a whole – not on any particular component or = layer of the implementation.  Should part of the implementation be con= tained in a library, and if there are be header parameters that the library doesn’t understand, the responsibility f= or fulfilling the “must understand” requirement for the remaini= ng header parameters would then fall to the application using that library.=

 

I believe that that cl= arification would narrow our disagreement to the consensus call question ab= ove, which once posed the working group, we’ll achieve closure on.&nb= sp; Hopefully we can do that in the next week or so, once people are likely to be back from their holiday break.=

 

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

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Monday, December 31, 2012 11:44 AM
To: Mike Jones; jose@ietf.org
Subject: RE: [jose] Whether implementations must understand all JOSE= header fields

 

I would say probably n= ot.

 

First, I would allow a= pplications to state that it is not necessary for all header fields to be u= nderstood.

 

Second, I don’t = believe that the text in the document matches what you have said below.

 

Jim<= /p>

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Sunday, December 30, 2012 12:21 AM
To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE= header fields

 

“Must understand= ” is a requirement on the system as a whole – not on a particul= ar level of library software.  It’s perfectly fine for a JOSE li= brary to process the headers that it understands and then leave the processing of the rest of them up to the application – which I think= is what you are advocating.  For those headers that the JOSE library = doesn’t understand, the responsibility for fulfilling the “must= understand” requirement for the remaining headers would then fall to the application.

 

I really don’t t= hink this is far from what you’re thinking of.  I completely agr= ee with you that inflexible libraries that reject the input because they do= n’t understand all the header values in it without giving the application a chance to weigh are probably not good software design.

 

The spec intentionally= doesn’t say anything about implementation layering, nor probably sho= uld it.  It imposes requirements on the complete, end-to-end system &#= 8211; not particular implementation layers.  At least as I see it, that’s an inclusive view of what we’re trying to = accomplish – not a narrow one.

 

Does that understandin= g move us closer to agreement?  I hope so…

 

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

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com= ]
Sent: Saturday, December 29, 2012 9:59 PM
To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE= header fields

 

I am going to go into = more detail than my last message

 

The issue is a questio= n of which part of the code is responsible for what set of processing.=

 

If a library says that= an item is either encrypted or signed and it wasn’t, or it was unabl= e to apply those transformations on request, then you have a security probl= em.  If you hand the library a piece of garbage and it says that it was not signed (or encrypted) then you do not have a s= ecurity problem, you have a different type of problem.

 

The same thing is true= with the ZIP example you gave earlier.  Is the application or the JW*= library responsible for dealing with the question of zipping the content? =  If you say the application is responsible, then it does not matter of the JW* code does not recognize the ZIP paramet= er.  If you say the JW* library is responsible, then it does matter if= the JW* code does not recognize the ZIP parameter.  You then also hav= e the question should the JW* code have the “right” to apply a ZIP operation even if it was not asked for = by the application.  It is after all part of the library and thus coul= d be applied at any time.

 

The position of mandat= ory understanding of fields is much more justifiable if one states that the= library is responsible for enforcing everything about the header.  Th= is would mean that the concept of a signing time field in the header would not make any sense.  The JW* library h= as no way of knowing what the semantics of the field is going to mean to th= e application and thus has  no method of enforcing it.  (Does the= object expire a specific amount of time after the signing time?  Does there need to be some type of allowance for c= lock skews?  Is there an interaction between a certificate if given an= d the signing time as a header field?  Are there fields in the key con= tainer that say when a key can be used and thus need to be enforced?) 

 

If on the other hand o= ne believes that there is a possibility that there is auxiliary data which = is not part of the content but is part of the context in which the signatur= e (or encryption) was applied, it is impossible for a JW* library to be able to enforce any of this context and= it must be deferred to the application for enforcement.<= /p>

 

To directly address yo= ur points below:

 

1.&n= bsp;      We owe d= evelopers a clear description of what to do with the items that we defined.=   If an application defines another field, then it will defined what t= o do with that item and not the JW* code and the application would be expected to enforce the semantics and not the JW*= code.  It does mean that each application will have its own list of w= hat items can appear, however it does not mean that the JW* code cannot sup= ply a library routine for doing the field name checking.

2.&n= bsp;     I am completel= y unable to understand why allowing a field for one application and not for= another application hurts interoperability or enforcement of the fields. &= nbsp; But as I am doing this in the application, I only have one standard that I am working with (until such a time as the = application is updated). 

3.&n= bsp;     If a profile d= ecides that the alg field need not be present, which is different that it&#= 8217;s value not being understood, then that is up to the application. = ; As long as the application does not make a security claim about the content that as transmitted that is a perfectly f= ine thing for it to do.  It might just be transmitted as plain unsigne= d, unencrypted data in the same format as the current JW* formats.  Th= ere is a different issue involved with the value of the alg field not being understood.  That is something that = the JW* libraries are perfectly competent to deal with and is not the same = type of extension mechanism as we are discussing here.

 

I completely disagree = that the option is either  not viable, or is a security problem. = I think that this is your narrow view of the world affecting how you are e= valuating the proposal that I have provided.  However as long as you are going to stay in the camp that says there is no= auxiliary data which is not part of the content of the message, then your = view is a consistent one.  I happen to strongly disagree with that vie= w of the world.

 

Jim<= /p>

 

 

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Saturday, December 29, 2012 8:25 PM
To: 'Mike Jones'; jose@ietf.org=
Subject: Re: [jose] Whether implementations must understand all JOSE= header fields

 

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, December 26, 2012 2:32 PM
To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE= header fields

 

That idea seems like i= t would (1) add to the overall complexity of implementations, (2) would be = counter the goal of interoperable implementations, and (3) would likely be = counter to goal of security.

 

(1) The way I see it, = if an extension mechanism (other than having both parties understand the ex= tension, which already works) is going to be defined, we owe users of the s= pecs a clear definition of how to do not-understood extensions.  Otherwise implementations of each profile= will potentially have to repeat the work of checking the fields used, rath= er than doing it in the JOSE libraries themselves, adding to overall implem= entation complexity.

 

(2)  Sometimes al= lowing fields to be not understood and sometimes requiring them to be, and = possibly using different extension mechanisms in different profiles would d= efinitely hurt interoperability.

 

(3)  If a profile= decided that the “alg” field need not be understood, that woul= d definitely defeat the security purposes of the JOSE specs.  The same= is true of many other fields.  We owe it to users of the specs to be clear that security-critical fields must be understood.  = “Punting” this to profiles or just putting it in the security c= onsiderations unnecessarily risks having profile writers get this wrong.

 

[JLS]  I would be= shocked if a JWS implementation would report that the signature verified i= n this case.  So I don’t think that there is any security issue = here.

 

Yes, in theory, we cou= ld include a consensus call question giving people this option as well, but= unless support for it shows up on the list, it would just seem (to me) to = unnecessarily complicate the questions we’re asking people by including an option that’s not actually= viable from a complexity, interoperability, or security point of view.

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com= ]
Sent: Wednesday, December 26, 2012 2:03 PM
To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE= header fields

 

This does not include = my recommended approach which is to punt the issue of required headers to t= he application rather than JOSE.

 

Jim<= /p>

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE hea= der fields

 

Currently the JOSE specs contain the following la= nguage declaring that all header (and some other) fields must be understood= :  “Implementations MUST understand the entire contents of the h= eader; otherwise, the … MUST be rejected.”  There's currently an open issue about whether all header fields should be required= to be understood by implementations using them or whether to relax this re= quirement in some circumstances.  We would like the working group to c= onsider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that al= l header fields must be understood by implementations using them.

 

PRO:  This is a simple rule designed to resu= lt in secure implementations.  Representations of existing JWS & J= WE objects are unchanged.

CON:  Extensibility is limited to cases wher= e all participating parties understand new fields that are introduced.=

 

2A.  Take an alternative approach where, by = default, all fields must be understood, but where an explicit list of field= s can be designated as “may be ignored if not understood”. = ; For instance, an “ign” (may be ignored) member could be defined whose value is an array listing the member names that may be safel= y ignored if not understood.  An example using this field in a JWS hea= der is:

 

    {"alg":"ES256&q= uot;,

     "ign":["n= otes"],

     "notes":"= This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT co= ntain the value "ign".)

 

PRO:  This would enable adding non-critical = header fields without breaking implementations.  It would maintain the= current semantics, while allowing explicit exceptions to be made in cases = where the fields are not security-critical and the structure has a meaningful interpretation without them.  Represen= tations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names a= nd may-be-ignored list, adding some implementation complexity.

 

2B.  Take an alternative approach where inst= ead of one header object, there would be two header objects.  Implemen= tations would be required to understand all fields in the first header obje= ct.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of = this approach, adding the second header object after the first in a JWS, wo= uld be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOi= JIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dX= JlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOj= EzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r= _wW1gFWFOEjXk

 

The first, third, and fourth fields are from the = example JWS in the current spec. The new second field is the base64url enco= ded representation of the string '{"notes":"This signature n= eed not be checked when the moon is full"}'.

 

PRO:  May-be-ignored fields are easily disti= nguishable from must-be-understood fields.

CON:  Implementations must consult/merge two= sets of headers to understand the meaning/structure of the object, adding = some implementation complexity.  Existing JWS & JWE object represe= ntations would become invalid.

 

After a discussion period, we believe that it wou= ld be useful for the chairs to make two formal consensus calls of the follo= wing kind:

 

FIRST POLL:  Should all header fields be cri= tical for implementations to understand?

YES – All header fields must continue to be= understood by implementations or the input must be rejected.

NO – A means of listing that specific heade= r fields may be safely ignored should be defined.

 

SECOND POLL:  Should the result of the first= poll be "NO", which syntax would you prefer for designating the = header fields that may be ignored if not understood?

A – Define a header field that explicitly l= ists the fields that may be safely ignored if not understood.

B – Introduce a second header, where implem= entations must understand all fields in the first but they may ignore not-u= nderstood fields in the second.

 

         =             &nb= sp;            =             &nb= sp; Thanks for considering these questions,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  Richard Barnes, John Bradley, Mike Jones

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943669F0EFATK5EX14MBXC283r_--