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

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

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

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

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

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

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

Brows= er support for WebCrypto is still iffy. See http://caniuse.com/#feat=3Dcryp= tography.

Notably, all the Android Browser= s before Android L (5.0) do not support WebCrypto, and there are tons of th= em out there.=C2=A0 They will be there for years.
There are many enterprise deployments of IE below 10, which are not go= ing to be upgraded anytime soon.

PHP started supporting SPKI in ver.= 5.6, which was released Aug. 28, 2014. Its deployment is very small as you= can expect - 0.7%.=C2=A0 Server platforms do not do major version upgrades= frequently.=C2=A0 See http://w3techs.com/technologies/details= /pl-php/5/all.
Pyth= on seems to have been supporting SPKI for sometime as a NetscapeSPKI object= .
So does Ruby.

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

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

Best,

Nat

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

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

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

S.

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

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en

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

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

The specification is available at:

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

An HTML formatted version is also available at:=

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

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

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

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

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

Thanks again for your = consistent attention to detail!

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

Couple more comments:

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

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

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

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

=
3.    &nb=
sp;  This statement from s=
ection 4
   “Use of escaped characters in the inp=
ut JWK representation SHOULD be avoided.
Does not agree wit=
h the statement from section 3.3
    “Charac=
ters in member names and member values MUST be represented without being es=
caped.”
While I assume that the statement in section =
4 is to apply to values, it does not say so.

This is now (hopefully) clarified through t=
he following language:

       &=
nbsp;            Use=
 of escaped characters in JWKs for which JWK Thumbprints will be computed s=
hould be avoided.

       &=
nbsp;            (Us=
e of escaped characters in the hash input JWKs derived from these original =
JWKs is prohibited.)

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

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

Jim

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

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

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

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

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

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

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

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

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

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

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

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

o 159 – 0x81 0x9f

o 9 – 0x09

o 0 – 0x00

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

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

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

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

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

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

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

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

o 290 – 0x82 0x01 0x22

o 257 – 0x82 0x01 0x01

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

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

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

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

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

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

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

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

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

· How are elliptic curve keys represented?

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

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

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

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

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

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

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

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

Hey Mike,

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

---= --BEGIN-----

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

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

-----END-----

<= /div>

This is pretty much the encoding design philosophy embraced by PK= CS#1 itself:

https://tools.ietf.org/html/rfc3447#section-9= .2

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

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

--Richard

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

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

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

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

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

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

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

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

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

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

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

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

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

=C2=A0

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

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

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

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

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

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

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

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

=C2=A0

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

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

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

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

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

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

=C2=A0

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

=C2=A0

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

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

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

=C2=A0

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

=C2=A0

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

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

=C2=A0

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

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

Inline…

<= /div>

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, March 11, 2015 at 1:16 AM<= /div>

<snip>

Things I haven’t yet learned that I&#= 8217;d need to know to really write this code:

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

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

<= div>

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

Mu= ltiple OIDs are never present before the ASN.1 NULL here (nor is are the par= ameters represented as ASN.1 NULL for other algorithms). The structure= is AlgorithmIdentifier as defined below. If multiple OIDs were permitted th= e algorithm field would be SEQUENCE or SET but it’s not.

   AlgorithmIdentifi=
er  ::=3D  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

<= pre class=3D"newpage" style=3D"font-size: 1em; margin-top: 0px; margin-bottom: 0= px; page-break-before: always; widows: 1;">

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

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

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

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

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

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

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

We have something similar as well...=C2=A0

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

Vladimir

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

--

Vladimir Dzhuvinov :: vladimir@connect2id.com

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

--
=

Nat Sakimura (=3Dnat)

Chairman, OpenID F= oundation
http://= nat.sakimura.org/
@_nat_en

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

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

Thanks,

Vladimir

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

Dear all,

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

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

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

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

Let us know what you think about it...

BR, Luigi.

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

-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com

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

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

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

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

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

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

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

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

o 0 – 0x00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Example: HS= 256 1.2.840.113549.2.9

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

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

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

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

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

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

<= o:p>

James Manger

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

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

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

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

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

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

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

&n= bsp;

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

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

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

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

o 159 – 0x81 0x9f

o 9 – 0x09

o 0 – 0x00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Example: HS256 1.2.840.113549.2.9<= /p>

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

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

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

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

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

James Manger

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

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

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

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

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

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

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

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

Jim

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

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

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

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

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

Feedback = welcomed.

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

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

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

I was simply going to note with bemusement that exact= ly this eventuality was foreseen by those of us that favored a more general= approach to key wrapping [0][1].=C2=A0 Those that dismissed that idea have= made their bed full of complexity, and now they are lying in it.

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

[0] http://tools.ietf.org/agenda/85/sl= ides/slides-85-jose-7.pdf
[1] http://tools.ietf.org/agenda/86/slides/sl= ides-86-jose-0.pdf

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

I cannot respond for Richard, but pe= rsonally I feel rather insulted by the current draft.=C2=A0 My first half a= dozen responses were rather vulgar and pejorative to this draft and thus d= eleted.
=C2=A0
This draft seems to be, more or less, what Richard and I= were proposing in Denver and were told was not possible due to backwards c= ompatibility.=C2=A0 What has changed that this is no longer true?=
= =C2=A0
Why is there=C2=A0 need to have a compact formation for this draft?=C2=A0= We were told in no uncertain terms that this was completely unnecessary in= Denver and thus was out of scope for the documents.
=C2=A0=
This docume= nt does not seem to have read the security considerations section of the JW= S draft specifically dealing with the existence of multiple sharers of the = secret key.
=C2=A0
This document has messed up the current documentatio= n in JWE about how to determine what type of document is being presented.= =C2=A0 This is completely unacceptable.
=C2=A0
There are now multiple r= epresentations of direct keying for mac.=C2=A0 This is a significant proble= m as one does not know which of the version one is supposed to be using.=
= =C2=A0
(The fact that I am half, if not all the way drunk has make this m= essage much easier to write).
=C2=A0
Jim
=C2=A0<= /p>
=C2=A0
From= : jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike J= ones
Sent: Tuesday, March 03, 2015 2:42 AM
To: jose@ietf.org
Subject= : [jose] Key Managed JSON Web Signature (KMJWS) specification=
=C2=A0
I took a little time today and= wrote a short draft specifying a JWS-like object that uses key management = for the MAC key used to integrity protect the payload.=C2=A0 We had conside= red doing this in JOSE issue #2 but didn=E2=80=99t do so at the tim= e because of lack of demand.=C2=A0 However, I wanted to get this down now t= o demonstrate that it is easy to do and specify a way to do it, should dema= nd develop in the future =E2=80=93 possibly after the JOSE working group has been closed.=C2=A0 See http://tools.= ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jon= es-jose-key-managed-json-web-signature-00.html.
=C2=A0
This spec r= euses key management functionality already present in the JWE spec and MAC functionality already present in the JWS spec.=C2=A0 The result is essentially a JWS with an Encrypted Key = value added, and a new =E2=80=9Cmac=E2=80=9D Header Parameter value representing the MAC al= gorithm used.=C2=A0 (Like JWE, the key management algorithm is carried in t= he =E2=80=9Calg= =E2=80=9D Header Parameter value.)
= =C2=A0
I also wrote this now as pos= sible input into our thinking on options for creating a CBOR JOSE mapping.=C2=A0 = If there are CBOR use cases needing managed MAC keys, this could help us re= ason about ways to structure the solution.
=C2=A0
Yes, the spec name a= nd abbreviation are far from catchy.=C2=A0 Better naming ideas would be gre= at.
=C2=A0
Feedback welcomed.
= =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
P.S.=C2=A0 This note was al= so posted at http://self-issued.info/?p=3D1344 and as @selfissued.
=C2=A0

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

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

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

=C2=A0
>> Things I learned by looking at th= ese 1024-bit RSA public key representations included:<= /p>
=C2=B7= =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ASN.1 uses byte-aligned Tag-Length-Value encodings.
=C2= =B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The tags for SEQUENCE, OID, NULL, BIT STRING, and INTEGER are respe= ctively 0x30, 0x06, 0x05, 0x03, and 0x02.
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 These L= ength values are encoded as follows:
o=C2=A0=C2=A0 159 =E2= =80=93 0x81 0x9f
o=C2=A0=C2=A0 9 =E2=80=93 0x09
o=C2=A0=C2=A0 0 =E2=80=93 0x00
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The OID 1.2.840.= 113549.1.1.1 is encoded in 9 bytes as 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x= 01 0x01.
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The OID is followed by an ASN.1 NULL - 0x0= 5 0x00.
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The RSA Key is represented as an encapsulat= ed bit field.
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is an apparently unused zero by= te (the 22^nd byte of the SPKI field in the RFC 7250 example) as = the first byte of this bit field.
=C2=A0
The ASN.1 BIT STRING is DER-encoded as:
|Tag|Len =C2=A0|Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
|=C2=A0=C2=A0 |=C2=A0 =C2=A0=C2=A0=C2=A0|Unused-bit-count=C2=A0 Bits-= paddeded-with-0-bits |
| 03| 818D| 00= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A030818902=E2=80=A6 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2= =A0
=C2=A0
For a BIT SRING, the value pa= rt of the tag-length-value starts with 1 byte that holds the number of unus= ed bits in the last byte of the value.
As an example, the = 7 bits 1110001 are DER-encoded as 03(tag) 02(length) 01(unused bit count) E= 2(bits plus 1 unused bit)
=C2=A0
=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The rest of the bit field contains concatenated representa= tions of the modulus and the exponent as ASN.1 INTEGERs.
<= u>=C2=A0
The modulus and exponent are encapsulated in = a SEQUENCE (tag byte 0x30), not just concatenated.
=
=C2=A0
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = The 1024 bit modulus is represent= ed in 129 bytes, with the first byte being zero.
=C2=A0
In= tegers are represented in 2=E2=80=99s-complement to handle positive and neg= ative integers. If the top bit of the first byte is 1 you have a negative i= nteger. Hence, you need an extra leading 0x00 byte for some positive intege= rs.
=C2=A0
= > RSA_2048_PREFIX =3D "30820122300D06092A864886F70D0101010500038201= 0F003082010A02820101";

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

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

--Richard

=C2= =A0

=C2=A0
=C2= =B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 How are the OIDs in the table at ht= tp://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A<= /a> represented as ASN.1 OID values?
=C2=A0
<= p style=3D"margin-left:0cm">Ex= ample: HS256=C2=A0=C2=A0 1.2.840.113549.2.9
= =C2=A0
Believe it or not, the first step to DER-encode an O= ID is to convert the first two numbers (1.2.) to a single number. Multiple = the first by 40 and add the second: 1*40 + 2 =3D 42 =3D 0x2A (aren=E2=80=99= t standards great ;). Now 42 and the following four numbers are each repres= ented with a variable-length encoding: 7 bits per byte; 8^th bit = (most significant bit) indicates if there are more bytes to follow.<= u>
Example: 113549 =3D 6*2^14 + 119 * 2^7 + 13 =3D> encoded= in 3 bytes 86 F7 0D, which you can see in the middle of RSA_2048_PREFIX ab= ove.
=C2=A0
P.S. The draft sp= lits the number 113549 (and JCA labels) over two lines. Yuck. Might be bett= er to put the XML DSIG uris in a separate table to avoid wrapping.
=C2=A0
= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Is ther= e always the apparently unused zero byte in the key representation or if no= t, when is it present and absent?
=C2=A0
Whenever you put a whole number of bytes into a BIT STRING you get t= he 0x00 byte as there are no unused bits.
=C2=A0
=C2=A0
--
James Manger<= u>

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

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

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

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

Replies to your specif= ic points follow inline…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Jim

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

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

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

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

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

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

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

Feedback welcomed.

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

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

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

flattened is not the same as compact FWIW

compact = -> https://tools.ietf.org/html/draft-ietf-jose-json-web-s= ignature-41#section-7.1

flattened -> https:/= /tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.2.2

On Thu= , Mar 12, 2015 at 8:08 AM, Justin Richer jricher@mit.edu> wro= te:

Just to add some perspective, if by = =E2=80=9Cflattened=E2=80=9D serialization, you mean the compact serializati= ons of JWS (header.payload.signature) and JWE (header.stuff.stuff.stuff.stu= ff I forgot the order), then there are huge advantages to these, and they= =E2=80=99re the only ones that I personally use.

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

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

=C2=A0=E2=80=94 Justin

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

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

--001a1140fa20146b4505111880e7-- From nobody Thu Mar 12 08:38:46 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C671A88F0 for ; Thu, 12 Mar 2015 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBXX0ukBh4nX for ; Thu, 12 Mar 2015 08:38:37 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4901A88E3 for

What do you consider to be clear text signatures? Would you consider carrying a payload that is a JSON string which is not base64-ed to be plain text? I.e. {"signature":"abc...def", "payload":"{'tag1':'value1','tag2':'value2'}", "headers":"...."} The item to be signed is not at the top level, but it is readable by humans.

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

Yes, I think so. As you can see "there are many roads to Rome" :-) One school says: "You must canonicalize data in a similar way as for XML", while another school claim that "Canonicalization is lunacy!". Full canonicalization like in the I-D above forces you to use a

to maintain strict property input/creation order became obvious. I'm currently not considering an IETF process, it seems like a better idea establishing this scheme through open source and actual usage :-) JCS was designed for supporting complex signature systems like: https://openkeystore.googlecode.com/svn/wcpp-payment- demo/trunk/docs/messages.html#UserSignedAuthorization Regards, Anders

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

I would actually vote for replacing the flatened JSON serialisation with one, that provides a real benefit. Taken up on a discussion I read earlier on the list, wouldn't it be more sensible to have a

This would of course require some form of normalisation/canonicalisaton as used e.g. in XML Security. Still, this would be something valuable to have and a real distinguishing point in comparison to the other serialisations. If people think that this is worth a discussion, then maybe we should kick-off an explicit thread on it.

Human-readable JSON signatures is a reality although not as an IETF standard. Since nobody is interested in bringing in the complexity of XML DSig normalization, there seems to be some possible routes ahead. Phillip Hallam-Baker have proposed a scheme based on separating the payload and the signature where the payload is used "verbatim" reducing normalization and canonicalization to exactly ZERO: http://www.ietf.org/mail-archive/web/acme/current/msg00224.html I have FWIW designed and also implemented a scheme which is based on JSON's intrinsic normalization (white-space removal + character escapes) but adds the constraint that a verifier honors the property order of the serialized object: https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html Since a JSON parser-core typically is less than 500 lines of fairly simple code I don't see that upgrading existing parsers with an ordered dictionary would be a show-stopper. It surely didn't stop me at least :-) Runnable Java+JavaScript implementation: https://mobilepki.org/jcs Partial Python implementation: https://code.google.com/p/openkeystore/source/browse/python/trunk/src /org/webpki/json/JCSValidator.py Minimal .NET implementation: https://code.google.com/p/openkeystore/source/browse/resources/trunk/ docs/JCSDemo.cs Cheers, Anders

Of = possible usefulness for Jose.=C2=A0 RFC:=C2=A0http://www.rfc-editor.org/rfc/rfc7493.txt

A few words of back= ground:=C2=A0https://www.tbray.org/ongoing/When/201x/2015/03/23/i-json

= - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbra= y)

--089e0141a73a7918010512232ced-- From nobody Wed Mar 25 14:08:15 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46AF1A00BE for ; Wed, 25 Mar 2015 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgRCQhWHhktU for ; Wed, 25 Mar 2015 14:08:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFD21A9008 for ; Wed, 25 Mar 2015 14:08:11 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.125.14; Wed, 25 Mar 2015 21:07:52 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Wed, 25 Mar 2015 21:07:52 +0000 From: Mike Jones To: Tim Bray , jose Thread-Topic: [jose] RFC 7493 Thread-Index: AQHQZz65BSAX0i1CVUiI+dlb+9ijEJ0tsInw Date: Wed, 25 Mar 2015 21:07:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:d9af:fdfd:457b:505e] authentication-results: textuality.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(122556002)(74316001)(86362001)(86612001)(2900100001)(16236675004)(19625215002)(92566002)(2950100001)(76576001)(40100003)(99286002)(46102003)(19300405004)(77096005)(15975445007)(102836002)(19580405001)(76176999)(33656002)(77156002)(54356999)(87936001)(19580395003)(2656002)(50986999)(106116001)(19609705001)(5880100001)(19617315012)(107886001)(3826002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 052670E5A4 Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4422F70D5DEB31304A6604AF50B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 21:07:52.4727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [jose] RFC 7493 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:08:14 -0000 --_000_BY2PR03MB4422F70D5DEB31304A6604AF50B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uZ3JhdHVsYXRpb25zIG9uIGNvbXBsZXRpb24gb2YgdGhlIEktSlNPTiBSRkMsIFRpbSENCg0K Rm9yIHdoYXQgaXTigJlzIHdvcnRoLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDMgYWxyZWFkeSBoYXMgYW4gaW5mb3JtYXRpdmUgcmVm ZXJlbmNlIHRvIEktSlNPTi4gIFdl4oCZbGwgdXBkYXRlIHRoaXMgdG8gdXBkYXRlIHRoZSBSRkMg d2l0aCB0aGUgbmV4dCByZXZpc2lvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9t OiBqb3NlIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGltIEJy YXkNClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjUsIDIwMTUgMzo1OSBQTQ0KVG86IGpvc2UNClN1 YmplY3Q6IFtqb3NlXSBSRkMgNzQ5Mw0KDQpPZiBwb3NzaWJsZSB1c2VmdWxuZXNzIGZvciBKb3Nl LiAgUkZDOiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3NDkzLnR4dA0KQSBmZXcg d29yZHMgb2YgYmFja2dyb3VuZDogaHR0cHM6Ly93d3cudGJyYXkub3JnL29uZ29pbmcvV2hlbi8y MDF4LzIwMTUvMDMvMjMvaS1qc29uDQoNCi0tDQotIFRpbSBCcmF5IChJZiB5b3XigJlkIGxpa2Ug dG8gc2VuZCBtZSBhIHByaXZhdGUgbWVzc2FnZSwgc2VlIGh0dHBzOi8va2V5YmFzZS5pby90aW1i cmF5KQ0K --_000_BY2PR03MB4422F70D5DEB31304A6604AF50B0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uZ3JhdHVsYXRpb25z IG9uIGNvbXBsZXRpb24gb2YgdGhlIEktSlNPTiBSRkMsIFRpbSE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciB3aGF0 IGl04oCZcyB3b3J0aCwNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtam9zZS1qd2stdGh1bWJwcmludC0wMyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTAzPC9hPiBhbHJlYWR5IGhhcyBhbiBpbmZv cm1hdGl2ZSByZWZlcmVuY2UgdG8gSS1KU09OLiZuYnNwOyBXZeKAmWxsIHVwZGF0ZSB0aGlzIHRv IHVwZGF0ZSB0aGUgUkZDIHdpdGggdGhlIG5leHQgcmV2aXNpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQ2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGpvc2UgW21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRpbSBCcmF5PGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMjUsIDIwMTUgMzo1OSBQTTxicj4NCjxi PlRvOjwvYj4gam9zZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gUkZDIDc0OTM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2YgcG9zc2libGUgdXNlZnVs bmVzcyBmb3IgSm9zZS4mbmJzcDsgUkZDOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVk aXRvci5vcmcvcmZjL3JmYzc0OTMudHh0Ij5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9y ZmM3NDkzLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkEgZmV3IHdvcmRzIG9mIGJhY2tncm91bmQ6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly93d3cudGJyYXkub3JnL29uZ29pbmcvV2hlbi8yMDF4LzIwMTUvMDMvMjMvaS1qc29uIj5odHRw czovL3d3dy50YnJheS5vcmcvb25nb2luZy9XaGVuLzIwMXgvMjAxNS8wMy8yMy9pLWpzb248L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRp bSBCcmF5IChJZiB5b3XigJlkIGxpa2UgdG8gc2VuZCBtZSBhIHByaXZhdGUgbWVzc2FnZSwgc2Vl IDxhIGhyZWY9Imh0dHBzOi8va2V5YmFzZS5pby90aW1icmF5IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2tleWJhc2UuaW8vdGltYnJheTwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB4422F70D5DEB31304A6604AF50B0BY2PR03MB442namprd_-- From nobody Thu Mar 26 16:41:27 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1141E1A6EE8 for ; Thu, 26 Mar 2015 16:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0rVoifLvThz for ; Thu, 26 Mar 2015 16:41:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0A41A1AA0 for ; Thu, 26 Mar 2015 16:41:21 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.125.14; Thu, 26 Mar 2015 23:41:19 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Thu, 26 Mar 2015 23:41:18 +0000 From: Mike Jones To: "jose@ietf.org" , "Matt Miller (mamille2)" Thread-Topic: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) Thread-Index: AQHQaB5bkfOhNCQj00mWiSuBrydmng== Date: Thu, 26 Mar 2015 23:41:18 +0000 Message-ID: References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:50c4:759d:a7ff:aa6e] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(36304003)(51914003)(584324002)(377454003)(43784003)(2501003)(230783001)(2656002)(19300405004)(46102003)(2950100001)(33656002)(19627405001)(19627595001)(106116001)(19617315012)(74316001)(19625215002)(2900100001)(15975445007)(62966003)(99286002)(87936001)(77156002)(50986999)(99936001)(77096005)(76576001)(76176999)(17760045003)(16236675004)(19580405001)(19580395003)(122556002)(18206015028)(40100003)(102836002)(92566002)(54356999)(86362001)(3826002)(16866105001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0527DFA348 Content-Type: multipart/related; boundary="_004_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2015 23:41:18.8233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "Shaun Cooley $shcooley$" Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:41:26 -0000 --_004_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_" --_000_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am working on the formatting of the algorithm cross-reference tables in J= WA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithm= s-40#appendix-A with the RFC Editor to make them more readable. When looki= ng at the table content (in a more readable rendition I'll share with you s= oon), I noticed that this string appears for the JCA value of three algorit= hms: AES/CBC/PKCS5Padding which I believe should be AES/CBC/PKCS7Padding This would be consistent with the changes made in -28 for the reasons descr= ibed in this thread. JAVA IMPLEMENTERS - If you are currently using AES/CB= C/PKCS5Padding can you please verify that your implementation still works a= fter changing this string to AES/CBC/PKCS7Padding and that the results are = still correct and reply to us letting us know what happened? Matt, if your= code for the cookbook is in Java, it would be especially good if you made = this code change and verified that nothing changes in the output. Also, this clearly inconsistent sentence currently occurs in http://tools.i= etf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1: CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS #7 padding using the cipher with the key X. I believe that the identifier CBC-PKCS5-ENC should be changed to CBC-PKCS7-= ENC. Unless people disagree, I will plan to apply these corrections during AUTH4= 8. Thanks all, -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, June 20, 2014 7:03 PM To: Shaun Cooley (shcooley) Cc: jose@ietf.org; Matt Miller (mamille2) Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PK= CS #5) This change has been incorporated in the -28 drafts. Thanks again, S= haun, -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, June 13, 2014 2:27 PM To: Shaun Cooley (shcooley) Cc: jose@ietf.org; Matt Miller (mamille2) Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PK= CS #5) (Adding the JOSE working group) I believe you're right. I'll plan to make this change in the next version = of the spec. Thanks for the careful read! -- Mike From: Shaun Cooley (shcooley) [mailto:shcooley@cisco.com] Sent: Friday, June 13, 2014 10:34 AM To: Mike Jones Cc: Matt Miller (mamille2) Subject: draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) Michael - I am working on implementing a browser compatible JS implementation of JOS= E, based on the work Matt Miller did for Node.JS. While going through the = spec, I noticed that PKCS #5 is called out for the AES-CBC ciphers. Should= n't this be PKCS #7? PKCS #5 - RFC2898 section 6.2 specifies: The padding string PS shall consist of 8 - (||M|| mod 8) octets all having = value 8 - (||M|| mod 8). PKCS #7 - RFC2315 section 10.3 note 2 specifies: For such algorithms, the method shall be to pad the input at the trailing e= nd with k - (l mod k) octets all having value k - (l mod k), where l is the= length of the input. PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKCS #5 i= s intended for block sizes of 8. This means that PKCS #7 is a superset of = #5, and given that AES is a block size of 16, it seems the spec should requ= ire PKCS #7. Thoughts? Shaun Cooley DISTINGUISHED ENGINEER.ENGINEERING Collaboration Technology Group shcooley@cisco.com Phone: +1 408 902 3344 Mobile: +1 310 293 2087 [http://www.cisco.com/web/europe/images/email/signature/logo05.jpg] Cisco.com This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am working on the fo= rmatting of the algorithm cross-reference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A with the RFC Editor to make them more readable. When looking at= the table content (in a more readable rendition I’ll share with you = soon), I noticed that this string appears for the JCA value of three algorithms:

&nbs= p; AES/CBC/PKCS= 5Padding=

which I believe should= be

&nbs= p; AES/CBC/PKCS= 7Padding=

This would be consiste= nt with the changes made in -28 for the reasons described in this thread.&n= bsp; JAVA IMPLEMENTERS – If you are currently using AES/CBC/PKCS5Padding can yo= u please verify that your implementation still works after changing this st= ring to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know what happened?&n= bsp; Matt, if you= r code for the cookbook is in Java, it would be especially good if you made= this code change and verified that nothing changes in the output.

Also, this clearly inc= onsistent sentence currently occurs in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5= .2.1:

= ; CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS

= ; #7 padding using the cipher with the key X.

I believe that the ide= ntifier CBC-PKCS5-ENC should be changed to CBC-= PKCS7-ENC.

Unless people disagree= , I will plan to apply these corrections during AUTH48.

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

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

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, June 20, 2014 7:03 PM
To: Shaun Cooley (shcooley)
Cc: jose@ietf.org; Matt Miller (mamille2)
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)

This change has been i= ncorporated in the -28 drafts.

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

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

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, June 13, 2014 2:27 PM
To: Shaun Cooley (shcooley)
Cc: jose@ietf.org; Matt Miller = (mamille2)
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)

(Adding the JOSE worki= ng group)

I believe you’re= right. I’ll plan to make this change in the next version of th= e spec.

Thanks for the careful= read!

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

From: Shaun Co= oley (shcooley) [mailto:shcooley@cisc= o.com]
Sent: Friday, June 13, 2014 10:34 AM
To: Mike Jones
Cc: Matt Miller (mamille2)
Subject: draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #= 5)

Michael –

I am working on implementing a browser compati= ble JS implementation of JOSE, based on the work Matt Miller did for Node.J= S. While going through the spec, I noticed that PKCS #5 is called out= for the AES-CBC ciphers. Shouldn’t this be PKCS #7?

PKCS #5 – RFC2898 section 6.2 specifies:<= /o:p>

The padding string PS shall consist of 8 - (|= |M|| mod 8) octets all having value 8 - (||M|| mod 8).

PKCS #7 – RFC2315 section 10.3 note 2 specifie= s:

For such algorithms, the method shall be to p= ad the input at the trailing end with k - (l mod k) octets all having value= k - (l mod k), where l is the length of the input.

PKCS #7 allows for padding in block sizes of 2-255 b= ytes, whereas PKCS #5 is intended for block sizes of 8. This means th= at PKCS #7 is a superset of #5, and given that AES is a block size of 16, i= t seems the spec should require PKCS #7.

Thoughts?

Shaun Cooley
DISTINGUISHED ENGINEER.ENGINEERING
Collaboration Technology Group
shcoole= y@cisco.com
Phone: +1 408 902 3344
Mobile: +1 310 293 2087

3D"http://=
Cisco.com

This email may contain confidential and pr= ivileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibit= ed. If you are not the intended recipient (or authorized to receive for the= recipient), please contact the sender by reply email and delete all copies= of this message.

For corporate legal information go to:
http://www.ci= sco.com/web/about/doing_business/legal/cri/index.html=

--_000_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_-- --_004_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=5673; creation-date="Thu, 26 Mar 2015 23:41:17 GMT"; modification-date="Thu, 26 Mar 2015 23:41:17 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgASQBuAwERAAIRAQMRAf/EAKUAAQABBAMBAAAAAAAAAAAA AAAJAQIHCAUGCgQBAQACAgMBAAAAAAAAAAAAAAAFBgQHAQIDCBAAAAYCAQQABAMHBQAAAAAAAgME BQYHAAEIERITCSExFBVBURbwcZEyJBcKYfFCQycRAAIABgEDAwICBQcNAAAAAAECABEDBAUGEiEx B0EiE1EyYXHwQrMVCJGhsbIzVDWB8ZOjwxRkdFV1Jzco/9oADAMBAAIRAxEAPwD38YhDEIYhDEIY hDEIYhDEIYhDEIYhDEIYhDEIYhDEIYhDEIpv5YhFNb3v54/phF2IQxCG8GEU1vr/ALY/OEVxCGIQ xCGIQxCGIQxCOqTWdQyuI6sl0/lUfhkXbhpi10gk7siZWhKYsUFpEhRy9wOITgNVKjgFlh2LuGMW ta1ve8yrOxvMjcLaWFKpWumnJUUsxkJnoAT0AJiJzeewutY18xsN3b2WKplQ1atUWnTUswVQWYgT ZiFUTmSQB1jTT2QWVJILwXuWxazmDhHnkltroyPTKIPA0a8lvk1mwVnUrWN9bTdGEacWJ4NAWpTm 6F4zu4set9BZa/H9hb3m52ljkqK1KPKryp1FmJpSqMAysJGTKJgjuJERqrz7nMjjfDWVzWtXj294 adqaVxQqFWCVbu2Rmp1UMxzpOwDoQZNNT2Mdt4ZWcrd+E9K2pacz85hdVlSCZzuYu5Rei29lC4bc JBJpA5nFl9qRtb/KrWqje4WgCNOHsWxD3ibbj0pbbeY7G0pA3JVKdNfVpSVFA9SeiqOnYADpEz4o zle58T4jO7Ddl6wxwevcV3H20+XKpVqOeskWb1HMzIs5PUxs/CZxDrJizNN6/lMfmsOkKYatjk8X dkT4xupBSg5IeNE5Nxx6Q/aZYnMINDoXcUeWMsegjAIOq7dWl1Y3D2l7TeldIZMjqVYeomCJjoQR 9QZ9pRsTGZTG5qwp5TEV6VzjawmlWkwdGAJB4spIMiCCO4IIMiCI7TvfT+OY8Z0Y7rW3asuVncpD UtjQmzGJnfnCLurzBJMzylrb5E06IG4Mytcyq1iYhwTEqiTdlCFoWyTizNdSzACFl3mPv8dUWlkK NWhWZAwV1KkqexAYAyMj/lBHcRH43LYvM0WucTcUbm3SoUZqTq6h1lyUlSRMTBl9CD2IiDb0k8hr uu+5fZG0W5a05sdsgtuwYcKbphIXB8RQ4qRSe+kjs2xRKuNOIjrIemireADejCShIClD4igdRddm +SsTjMZjsM+Ot6VF6lu4cooUvxWhIsR1Y+5vcZsZ9TGnfEGazOVyuwU8tc17inSu0+MVHLCmGe5B CAkhFkiyVZKABICJxIncdTzqZTqu4ZZcFlk8rFQiSWJDo7KWV4ksHVOQThIU8pZUC1QvZDlO05gQ hUFg3sZYw/zBFrWsq2Pv7a3pXlxRqpaVwTTdlIVwO5ViAD3HYnpG5LfJ4+7uq1la16VS7oECoisp ZCewZQSR2PcCMlZiRnQxCGIQxCGIRo5z+5USjiJTUcsqJR2PyZzerOj8JPQyUTiFAU2uDBK5AvUl bbFaJRpcIqM+EoQh7LLEd3iAZoPYK8aDq1pt2Yq428qVKVNLV6oKSnyDIoHuBEvfM+plIETnGg/4 ivLOb8OaVabNgbW2u724y9G1KV/k4Cm9G4rOw+NkbnKhwUklVLciry4nXj2/u/1vBBU8bL+n04TO s1uyPJ5PD9acco0T5ewvy6B5Ond2h69OvTX4S/ipTR3YU+p40ao/PsPr/N+PeK1/FSBlPChrMvH5 Luzfj3lymZT6TlOXpOOo88VeyfTAvVa69dUrxVH1+H/ZOaWDr5/L4Dz300BvLXX++Xk/9HX6Rz5W H/y1xX/pGI/b2McLH1Hf6I3RTr8eHU7M/f0bpB+X4b6fP5Z2uv8A3AP+6U/6VjIw9Pn/AAsil6HX ao/lV/8APHZ/VzPTK29Pld2cW3hdzK/r3kvOC2sw8SUDmOI21cz6FvGqCWaJOFZtu8ezNAFsOhde m+nTMHyBai/8lV7KfEVa1tTJlMjlRorOXrKZ/CLD4Uujh/BdlfhOTW1vf1ePUcuF1dOBP0nLvL1j O3rA5lzPnPxj/vPP4tGIlKkNhy2DOKGHfdS4+sAxJ2ZyROCJI9OLw4oRjRPxZJoBq1GhHEiMDsAT NFAhd41u21bOfu20qPUtjRRwXlyHIkEEgKD1WY6D6ekzcvGG5X286v8AvrIUqVG7W4qUiKfLgQoU ggMWYdGAPuPUEiQMhGr/AI0hvl4qX0Lr16chTtfu/wDN4Nv55cfM3+PWv/Kf7R/0l6doo38PSGnq 96p/vx/ZU/0/ljH3+PUb5L59qvx/ltqqtfxmPJ7Xy+fw6Z7+Wf8ADMGfT4Kv9W2jt4XUDL7CP+Jp f17qOa9Vh3f7i/bqHX/CWv8Arp8fwtt010+Pw30/b89+W8dPH2B+nxqf9UP0nGboI/8AJGxH0+Vv 2x/njfiifYjYFt+1zlPwEcYHDmmuaHp4ieR6YolD2fNnh+SradTOZTyM9Zpi20LQWsLZBJCMo5Lt FrvOP8u/HV8nqdrYaNZbStWo15dXBRkPHgqyqylIcpj4+5JB5dhLrcMVt15kN8v9UelTWztbcOrj lzLA0pzmeMj8vQAdOI6mZlLdlEi/wxCGIQxCMZWvTVX3lGksPtqGNE5jSJ6QyNI0vGlP06d7bSla dG4EjSKEx4Di0y88kWtD7TCTjCx6EAYg7ksXmMnhLg3eKrPQuGQoWWUypIJBmCJTAP4EAjqIrO16 bq+845MRttlRvsbTrrWWnUnJaqBlVxxIIIV3U9ZFWZSCrEG+0aerO6oMurW0Yc1S+DuA0BqmPL9K U6XRrWoLUt5qY5uUIlqE5IaVrsGQaWLQeoevaIWt9MblMhiLwZDG1WpXizkwlP3AgzBmDMHrMH69 wIyNh1jAbViGwOwWtO5xD8Z02mBNCCpUqVZSsuhUgy6diRGv/NXi+s5HcOrH4yVwvjsEVSFig7VD znFMrJi7IVAZlEpU0tJ5DSnUq0TSamioUQREEHCTgM0MJRnZ2bmdU2BcFtFDYL5alYI9QvI+9jUR 0LdehM35dSJn1E5xWPI+jHcfHl3pGJajafLSoJS5Aikgt61KqiEKCVQikE9oPEGYBlI81x94ytlc 8QYBxWtP7DY7Sz1eKu52SFEpKjslSuZCst9RkEKRgXfbzAuBhRZovCeIIdG6CSPegh8c3nql/stb YcfzoO9f5KfUc1IlxMx0mJTPcenX1zdT02hhdCtNJzHxXdClZfBWEj8dQMDzAB93H3EAmRIE5KTI ZdgdJVRWNUoaOgkGZI7UzazPMfSwVKUeoZfs8iUOKx/RqArj1Slbp7Vu6o1WM8wwxQaoMEMQhC3v cZeZPIX+QOVvKrvkGdWNQ/dyUAKRKUuIUASkBISixY7BYjE4hcDjrenSw6IyCkJleLklwZkk8izF iSSSSSesfLSVDVBxxgxNa0jBGeu4QQ5uL0FgZdrTSDHZ2GWNwcFKpyVrnBYqUaJLB3mnD2EosBYe gAADpk8pkMzdm+ydVq12VC8jKch2AkAAB+A79e8MLgsTr1iMbhaCW9iGLcFmRybuSWJJJ/EnoAOw EcZRXG2i+MkcfIjQlaRysI5JJMumD20xwtWFMvkLimSI1C4e1qpYcUWBGgJJJTliAmTFF6ASWAPX Wd8pmMpmqy3GUrPXrogUFvRRMy6AepmT3PqZxxiMDiMBQe1w1Cnb0KlQuwWfVjIE9SfQAAdgBIAC I+vWN65p7wVsnmrNZpYESmqDklZsdkcLSRhK8EK2WLxZ5tF3RGSf7ojSEEPzjqyfGalSiVpyPo+4 Kk3ydAWrc9utdntMdb21KpTazosrlip5Mwpg8ZH7R8cwTImfYS61HRdLu9Tvcnc3VanVW+rqyBQw KqjVSOUwPcfl6gTAl9xn0kBrzjPQ1UWbaty11WEaiVn3etRuNqTFqJVBdJetQiONKPWBOVHJEWz1 SgahRpIUnCrVC2efow7fflVusxk72yoY67rO9lbAikh7ID9PyAkJzkOgkIuNnhMVj764yVnQSnfX RBquJzcj6zMh3mZATPUzMWxrjJQkOvWd8mYxV0ZZb4s2NoIjO7MREqgSCRxxt0yaTNivQ1Q0BJQ/ 003ecZJBRqnaFPs4RmyS+3mrmMnXxlLDVqzti6L8kpmXFWPLqOk/1mlMyEzKU4UcLi7fKVc1RoIu UroFeoJ8mUceh6y/VWcgJ8ROchGdsjIlIYhDEIYhFN4hEQntS9gs+4ittXVVQscSSfkBeLgeli2l 7Ya+kMDYS4N7KlNRMBJhQnyTSV+cy0jYQLvI0Mo4RoB70WWPZXjzTLPZKlxkczUNPDWizaR48mkT 1f8AVRVHJiOvUSPcjQvm3ynltFp2OC1aitback5FPkvMIgZUBCD76lSowSmOq9GLAniDbwcY/bk1 W+kX83JrC5TTb5Xj0r00MSOoUr1EJ19eymMbe7ig8QjLgeaNvGtCZtIpc0OhAD3GaF03vrttbxxU x5TVKVWnklrKJsa3F0keRX5HYd5dwrfQSj38b2vm+3zAreRbq3r4WpaseKLahqVaa8Q3w0qZPt5f a1RPxnKMb8IOYvIi4PZ1zm472HYX6gqCmgTz+3UR/SUHadx3bNZ7BHW3f35kjLZJ3b6ZmWmk/wBc tU9/d3j7h6CLXts+u4fHaRi8zZ0eGTuRT+Rubnlypsx9rMVWZAPtA7fSPXSNt2PLeTM5r+RuPkw9 n8vw0/jprw411Qe9aau0lJHudp9+p6xG7JfZF7AuR3NbkJSFNcweMnC+O1fPJbB4HGLzboM0oZsb FJiuhaRAmlEyqyyHJxmjuc3aUqkoDkoQ7P7Eqczs3rVuo6fqmI1u0yWQx97katekru9EuSnNA8yq 1aYCiZAMj9WI9alU3reM/t19icZlLDE21vWenTS4WmBU4VCkg70arGo0psJqBOSr9JdfZ97C5V66 uJEIlprdHJfyOsTbPB4yicAHiiRcsRR4pxnk3cEaD7Scuj7CcDoUlKGlEcpXJQ77CvJ26/0vVLfb c9UoTenh6U3aX3lS0kpgmcmYdyZ9AZdZRtfedwudN1ylcFadTN1uKKDPgHCzqVCBxmqnsBxmWXss 41p4FF+9eQXbR9mcvZvCD+L82Sy1zn9ZFMVIMc3ijW6VpJ3SvVbgljMFa5QhFqbDaChpCHlW4J9D EBcQEITtgl9pPjKljbmywFOr++6RUU6nKsVYiooqAFnZD7OfXgFP6rHpENqQ8q1cpa3ux1aRwdQO alMLRDqDTY0ywWmrD38JgOWHZlHWME8xvZP7Ab653yz19+rlsjUff6kAp1ZttPzHFXxQU4sOmvUz WK1FgNT9D4rBoo7PJDKYIxrVuK926hSj35SCxymvafq2K1iltW6s70bj+zpBnHRp8AOBDPUYDn94 ULOY6EiP2Lctsy201NS0cIla3n8lVlQmay5kmoGRUUnh9hdm+09QD9nCH2V89qd52sfrq9obLHnm b2YiArq+2Y81RFlNNWrkDy5R0w4UAQNENk8Ll4mRQ3JFCZvRODc7FbIVhHvzaS9Nk0/WMhrTbZpb MttRMqlJi7divIe8l1dAeRBLKVM16SLe+tbftVhsq6nuqo1zWE6dVQi958fsARkYgqCAGDiRn1A9 OWuv45pkE+sbmiudoQxCGIQxCLRfL9vj/piH5RBV7ieGt+2u+UHyw4sNRkmuLjo7p1ZkWQgRHP69 AzSNvmkRf44iXDJJelkTkqE8RzdoQz1ZazXhAMRYgD2v422fE46hea7nWCY69X7jMKCyFHDETK81 Mg3ZePUx89ebPH+ezl9jN11RPkzmKb+zEubBai1aToD0c06gb2d2D9AZEHJHBTnPzl5I3OlgF/cH JjxzgbZW74+PlhyeB2zG0D3NUS9iSNTWxHThnZW1pTOBC1WbtEM1zVdpGuh2tBFsUbtWq6thMabv D5SneXTV1Vaa1KTFUIMy3AsWlJfcAo69pxZdF3jeNkzAsdgwdbHWK27M1V6VdA1QFQqr8qgKCCx4 k1D0+7p11t9edMXPDPbx7FLImlR2fEq4mgbI/RU/k8BlTFCZfpbcEac0P6XlTq1JWJ/2tbiRqCvp DzvKQWIwPUAd71Lbbk8dc+P8RZW1xQqXlP4udNaiM6SpMDyUHksj0Mx3l6nrEaHhMtZeUc/kru1u KVhXNb46j03VKk66MODsoVpjqJHt19JxGZ7MoxbvMWw7GiEK9L11Q69CbTXxlm5bxdFaKSOz2Pxu ULWlPIJC0aqeK1w8pZjHUZGwPLo9qRJSdliLV7KDoOXDTa9hr9pRr3WxW9TF/AGNqxp8kZkBKqfl eovFpjiqCfWYBiq7za3+zX1ehbavc0st/vBUXiiqFqKrkBmHwpSbmoHvd24iXuIEokA55+rLkfyC 9W/Eir21akmPKjilEGA9fHFb6mFqXI1sUTM8ugLLI1y4tpUvsf8AoG0pCrUHgTLQNQwBEHagvYap rO7YjFbtf3rjhg7+oRyl9pDzR2AE+LTYsB1BYfQxddq0HM5fQ8dj1IqZ7H0lmsx7gU4vTViZclko ViZEIZdSIyFwF9h/s7t+8aP498mfX1YdXxfaSYNlwckpJWduRWPqRxCt5S4sLql28x1vhLM6S2bM zemNNLcViNWJaMKQgrQy9l4e06pplhjrnLYbK0a9eamlbrUpMw51FDAybmQiFj9ikSBYmRnIant2 8ZHJ22IzmJq0KMmFa4anVVTxpsVImvxgu4UGTsDyIUDpLTjk5QnsD9avsstznlw4oR85VVDyTTOw pxCIywyCaP7cql7iwvkrjTuwQ5OrmLWpSzdmA6M7yiQK0ZKE7aU/u3o8I7Bhsrqm4ahQ1jYbpLG/ syODsyop4AqrBnkpmh4shYEn3D0iFy+I2jT9yuNo1+2e+x96GLoqs5HIhmUhAWB5gMjhSAswfURT iRxz56exn2dwD2Ic0qDd+MNY8fWtrRV7X8vjT3EZA4KIgdJV0Ii7PH5kQjmastvmcpVP7i9LkadM aP8Ap0gdBML0n4z2W1fUtMq6prt0t7e3THm6srKOfEOxZJoJqgRUUkju3rHrhMVs22bjR2rYLZrO ytVHBGVkYleRRQrycydi5ZgAew9JetnX7flmix0/KN4CK5zHMMQhiEMQhiEU6a3iEOmsQ7Q6a6dO nw/LEIdM4kIQ6azmEOmsQ/CHTWPwhDprEIriEMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEMQhi EMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEf//Z --_004_BY2PR03MB44255D6D63EA00274A86086F5080BY2PR03MB442namprd_-- From nobody Thu Mar 26 17:32:02 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833481A8840 for ; Thu, 26 Mar 2015 17:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JKvz0FpY8_Q for ; Thu, 26 Mar 2015 17:31:58 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A791A882F for ; Thu, 26 Mar 2015 17:31:58 -0700 (PDT) Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKVRSk/cgW0+dJDvPAzh6h2nUMWpoF5kZj@postini.com; Thu, 26 Mar 2015 17:31:58 PDT Received: by igcau2 with SMTP id au2so23095944igc.1 for ; Thu, 26 Mar 2015 17:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RvLxGsqBLpgCep1qiSnOyiqR4pzPYq2CIOrL90bYGzA=; b=PYWWmk53wwxI1lCvT+6YeIqNxCIbCFAbVMIxkuNo7+3nCV3iDMFjR7cQA8M2124xtj HT8Wi7qcOv8yaCmuGrjCluGQQoZ0o3nuNN9lCdOpdLZAiTaiPb5nYMiA0ptA1ZjznSVH HHO4HntpuiPBu0xo6Ckgcw59Nca3Rx3McJrLIZnIbz4L5zd6pUVNVHpvY0SiX38MP8rB e2it9VzItffbL93CdJeE6W4yH6ULvRPvW8M0gCZCbnibPXhPHHAccxJPzXJMc6piSzMG boHHD14VBH+7llu5D9IuyFm0MbMw5SwhhbLFiBrKPeNIA8HbpK1Hh7Zp4SBuTIz1slPx Ka+w== X-Gm-Message-State: ALoCoQkBTLcAlJTwwWbb8JQxt2g0okdtwFiDElw8fEJHT4hJy8TG9LrIfBS02AEdMLtrivN8grYpBFGGiwMiMyH2nstvoB266Dtm+4sW0VIyHKTHC+L9jUcqvN9W/bPxhuI63wThwh9x X-Received: by 10.50.176.196 with SMTP id ck4mr41447306igc.40.1427416317495; Thu, 26 Mar 2015 17:31:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.176.196 with SMTP id ck4mr41447290igc.40.1427416317333; Thu, 26 Mar 2015 17:31:57 -0700 (PDT) Received: by 10.64.7.193 with HTTP; Thu, 26 Mar 2015 17:31:56 -0700 (PDT) Received: by 10.64.7.193 with HTTP; Thu, 26 Mar 2015 17:31:56 -0700 (PDT) In-Reply-To: References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 26 Mar 2015 19:31:56 -0500 Message-ID: From: Brian Campbell To: Mike Jones Content-Type: multipart/related; boundary=089e0111b8fa8ad4a305123a4216 Archived-At: Cc: "jose@ietf.org" , "Shaun Cooley $shcooley$" , Matt Miller Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:32:01 -0000 --089e0111b8fa8ad4a305123a4216 Content-Type: multipart/alternative; boundary=089e0111b8fa8ad49e05123a4215 --089e0111b8fa8ad49e05123a4215 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am pretty sure you should not make that change to the JCA algorithm string. I'll have to search around to remember why, some oddity of Java I think, but I'm away from my laptop right now and that one is too much to research on a phone. On Mar 26, 2015 6:41 PM, "Mike Jones" wrote: > I am working on the formatting of the algorithm cross-reference tables > in JWA Appendix A > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendi= x-A > with the RFC Editor to make them more readable. When looking at the tabl= e > content (in a more readable rendition I=E2=80=99ll share with you soon), = I noticed > that this string appears for the JCA value of three algorithms: > > AES/CBC/PKCS5Padding > > which I believe should be > > AES/CBC/PKCS7Padding > > > > This would be consistent with the changes made in -28 for the reasons > described in this thread. JAVA IMPLEMENTERS =E2=80=93 If you are current= ly using > AES/CBC/PKCS5Padding can you please verify that your implementation still > works after changing this string to AES/CBC/PKCS7Padding and that the > results are still correct and reply to us letting us know what happened? > Matt, if your code for the cookbook is in Java, it would be especially > good if you made this code change and verified that nothing changes in th= e > output. > > > > Also, this clearly inconsistent sentence currently occurs in > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section= -5.2.1 > : > > CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS > > #7 padding using the cipher with the key X. > > > > I believe that the identifier CBC-PKCS5-ENC should be changed to > CBC-PKCS7-ENC. > > > > Unless people disagree, I will plan to apply these corrections during > AUTH48. > > > > Thanks all, > > -- Mike > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Friday, June 20, 2014 7:03 PM > *To:* Shaun Cooley (shcooley) > *Cc:* jose@ietf.org; Matt Miller (mamille2) > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 > (PKCS #5) > > > > This change has been incorporated in the -28 drafts. > > > > Thanks again, > Shaun, > > -- Mike > > > > *From:* jose [mailto:jose-bounces@ietf.org ] *On > Behalf Of *Mike Jones > *Sent:* Friday, June 13, 2014 2:27 PM > *To:* Shaun Cooley (shcooley) > *Cc:* jose@ietf.org; Matt Miller (mamille2) > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 > (PKCS #5) > > > > (Adding the JOSE working group) > > > > I believe you=E2=80=99re right. I=E2=80=99ll plan to make this change in= the next version > of the spec. > > > > Thanks for the careful read! > > > > -- Mike > > > > *From:* Shaun Cooley (shcooley) [mailto:shcooley@cisco.com > ] > *Sent:* Friday, June 13, 2014 10:34 AM > *To:* Mike Jones > *Cc:* Matt Miller (mamille2) > *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) > > > > Michael =E2=80=93 > > I am working on implementing a browser compatible JS implementation of > JOSE, based on the work Matt Miller did for Node.JS. While going through > the spec, I noticed that PKCS #5 is called out for the AES-CBC ciphers. > Shouldn=E2=80=99t this be PKCS #7? > > > > PKCS #5 =E2=80=93 RFC2898 section 6.2 specifies: > > The padding string PS shall consist of 8 - (||M|| mod 8) octets all havin= g > value 8 - (||M|| mod 8). > > > > PKCS #7 =E2=80=93 RFC2315 section 10.3 note 2 specifies: > > For such algorithms, the method shall be to pad the input at the trailing > end with k - (l mod k) octets all having value k - (l mod k), where l is > the length of the input. > > > > PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKCS #5 > is intended for block sizes of 8. This means that PKCS #7 is a superset = of > #5, and given that AES is a block size of 16, it seems the spec should > require PKCS #7. > > > > Thoughts? > > > > *Shaun Cooley* > DISTINGUISHED ENGINEER.ENGINEERING > Collaboration Technology Group > shcooley@cisco.com > Phone: *+1 408 902 3344 <%2B1%20408%20902%203344>* > Mobile: *+1 310 293 2087 <%2B1%20310%20293%202087>* > > [image: http://www.cisco.com/web/europe/images/email/signature/logo05.jpg= ] > Cisco.com > > > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosur= e > by others is strictly prohibited. If you are not the intended recipient (= or > authorized to receive for the recipient), please contact the sender by > reply email and delete all copies of this message. > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e0111b8fa8ad49e05123a4215 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am pretty sure you should not make that change to the JCA = algorithm string. I'll have to search around to remember why, some oddi= ty of Java I think, but I'm away from my laptop right now and that one = is too much to research on a phone.

On Mar 26, 2015 6:41 PM, "Mike Jones" = <Michael.Jones@microsoft.= com> wrote:

I am working on the fo= rmatting of the algorithm cross-reference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A with the RFC Editor to make them more readable.=C2=A0 When looking at= the table content (in a more readable rendition I=E2=80=99ll share with yo= u soon), I noticed that this string appears for the JCA value of three algorithms:

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AES/CBC/PKC= S5Padding

which I believe should= be

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AES/CBC/PKC= S7Padding

=C2=A0

This would be consiste= nt with the changes made in -28 for the reasons described in this thread.= =C2=A0 JAVA IMPLEMENTERS =E2=80=93 If you are currently using AES/CBC/PKCS5Padding can = you please verify that your implementation still works after changing this = string to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know what happened?= =C2=A0 Matt, if you= r code for the cookbook is in Java, it would be especially good if you made= this code change and verified that nothing changes in the output.

=C2=A0

Also, this clearly inc= onsistent sentence currently occurs in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5= .2.1:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CBC-PKCS5-ENC(X, P) denotes the AES CBC encryptio= n of P using PKCS

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #7 padding using the cipher with the key X.

=C2=A0

I believe that the ide= ntifier CBC-PKCS5-ENC should be changed to CBC-= PKCS7-ENC.

=C2=A0

Unless people disagree= , I will plan to apply these corrections during AUTH48.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks all,

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

=C2=A0

From: jose [ma= ilto:jose-bounce= s@ietf.org] On Behalf Of Mike Jones
Sent: Friday, June 20, 2014 7:03 PM
To: Shaun Cooley (shcooley)
Cc: jose@ietf.org= ; Matt Miller (mamille2)
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)

=C2=A0

This change has been i= ncorporated in the -28 drafts.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again, Shaun,=

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

=C2=A0

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Mike Jones
Sent: Friday, June 13, 2014 2:27 PM
To: Shaun Cooley (shcooley)
Cc: jose@ietf.org= ; Matt Miller (mamille2)
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)

=C2=A0

(Adding the JOSE worki= ng group)

=C2=A0

I believe you=E2=80=99= re right.=C2=A0 I=E2=80=99ll plan to make this change in the next version o= f the spec.

=C2=A0

Thanks for the careful= read!

=C2=A0

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

=C2=A0

From: Shaun Co= oley (shcooley) [ma= ilto:shcooley@cisco.com]
Sent: Friday, June 13, 2014 10:34 AM
To: Mike Jones
Cc: Matt Miller (mamille2)
Subject: draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #= 5)

=C2=A0

Michael =E2=80=93

=C2=A0I am working on implementing a browser compati= ble JS implementation of JOSE, based on the work Matt Miller did for Node.J= S.=C2=A0 While going through the spec, I noticed that PKCS #5 is called out= for the AES-CBC ciphers.=C2=A0 Shouldn=E2=80=99t this be PKCS #7?

=C2=A0

PKCS #5 =E2=80=93 RFC2898 section 6.2 specifies:<= /u>

The padding string PS shall consist of 8 - (||M|| mod 8) octets al= l having value 8 - (||M|| mod 8).

=C2=A0

PKCS #7 =E2=80=93 RFC2315 section 10.3 note 2 specif= ies:

For such algorithms, the method shall be to pad the input at the t= railing end with k - (l mod k) octets all having value k - (l mod k), where= l is the length of the input.

=C2=A0

PKCS #7 allows for padding in block sizes of 2-255 b= ytes, whereas PKCS #5 is intended for block sizes of 8.=C2=A0 This means th= at PKCS #7 is a superset of #5, and given that AES is a block size of 16, i= t seems the spec should require PKCS #7.

=C2=A0

Thoughts?

=C2=A0

Shaun Cooley
DISTINGUISHED ENGINEER.ENGINEERING
Collaboration Technology Group
shcooley@cisco.com
Phone:=C2=A0+1 408 902 3344
Mobile:=C2=A0+1 310 293 2087

Cisco.com

=C2=A0

This email may contain confi= dential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibit= ed. If you are not the intended recipient (or authorized to receive for the= recipient), please contact the sender by reply email and delete all copies= of this message.

For corporate legal informat= ion go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

=C2=A0

=C2=A0

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

--089e0111b8fa8ad49e05123a4215-- --089e0111b8fa8ad4a305123a4216 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: e4a8c34cd4e61946_0.0.1 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgASQBuAwERAAIRAQMRAf/EAKUAAQABBAMBAAAAAAAAAAAA AAAJAQIHCAUGCgQBAQACAgMBAAAAAAAAAAAAAAAFBgQHAQIDCBAAAAYCAQQABAMHBQAAAAAAAgME BQYHAAEIERITCSExFBVBURbwcZEyJBcKYfFCQycRAAIABgEDAwICBQcNAAAAAAECABEDBAUGEiEx B0EiE1EyYXHwQrMVCJGhsbIzVDWB8ZOjwxRkdFV1Jzco/9oADAMBAAIRAxEAPwD38YhDEIYhDEIY hDEIYhDEIYhDEIYhDEIYhDEIYhDEIYhDEIpv5YhFNb3v54/phF2IQxCG8GEU1vr/ALY/OEVxCGIQ xCGIQxCGIQxCOqTWdQyuI6sl0/lUfhkXbhpi10gk7siZWhKYsUFpEhRy9wOITgNVKjgFlh2LuGMW ta1ve8yrOxvMjcLaWFKpWumnJUUsxkJnoAT0AJiJzeewutY18xsN3b2WKplQ1atUWnTUswVQWYgT ZiFUTmSQB1jTT2QWVJILwXuWxazmDhHnkltroyPTKIPA0a8lvk1mwVnUrWN9bTdGEacWJ4NAWpTm 6F4zu4set9BZa/H9hb3m52ljkqK1KPKryp1FmJpSqMAysJGTKJgjuJERqrz7nMjjfDWVzWtXj294 adqaVxQqFWCVbu2Rmp1UMxzpOwDoQZNNT2Mdt4ZWcrd+E9K2pacz85hdVlSCZzuYu5Rei29lC4bc JBJpA5nFl9qRtb/KrWqje4WgCNOHsWxD3ibbj0pbbeY7G0pA3JVKdNfVpSVFA9SeiqOnYADpEz4o zle58T4jO7Ddl6wxwevcV3H20+XKpVqOeskWb1HMzIs5PUxs/CZxDrJizNN6/lMfmsOkKYatjk8X dkT4xupBSg5IeNE5Nxx6Q/aZYnMINDoXcUeWMsegjAIOq7dWl1Y3D2l7TeldIZMjqVYeomCJjoQR 9QZ9pRsTGZTG5qwp5TEV6VzjawmlWkwdGAJB4spIMiCCO4IIMiCI7TvfT+OY8Z0Y7rW3asuVncpD UtjQmzGJnfnCLurzBJMzylrb5E06IG4Mytcyq1iYhwTEqiTdlCFoWyTizNdSzACFl3mPv8dUWlkK NWhWZAwV1KkqexAYAyMj/lBHcRH43LYvM0WucTcUbm3SoUZqTq6h1lyUlSRMTBl9CD2IiDb0k8hr uu+5fZG0W5a05sdsgtuwYcKbphIXB8RQ4qRSe+kjs2xRKuNOIjrIemireADejCShIClD4igdRddm +SsTjMZjsM+Ot6VF6lu4cooUvxWhIsR1Y+5vcZsZ9TGnfEGazOVyuwU8tc17inSu0+MVHLCmGe5B CAkhFkiyVZKABICJxIncdTzqZTqu4ZZcFlk8rFQiSWJDo7KWV4ksHVOQThIU8pZUC1QvZDlO05gQ hUFg3sZYw/zBFrWsq2Pv7a3pXlxRqpaVwTTdlIVwO5ViAD3HYnpG5LfJ4+7uq1la16VS7oECoisp ZCewZQSR2PcCMlZiRnQxCGIQxCGIRo5z+5USjiJTUcsqJR2PyZzerOj8JPQyUTiFAU2uDBK5AvUl bbFaJRpcIqM+EoQh7LLEd3iAZoPYK8aDq1pt2Yq428qVKVNLV6oKSnyDIoHuBEvfM+plIETnGg/4 ivLOb8OaVabNgbW2u724y9G1KV/k4Cm9G4rOw+NkbnKhwUklVLciry4nXj2/u/1vBBU8bL+n04TO s1uyPJ5PD9acco0T5ewvy6B5Ond2h69OvTX4S/ipTR3YU+p40ao/PsPr/N+PeK1/FSBlPChrMvH5 Luzfj3lymZT6TlOXpOOo88VeyfTAvVa69dUrxVH1+H/ZOaWDr5/L4Dz300BvLXX++Xk/9HX6Rz5W H/y1xX/pGI/b2McLH1Hf6I3RTr8eHU7M/f0bpB+X4b6fP5Z2uv8A3AP+6U/6VjIw9Pn/AAsil6HX ao/lV/8APHZ/VzPTK29Pld2cW3hdzK/r3kvOC2sw8SUDmOI21cz6FvGqCWaJOFZtu8ezNAFsOhde m+nTMHyBai/8lV7KfEVa1tTJlMjlRorOXrKZ/CLD4Uujh/BdlfhOTW1vf1ePUcuF1dOBP0nLvL1j O3rA5lzPnPxj/vPP4tGIlKkNhy2DOKGHfdS4+sAxJ2ZyROCJI9OLw4oRjRPxZJoBq1GhHEiMDsAT NFAhd41u21bOfu20qPUtjRRwXlyHIkEEgKD1WY6D6ekzcvGG5X286v8AvrIUqVG7W4qUiKfLgQoU ggMWYdGAPuPUEiQMhGr/AI0hvl4qX0Lr16chTtfu/wDN4Nv55cfM3+PWv/Kf7R/0l6doo38PSGnq 96p/vx/ZU/0/ljH3+PUb5L59qvx/ltqqtfxmPJ7Xy+fw6Z7+Wf8ADMGfT4Kv9W2jt4XUDL7CP+Jp f17qOa9Vh3f7i/bqHX/CWv8Arp8fwtt010+Pw30/b89+W8dPH2B+nxqf9UP0nGboI/8AJGxH0+Vv 2x/njfiifYjYFt+1zlPwEcYHDmmuaHp4ieR6YolD2fNnh+SradTOZTyM9Zpi20LQWsLZBJCMo5Lt FrvOP8u/HV8nqdrYaNZbStWo15dXBRkPHgqyqylIcpj4+5JB5dhLrcMVt15kN8v9UelTWztbcOrj lzLA0pzmeMj8vQAdOI6mZlLdlEi/wxCGIQxCMZWvTVX3lGksPtqGNE5jSJ6QyNI0vGlP06d7bSla dG4EjSKEx4Di0y88kWtD7TCTjCx6EAYg7ksXmMnhLg3eKrPQuGQoWWUypIJBmCJTAP4EAjqIrO16 bq+845MRttlRvsbTrrWWnUnJaqBlVxxIIIV3U9ZFWZSCrEG+0aerO6oMurW0Yc1S+DuA0BqmPL9K U6XRrWoLUt5qY5uUIlqE5IaVrsGQaWLQeoevaIWt9MblMhiLwZDG1WpXizkwlP3AgzBmDMHrMH69 wIyNh1jAbViGwOwWtO5xD8Z02mBNCCpUqVZSsuhUgy6diRGv/NXi+s5HcOrH4yVwvjsEVSFig7VD znFMrJi7IVAZlEpU0tJ5DSnUq0TSamioUQREEHCTgM0MJRnZ2bmdU2BcFtFDYL5alYI9QvI+9jUR 0LdehM35dSJn1E5xWPI+jHcfHl3pGJajafLSoJS5Aikgt61KqiEKCVQikE9oPEGYBlI81x94ytlc 8QYBxWtP7DY7Sz1eKu52SFEpKjslSuZCst9RkEKRgXfbzAuBhRZovCeIIdG6CSPegh8c3nql/stb YcfzoO9f5KfUc1IlxMx0mJTPcenX1zdT02hhdCtNJzHxXdClZfBWEj8dQMDzAB93H3EAmRIE5KTI ZdgdJVRWNUoaOgkGZI7UzazPMfSwVKUeoZfs8iUOKx/RqArj1Slbp7Vu6o1WM8wwxQaoMEMQhC3v cZeZPIX+QOVvKrvkGdWNQ/dyUAKRKUuIUASkBISixY7BYjE4hcDjrenSw6IyCkJleLklwZkk8izF iSSSSSesfLSVDVBxxgxNa0jBGeu4QQ5uL0FgZdrTSDHZ2GWNwcFKpyVrnBYqUaJLB3mnD2EosBYe gAADpk8pkMzdm+ydVq12VC8jKch2AkAAB+A79e8MLgsTr1iMbhaCW9iGLcFmRybuSWJJJ/EnoAOw EcZRXG2i+MkcfIjQlaRysI5JJMumD20xwtWFMvkLimSI1C4e1qpYcUWBGgJJJTliAmTFF6ASWAPX Wd8pmMpmqy3GUrPXrogUFvRRMy6AepmT3PqZxxiMDiMBQe1w1Cnb0KlQuwWfVjIE9SfQAAdgBIAC I+vWN65p7wVsnmrNZpYESmqDklZsdkcLSRhK8EK2WLxZ5tF3RGSf7ojSEEPzjqyfGalSiVpyPo+4 Kk3ydAWrc9utdntMdb21KpTazosrlip5Mwpg8ZH7R8cwTImfYS61HRdLu9Tvcnc3VanVW+rqyBQw KqjVSOUwPcfl6gTAl9xn0kBrzjPQ1UWbaty11WEaiVn3etRuNqTFqJVBdJetQiONKPWBOVHJEWz1 SgahRpIUnCrVC2efow7fflVusxk72yoY67rO9lbAikh7ID9PyAkJzkOgkIuNnhMVj764yVnQSnfX RBquJzcj6zMh3mZATPUzMWxrjJQkOvWd8mYxV0ZZb4s2NoIjO7MREqgSCRxxt0yaTNivQ1Q0BJQ/ 003ecZJBRqnaFPs4RmyS+3mrmMnXxlLDVqzti6L8kpmXFWPLqOk/1mlMyEzKU4UcLi7fKVc1RoIu UroFeoJ8mUceh6y/VWcgJ8ROchGdsjIlIYhDEIYhFN4hEQntS9gs+4ittXVVQscSSfkBeLgeli2l 7Ya+kMDYS4N7KlNRMBJhQnyTSV+cy0jYQLvI0Mo4RoB70WWPZXjzTLPZKlxkczUNPDWizaR48mkT 1f8AVRVHJiOvUSPcjQvm3ynltFp2OC1aitback5FPkvMIgZUBCD76lSowSmOq9GLAniDbwcY/bk1 W+kX83JrC5TTb5Xj0r00MSOoUr1EJ19eymMbe7ig8QjLgeaNvGtCZtIpc0OhAD3GaF03vrttbxxU x5TVKVWnklrKJsa3F0keRX5HYd5dwrfQSj38b2vm+3zAreRbq3r4WpaseKLahqVaa8Q3w0qZPt5f a1RPxnKMb8IOYvIi4PZ1zm472HYX6gqCmgTz+3UR/SUHadx3bNZ7BHW3f35kjLZJ3b6ZmWmk/wBc tU9/d3j7h6CLXts+u4fHaRi8zZ0eGTuRT+Rubnlypsx9rMVWZAPtA7fSPXSNt2PLeTM5r+RuPkw9 n8vw0/jprw411Qe9aau0lJHudp9+p6xG7JfZF7AuR3NbkJSFNcweMnC+O1fPJbB4HGLzboM0oZsb FJiuhaRAmlEyqyyHJxmjuc3aUqkoDkoQ7P7Eqczs3rVuo6fqmI1u0yWQx97katekru9EuSnNA8yq 1aYCiZAMj9WI9alU3reM/t19icZlLDE21vWenTS4WmBU4VCkg70arGo0psJqBOSr9JdfZ97C5V66 uJEIlprdHJfyOsTbPB4yicAHiiRcsRR4pxnk3cEaD7Scuj7CcDoUlKGlEcpXJQ77CvJ26/0vVLfb c9UoTenh6U3aX3lS0kpgmcmYdyZ9AZdZRtfedwudN1ylcFadTN1uKKDPgHCzqVCBxmqnsBxmWXss 41p4FF+9eQXbR9mcvZvCD+L82Sy1zn9ZFMVIMc3ijW6VpJ3SvVbgljMFa5QhFqbDaChpCHlW4J9D EBcQEITtgl9pPjKljbmywFOr++6RUU6nKsVYiooqAFnZD7OfXgFP6rHpENqQ8q1cpa3ux1aRwdQO alMLRDqDTY0ywWmrD38JgOWHZlHWME8xvZP7Ab653yz19+rlsjUff6kAp1ZttPzHFXxQU4sOmvUz WK1FgNT9D4rBoo7PJDKYIxrVuK926hSj35SCxymvafq2K1iltW6s70bj+zpBnHRp8AOBDPUYDn94 ULOY6EiP2Lctsy201NS0cIla3n8lVlQmay5kmoGRUUnh9hdm+09QD9nCH2V89qd52sfrq9obLHnm b2YiArq+2Y81RFlNNWrkDy5R0w4UAQNENk8Ll4mRQ3JFCZvRODc7FbIVhHvzaS9Nk0/WMhrTbZpb MttRMqlJi7divIe8l1dAeRBLKVM16SLe+tbftVhsq6nuqo1zWE6dVQi958fsARkYgqCAGDiRn1A9 OWuv45pkE+sbmiudoQxCGIQxCLRfL9vj/piH5RBV7ieGt+2u+UHyw4sNRkmuLjo7p1ZkWQgRHP69 AzSNvmkRf44iXDJJelkTkqE8RzdoQz1ZazXhAMRYgD2v422fE46hea7nWCY69X7jMKCyFHDETK81 Mg3ZePUx89ebPH+ezl9jN11RPkzmKb+zEubBai1aToD0c06gb2d2D9AZEHJHBTnPzl5I3OlgF/cH JjxzgbZW74+PlhyeB2zG0D3NUS9iSNTWxHThnZW1pTOBC1WbtEM1zVdpGuh2tBFsUbtWq6thMabv D5SneXTV1Vaa1KTFUIMy3AsWlJfcAo69pxZdF3jeNkzAsdgwdbHWK27M1V6VdA1QFQqr8qgKCCx4 k1D0+7p11t9edMXPDPbx7FLImlR2fEq4mgbI/RU/k8BlTFCZfpbcEac0P6XlTq1JWJ/2tbiRqCvp DzvKQWIwPUAd71Lbbk8dc+P8RZW1xQqXlP4udNaiM6SpMDyUHksj0Mx3l6nrEaHhMtZeUc/kru1u KVhXNb46j03VKk66MODsoVpjqJHt19JxGZ7MoxbvMWw7GiEK9L11Q69CbTXxlm5bxdFaKSOz2Pxu ULWlPIJC0aqeK1w8pZjHUZGwPLo9qRJSdliLV7KDoOXDTa9hr9pRr3WxW9TF/AGNqxp8kZkBKqfl eovFpjiqCfWYBiq7za3+zX1ehbavc0st/vBUXiiqFqKrkBmHwpSbmoHvd24iXuIEokA55+rLkfyC 9W/Eir21akmPKjilEGA9fHFb6mFqXI1sUTM8ugLLI1y4tpUvsf8AoG0pCrUHgTLQNQwBEHagvYap rO7YjFbtf3rjhg7+oRyl9pDzR2AE+LTYsB1BYfQxddq0HM5fQ8dj1IqZ7H0lmsx7gU4vTViZclko ViZEIZdSIyFwF9h/s7t+8aP498mfX1YdXxfaSYNlwckpJWduRWPqRxCt5S4sLql28x1vhLM6S2bM zemNNLcViNWJaMKQgrQy9l4e06pplhjrnLYbK0a9eamlbrUpMw51FDAybmQiFj9ikSBYmRnIant2 8ZHJ22IzmJq0KMmFa4anVVTxpsVImvxgu4UGTsDyIUDpLTjk5QnsD9avsstznlw4oR85VVDyTTOw pxCIywyCaP7cql7iwvkrjTuwQ5OrmLWpSzdmA6M7yiQK0ZKE7aU/u3o8I7Bhsrqm4ahQ1jYbpLG/ syODsyop4AqrBnkpmh4shYEn3D0iFy+I2jT9yuNo1+2e+x96GLoqs5HIhmUhAWB5gMjhSAswfURT iRxz56exn2dwD2Ic0qDd+MNY8fWtrRV7X8vjT3EZA4KIgdJV0Ii7PH5kQjmastvmcpVP7i9LkadM aP8Ap0gdBML0n4z2W1fUtMq6prt0t7e3THm6srKOfEOxZJoJqgRUUkju3rHrhMVs22bjR2rYLZrO ytVHBGVkYleRRQrycydi5ZgAew9JetnX7flmix0/KN4CK5zHMMQhiEMQhiEU6a3iEOmsQ7Q6a6dO nw/LEIdM4kIQ6azmEOmsQ/CHTWPwhDprEIriEMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEMQhi EMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEMQhiEf//Z --089e0111b8fa8ad4a305123a4216-- From nobody Thu Mar 26 23:20:57 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2B71A1B27 for ; Thu, 26 Mar 2015 23:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxA1qnBHD4yu for ; Thu, 26 Mar 2015 23:20:53 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F2D1A1A62 for ; Thu, 26 Mar 2015 23:20:53 -0700 (PDT) Received: by wiaa2 with SMTP id a2so17557720wia.0 for ; Thu, 26 Mar 2015 23:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CVUqpqBAhIh4I+D8rP1HthIC0A4HmRdPGeZ1oiM/M2Y=; b=yN2qJWPOnhMzig1zBJAaiBx08tfu3wyQxVKwGA3inLSbGq5YS+TQx4H/CNit4mIBji DT1WzmblD7xbX3RpetC2cT7aQhBAUBzSfWU9j61AHepIQpV+ngl6La/qgIg/HoCtUI6e FA6PG5smB2SUUQScvWqlPqphqbx1deqrIB3D7w9h13OGts+S7w2yiVi7nJ6mWZscnMrG AIqcVVwsExZyfJvILx813VS5ihXPTYF7blIkR6v/kiaV0x+W5jwLUrxMjS/o1myTY4i8 fN8/pXXy1wpjhXOhtUMZClwIE8zl76SRKmFh18m1DVNxtOtzClumZeHfrLeCmCPwT8VQ xZgw== X-Received: by 10.180.107.198 with SMTP id he6mr20881245wib.68.1427437251860; Thu, 26 Mar 2015 23:20:51 -0700 (PDT) Received: from [192.168.1.79] (4.197.130.77.rev.sfr.net. [77.130.197.4]) by mx.google.com with ESMTPSA id ei8sm1957260wib.10.2015.03.26.23.20.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 23:20:51 -0700 (PDT) Message-ID: <5514F6C0.7090905@gmail.com> Date: Fri, 27 Mar 2015 07:20:48 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brian Campbell , Mike Jones References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com>

In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Shaun Cooley $shcooley$" , "jose@ietf.org" , Matt Miller Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 06:20:55 -0000 On 2015-03-27 01:31, Brian Campbell wrote: > I am pretty sure you should not make that change to the JCA algorithm string. > I'll have to search around to remember why, some oddity of Java I think, > but I'm away from my laptop right now and that one is too much to research on a phone. Indeed, this is an old SUN bug that we have to put up with: http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html It is worth a note though. Anders > > On Mar 26, 2015 6:41 PM, "Mike Jones" > wrote: > > I am working on the formatting of the algorithm cross-reference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A with the RFC Editor to make them more readable. When looking at the table content (in a more readable rendition I�ll share with you soon), I noticed that this string appears for the JCA value of three algorithms:____ > > AES/CBC/PKCS5Padding____ > > which I believe should be____ > > AES/CBC/PKCS7Padding____ > > __ __ > > This would be consistent with the changes made in -28 for the reasons described in this thread. JAVA IMPLEMENTERS� If you are currently using AES/CBC/PKCS5Padding can you please verify that your implementation still works after changing this string to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know what happened? Matt, if your code for the cookbook is in Java, it would be especially good if you made this code change and verified that nothing changes in the output.____ > > __ __ > > Also, this clearly inconsistent sentence currently occurs in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1:____ > > CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS____ > > #7 padding using the cipher with the key X.____ > > __ __ > > I believe that the identifier CBC-PKCS5-ENCshould be changed to CBC-PKCS7-ENC.____ > > __ __ > > Unless people disagree, I will plan to apply these corrections during AUTH48.____ > > __ __ > > Thanks all,____ > > -- Mike____ > > __ __ > > *From:*jose [mailto:jose-bounces@ietf.org ] *On Behalf Of *Mike Jones > *Sent:* Friday, June 20, 2014 7:03 PM > *To:* Shaun Cooley (shcooley) > *Cc:* jose@ietf.org ; Matt Miller (mamille2) > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____ > > __ __ > > This change has been incorporated in the -28 drafts.____ > > __ __ > > Thanks again, Shaun,____ > > -- Mike____ > > __ __ > > *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Friday, June 13, 2014 2:27 PM > *To:* Shaun Cooley (shcooley) > *Cc:* jose@ietf.org ; Matt Miller (mamille2) > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____ > > __ __ > > (Adding the JOSE working group)____ > > __ __ > > I believe you�re right. I�ll plan to make this change in the next version of the spec.____ > > __ __ > > Thanks for the careful read!____ > > __ __ > > -- Mike____ > > __ __ > > *From:*Shaun Cooley (shcooley) [mailto:shcooley@cisco.com] > *Sent:* Friday, June 13, 2014 10:34 AM > *To:* Mike Jones > *Cc:* Matt Miller (mamille2) > *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____ > > __ __ > > Michael �____ > > I am working on implementing a browser compatible JS implementation of JOSE, based on the work Matt Miller did for Node.JS. While going through the spec, I noticed that PKCS #5 is called out for the AES-CBC ciphers. Shouldn�t this be PKCS #7?____ > > __ __ > > PKCS #5 � RFC2898 section 6.2 specifies:____ > > The padding string PS shall consist of 8 - (||M|| mod 8) octets all having value 8 - (||M|| mod 8).____ > > __ __ > > PKCS #7 � RFC2315 section 10.3 note 2 specifies:____ > > For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input.____ > > __ __ > > PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKCS #5 is intended for block sizes of 8. This means that PKCS #7 is a superset of #5, and given that AES is a block size of 16, it seems the spec should require PKCS #7.____ > > __ __ > > Thoughts?____ > > __ __ > > *Shaun Cooley* > DISTINGUISHED ENGINEER.ENGINEERING > Collaboration Technology Group > shcooley@cisco.com > Phone: *+1 408 902 3344 * > Mobile: *+1 310 293 2087 *____ > > > > http://www.cisco.com/web/europe/images/email/signature/logo05.jpg > Cisco.com ____ > > __ __ > > This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.____ > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html____ > > __ __ > > __ __ > > > _______________________________________________ > 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 nobody Fri Mar 27 06:09:40 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2721A8780 for ; Thu, 26 Mar 2015 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AwaOOVkPUxg for ; Thu, 26 Mar 2015 17:11:21 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0B91A873E for ; Thu, 26 Mar 2015 17:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19557; q=dns/txt; s=iport; t=1427415081; x=1428624681; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0Trk+rviPAT66mBzVD0BCGHtx/lmFk9qw0Bh2cs111w=; b=dVr+nwQMIQ/+VaEK1/pxHH+dj2MfKG9XfEmGF2ArdaI9CZDuZ5V282sx YhHKZu1TfEhwfuKFYSYcLWIiRdcxMXiSY6aU0tCTFmg7kwtFQVKhMYrV5 nKn32l9HzgSHtnabgPhmG02S2qG4GB+SH682mW55vkURz3fHuR8blZ1B7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRBgDynxRV/5JdJa1cgkNDUloEwzCCAYVzAoFFTAEBAQEBAX2EFAEBAQQtXAIBCA4DBAEBCw8CDAcyFAkIAgQBEgiIJw3MBAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKIRHNwEgBwKCboEWBYULgUKHdYIOg2+HGzqCdoJaiUGDRyKBfwMcgVBvAQFjH0B/AQEB X-IronPort-AV: E=Sophos;i="5.11,476,1422921600"; d="scan'208,217";a="403915256" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 27 Mar 2015 00:10:57 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2R0AvRw014358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 00:10:57 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.108]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 19:10:57 -0500 From: "Shaun Cooley (shcooley)" To: Mike Jones , "jose@ietf.org" , "Matt Miller (mamille2)" Thread-Topic: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) Thread-Index: AQHQaB5s2b3uP7gIUkup1RKg/ZrPmZ0vdJOQ Date: Fri, 27 Mar 2015 00:10:55 +0000 Message-ID: <187A7B1DA239514F9146FC78B19AADE356CB143A@xmb-aln-x10.cisco.com> References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.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: [10.19.187.27] Content-Type: multipart/alternative; boundary="_000_187A7B1DA239514F9146FC78B19AADE356CB143Axmbalnx10ciscoc_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 06:09:37 -0700 Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:11:24 -0000 --_000_187A7B1DA239514F9146FC78B19AADE356CB143Axmbalnx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agreed. -Shaun From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, March 26, 2015 4:41 PM To: jose@ietf.org; Matt Miller (mamille2) Cc: Shaun Cooley (shcooley) Subject: RE: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PK= CS #5) I am working on the formatting of the algorithm cross-reference tables in J= WA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithm= s-40#appendix-A with the RFC Editor to make them more readable. When looki= ng at the table content (in a more readable rendition I=92ll share with you= soon), I noticed that this string appears for the JCA value of three algor= ithms: AES/CBC/PKCS5Padding which I believe should be AES/CBC/PKCS7Padding This would be consistent with the changes made in -28 for the reasons descr= ibed in this thread. JAVA IMPLEMENTERS =96 If you are currently using AES/= CBC/PKCS5Padding can you please verify that your implementation still works= after changing this string to AES/CBC/PKCS7Padding and that the results ar= e still correct and reply to us letting us know what happened? Matt, if yo= ur code for the cookbook is in Java, it would be especially good if you mad= e this code change and verified that nothing changes in the output. Also, this clearly inconsistent sentence currently occurs in http://tools.i= etf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1: CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS #7 padding using the cipher with the key X. I believe that the identifier CBC-PKCS5-ENC should be changed to CBC-PKCS7-= ENC. Unless people disagree, I will plan to apply these corrections during AUTH4= 8. Thanks all, -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, June 20, 2014 7:03 PM To: Shaun Cooley (shcooley) Cc: jose@ietf.org; Matt Miller (mamille2) Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PK= CS #5) This change has been incorporated in the -28 drafts. Thanks again, S= haun, -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, June 13, 2014 2:27 PM To: Shaun Cooley (shcooley) Cc: jose@ietf.org; Matt Miller (mamille2) Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PK= CS #5) (Adding the JOSE working group) I believe you=92re right. I=92ll plan to make this change in the next vers= ion of the spec. Thanks for the careful read! -- Mike From: Shaun Cooley (shcooley) [mailto:shcooley@cisco.com] Sent: Friday, June 13, 2014 10:34 AM To: Mike Jones Cc: Matt Miller (mamille2) Subject: draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) Michael =96 I am working on implementing a browser compatible JS implementation of JOS= E, based on the work Matt Miller did for Node.JS. While going through the = spec, I noticed that PKCS #5 is called out for the AES-CBC ciphers. Should= n=92t this be PKCS #7? PKCS #5 =96 RFC2898 section 6.2 specifies: The padding string PS shall consist of 8 - (||M|| mod 8) octets all having = value 8 - (||M|| mod 8). PKCS #7 =96 RFC2315 section 10.3 note 2 specifies: For such algorithms, the method shall be to pad the input at the trailing e= nd with k - (l mod k) octets all having value k - (l mod k), where l is the= length of the input. PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKCS #5 i= s intended for block sizes of 8. This means that PKCS #7 is a superset of = #5, and given that AES is a block size of 16, it seems the spec should requ= ire PKCS #7. Thoughts? --_000_187A7B1DA239514F9146FC78B19AADE356CB143Axmbalnx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Agreed.

-Shaun

From: Mike Jones [mailto:Michael.Jones@micros= oft.com]
Sent: Thursday, March 26, 2015 4:41 PM
To: jose@ietf.org; Matt Miller (mamille2)
Cc: Shaun Cooley (shcooley)
Subject: RE: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)

I am working on the fo= rmatting of the algorithm cross-reference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A with the RFC Editor to make them more readable. When looking at= the table content (in a more readable rendition I=92ll share with you soon= ), I noticed that this string appears for the JCA value of three algorithms:

&nbs= p; AES/CBC/PKCS= 5Padding=

which I believe should= be

&nbs= p; AES/CBC/PKCS= 7Padding=

This would be consiste= nt with the changes made in -28 for the reasons described in this thread.&n= bsp; JAVA IMPLEMENTERS =96 If you are currently using AES/CBC/PKCS5Padding can you pl= ease verify that your implementation still works after changing this string= to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know what happened?&n= bsp; Matt, if you= r code for the cookbook is in Java, it would be especially good if you made= this code change and verified that nothing changes in the output.

Also, this clearly inc= onsistent sentence currently occurs in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5= .2.1:

= ; CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS

= ; #7 padding using the cipher with the key X.

I believe that the ide= ntifier CBC-PKCS5-ENC should be changed to CBC-= PKCS7-ENC.

Unless people disagree= , I will plan to apply these corrections during AUTH48.

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

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

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, June 20, 2014 7:03 PM
To: Shaun Cooley (shcooley)
Cc: jose@ietf.org; Matt Miller = (mamille2)
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)

This change has been i= ncorporated in the -28 drafts.

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

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

(Adding the JOSE worki= ng group)

I believe you=92re rig= ht. I=92ll plan to make this change in the next version of the spec.<= o:p>

Thanks for the careful= read!

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

From: Shaun Cooley (shcooley) [mailto:shcooley@cisco.com]
Sent: Friday, June 13, 2014 10:34 AM
To: Mike Jones
Cc: Matt Miller (mamille2)
Subject: draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #= 5)

Michael =96

PKCS #5 =96 RFC2898 section 6.2 specifies:

The padding string PS shall consist of 8 - (|= |M|| mod 8) octets all having value 8 - (||M|| mod 8).

PKCS #7 =96 RFC2315 section 10.3 note 2 specifies:

For such algorithms, the method shall be to p= ad the input at the trailing end with k - (l mod k) octets all having value= k - (l mod k), where l is the length of the input.

Thoughts?

--_000_187A7B1DA239514F9146FC78B19AADE356CB143Axmbalnx10ciscoc_-- From nobody Fri Mar 27 07:36:37 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F0C1ACEA0 for ; Fri, 27 Mar 2015 07:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDDd25TStZ-d for ; Fri, 27 Mar 2015 07:36:32 -0700 (PDT) Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF011ACE8E for ; Fri, 27 Mar 2015 07:36:32 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa08-07.prod.phx3.secureserver.net with id 8ecV1q00Q15ZTut01ecWne; Fri, 27 Mar 2015 07:36:31 -0700 Message-ID: <55156AED.3060402@connect2id.com> Date: Fri, 27 Mar 2015 16:36:29 +0200 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: jose@ietf.org References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com>

<5514F6C0.7090905@gmail.com> In-Reply-To: <5514F6C0.7090905@gmail.com> Content-Type: multipart/alternative; boundary="------------060403050007020901020908" Archived-At: Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 14:36:35 -0000 This is a multi-part message in MIME format. --------------060403050007020901020908 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit This is indeed a JCA oddity, when "PKCS5Padding" is specified Java actually does "PKCS7Padding". If you stick "PKCS7Padding" you'll get an |NoSuchAlgorithmException: Cannot find any provider supporting AES/CBC/PKCS7Padding | Vladimir On 27.03.2015 08:20, Anders Rundgren wrote: > On 2015-03-27 01:31, Brian Campbell wrote: >> I am pretty sure you should not make that change to the JCA algorithm >> string. > > I'll have to search around to remember why, some oddity of Java I > think, > > but I'm away from my laptop right now and that one is too much to > research on a phone. > > Indeed, this is an old SUN bug that we have to put up with: > http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html > > It is worth a note though. > > Anders > >> >> On Mar 26, 2015 6:41 PM, "Mike Jones" > > wrote: >> >> I am working on the formatting of the algorithm cross-reference >> tables in JWA Appendix A >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A >> with the RFC Editor to make them more readable. When looking at the >> table content (in a more readable rendition I�ll share with you >> soon), I noticed that this string appears for the JCA value of three >> algorithms:____ >> >> AES/CBC/PKCS5Padding____ >> >> which I believe should be____ >> >> AES/CBC/PKCS7Padding____ >> >> __ __ >> >> This would be consistent with the changes made in -28 for the >> reasons described in this thread. JAVA IMPLEMENTERS� If you are >> currently using AES/CBC/PKCS5Padding can you please verify that your >> implementation still works after changing this string to >> AES/CBC/PKCS7Padding and that the results are still correct and reply >> to us letting us know what happened? Matt, if your code for the >> cookbook is in Java, it would be especially good if you made this >> code change and verified that nothing changes in the output.____ >> >> __ __ >> >> Also, this clearly inconsistent sentence currently occurs in >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1:____ >> >> >> CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P >> using PKCS____ >> >> #7 padding using the cipher with the key X.____ >> >> __ __ >> >> I believe that the identifier CBC-PKCS5-ENCshould be changed to >> CBC-PKCS7-ENC.____ >> >> __ __ >> >> Unless people disagree, I will plan to apply these corrections >> during AUTH48.____ >> >> __ __ >> >> >> Thanks all,____ >> >> -- >> Mike____ >> >> __ __ >> >> *From:*jose [mailto:jose-bounces@ietf.org >> ] *On Behalf Of *Mike Jones >> *Sent:* Friday, June 20, 2014 7:03 PM >> *To:* Shaun Cooley (shcooley) >> *Cc:* jose@ietf.org ; Matt Miller (mamille2) >> *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: >> section-5.2 (PKCS #5)____ >> >> __ __ >> >> This change has been incorporated in the -28 drafts.____ >> >> __ __ >> >> >> Thanks again, Shaun,____ >> >> -- >> Mike____ >> >> __ __ >> >> *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones >> *Sent:* Friday, June 13, 2014 2:27 PM >> *To:* Shaun Cooley (shcooley) >> *Cc:* jose@ietf.org ; Matt Miller (mamille2) >> *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: >> section-5.2 (PKCS #5)____ >> >> __ __ >> >> (Adding the JOSE working group)____ >> >> __ __ >> >> I believe you�re right. I�ll plan to make this change in the >> next version of the spec.____ >> >> __ __ >> >> Thanks for the careful read!____ >> >> __ __ >> >> -- >> Mike____ >> >> __ __ >> >> *From:*Shaun Cooley (shcooley) [mailto:shcooley@cisco.com] >> *Sent:* Friday, June 13, 2014 10:34 AM >> *To:* Mike Jones >> *Cc:* Matt Miller (mamille2) >> *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2 >> (PKCS #5)____ >> >> __ __ >> >> Michael �____ >> >> I am working on implementing a browser compatible JS >> implementation of JOSE, based on the work Matt Miller did for >> Node.JS. While going through the spec, I noticed that PKCS #5 is >> called out for the AES-CBC ciphers. Shouldn�t this be PKCS #7?____ >> >> __ __ >> >> PKCS #5 � RFC2898 section 6.2 specifies:____ >> >> The padding string PS shall consist of 8 - (||M|| mod 8) octets >> all having value 8 - (||M|| mod 8).____ >> >> __ __ >> >> PKCS #7 � RFC2315 section 10.3 note 2 specifies:____ >> >> For such algorithms, the method shall be to pad the input at the >> trailing end with k - (l mod k) octets all having value k - (l mod >> k), where l is the length of the input.____ >> >> __ __ >> >> PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas >> PKCS #5 is intended for block sizes of 8. This means that PKCS #7 is >> a superset of #5, and given that AES is a block size of 16, it seems >> the spec should require PKCS #7.____ >> >> __ __ >> >> Thoughts?____ >> >> __ __ >> >> *Shaun Cooley* >> DISTINGUISHED ENGINEER.ENGINEERING >> Collaboration Technology Group >> shcooley@cisco.com >> Phone: *+1 408 902 3344 * >> Mobile: *+1 310 293 2087 *____ >> >> >> >> http://www.cisco.com/web/europe/images/email/signature/logo05.jpg >> Cisco.com ____ >> >> __ __ >> >> This email may contain confidential and privileged material for >> the sole use of the intended recipient. Any review, use, distribution >> or disclosure by others is strictly prohibited. If you are not the >> intended recipient (or authorized to receive for the recipient), >> please contact the sender by reply email and delete all copies of >> this message.____ >> >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html____ >> >> __ __ >> >> __ __ >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- Vladimir Dzhuvinov :: vladimir@connect2id.com --------------060403050007020901020908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit This is indeed a JCA oddity, when "PKCS5Padding" is specified Java actually does "PKCS7Padding".

If you stick "PKCS7Padding" you'll get an

NoSuchAlgorithmException: Cannot find any provider supporting AES/CBC/PKCS7Padding

Vladimir

On 27.03.2015 08:20, Anders Rundgren wrote:

On 2015-03-27 01:31, Brian Campbell wrote:

I am pretty sure you should not make that change to the JCA algorithm string.

>� I'll have to search around to remember why, some oddity of Java I think,
> but I'm away from my laptop right now and that one is too much to research on a phone.

Indeed, this is an old SUN bug that we have to put up with:
http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html

It is worth a note though.

Anders

On Mar 26, 2015 6:41 PM, "Mike Jones" <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:

�� I am working on the formatting of the algorithm cross-reference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A with the RFC Editor to make them more readable.� When looking at the table content (in a more readable rendition I�ll share with you soon), I noticed that this string appears for the JCA value of three algorithms:____

�� AES/CBC/PKCS5Padding____

�� which I believe should be____

�� AES/CBC/PKCS7Padding____

�� __ __

�� This would be consistent with the changes made in -28 for the reasons described in this thread. JAVA IMPLEMENTERS� If you are currently using AES/CBC/PKCS5Padding can you please verify that your implementation still works after changing this string to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know what happened? Matt, if your code for the cookbook is in Java, it would be especially good if you made this code change and verified that nothing changes in the output.____

�� __ __

�� Also, this clearly inconsistent sentence currently occurs in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1:____

�� CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS____

�� #7 padding using the cipher with the key X.____

�� __ __

�� I believe that the identifier CBC-PKCS5-ENCshould be changed to CBC-PKCS7-ENC.____

�� __ __

�� Unless people disagree, I will plan to apply these corrections during AUTH48.____

�� __ __

�� Thanks all,____

�� -- Mike____

�� __ __

�� *From:*jose [mailto:jose-bounces@ietf.org <mailto:jose-bounces@ietf.org>] *On Behalf Of *Mike Jones
�� *Sent:* Friday, June 20, 2014 7:03 PM
�� *To:* Shaun Cooley (shcooley)
�� *Cc:* jose@ietf.org <mailto:jose@ietf.org>; Matt Miller (mamille2)
�� *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____

�� __ __

�� This change has been incorporated in the -28 drafts.____

�� __ __

�� Thanks again, Shaun,____

�� -- Mike____

�� __ __

�� *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones
�� *Sent:* Friday, June 13, 2014 2:27 PM
�� *To:* Shaun Cooley (shcooley)
�� *Cc:* jose@ietf.org <mailto:jose@ietf.org>; Matt Miller (mamille2)
�� *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____

�� __ __

�� (Adding the JOSE working group)____

�� __ __

�� I believe you�re right.� I�ll plan to make this change in the next version of the spec.____

�� __ __

�� Thanks for the careful read!____

�� __ __

�� -- Mike____

�� __ __

�� *From:*Shaun Cooley (shcooley) [mailto:shcooley@cisco.com]
�� *Sent:* Friday, June 13, 2014 10:34 AM
�� *To:* Mike Jones
�� *Cc:* Matt Miller (mamille2)
�� *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____

�� __ __

�� Michael �____

�� I am working on implementing a browser compatible JS implementation of JOSE, based on the work Matt Miller did for Node.JS.� While going through the spec, I noticed that PKCS #5 is called out for the AES-CBC ciphers.� Shouldn�t this be PKCS #7?____

�� __ __

�� PKCS #5 � RFC2898 section 6.2 specifies:____

�� The padding string PS shall consist of 8 - (||M|| mod 8) octets all having value 8 - (||M|| mod 8).____

�� __ __

�� PKCS #7 � RFC2315 section 10.3 note 2 specifies:____

�� For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input.____

�� __ __

�� PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKCS #5 is intended for block sizes of 8.� This means that PKCS #7 is a superset of #5, and given that AES is a block size of 16, it seems the spec should require PKCS #7.____

�� __ __

�� Thoughts?____

�� __ __

�� *Shaun Cooley*
�� DISTINGUISHED ENGINEER.ENGINEERING
�� Collaboration Technology Group
�� shcooley@cisco.com <mailto:shcooley@cisco.com>
�� Phone: *+1 408 902 3344 <tel:%2B1%20408%20902%203344>*
�� Mobile: *+1 310 293 2087 <tel:%2B1%20310%20293%202087>*____

��

�� http://www.cisco.com/web/europe/images/email/signature/logo05.jpg
�� Cisco.com <http://www.cisco.com/>____

�� __ __

�� This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.____

�� For corporate legal information go to:
�� http://www.cisco.com/web/about/doing_business/legal/cri/index.html____

�� __ __

�� __ __

�� _______________________________________________
�� jose mailing list
�� jose@ietf.org <mailto:jose@ietf.org>
�� https://www.ietf.org/mailman/listinfo/jose

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

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

-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com

--------------060403050007020901020908-- From nobody Fri Mar 27 07:42:11 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CF51ACE75 for ; Fri, 27 Mar 2015 07:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYDuqxNOzP2h for ; Fri, 27 Mar 2015 07:42:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BCE1A8834 for ; Fri, 27 Mar 2015 07:42:04 -0700 (PDT) Received: from BLUPR03MB440.namprd03.prod.outlook.com (10.141.78.154) by BLUPR03MB1476.namprd03.prod.outlook.com (25.163.81.18) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 27 Mar 2015 14:42:03 +0000 Received: from BLUPR03MB437.namprd03.prod.outlook.com (10.141.78.147) by BLUPR03MB440.namprd03.prod.outlook.com (10.141.78.154) with Microsoft SMTP Server (TLS) id 15.1.125.14; Fri, 27 Mar 2015 14:42:01 +0000 Received: from BLUPR03MB437.namprd03.prod.outlook.com ([10.141.78.147]) by BLUPR03MB437.namprd03.prod.outlook.com ([10.141.78.147]) with mapi id 15.01.0125.002; Fri, 27 Mar 2015 14:42:01 +0000 From: Mike Jones To: Vladimir Dzhuvinov , "jose@ietf.org" Thread-Topic: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) Thread-Index: AQHQaB5bkfOhNCQj00mWiSuBrydmnp0vep8AgABheACAAIp+gIAAAWcA Date: Fri, 27 Mar 2015 14:42:01 +0000 Message-ID: References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com>

<5514F6C0.7090905@gmail.com> <55156AED.3060402@connect2id.com> In-Reply-To: <55156AED.3060402@connect2id.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.52.104] authentication-results: connect2id.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB440; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1476; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(51914003)(377454003)(24454002)(43784003)(36304003)(377424004)(92566002)(66066001)(2950100001)(2900100001)(76576001)(46102003)(74316001)(99286002)(86362001)(93886004)(19617315012)(86612001)(107886001)(19300405004)(2501003)(77096005)(2656002)(16236675004)(33656002)(106356001)(77156002)(62966003)(50986999)(87936001)(76176999)(54356999)(19580395003)(19580405001)(40100003)(106116001)(19625215002)(122556002)(102836002)(15975445007)(230783001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB440; H:BLUPR03MB437.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR03MB440; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB440; x-forefront-prvs: 0528942FD8 Content-Type: multipart/alternative; boundary="_000_BLUPR03MB437FA23B6B756B3DB551FC6F5090BLUPR03MB437namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 14:42:01.3812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB440 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 14:42:10 -0000 --_000_BLUPR03MB437FA23B6B756B3DB551FC6F5090BLUPR03MB437namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a bunch, Vladimir. That definitively answers the question. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov Sent: Friday, March 27, 2015 9:36 AM To: jose@ietf.org Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PK= CS #5) This is indeed a JCA oddity, when "PKCS5Padding" is specified Java actually= does "PKCS7Padding". If you stick "PKCS7Padding" you'll get an NoSuchAlgorithmException: Cannot find any provider supporting AES/CBC/PKCS7= Padding Vladimir On 27.03.2015 08:20, Anders Rundgren wrote: On 2015-03-27 01:31, Brian Campbell wrote: I am pretty sure you should not make that change to the JCA algorithm strin= g. > I'll have to search around to remember why, some oddity of Java I think, > but I'm away from my laptop right now and that one is too much to researc= h on a phone. Indeed, this is an old SUN bug that we have to put up with: http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html It is worth a note though. Anders On Mar 26, 2015 6:41 PM, "Mike Jones" > wrote: I am working on the formatting of the algorithm cross-reference tables = in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algor= ithms-40#appendix-A with the RFC Editor to make them more readable. When l= ooking at the table content (in a more readable rendition I'll share with y= ou soon), I noticed that this string appears for the JCA value of three alg= orithms:____ AES/CBC/PKCS5Padding____ which I believe should be____ AES/CBC/PKCS7Padding____ __ __ This would be consistent with the changes made in -28 for the reasons d= escribed in this thread. JAVA IMPLEMENTERS- If you are currently using AES/= CBC/PKCS5Padding can you please verify that your implementation still works= after changing this string to AES/CBC/PKCS7Padding and that the results ar= e still correct and reply to us letting us know what happened? Matt, if you= r code for the cookbook is in Java, it would be especially good if you made= this code change and verified that nothing changes in the output.____ __ __ Also, this clearly inconsistent sentence currently occurs in http://too= ls.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1:____ CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PK= CS____ #7 padding using the cipher with the key X.____ __ __ I believe that the identifier CBC-PKCS5-ENCshould be changed to CBC-PKC= S7-ENC.____ __ __ Unless people disagree, I will plan to apply these corrections during A= UTH48.____ __ __ Thanks all= ,____ -- Mike___= _ __ __ *From:*jose [mailto:jose-bounces@ietf.org

] *On Behalf Of *Mike Jones *Sent:* Friday, June 20, 2014 7:03 PM *To:* Shaun Cooley (shcooley) *Cc:* jose@ietf.org ; Matt Miller (mamille2) *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5= .2 (PKCS #5)____ __ __ This change has been incorporated in the -28 drafts.____ __ __ Thanks aga= in, Shaun,____ -- Mike___= _ __ __ *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones *Sent:* Friday, June 13, 2014 2:27 PM *To:* Shaun Cooley (shcooley) *Cc:* jose@ietf.org ; Matt Miller (mamille2) *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5= .2 (PKCS #5)____ __ __ (Adding the JOSE working group)____ __ __ I believe you're right. I'll plan to make this change in the next vers= ion of the spec.____ __ __ Thanks for the careful read!____ __ __ -- Mike___= _ __ __ *From:*Shaun Cooley (shcooley) [mailto:shcooley@cisco.com] *Sent:* Friday, June 13, 2014 10:34 AM *To:* Mike Jones *Cc:* Matt Miller (mamille2) *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5= )____ __ __ Michael -____ I am working on implementing a browser compatible JS implementation o= f JOSE, based on the work Matt Miller did for Node.JS. While going through= the spec, I noticed that PKCS #5 is called out for the AES-CBC ciphers. S= houldn't this be PKCS #7?____ __ __ PKCS #5 - RFC2898 section 6.2 specifies:____ The padding string PS shall consist of 8 - (||M|| mod 8) octets all hav= ing value 8 - (||M|| mod 8).____ __ __ PKCS #7 - RFC2315 section 10.3 note 2 specifies:____ For such algorithms, the method shall be to pad the input at the traili= ng end with k - (l mod k) octets all having value k - (l mod k), where l is= the length of the input.____ __ __ PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKCS = #5 is intended for block sizes of 8. This means that PKCS #7 is a superset= of #5, and given that AES is a block size of 16, it seems the spec should = require PKCS #7.____ __ __ Thoughts?____ __ __ *Shaun Cooley* DISTINGUISHED ENGINEER.ENGINEERING Collaboration Technology Group shcooley@cisco.com Phone: *+1 408 902 3344 * Mobile: *+1 310 293 2087 *____ http://www.cisco.com/web/europe/images/email/signature/logo05.jpg Cisco.com ____ __ __ This email may contain confidential and privileged material for the sol= e use of the intended recipient. Any review, use, distribution or disclosur= e by others is strictly prohibited. If you are not the intended recipient (= or authorized to receive for the recipient), please contact the sender by r= eply email and delete all copies of this message.____ For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html____ __ __ __ __ _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- Vladimir Dzhuvinov :: vladimir@connect2id.com --_000_BLUPR03MB437FA23B6B756B3DB551FC6F5090BLUPR03MB437namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks a bunch, Vladimir.= That definitively answers the question.

<= /p>

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

<= /p>

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Friday, March 27, 2015 9:36 AM
To: jose@ietf.org
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)

This is indeed a JCA = oddity, when "PKCS5Padding" is specified Java actually does "= ;PKCS7Padding".

If you stick "PKCS7Padding" you'll get an

NoSuchAlgorithmException: Cannot find any provider supporting AES=
/CBC/PKCS7Padding

Vladimir

On 27.03.2015 08:20, Anders Rundgren wrote:

On 2015-03-27 01:31, Brian Campbell wrote:

I am pretty sure you should not make that change to = the JCA algorithm string.

> I'll have to search around to remember wh= y, some oddity of Java I think,
> but I'm away from my laptop right now and that one is too much to rese= arch on a phone.

Indeed, this is an old SUN bug that we have to put up with:
http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html

It is worth a note though.

Anders

On Mar 26, 2015 6:41 PM, "Mike Jones" <Michael.Jones@microsoft.com <mailto:Michael.Jones@mic= rosoft.com>> wrote:

    I am working on the formatting of the algorithm cross-re= ference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A with the RFC Editor to make them more readable. When looking at= the table content (in a more readable rendition I’ll share with you = soon), I noticed that this string appears for the JCA value of three algorithms:____

            &nb= sp;       AES/CBC/PKCS5Padding____

    which I believe should be____

            &nb= sp;       AES/CBC/PKCS7Padding____

    __ __

    This would be consistent with the changes made in -28 fo= r the reasons described in this thread. JAVA IMPLEMENTERS– If you are= currently using AES/CBC/PKCS5Padding can you please verify that your imple= mentation still works after changing this string to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know wha= t happened? Matt, if your code for the cookbook is in Java, it would be esp= ecially good if you made this code change and verified that nothing changes= in the output.____

    __ __

    Also, this clearly inconsistent sentence currently occur= s in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5= .2.1:____

           CBC-PKCS5-ENC(= X, P) denotes the AES CBC encryption of P using PKCS____

           #7 padding usi= ng the cipher with the key X.____

    __ __

    I believe that the identifier CBC-PKCS5-ENCshould be cha= nged to CBC-PKCS7-ENC.____

    __ __

    Unless people disagree, I will plan to apply these corre= ctions during AUTH48.____

    __ __

            &nb= sp;            =             &nb= sp;            =             &nb= sp; Thanks all,____

            &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike____

    __ __

    *From:*jose [ma= ilto:jose-bounces@ietf.org <mailto:jose-bounces@ietf.org&g= t;] *On Behalf Of *Mike Jones
    *Sent:* Friday, June 20, 2014 7:03 PM
    *To:* Shaun Cooley (shcooley)
    *Cc:* jose@ietf.org= <mailto:jose@ietf.org>; Matt Miller (mamille2)
    *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithm= s-27: section-5.2 (PKCS #5)____

    __ __

    This change has been incorporated in the -28 drafts.____=

    __ __

            &nb= sp;            =             &nb= sp;            =             &nb= sp; Thanks again, Shaun,____

            &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike____

    __ __

    *From:*jose [ma= ilto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones
    *Sent:* Friday, June 13, 2014 2:27 PM
    *To:* Shaun Cooley (shcooley)
    *Cc:* jose@ietf.org= <mailto:jose@ietf.org>; Matt Miller (mamille2)
    *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithm= s-27: section-5.2 (PKCS #5)____

    __ __

    (Adding the JOSE working group)____

    __ __

    I believe you’re right. I’ll plan to m= ake this change in the next version of the spec.____

    __ __

    Thanks for the careful read!____

    __ __

            &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike____

    __ __

    *From:*Shaun Cooley (shcooley) [mailto:shcooley@cisco.com]
    *Sent:* Friday, June 13, 2014 10:34 AM
    *To:* Mike Jones
    *Cc:* Matt Miller (mamille2)
    *Subject:* draft-ietf-jose-json-web-algorithms-27: secti= on-5.2 (PKCS #5)____

    __ __

    Michael –____

      I am working on implementing a browser compa= tible JS implementation of JOSE, based on the work Matt Miller did for Node= .JS. While going through the spec, I noticed that PKCS #5 is called o= ut for the AES-CBC ciphers. Shouldn’t this be PKCS #7?____

    __ __

    PKCS #5 – RFC2898 section 6.2 specifies:____

    The padding string PS shall consist of 8 - (||M|| mod 8)= octets all having value 8 - (||M|| mod 8).____

    __ __

    PKCS #7 – RFC2315 section 10.3 note 2 specifies:__= __

    For such algorithms, the method shall be to pad the inpu= t at the trailing end with k - (l mod k) octets all having value k - (l mod= k), where l is the length of the input.____

    __ __

    PKCS #7 allows for padding in block sizes of 2-255 bytes= , whereas PKCS #5 is intended for block sizes of 8. This means that P= KCS #7 is a superset of #5, and given that AES is a block size of 16, it se= ems the spec should require PKCS #7.____

    __ __

    Thoughts?____

    __ __

    *Shaun Cooley*
    DISTINGUISHED ENGINEER.ENGINEERING
    Collaboration Technology Group
    shcooley@cisco.com= <mailto:shcooley@cisco.com>
    Phone: *+1 408 902 3344 <tel:%2B1%20408%20902%203344>*
    Mobile: *+1 310 293 2087 <tel:%2B1%20310%20293%202087>*____



    http://www.cisco.com/web/europe/images/email/signatur= e/logo05.jpg
    Cisco.com <http://w= ww.cisco.com/>____

    __ __

    This email may contain confidential and privileged mater= ial for the sole use of the intended recipient. Any review, use, distributi= on or disclosure by others is strictly prohibited. If you are not the inten= ded recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies= of this message.____

    For corporate legal information go to:
    http://www.cisco.com/web/about/doing_business/legal/cri/index.html____ =

    __ __

    __ __

    _______________________________________________
    jose mailing list
    jose@ietf.org <mailto:jose@ietf.org>
    h= ttps://www.ietf.org/mailman/listinfo/jose

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

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

--

Vladimir Dzhuvinov :: vladi=
mir@connect2id.com

--_000_BLUPR03MB437FA23B6B756B3DB551FC6F5090BLUPR03MB437namprd_-- From nobody Fri Mar 27 10:15:55 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692701B2A52 for ; Fri, 27 Mar 2015 10:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK-pWaQFE4Ia for ; Fri, 27 Mar 2015 10:15:51 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DE01B2A3A for ; Fri, 27 Mar 2015 10:15:45 -0700 (PDT) Received: from mail-ig0-f181.google.com ([209.85.213.181]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKVRWQQcK3PDQ9w/Ijgm6wvZkzi0rLc/q1@postini.com; Fri, 27 Mar 2015 10:15:45 PDT Received: by igbqf9 with SMTP id qf9so25654382igb.1 for ; Fri, 27 Mar 2015 10:15:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ssmhff6RcX8P5jFylwqi27Qv/US++WyUuX4fqIhw85Q=; b=AZ+2Cp3F8uwxIcHAEKHBJv4YZWv1FP771svwgOw8LYdKbxovdO8SvcreEfxxEluy0W 7BeXlG74pVIy12a4nBD8lgGJ4J38TUogDeBLXmpt4bghcQCK1XUTSDXmYEfz1J1BC/mR cudx7k+PfLTW0zUxXZKL6MM0YpDHsF4Oks2QnvlUx4+XvuavbrD1glULrK3ETfj3ux/t YiKOg64qB12ieZI+jrWAGyL5fttNV+SQCGMCKmIlIfGida8ZEKiAG6ZDu12j45JM7CH6 pMtgWYP57dLC7OtHCPVKNYbuK+uaYiuCRbtBOP2kc3iKJmWvvEI2CAEjEHtYDFpEvUpZ um3w== X-Gm-Message-State: ALoCoQnyYT4JJCN+V8C4HAaPs23Pajr5ujPnav5DP9E50e8jykompbvhRWbf9CQcYkKscvvZzEeShVdPKpSN/XP6VzBfw09nOfmIqnQsrDpf5DrOaqVMsdzDuVI+jCKtGap44Bt/vUi1 X-Received: by 10.50.30.138 with SMTP id s10mr3444525igh.3.1427476544769; Fri, 27 Mar 2015 10:15:44 -0700 (PDT) X-Received: by 10.50.30.138 with SMTP id s10mr3444509igh.3.1427476544593; Fri, 27 Mar 2015 10:15:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Fri, 27 Mar 2015 10:15:14 -0700 (PDT) In-Reply-To: References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com>

<5514F6C0.7090905@gmail.com> <55156AED.3060402@connect2id.com> From: Brian Campbell Date: Fri, 27 Mar 2015 12:15:14 -0500 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=047d7bdc9f505dbbdb05124848a0 Archived-At: Cc: "jose@ietf.org" , Vladimir Dzhuvinov Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:15:54 -0000 --047d7bdc9f505dbbdb05124848a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It may or may not warrant a note of some sort to explain the discrepancy (not sure if that's really in scope). It looks as though some providers like Bouncy Castle and the one on Android will work with "AES/CBC/PKCS7Padding". But "AES/CBC/PKCS5Padding" is what is needed for the Sun/Oracle JCA provider (I verified this again against Java 7 & 8) and is what is required by "Every implementation of the Java platform" per http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html and it actually give you PKCS7Padding even though it says 5. On Fri, Mar 27, 2015 at 9:42 AM, Mike Jones wrote: > Thanks a bunch, Vladimir. That definitively answers the question. > > > > -- Mike > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Vladimir > Dzhuvinov > *Sent:* Friday, March 27, 2015 9:36 AM > *To:* jose@ietf.org > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 > (PKCS #5) > > > > This is indeed a JCA oddity, when "PKCS5Padding" is specified Java > actually does "PKCS7Padding". > > If you stick "PKCS7Padding" you'll get an > > NoSuchAlgorithmException: Cannot find any provider supporting AES/CBC/PKC= S7Padding > > > > > > Vladimir > > On 27.03.2015 08:20, Anders Rundgren wrote: > > On 2015-03-27 01:31, Brian Campbell wrote: > > I am pretty sure you should not make that change to the JCA algorithm > string. > > > I'll have to search around to remember why, some oddity of Java I > think, > > but I'm away from my laptop right now and that one is too much to > research on a phone. > > Indeed, this is an old SUN bug that we have to put up with: > http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html > > It is worth a note though. > > Anders > > > > On Mar 26, 2015 6:41 PM, "Mike Jones" > > wrote: > > I am working on the formatting of the algorithm cross-reference table= s > in JWA Appendix A > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendi= x-A > with the RFC Editor to make them more readable. When looking at the tabl= e > content (in a more readable rendition I=E2=80=99ll share with you soon), = I noticed > that this string appears for the JCA value of three algorithms:____ > > AES/CBC/PKCS5Padding____ > > which I believe should be____ > > AES/CBC/PKCS7Padding____ > > __ __ > > This would be consistent with the changes made in -28 for the reasons > described in this thread. JAVA IMPLEMENTERS=E2=80=93 If you are currently= using > AES/CBC/PKCS5Padding can you please verify that your implementation still > works after changing this string to AES/CBC/PKCS7Padding and that the > results are still correct and reply to us letting us know what happened? > Matt, if your code for the cookbook is in Java, it would be especially go= od > if you made this code change and verified that nothing changes in the > output.____ > > __ __ > > Also, this clearly inconsistent sentence currently occurs in > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section= -5.2.1:____ > > CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using > PKCS____ > > #7 padding using the cipher with the key X.____ > > __ __ > > I believe that the identifier CBC-PKCS5-ENCshould be changed to > CBC-PKCS7-ENC.____ > > __ __ > > Unless people disagree, I will plan to apply these corrections during > AUTH48.____ > > __ __ > > Thanks > all,____ > > -- > Mike____ > > __ __ > > *From:*jose [mailto:jose-bounces@ietf.org >

] *On Behalf Of > *Mike Jones > *Sent:* Friday, June 20, 2014 7:03 PM > *To:* Shaun Cooley (shcooley) > *Cc:* jose@ietf.org ; Matt > Miller (mamille2) > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: > section-5.2 (PKCS #5)____ > > __ __ > > This change has been incorporated in the -28 drafts.____ > > __ __ > > Thanks > again, Shaun,____ > > -- > Mike____ > > __ __ > > *From:*jose [mailto:jose-bounces@ietf.org ] > *On Behalf Of *Mike Jones > *Sent:* Friday, June 13, 2014 2:27 PM > *To:* Shaun Cooley (shcooley) > *Cc:* jose@ietf.org ; Matt > Miller (mamille2) > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: > section-5.2 (PKCS #5)____ > > __ __ > > (Adding the JOSE working group)____ > > __ __ > > I believe you=E2=80=99re right. I=E2=80=99ll plan to make this chang= e in the next > version of the spec.____ > > __ __ > > Thanks for the careful read!____ > > __ __ > > -- > Mike____ > > __ __ > > *From:*Shaun Cooley (shcooley) [mailto:shcooley@cisco.com > ] > *Sent:* Friday, June 13, 2014 10:34 AM > *To:* Mike Jones > *Cc:* Matt Miller (mamille2) > *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS > #5)____ > > __ __ > > Michael =E2=80=93____ > > I am working on implementing a browser compatible JS implementation > of JOSE, based on the work Matt Miller did for Node.JS. While going > through the spec, I noticed that PKCS #5 is called out for the AES-CBC > ciphers. Shouldn=E2=80=99t this be PKCS #7?____ > > __ __ > > PKCS #5 =E2=80=93 RFC2898 section 6.2 specifies:____ > > The padding string PS shall consist of 8 - (||M|| mod 8) octets all > having value 8 - (||M|| mod 8).____ > > __ __ > > PKCS #7 =E2=80=93 RFC2315 section 10.3 note 2 specifies:____ > > For such algorithms, the method shall be to pad the input at the > trailing end with k - (l mod k) octets all having value k - (l mod k), > where l is the length of the input.____ > > __ __ > > PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKC= S > #5 is intended for block sizes of 8. This means that PKCS #7 is a supers= et > of #5, and given that AES is a block size of 16, it seems the spec should > require PKCS #7.____ > > __ __ > > Thoughts?____ > > __ __ > > *Shaun Cooley* > DISTINGUISHED ENGINEER.ENGINEERING > Collaboration Technology Group > shcooley@cisco.com > Phone: *+1 408 902 3344 <%2B1%20408%20902%203344>>* > Mobile: *+1 310 293 2087 <%2B1%20310%20293%202087>>*____ > > > > http://www.cisco.com/web/europe/images/email/signature/logo05.jpg > Cisco.com ____ > > __ __ > > This email may contain confidential and privileged material for the > sole use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact th= e > sender by reply email and delete all copies of this message.____ > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html___= _ > > __ __ > > __ __ > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > -- > > Vladimir Dzhuvinov :: vladimir@connect2id.com > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --047d7bdc9f505dbbdb05124848a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It may or may not warrant a note of some sort to explain t= he discrepancy (not sure if that's really in scope). It looks as though= some providers like Bouncy Castle and the one on Android will work with &q= uot;AES/CBC/PKCS7Padding". But "AES/CBC/PKCS5Padding" is wha= t is needed for the Sun/Oracle JCA provider (I verified this again against = Java 7 & 8) and is what is required by "Every implementation of th= e Java platform" per http://docs.oracle.com/javase/7/docs/api/javax= /crypto/Cipher.html and it actually give you PKCS7Padding even though i= t says 5.

On Fri, Mar 27, 2015 at 9:42 AM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

Thanks a bunch, Vladimir.= =C2=A0 That definitively answers the question.

=C2=A0

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

=C2=A0

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Friday, March 27, 2015 9:36 AM
To: jose@ietf.org=
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-= 5.2 (PKCS #5)
=C2=A0

This is indeed a JCA = oddity, when "PKCS5Padding" is specified Java actually does "= ;PKCS7Padding".

If you stick "PKCS7Padding" you'll get an
NoSuchAlgorithmException: Cannot find any provider supporting AES/<=
span>CBC/PKCS7Padding
=C2=A0
=C2=A0
Vladimir

On 27.03.2015 08:20, Anders Rundgren wrote:

On 2015-03-27 01:31, Brian Campbell wrote:

I am pretty sure you should not make that change to = the JCA algorithm string.

>=C2=A0 I'll have to search around to remembe= r why, some oddity of Java I think,
> but I'm away from my laptop right now and that one is too much to = research on a phone.

Indeed, this is an old SUN bug that we have to put up with:
http://docs.oracle.com/javase/7/docs/api/javax/crypto/= Cipher.html

It is worth a note though.

Anders

On Mar 26, 2015 6:41 PM, "Mike Jones" <Michael.Jones@microsoft.com <mailto= :Michael.Jones@microsoft.com>> wrote:

=C2=A0=C2=A0=C2=A0 I am working on the formatting of the algorithm cross-re= ference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-= A with the RFC Editor to make them more readable.=C2=A0 When looking at= the table content (in a more readable rendition I=E2=80=99ll share with yo= u soon), I noticed that this string appears for the JCA value of three algorithms:____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AES/CBC/PKCS5Padding____

=C2=A0=C2=A0=C2=A0 which I believe should be____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AES/CBC/PKCS7Padding____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 This would be consistent with the changes made in -28 fo= r the reasons described in this thread. JAVA IMPLEMENTERS=E2=80=93 If you a= re currently using AES/CBC/PKCS5Padding can you please verify that your imp= lementation still works after changing this string to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know wha= t happened? Matt, if your code for the cookbook is in Java, it would be esp= ecially good if you made this code change and verified that nothing changes= in the output.____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 Also, this clearly inconsistent sentence currently occur= s in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5= .2.1:____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CBC-PKCS5-ENC(= X, P) denotes the AES CBC encryption of P using PKCS____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #7 padding usi= ng the cipher with the key X.____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 I believe that the identifier CBC-PKCS5-ENCshould be cha= nged to CBC-PKCS7-ENC.____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 Unless people disagree, I will plan to apply these corre= ctions during AUTH48.____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Thanks all,____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 *From:*jose [mailto:jose-bounces@ietf.org <mailto:jose-= bounces@ietf.org>] *On Behalf Of *Mike Jones
=C2=A0=C2=A0=C2=A0 *Sent:* Friday, June 20, 2014 7:03 PM
=C2=A0=C2=A0=C2=A0 *To:* Shaun Cooley (shcooley)
=C2=A0=C2=A0=C2=A0 *Cc:* jose@ietf.org <mailto:jose@ietf.org>; Matt Miller (mamille2)
=C2=A0=C2=A0=C2=A0 *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithm= s-27: section-5.2 (PKCS #5)____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 This change has been incorporated in the -28 drafts.____=

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Thanks again, Shaun,____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones
=C2=A0=C2=A0=C2=A0 *Sent:* Friday, June 13, 2014 2:27 PM
=C2=A0=C2=A0=C2=A0 *To:* Shaun Cooley (shcooley)
=C2=A0=C2=A0=C2=A0 *Cc:* jose@ietf.org <mailto:jose@ietf.org>; Matt Miller (mamille2)
=C2=A0=C2=A0=C2=A0 *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithm= s-27: section-5.2 (PKCS #5)____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 (Adding the JOSE working group)____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 I believe you=E2=80=99re right.=C2=A0 I=E2=80=99ll plan = to make this change in the next version of the spec.____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 Thanks for the careful read!____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 *From:*Shaun Cooley (shcooley) [mailto:shcooley@cisco.com]
=C2=A0=C2=A0=C2=A0 *Sent:* Friday, June 13, 2014 10:34 AM
=C2=A0=C2=A0=C2=A0 *To:* Mike Jones
=C2=A0=C2=A0=C2=A0 *Cc:* Matt Miller (mamille2)
=C2=A0=C2=A0=C2=A0 *Subject:* draft-ietf-jose-json-web-algorithms-27: secti= on-5.2 (PKCS #5)____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 Michael =E2=80=93____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am working on implementing a browser compa= tible JS implementation of JOSE, based on the work Matt Miller did for Node= .JS.=C2=A0 While going through the spec, I noticed that PKCS #5 is called o= ut for the AES-CBC ciphers.=C2=A0 Shouldn=E2=80=99t this be PKCS #7?____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 PKCS #5 =E2=80=93 RFC2898 section 6.2 specifies:____
=C2=A0=C2=A0=C2=A0 The padding string PS shall consist of 8 - (||M|| mod 8)= octets all having value 8 - (||M|| mod 8).____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 PKCS #7 =E2=80=93 RFC2315 section 10.3 note 2 specifies:= ____

=C2=A0=C2=A0=C2=A0 For such algorithms, the method shall be to pad the inpu= t at the trailing end with k - (l mod k) octets all having value k - (l mod= k), where l is the length of the input.____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 PKCS #7 allows for padding in block sizes of 2-255 bytes= , whereas PKCS #5 is intended for block sizes of 8.=C2=A0 This means that P= KCS #7 is a superset of #5, and given that AES is a block size of 16, it se= ems the spec should require PKCS #7.____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 Thoughts?____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 *Shaun Cooley*
=C2=A0=C2=A0=C2=A0 DISTINGUISHED ENGINEER.ENGINEERING
=C2=A0=C2=A0=C2=A0 Collaboration Technology Group
=C2=A0=C2=A0=C2=A0 = shcooley@cisco.com <mailto:shcooley@cisco.com>
=C2=A0=C2=A0=C2=A0 Phone: *+1 408 902 3344 <tel:%2B1%20408%20902%203344>= *
=C2=A0=C2=A0=C2=A0 Mobile: *+1 310 293 2087 <tel:%2B1%20310%20293%202087&= gt;*____

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 http://www.cisco.com/web/europe/ima= ges/email/signature/logo05.jpg
=C2=A0=C2=A0=C2=A0 Cisco.com <http://www.cisco.com/>____

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 This email may contain confidential and privileged mater= ial for the sole use of the intended recipient. Any review, use, distributi= on or disclosure by others is strictly prohibited. If you are not the inten= ded recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies= of this message.____

=C2=A0=C2=A0=C2=A0 For corporate legal information go to:
=C2=A0=C2=A0=C2=A0 http://www.cisco.com/web/about/doing_business/legal/cri/index.html____ =

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 __ __

=C2=A0=C2=A0=C2=A0 _______________________________________________
=C2=A0=C2=A0=C2=A0 jose mailing list
=C2=A0=C2=A0=C2=A0 jose@= ietf.org <mailto:jose@ietf.org>
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/jose

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

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--047d7bdc9f505dbbdb05124848a0-- From nobody Fri Mar 27 10:19:19 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B551B2A75 for ; Fri, 27 Mar 2015 10:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOd07P7Ny8YZ for ; Fri, 27 Mar 2015 10:19:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9687C1A87A6 for ; Fri, 27 Mar 2015 10:19:13 -0700 (PDT) Received: from BLUPR03MB437.namprd03.prod.outlook.com (10.141.78.147) by BLUPR03MB439.namprd03.prod.outlook.com (10.141.78.151) with Microsoft SMTP Server (TLS) id 15.1.125.14; Fri, 27 Mar 2015 17:19:12 +0000 Received: from BLUPR03MB437.namprd03.prod.outlook.com ([10.141.78.147]) by BLUPR03MB437.namprd03.prod.outlook.com ([10.141.78.147]) with mapi id 15.01.0125.002; Fri, 27 Mar 2015 17:19:12 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) Thread-Index: AQHQaB5bkfOhNCQj00mWiSuBrydmnp0vep8AgABheACAAIp+gIAAAWcAgAAq9ACAAACAcA== Date: Fri, 27 Mar 2015 17:19:12 +0000 Message-ID: References: <187A7B1DA239514F9146FC78B19AADE322D48DD4@xmb-aln-x10.cisco.com> <4E1F6AAD24975D4BA5B16804296739439AD6D7DD@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD86E7C@TK5EX14MBXC294.redmond.corp.microsoft.com>

<5514F6C0.7090905@gmail.com> <55156AED.3060402@connect2id.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.52.104] authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB439; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(36304003)(51914003)(24454002)(377454003)(377424004)(2950100001)(2900100001)(19609705001)(87936001)(76576001)(92566002)(102836002)(15975445007)(74316001)(77096005)(93886004)(19625215002)(33656002)(62966003)(77156002)(86362001)(230783001)(86612001)(19300405004)(110136001)(54356999)(76176999)(66066001)(46102003)(19617315012)(40100003)(16236675004)(19580405001)(19580395003)(106116001)(2656002)(122556002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB439; H:BLUPR03MB437.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR03MB439; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB439; x-forefront-prvs: 0528942FD8 Content-Type: multipart/alternative; boundary="_000_BLUPR03MB437DD348A3D595DE05D7E14F5090BLUPR03MB437namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 17:19:12.2047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB439 Archived-At: Cc: "jose@ietf.org" , Vladimir Dzhuvinov Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:19:17 -0000 --_000_BLUPR03MB437DD348A3D595DE05D7E14F5090BLUPR03MB437namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgYW4gaW1wbGVtZW50ZXIgdHJpZXMgQUVTL0NCQy9QS0NTN1BhZGRpbmcgYW5kIGl0IGZhaWxz LCB0aGUgc2l0dWF0aW9uIGlzIHNlbGYtY29ycmVjdGluZy4gIFRoZXnigJlsbCBjaGFuZ2UgdG8g dXNpbmcgd2hhdOKAmXMgaW4gdGhlIHRhYmxlLCBldmVuIHRob3VnaCBpdCBtYXkgc2VlbSBvZGQu ICBHaXZlbiB0aGUgUkZDIEVkaXRvciBoYXMgYWxyZWFkeSBkb25lIHRoZSBlZGl0aW5nIGFuZCB0 aGUgZG9jIGlzIGluIGZpbmFsIGludGVybmFsIHJldmlldyBzdGF0ZSwgSeKAmWQgc2F5IHRoYXQg bGVzcyBpcyBtb3JlIGF0IHRoaXMgcG9pbnQuDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDI3LCAy MDE1IDEyOjE1IFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IFZsYWRpbWlyIER6aHV2aW5vdjsgam9z ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt YWxnb3JpdGhtcy0yNzogc2VjdGlvbi01LjIgKFBLQ1MgIzUpDQoNCkl0IG1heSBvciBtYXkgbm90 IHdhcnJhbnQgYSBub3RlIG9mIHNvbWUgc29ydCB0byBleHBsYWluIHRoZSBkaXNjcmVwYW5jeSAo bm90IHN1cmUgaWYgdGhhdCdzIHJlYWxseSBpbiBzY29wZSkuIEl0IGxvb2tzIGFzIHRob3VnaCBz b21lIHByb3ZpZGVycyBsaWtlIEJvdW5jeSBDYXN0bGUgYW5kIHRoZSBvbmUgb24gQW5kcm9pZCB3 aWxsIHdvcmsgd2l0aCAiQUVTL0NCQy9QS0NTN1BhZGRpbmciLiBCdXQgIkFFUy9DQkMvUEtDUzVQ YWRkaW5nIiBpcyB3aGF0IGlzIG5lZWRlZCBmb3IgdGhlIFN1bi9PcmFjbGUgSkNBIHByb3ZpZGVy IChJIHZlcmlmaWVkIHRoaXMgYWdhaW4gYWdhaW5zdCBKYXZhIDcgJiA4KSBhbmQgaXMgd2hhdCBp cyByZXF1aXJlZCBieSAiRXZlcnkgaW1wbGVtZW50YXRpb24gb2YgdGhlIEphdmEgcGxhdGZvcm0i IHBlciBodHRwOi8vZG9jcy5vcmFjbGUuY29tL2phdmFzZS83L2RvY3MvYXBpL2phdmF4L2NyeXB0 by9DaXBoZXIuaHRtbCBhbmQgaXQgYWN0dWFsbHkgZ2l2ZSB5b3UgUEtDUzdQYWRkaW5nIGV2ZW4g dGhvdWdoIGl0IHNheXMgNS4NCg0KT24gRnJpLCBNYXIgMjcsIDIwMTUgYXQgOTo0MiBBTSwgTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoYW5rcyBhIGJ1bmNoLCBWbGFkaW1pci4gIFRoYXQg ZGVmaW5pdGl2ZWx5IGFuc3dlcnMgdGhlIHF1ZXN0aW9uLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IGpvc2UgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBWbGFkaW1pciBEemh1dmlub3YNClNlbnQ6IEZyaWRheSwg TWFyY2ggMjcsIDIwMTUgOTozNiBBTQ0KVG86IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2pvc2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdv cml0aG1zLTI3OiBzZWN0aW9uLTUuMiAoUEtDUyAjNSkNCg0KVGhpcyBpcyBpbmRlZWQgYSBKQ0Eg b2RkaXR5LCB3aGVuICJQS0NTNVBhZGRpbmciIGlzIHNwZWNpZmllZCBKYXZhIGFjdHVhbGx5IGRv ZXMgIlBLQ1M3UGFkZGluZyIuDQoNCklmIHlvdSBzdGljayAiUEtDUzdQYWRkaW5nIiB5b3UnbGwg Z2V0IGFuDQoNCk5vU3VjaEFsZ29yaXRobUV4Y2VwdGlvbjogQ2Fubm90IGZpbmQgYW55IHByb3Zp ZGVyIHN1cHBvcnRpbmcgQUVTL0NCQy9QS0NTN1BhZGRpbmcNCg0KDQoNCg0KVmxhZGltaXINCk9u IDI3LjAzLjIwMTUgMDg6MjAsIEFuZGVycyBSdW5kZ3JlbiB3cm90ZToNCk9uIDIwMTUtMDMtMjcg MDE6MzEsIEJyaWFuIENhbXBiZWxsIHdyb3RlOg0KSSBhbSBwcmV0dHkgc3VyZSB5b3Ugc2hvdWxk IG5vdCBtYWtlIHRoYXQgY2hhbmdlIHRvIHRoZSBKQ0EgYWxnb3JpdGhtIHN0cmluZy4NCj4gIEkn bGwgaGF2ZSB0byBzZWFyY2ggYXJvdW5kIHRvIHJlbWVtYmVyIHdoeSwgc29tZSBvZGRpdHkgb2Yg SmF2YSBJIHRoaW5rLA0KPiBidXQgSSdtIGF3YXkgZnJvbSBteSBsYXB0b3AgcmlnaHQgbm93IGFu ZCB0aGF0IG9uZSBpcyB0b28gbXVjaCB0byByZXNlYXJjaCBvbiBhIHBob25lLg0KDQpJbmRlZWQs IHRoaXMgaXMgYW4gb2xkIFNVTiBidWcgdGhhdCB3ZSBoYXZlIHRvIHB1dCB1cCB3aXRoOg0KaHR0 cDovL2RvY3Mub3JhY2xlLmNvbS9qYXZhc2UvNy9kb2NzL2FwaS9qYXZheC9jcnlwdG8vQ2lwaGVy Lmh0bWwNCg0KSXQgaXMgd29ydGggYSBub3RlIHRob3VnaC4NCg0KQW5kZXJzDQoNCg0KT24gTWFy IDI2LCAyMDE1IDY6NDEgUE0sICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IDxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQoNCiAgICBJIGFtIHdvcmtpbmcgb24gdGhlIGZvcm1hdHRpbmcgb2YgdGhlIGFsZ29y aXRobSBjcm9zcy1yZWZlcmVuY2UgdGFibGVzIGluIEpXQSBBcHBlbmRpeCBBIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTQwI2Fw cGVuZGl4LUEgd2l0aCB0aGUgUkZDIEVkaXRvciB0byBtYWtlIHRoZW0gbW9yZSByZWFkYWJsZS4g IFdoZW4gbG9va2luZyBhdCB0aGUgdGFibGUgY29udGVudCAoaW4gYSBtb3JlIHJlYWRhYmxlIHJl bmRpdGlvbiBJ4oCZbGwgc2hhcmUgd2l0aCB5b3Ugc29vbiksIEkgbm90aWNlZCB0aGF0IHRoaXMg c3RyaW5nIGFwcGVhcnMgZm9yIHRoZSBKQ0EgdmFsdWUgb2YgdGhyZWUgYWxnb3JpdGhtczpfX19f DQoNCiAgICAgICAgICAgICAgICAgICAgQUVTL0NCQy9QS0NTNVBhZGRpbmdfX19fDQoNCiAgICB3 aGljaCBJIGJlbGlldmUgc2hvdWxkIGJlX19fXw0KDQogICAgICAgICAgICAgICAgICAgIEFFUy9D QkMvUEtDUzdQYWRkaW5nX19fXw0KDQogICAgX18gX18NCg0KICAgIFRoaXMgd291bGQgYmUgY29u c2lzdGVudCB3aXRoIHRoZSBjaGFuZ2VzIG1hZGUgaW4gLTI4IGZvciB0aGUgcmVhc29ucyBkZXNj cmliZWQgaW4gdGhpcyB0aHJlYWQuIEpBVkEgSU1QTEVNRU5URVJT4oCTIElmIHlvdSBhcmUgY3Vy cmVudGx5IHVzaW5nIEFFUy9DQkMvUEtDUzVQYWRkaW5nIGNhbiB5b3UgcGxlYXNlIHZlcmlmeSB0 aGF0IHlvdXIgaW1wbGVtZW50YXRpb24gc3RpbGwgd29ya3MgYWZ0ZXIgY2hhbmdpbmcgdGhpcyBz dHJpbmcgdG8gQUVTL0NCQy9QS0NTN1BhZGRpbmcgYW5kIHRoYXQgdGhlIHJlc3VsdHMgYXJlIHN0 aWxsIGNvcnJlY3QgYW5kIHJlcGx5IHRvIHVzIGxldHRpbmcgdXMga25vdyB3aGF0IGhhcHBlbmVk PyBNYXR0LCBpZiB5b3VyIGNvZGUgZm9yIHRoZSBjb29rYm9vayBpcyBpbiBKYXZhLCBpdCB3b3Vs ZCBiZSBlc3BlY2lhbGx5IGdvb2QgaWYgeW91IG1hZGUgdGhpcyBjb2RlIGNoYW5nZSBhbmQgdmVy aWZpZWQgdGhhdCBub3RoaW5nIGNoYW5nZXMgaW4gdGhlIG91dHB1dC5fX19fDQoNCiAgICBfXyBf Xw0KDQogICAgQWxzbywgdGhpcyBjbGVhcmx5IGluY29uc2lzdGVudCBzZW50ZW5jZSBjdXJyZW50 bHkgb2NjdXJzIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1hbGdvcml0aG1zLTQwI3NlY3Rpb24tNS4yLjE6X19fXw0KDQogICAgICAgICAgIENC Qy1QS0NTNS1FTkMoWCwgUCkgZGVub3RlcyB0aGUgQUVTIENCQyBlbmNyeXB0aW9uIG9mIFAgdXNp bmcgUEtDU19fX18NCg0KICAgICAgICAgICAjNyBwYWRkaW5nIHVzaW5nIHRoZSBjaXBoZXIgd2l0 aCB0aGUga2V5IFguX19fXw0KDQogICAgX18gX18NCg0KICAgIEkgYmVsaWV2ZSB0aGF0IHRoZSBp ZGVudGlmaWVyIENCQy1QS0NTNS1FTkNzaG91bGQgYmUgY2hhbmdlZCB0byBDQkMtUEtDUzctRU5D Ll9fX18NCg0KICAgIF9fIF9fDQoNCiAgICBVbmxlc3MgcGVvcGxlIGRpc2FncmVlLCBJIHdpbGwg cGxhbiB0byBhcHBseSB0aGVzZSBjb3JyZWN0aW9ucyBkdXJpbmcgQVVUSDQ4Ll9fX18NCg0KICAg IF9fIF9fDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGhhbmtzIGFsbCxfX19fDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZV9fX18N Cg0KICAgIF9fIF9fDQoNCiAgICAqRnJvbToqam9zZSBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRm Lm9yZyA8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZz5dICpPbiBCZWhhbGYgT2YgKk1pa2UgSm9uZXMNCiAgICAqU2VudDoqIEZyaWRheSwg SnVuZSAyMCwgMjAxNCA3OjAzIFBNDQogICAgKlRvOiogU2hhdW4gQ29vbGV5IChzaGNvb2xleSkN CiAgICAqQ2M6KiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPiA8bWFpbHRvOmpv c2VAaWV0Zi5vcmc+PG1haWx0bzpqb3NlQGlldGYub3JnPjsgTWF0dCBNaWxsZXIgKG1hbWlsbGUy KQ0KICAgICpTdWJqZWN0OiogUmU6IFtqb3NlXSBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxn b3JpdGhtcy0yNzogc2VjdGlvbi01LjIgKFBLQ1MgIzUpX19fXw0KDQogICAgX18gX18NCg0KICAg IFRoaXMgY2hhbmdlIGhhcyBiZWVuIGluY29ycG9yYXRlZCBpbiB0aGUgLTI4IGRyYWZ0cy5fX19f DQoNCiAgICBfXyBfXw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwgU2hhdW4sX19fXw0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2VfX19fDQoNCiAgICBfXyBfXw0KDQogICAgKkZyb206Kmpvc2UgW21haWx0bzpq b3NlLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKk1pa2UgSm9uZXMNCiAgICAqU2Vu dDoqIEZyaWRheSwgSnVuZSAxMywgMjAxNCAyOjI3IFBNDQogICAgKlRvOiogU2hhdW4gQ29vbGV5 IChzaGNvb2xleSkNCiAgICAqQ2M6KiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3Jn PiA8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+PG1haWx0bzpqb3NlQGlldGYub3JnPjsgTWF0dCBNaWxs ZXIgKG1hbWlsbGUyKQ0KICAgICpTdWJqZWN0OiogUmU6IFtqb3NlXSBkcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItYWxnb3JpdGhtcy0yNzogc2VjdGlvbi01LjIgKFBLQ1MgIzUpX19fXw0KDQogICAg X18gX18NCg0KICAgIChBZGRpbmcgdGhlIEpPU0Ugd29ya2luZyBncm91cClfX19fDQoNCiAgICBf XyBfXw0KDQogICAgSSBiZWxpZXZlIHlvdeKAmXJlIHJpZ2h0LiAgSeKAmWxsIHBsYW4gdG8gbWFr ZSB0aGlzIGNoYW5nZSBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBzcGVjLl9fX18NCg0KICAg IF9fIF9fDQoNCiAgICBUaGFua3MgZm9yIHRoZSBjYXJlZnVsIHJlYWQhX19fXw0KDQogICAgX18g X18NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlX19fXw0KDQogICAgX18gX18NCg0KICAgICpGcm9tOipTaGF1 biBDb29sZXkgKHNoY29vbGV5KSBbbWFpbHRvOnNoY29vbGV5QGNpc2NvLmNvbV0NCiAgICAqU2Vu dDoqIEZyaWRheSwgSnVuZSAxMywgMjAxNCAxMDozNCBBTQ0KICAgICpUbzoqIE1pa2UgSm9uZXMN CiAgICAqQ2M6KiBNYXR0IE1pbGxlciAobWFtaWxsZTIpDQogICAgKlN1YmplY3Q6KiBkcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0yNzogc2VjdGlvbi01LjIgKFBLQ1MgIzUpX19f Xw0KDQogICAgX18gX18NCg0KICAgIE1pY2hhZWwg4oCTX19fXw0KDQogICAgICBJIGFtIHdvcmtp bmcgb24gaW1wbGVtZW50aW5nIGEgYnJvd3NlciBjb21wYXRpYmxlIEpTIGltcGxlbWVudGF0aW9u IG9mIEpPU0UsIGJhc2VkIG9uIHRoZSB3b3JrIE1hdHQgTWlsbGVyIGRpZCBmb3IgTm9kZS5KUy4g IFdoaWxlIGdvaW5nIHRocm91Z2ggdGhlIHNwZWMsIEkgbm90aWNlZCB0aGF0IFBLQ1MgIzUgaXMg Y2FsbGVkIG91dCBmb3IgdGhlIEFFUy1DQkMgY2lwaGVycy4gIFNob3VsZG7igJl0IHRoaXMgYmUg UEtDUyAjNz9fX19fDQoNCiAgICBfXyBfXw0KDQogICAgUEtDUyAjNSDigJMgUkZDMjg5OCBzZWN0 aW9uIDYuMiBzcGVjaWZpZXM6X19fXw0KDQogICAgVGhlIHBhZGRpbmcgc3RyaW5nIFBTIHNoYWxs IGNvbnNpc3Qgb2YgOCAtICh8fE18fCBtb2QgOCkgb2N0ZXRzIGFsbCBoYXZpbmcgdmFsdWUgOCAt ICh8fE18fCBtb2QgOCkuX19fXw0KDQogICAgX18gX18NCg0KICAgIFBLQ1MgIzcg4oCTIFJGQzIz MTUgc2VjdGlvbiAxMC4zIG5vdGUgMiBzcGVjaWZpZXM6X19fXw0KDQogICAgRm9yIHN1Y2ggYWxn b3JpdGhtcywgdGhlIG1ldGhvZCBzaGFsbCBiZSB0byBwYWQgdGhlIGlucHV0IGF0IHRoZSB0cmFp bGluZyBlbmQgd2l0aCBrIC0gKGwgbW9kIGspIG9jdGV0cyBhbGwgaGF2aW5nIHZhbHVlIGsgLSAo bCBtb2QgayksIHdoZXJlIGwgaXMgdGhlIGxlbmd0aCBvZiB0aGUgaW5wdXQuX19fXw0KDQogICAg X18gX18NCg0KICAgIFBLQ1MgIzcgYWxsb3dzIGZvciBwYWRkaW5nIGluIGJsb2NrIHNpemVzIG9m IDItMjU1IGJ5dGVzLCB3aGVyZWFzIFBLQ1MgIzUgaXMgaW50ZW5kZWQgZm9yIGJsb2NrIHNpemVz IG9mIDguICBUaGlzIG1lYW5zIHRoYXQgUEtDUyAjNyBpcyBhIHN1cGVyc2V0IG9mICM1LCBhbmQg Z2l2ZW4gdGhhdCBBRVMgaXMgYSBibG9jayBzaXplIG9mIDE2LCBpdCBzZWVtcyB0aGUgc3BlYyBz aG91bGQgcmVxdWlyZSBQS0NTICM3Ll9fX18NCg0KICAgIF9fIF9fDQoNCiAgICBUaG91Z2h0cz9f X19fDQoNCiAgICBfXyBfXw0KDQogICAgKlNoYXVuIENvb2xleSoNCiAgICBESVNUSU5HVUlTSEVE IEVOR0lORUVSLkVOR0lORUVSSU5HDQogICAgQ29sbGFib3JhdGlvbiBUZWNobm9sb2d5IEdyb3Vw DQogICAgc2hjb29sZXlAY2lzY28uY29tPG1haWx0bzpzaGNvb2xleUBjaXNjby5jb20+IDxtYWls dG86c2hjb29sZXlAY2lzY28uY29tPjxtYWlsdG86c2hjb29sZXlAY2lzY28uY29tPg0KICAgIFBo b25lOiAqKzEgNDA4IDkwMiAzMzQ0PHRlbDolMkIxJTIwNDA4JTIwOTAyJTIwMzM0ND4gPHRlbDol MkIxJTIwNDA4JTIwOTAyJTIwMzM0ND4qDQogICAgTW9iaWxlOiAqKzEgMzEwIDI5MyAyMDg3PHRl bDolMkIxJTIwMzEwJTIwMjkzJTIwMjA4Nz4gPHRlbDolMkIxJTIwMzEwJTIwMjkzJTIwMjA4Nz4q X19fXw0KDQoNCg0KICAgIGh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9ldXJvcGUvaW1hZ2VzL2Vt YWlsL3NpZ25hdHVyZS9sb2dvMDUuanBnDQogICAgQ2lzY28uY29tIDxodHRwOi8vd3d3LmNpc2Nv LmNvbS8+PGh0dHA6Ly93d3cuY2lzY28uY29tLz5fX19fDQoNCiAgICBfXyBfXw0KDQogICAgVGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1 c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3Jp emVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2Uu X19fXw0KDQogICAgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCiAgICBo dHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2lu ZGV4Lmh0bWxfX19fDQoNCiAgICBfXyBfXw0KDQogICAgX18gX18NCg0KDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBqb3NlIG1haWxpbmcg bGlzdA0KICAgIGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+IDxtYWlsdG86am9z ZUBpZXRmLm9yZz48bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8 bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2pvc2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg0KLS0NCg0K VmxhZGltaXIgRHpodXZpbm92IDo6IHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFk aW1pckBjb25uZWN0MmlkLmNvbT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpq b3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3Nl DQoNCg== --_000_BLUPR03MB437DD348A3D595DE05D7E14F5090BLUPR03MB437namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J ZiBhbiBpbXBsZW1lbnRlciB0cmllcw0KPC9zcGFuPkFFUy9DQkMvUEtDUzdQYWRkaW5nPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiBhbmQgaXQgZmFpbHMsIHRoZSBz aXR1YXRpb24gaXMgc2VsZi1jb3JyZWN0aW5nLiZuYnNwOyBUaGV54oCZbGwgY2hhbmdlIHRvIHVz aW5nIHdoYXTigJlzIGluIHRoZSB0YWJsZSwgZXZlbiB0aG91Z2ggaXQgbWF5IHNlZW0gb2RkLiZu YnNwOyBHaXZlbiB0aGUgUkZDIEVkaXRvciBoYXMNCiBhbHJlYWR5IGRvbmUgdGhlIGVkaXRpbmcg YW5kIHRoZSBkb2MgaXMgaW4gZmluYWwgaW50ZXJuYWwgcmV2aWV3IHN0YXRlLCBJ4oCZZCBzYXkg dGhhdCBsZXNzIGlzIG1vcmUgYXQgdGhpcyBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyNywgMjAxNSAx MjoxNSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gVmxhZGlt aXIgRHpodXZpbm92OyBqb3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbam9z ZV0gZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMjc6IHNlY3Rpb24tNS4yIChQ S0NTICM1KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IG1heSBvciBt YXkgbm90IHdhcnJhbnQgYSBub3RlIG9mIHNvbWUgc29ydCB0byBleHBsYWluIHRoZSBkaXNjcmVw YW5jeSAobm90IHN1cmUgaWYgdGhhdCdzIHJlYWxseSBpbiBzY29wZSkuIEl0IGxvb2tzIGFzIHRo b3VnaCBzb21lIHByb3ZpZGVycyBsaWtlIEJvdW5jeSBDYXN0bGUgYW5kIHRoZSBvbmUgb24gQW5k cm9pZCB3aWxsIHdvcmsgd2l0aCAmcXVvdDtBRVMvQ0JDL1BLQ1M3UGFkZGluZyZxdW90Oy4gQnV0 ICZxdW90O0FFUy9DQkMvUEtDUzVQYWRkaW5nJnF1b3Q7DQogaXMgd2hhdCBpcyBuZWVkZWQgZm9y IHRoZSBTdW4vT3JhY2xlIEpDQSBwcm92aWRlciAoSSB2ZXJpZmllZCB0aGlzIGFnYWluIGFnYWlu c3QgSmF2YSA3ICZhbXA7IDgpIGFuZCBpcyB3aGF0IGlzIHJlcXVpcmVkIGJ5ICZxdW90O0V2ZXJ5 IGltcGxlbWVudGF0aW9uIG9mIHRoZSBKYXZhIHBsYXRmb3JtJnF1b3Q7IHBlcg0KPGEgaHJlZj0i aHR0cDovL2RvY3Mub3JhY2xlLmNvbS9qYXZhc2UvNy9kb2NzL2FwaS9qYXZheC9jcnlwdG8vQ2lw aGVyLmh0bWwiPmh0dHA6Ly9kb2NzLm9yYWNsZS5jb20vamF2YXNlLzcvZG9jcy9hcGkvamF2YXgv Y3J5cHRvL0NpcGhlci5odG1sPC9hPiBhbmQgaXQgYWN0dWFsbHkgZ2l2ZSB5b3UgUEtDUzdQYWRk aW5nIGV2ZW4gdGhvdWdoIGl0IHNheXMgNS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXIgMjcsIDIwMTUgYXQgOTo0MiBBTSwgTWlrZSBK b25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgYSBidW5jaCwgVmxh ZGltaXIuJm5ic3A7IFRoYXQgZGVmaW5pdGl2ZWx5IGFuc3dlcnMgdGhlIHF1ZXN0aW9uLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGpv c2UgW21haWx0bzo8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ VmxhZGltaXIgRHpodXZpbm92PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMjcsIDIw MTUgOTozNiBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW2pvc2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTI3OiBzZWN0aW9u LTUuMiAoUEtDUyAjNSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij5UaGlzIGlzIGluZGVlZCBhIEpDQSBvZGRpdHksIHdoZW4gJnF1b3Q7 UEtDUzVQYWRkaW5nJnF1b3Q7IGlzIHNwZWNpZmllZCBKYXZhIGFjdHVhbGx5IGRvZXMgJnF1b3Q7 UEtDUzdQYWRkaW5nJnF1b3Q7Ljxicj4NCjxicj4NCklmIHlvdSBzdGljayAmcXVvdDtQS0NTN1Bh ZGRpbmcmcXVvdDsgeW91J2xsIGdldCBhbiA8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Tm9TdWNoQWxn b3JpdGhtRXhjZXB0aW9uOiBDYW5ub3QgZmluZCBhbnkgcHJvdmlkZXIgc3VwcG9ydGluZyBBRVMv Q0JDL1BLQ1M3UGFkZGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlZs YWRpbWlyPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAy Ny4wMy4yMDE1IDA4OjIwLCBBbmRlcnMgUnVuZGdyZW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAyMDE1LTAzLTI3IDAxOjMxLCBCcmlhbiBDYW1w YmVsbCB3cm90ZToNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFt IHByZXR0eSBzdXJlIHlvdSBzaG91bGQgbm90IG1ha2UgdGhhdCBjaGFuZ2UgdG8gdGhlIEpDQSBh bGdvcml0aG0gc3RyaW5nLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsm bmJzcDsgSSdsbCBoYXZlIHRvIHNlYXJjaCBhcm91bmQgdG8gcmVtZW1iZXIgd2h5LCBzb21lIG9k ZGl0eSBvZiBKYXZhIEkgdGhpbmssDQo8YnI+DQomZ3Q7IGJ1dCBJJ20gYXdheSBmcm9tIG15IGxh cHRvcCByaWdodCBub3cgYW5kIHRoYXQgb25lIGlzIHRvbyBtdWNoIHRvIHJlc2VhcmNoIG9uIGEg cGhvbmUuDQo8YnI+DQo8YnI+DQpJbmRlZWQsIHRoaXMgaXMgYW4gb2xkIFNVTiBidWcgdGhhdCB3 ZSBoYXZlIHRvIHB1dCB1cCB3aXRoOiA8YnI+DQo8YSBocmVmPSJodHRwOi8vZG9jcy5vcmFjbGUu Y29tL2phdmFzZS83L2RvY3MvYXBpL2phdmF4L2NyeXB0by9DaXBoZXIuaHRtbCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9kb2NzLm9yYWNsZS5jb20vamF2YXNlLzcvZG9jcy9hcGkvamF2YXgvY3J5 cHRvL0NpcGhlci5odG1sPC9hPg0KPGJyPg0KPGJyPg0KSXQgaXMgd29ydGggYSBub3RlIHRob3Vn aC4gPGJyPg0KPGJyPg0KQW5kZXJzIDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpPbiBNYXIgMjYsIDIwMTUgNjo0MSBQTSwgJnF1b3Q7TWlrZSBKb25l cyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4NCjxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+Jmd0OyB3cm90ZToNCjxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBJIGFtIHdvcmtpbmcgb24gdGhlIGZvcm1hdHRp bmcgb2YgdGhlIGFsZ29yaXRobSBjcm9zcy1yZWZlcmVuY2UgdGFibGVzIGluIEpXQSBBcHBlbmRp eCBBDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItYWxnb3JpdGhtcy00MCNhcHBlbmRpeC1BIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGht cy00MCNhcHBlbmRpeC1BPC9hPiB3aXRoIHRoZSBSRkMgRWRpdG9yIHRvIG1ha2UgdGhlbSBtb3Jl IHJlYWRhYmxlLiZuYnNwOyBXaGVuIGxvb2tpbmcgYXQgdGhlIHRhYmxlIGNvbnRlbnQgKGluIGEg bW9yZSByZWFkYWJsZSByZW5kaXRpb24gSeKAmWxsIHNoYXJlIHdpdGggeW91IHNvb24pLCBJIG5v dGljZWQgdGhhdCB0aGlzIHN0cmluZyBhcHBlYXJzIGZvcg0KIHRoZSBKQ0EgdmFsdWUgb2YgdGhy ZWUgYWxnb3JpdGhtczpfX19fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBRVMvQ0JDL1BLQ1M1UGFkZGluZ19fX18g PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIEkgYmVsaWV2ZSBzaG91bGQgYmVf X19fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBRVMvQ0JDL1BLQ1M3UGFkZGluZ19fX18gPGJyPg0KPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlz IHdvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgY2hhbmdlcyBtYWRlIGluIC0yOCBmb3IgdGhl IHJlYXNvbnMgZGVzY3JpYmVkIGluIHRoaXMgdGhyZWFkLiBKQVZBIElNUExFTUVOVEVSU+KAkyBJ ZiB5b3UgYXJlIGN1cnJlbnRseSB1c2luZyBBRVMvQ0JDL1BLQ1M1UGFkZGluZyBjYW4geW91IHBs ZWFzZSB2ZXJpZnkgdGhhdCB5b3VyIGltcGxlbWVudGF0aW9uIHN0aWxsIHdvcmtzIGFmdGVyIGNo YW5naW5nIHRoaXMgc3RyaW5nIHRvIEFFUy9DQkMvUEtDUzdQYWRkaW5nDQogYW5kIHRoYXQgdGhl IHJlc3VsdHMgYXJlIHN0aWxsIGNvcnJlY3QgYW5kIHJlcGx5IHRvIHVzIGxldHRpbmcgdXMga25v dyB3aGF0IGhhcHBlbmVkPyBNYXR0LCBpZiB5b3VyIGNvZGUgZm9yIHRoZSBjb29rYm9vayBpcyBp biBKYXZhLCBpdCB3b3VsZCBiZSBlc3BlY2lhbGx5IGdvb2QgaWYgeW91IG1hZGUgdGhpcyBjb2Rl IGNoYW5nZSBhbmQgdmVyaWZpZWQgdGhhdCBub3RoaW5nIGNoYW5nZXMgaW4gdGhlIG91dHB1dC5f X19fDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPg0KPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IEFsc28sIHRoaXMgY2xlYXJseSBpbmNvbnNpc3RlbnQgc2VudGVuY2Ug Y3VycmVudGx5IG9jY3VycyBpbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy00MCNzZWN0aW9uLTUuMi4xOl9fX18i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt am9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTQwI3NlY3Rpb24tNS4yLjE6X19fXzwvYT4NCjxicj4N Cjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBDQkMtUEtDUzUtRU5DKFgsIFApIGRlbm90ZXMgdGhlIEFFUyBDQkMgZW5jcnlw dGlvbiBvZiBQIHVzaW5nIFBLQ1NfX19fDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIzcgcGFkZGluZyB1c2lu ZyB0aGUgY2lwaGVyIHdpdGggdGhlIGtleSBYLl9fX18gPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7IF9fIF9fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBJIGJlbGlldmUgdGhh dCB0aGUgaWRlbnRpZmllciBDQkMtUEtDUzUtRU5Dc2hvdWxkIGJlIGNoYW5nZWQgdG8gQ0JDLVBL Q1M3LUVOQy5fX19fDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFVubGVzcyBwZW9wbGUgZGlzYWdyZWUsIEkgd2lsbCBw bGFuIHRvIGFwcGx5IHRoZXNlIGNvcnJlY3Rpb25zIGR1cmluZyBBVVRINDguX19fXw0KPGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWxsLF9fX18gPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2VfX19fIDxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+DQo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgKkZyb206Kmpvc2UgWzxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPg0KPGEg aHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtt YWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnJmd0OzwvYT5dICpPbiBCZWhhbGYgT2YgKk1pa2Ug Sm9uZXMNCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAqU2VudDoqIEZyaWRheSwgSnVuZSAyMCwg MjAxNCA3OjAzIFBNIDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAqVG86KiBTaGF1biBDb29sZXkg KHNoY29vbGV5KSA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgKkNjOiogPGEgaHJlZj0ibWFpbHRv Ompvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5qb3NlQGlldGYub3JnPC9hPiA8YSBocmVm PSJtYWlsdG86am9zZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KJmx0O21haWx0bzpqb3Nl QGlldGYub3JnJmd0OzwvYT47IE1hdHQgTWlsbGVyIChtYW1pbGxlMikgPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICpTdWJqZWN0OiogUmU6IFtqb3NlXSBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt YWxnb3JpdGhtcy0yNzogc2VjdGlvbi01LjIgKFBLQ1MgIzUpX19fXw0KPGJyPg0KPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlz IGNoYW5nZSBoYXMgYmVlbiBpbmNvcnBvcmF0ZWQgaW4gdGhlIC0yOCBkcmFmdHMuX19fXyA8YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhZ2FpbiwgU2hhdW4sX19fXw0K PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t IE1pa2VfX19fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgKkZyb206Kmpvc2UgWzxhIGhyZWY9Im1haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86am9zZS1ib3VuY2VzQGlldGYu b3JnPC9hPl0gKk9uIEJlaGFsZiBPZiAqTWlrZSBKb25lcw0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICpTZW50OiogRnJpZGF5LCBKdW5lIDEzLCAyMDE0IDI6MjcgUE0gPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICpUbzoqIFNoYXVuIENvb2xleSAoc2hjb29sZXkpIDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmpvc2VAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+DQombHQ7bWFpbHRvOmpvc2VAaWV0Zi5vcmcmZ3Q7PC9hPjsgTWF0dCBNaWxs ZXIgKG1hbWlsbGUyKSA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgKlN1YmplY3Q6KiBSZTogW2pv c2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTI3OiBzZWN0aW9uLTUuMiAo UEtDUyAjNSlfX19fDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IChBZGRpbmcgdGhlIEpPU0Ugd29ya2luZyBncm91cClf X19fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgSSBiZWxpZXZlIHlvdeKAmXJlIHJpZ2h0LiZuYnNwOyBJ4oCZbGwgcGxh biB0byBtYWtlIHRoaXMgY2hhbmdlIGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIHNwZWMuX19f Xw0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyBUaGFua3MgZm9yIHRoZSBjYXJlZnVsIHJlYWQhX19fXyA8YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2VfX19fIDxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyBfXyBfXyA8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgKkZyb206KlNo YXVuIENvb2xleSAoc2hjb29sZXkpIFs8YSBocmVmPSJtYWlsdG86c2hjb29sZXlAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNoY29vbGV5QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgKlNlbnQ6KiBGcmlkYXksIEp1bmUgMTMsIDIwMTQgMTA6MzQgQU0g PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICpUbzoqIE1pa2UgSm9uZXMgPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICpDYzoqIE1hdHQgTWlsbGVyIChtYW1pbGxlMikgPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7ICpTdWJqZWN0OiogZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMjc6 IHNlY3Rpb24tNS4yIChQS0NTICM1KV9fX18gPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 IF9fIF9fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBNaWNoYWVsIOKAk19fX18gPGJy Pg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYW0gd29ya2luZyBvbiBp bXBsZW1lbnRpbmcgYSBicm93c2VyIGNvbXBhdGlibGUgSlMgaW1wbGVtZW50YXRpb24gb2YgSk9T RSwgYmFzZWQgb24gdGhlIHdvcmsgTWF0dCBNaWxsZXIgZGlkIGZvciBOb2RlLkpTLiZuYnNwOyBX aGlsZSBnb2luZyB0aHJvdWdoIHRoZSBzcGVjLCBJIG5vdGljZWQgdGhhdCBQS0NTICM1IGlzIGNh bGxlZCBvdXQgZm9yIHRoZSBBRVMtQ0JDIGNpcGhlcnMuJm5ic3A7IFNob3VsZG7igJl0IHRoaXMg YmUgUEtDUyAjNz9fX19fDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJy Pg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFBLQ1MgIzUg4oCTIFJGQzI4OTggc2VjdGlvbiA2 LjIgc3BlY2lmaWVzOl9fX18gPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBwYWRk aW5nIHN0cmluZyBQUyBzaGFsbCBjb25zaXN0IG9mIDggLSAofHxNfHwgbW9kIDgpIG9jdGV0cyBh bGwgaGF2aW5nIHZhbHVlIDggLSAofHxNfHwgbW9kIDgpLl9fX18NCjxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgUEtDUyAj NyDigJMgUkZDMjMxNSBzZWN0aW9uIDEwLjMgbm90ZSAyIHNwZWNpZmllczpfX19fIDxicj4NCjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBGb3Igc3VjaCBhbGdvcml0aG1zLCB0aGUgbWV0aG9kIHNo YWxsIGJlIHRvIHBhZCB0aGUgaW5wdXQgYXQgdGhlIHRyYWlsaW5nIGVuZCB3aXRoIGsgLSAobCBt b2Qgaykgb2N0ZXRzIGFsbCBoYXZpbmcgdmFsdWUgayAtIChsIG1vZCBrKSwgd2hlcmUgbCBpcyB0 aGUgbGVuZ3RoIG9mIHRoZSBpbnB1dC5fX19fDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgX18gX18gPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFBLQ1MgIzcgYWxsb3dzIGZv ciBwYWRkaW5nIGluIGJsb2NrIHNpemVzIG9mIDItMjU1IGJ5dGVzLCB3aGVyZWFzIFBLQ1MgIzUg aXMgaW50ZW5kZWQgZm9yIGJsb2NrIHNpemVzIG9mIDguJm5ic3A7IFRoaXMgbWVhbnMgdGhhdCBQ S0NTICM3IGlzIGEgc3VwZXJzZXQgb2YgIzUsIGFuZCBnaXZlbiB0aGF0IEFFUyBpcyBhIGJsb2Nr IHNpemUgb2YgMTYsIGl0IHNlZW1zIHRoZSBzcGVjIHNob3VsZCByZXF1aXJlIFBLQ1MgIzcuX19f Xw0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyBUaG91Z2h0cz9fX19fIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyBfXyBfXyA8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgKlNoYXVuIENvb2xleSogPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IERJU1RJTkdVSVNIRUQgRU5HSU5FRVIuRU5HSU5FRVJJTkcg PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IENvbGxhYm9yYXRpb24gVGVjaG5vbG9neSBHcm91cCA8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnNoY29vbGV5QGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnNoY29vbGV5QGNpc2NvLmNvbTwvYT4gPGEgaHJlZj0ibWFpbHRv OnNoY29vbGV5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KJmx0O21haWx0bzpzaGNvb2xl eUBjaXNjby5jb20mZ3Q7PC9hPiA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgUGhvbmU6ICo8YSBo cmVmPSJ0ZWw6JTJCMSUyMDQwOCUyMDkwMiUyMDMzNDQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzEg NDA4IDkwMiAzMzQ0PC9hPiAmbHQ7PGEgaHJlZj0idGVsOiUyQjElMjA0MDglMjA5MDIlMjAzMzQ0 IiB0YXJnZXQ9Il9ibGFuayI+dGVsOiUyQjElMjA0MDglMjA5MDIlMjAzMzQ0PC9hPiZndDsqDQo8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgTW9iaWxlOiAqPGEgaHJlZj0idGVsOiUyQjElMjAzMTAl MjAyOTMlMjAyMDg3IiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxIDMxMCAyOTMgMjA4NzwvYT4gJmx0 OzxhIGhyZWY9InRlbDolMkIxJTIwMzEwJTIwMjkzJTIwMjA4NyIgdGFyZ2V0PSJfYmxhbmsiPnRl bDolMkIxJTIwMzEwJTIwMjkzJTIwMjA4NzwvYT4mZ3Q7Kl9fX18NCjxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQo8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2V1cm9wZS9pbWFn ZXMvZW1haWwvc2lnbmF0dXJlL2xvZ28wNS5qcGciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93 d3cuY2lzY28uY29tL3dlYi9ldXJvcGUvaW1hZ2VzL2VtYWlsL3NpZ25hdHVyZS9sb2dvMDUuanBn PC9hPiA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgQ2lzY28uY29tIDxhIGhyZWY9Imh0dHA6Ly93 d3cuY2lzY28uY29tLyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtodHRwOi8vd3d3LmNpc2NvLmNvbS8m Z3Q7PC9hPl9fX18NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+DQo8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZQ0KIHJlY2lw aWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0 ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS5fX19fDQo8YnI+DQo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzogPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9k b2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbF9fX18iIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkv aW5kZXguaHRtbF9fX188L2E+IDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8 YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPg0KPGJyPg0KPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBqb3NlIG1haWxpbmcgbGlzdCA8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5qb3NlQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPg0KJmx0O21haWx0bzpqb3NlQGlldGYub3JnJmd0OzwvYT4gPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vam9zZTwvYT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIDxicj4NCmpvc2UgbWFpbGluZyBs aXN0IDxicj4NCjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ am9zZUBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIDxicj4NCmpvc2UgbWFpbGluZyBsaXN0IDxicj4NCjxhIGhyZWY9Im1haWx0bzpqb3Nl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPg0KPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5WbGFkaW1pciBEemh1 dmlub3YgOjogPGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208L2E+PG86cD48L286cD48L3ByZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB437DD348A3D595DE05D7E14F5090BLUPR03MB437namprd_-- From nobody Fri Mar 27 11:16:46 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EF71A89AC for ; Fri, 27 Mar 2015 11:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKOV5n56umEK for ; Fri, 27 Mar 2015 11:16:37 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980A11A8730 for ; Fri, 27 Mar 2015 11:16:36 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-cf-55159e82abe8 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 83.0C.03488.28E95155; Fri, 27 Mar 2015 14:16:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t2RIGXpp004933; Fri, 27 Mar 2015 14:16:34 -0400 Received: from [IPv6:2607:fb90:92f:5ba4:0:44:fbb1:df01] (md64636d0.tmodns.net [208.54.70.214]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2RIGU3d027836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Mar 2015 14:16:32 -0400 Date: Fri, 27 Mar 2015 13:07:09 -0500 Message-ID: Importance: normal From: Justin Richer To: Brian Campbell , Mike Jones MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_4304169759815660" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixG6nrts0TzTU4GabscXq/zcZLdas6Way 2DvtE4vFu3cfGB1YPOZ/bmH1WLLkJ5NH646/7B53j15kCWCJ4rJJSc3JLEst0rdL4MrYeusF Y8GLmUwVE6bsZm5g3DKJqYuRk0NCwETi3be/zBC2mMSFe+vZuhi5OIQEFjNJ/H0ziRHC2cgo cf9lExOEc5tJ4t75PnaQFhYBVYn+nRfARgkLBEucXbyYBcTmFXCTaJ+1C8jm4OAUEJLo2iUB EmYDKp++pgWsXEQgRWLryxdg5cwCMRJXvpxlg2gVlDg58wlYK7NAqMThtvAJjHyzkGRmIWRm gTWrS/yZd4kZwlaUmNL9kB2iRE1iWasSsvACRrZVjLIpuVW6uYmZOcWpybrFyYl5ealFukZ6 uZkleqkppZsYQWHOKcm7g/HdQaVDjAIcjEo8vD92i4QKsSaWFVfmHmKU5GBSEuU1nyEaKsSX lJ9SmZFYnBFfVJqTWnyIUYKDWUmEd8NUoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU 1ILUIpisDAeHkgTvhblAjYJFqempFWmZOSUIaSYOTpDhPEDD94PU8BYXJOYWZ6ZD5E8x6nLM ufl7EZMQS15+XqqUOG8rSJEASFFGaR7cHFh6esUoDvSWMO9akCoeYGqDm/QKaAkT0BLDDhGQ JSWJCCmpBsYLDP9ysyVXl8mcmXBUYZZCPLc6c+RqvwczRFazi2XcdY2cpb1Kx7x1XY3uM8VO 6dVRBmYFCxZcmBxS4vQ999lHOa382ntffd7+NJk2s15JWPrPNSE5djOtymiWbUVnP+7l3d0U tECpVXbayljnW+d8blpMkyiSPeyX+eOfRWfM9ct1aqdajyqxFGckGmoxFxUnAgDvb5GoKgMA AA== Archived-At: Cc: "jose@ietf.org" , Vladimir Dzhuvinov Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 18:16:45 -0000 ----_com.android.email_4304169759815660 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKSSBiZWxpZXZlIGFuIGltcGxlbWVudGVycyBub3RlIGlzIGFwcHJvcHJpYXRlIGhlcmUu CgoKLS0gSnVzdGluCi8gU2VudCBmcm9tIG15IHBob25lIC8KCi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPiAKRGF0ZTogMDMvMjcvMjAxNSAgMTI6MTUgUE0gIChHTVQtMDY6MDApIApUbzogTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiAKQ2M6IGpvc2VAaWV0Zi5vcmcs IFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+IApTdWJqZWN0OiBS ZTogW2pvc2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTI3OiBzZWN0aW9u LTUuMiAoUEtDUyAjNSkgCgpJdCBtYXkgb3IgbWF5IG5vdCB3YXJyYW50IGEgbm90ZSBvZiBzb21l IHNvcnQgdG8gZXhwbGFpbiB0aGUgZGlzY3JlcGFuY3kgKG5vdCBzdXJlIGlmIHRoYXQncyByZWFs bHkgaW4gc2NvcGUpLiBJdCBsb29rcyBhcyB0aG91Z2ggc29tZSBwcm92aWRlcnMgbGlrZSBCb3Vu Y3kgQ2FzdGxlIGFuZCB0aGUgb25lIG9uIEFuZHJvaWQgd2lsbCB3b3JrIHdpdGggIkFFUy9DQkMv UEtDUzdQYWRkaW5nIi4gQnV0ICJBRVMvQ0JDL1BLQ1M1UGFkZGluZyIgaXMgd2hhdCBpcyBuZWVk ZWQgZm9yIHRoZSBTdW4vT3JhY2xlIEpDQSBwcm92aWRlciAoSSB2ZXJpZmllZCB0aGlzIGFnYWlu IGFnYWluc3QgSmF2YSA3ICYgOCkgYW5kIGlzIHdoYXQgaXMgcmVxdWlyZWQgYnkgIkV2ZXJ5IGlt cGxlbWVudGF0aW9uIG9mIHRoZSBKYXZhIHBsYXRmb3JtIiBwZXIgaHR0cDovL2RvY3Mub3JhY2xl LmNvbS9qYXZhc2UvNy9kb2NzL2FwaS9qYXZheC9jcnlwdG8vQ2lwaGVyLmh0bWwgYW5kIGl0IGFj dHVhbGx5IGdpdmUgeW91IFBLQ1M3UGFkZGluZyBldmVuIHRob3VnaCBpdCBzYXlzIDUuIAoKT24g RnJpLCBNYXIgMjcsIDIwMTUgYXQgOTo0MiBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPiB3cm90ZToKCgoKCgoKCgpUaGFua3MgYSBidW5jaCwgVmxhZGltaXIuwqAg VGhhdCBkZWZpbml0aXZlbHkgYW5zd2VycyB0aGUgcXVlc3Rpb24uCsKgCsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLS0gTWlrZQrC oAoKCkZyb206IGpvc2UgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddCk9uIEJlaGFsZiBP ZiBWbGFkaW1pciBEemh1dmlub3YKClNlbnQ6IEZyaWRheSwgTWFyY2ggMjcsIDIwMTUgOTozNiBB TQoKVG86IGpvc2VAaWV0Zi5vcmcKClN1YmplY3Q6IFJlOiBbam9zZV0gZHJhZnQtaWV0Zi1qb3Nl LWpzb24td2ViLWFsZ29yaXRobXMtMjc6IHNlY3Rpb24tNS4yIChQS0NTICM1KQoKCsKgClRoaXMg aXMgaW5kZWVkIGEgSkNBIG9kZGl0eSwgd2hlbiAiUEtDUzVQYWRkaW5nIiBpcyBzcGVjaWZpZWQg SmF2YSBhY3R1YWxseSBkb2VzICJQS0NTN1BhZGRpbmciLgoKCgpJZiB5b3Ugc3RpY2sgIlBLQ1M3 UGFkZGluZyIgeW91J2xsIGdldCBhbiAKTm9TdWNoQWxnb3JpdGhtRXhjZXB0aW9uOiBDYW5ub3Qg ZmluZCBhbnkgcHJvdmlkZXIgc3VwcG9ydGluZyBBRVMvQ0JDL1BLQ1M3UGFkZGluZwrCoArCoApW bGFkaW1pcgoKT24gMjcuMDMuMjAxNSAwODoyMCwgQW5kZXJzIFJ1bmRncmVuIHdyb3RlOgoKCk9u IDIwMTUtMDMtMjcgMDE6MzEsIEJyaWFuIENhbXBiZWxsIHdyb3RlOiAKCgoKCkkgYW0gcHJldHR5 IHN1cmUgeW91IHNob3VsZCBub3QgbWFrZSB0aGF0IGNoYW5nZSB0byB0aGUgSkNBIGFsZ29yaXRo bSBzdHJpbmcuCgo+wqAgSSdsbCBoYXZlIHRvIHNlYXJjaCBhcm91bmQgdG8gcmVtZW1iZXIgd2h5 LCBzb21lIG9kZGl0eSBvZiBKYXZhIEkgdGhpbmssCgoKPiBidXQgSSdtIGF3YXkgZnJvbSBteSBs YXB0b3AgcmlnaHQgbm93IGFuZCB0aGF0IG9uZSBpcyB0b28gbXVjaCB0byByZXNlYXJjaCBvbiBh IHBob25lLgoKCgoKSW5kZWVkLCB0aGlzIGlzIGFuIG9sZCBTVU4gYnVnIHRoYXQgd2UgaGF2ZSB0 byBwdXQgdXAgd2l0aDogCgpodHRwOi8vZG9jcy5vcmFjbGUuY29tL2phdmFzZS83L2RvY3MvYXBp L2phdmF4L2NyeXB0by9DaXBoZXIuaHRtbAoKCgoKSXQgaXMgd29ydGggYSBub3RlIHRob3VnaC4g CgoKCkFuZGVycyAKCgoKCgoKCgpPbiBNYXIgMjYsIDIwMTUgNjo0MSBQTSwgIk1pa2UgSm9uZXMi IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20KPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+PiB3cm90ZToKCgoKCsKgwqDCoCBJIGFtIHdvcmtpbmcgb24gdGhlIGZvcm1hdHRp bmcgb2YgdGhlIGFsZ29yaXRobSBjcm9zcy1yZWZlcmVuY2UgdGFibGVzIGluIEpXQSBBcHBlbmRp eCBBCgpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt YWxnb3JpdGhtcy00MCNhcHBlbmRpeC1BIHdpdGggdGhlIFJGQyBFZGl0b3IgdG8gbWFrZSB0aGVt IG1vcmUgcmVhZGFibGUuwqAgV2hlbiBsb29raW5nIGF0IHRoZSB0YWJsZSBjb250ZW50IChpbiBh IG1vcmUgcmVhZGFibGUgcmVuZGl0aW9uIEnigJlsbCBzaGFyZSB3aXRoIHlvdSBzb29uKSwgSSBu b3RpY2VkIHRoYXQgdGhpcyBzdHJpbmcgYXBwZWFycyBmb3IKIHRoZSBKQ0EgdmFsdWUgb2YgdGhy ZWUgYWxnb3JpdGhtczpfX19fIAoKCgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBBRVMvQ0JDL1BLQ1M1UGFkZGluZ19fX18gCgoKCsKgwqDCoCB3aGljaCBJIGJlbGlldmUg c2hvdWxkIGJlX19fXyAKCgoKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg QUVTL0NCQy9QS0NTN1BhZGRpbmdfX19fIAoKCgrCoMKgwqAgX18gX18gCgoKCsKgwqDCoCBUaGlz IHdvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgY2hhbmdlcyBtYWRlIGluIC0yOCBmb3IgdGhl IHJlYXNvbnMgZGVzY3JpYmVkIGluIHRoaXMgdGhyZWFkLiBKQVZBIElNUExFTUVOVEVSU+KAkyBJ ZiB5b3UgYXJlIGN1cnJlbnRseSB1c2luZyBBRVMvQ0JDL1BLQ1M1UGFkZGluZyBjYW4geW91IHBs ZWFzZSB2ZXJpZnkgdGhhdCB5b3VyIGltcGxlbWVudGF0aW9uIHN0aWxsIHdvcmtzIGFmdGVyIGNo YW5naW5nIHRoaXMgc3RyaW5nIHRvIEFFUy9DQkMvUEtDUzdQYWRkaW5nCiBhbmQgdGhhdCB0aGUg cmVzdWx0cyBhcmUgc3RpbGwgY29ycmVjdCBhbmQgcmVwbHkgdG8gdXMgbGV0dGluZyB1cyBrbm93 IHdoYXQgaGFwcGVuZWQ/IE1hdHQsIGlmIHlvdXIgY29kZSBmb3IgdGhlIGNvb2tib29rIGlzIGlu IEphdmEsIGl0IHdvdWxkIGJlIGVzcGVjaWFsbHkgZ29vZCBpZiB5b3UgbWFkZSB0aGlzIGNvZGUg Y2hhbmdlIGFuZCB2ZXJpZmllZCB0aGF0IG5vdGhpbmcgY2hhbmdlcyBpbiB0aGUgb3V0cHV0Ll9f X18KCgoKCsKgwqDCoCBfXyBfXyAKCgoKwqDCoMKgIEFsc28sIHRoaXMgY2xlYXJseSBpbmNvbnNp c3RlbnQgc2VudGVuY2UgY3VycmVudGx5IG9jY3VycyBpbiAKaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtNDAjc2VjdGlvbi01LjIu MTpfX19fCgoKCgrCoMKgwqDCoMKgwqDCoMKgwqDCoCBDQkMtUEtDUzUtRU5DKFgsIFApIGRlbm90 ZXMgdGhlIEFFUyBDQkMgZW5jcnlwdGlvbiBvZiBQIHVzaW5nIFBLQ1NfX19fCgoKCgrCoMKgwqDC oMKgwqDCoMKgwqDCoCAjNyBwYWRkaW5nIHVzaW5nIHRoZSBjaXBoZXIgd2l0aCB0aGUga2V5IFgu X19fXyAKCgoKwqDCoMKgIF9fIF9fIAoKCgrCoMKgwqAgSSBiZWxpZXZlIHRoYXQgdGhlIGlkZW50 aWZpZXIgQ0JDLVBLQ1M1LUVOQ3Nob3VsZCBiZSBjaGFuZ2VkIHRvIENCQy1QS0NTNy1FTkMuX19f XwoKCgoKwqDCoMKgIF9fIF9fIAoKCgrCoMKgwqAgVW5sZXNzIHBlb3BsZSBkaXNhZ3JlZSwgSSB3 aWxsIHBsYW4gdG8gYXBwbHkgdGhlc2UgY29ycmVjdGlvbnMgZHVyaW5nIEFVVEg0OC5fX19fCgoK CgrCoMKgwqAgX18gX18gCgoKCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFRoYW5rcyBhbGwsX19fXyAKCgoKwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgLS0gTWlrZV9fX18gCgoKCsKgwqDCoCBfXyBfXyAKCgoKwqDCoMKgICpGcm9t Oipqb3NlIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnCjxtYWlsdG86am9zZS1ib3VuY2Vz QGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAqTWlrZSBKb25lcwoKCsKgwqDCoCAqU2VudDoqIEZy aWRheSwgSnVuZSAyMCwgMjAxNCA3OjAzIFBNIAoKwqDCoMKgICpUbzoqIFNoYXVuIENvb2xleSAo c2hjb29sZXkpIAoKwqDCoMKgICpDYzoqIGpvc2VAaWV0Zi5vcmcgCjxtYWlsdG86am9zZUBpZXRm Lm9yZz47IE1hdHQgTWlsbGVyIChtYW1pbGxlMikgCgrCoMKgwqAgKlN1YmplY3Q6KiBSZTogW2pv c2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTI3OiBzZWN0aW9uLTUuMiAo UEtDUyAjNSlfX19fCgoKCgrCoMKgwqAgX18gX18gCgoKCsKgwqDCoCBUaGlzIGNoYW5nZSBoYXMg YmVlbiBpbmNvcnBvcmF0ZWQgaW4gdGhlIC0yOCBkcmFmdHMuX19fXyAKCgoKwqDCoMKgIF9fIF9f IAoKCgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBUaGFua3MgYWdhaW4sIFNoYXVuLF9fX18KCgoKCsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIC0tIE1pa2VfX19fIAoKCgrCoMKgwqAgX18gX18gCgoKCsKgwqDCoCAqRnJvbToqam9z ZSBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqTWlrZSBKb25l cwoKCsKgwqDCoCAqU2VudDoqIEZyaWRheSwgSnVuZSAxMywgMjAxNCAyOjI3IFBNIAoKwqDCoMKg ICpUbzoqIFNoYXVuIENvb2xleSAoc2hjb29sZXkpIAoKwqDCoMKgICpDYzoqIGpvc2VAaWV0Zi5v cmcgCjxtYWlsdG86am9zZUBpZXRmLm9yZz47IE1hdHQgTWlsbGVyIChtYW1pbGxlMikgCgrCoMKg wqAgKlN1YmplY3Q6KiBSZTogW2pvc2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0 aG1zLTI3OiBzZWN0aW9uLTUuMiAoUEtDUyAjNSlfX19fCgoKCgrCoMKgwqAgX18gX18gCgoKCsKg wqDCoCAoQWRkaW5nIHRoZSBKT1NFIHdvcmtpbmcgZ3JvdXApX19fXyAKCgoKwqDCoMKgIF9fIF9f IAoKCgrCoMKgwqAgSSBiZWxpZXZlIHlvdeKAmXJlIHJpZ2h0LsKgIEnigJlsbCBwbGFuIHRvIG1h a2UgdGhpcyBjaGFuZ2UgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgc3BlYy5fX19fCgoKCgrC oMKgwqAgX18gX18gCgoKCsKgwqDCoCBUaGFua3MgZm9yIHRoZSBjYXJlZnVsIHJlYWQhX19fXyAK CgoKwqDCoMKgIF9fIF9fIAoKCgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAtLSBNaWtlX19fXyAKCgoKwqDCoMKg IF9fIF9fIAoKCgrCoMKgwqAgKkZyb206KlNoYXVuIENvb2xleSAoc2hjb29sZXkpIFttYWlsdG86 c2hjb29sZXlAY2lzY28uY29tXQoKCsKgwqDCoCAqU2VudDoqIEZyaWRheSwgSnVuZSAxMywgMjAx NCAxMDozNCBBTSAKCsKgwqDCoCAqVG86KiBNaWtlIEpvbmVzIAoKwqDCoMKgICpDYzoqIE1hdHQg TWlsbGVyIChtYW1pbGxlMikgCgrCoMKgwqAgKlN1YmplY3Q6KiBkcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0yNzogc2VjdGlvbi01LjIgKFBLQ1MgIzUpX19fXyAKCgoKwqDCoMKg IF9fIF9fIAoKCgrCoMKgwqAgTWljaGFlbCDigJNfX19fIAoKCgrCoMKgwqDCoMKgIEkgYW0gd29y a2luZyBvbiBpbXBsZW1lbnRpbmcgYSBicm93c2VyIGNvbXBhdGlibGUgSlMgaW1wbGVtZW50YXRp b24gb2YgSk9TRSwgYmFzZWQgb24gdGhlIHdvcmsgTWF0dCBNaWxsZXIgZGlkIGZvciBOb2RlLkpT LsKgIFdoaWxlIGdvaW5nIHRocm91Z2ggdGhlIHNwZWMsIEkgbm90aWNlZCB0aGF0IFBLQ1MgIzUg aXMgY2FsbGVkIG91dCBmb3IgdGhlIEFFUy1DQkMgY2lwaGVycy7CoCBTaG91bGRu4oCZdCB0aGlz IGJlIFBLQ1MgIzc/X19fXwoKCgoKwqDCoMKgIF9fIF9fIAoKCgrCoMKgwqAgUEtDUyAjNSDigJMg UkZDMjg5OCBzZWN0aW9uIDYuMiBzcGVjaWZpZXM6X19fXyAKCgoKwqDCoMKgIFRoZSBwYWRkaW5n IHN0cmluZyBQUyBzaGFsbCBjb25zaXN0IG9mIDggLSAofHxNfHwgbW9kIDgpIG9jdGV0cyBhbGwg aGF2aW5nIHZhbHVlIDggLSAofHxNfHwgbW9kIDgpLl9fX18KCgoKCsKgwqDCoCBfXyBfXyAKCgoK wqDCoMKgIFBLQ1MgIzcg4oCTIFJGQzIzMTUgc2VjdGlvbiAxMC4zIG5vdGUgMiBzcGVjaWZpZXM6 X19fXyAKCgoKwqDCoMKgIEZvciBzdWNoIGFsZ29yaXRobXMsIHRoZSBtZXRob2Qgc2hhbGwgYmUg dG8gcGFkIHRoZSBpbnB1dCBhdCB0aGUgdHJhaWxpbmcgZW5kIHdpdGggayAtIChsIG1vZCBrKSBv Y3RldHMgYWxsIGhhdmluZyB2YWx1ZSBrIC0gKGwgbW9kIGspLCB3aGVyZSBsIGlzIHRoZSBsZW5n dGggb2YgdGhlIGlucHV0Ll9fX18KCgoKCsKgwqDCoCBfXyBfXyAKCgoKwqDCoMKgIFBLQ1MgIzcg YWxsb3dzIGZvciBwYWRkaW5nIGluIGJsb2NrIHNpemVzIG9mIDItMjU1IGJ5dGVzLCB3aGVyZWFz IFBLQ1MgIzUgaXMgaW50ZW5kZWQgZm9yIGJsb2NrIHNpemVzIG9mIDguwqAgVGhpcyBtZWFucyB0 aGF0IFBLQ1MgIzcgaXMgYSBzdXBlcnNldCBvZiAjNSwgYW5kIGdpdmVuIHRoYXQgQUVTIGlzIGEg YmxvY2sgc2l6ZSBvZiAxNiwgaXQgc2VlbXMgdGhlIHNwZWMgc2hvdWxkIHJlcXVpcmUgUEtDUyAj Ny5fX19fCgoKCgrCoMKgwqAgX18gX18gCgoKCsKgwqDCoCBUaG91Z2h0cz9fX19fIAoKCgrCoMKg wqAgX18gX18gCgoKCsKgwqDCoCAqU2hhdW4gQ29vbGV5KiAKCsKgwqDCoCBESVNUSU5HVUlTSEVE IEVOR0lORUVSLkVOR0lORUVSSU5HIAoKwqDCoMKgIENvbGxhYm9yYXRpb24gVGVjaG5vbG9neSBH cm91cCAKCsKgwqDCoCBzaGNvb2xleUBjaXNjby5jb20gCjxtYWlsdG86c2hjb29sZXlAY2lzY28u Y29tPiAKCsKgwqDCoCBQaG9uZTogKisxIDQwOCA5MDIgMzM0NCA8dGVsOiUyQjElMjA0MDglMjA5 MDIlMjAzMzQ0PioKCgrCoMKgwqAgTW9iaWxlOiAqKzEgMzEwIDI5MyAyMDg3IDx0ZWw6JTJCMSUy MDMxMCUyMDI5MyUyMDIwODc+Kl9fX18KCgoKCsKgwqDCoMKgwqDCoMKgIAoKCgrCoMKgwqAgaHR0 cDovL3d3dy5jaXNjby5jb20vd2ViL2V1cm9wZS9pbWFnZXMvZW1haWwvc2lnbmF0dXJlL2xvZ28w NS5qcGcKCgrCoMKgwqAgQ2lzY28uY29tIDxodHRwOi8vd3d3LmNpc2NvLmNvbS8+X19fXyAKCgoK wqDCoMKgIF9fIF9fIAoKCgrCoMKgwqAgVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZQogcmVjaXBp ZW50KSwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQgZGVsZXRl IGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLl9fX18KCgoKCsKgwqDCoCBGb3IgY29ycG9yYXRl IGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOiAKCsKgwqDCoCAKaHR0cDovL3d3dy5jaXNjby5jb20v d2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sX19fXyAKCgoKwqDC oMKgIF9fIF9fIAoKCgrCoMKgwqAgX18gX18gCgoKCgoKwqDCoMKgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIAoKwqDCoMKgIGpvc2UgbWFpbGluZyBsaXN0 IAoKwqDCoMKgIGpvc2VAaWV0Zi5vcmcgCjxtYWlsdG86am9zZUBpZXRmLm9yZz4gCgrCoMKgwqAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlCgoKCgoKCgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gCgpqb3NlIG1haWxpbmcg bGlzdCAKCmpvc2VAaWV0Zi5vcmcgCgpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2pvc2UKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gCgpqb3NlIG1haWxpbmcgbGlzdCAKCmpvc2VAaWV0Zi5vcmcgCgpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UKCgoKCgoKCi0tIApWbGFkaW1pciBEemh1dmlub3Yg OjogdmxhZGltaXJAY29ubmVjdDJpZC5jb20KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpqb3NlIG1haWxpbmcgbGlzdAoKam9zZUBpZXRmLm9yZwoK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlCgoKCgo= ----_com.android.email_4304169759815660 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2PkkgYmVsaWV2ZSBh biBpbXBsZW1lbnRlcnMgbm90ZSBpcyBhcHByb3ByaWF0ZSBoZXJlLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25h dHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjlweCI+PGRpdiBzdHlsZT0iZm9udC1zaXplOiA5 cHg7ICI+LS0gSnVzdGluPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+PGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogOXB4OyAiPi8gU2VudCBmcm9tIG15IHBob25lIC88 L2Rpdj48L2Rpdj48ZGl2PjwvZGl2PjwvZGl2Pjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLTxicj5Gcm9tOiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20mZ3Q7IDxicj5EYXRlOiAwMy8yNy8yMDE1ICAxMjoxNSBQTSAgKEdNVC0wNjow MCkgPGJyPlRvOiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7 IDxicj5DYzogam9zZUBpZXRmLm9yZywgVmxhZGltaXIgRHpodXZpbm92ICZsdDt2bGFkaW1pckBj b25uZWN0MmlkLmNvbSZndDsgPGJyPlN1YmplY3Q6IFJlOiBbam9zZV0gZHJhZnQtaWV0Zi1qb3Nl LWpzb24td2ViLWFsZ29yaXRobXMtMjc6IHNlY3Rpb24tNS4yIChQS0NTICM1KSA8YnI+PGJyPjxt ZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04Ij48ZGl2IGRpcj0ibHRyIj5JdCBtYXkgb3IgbWF5IG5vdCB3YXJyYW50IGEgbm90ZSBv ZiBzb21lIHNvcnQgdG8gZXhwbGFpbiB0aGUgZGlzY3JlcGFuY3kgKG5vdCBzdXJlIGlmIHRoYXQn cyByZWFsbHkgaW4gc2NvcGUpLiBJdCBsb29rcyBhcyB0aG91Z2ggc29tZSBwcm92aWRlcnMgbGlr ZSBCb3VuY3kgQ2FzdGxlIGFuZCB0aGUgb25lIG9uIEFuZHJvaWQgd2lsbCB3b3JrIHdpdGggIkFF Uy9DQkMvUEtDUzdQYWRkaW5nIi4gQnV0ICJBRVMvQ0JDL1BLQ1M1UGFkZGluZyIgaXMgd2hhdCBp cyBuZWVkZWQgZm9yIHRoZSBTdW4vT3JhY2xlIEpDQSBwcm92aWRlciAoSSB2ZXJpZmllZCB0aGlz IGFnYWluIGFnYWluc3QgSmF2YSA3ICZhbXA7IDgpIGFuZCBpcyB3aGF0IGlzIHJlcXVpcmVkIGJ5 ICJFdmVyeSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgSmF2YSBwbGF0Zm9ybSIgcGVyIDxhIGhyZWY9 Imh0dHA6Ly9kb2NzLm9yYWNsZS5jb20vamF2YXNlLzcvZG9jcy9hcGkvamF2YXgvY3J5cHRvL0Np cGhlci5odG1sIj5odHRwOi8vZG9jcy5vcmFjbGUuY29tL2phdmFzZS83L2RvY3MvYXBpL2phdmF4 L2NyeXB0by9DaXBoZXIuaHRtbDwvYT4gYW5kIGl0IGFjdHVhbGx5IGdpdmUgeW91IFBLQ1M3UGFk ZGluZyBldmVuIHRob3VnaCBpdCBzYXlzIDUuIDxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIE1hciAyNywgMjAxNSBh dCA5OjQyIEFNLCBNaWtlIEpvbmVzIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CgoKCgoKPGRpdiBiZ2NvbG9yPSJ3aGl0ZSIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0iRU4tVVMiPgo8ZGl2Pgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+VGhh bmtzIGEgYnVuY2gsIFZsYWRpbWlyLiZuYnNwOyBUaGF0IGRlZmluaXRpdmVseSBhbnN3ZXJzIHRo ZSBxdWVzdGlvbi48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7 PHU+PC91Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4KPGRp dj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IGpvc2UgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0KPGI+T24gQmVoYWxmIE9mIDwvYj5WbGFkaW1pciBE emh1dmlub3Y8YnI+CjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDI3LCAyMDE1IDk6MzYgQU08 YnI+CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5qb3NlQGlldGYub3JnPC9hPjxicj4KPGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0gZHJh ZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMjc6IHNlY3Rpb24tNS4yIChQS0NTICM1 KTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4KPC9kaXY+CjwvZGl2PjxkaXY+PGRpdiBjbGFzcz0i aDUiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGlzIGlzIGluZGVl ZCBhIEpDQSBvZGRpdHksIHdoZW4gIlBLQ1M1UGFkZGluZyIgaXMgc3BlY2lmaWVkIEphdmEgYWN0 dWFsbHkgZG9lcyAiUEtDUzdQYWRkaW5nIi48YnI+Cjxicj4KSWYgeW91IHN0aWNrICJQS0NTN1Bh ZGRpbmciIHlvdSdsbCBnZXQgYW4gPHU+PC91Pjx1PjwvdT48L3A+CjxwcmU+PHNwYW4+Tm9TdWNo QWxnb3JpdGhtRXhjZXB0aW9uPC9zcGFuPjxzcGFuPjo8L3NwYW4+PHNwYW4+IDwvc3Bhbj48c3Bh bj5DYW5ub3Q8L3NwYW4+PHNwYW4+IGZpbmQgYW55IHByb3ZpZGVyIHN1cHBvcnRpbmcgQUVTPC9z cGFuPjxzcGFuPi88L3NwYW4+PHNwYW4+Q0JDPC9zcGFuPjxzcGFuPi88L3NwYW4+PHNwYW4+UEtD UzdQYWRkaW5nPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4+PHU+PC91PiZu YnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3NwYW4+PC9wcmU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+VmxhZGltaXI8dT48L3U+PHU+PC91PjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gMjcuMDMuMjAxNSAwODoyMCwgQW5kZXJzIFJ1bmRncmVuIHdyb3RlOjx1PjwvdT48dT48 L3U+PC9wPgo8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIwMTUtMDMtMjcgMDE6MzEs IEJyaWFuIENhbXBiZWxsIHdyb3RlOiA8YnI+Cjxicj4KPHU+PC91Pjx1PjwvdT48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYW0gcHJldHR5IHN1cmUgeW91IHNob3VsZCBub3QgbWFrZSB0aGF0 IGNoYW5nZSB0byB0aGUgSkNBIGFsZ29yaXRobSBzdHJpbmcuCjx1PjwvdT48dT48L3U+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7IEknbGwgaGF2ZSB0byBzZWFyY2ggYXJvdW5k IHRvIHJlbWVtYmVyIHdoeSwgc29tZSBvZGRpdHkgb2YgSmF2YSBJIHRoaW5rLAo8YnI+CiZndDsg YnV0IEknbSBhd2F5IGZyb20gbXkgbGFwdG9wIHJpZ2h0IG5vdyBhbmQgdGhhdCBvbmUgaXMgdG9v IG11Y2ggdG8gcmVzZWFyY2ggb24gYSBwaG9uZS4KPGJyPgo8YnI+CkluZGVlZCwgdGhpcyBpcyBh biBvbGQgU1VOIGJ1ZyB0aGF0IHdlIGhhdmUgdG8gcHV0IHVwIHdpdGg6IDxicj4KPGEgaHJlZj0i aHR0cDovL2RvY3Mub3JhY2xlLmNvbS9qYXZhc2UvNy9kb2NzL2FwaS9qYXZheC9jcnlwdG8vQ2lw aGVyLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZG9jcy5vcmFjbGUuY29tL2phdmFzZS83 L2RvY3MvYXBpL2phdmF4L2NyeXB0by9DaXBoZXIuaHRtbDwvYT4KPGJyPgo8YnI+Ckl0IGlzIHdv cnRoIGEgbm90ZSB0aG91Z2guIDxicj4KPGJyPgpBbmRlcnMgPGJyPgo8YnI+Cjxicj4KPHU+PC91 Pjx1PjwvdT48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPgpPbiBNYXIgMjYsIDIwMTUgNjo0MSBQTSwgIk1pa2UgSm9uZXMiICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPgo8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O21haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPiZndDsgd3JvdGU6Cjxicj4KPGJyPgombmJzcDsmbmJz cDsmbmJzcDsgSSBhbSB3b3JraW5nIG9uIHRoZSBmb3JtYXR0aW5nIG9mIHRoZSBhbGdvcml0aG0g Y3Jvc3MtcmVmZXJlbmNlIHRhYmxlcyBpbiBKV0EgQXBwZW5kaXggQQo8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy00 MCNhcHBlbmRpeC1BIiB0YXJnZXQ9Il9ibGFuayI+Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTQwI2FwcGVuZGl4LUE8L2E+IHdp dGggdGhlIFJGQyBFZGl0b3IgdG8gbWFrZSB0aGVtIG1vcmUgcmVhZGFibGUuJm5ic3A7IFdoZW4g bG9va2luZyBhdCB0aGUgdGFibGUgY29udGVudCAoaW4gYSBtb3JlIHJlYWRhYmxlIHJlbmRpdGlv biBJ4oCZbGwgc2hhcmUgd2l0aCB5b3Ugc29vbiksIEkgbm90aWNlZCB0aGF0IHRoaXMgc3RyaW5n IGFwcGVhcnMgZm9yCiB0aGUgSkNBIHZhbHVlIG9mIHRocmVlIGFsZ29yaXRobXM6X19fXyA8YnI+ Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEFFUy9DQkMvUEtDUzVQYWRkaW5nX19fXyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5i c3A7IHdoaWNoIEkgYmVsaWV2ZSBzaG91bGQgYmVfX19fIDxicj4KPGJyPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUVTL0NCQy9QS0NT N1BhZGRpbmdfX19fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPgo8YnI+ CiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIHdvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgY2hh bmdlcyBtYWRlIGluIC0yOCBmb3IgdGhlIHJlYXNvbnMgZGVzY3JpYmVkIGluIHRoaXMgdGhyZWFk LiBKQVZBIElNUExFTUVOVEVSU+KAkyBJZiB5b3UgYXJlIGN1cnJlbnRseSB1c2luZyBBRVMvQ0JD L1BLQ1M1UGFkZGluZyBjYW4geW91IHBsZWFzZSB2ZXJpZnkgdGhhdCB5b3VyIGltcGxlbWVudGF0 aW9uIHN0aWxsIHdvcmtzIGFmdGVyIGNoYW5naW5nIHRoaXMgc3RyaW5nIHRvIEFFUy9DQkMvUEtD UzdQYWRkaW5nCiBhbmQgdGhhdCB0aGUgcmVzdWx0cyBhcmUgc3RpbGwgY29ycmVjdCBhbmQgcmVw bHkgdG8gdXMgbGV0dGluZyB1cyBrbm93IHdoYXQgaGFwcGVuZWQ/IE1hdHQsIGlmIHlvdXIgY29k ZSBmb3IgdGhlIGNvb2tib29rIGlzIGluIEphdmEsIGl0IHdvdWxkIGJlIGVzcGVjaWFsbHkgZ29v ZCBpZiB5b3UgbWFkZSB0aGlzIGNvZGUgY2hhbmdlIGFuZCB2ZXJpZmllZCB0aGF0IG5vdGhpbmcg Y2hhbmdlcyBpbiB0aGUgb3V0cHV0Ll9fX18KPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBf XyBfXyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IEFsc28sIHRoaXMgY2xlYXJseSBpbmNv bnNpc3RlbnQgc2VudGVuY2UgY3VycmVudGx5IG9jY3VycyBpbiA8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy00MCNz ZWN0aW9uLTUuMi4xOl9fX18iIHRhcmdldD0iX2JsYW5rIj4KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtNDAjc2VjdGlvbi01LjIu MTpfX19fPC9hPgo8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENCQy1QS0NTNS1FTkMoWCwgUCkgZGVub3RlcyB0aGUg QUVTIENCQyBlbmNyeXB0aW9uIG9mIFAgdXNpbmcgUEtDU19fX18KPGJyPgo8YnI+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjNyBw YWRkaW5nIHVzaW5nIHRoZSBjaXBoZXIgd2l0aCB0aGUga2V5IFguX19fXyA8YnI+Cjxicj4KJm5i c3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgSSBiZWxp ZXZlIHRoYXQgdGhlIGlkZW50aWZpZXIgQ0JDLVBLQ1M1LUVOQ3Nob3VsZCBiZSBjaGFuZ2VkIHRv IENCQy1QS0NTNy1FTkMuX19fXwo8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxi cj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgVW5sZXNzIHBlb3BsZSBkaXNhZ3JlZSwgSSB3aWxs IHBsYW4gdG8gYXBwbHkgdGhlc2UgY29ycmVjdGlvbnMgZHVyaW5nIEFVVEg0OC5fX19fCjxicj4K PGJyPgombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWxsLF9fX18gPGJyPgo8YnI+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlX19fXyA8YnI+Cjxi cj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsg KkZyb206Kmpvc2UgWzxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPgo8YSBocmVmPSJtYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O21haWx0bzpqb3Nl LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9hPl0gKk9uIEJlaGFsZiBPZiAqTWlrZSBKb25lcwo8YnI+ CiZuYnNwOyZuYnNwOyZuYnNwOyAqU2VudDoqIEZyaWRheSwgSnVuZSAyMCwgMjAxNCA3OjAzIFBN IDxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7ICpUbzoqIFNoYXVuIENvb2xleSAoc2hjb29sZXkpIDxi cj4KJm5ic3A7Jm5ic3A7Jm5ic3A7ICpDYzoqIDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOmpvc2VA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4KJmx0O21haWx0bzpqb3NlQGlldGYub3JnJmd0Ozwv YT47IE1hdHQgTWlsbGVyIChtYW1pbGxlMikgPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgKlN1Ympl Y3Q6KiBSZTogW2pvc2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTI3OiBz ZWN0aW9uLTUuMiAoUEtDUyAjNSlfX19fCjxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgX18g X18gPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGNoYW5nZSBoYXMgYmVlbiBpbmNv cnBvcmF0ZWQgaW4gdGhlIC0yOCBkcmFmdHMuX19fXyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5i c3A7IF9fIF9fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhhbmtzIGFnYWluLCBTaGF1bixfX19fCjxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZV9fX18gPGJyPgo8YnI+CiZuYnNwOyZu YnNwOyZuYnNwOyBfXyBfXyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7ICpGcm9tOipqb3Nl IFs8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2YgKk1pa2UgSm9u ZXMKPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgKlNlbnQ6KiBGcmlkYXksIEp1bmUgMTMsIDIwMTQg MjoyNyBQTSA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyAqVG86KiBTaGF1biBDb29sZXkgKHNoY29v bGV5KSA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86am9zZUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0 bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+CiZsdDttYWlsdG86am9zZUBpZXRmLm9y ZyZndDs8L2E+OyBNYXR0IE1pbGxlciAobWFtaWxsZTIpIDxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICpTdWJqZWN0OiogUmU6IFtqb3NlXSBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGht cy0yNzogc2VjdGlvbi01LjIgKFBLQ1MgIzUpX19fXwo8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5i c3A7IF9fIF9fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgKEFkZGluZyB0aGUgSk9TRSB3 b3JraW5nIGdyb3VwKV9fX18gPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+ Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYmVsaWV2ZSB5b3XigJlyZSByaWdodC4mbmJzcDsg SeKAmWxsIHBsYW4gdG8gbWFrZSB0aGlzIGNoYW5nZSBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRo ZSBzcGVjLl9fX18KPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+Cjxicj4K Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBmb3IgdGhlIGNhcmVmdWwgcmVhZCFfX19fIDxicj4K PGJyPgombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlX19fXyA8YnI+Cjxicj4KJm5ic3A7Jm5i c3A7Jm5ic3A7IF9fIF9fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgKkZyb206KlNoYXVu IENvb2xleSAoc2hjb29sZXkpIFs8YSBocmVmPSJtYWlsdG86c2hjb29sZXlAY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNoY29vbGV5QGNpc2NvLmNvbTwvYT5dCjxicj4KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICpTZW50OiogRnJpZGF5LCBKdW5lIDEzLCAyMDE0IDEwOjM0IEFNIDxicj4K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpUbzoqIE1pa2UgSm9uZXMgPGJyPgombmJzcDsmbmJzcDsmbmJz cDsgKkNjOiogTWF0dCBNaWxsZXIgKG1hbWlsbGUyKSA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyAq U3ViamVjdDoqIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTI3OiBzZWN0aW9u LTUuMiAoUEtDUyAjNSlfX19fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJy Pgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBNaWNoYWVsIOKAk19fX18gPGJyPgo8YnI+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGFtIHdvcmtpbmcgb24gaW1wbGVtZW50aW5nIGEg YnJvd3NlciBjb21wYXRpYmxlIEpTIGltcGxlbWVudGF0aW9uIG9mIEpPU0UsIGJhc2VkIG9uIHRo ZSB3b3JrIE1hdHQgTWlsbGVyIGRpZCBmb3IgTm9kZS5KUy4mbmJzcDsgV2hpbGUgZ29pbmcgdGhy b3VnaCB0aGUgc3BlYywgSSBub3RpY2VkIHRoYXQgUEtDUyAjNSBpcyBjYWxsZWQgb3V0IGZvciB0 aGUgQUVTLUNCQyBjaXBoZXJzLiZuYnNwOyBTaG91bGRu4oCZdCB0aGlzIGJlIFBLQ1MgIzc/X19f Xwo8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4KPGJyPgombmJzcDsmbmJz cDsmbmJzcDsgUEtDUyAjNSDigJMgUkZDMjg5OCBzZWN0aW9uIDYuMiBzcGVjaWZpZXM6X19fXyA8 YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBwYWRkaW5nIHN0cmluZyBQUyBzaGFsbCBj b25zaXN0IG9mIDggLSAofHxNfHwgbW9kIDgpIG9jdGV0cyBhbGwgaGF2aW5nIHZhbHVlIDggLSAo fHxNfHwgbW9kIDgpLl9fX18KPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+ Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IFBLQ1MgIzcg4oCTIFJGQzIzMTUgc2VjdGlvbiAxMC4z IG5vdGUgMiBzcGVjaWZpZXM6X19fXyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBz dWNoIGFsZ29yaXRobXMsIHRoZSBtZXRob2Qgc2hhbGwgYmUgdG8gcGFkIHRoZSBpbnB1dCBhdCB0 aGUgdHJhaWxpbmcgZW5kIHdpdGggayAtIChsIG1vZCBrKSBvY3RldHMgYWxsIGhhdmluZyB2YWx1 ZSBrIC0gKGwgbW9kIGspLCB3aGVyZSBsIGlzIHRoZSBsZW5ndGggb2YgdGhlIGlucHV0Ll9fX18K PGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7 Jm5ic3A7IFBLQ1MgIzcgYWxsb3dzIGZvciBwYWRkaW5nIGluIGJsb2NrIHNpemVzIG9mIDItMjU1 IGJ5dGVzLCB3aGVyZWFzIFBLQ1MgIzUgaXMgaW50ZW5kZWQgZm9yIGJsb2NrIHNpemVzIG9mIDgu Jm5ic3A7IFRoaXMgbWVhbnMgdGhhdCBQS0NTICM3IGlzIGEgc3VwZXJzZXQgb2YgIzUsIGFuZCBn aXZlbiB0aGF0IEFFUyBpcyBhIGJsb2NrIHNpemUgb2YgMTYsIGl0IHNlZW1zIHRoZSBzcGVjIHNo b3VsZCByZXF1aXJlIFBLQ1MgIzcuX19fXwo8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9f IF9fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgVGhvdWdodHM/X19fXyA8YnI+Cjxicj4K Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxicj4KPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgKlNo YXVuIENvb2xleSogPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgRElTVElOR1VJU0hFRCBFTkdJTkVF Ui5FTkdJTkVFUklORyA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBDb2xsYWJvcmF0aW9uIFRlY2hu b2xvZ3kgR3JvdXAgPGJyPgombmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnNoY29v bGV5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoY29vbGV5QGNpc2NvLmNvbTwvYT4gPGEg aHJlZj0ibWFpbHRvOnNoY29vbGV5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPgombHQ7bWFp bHRvOnNoY29vbGV5QGNpc2NvLmNvbSZndDs8L2E+IDxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IFBo b25lOiAqPGEgaHJlZj0idGVsOiUyQjElMjA0MDglMjA5MDIlMjAzMzQ0IiB2YWx1ZT0iKzE0MDg5 MDIzMzQ0IiB0YXJnZXQ9Il9ibGFuayI+KzEgNDA4IDkwMiAzMzQ0PC9hPiAmbHQ7PGEgaHJlZj0i dGVsOiUyQjElMjA0MDglMjA5MDIlMjAzMzQ0IiB0YXJnZXQ9Il9ibGFuayI+dGVsOiUyQjElMjA0 MDglMjA5MDIlMjAzMzQ0PC9hPiZndDsqCjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IE1vYmlsZTog KjxhIGhyZWY9InRlbDolMkIxJTIwMzEwJTIwMjkzJTIwMjA4NyIgdmFsdWU9IisxMzEwMjkzMjA4 NyIgdGFyZ2V0PSJfYmxhbmsiPisxIDMxMCAyOTMgMjA4NzwvYT4gJmx0OzxhIGhyZWY9InRlbDol MkIxJTIwMzEwJTIwMjkzJTIwMjA4NyIgdGFyZ2V0PSJfYmxhbmsiPnRlbDolMkIxJTIwMzEwJTIw MjkzJTIwMjA4NzwvYT4mZ3Q7Kl9fX18KPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9ldXJvcGUvaW1hZ2VzL2VtYWlsL3NpZ25hdHVyZS9s b2dvMDUuanBnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2V1cm9w ZS9pbWFnZXMvZW1haWwvc2lnbmF0dXJlL2xvZ28wNS5qcGc8L2E+Cjxicj4KJm5ic3A7Jm5ic3A7 Jm5ic3A7IENpc2NvLmNvbSA8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS8iIHRhcmdldD0i X2JsYW5rIj4mbHQ7aHR0cDovL3d3dy5jaXNjby5jb20vJmd0OzwvYT5fX19fIDxicj4KPGJyPgom bmJzcDsmbmJzcDsmbmJzcDsgX18gX18gPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhvcml6 ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlCiByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2Uu X19fXwo8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5m b3JtYXRpb24gZ28gdG86IDxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93 d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRt bF9fX18iIHRhcmdldD0iX2JsYW5rIj4KaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2Rv aW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sX19fXzwvYT4gPGJyPgo8YnI+CiZuYnNw OyZuYnNwOyZuYnNwOyBfXyBfXyA8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IF9fIF9fIDxi cj4KPGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyBqb3NlIG1haWxp bmcgbGlzdCA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpq b3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+CiZsdDttYWlsdG86am9zZUBpZXRmLm9yZyZn dDs8L2E+IDxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT4KPGJyPgo8YnI+Cjxicj4KPGJyPgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8YnI+Cmpvc2UgbWFp bGluZyBsaXN0IDxicj4KPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5qb3NlQGlldGYub3JnPC9hPiA8YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT4KPHU+PC91Pjx1PjwvdT48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gPGJyPgpqb3NlIG1haWxpbmcgbGlzdCA8YnI+CjxhIGhyZWY9Im1haWx0bzpqb3Nl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT4gPGJyPgo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2U8L2E+Cjx1Pjwv dT48dT48L3U+PC9wPgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4KPGJy Pgo8dT48L3U+PHU+PC91PjwvcD4KPHByZT4tLSA8dT48L3U+PHU+PC91PjwvcHJlPgo8cHJlPlZs YWRpbWlyIER6aHV2aW5vdiA6OiA8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5j b20iIHRhcmdldD0iX2JsYW5rIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT48dT48L3U+PHU+ PC91PjwvcHJlPgo8L2Rpdj48L2Rpdj48L2Rpdj4KPC9kaXY+Cgo8YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Cmpvc2UgbWFpbGluZyBsaXN0PGJy Pgo8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+Cjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48 YnI+Cjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pgo8L2JvZHk+PC9odG1sPg== ----_com.android.email_4304169759815660-- From nobody Tue Mar 31 08:22:02 2015 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108311ACE36 for ; Tue, 31 Mar 2015 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4sU_6nJoQzh for ; Tue, 31 Mar 2015 08:21:53 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE11D1ACE38 for ; Tue, 31 Mar 2015 08:21:52 -0700 (PDT) Received: by lagg8 with SMTP id g8so15378910lag.1 for ; Tue, 31 Mar 2015 08:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=xL9YRhu05tiL8Wqr8qEyRDBgf30SM2VvPcKhwT47+h4=; b=oEXUlp3cA3o9BzfK+4AjqzrvnfkGJuMwzUzr4cbXOciyAdS3fatEZy5XThZCBi//4i 7nz0oUk9+AOCLOuCj7c5wbGDCPA96neOZFog4PQVeLJ8ROJC+/isxViP84DELU85kSTS da6UJEPemE5GweqAwt1TaaSCz8nLtgAzk7JvqNKxqeSEEmnFerkUO1guNQaUxU/f7maf rBzLzWVqd7S7bH/w13iyQlhJhwyAD/wBut/arvSsskxwtrpwnSfXWoahQyzUVFl4sDVP CChQzUA9XTAlIY5xXNDvbwcPObRpzK7jlOsnxPbzJ7Pfab563I/4h+bx7oJz5UXoWHjS OfJA== MIME-Version: 1.0 X-Received: by 10.152.4.136 with SMTP id k8mr31357305lak.103.1427815311346; Tue, 31 Mar 2015 08:21:51 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Tue, 31 Mar 2015 08:21:51 -0700 (PDT) Date: Tue, 31 Mar 2015 11:21:51 -0400 X-Google-Sender-Auth: auTCEORhfLjlrpcqdNIa5eS-Y0Y Message-ID: From: Phillip Hallam-Baker To: "jose@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [jose] Initial results of Binary encoding in JSON-B and JSON-C X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 15:21:56 -0000 Yesterday I added implementations of JWS, JSON-B and JSON-C to my existing JSON encoding suite (PROTOGEN). For the sake of fair comparison, I have not attempted any further optimization or made any changes to the encoding described here. http://tools.ietf.org/html/draft-hallambaker-jsonbcd-02 I could easily shave a few more bytes off the total with additional techniques which I considered but rejected as not being worth the space/complexity tradeoff. Implementation took approximately 2 hours for the encoding scheme and 4 hours for JWS. Much of the latter being spent writing test code to make sure that the test vectors in draft-41 work (they do). While implementing additional encodings is additional work, the binary encodings are actually much easier to implement than the text. There is no need to perform Base64 encoding. Estimating space requirements is a lot easier, etc. If I was implementing one encoder for a constrained device I would much prefer to do implement JSON-C than JSON. On the decoder side, JSON-B is a strict super-set of JSON which means that a decoder must support both encodings unless a 'binary only' subset is defined. But this does mean that a JSON-C decoder can decode JSON-B or traditional JSON, one decoder fits all. For a test case, I used: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41 Encoding the HMAC signature example results in the following encoding sizes: In JSON: 244 bytes In JSON-B: 165 bytes In JSON-C: 129 bytes In each case the Payload data is the string given in the example, even though this is JSON, this is left as is to provide a fair basis for comparison. This slightly overstates the advantage of JSON-B as my JSON encoding has indentation. The main saving comes from avoiding the need to BASE64 armor the binary blobs. Looking at the internals: In JSON: 244 bytes Protected 35 / Payload 70 / Signature 32 In JSON-B: 165 bytes Protected 24 / Payload 70 / Signature 32 In JSON-C: 129 bytes Protected 13 / Payload 70 / Signature 32 Since the payload and signature are the same for each example, 102 bytes of the message are irreducible. The move from text to binary blobs saves 79 bytes, 30 of which are coming from eliminating Base64. Tag and string compression saves another 34 bytes, but only in the case where we can pre-exchange the tag dictionary. JSON-C also supports an on-the fly string compression technique but that only provides savings for longer messages with large areas of repeated texts. Conclusion: 1) We do not need a new working group to specify a binary encoding of JOSE. The fact that CBOR requires hand tweaking to apply it to a JSON data structure is the reason that I and others objected to the approach from the start. Note that I wrote JSON-BCD in response to the statement made by the CBOR cabal that they were a private group that was not required to be open, consider alternative approaches or respect IETF consensus. In particular the statement was made repeatedly that 'CBOR is not intended to be a binary encoding of JSON'. 2) A binary encoding of JSON should not require additional IETF time, effort or review. The implementation of JSON-B is entirely mechanical and required no additional input whatsoever. The only additional input required for use of JSON-C is the compilation of a tag dictionary. The one I used has 88 defined code points which I compiled by looking through the IANA considerations section of the draft. This could easily be produced automatically through use of a tool. Since JSON-B uses byte aligned tags and there is only a need for 88 of them, the choice of tag values has absolutely no impact on the compression efficiency. 3) A binary encoding should not require ongoing maintenance. What worries me most about the CBOR fiasco is that we risk a MIB type situation in which every new IETF JSON protocol requires a parallel 'CBOR' encoding and this becomes an ongoing maintenance requirement. JSON-B is designed as a strict superset of JSON so that upwards compatibility is guaranteed. This allows use of a new version of the specification or support a privately defined tag that is not in the dictionary without waiting for a new dictionary to be issued or a new 'binary' version of the specification to be defined. 4) The IETF needs a binary encoding of JSON that encodes precisely the JSON data model with (almost) nothing added or taken away. A Binary encoding of JSON does need to add a binary type which is an extension of the JSON model. A case could also be made for a DateTime intrinsic type which would be rendered in RFC3339 format strings in JSON but I have resisted this so far. One of the main reasons for rejecting many of the existing Binary JSON formats is that the designers have found the temptation to add code points for their favorite random data types irresistible. 5) While it is possible to improve JSON-B compression efficiency, the savings are unlikely to be very interesting. The use of the JWS example is instructive because the only way to improve significantly on JSON-C would be to compress the payload. Out of the 129 bytes used in the JSON-C version, 104 are data elements and 25 are framing for two nested structures with a total of six structure element. That is an average overhead of 4 bytes per element including the tag and length data.