From bcampbell@pingidentity.com Mon Apr 2 07:42:50 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8356521F84D1 for ; Mon, 2 Apr 2012 07:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzST3-8uLQWr for ; Mon, 2 Apr 2012 07:42:50 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id A784921F8510 for ; Mon, 2 Apr 2012 07:42:49 -0700 (PDT) Received: from mail-vx0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKT3m66PXwKWpdEEZdYkq0t7FOF+ql+2UK@postini.com; Mon, 02 Apr 2012 07:42:49 PDT Received: by vcbf13 with SMTP id f13so2549229vcb.8 for ; Mon, 02 Apr 2012 07:42:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/HN11ncLcwWDEYIdzrqneJcEG0aLF/vAbnIro0UsG8M=; b=TqFZyOYnWu/gCHf2xzgZzHHGPvHdVj2HCGo4N/cUkm3yOQ+5/SOEj+VLvgQnlOSYug bvyB8TBSsj9cMMQe98q/itt88/3Oh8zgrMQ7kIxYglVBPFgq1+o5Or4NwLIOxTJ/pfYS 8wcix/4kLttQu3aC/PAaUyfUCXF+FkuFwoeV6Ot4cqKgNnWAsRwFl9m90LBwhDxxP3Jc hDQsWL4pbm9pwE12zWk6zmi9mija2ERyRdsdHyDxOTCegiIa6qUB4aXXDKkiuI+iKktE 9qjHCfCswslab7KSC3twxoFvUqB3afl3b4E3lduKCvza/mGTknezgTpHK3JCpecij0Xf ty8Q== Received: by 10.52.27.162 with SMTP id u2mr3286265vdg.65.1333377768036; Mon, 02 Apr 2012 07:42:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Mon, 2 Apr 2012 07:42:17 -0700 (PDT) In-Reply-To: <20120331124748.cc40c4f3d92d2001859047cd8cabb9ab.5135826b7b.wbe@email07.europe.secureserver.net> References: <20120331124748.cc40c4f3d92d2001859047cd8cabb9ab.5135826b7b.wbe@email07.europe.secureserver.net> From: Brian Campbell Date: Mon, 2 Apr 2012 08:42:17 -0600 Message-ID: To: "Vladimir Dzhuvinov / NimbusDS" Content-Type: multipart/alternative; boundary=20cf307ca3b037191a04bcb33447 X-Gm-Message-State: ALoCoQna8MV3FfNT2B1g4leBgc/HR+N8lhuYOW/eaglXdBrnfDUPpeJ9X9DUuzRrjCC7KbA6Ucu3 Cc: jose@ietf.org Subject: Re: [jose] JWA - list encryption algorithms requiring integrity? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:42:50 -0000 --20cf307ca3b037191a04bcb33447 Content-Type: text/plain; charset=ISO-8859-1 +1 On Sat, Mar 31, 2012 at 1:47 PM, Vladimir Dzhuvinov / NimbusDS < vladimir@nimbusds.com> wrote: > Hey guys, > > Just a small suggestion regarding the JSON Web Algorithms (JWA) spec: it > could be useful to list which encryption algorithms require the > additional integrity protection. > > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --20cf307ca3b037191a04bcb33447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Sat, Mar 31, 2012 at 1:47 PM, Vladi= mir Dzhuvinov / NimbusDS <vladimir@nimbusds.com> wrote:
Hey guys,

Just a small suggestion regarding the JSON Web Algorithms (JWA) spec: it could be useful to list which encryption algorithms require the
additional integrity protection.


Vladimir

--
Vladimir Dzhuvinov : = www.NimbusDS.com : vladimir@ni= mbusds.com

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

--20cf307ca3b037191a04bcb33447-- From Michael.Jones@microsoft.com Mon Apr 2 08:08:16 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEAF21F85EF for ; Mon, 2 Apr 2012 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3FpTRZu4N29 for ; Mon, 2 Apr 2012 08:08:15 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id A9B5D21F84C9 for ; Mon, 2 Apr 2012 08:08:14 -0700 (PDT) Received: from mail60-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Apr 2012 15:08:13 +0000 Received: from mail60-db3 (localhost [127.0.0.1]) by mail60-db3-R.bigfish.com (Postfix) with ESMTP id 70EA42203A8; Mon, 2 Apr 2012 15:08:13 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail60-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail60-db3 (localhost.localdomain [127.0.0.1]) by mail60-db3 (MessageSwitch) id 1333379290935984_32624; Mon, 2 Apr 2012 15:08:10 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.238]) by mail60-db3.bigfish.com (Postfix) with ESMTP id DFE0D40059; Mon, 2 Apr 2012 15:08:10 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Apr 2012 15:08:09 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0283.004; Mon, 2 Apr 2012 15:08:05 +0000 From: Mike Jones To: Brian Campbell , Vladimir Dzhuvinov / NimbusDS Thread-Topic: [jose] JWA - list encryption algorithms requiring integrity? Thread-Index: AQHND3csqDhWXV7ErkeSqjuWaG/5g5aHnquAgAAG04A= Date: Mon, 2 Apr 2012 15:08:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366452A41@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120331124748.cc40c4f3d92d2001859047cd8cabb9ab.5135826b7b.wbe@email07.europe.secureserver.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366452A41TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] JWA - list encryption algorithms requiring integrity? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:08:16 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366452A41TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Already planned for the next revision. Eric Rescorla's presentation in Par= is contained this information, which will be incorporated in the spec. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bri= an Campbell Sent: Monday, April 02, 2012 7:42 AM To: Vladimir Dzhuvinov / NimbusDS Cc: jose@ietf.org Subject: Re: [jose] JWA - list encryption algorithms requiring integrity? +1 On Sat, Mar 31, 2012 at 1:47 PM, Vladimir Dzhuvinov / NimbusDS > wrote: Hey guys, Just a small suggestion regarding the JSON Web Algorithms (JWA) spec: it could be useful to list which encryption algorithms require the additional integrity protection. Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@n= imbusds.com _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366452A41TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Already planned for the n= ext revision.  Eric Rescorla’s presentation in Paris contained t= his information, which will be incorporated in the spec.<= /p>

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, April 02, 2012 7:42 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] JWA - list encryption algorithms requiring integ= rity?

 

+1

On Sat, Mar 31, 2012 at 1:47 PM, Vladimir Dzhuvinov = / NimbusDS <vladimir@nimbusds.c= om> wrote:

Hey guys,

Just a small suggestion regarding the JSON Web Algorithms (JWA) spec: it could be useful to list which encryption algorithms require the
additional integrity protection.


Vladimir

--
Vladimir Dzhuvinov : = www.NimbusDS.com : vladimir@nimbusds.com

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366452A41TK5EX14MBXC283r_-- From vladimir@nimbusds.com Tue Apr 3 02:11:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B765621F84B8 for ; Tue, 3 Apr 2012 02:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVfCAsQHkeOd for ; Tue, 3 Apr 2012 02:11:45 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 5C52621F84A6 for ; Tue, 3 Apr 2012 02:11:44 -0700 (PDT) Received: (qmail 22077 invoked from network); 3 Apr 2012 09:11:42 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 3 Apr 2012 09:11:31 -0000 Received: (qmail 10145 invoked by uid 99); 3 Apr 2012 09:11:31 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 95.43.58.44 User-Agent: Workspace Webmail 5.6.15 Message-Id: <20120403021130.cc40c4f3d92d2001859047cd8cabb9ab.5dd95571f3.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Tue, 03 Apr 2012 02:11:30 -0700 Mime-Version: 1.0 Subject: [jose] JWE and the Initialisation Vector (iv) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:11:47 -0000 Hi guys,=0A=0Ahttp://tools.ietf.org/html/draft-ietf-jose-json-web-encryptio= n-01#section-8.2=0A=0Asays "for GCM, the random 64-bit IV is prepended to t= he ciphertext."=0A=0AIsn't the JWE "iv" header parameter meant to store the= IV bytes?=0A=0AVladimir=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vla= dimir@nimbusds.com=0A From vladimir@nimbusds.com Tue Apr 3 02:24:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DCA21F85AE for ; Tue, 3 Apr 2012 02:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNaMwD1+FwNH for ; Tue, 3 Apr 2012 02:24:28 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 1943521F85AA for ; Tue, 3 Apr 2012 02:24:27 -0700 (PDT) Received: (qmail 1176 invoked from network); 3 Apr 2012 09:24:26 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 3 Apr 2012 09:24:22 -0000 Received: (qmail 1539 invoked by uid 99); 3 Apr 2012 09:24:22 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 95.43.58.44 User-Agent: Workspace Webmail 5.6.15 Message-Id: <20120403022421.cc40c4f3d92d2001859047cd8cabb9ab.f58ffac80e.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Tue, 03 Apr 2012 02:24:21 -0700 Mime-Version: 1.0 Subject: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:24:29 -0000 Today I reached a point in my JWT+JOSE library implementation where I=0Awou= ldn't feel ashamed to release it to the public :)=0A=0Ahttps://github.com/N= imbusDS/Nimbus-JWT=0A=0AThe library is fully documented:=0Ahttp://nimbusds.= com/files/jwt/javadoc/index.html=0A=0A=0AThe Nimbus-JWT library started a m= onth ago from code borrowed from Axel=0ANennker's + Co OpenInfoCard project= and at this point covers fully plain=0Aand signed JWTs as well as JSON Web= Keys (JWK). The JWE implementation=0Astill requires a bit of work to add H= MAC integrity and cover the=0Aremaining elliptic curve and key-wrap encrypt= ion algorithms from the JWA=0Aspec. I would be very thankful if somebody co= uld help me with that as I=0Adon't have much experience with cryptography := )=0A=0AFor the listing of the supported JWAs:=0Ahttp://nimbusds.com/files/j= wt/javadoc/com/nimbusds/jwt/JWA.html=0A=0ACheers,=0A=0AVladimir=0A--=0AVlad= imir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A From bcampbell@pingidentity.com Wed Apr 4 15:41:13 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFBC21F849B for ; Wed, 4 Apr 2012 15:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgE9KY9-jldN for ; Wed, 4 Apr 2012 15:41:13 -0700 (PDT) Received: from psmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7321F8499 for ; Wed, 4 Apr 2012 15:41:12 -0700 (PDT) Received: from mail-vb0-f42.google.com ([209.85.212.42]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKT3zOCK5j7yPBt+Rbf2QeFXwCsQw2bXXt@postini.com; Wed, 04 Apr 2012 15:41:12 PDT Received: by vbjk13 with SMTP id k13so774132vbj.29 for ; Wed, 04 Apr 2012 15:41:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=QjdffPpLYvO9JZUHEjRRxw5KaGsOilIKPPHHXbnsz3Y=; b=iJOtsuiQ2jv6ntdlY5BNgl4sJAsou6YBeHTVlweR/brJcrys8RyDA5oQDX2a+erzYN RW7v5w9PN4mch1mjd9A35D+pwX4qeMYjYT6WHi69iul3trgJl2AEoDq9GQH7yrJgguWK b7cVI+t5n7ZemHdx8yi3aXS5T0V0yoS4XojJDl82nJL3Cjw7gkTs5lzZmuY69qyDJhsS 1PTpvFZ8VyL1mS48PNaLWc8tnV0ZmMLw8ulh/LsxVQ+Yk0aFQ1pkMriF2cSn9dv15RQB PO+i9w14XAQsBu9RwK3ij0IWLY/ajYXAoTCi4/SL6KCxGk39zM2q2EdKejVzG8+WNys4 PWTw== Received: by 10.52.27.162 with SMTP id u2mr142511vdg.65.1333579271378; Wed, 04 Apr 2012 15:41:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Wed, 4 Apr 2012 15:40:40 -0700 (PDT) From: Brian Campbell Date: Wed, 4 Apr 2012 16:40:40 -0600 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlH9e2mKrtmbDq5x72ZA9cwbaV960k60DVGEQRYDy4iJq0oKlYAuwENKQlSEDgUBxluOAF2 Subject: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:41:13 -0000 Hi all, I was hoping someone could help me (hopefully it's not just me!) understand the reasons for the introduction of the key derivation stuff* into JWE draft -01? I understand that it's there to derive the two keys, CEK and CIK, from the CMK and that it is to be done when a non-AEAD algorithm is used to encrypt the content. But what is the value of deriving the two keys as apposed to using the CMK for both encryption and integrity? Perhaps naively I assumed that using the CMK for both would be sufficient. It's randomly generated and used only for the one JWE. It's not clear to me what benefit is provided by the additional complexity of the derivation function as well as its conditional application (and the potential interoperability problems that come with such complexity). I assume there's some security benefit? But I can't see what it is. Any help would be appreciated. Thanks, Brian * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-7 which is referenced by http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-5 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-6 From juraj.somorovsky@rub.de Wed Apr 4 16:13:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DE621F8546 for ; Wed, 4 Apr 2012 16:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECmgIm1tGJLJ for ; Wed, 4 Apr 2012 16:13:26 -0700 (PDT) Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id A517821F84C2 for ; Wed, 4 Apr 2012 16:13:25 -0700 (PDT) X-Queued: (qmail 8917 invoked by alias); 4 Apr 2012 23:13:24 -0000 X-Queued: (qmail 8902 invoked from network); 4 Apr 2012 23:13:24 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx4.rz.ruhr-uni-bochum.de with SMTP; 4 Apr 2012 23:13:24 -0000 X-Queued: (qmail 1578 invoked by uid 281); 4 Apr 2012 23:13:24 -0000 X-Qmailscanner: from 178.201.46.200 (7Cil8M2CiUyUioUk/LQ5Gw==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.29/4.75. Clear:RC:1(178.201.46.200):. Processed in 0.033693 secs); 04 Apr 2012 23:13:24 -0000 Received: from ip-178-201-46-200.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUyUioUk/LQ5Gw==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 4 Apr 2012 23:13:23 -0000 Date: 5 Apr 2012 01:13:22 +0200 Message-ID: <4F7CD592.6090902@rub.de> From: "Juraj Somorovsky" To: vladimir@nimbusds.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 References: <20120403022421.cc40c4f3d92d2001859047cd8cabb9ab.f58ffac80e.wbe@email07.europe.secureserver.net> In-Reply-To: <20120403022421.cc40c4f3d92d2001859047cd8cabb9ab.f58ffac80e.wbe@email07.europe.secureserver.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: jose@ietf.org Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 23:13:26 -0000 Hi Vladimir, I have took a look at your implementation and found out, that your PKCS1 handling is vulnerable to the Bleichenbacher attack (the adversary could be able to issue different ciphertexts, send them to the server, and according to its responses he could learn the encrypted CEK) I will send you PoCs and instructions how to fix it by tomorrow...or just take a look at the document written by Eric Rescorla: http://www.ietf.org/rfc/rfc3218.txt Regards Juraj On 04/03/2012 11:24 AM, Vladimir Dzhuvinov / NimbusDS wrote: > Today I reached a point in my JWT+JOSE library implementation where I > wouldn't feel ashamed to release it to the public :) > > https://github.com/NimbusDS/Nimbus-JWT > > The library is fully documented: > http://nimbusds.com/files/jwt/javadoc/index.html > > > The Nimbus-JWT library started a month ago from code borrowed from Axel > Nennker's + Co OpenInfoCard project and at this point covers fully plain > and signed JWTs as well as JSON Web Keys (JWK). The JWE implementation > still requires a bit of work to add HMAC integrity and cover the > remaining elliptic curve and key-wrap encryption algorithms from the JWA > spec. I would be very thankful if somebody could help me with that as I > don't have much experience with cryptography :) > > For the listing of the supported JWAs: > http://nimbusds.com/files/jwt/javadoc/com/nimbusds/jwt/JWA.html > > Cheers, > > Vladimir > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- M.Sc. Juraj Somorovsky Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum ----------------------------------- Universitätsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de From ve7jtb@ve7jtb.com Wed Apr 4 16:42:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7435211E80FE for ; Wed, 4 Apr 2012 16:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcgs2dDCSbzm for ; Wed, 4 Apr 2012 16:42:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7CD311E809F for ; Wed, 4 Apr 2012 16:42:25 -0700 (PDT) Received: by ggmi1 with SMTP id i1so568615ggm.31 for ; Wed, 04 Apr 2012 16:42:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=9JvWZAm8c839rBbGPrMo87m8zn9fufrt0GjE61Ppmyc=; b=BayUubVC/62r202THqMsuj/V4ldsUzw/wp/FPGWFpMWYLpPuU/IHEhZHGJUjUwWzah TNnayAPUBlxd0Y7hcpFZUb4JZdXHJYIpUdfiy6F0zpv5bW3wGeZ17cekyJ3//mYjYZ+V Ag3Dec+QS2INsShaVcAMdkC74wcVzRhZA2brHCfJ/zFDnOudmssrWLi1OPsfDae4sgAm zk7HBKo4n/BD3dev4XE4SrPH3RESF+kdd+l297FiVHLz6VcejwzJ5loyfSL0Y2Rmdr/W IHKnSwmn8yfZC/5tkbY4klHj7rPl7I4OydwxIWqs2q0rDSMDbhWqnXYWI31QXYpIFesk XAzg== Received: by 10.101.152.1 with SMTP id e1mr77049ano.83.1333582945272; Wed, 04 Apr 2012 16:42:25 -0700 (PDT) Received: from [192.168.1.213] (190-20-18-73.baf.movistar.cl. [190.20.18.73]) by mx.google.com with ESMTPS id t43sm7949514yht.11.2012.04.04.16.42.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 16:42:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_00484FDE-E227-456C-9445-85D7CA3EDB5C"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Wed, 4 Apr 2012 20:42:14 -0300 Message-Id: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> References: To: Brian Campbell X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmuSCdwIXS6Fpsa3RNybnqaf+AzYO0W+4+E+V9ELemPq8OaRBJS7un35O6D9l+Ij4EO/pia Cc: jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 23:42:26 -0000 --Apple-Mail=_00484FDE-E227-456C-9445-85D7CA3EDB5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The use of a single key across two functions is one of things that is = not provably without problems. I agree that from an implementers point of view one key is simpler. There is a related-key attack that using the same key would enable. = This can be combined with differential and linear attacks on symmetric = key cyphers. Generally this can be thought of as a bad thing. What is certain is that it increases the possible attack surface, and = if the is a problem discovered as we have seen with AES-CBC it is going = to be hard to change later. We need key derivation anyway for ECDH-ES to produce a key of the = correct bit length. Doing key derivation on CMK is the theoretically proper way to do it. Making a simplification might bite us in the future. I suppose one way to get around the conditional application argument is = to always use it to produce the CEK even with AEAD algorithms. Regards John B. On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > Hi all, >=20 > I was hoping someone could help me (hopefully it's not just me!) > understand the reasons for the introduction of the key derivation > stuff* into JWE draft -01? >=20 > I understand that it's there to derive the two keys, CEK and CIK, from > the CMK and that it is to be done when a non-AEAD algorithm is used to > encrypt the content. But what is the value of deriving the two keys as > apposed to using the CMK for both encryption and integrity? >=20 > Perhaps naively I assumed that using the CMK for both would be > sufficient. It's randomly generated and used only for the one JWE. > It's not clear to me what benefit is provided by the additional > complexity of the derivation function as well as its conditional > application (and the potential interoperability problems that come > with such complexity). I assume there's some security benefit? But I > can't see what it is. >=20 > Any help would be appreciated. > Thanks, > Brian >=20 > * = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 7 > which is referenced by > = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 5 > and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 6 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_00484FDE-E227-456C-9445-85D7CA3EDB5C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NDIzNDIxNVowIwYJKoZIhvcNAQkEMRYEFMkeQGx/C/KDvg2xpZbBe7SsU6UOMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACfUzlkZTQrxz7Nbls/dB+CtP8ZVGiZ3C2CwIODJ32ezGLwCLRwDy5BTrcp5JUZiQQ8D/VeHtkYK NOrhPruY32FZYpeifFRFbGfqF0Z7Efvy1Xhx1+vQc4qXUuBj1gUlhuV5Xg14ScXQbqH9o1u2MImR FQEkV7Hwem01ApCeyhEvbQhv0TqzkgyGiljw3YN8pMvgMvMqw8gjIfO93k1l1KgFcxSTzNi1wRDO UbF5sAur+WUWy9xr4mnYohtz1fYxAQCT986mpilrYLcVdVsTqUlEYLPSJ0rb/WcMQ8RYRjUYiX2H DXSiEBWsFQYc43fb2MlhNGsOWV8C/foV5xSg+IwAAAAAAAA= --Apple-Mail=_00484FDE-E227-456C-9445-85D7CA3EDB5C-- From vladimir@nimbusds.com Thu Apr 5 04:34:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A899921F878B for ; Thu, 5 Apr 2012 04:34:15 -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=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfWjlTrhAkOV for ; Thu, 5 Apr 2012 04:34:14 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 4C79021F8775 for ; Thu, 5 Apr 2012 04:34:14 -0700 (PDT) Received: (qmail 30562 invoked from network); 5 Apr 2012 11:34:08 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 5 Apr 2012 11:33:57 -0000 Received: (qmail 32679 invoked by uid 99); 5 Apr 2012 11:33:57 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.76.96 User-Agent: Workspace Webmail 5.6.15 Message-Id: <20120405043356.cc40c4f3d92d2001859047cd8cabb9ab.f357faaeda.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Juraj Somorovsky" Date: Thu, 05 Apr 2012 04:33:56 -0700 Mime-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:34:15 -0000 Hey, huge thanks for that!=0A=0AI remember this weakness mentioned some tim= e ago, but didn't know more=0Auntil now.=0A=0AI'm not planning more work on= the JWT library for the next couple of=0Aweeks. So there's no rush, at lea= st for me. If you have a concrete=0Asuggestion how to fix the I would be gr= ateful :)=0A=0ACheers,=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.Nim= busDS.com : vladimir@nimbusds.com=0A =0A=0A-------- Original Message ------= --=0ASubject: Re: [jose] JWT + JOSE for Java=0AFrom: "Juraj Somorovsky" =0ADate: Thu, April 05, 2012 12:13 am=0ATo: vladimir@= nimbusds.com=0ACc: jose@ietf.org=0A=0A=0AHi Vladimir,=0A=0AI have took a lo= ok at your implementation and found out, that your PKCS1=0Ahandling is vuln= erable to the Bleichenbacher attack (the adversary could=0Abe able to issue= different ciphertexts, send them to the server, and=0Aaccording to its res= ponses he could learn the encrypted CEK)=0A=0AI will send you PoCs and inst= ructions how to fix it by tomorrow...or=0Ajust take a look at the document = written by Eric Rescorla:=0Ahttp://www.ietf.org/rfc/rfc3218.txt=0A=0ARegard= s=0AJuraj=0A=0AOn 04/03/2012 11:24 AM, Vladimir Dzhuvinov / NimbusDS wrote:= =0A> Today I reached a point in my JWT+JOSE library implementation where I= =0A> wouldn't feel ashamed to release it to the public :)=0A> =0A> https://= github.com/NimbusDS/Nimbus-JWT=0A> =0A> The library is fully documented:=0A= > http://nimbusds.com/files/jwt/javadoc/index.html=0A> =0A> =0A> The Nimbus= -JWT library started a month ago from code borrowed from Axel=0A> Nennker's= + Co OpenInfoCard project and at this point covers fully plain=0A> and sig= ned JWTs as well as JSON Web Keys (JWK). The JWE implementation=0A> still r= equires a bit of work to add HMAC integrity and cover the=0A> remaining ell= iptic curve and key-wrap encryption algorithms from the JWA=0A> spec. I wou= ld be very thankful if somebody could help me with that as I=0A> don't have= much experience with cryptography :)=0A> =0A> For the listing of the suppo= rted JWAs:=0A> http://nimbusds.com/files/jwt/javadoc/com/nimbusds/jwt/JWA.h= tml=0A> =0A> Cheers,=0A> =0A> Vladimir=0A> --=0A> Vladimir Dzhuvinov : www.= NimbusDS.com : vladimir@nimbusds.com=0A> =0A> _____________________________= __________________=0A> jose mailing list=0A> jose@ietf.org=0A> https://www.= ietf.org/mailman/listinfo/jose=0A=0A-- =0AM.Sc. Juraj Somorovsky=0A=0ALehrs= tuhl f=C3=BCr Netz- und Datensicherheit=0ARuhr Universit=C3=A4t Bochum=0A--= ---------------------------------=0AUniversit=C3=A4tsstr. 150, Geb. ID 2/41= 1=0AD-44780 Bochum=0A=0ATelefon: +49 (0) 234 / 32-26551=0AFax: +49 (0) 234 = / 32-14347=0Ahttp://www.nds.rub.de=0A From Axel.Nennker@telekom.de Thu Apr 5 05:00:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2054021F87CD for ; Thu, 5 Apr 2012 05:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ju23fbrd8MD for ; Thu, 5 Apr 2012 05:00:34 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id B5E5921F881D for ; Thu, 5 Apr 2012 05:00:33 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 05 Apr 2012 14:00:14 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.250]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Thu, 5 Apr 2012 14:00:14 +0200 From: To: , Date: Thu, 5 Apr 2012 14:00:13 +0200 Thread-Topic: [jose] JWT + JOSE for Java Thread-Index: Ac0SuI6VLC6cIch5TGm4x9nsVGx68wAaRcDQ Message-ID: References: <20120403022421.cc40c4f3d92d2001859047cd8cabb9ab.f58ffac80e.wbe@email07.europe.secureserver.net> <4F7CD592.6090902@rub.de> In-Reply-To: <4F7CD592.6090902@rub.de> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 12:00:35 -0000 Hi Juraj, As Vladimir's work is based on my implementation I guess that my implementa= tion has room for improvement too. https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/j= son/WebToken.java ENC_ALG_RSA_OAEP is better than ENC_ALG_RSA1_5.=20 https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/j= son/WebToken.java#116 Both padding algorithms are supported by my code and this RSA bulletin ment= ions OAEP as one counter measure against the Bleichenbacher attack. ftp://f= tp.rsasecurity.com/pub/pdfs/bulletn7.pdf Does "your" attack work against ENC_ALG_RSA_OAEP too? Additional counter me= asures suggestions are very welcome. RSA1_5 is in the proposed standard because it is widely available although = RSA recommends to use OAEP for decades.=20 I think that RSA-OAEP should be mandatory to implement and RSA1_5 deprecate= d. Cheers. Greetings from Berlin to Bochum. Axel -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jur= aj Somorovsky Sent: Thursday, April 05, 2012 1:13 AM To: vladimir@nimbusds.com Cc: jose@ietf.org Subject: Re: [jose] JWT + JOSE for Java Hi Vladimir, I have took a look at your implementation and found out, that your PKCS1 ha= ndling is vulnerable to the Bleichenbacher attack (the adversary could be a= ble to issue different ciphertexts, send them to the server, and according = to its responses he could learn the encrypted CEK) I will send you PoCs and instructions how to fix it by tomorrow...or just t= ake a look at the document written by Eric Rescorla: http://www.ietf.org/rfc/rfc3218.txt Regards Juraj On 04/03/2012 11:24 AM, Vladimir Dzhuvinov / NimbusDS wrote: > Today I reached a point in my JWT+JOSE library implementation where I=20 > wouldn't feel ashamed to release it to the public :) >=20 > https://github.com/NimbusDS/Nimbus-JWT >=20 > The library is fully documented: > http://nimbusds.com/files/jwt/javadoc/index.html >=20 >=20 > The Nimbus-JWT library started a month ago from code borrowed from=20 > Axel Nennker's + Co OpenInfoCard project and at this point covers=20 > fully plain and signed JWTs as well as JSON Web Keys (JWK). The JWE=20 > implementation still requires a bit of work to add HMAC integrity and=20 > cover the remaining elliptic curve and key-wrap encryption algorithms=20 > from the JWA spec. I would be very thankful if somebody could help me=20 > with that as I don't have much experience with cryptography :) >=20 > For the listing of the supported JWAs: > http://nimbusds.com/files/jwt/javadoc/com/nimbusds/jwt/JWA.html >=20 > Cheers, >=20 > Vladimir > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- M.Sc. Juraj Somorovsky Lehrstuhl f=FCr Netz- und Datensicherheit Ruhr Universit=E4t Bochum ----------------------------------- Universit=E4tsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From mamille2@cisco.com Thu Apr 5 05:50:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1A21F87F3 for ; Thu, 5 Apr 2012 05:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3d0MO+Pf+hT for ; Thu, 5 Apr 2012 05:50:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5C10221F86A8 for ; Thu, 5 Apr 2012 05:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=3657; q=dns/txt; s=iport; t=1333630200; x=1334839800; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mvql+pjdJegOO9hgj9EqVBC9LkxzDCYD1jH1oVFmYxE=; b=YbLrXvr1piOMTrnQWUNox5+L1QEgDknlfKQtWJ3Yuc8nOTcNxcVVN+82 wdq7T7g+6i7qb+j7L2SxKuhx6ja3lXBz+MKGdxjFYVpGiGS5JR5Z3DhTB 6YlAb3n7oi6U3pKJ4We6B+3VZbGGpnvhwKtiBkpfoIlsD7Ys+hc1QIXRq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOiTfU+rRDoG/2dsb2JhbABFuGyBB4IJAQEBAwEBAQEPASc0CwULCw4KLicwBhMih2cEAQubLZ93j3djBIhZjRKBEY06gWmDBg X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="36078899" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 05 Apr 2012 12:50:00 +0000 Received: from dhcp-64-101-72-208.cisco.com (dhcp-64-101-72-208.cisco.com [64.101.72.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q35Cnxvx019992; Thu, 5 Apr 2012 12:49:59 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matt Miller In-Reply-To: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> Date: Thu, 5 Apr 2012 06:49:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> To: John Bradley X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: Brian Campbell , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 12:50:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another way around the conditional in application-space is to define an = AEAD algorithm composed of an encryption and hashing function. This = seems like a reasonable place to start looking at one: < = http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. On Apr 4, 2012, at 17:42, John Bradley wrote: > The use of a single key across two functions is one of things that is = not provably without problems. >=20 > I agree that from an implementers point of view one key is simpler. >=20 > There is a related-key attack that using the same key would enable. = This can be combined with differential and linear attacks on symmetric = key cyphers. >=20 > Generally this can be thought of as a bad thing. >=20 > What is certain is that it increases the possible attack surface, and = if the is a problem discovered as we have seen with AES-CBC it is going = to be hard to change later. >=20 > We need key derivation anyway for ECDH-ES to produce a key of the = correct bit length. >=20 > Doing key derivation on CMK is the theoretically proper way to do it. > Making a simplification might bite us in the future. >=20 > I suppose one way to get around the conditional application argument = is to always use it to produce the CEK even with AEAD algorithms. >=20 > Regards > John B. >=20 > On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >=20 >> Hi all, >>=20 >> I was hoping someone could help me (hopefully it's not just me!) >> understand the reasons for the introduction of the key derivation >> stuff* into JWE draft -01? >>=20 >> I understand that it's there to derive the two keys, CEK and CIK, = from >> the CMK and that it is to be done when a non-AEAD algorithm is used = to >> encrypt the content. But what is the value of deriving the two keys = as >> apposed to using the CMK for both encryption and integrity? >>=20 >> Perhaps naively I assumed that using the CMK for both would be >> sufficient. It's randomly generated and used only for the one JWE. >> It's not clear to me what benefit is provided by the additional >> complexity of the derivation function as well as its conditional >> application (and the potential interoperability problems that come >> with such complexity). I assume there's some security benefit? But I >> can't see what it is. >>=20 >> Any help would be appreciated. >> Thanks, >> Brian >>=20 >> * = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 7 >> which is referenced by >> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 5 >> and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 6 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVqzQj YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR8kx c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvLy LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb+ ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fbY LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDGz/I=3D =3D174E -----END PGP SIGNATURE----- From vladimir@nimbusds.com Thu Apr 5 06:04:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0670E21F87FE for ; Thu, 5 Apr 2012 06:04:10 -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=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxAeazr1DpYs for ; Thu, 5 Apr 2012 06:04:09 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id BB4A321F87D8 for ; Thu, 5 Apr 2012 06:04:08 -0700 (PDT) Received: (qmail 20770 invoked from network); 5 Apr 2012 13:04:06 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 5 Apr 2012 13:03:59 -0000 Received: (qmail 26984 invoked by uid 99); 5 Apr 2012 13:03:59 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.76.96 User-Agent: Workspace Webmail 5.6.15 Message-Id: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: Axel.Nennker@telekom.de, juraj.somorovsky@rub.de Date: Thu, 05 Apr 2012 06:03:58 -0700 Mime-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 13:04:10 -0000 Hallo Berlin, hallo Bochum, hallo Welt! :)=0A=0AI just sent an email to a c= rypto expert at a partner company to ask for=0Ahis opinion is on that. My f= eeling is that when we collect sufficient=0Aopinions on that the "truth" wi= ll eventually emerge :)=0A=0AAs mentioned, I don't have a proper crypto bac= kground, so during=0Arefactoring I made sure Axel's code remained just as i= t was.=0A=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : v= ladimir@nimbusds.com=0A=0A=0A=0A=0A=0A-------- Original Message --------=0A= Subject: Re: [jose] JWT + JOSE for Java=0AFrom: = =0ADate: Thu, April 05, 2012 1:00 pm=0ATo: , =0ACc: jose@ietf.org=0A=0A=0AHi Juraj,=0A=0AAs Vladimir's= work is based on my implementation I guess that my=0Aimplementation has ro= om for improvement too.=0Ahttps://code.google.com/p/openinfocard/source/bro= wse/trunk/src/org/xmldap/json/WebToken.java=0A=0AENC_ALG_RSA_OAEP is better= than ENC_ALG_RSA1_5. =0Ahttps://code.google.com/p/openinfocard/source/brow= se/trunk/src/org/xmldap/json/WebToken.java#116=0A=0ABoth padding algorithms= are supported by my code and this RSA bulletin=0Amentions OAEP as one coun= ter measure against the Bleichenbacher attack.=0Aftp://ftp.rsasecurity.com/= pub/pdfs/bulletn7.pdf=0A=0ADoes "your" attack work against ENC_ALG_RSA_OAEP= too? Additional counter=0Ameasures suggestions are very welcome.=0A=0ARSA1= _5 is in the proposed standard because it is widely available=0Aalthough RS= A recommends to use OAEP for decades. =0AI think that RSA-OAEP should be ma= ndatory to implement and RSA1_5=0Adeprecated.=0A=0ACheers. Greetings from B= erlin to Bochum.=0AAxel=0A=0A=0A-----Original Message-----=0AFrom: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of=0AJuraj Somorovsk= y=0ASent: Thursday, April 05, 2012 1:13 AM=0ATo: vladimir@nimbusds.com=0ACc= : jose@ietf.org=0ASubject: Re: [jose] JWT + JOSE for Java=0A=0AHi Vladimir,= =0A=0AI have took a look at your implementation and found out, that your PK= CS1=0Ahandling is vulnerable to the Bleichenbacher attack (the adversary co= uld=0Abe able to issue different ciphertexts, send them to the server, and= =0Aaccording to its responses he could learn the encrypted CEK)=0A=0AI will= send you PoCs and instructions how to fix it by tomorrow...or=0Ajust take = a look at the document written by Eric Rescorla:=0Ahttp://www.ietf.org/rfc/= rfc3218.txt=0A=0ARegards=0AJuraj=0A=0AOn 04/03/2012 11:24 AM, Vladimir Dzhu= vinov / NimbusDS wrote:=0A> Today I reached a point in my JWT+JOSE library = implementation where I =0A> wouldn't feel ashamed to release it to the publ= ic :)=0A> =0A> https://github.com/NimbusDS/Nimbus-JWT=0A> =0A> The library = is fully documented:=0A> http://nimbusds.com/files/jwt/javadoc/index.html= =0A> =0A> =0A> The Nimbus-JWT library started a month ago from code borrowe= d from =0A> Axel Nennker's + Co OpenInfoCard project and at this point cove= rs =0A> fully plain and signed JWTs as well as JSON Web Keys (JWK). The JWE= =0A> implementation still requires a bit of work to add HMAC integrity and= =0A> cover the remaining elliptic curve and key-wrap encryption algorithms= =0A> from the JWA spec. I would be very thankful if somebody could help me= =0A> with that as I don't have much experience with cryptography :)=0A> = =0A> For the listing of the supported JWAs:=0A> http://nimbusds.com/files/j= wt/javadoc/com/nimbusds/jwt/JWA.html=0A> =0A> Cheers,=0A> =0A> Vladimir=0A>= --=0A> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A> = =0A> _______________________________________________=0A> jose mailing list= =0A> jose@ietf.org=0A> https://www.ietf.org/mailman/listinfo/jose=0A=0A--= =0AM.Sc. Juraj Somorovsky=0A=0ALehrstuhl f=C3=BCr Netz- und Datensicherheit= =0ARuhr Universit=C3=A4t Bochum=0A-----------------------------------=0AUni= versit=C3=A4tsstr. 150, Geb. ID 2/411=0AD-44780 Bochum=0A=0ATelefon: +49 (0= ) 234 / 32-26551=0AFax: +49 (0) 234 / 32-14347=0Ahttp://www.nds.rub.de=0A__= _____________________________________________=0Ajose mailing list=0Ajose@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/jose=0A_____________________= __________________________=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://ww= w.ietf.org/mailman/listinfo/jose=0A From vladimir@nimbusds.com Thu Apr 5 07:18:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D99421F8770 for ; Thu, 5 Apr 2012 07:18:05 -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=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEaHVzxhbTEF for ; Thu, 5 Apr 2012 07:18:04 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 0E6BD21F8769 for ; Thu, 5 Apr 2012 07:18:03 -0700 (PDT) Received: (qmail 15756 invoked from network); 5 Apr 2012 14:18:02 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 5 Apr 2012 14:17:59 -0000 Received: (qmail 16763 invoked by uid 99); 5 Apr 2012 14:17:59 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.76.96 User-Agent: Workspace Webmail 5.6.15 Message-Id: <20120405071758.cc40c4f3d92d2001859047cd8cabb9ab.b5b15f820c.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: Axel.Nennker@telekom.de, juraj.somorovsky@rub.de Date: Thu, 05 Apr 2012 07:17:58 -0700 Mime-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:18:05 -0000 +1 in favour of deprecating RSA1_5 in favour of OAEP.=0A=0AOn Thu, 2012-04-= 05 at 13:04 +0000, Mike Scott wrote:=0A> Hello Vladimir,=0A> =0A> I would r= ecommend OAEP. As I recall there were some obscure attacks on earlier propo= sals from RSA.=0A> =0A> Mike=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.co= m : vladimir@nimbusds.com=0A =0A=0A=0A=0A-------- Original Message --------= =0ASubject: Re: [jose] JWT + JOSE for Java=0AFrom: "Vladimir Dzhuvinov / Ni= mbusDS" =0ADate: Thu, April 05, 2012 2:03 pm=0ATo: A= xel.Nennker@telekom.de, juraj.somorovsky@rub.de=0ACc: jose@ietf.org=0A=0AHa= llo Berlin, hallo Bochum, hallo Welt! :)=0A=0AI just sent an email to a cry= pto expert at a partner company to ask for=0Ahis opinion is on that. My fee= ling is that when we collect sufficient=0Aopinions on that the "truth" will= eventually emerge :)=0A=0AAs mentioned, I don't have a proper crypto backg= round, so during=0Arefactoring I made sure Axel's code remained just as it = was.=0A=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vla= dimir@nimbusds.com=0A=0A=0A=0A=0A=0A-------- Original Message --------=0ASu= bject: Re: [jose] JWT + JOSE for Java=0AFrom: =0AD= ate: Thu, April 05, 2012 1:00 pm=0ATo: , =0ACc: jose@ietf.org=0A=0A=0AHi Juraj,=0A=0AAs Vladimir's wor= k is based on my implementation I guess that my=0Aimplementation has room f= or improvement too.=0Ahttps://code.google.com/p/openinfocard/source/browse/= trunk/src/org/xmldap/json/WebToken.java=0A=0AENC_ALG_RSA_OAEP is better tha= n ENC_ALG_RSA1_5. =0Ahttps://code.google.com/p/openinfocard/source/browse/t= runk/src/org/xmldap/json/WebToken.java#116=0A=0ABoth padding algorithms are= supported by my code and this RSA bulletin=0Amentions OAEP as one counter = measure against the Bleichenbacher attack.=0Aftp://ftp.rsasecurity.com/pub/= pdfs/bulletn7.pdf=0A=0ADoes "your" attack work against ENC_ALG_RSA_OAEP too= ? Additional counter=0Ameasures suggestions are very welcome.=0A=0ARSA1_5 i= s in the proposed standard because it is widely available=0Aalthough RSA re= commends to use OAEP for decades. =0AI think that RSA-OAEP should be mandat= ory to implement and RSA1_5=0Adeprecated.=0A=0ACheers. Greetings from Berli= n to Bochum.=0AAxel=0A=0A=0A-----Original Message-----=0AFrom: jose-bounces= @ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of=0AJuraj Somorovsky=0A= Sent: Thursday, April 05, 2012 1:13 AM=0ATo: vladimir@nimbusds.com=0ACc: jo= se@ietf.org=0ASubject: Re: [jose] JWT + JOSE for Java=0A=0AHi Vladimir,=0A= =0AI have took a look at your implementation and found out, that your PKCS1= =0Ahandling is vulnerable to the Bleichenbacher attack (the adversary could= =0Abe able to issue different ciphertexts, send them to the server, and=0Aa= ccording to its responses he could learn the encrypted CEK)=0A=0AI will sen= d you PoCs and instructions how to fix it by tomorrow...or=0Ajust take a lo= ok at the document written by Eric Rescorla:=0Ahttp://www.ietf.org/rfc/rfc3= 218.txt=0A=0ARegards=0AJuraj=0A=0AOn 04/03/2012 11:24 AM, Vladimir Dzhuvino= v / NimbusDS wrote:=0A> Today I reached a point in my JWT+JOSE library impl= ementation where I =0A> wouldn't feel ashamed to release it to the public := )=0A> =0A> https://github.com/NimbusDS/Nimbus-JWT=0A> =0A> The library is f= ully documented:=0A> http://nimbusds.com/files/jwt/javadoc/index.html=0A> = =0A> =0A> The Nimbus-JWT library started a month ago from code borrowed fro= m =0A> Axel Nennker's + Co OpenInfoCard project and at this point covers = =0A> fully plain and signed JWTs as well as JSON Web Keys (JWK). The JWE = =0A> implementation still requires a bit of work to add HMAC integrity and = =0A> cover the remaining elliptic curve and key-wrap encryption algorithms = =0A> from the JWA spec. I would be very thankful if somebody could help me = =0A> with that as I don't have much experience with cryptography :)=0A> =0A= > For the listing of the supported JWAs:=0A> http://nimbusds.com/files/jwt/= javadoc/com/nimbusds/jwt/JWA.html=0A> =0A> Cheers,=0A> =0A> Vladimir=0A> --= =0A> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A> =0A>= _______________________________________________=0A> jose mailing list=0A> = jose@ietf.org=0A> https://www.ietf.org/mailman/listinfo/jose=0A=0A--=0AM.Sc= . Juraj Somorovsky=0A=0ALehrstuhl f=C3=BCr Netz- und Datensicherheit=0ARuhr= Universit=C3=A4t Bochum=0A-----------------------------------=0AUniversit= =C3=A4tsstr. 150, Geb. ID 2/411=0AD-44780 Bochum=0A=0ATelefon: +49 (0) 234 = / 32-26551=0AFax: +49 (0) 234 / 32-14347=0Ahttp://www.nds.rub.de=0A________= _______________________________________=0Ajose mailing list=0Ajose@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/jose=0A___________________________= ____________________=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://www.ietf= .org/mailman/listinfo/jose=0A=0A___________________________________________= ____=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://www.ietf.org/mailman/lis= tinfo/jose=0A From ve7jtb@ve7jtb.com Thu Apr 5 07:28:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F323121F853E for ; Thu, 5 Apr 2012 07:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLvTApOsiuPR for ; Thu, 5 Apr 2012 07:28:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E156221F853D for ; Thu, 5 Apr 2012 07:28:36 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so687478vcb.31 for ; Thu, 05 Apr 2012 07:28:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=HEWDIcBKWJXnh3CEQRscXkJATATlTPx6My/J3VghByg=; b=Oh2UC490XOX+PxbLl+tBeCluDIp9EAiDLLbrew8h/LdQuDo3XsMHvVOeZuiWuuL5q/ koJg7pA+/vu85+ppbznjWJYQikQ21/GIzWo9iPO7AHM2p0HEWe3Y8geaf/jbzpGmkL8V vMibmp8rfmQTckNzDthVVHVd6LxC0DqQ6/svaHcgKUgVTk5FRHzf7H/g1znEMF9j1ZvF vBQLAx5IbM6bvh+gSowMwEpTUz8sscg4+DsWw1Yp98Dl5Oyx1PMHeaM0KEU/yswS5U6o sC7kXet9TK2hCTrXQfH7fqs7FSJ35vS3T+1TDgG8waM7htKzMGbgPvMaj0BcLckPUTg6 tpRw== Received: by 10.52.73.102 with SMTP id k6mr1665654vdv.57.1333636116350; Thu, 05 Apr 2012 07:28:36 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id jz16sm4536471vdb.9.2012.04.05.07.28.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 07:28:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_BAAF2983-4884-4500-A1AC-C79E06C073C6"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> Date: Thu, 5 Apr 2012 11:28:18 -0300 Message-Id: <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmtN81yQyzDZZla7jq8XBI8keeGEIIaO4YJsTnV8UGN8f/VcRv4WE5b2R/n/53kqsYxmmBy Cc: Brian Campbell , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:28:38 -0000 --Apple-Mail=_BAAF2983-4884-4500-A1AC-C79E06C073C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A couple of observations. The current proposal provides integrity over the header, a new AEAD alg = doesn't do that. Low level crypto is a challenge. Re-using standard underlying = algorithms like HMAC and AES-CBC allow for JS and other libs to call = standard lower level crypto functions. I am not against having another AEAD alg, but want to help people = understand the current design choice. John B. On 2012-04-05, at 9:49 AM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Another way around the conditional in application-space is to define = an AEAD algorithm composed of an encryption and hashing function. This = seems like a reasonable place to start looking at one: < = http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. >=20 > On Apr 4, 2012, at 17:42, John Bradley wrote: >=20 >> The use of a single key across two functions is one of things that is = not provably without problems. >>=20 >> I agree that from an implementers point of view one key is simpler. >>=20 >> There is a related-key attack that using the same key would enable. = This can be combined with differential and linear attacks on symmetric = key cyphers. >>=20 >> Generally this can be thought of as a bad thing. >>=20 >> What is certain is that it increases the possible attack surface, = and if the is a problem discovered as we have seen with AES-CBC it is = going to be hard to change later. >>=20 >> We need key derivation anyway for ECDH-ES to produce a key of the = correct bit length. >>=20 >> Doing key derivation on CMK is the theoretically proper way to do it. >> Making a simplification might bite us in the future. >>=20 >> I suppose one way to get around the conditional application argument = is to always use it to produce the CEK even with AEAD algorithms. >>=20 >> Regards >> John B. >>=20 >> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>=20 >>> Hi all, >>>=20 >>> I was hoping someone could help me (hopefully it's not just me!) >>> understand the reasons for the introduction of the key derivation >>> stuff* into JWE draft -01? >>>=20 >>> I understand that it's there to derive the two keys, CEK and CIK, = from >>> the CMK and that it is to be done when a non-AEAD algorithm is used = to >>> encrypt the content. But what is the value of deriving the two keys = as >>> apposed to using the CMK for both encryption and integrity? >>>=20 >>> Perhaps naively I assumed that using the CMK for both would be >>> sufficient. It's randomly generated and used only for the one JWE. >>> It's not clear to me what benefit is provided by the additional >>> complexity of the derivation function as well as its conditional >>> application (and the potential interoperability problems that come >>> with such complexity). I assume there's some security benefit? But I >>> can't see what it is. >>>=20 >>> Any help would be appreciated. >>> Thanks, >>> Brian >>>=20 >>> * = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 7 >>> which is referenced by >>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 5 >>> and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 6 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > - - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVqzQj > YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR8kx > c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvLy > LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb+ > ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fbY > LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDGz/I=3D > =3D174E > -----END PGP SIGNATURE----- --Apple-Mail=_BAAF2983-4884-4500-A1AC-C79E06C073C6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NTE0MjgxOVowIwYJKoZIhvcNAQkEMRYEFO+jXfYUXfrrRNNb35Ag5MYEFSVKMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJwAtReg2/l4v5T4FwPVKWv3szw3PQOmzkY7LxRwjqWv1BldyO0WPkygIwEVZLJEDyVW68Pxwmov W/Yzm7sC2uecSUDqZsNYpAagsuSmqmLYi4s4Z2rTRHStSz5BG8l0LxrdkY2BDHbR7r4in/dTFoWy 7re2NCAOdpGSvrhDnW12dMQHiwZCf9UQM5Y5QTzIKFsXb1tIblUt7bHgQsywy3yY9eCNA1mftYY5 usiSI5H2fJXmuRcap4FDWA+WEA2IJAHdbrQVGYziuqaK2YIKGjpOrqHWFxsmeJ1mtkMx14ElWou8 oASKAAyyBKv94sbRFKQ+7+hqJ0Peo2EcRyx1FZUAAAAAAAA= --Apple-Mail=_BAAF2983-4884-4500-A1AC-C79E06C073C6-- From mamille2@cisco.com Thu Apr 5 07:51:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A321F86C6 for ; Thu, 5 Apr 2012 07:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Jcbjkm8184 for ; Thu, 5 Apr 2012 07:51:01 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 485A521F86BE for ; Thu, 5 Apr 2012 07:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4827; q=dns/txt; s=iport; t=1333637455; x=1334847055; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=a/Q6fG7Avngfv7McY/JPHyEM0JhwdXfFgE7Ahh2K+Q4=; b=g7Bm+LaBUeMZ4avRsX9lrWjpwPaMPH7k/EGwSgXimmZUIDLCFJ6rIG1P zz442FtMtTDa86npBK2C4fm4YoAEI0W0Q3DQJVsoPclwPaYy1EK96WvKa ZbH/eqgVUcv5Fm+y9PcyvCX3BVIN4hfVM6kaB1mNzIz0YxTgBfWCGLl/5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEKwfU+rRDoH/2dsb2JhbABDuHaBB4IJAQEBAwEBAQEPASc0CwULCw4KLicwBhMih2cEAQufQpgVj3djBIhZjRKBEY06gWmDBg X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="39209049" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 05 Apr 2012 14:50:54 +0000 Received: from dhcp-64-101-72-208.cisco.com (dhcp-64-101-72-208.cisco.com [64.101.72.208]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q35EorfL024926; Thu, 5 Apr 2012 14:50:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matt Miller In-Reply-To: <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> Date: Thu, 5 Apr 2012 08:50:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> To: John Bradley X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: Brian Campbell , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:51:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 5, 2012, at 08:28, John Bradley wrote: > A couple of observations. >=20 > The current proposal provides integrity over the header, a new AEAD = alg doesn't do that. The current proposal does not provide this for existing AEAD algorithms.=20= > Low level crypto is a challenge. Re-using standard underlying = algorithms like HMAC and AES-CBC allow for JS and other libs to call = standard lower level crypto functions. >=20 The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and = HMAC-SHA-256); it's not any more low-level than the non-AEAD path = specified in JWE. > I am not against having another AEAD alg, but want to help people = understand the current design choice. >=20 The benefit is to have a single path through the use of algorithms. It = puts the differences into the algorithm implementations, which is where = they should be. > John B. > On 2012-04-05, at 9:49 AM, Matt Miller wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Another way around the conditional in application-space is to define = an AEAD algorithm composed of an encryption and hashing function. This = seems like a reasonable place to start looking at one: < = http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. >>=20 >> On Apr 4, 2012, at 17:42, John Bradley wrote: >>=20 >>> The use of a single key across two functions is one of things that = is not provably without problems. >>>=20 >>> I agree that from an implementers point of view one key is simpler. >>>=20 >>> There is a related-key attack that using the same key would enable. = This can be combined with differential and linear attacks on symmetric = key cyphers. >>>=20 >>> Generally this can be thought of as a bad thing. >>>=20 >>> What is certain is that it increases the possible attack surface, = and if the is a problem discovered as we have seen with AES-CBC it is = going to be hard to change later. >>>=20 >>> We need key derivation anyway for ECDH-ES to produce a key of the = correct bit length. >>>=20 >>> Doing key derivation on CMK is the theoretically proper way to do = it. >>> Making a simplification might bite us in the future. >>>=20 >>> I suppose one way to get around the conditional application argument = is to always use it to produce the CEK even with AEAD algorithms. >>>=20 >>> Regards >>> John B. >>>=20 >>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I was hoping someone could help me (hopefully it's not just me!) >>>> understand the reasons for the introduction of the key derivation >>>> stuff* into JWE draft -01? >>>>=20 >>>> I understand that it's there to derive the two keys, CEK and CIK, = from >>>> the CMK and that it is to be done when a non-AEAD algorithm is used = to >>>> encrypt the content. But what is the value of deriving the two keys = as >>>> apposed to using the CMK for both encryption and integrity? >>>>=20 >>>> Perhaps naively I assumed that using the CMK for both would be >>>> sufficient. It's randomly generated and used only for the one JWE. >>>> It's not clear to me what benefit is provided by the additional >>>> complexity of the derivation function as well as its conditional >>>> application (and the potential interoperability problems that come >>>> with such complexity). I assume there's some security benefit? But = I >>>> can't see what it is. >>>>=20 >>>> Any help would be appreciated. >>>> Thanks, >>>> Brian >>>>=20 >>>> * = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 7 >>>> which is referenced by >>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 5 >>>> and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 6 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPfbFOAAoJEJq6Ou0cgrSPPSAH/jyPOD3BKP/bYlq5fh2N+J/l 63kyL3oo+wN++Ifm1TF+6d5DYD3OIht7HrzcJsek8haEEeUVgjFaDqJNQmbPmX4I x4n8AZedPMq37a13k35r25OefqtNgfctVPowDAXlWDRUXvpqKB8yfTNDcCJNvAVh i8PEKO3EUeYGGehVLMWfZ61zupxGbS3p4PBV4SuIlQFYAeVDjlXLorxt6JKMu0H9 ZKGkSaHhXR8SprMEoASAWXD/PzJhXbLka3dAGxOiFL8YBGb0ei/Fxt+LdlATSpa7 Jq4FrURTG6RzJDgOX5Mi6AFL4ke/GVinksz5SXwrMe9i74bt+8LYjptvGYWKPiw=3D =3D1hMy -----END PGP SIGNATURE----- From ve7jtb@ve7jtb.com Thu Apr 5 07:51:46 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB9021F86C3 for ; Thu, 5 Apr 2012 07:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ+-nk+aifbp for ; Thu, 5 Apr 2012 07:51:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 967E121F86C2 for ; Thu, 5 Apr 2012 07:51:43 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so706042vcb.31 for ; Thu, 05 Apr 2012 07:51:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4xNdx+NdjCIINUbHK5r0RFE6f3FqTQxmSvY/jeClwHk=; b=I+UsnDt+lbJ38wWjYQO9Z8NI8g41mI2ozsUTTYzO1sUM1q8GDj+I6IwPxJJAkjZDT7 uYn0cubrYCDqLZYC7fFsEz1ts/LBkVE0jH8nHFDePYEAMwPUN+FpAbGJ00WbQr0E6ME6 30Rx0C4pykBmpgfU3xeLgMWojPpNFN6FESJOv7gGO9HHm+cQeAjHkuJVWU6KGV7aEo4G B3mc2CBSchdTR7O3r+HZIAjvismnMpP40jVVWb7lMS8dISX6tTMnmvr5FYqxhxg73ezv 0wUFzksvxphBBgFwiNwG8F/PdehBSyhHWjXcrCOvKeNm9bcrymvlcx3N0C/12z3d/Xl2 V3BQ== Received: by 10.52.28.178 with SMTP id c18mr1715063vdh.45.1333637503132; Thu, 05 Apr 2012 07:51:43 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id cp2sm4599313vdb.3.2012.04.05.07.51.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 07:51:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_CAA4BB4E-5537-4792-B192-4415725EA78C"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <20120405071758.cc40c4f3d92d2001859047cd8cabb9ab.b5b15f820c.wbe@email07.europe.secureserver.net> Date: Thu, 5 Apr 2012 11:51:06 -0300 Message-Id: References: <20120405071758.cc40c4f3d92d2001859047cd8cabb9ab.b5b15f820c.wbe@email07.europe.secureserver.net> To: "Vladimir Dzhuvinov / NimbusDS" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkp55xAxfkwG22QjK9qIH8Um+zHQAMhlY/NellKvgXBnQbbsYQxGZ+Ok6mjrm7Wus9rELJB Cc: jose@ietf.org, Axel.Nennker@telekom.de, juraj.somorovsky@rub.de Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:51:46 -0000 --Apple-Mail=_CAA4BB4E-5537-4792-B192-4415725EA78C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have been pro OAEP for a long time. I think we had OAEP as the = default in the earlier JSS spec. The question always comes back to deployability. PKCS#1_5 is available = more places. I am interested in peoples opinions especialy developers and library = people. John B. On 2012-04-05, at 11:17 AM, Vladimir Dzhuvinov / NimbusDS wrote: > +1 in favour of deprecating RSA1_5 in favour of OAEP. >=20 > On Thu, 2012-04-05 at 13:04 +0000, Mike Scott wrote: >> Hello Vladimir, >>=20 >> I would recommend OAEP. As I recall there were some obscure attacks = on earlier proposals from RSA. >>=20 >> Mike >=20 > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >=20 >=20 >=20 >=20 > -------- Original Message -------- > Subject: Re: [jose] JWT + JOSE for Java > From: "Vladimir Dzhuvinov / NimbusDS" > Date: Thu, April 05, 2012 2:03 pm > To: Axel.Nennker@telekom.de, juraj.somorovsky@rub.de > Cc: jose@ietf.org >=20 > Hallo Berlin, hallo Bochum, hallo Welt! :) >=20 > I just sent an email to a crypto expert at a partner company to ask = for > his opinion is on that. My feeling is that when we collect sufficient > opinions on that the "truth" will eventually emerge :) >=20 > As mentioned, I don't have a proper crypto background, so during > refactoring I made sure Axel's code remained just as it was. >=20 >=20 > Vladimir >=20 > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >=20 >=20 >=20 >=20 >=20 > -------- Original Message -------- > Subject: Re: [jose] JWT + JOSE for Java > From: > Date: Thu, April 05, 2012 1:00 pm > To: , > Cc: jose@ietf.org >=20 >=20 > Hi Juraj, >=20 > As Vladimir's work is based on my implementation I guess that my > implementation has room for improvement too. > = https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/= json/WebToken.java >=20 > ENC_ALG_RSA_OAEP is better than ENC_ALG_RSA1_5.=20 > = https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/= json/WebToken.java#116 >=20 > Both padding algorithms are supported by my code and this RSA bulletin > mentions OAEP as one counter measure against the Bleichenbacher = attack. > ftp://ftp.rsasecurity.com/pub/pdfs/bulletn7.pdf >=20 > Does "your" attack work against ENC_ALG_RSA_OAEP too? Additional = counter > measures suggestions are very welcome. >=20 > RSA1_5 is in the proposed standard because it is widely available > although RSA recommends to use OAEP for decades.=20 > I think that RSA-OAEP should be mandatory to implement and RSA1_5 > deprecated. >=20 > Cheers. Greetings from Berlin to Bochum. > Axel >=20 >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > Juraj Somorovsky > Sent: Thursday, April 05, 2012 1:13 AM > To: vladimir@nimbusds.com > Cc: jose@ietf.org > Subject: Re: [jose] JWT + JOSE for Java >=20 > Hi Vladimir, >=20 > I have took a look at your implementation and found out, that your = PKCS1 > handling is vulnerable to the Bleichenbacher attack (the adversary = could > be able to issue different ciphertexts, send them to the server, and > according to its responses he could learn the encrypted CEK) >=20 > I will send you PoCs and instructions how to fix it by tomorrow...or > just take a look at the document written by Eric Rescorla: > http://www.ietf.org/rfc/rfc3218.txt >=20 > Regards > Juraj >=20 > On 04/03/2012 11:24 AM, Vladimir Dzhuvinov / NimbusDS wrote: >> Today I reached a point in my JWT+JOSE library implementation where I=20= >> wouldn't feel ashamed to release it to the public :) >>=20 >> https://github.com/NimbusDS/Nimbus-JWT >>=20 >> The library is fully documented: >> http://nimbusds.com/files/jwt/javadoc/index.html >>=20 >>=20 >> The Nimbus-JWT library started a month ago from code borrowed from=20 >> Axel Nennker's + Co OpenInfoCard project and at this point covers=20 >> fully plain and signed JWTs as well as JSON Web Keys (JWK). The JWE=20= >> implementation still requires a bit of work to add HMAC integrity and=20= >> cover the remaining elliptic curve and key-wrap encryption algorithms=20= >> from the JWA spec. I would be very thankful if somebody could help me=20= >> with that as I don't have much experience with cryptography :) >>=20 >> For the listing of the supported JWAs: >> http://nimbusds.com/files/jwt/javadoc/com/nimbusds/jwt/JWA.html >>=20 >> Cheers, >>=20 >> Vladimir >> -- >> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > -- > M.Sc. Juraj Somorovsky >=20 > Lehrstuhl f=FCr Netz- und Datensicherheit > Ruhr Universit=E4t Bochum > ----------------------------------- > Universit=E4tsstr. 150, Geb. ID 2/411 > D-44780 Bochum >=20 > Telefon: +49 (0) 234 / 32-26551 > Fax: +49 (0) 234 / 32-14347 > http://www.nds.rub.de > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_CAA4BB4E-5537-4792-B192-4415725EA78C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NTE0NTEwN1owIwYJKoZIhvcNAQkEMRYEFJUq7nKK3k+NlpERpTRozbw11urOMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABmM6HaCkpXAcH8y/wBkzmWCu3qmoGsxK/CdUJndIhPV4oXf4SU+1wg9flCUkQtGGhi7vM66i3fK BJLGfMLfKlC3gxNWv/talu1jZHwgZHGI88Q20SUKv2jUEGkZj9gFt4W30H/WDSbWilgq6nFEm5v4 qK+XVHImantyFpUHsAXjEu8jKKWtubnrBPSKhz36mgBftZTq1F+noItOAEWckTrs/NNaIV12h6Rj cdzyt7+L8EcGzZqenJvxCCJCwlQcxJvkKm2qjzkPwogjir+M5zQu887/IjCLeaB1R/41Kp0VIT21 CNVfO7YpMs0Tyxg41VESM/pIz5kA/v8MSM1XJ8UAAAAAAAA= --Apple-Mail=_CAA4BB4E-5537-4792-B192-4415725EA78C-- From Michael.Jones@microsoft.com Thu Apr 5 08:08:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9C21F8618 for ; Thu, 5 Apr 2012 08:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ9Tj978TCf9 for ; Thu, 5 Apr 2012 08:08:01 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4615821F85A2 for ; Thu, 5 Apr 2012 08:08:01 -0700 (PDT) Received: from mail160-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 15:08:00 +0000 Received: from mail160-ch1 (localhost [127.0.0.1]) by mail160-ch1-R.bigfish.com (Postfix) with ESMTP id 423F624048B; Thu, 5 Apr 2012 15:08:00 +0000 (UTC) X-SpamScore: -31 X-BigFish: VS-31(zz9371I542M1447Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail160-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail160-ch1 (localhost.localdomain [127.0.0.1]) by mail160-ch1 (MessageSwitch) id 1333638479168229_3284; Thu, 5 Apr 2012 15:07:59 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail160-ch1.bigfish.com (Postfix) with ESMTP id 1EAA34C005B; Thu, 5 Apr 2012 15:07:59 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 15:07:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Thu, 5 Apr 2012 15:07:29 +0000 From: Mike Jones To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" Thread-Topic: [jose] JWE and the Initialisation Vector (iv) Thread-Index: AQHNEXnQAz5+sojiVE+/NzMulflYkZaMWG4w Date: Thu, 5 Apr 2012 15:07:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436645B05C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120403021130.cc40c4f3d92d2001859047cd8cabb9ab.5dd95571f3.wbe@email07.europe.secureserver.net> In-Reply-To: <20120403021130.cc40c4f3d92d2001859047cd8cabb9ab.5dd95571f3.wbe@email07.europe.secureserver.net> 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-OriginatorOrg: microsoft.com Subject: Re: [jose] JWE and the Initialisation Vector (iv) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:08:02 -0000 Yes, the language about "prepended" is in error, and will be removed in the= next draft. Thanks for the comments based upon your implementation work! -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Vla= dimir Dzhuvinov / NimbusDS Sent: Tuesday, April 03, 2012 2:12 AM To: jose@ietf.org Subject: [jose] JWE and the Initialisation Vector (iv) Hi guys, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-8= .2 says "for GCM, the random 64-bit IV is prepended to the ciphertext." Isn't the JWE "iv" header parameter meant to store the IV bytes? Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Thu Apr 5 08:12:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FB221F871C for ; Thu, 5 Apr 2012 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4YoJ+7p9f-K for ; Thu, 5 Apr 2012 08:12:13 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFF721F8716 for ; Thu, 5 Apr 2012 08:12:13 -0700 (PDT) Received: by ggmi1 with SMTP id i1so841902ggm.31 for ; Thu, 05 Apr 2012 08:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Jqe95oqx4273FVvrSe7DHlueTowTvDJBOuIW87fDWes=; b=SMvfEi4LJ6bMR+ez7HcVSR5ai8T5nLKZPuAEoJqaRQnGG+hPyKneEZKSPuLh9hWeDe Oq+36XG+6V44zjGM46y3oOg23VKeny9tO7ToWWJAy8G5CcYHzePOVFdrQUWPl53avX2E xMsooLr3DB4zp4i9UgnWRwo+mirOcY6/75uFvJoNJwuEC+uQLpmUgSjuPQWnAgpnA1HR qLMfQX4fsr2G7Daqp1kWKmwNxZw3F6CK9+PUGLR3YIa76EvD4ArZJX6VOEAdwLQ/DLmA 89dVmJPVSkmRtA5UBvNzFjSi/Q0CnscLOmiq6y3rUEs5fZ4erFrzfyGMec3hPaJGTYs4 A3RA== Received: by 10.236.170.70 with SMTP id o46mr2451836yhl.122.1333638733141; Thu, 05 Apr 2012 08:12:13 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id x10sm16100502yhm.12.2012.04.05.08.12.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:12:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_CADF6201-46DD-4B81-BF16-754F72153944"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> Date: Thu, 5 Apr 2012 12:12:05 -0300 Message-Id: <4CD31FEA-9079-4964-A943-1AD6C69BAF92@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl8XHxy4gB299INMOl4Tuc8j2adxfjGCph7HyW960ENG23LXLWO3fWUUp913PGDJPKqEHjf Cc: Brian Campbell , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:12:14 -0000 --Apple-Mail=_CADF6201-46DD-4B81-BF16-754F72153944 Content-Type: multipart/alternative; boundary="Apple-Mail=_60A5F776-08BB-48BB-97B3-485DD8B6A225" --Apple-Mail=_60A5F776-08BB-48BB-97B3-485DD8B6A225 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-04-05, at 11:50 AM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On Apr 5, 2012, at 08:28, John Bradley wrote: >=20 >> A couple of observations. >>=20 >> The current proposal provides integrity over the header, a new AEAD = alg doesn't do that. >=20 > The current proposal does not provide this for existing AEAD = algorithms.=20 True that is an advantage the composite CBC + HMAC has over GCM. >=20 >> Low level crypto is a challenge. Re-using standard underlying = algorithms like HMAC and AES-CBC allow for JS and other libs to call = standard lower level crypto functions. >>=20 >=20 > The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and = HMAC-SHA-256); it's not any more low-level than the non-AEAD path = specified in JWE. I will have another look at it. >=20 >> I am not against having another AEAD alg, but want to help people = understand the current design choice. >>=20 >=20 > The benefit is to have a single path through the use of algorithms. = It puts the differences into the algorithm implementations, which is = where they should be. >=20 There is no AES-CBC option without HMAC. Perhaps we should net be = calling it AES-CBC in JWA. John B. >> John B. >> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>=20 --Apple-Mail=_60A5F776-08BB-48BB-97B3-485DD8B6A225 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1


On Apr 5, 2012, at 08:28, John Bradley = wrote:

A couple of = observations.

The current = proposal provides integrity over the header,  a new AEAD alg = doesn't do that.

The current proposal does not = provide this for existing AEAD algorithms. =

True that is an advantage the = composite CBC + HMAC has over GCM.


Low level crypto is a = challenge.   Re-using standard underlying algorithms like HMAC = and AES-CBC allow for JS and other libs to call standard lower level = crypto functions.


The draft I noted uses AES-CBC-128 = and HMAC-SHA1 (or AES-CBC-256 and HMAC-SHA-256); it's not any more = low-level than the non-AEAD path specified in = JWE.

I will have another look at = it.

I am = not against having another AEAD alg,  but want to help people = understand the current design choice.


The benefit is to have a single path = through the use of algorithms.  It puts the differences into the = algorithm implementations, which is where they should = be.

There is no AES-CBC option without = HMAC.  Perhaps we should net be calling it AES-CBC in = JWA.

John B.

John = B.
On 2012-04-05, at 9:49 AM, = Matt Miller wrote:


= --Apple-Mail=_60A5F776-08BB-48BB-97B3-485DD8B6A225-- --Apple-Mail=_CADF6201-46DD-4B81-BF16-754F72153944 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NTE1MTIwNVowIwYJKoZIhvcNAQkEMRYEFOXDdm5oX1RHO6BIYhzOCXwburddMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABxRyOtIYFxlMnI7+zcmIHn4bAZbEB/4B+7fLJmEckXhZc/5xtfKDf4KuInRYIl8qvpJxuEjqIEM MUvFQDGx8S5R7HqlLZ54qLvp/BsSDMUoP21lc4he0W79A9hGEBRgtWKbwQ2RSNe/EWsZhST3Ppz2 bWIrshNxE7Cyfb3cYMXnwCf6+1Q0YpY06aqipzjNEh6ehVf7P5gYl15YCpctZErG0Bq+GxMPSP0e tckx/ShleiKAQJ7rd44YkECHM7PSaprzx/zQrN8EGFT6X8lHMdD+eX6f/z2NDEiitl4WkBWlSHek h4V+iuwKHxoBwS76jBh+wosq3pcYe6ulb6aaLNEAAAAAAAA= --Apple-Mail=_CADF6201-46DD-4B81-BF16-754F72153944-- From juraj.somorovsky@rub.de Thu Apr 5 08:29:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AF721F86D8 for ; Thu, 5 Apr 2012 08:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M05RB1KeN9Sp for ; Thu, 5 Apr 2012 08:29:42 -0700 (PDT) Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id 193C521F86D3 for ; Thu, 5 Apr 2012 08:29:41 -0700 (PDT) X-Queued: (qmail 8788 invoked by alias); 5 Apr 2012 15:29:41 -0000 X-Queued: (qmail 8775 invoked from network); 5 Apr 2012 15:29:40 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx6.rz.ruhr-uni-bochum.de with SMTP; 5 Apr 2012 15:29:40 -0000 X-Queued: (qmail 10128 invoked by uid 281); 5 Apr 2012 15:29:40 -0000 X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUxYjUvpkaF/yQ==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.29/4.75. Clear:RC:1(134.147.40.78):. Processed in 0.038314 secs); 05 Apr 2012 15:29:40 -0000 Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUxYjUvpkaF/yQ==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 5 Apr 2012 15:29:40 -0000 Date: 5 Apr 2012 17:29:39 +0200 Message-ID: <4F7DBA63.3020503@rub.de> From: "Juraj Somorovsky" To: "Vladimir Dzhuvinov / NimbusDS" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> In-Reply-To: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: jose@ietf.org, Axel.Nennker@telekom.de Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:29:43 -0000 Hi :) ok, I'll try to explain the Bleichenbacher attack in few sentences... If you construct your ciphertext using PKCS1, you take your symmetric key CEK and you padd it with some bytes to achieve a given message length... it looks like this: 0x00 0x02 ... random bytes (except for 0x00) ... 0x00 CEK You can encrypt this message using the server's public key. On the decryptor's side, the server tries to extract CEK. It decrypts the message using its RSA private key and *checks the message padding format* (0x00 0x02 ... 0x00 CEK). Afterwards, it takes CEK. The problem is: if the server responds differently according to the PKCS1 padding validity, the attacker can learn some bits of the plaintext. By sending a huge amount of messages (about 1,000,000 or more...this depends on the server message check and the transmitted message), he can learn the secured CEK and thus decrypt the whole message. When looking at both your codes, I see two problems: case RSA1_5: Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding"); cipher.init(Cipher.DECRYPT_MODE, rsaPrivateKey); // this way, you throw an exception everytime you get invalid PKCS1 message. Your framework says e.g.: com.nimbusds.jwt.JWEException: Couldn't decrypt: unknown block type if the decrypted message does not start with 0x00 0x02 or it says com.nimbusds.jwt.JWEException: Couldn't decrypt: no data in block if the decrypted message does not contain any 0x00 in the middle byte[] secretKeyBytes1 = cipher.doFinal(encryptedKey.decode()); if (8* secretKeyBytes1.length != keylength) { // this throws something like com.nimbusds.jwt.JWEException: Couldn't decrypt: WebToken.decrypt RSA PKCS1Padding symmetric key length mismatch: 48 != 256 which gives the attacker again the possibility to distinguish between valid and invalid messages throw new Exception("WebToken.decrypt RSA PKCS1Padding symmetric key length mismatch: " + secretKeyBytes1.length + " != " + keylength); } keySpec = new SecretKeySpec(secretKeyBytes1, symmetricAlgorithm); break; Responding with a generalized error message also does not help completely as the attacker could observe the response time of the server. Namely, valid PKCS1 messages bring a CEK, which is then used for data decryption (AES-CBC, AES-GCM...). Invalid PKCS1 messages return a fault response directly, without data decryption. This offers a nice timing side-channel. Please note that the attacker can force the server to process arbitrarily data (also e.g. 1MB), so the attack could become practical also over the Internet (tested in similar scenario with XML Encryption :) ) Ok, so additionally to the same error messages, you should also consider timing and thus regenerate a symmetric key CEK every time, it was incorrectly decrypted (this way all the invalid PKCS1 ciphertexts will be processed, CEK generated, and the MAC validation will fail), something like this: case RSA1_5: // initialize somewhere SecureRandom (e.g. in your JWE constructor) // SecureRandom random = SecureRandom.getInstance("SHA1PRNG") Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding"); cipher.init(Cipher.DECRYPT_MODE, rsaPrivateKey); byte[] secretKeyBytes1 = null; try { secretKeyBytes1 = cipher.doFinal(encryptedKey.decode()); } catch(BadPaddingException e) { // regenerate key if the PKCS1 padding is incorrect secretKeyBytes1 = new byte[keylength / 8]; random.nextBytes(secretKeyBytes1); } if (8* secretKeyBytes1.length != keylength) { // regenerate key if the length is incorrect secretKeyBytes1 = new byte[keylength / 8]; random.nextBytes(secretKeyBytes1); } keySpec = new SecretKeySpec(secretKeyBytes1, symmetricAlgorithm); break; I hope this will thwart the attack... We have already tried to convince the standard developers to exclude PKCS1 from the standard: http://www.mail-archive.com/jose@ietf.org/msg00075.html ...it did not work. RSA-OAEP is the good choice for JOSE as PKCS1 will cause similar problems also for other developers. Regards from Bochum Juraj On 04/05/2012 03:03 PM, Vladimir Dzhuvinov / NimbusDS wrote: > Hallo Berlin, hallo Bochum, hallo Welt! :) > > I just sent an email to a crypto expert at a partner company to ask for > his opinion is on that. My feeling is that when we collect sufficient > opinions on that the "truth" will eventually emerge :) > > As mentioned, I don't have a proper crypto background, so during > refactoring I made sure Axel's code remained just as it was. > > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > > > > -------- Original Message -------- > Subject: Re: [jose] JWT + JOSE for Java > From: > Date: Thu, April 05, 2012 1:00 pm > To: , > Cc: jose@ietf.org > > > Hi Juraj, > > As Vladimir's work is based on my implementation I guess that my > implementation has room for improvement too. > https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/json/WebToken.java > > ENC_ALG_RSA_OAEP is better than ENC_ALG_RSA1_5. > https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/json/WebToken.java#116 > > Both padding algorithms are supported by my code and this RSA bulletin > mentions OAEP as one counter measure against the Bleichenbacher attack. > ftp://ftp.rsasecurity.com/pub/pdfs/bulletn7.pdf > > Does "your" attack work against ENC_ALG_RSA_OAEP too? Additional counter > measures suggestions are very welcome. > > RSA1_5 is in the proposed standard because it is widely available > although RSA recommends to use OAEP for decades. > I think that RSA-OAEP should be mandatory to implement and RSA1_5 > deprecated. > > Cheers. Greetings from Berlin to Bochum. > Axel > > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Juraj Somorovsky > Sent: Thursday, April 05, 2012 1:13 AM > To: vladimir@nimbusds.com > Cc: jose@ietf.org > Subject: Re: [jose] JWT + JOSE for Java > > Hi Vladimir, > > I have took a look at your implementation and found out, that your PKCS1 > handling is vulnerable to the Bleichenbacher attack (the adversary could > be able to issue different ciphertexts, send them to the server, and > according to its responses he could learn the encrypted CEK) > > I will send you PoCs and instructions how to fix it by tomorrow...or > just take a look at the document written by Eric Rescorla: > http://www.ietf.org/rfc/rfc3218.txt > > Regards > Juraj > > On 04/03/2012 11:24 AM, Vladimir Dzhuvinov / NimbusDS wrote: >> Today I reached a point in my JWT+JOSE library implementation where I >> wouldn't feel ashamed to release it to the public :) >> >> https://github.com/NimbusDS/Nimbus-JWT >> >> The library is fully documented: >> http://nimbusds.com/files/jwt/javadoc/index.html >> >> >> The Nimbus-JWT library started a month ago from code borrowed from >> Axel Nennker's + Co OpenInfoCard project and at this point covers >> fully plain and signed JWTs as well as JSON Web Keys (JWK). The JWE >> implementation still requires a bit of work to add HMAC integrity and >> cover the remaining elliptic curve and key-wrap encryption algorithms >> from the JWA spec. I would be very thankful if somebody could help me >> with that as I don't have much experience with cryptography :) >> >> For the listing of the supported JWAs: >> http://nimbusds.com/files/jwt/javadoc/com/nimbusds/jwt/JWA.html >> >> Cheers, >> >> Vladimir >> -- >> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > -- > M.Sc. Juraj Somorovsky > > Lehrstuhl für Netz- und Datensicherheit > Ruhr Universität Bochum > ----------------------------------- > Universitätsstr. 150, Geb. ID 2/411 > D-44780 Bochum > > Telefon: +49 (0) 234 / 32-26551 > Fax: +49 (0) 234 / 32-14347 > http://www.nds.rub.de > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- M.Sc. Juraj Somorovsky Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum ----------------------------------- Universitätsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de From ietf@augustcellars.com Thu Apr 5 08:30:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFA321F86D5 for ; Thu, 5 Apr 2012 08:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo8kmY2mCuKJ for ; Thu, 5 Apr 2012 08:30:14 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CD21F86E5 for ; Thu, 5 Apr 2012 08:30:14 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1B8C62CA23; Thu, 5 Apr 2012 08:30:01 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" , "'Matt Miller'" References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> In-Reply-To: <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> Date: Thu, 5 Apr 2012 08:28:43 -0700 Message-ID: <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKHZrmAco3AbGqXh0I+g1KfPwtE7gGNJkrMAtHy7j4CTGAGGJTiWB+A Cc: 'Brian Campbell' , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:30:17 -0000 John, I am at a loss, why do you believe that a new AEAD algorithm would not protect the headers? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > John Bradley > Sent: Thursday, April 05, 2012 7:28 AM > To: Matt Miller > Cc: Brian Campbell; jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > A couple of observations. > > The current proposal provides integrity over the header, a new AEAD alg > doesn't do that. > Low level crypto is a challenge. Re-using standard underlying algorithms like > HMAC and AES-CBC allow for JS and other libs to call standard lower level > crypto functions. > > I am not against having another AEAD alg, but want to help people > understand the current design choice. > > John B. > On 2012-04-05, at 9:49 AM, Matt Miller wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Another way around the conditional in application-space is to define an > AEAD algorithm composed of an encryption and hashing function. This > seems like a reasonable place to start looking at one: < > http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. > > > > On Apr 4, 2012, at 17:42, John Bradley wrote: > > > >> The use of a single key across two functions is one of things that is not > provably without problems. > >> > >> I agree that from an implementers point of view one key is simpler. > >> > >> There is a related-key attack that using the same key would enable. This > can be combined with differential and linear attacks on symmetric key > cyphers. > >> > >> Generally this can be thought of as a bad thing. > >> > >> What is certain is that it increases the possible attack surface, and if the is > a problem discovered as we have seen with AES-CBC it is going to be hard to > change later. > >> > >> We need key derivation anyway for ECDH-ES to produce a key of the > correct bit length. > >> > >> Doing key derivation on CMK is the theoretically proper way to do it. > >> Making a simplification might bite us in the future. > >> > >> I suppose one way to get around the conditional application argument is > to always use it to produce the CEK even with AEAD algorithms. > >> > >> Regards > >> John B. > >> > >> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > >> > >>> Hi all, > >>> > >>> I was hoping someone could help me (hopefully it's not just me!) > >>> understand the reasons for the introduction of the key derivation > >>> stuff* into JWE draft -01? > >>> > >>> I understand that it's there to derive the two keys, CEK and CIK, > >>> from the CMK and that it is to be done when a non-AEAD algorithm is > >>> used to encrypt the content. But what is the value of deriving the > >>> two keys as apposed to using the CMK for both encryption and integrity? > >>> > >>> Perhaps naively I assumed that using the CMK for both would be > >>> sufficient. It's randomly generated and used only for the one JWE. > >>> It's not clear to me what benefit is provided by the additional > >>> complexity of the derivation function as well as its conditional > >>> application (and the potential interoperability problems that come > >>> with such complexity). I assume there's some security benefit? But I > >>> can't see what it is. > >>> > >>> Any help would be appreciated. > >>> Thanks, > >>> Brian > >>> > >>> * > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se > >>> ction-7 > >>> which is referenced by > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se > >>> ction-5 and > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se > >>> ction-6 _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > > > > - - m&m > > > > Matt Miller - > > Cisco Systems, Inc. > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > > Comment: GPGTools - http://gpgtools.org > > > > > iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq > zQj > > > YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR > 8kx > > > c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL > y > > > LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb > + > > > ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb > Y > > > LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG > z/I= > > =174E > > -----END PGP SIGNATURE----- From mamille2@cisco.com Thu Apr 5 08:41:53 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB07C21F864F for ; Thu, 5 Apr 2012 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+Z270qNuXyp for ; Thu, 5 Apr 2012 08:41:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1382221F85A2 for ; Thu, 5 Apr 2012 08:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=2643; q=dns/txt; s=iport; t=1333640511; x=1334850111; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cLyZSC/VLv9xrbzO3laGE5asGa0Eo0iKFn6/YPF8+9s=; b=TAOveCIKSdQ9OxeAUtqBc4uYiGnh7Q4XFed5GBFcwDQFXhokf/wqYldJ JQOuHOFu1r6dZsaIrPfdijw+7c10u4sbaBkduJOHwQxlVO9u4Bqjs18aU GxhqDEUZpsQcj+zo7//yGqzy2Hr3kSKHe4CB5f7nRtPONoJN5lV0eCXKJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANe8fU+rRDoI/2dsb2JhbABFuG6BB4IJAQEBAwESASc/EAsOCi5XBhMbB4dnBAGbF591j3djBIhZjRKBEY06gWmDBg X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="36637005" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 05 Apr 2012 15:41:49 +0000 Received: from dhcp-64-101-72-208.cisco.com (dhcp-64-101-72-208.cisco.com [64.101.72.208]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q35Ffmbl019619; Thu, 5 Apr 2012 15:41:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matt Miller In-Reply-To: <4CD31FEA-9079-4964-A943-1AD6C69BAF92@ve7jtb.com> Date: Thu, 5 Apr 2012 09:41:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> <4CD31FEA-9079-4964-A943-1AD6C69BAF92@ve7jtb.com> To: John Bradley X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: Brian Campbell , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:41:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 5, 2012, at 09:12, John Bradley wrote: >=20 > On 2012-04-05, at 11:50 AM, Matt Miller wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >>=20 >> On Apr 5, 2012, at 08:28, John Bradley wrote: >>=20 >>> A couple of observations. >>>=20 >>> The current proposal provides integrity over the header, a new AEAD = alg doesn't do that. >>=20 >> The current proposal does not provide this for existing AEAD = algorithms.=20 >=20 > True that is an advantage the composite CBC + HMAC has over GCM. >=20 Maybe we should find a way to correct that. One possible solution is to = use the base64url-encoded header as the additional data (possibly = truncated based on algorithm requirements). >>=20 >>> Low level crypto is a challenge. Re-using standard underlying = algorithms like HMAC and AES-CBC allow for JS and other libs to call = standard lower level crypto functions. >>>=20 >>=20 >> The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and = HMAC-SHA-256); it's not any more low-level than the non-AEAD path = specified in JWE. >=20 > I will have another look at it. >>=20 >>> I am not against having another AEAD alg, but want to help people = understand the current design choice. >>>=20 >>=20 >> The benefit is to have a single path through the use of algorithms. = It puts the differences into the algorithm implementations, which is = where they should be. >>=20 > There is no AES-CBC option without HMAC. Perhaps we should net be = calling it AES-CBC in JWA. >=20 I get there's no AES-CBC sans HMAC, and I completely agree that = encryption without integrity protection is not worth it. All I'm = suggesting is we (or someone) define an AEAD algorithm, say = "AES-CBC-HMAC-SHA2-CONCAT-KDF" or something, which pulls together the = non-AEAD path from JWE into its own algorithm. >>> John B. >>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>>=20 >=20 - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPfb09AAoJEJq6Ou0cgrSPFQgIAObHB26bX7zdqcyzdWdMQYpA H7JmkjMZSLCG1WMPUJWgg9w3+/SbxBkoTFKQC5SLzZrYXTErXD3sfzEXt5U5i/2v buvnqNd4ELZDsf3kosBmn6Y2h45DPlLVMT1JE2wbQDqfx6PZPdBISGdZYlPAqXWl cMyLKdVIBYE/4ADa2Rwswnke3dLvv4vkJUzcItAeBA0khLzS25B1Q2JpunOSKMyD i0SPxEJ9aZHghxmjGQtQIU9DBI7kuvCap8eD9zYj6DPGoAnEKWMr/hoWUjMhB7HH wEVm6dKbmH7aTVSkl4suUnU2uclurmwCB42xDNPieULQy/2T2/oKU9ERwIm0M4k=3D =3DdvxJ -----END PGP SIGNATURE----- From ve7jtb@ve7jtb.com Thu Apr 5 08:45:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14A621F8712 for ; Thu, 5 Apr 2012 08:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54SRyCfxwtd3 for ; Thu, 5 Apr 2012 08:45:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C637121F8716 for ; Thu, 5 Apr 2012 08:45:23 -0700 (PDT) Received: by yhkk25 with SMTP id k25so865345yhk.31 for ; Thu, 05 Apr 2012 08:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=+dSdQMeSrsLuyx9Gea9Dt3ltlVqF7X4pddNOjPTfpyM=; b=S27k5RSJPNoaLa4VZW3+Lm3oP4Gyi3hdw9YhSp+N45lrB47I4+e43hS772qh7ptqUM coc8O84uwLX9ftMOWMC41ZfJF3Un3ksOyEod9JyL8imtSRPyR/EXPjbd1bgov0bv2bMZ uiagTKi82+d9i+ZJucTQfZbAl7PGwGwkyM3vHYRjlBQFoKuSW/1UcHIt7Idk0CTFgZNK ZHbx4PsYAffpXYU3k83bL9xL/y34WpX/9Cliu7dOmJIVaL3gGsB/z6SSkAuF6DRMEDfY mKKarcBpFkImG87KmjWrdTM+iEnPBW4YPXBwzKIgw//rs9t0ygJonRA5T4lOCngZMMwR g0mg== Received: by 10.236.192.230 with SMTP id i66mr2625959yhn.92.1333640723279; Thu, 05 Apr 2012 08:45:23 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id 34sm7334493anu.6.2012.04.05.08.45.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:45:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D03CF060-9CDE-4E62-A30B-FD156D145433"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> Date: Thu, 5 Apr 2012 12:45:14 -0300 Message-Id: <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnOGI0H7LwfBMrniWOfi7FbawkXOmGiZYb8HitKx3g5YKGt1jPIyC/nICP6pHYqZv7M/sGv Cc: 'Brian Campbell' , jose@ietf.org, 'Matt Miller' Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:45:24 -0000 --Apple-Mail=_D03CF060-9CDE-4E62-A30B-FD156D145433 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In JWE the headers are not encrypted. =20 GCM provides integrity only over the encrypted content. In the composite AES-CBC + HMAC the integrity is calculated over both = the Header and the encrypted content. The advantage of not using a AEAD algorithm is that the composite can be = more JOSE aware. I can't rule out having missed something thats why we review these = things:) John B. On 2012-04-05, at 12:28 PM, Jim Schaad wrote: > >=20 > John, >=20 > I am at a loss, why do you believe that a new AEAD algorithm would not > protect the headers? >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> John Bradley >> Sent: Thursday, April 05, 2012 7:28 AM >> To: Matt Miller >> Cc: Brian Campbell; jose@ietf.org >> Subject: Re: [jose] Understanding the motivation for Key Derivation? >>=20 >> A couple of observations. >>=20 >> The current proposal provides integrity over the header, a new AEAD = alg >> doesn't do that. >> Low level crypto is a challenge. Re-using standard underlying = algorithms > like >> HMAC and AES-CBC allow for JS and other libs to call standard lower = level >> crypto functions. >>=20 >> I am not against having another AEAD alg, but want to help people >> understand the current design choice. >>=20 >> John B. >> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> Another way around the conditional in application-space is to define = an >> AEAD algorithm composed of an encryption and hashing function. This >> seems like a reasonable place to start looking at one: < >> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. >>>=20 >>> On Apr 4, 2012, at 17:42, John Bradley wrote: >>>=20 >>>> The use of a single key across two functions is one of things that = is > not >> provably without problems. >>>>=20 >>>> I agree that from an implementers point of view one key is simpler. >>>>=20 >>>> There is a related-key attack that using the same key would enable. > This >> can be combined with differential and linear attacks on symmetric key >> cyphers. >>>>=20 >>>> Generally this can be thought of as a bad thing. >>>>=20 >>>> What is certain is that it increases the possible attack surface, = and > if the is >> a problem discovered as we have seen with AES-CBC it is going to be = hard > to >> change later. >>>>=20 >>>> We need key derivation anyway for ECDH-ES to produce a key of the >> correct bit length. >>>>=20 >>>> Doing key derivation on CMK is the theoretically proper way to do = it. >>>> Making a simplification might bite us in the future. >>>>=20 >>>> I suppose one way to get around the conditional application = argument is >> to always use it to produce the CEK even with AEAD algorithms. >>>>=20 >>>> Regards >>>> John B. >>>>=20 >>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I was hoping someone could help me (hopefully it's not just me!) >>>>> understand the reasons for the introduction of the key derivation >>>>> stuff* into JWE draft -01? >>>>>=20 >>>>> I understand that it's there to derive the two keys, CEK and CIK, >>>>> from the CMK and that it is to be done when a non-AEAD algorithm = is >>>>> used to encrypt the content. But what is the value of deriving the >>>>> two keys as apposed to using the CMK for both encryption and > integrity? >>>>>=20 >>>>> Perhaps naively I assumed that using the CMK for both would be >>>>> sufficient. It's randomly generated and used only for the one = JWE. >>>>> It's not clear to me what benefit is provided by the additional >>>>> complexity of the derivation function as well as its conditional >>>>> application (and the potential interoperability problems that come >>>>> with such complexity). I assume there's some security benefit? But = I >>>>> can't see what it is. >>>>>=20 >>>>> Any help would be appreciated. >>>>> Thanks, >>>>> Brian >>>>>=20 >>>>> * >>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se >>>>> ction-7 >>>>> which is referenced by >>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se >>>>> ction-5 and >>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se >>>>> ction-6 _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>> - - m&m >>>=20 >>> Matt Miller - >>> Cisco Systems, Inc. >>>=20 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>>=20 >>>=20 >> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq >> zQj >>>=20 >> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR >> 8kx >>>=20 >> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL >> y >>>=20 >> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb >> + >>>=20 >> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb >> Y >>>=20 >> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG >> z/I=3D >>> =3D174E >>> -----END PGP SIGNATURE----- >=20 >=20 --Apple-Mail=_D03CF060-9CDE-4E62-A30B-FD156D145433 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NTE1NDUxNVowIwYJKoZIhvcNAQkEMRYEFAbyQcS2xSd/u/tsITVuaOpqnl0kMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACWGvkIW7brk6ZRRIpYw8Niq3zcdVqqhjHoi7zv2nKIM3iNPW9l6piMYOCFaaENH3sR12CgKuwhb Xe3IAjGoN5lPwsJGtnGPCzzjdMD9hSupB4GcaE9y150TDT1u7QqnS8AgvD6L+b5aerJA3Q7kSq2u g0Ds6I/ecDJyo8WRxgGBKtOJgbJCyRIorOD8dRt+y5328t2J1u0Lrn76stv14P32ouhN4OdJqIUg IeQ8OVAP5YqiVJiXyEgnwFGePnDxzQiewrf/3Z7bklkgdRQMeiFVTXw1QeijJNRhD1DzEz49XKKv KRVzYXQmBNb/C+15TF6ra1BTRyDYlMEDWAu5ZrMAAAAAAAA= --Apple-Mail=_D03CF060-9CDE-4E62-A30B-FD156D145433-- From ve7jtb@ve7jtb.com Thu Apr 5 08:51:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D4A21F85C3 for ; Thu, 5 Apr 2012 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tesSf5hzNryS for ; Thu, 5 Apr 2012 08:51:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9B7121F8712 for ; Thu, 5 Apr 2012 08:51:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1278173vbb.31 for ; Thu, 05 Apr 2012 08:51:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=mQtKzCOlQuIfWRcoRi3HcOLd/rEay9gA/QzqaB6IZ+o=; b=W7Shg8YOdTNLni77FdxYLQzyJRc0AHt1CBDrcXQY2AQ9JEIk2w7xsgBe89kYF2njCk qhXBKl1no9ZFtbTMp9uyhS0wznxAqZ0YyP0ma/hIt3xeATc6efygsflmm9WJQ3yiIADf g/1irqJYDBuFOyKDF6wg8teq2Ns/eURsoJzmpOzHOQOOZNhPb/6WprKkGRJmJdT4o36K wQ89z31aLbzU9p3beabRp/gTaMOw4D/AFRXpCr3xBrD8hWjYSm4X3Uhye8pw3PYl72JL uceL5yWMTqOppt6hhc9HhRtyv4rsPiItS0I6Jkt08yqS7CERaxQ5lf6fgqcJhiSe91A5 IbvA== Received: by 10.52.91.225 with SMTP id ch1mr1888780vdb.31.1333641067263; Thu, 05 Apr 2012 08:51:07 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id r5sm4737610vdg.17.2012.04.05.08.51.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:51:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_4D315277-D786-44C6-8BE6-8F8F39DD21E0"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> Date: Thu, 5 Apr 2012 12:51:01 -0300 Message-Id: References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> <4CD31FEA-9079-4964-A943-1AD6C69BAF92@ve7jtb.com> <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkNlJksPGGWhCWvsPECP1ih2B+yt0wwYHAUYPuY3yy2oA955yM32t9Z0oMy7w4e+x4kbvFf Cc: Brian Campbell , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:51:08 -0000 --Apple-Mail=_4D315277-D786-44C6-8BE6-8F8F39DD21E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If we can find a way to do integrity for AEAD algorithms, that would be = great. I am OK with defining one or more AES-CBC-HMAC alg. The downside is that allowing flexibility on the HMAC size would cause a = large list of alg. =20 It is perhaps a flexibility vs implementation complexity argument.=20 I am not super emotionally attached to having them as separate = parameters. John B. On 2012-04-05, at 12:41 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On Apr 5, 2012, at 09:12, John Bradley wrote: >=20 >>=20 >> On 2012-04-05, at 11:50 AM, Matt Miller wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>>=20 >>> On Apr 5, 2012, at 08:28, John Bradley wrote: >>>=20 >>>> A couple of observations. >>>>=20 >>>> The current proposal provides integrity over the header, a new = AEAD alg doesn't do that. >>>=20 >>> The current proposal does not provide this for existing AEAD = algorithms.=20 >>=20 >> True that is an advantage the composite CBC + HMAC has over GCM. >>=20 >=20 > Maybe we should find a way to correct that. One possible solution is = to use the base64url-encoded header as the additional data (possibly = truncated based on algorithm requirements). >=20 >>>=20 >>>> Low level crypto is a challenge. Re-using standard underlying = algorithms like HMAC and AES-CBC allow for JS and other libs to call = standard lower level crypto functions. >>>>=20 >>>=20 >>> The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and = HMAC-SHA-256); it's not any more low-level than the non-AEAD path = specified in JWE. >>=20 >> I will have another look at it. >>>=20 >>>> I am not against having another AEAD alg, but want to help people = understand the current design choice. >>>>=20 >>>=20 >>> The benefit is to have a single path through the use of algorithms. = It puts the differences into the algorithm implementations, which is = where they should be. >>>=20 >> There is no AES-CBC option without HMAC. Perhaps we should net be = calling it AES-CBC in JWA. >>=20 >=20 > I get there's no AES-CBC sans HMAC, and I completely agree that = encryption without integrity protection is not worth it. All I'm = suggesting is we (or someone) define an AEAD algorithm, say = "AES-CBC-HMAC-SHA2-CONCAT-KDF" or something, which pulls together the = non-AEAD path from JWE into its own algorithm. >=20 >>>> John B. >>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>>>=20 >>=20 >=20 >=20 > - - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBAgAGBQJPfb09AAoJEJq6Ou0cgrSPFQgIAObHB26bX7zdqcyzdWdMQYpA > H7JmkjMZSLCG1WMPUJWgg9w3+/SbxBkoTFKQC5SLzZrYXTErXD3sfzEXt5U5i/2v > buvnqNd4ELZDsf3kosBmn6Y2h45DPlLVMT1JE2wbQDqfx6PZPdBISGdZYlPAqXWl > cMyLKdVIBYE/4ADa2Rwswnke3dLvv4vkJUzcItAeBA0khLzS25B1Q2JpunOSKMyD > i0SPxEJ9aZHghxmjGQtQIU9DBI7kuvCap8eD9zYj6DPGoAnEKWMr/hoWUjMhB7HH > wEVm6dKbmH7aTVSkl4suUnU2uclurmwCB42xDNPieULQy/2T2/oKU9ERwIm0M4k=3D > =3DdvxJ > -----END PGP SIGNATURE----- --Apple-Mail=_4D315277-D786-44C6-8BE6-8F8F39DD21E0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NTE1NTEwMlowIwYJKoZIhvcNAQkEMRYEFN49DQRey/M3QTKGYxoEeRtJfZhoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AGXS96jrJZDE8eHOUC4bgvQZs5iHdU+A4Ii6oQfzfyqxtWno+nN6A6cTUm5/QPnmKeddBLRNleDm behMwbfGNogxK1329brFCCkUwWILoo5yfQPX+se0WnGyH+JBWfDHULBXlN1Y38/oeC0iPBcUfteX G9vJHiGUhUhy8ah3lZRGfZOuqgFquHAnQJn6V5gdvwPstVHCJzj9hM/4f+37ZJlr0yVMQc3u4mGy aMYr0vQdh1Gpd0QK9DDbSZdYwfIK0v/zkwYB6nMALSc265n6Jdi9MqvyCpD5kuCt2syJfigKCXsf sUPXEx3tbmvraw1Ei8y6EMA/EVRr253+EXDmhOoAAAAAAAA= --Apple-Mail=_4D315277-D786-44C6-8BE6-8F8F39DD21E0-- From ve7jtb@ve7jtb.com Thu Apr 5 08:53:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0A821F8709 for ; Thu, 5 Apr 2012 08:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HA0ifnm4oqY for ; Thu, 5 Apr 2012 08:53:45 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2898321F8674 for ; Thu, 5 Apr 2012 08:53:44 -0700 (PDT) Received: by ggmi1 with SMTP id i1so872084ggm.31 for ; Thu, 05 Apr 2012 08:53:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Lqtn5Na02+t731ysw2rugGXAo/KPKmnEYurWtce9D0I=; b=BFi8+e3STxY3Zd5DiHwFeMjD119XhPCNMdRHAFkDwzngfnDmYob/T+5JWnQSthihQp XslyhtUIjKrl8jHt1nGcNnMmbSMdfYY/7bsGZOefoqKKK1Y+PFk4qvWLvTWQXPkJE4gU fW/sKYCLuJW7un8U6nJEQacWEFyZYgyGyGlh7kv/j7DGxCg920pqThdFCC3wdo/9ge6w Jl+X6YK6gK+1NXMdsONoF/XHErsM1/iZ0SP8iph2PIgVSbVLMue8PUCwrHcNRpXOaf0i Vd64UyU5wfV8dzuEnc0JasHwkDS11IMfQ4J23cB+JH3MyhXlTVeW0+08IyLVwZPf1XeF 0zXw== Received: by 10.236.185.4 with SMTP id t4mr2638997yhm.129.1333641224627; Thu, 05 Apr 2012 08:53:44 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id e1sm16478648yhi.9.2012.04.05.08.53.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:53:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D13A7D18-19F4-4F08-A6A4-7858E6D41383"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Thu, 5 Apr 2012 12:53:36 -0300 Message-Id: References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnilERvckpfHhUUoLozwm5fjy5aP4iFEdxxXrzpcXsaU5fTkEPM4GOoceD73Li1CMJKP+t5 Cc: jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:53:47 -0000 --Apple-Mail=_D13A7D18-19F4-4F08-A6A4-7858E6D41383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes the KDF for ECDH-ES is baked into the alg, but we did use the same = KDF to make things easier (or at least not harder) John B. On 2012-04-05, at 12:47 PM, Brian Campbell wrote: > Okay, you had me at "not provably";) Thanks for the explanation, = John. >=20 > And yep - from an implementers point of view, one key is much simpler. > I'm working on an implementation now and I'll admit that laziness was > my first reaction to seeing the KDF and having to go find NIST Special > Publication 800-56A. But that thought was also followed by thinking > that the application of the KDF looks like a likely place for > implementation, interpretation and interop problems to show up. Maybe > that's not a valid concern but I wanted to ask about it. And asking > seems to have sparked some additional discussion which can't hurt. >=20 > And yes, ECDH-ES does use the KDF but it's somewhat different as it's > encapsulated in the algorithm rather than part of core JWE. >=20 > I assume that generating and sending two keys was not considered due > to the goal of having the JWE compact serialization be as compact as > possible? >=20 > I don't know if always using a KDF for the CEK, even with AEAD > algorithms, simplifies things all that much. Maybe it does. I don't > know. The conditional based on one aspect of the underlying algorithm > does feel a touch awkward but I (now) understand the reasons for doing > it that way. >=20 > On Wed, Apr 4, 2012 at 5:42 PM, John Bradley = wrote: >> The use of a single key across two functions is one of things that is = not provably without problems. >>=20 >> I agree that from an implementers point of view one key is simpler. >>=20 >> There is a related-key attack that using the same key would enable. = This can be combined with differential and linear attacks on symmetric = key cyphers. >>=20 >> Generally this can be thought of as a bad thing. >>=20 >> What is certain is that it increases the possible attack surface, = and if the is a problem discovered as we have seen with AES-CBC it is = going to be hard to change later. >>=20 >> We need key derivation anyway for ECDH-ES to produce a key of the = correct bit length. >>=20 >> Doing key derivation on CMK is the theoretically proper way to do it. >> Making a simplification might bite us in the future. >>=20 >> I suppose one way to get around the conditional application argument = is to always use it to produce the CEK even with AEAD algorithms. >>=20 >> Regards >> John B. >>=20 >> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>=20 >>> Hi all, >>>=20 >>> I was hoping someone could help me (hopefully it's not just me!) >>> understand the reasons for the introduction of the key derivation >>> stuff* into JWE draft -01? >>>=20 >>> I understand that it's there to derive the two keys, CEK and CIK, = from >>> the CMK and that it is to be done when a non-AEAD algorithm is used = to >>> encrypt the content. But what is the value of deriving the two keys = as >>> apposed to using the CMK for both encryption and integrity? >>>=20 >>> Perhaps naively I assumed that using the CMK for both would be >>> sufficient. It's randomly generated and used only for the one JWE. >>> It's not clear to me what benefit is provided by the additional >>> complexity of the derivation function as well as its conditional >>> application (and the potential interoperability problems that come >>> with such complexity). I assume there's some security benefit? But I >>> can't see what it is. >>>=20 >>> Any help would be appreciated. >>> Thanks, >>> Brian >>>=20 >>> * = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 7 >>> which is referenced by >>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 5 >>> and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-= 6 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 --Apple-Mail=_D13A7D18-19F4-4F08-A6A4-7858E6D41383 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NTE1NTMzN1owIwYJKoZIhvcNAQkEMRYEFLHkwCkty3xrvB3NuRKPdbYK+Lx8MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AHzcPMeOn9yfloDZNT9jiQXf2Abvl06kx5UefBy/onmt+6z+ERE9oaokE6khtOx65+4RF66yoJSb iwM05FFLj2iM5Y5FNlG/pW7OybDXgu56/OXfD0af1HoqX1Xxc/iirtLamC1/9JaRn7PMiNL0E/zC S61zmXX6jRUqyn5rkyiO0W5NH8zDwjK0UqoqGdiY+m2rzWeZAoYVe1wY2i5G9pgbpnDvl7LdcM/i flRH2d2VGPvjh4mmPcplZjaesA3tI1o/5aJdVhsEHhAvFE9z/9D46WZJJJ7YswyLA/NJzVb8zt3P vGzvwiaxj/oOtPGT1cZ8sV18fDZ4OnX+h28WHPQAAAAAAAA= --Apple-Mail=_D13A7D18-19F4-4F08-A6A4-7858E6D41383-- From tom@ritter.vg Thu Apr 5 09:04:36 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6841021F872B for ; Thu, 5 Apr 2012 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaZDbAqn9xNR for ; Thu, 5 Apr 2012 09:04:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6365C21F872D for ; Thu, 5 Apr 2012 09:04:35 -0700 (PDT) Received: by yhkk25 with SMTP id k25so878552yhk.31 for ; Thu, 05 Apr 2012 09:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zdj1XC56+IMTi2Lpyydml94K4Uiq546MLkaM7PPDh9w=; b=2/QWFhTilbm1kKxR+V00o9BWtV3yNHpPV/OytVMnSu9VZsCRnTtrV7S4g52uMypav9 GCu+9LmJ2UyCBbdjiGdR8/d1ve/P2iBHNVOuQJNZe93slX6pKTeEURR/9eRpKxh90lxH Musesbg61/vp3VQIMeLdxPhBioyvegGSPVrO8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Zdj1XC56+IMTi2Lpyydml94K4Uiq546MLkaM7PPDh9w=; b=c2TlqcJyYgYV3N9D+YsmREZPhbSCnUoberUdlXZCiJAs03evOL3i5D6/iJ3sbfdA40 B72hVLeD64isjdV6XY6Br1vq5C+YccYp9h1dcWArQHQvSZq4hc+b/sd5JHIxNCV93ohR 6NvYrPz5G9J21FWmlmWCmUQrzSXwgXtA5THq5wwCW9fV7tOhx+X4a1RMoZQLTVEGqRjy nFSINM4QIFHDeEPzLc2E3KM5sg8tpB4gJ+t89rzNJpuR0gpFAuwDg1Wn8nvpM3YmqnSX ah7G8Rrf0qkE+OAHWEvrxC9oXKls9y4wFivSQNs+zRNSRpCPwLJb8IAde1Da5HlfuTgl Wg5A== Received: by 10.60.0.201 with SMTP id 9mr4520467oeg.59.1333641874906; Thu, 05 Apr 2012 09:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.182.5 with HTTP; Thu, 5 Apr 2012 09:04:14 -0700 (PDT) In-Reply-To: <4F7DBA63.3020503@rub.de> References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> From: Tom Ritter Date: Thu, 5 Apr 2012 12:04:14 -0400 Message-ID: To: Juraj Somorovsky Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlh1As9tPFz1GHZ/p7QMLpDRNXUercbcrr9zGGQN/+0VefBVvI56QDvu4YV8hB7P16H5kzD Cc: Axel.Nennker@telekom.de, jose@ietf.org, Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:04:36 -0000 On 5 April 2012 11:29, Juraj Somorovsky wrote: > RSA-OAEP is the good choice for JOSE as PKCS1 will cause similar > problems also for other developers. > > > Regards from Bochum > Juraj I haven't been following closely, but if it hasn't been already I should point out there's a very similar attack against RSA-OAEP you need to take care to avoid: http://ritter.vg/blog-mangers_oracle.html -tom From ietf@augustcellars.com Thu Apr 5 09:06:54 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07721F85AD for ; Thu, 5 Apr 2012 09:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qebbU5tb-q+o for ; Thu, 5 Apr 2012 09:06:52 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1775B21F86B7 for ; Thu, 5 Apr 2012 09:06:52 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 860852CA21; Thu, 5 Apr 2012 09:06:37 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> In-Reply-To: <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> Date: Thu, 5 Apr 2012 09:05:26 -0700 Message-ID: <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKHZrmAco3AbGqXh0I+g1KfPwtE7gGNJkrMAtHy7j4CTGAGGAJ3LV1+AWIsXyiUw5b8cA== Cc: 'Brian Campbell' , jose@ietf.org, 'Matt Miller' Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:06:54 -0000 Ok - I see you problem. Yes, in JWE the headers are not encrypted. GCM provides integrity over both the encrypted content and the additional data fields (hence the difference between AD (authenticated Data) and AEAD(Authenticated Data with Additional Data). All AEAD algorithms provide for the ability to have data which is not part of the encrypted data be included in the authenticated data. In fact AEAD algorithms can be used as MAC algorithms in many cases by simply having an empty string for the encrypted data (it depends in part on the internal construction of the encrypted data stream). I believe we verified that this was a true statement for GCM at the last IETF meeting (in a hallway conversation). Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Thursday, April 05, 2012 8:45 AM > To: Jim Schaad > Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > In JWE the headers are not encrypted. > > GCM provides integrity only over the encrypted content. > > In the composite AES-CBC + HMAC the integrity is calculated over both the > Header and the encrypted content. > > The advantage of not using a AEAD algorithm is that the composite can be > more JOSE aware. > > I can't rule out having missed something thats why we review these things:) > > John B. > On 2012-04-05, at 12:28 PM, Jim Schaad wrote: > > > > > > > John, > > > > I am at a loss, why do you believe that a new AEAD algorithm would not > > protect the headers? > > > > Jim > > > > > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > Of > >> John Bradley > >> Sent: Thursday, April 05, 2012 7:28 AM > >> To: Matt Miller > >> Cc: Brian Campbell; jose@ietf.org > >> Subject: Re: [jose] Understanding the motivation for Key Derivation? > >> > >> A couple of observations. > >> > >> The current proposal provides integrity over the header, a new AEAD alg > >> doesn't do that. > >> Low level crypto is a challenge. Re-using standard underlying algorithms > > like > >> HMAC and AES-CBC allow for JS and other libs to call standard lower level > >> crypto functions. > >> > >> I am not against having another AEAD alg, but want to help people > >> understand the current design choice. > >> > >> John B. > >> On 2012-04-05, at 9:49 AM, Matt Miller wrote: > >> > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> Another way around the conditional in application-space is to define an > >> AEAD algorithm composed of an encryption and hashing function. This > >> seems like a reasonable place to start looking at one: < > >> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. > >>> > >>> On Apr 4, 2012, at 17:42, John Bradley wrote: > >>> > >>>> The use of a single key across two functions is one of things that is > > not > >> provably without problems. > >>>> > >>>> I agree that from an implementers point of view one key is simpler. > >>>> > >>>> There is a related-key attack that using the same key would enable. > > This > >> can be combined with differential and linear attacks on symmetric key > >> cyphers. > >>>> > >>>> Generally this can be thought of as a bad thing. > >>>> > >>>> What is certain is that it increases the possible attack surface, and > > if the is > >> a problem discovered as we have seen with AES-CBC it is going to be hard > > to > >> change later. > >>>> > >>>> We need key derivation anyway for ECDH-ES to produce a key of the > >> correct bit length. > >>>> > >>>> Doing key derivation on CMK is the theoretically proper way to do it. > >>>> Making a simplification might bite us in the future. > >>>> > >>>> I suppose one way to get around the conditional application argument > is > >> to always use it to produce the CEK even with AEAD algorithms. > >>>> > >>>> Regards > >>>> John B. > >>>> > >>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> I was hoping someone could help me (hopefully it's not just me!) > >>>>> understand the reasons for the introduction of the key derivation > >>>>> stuff* into JWE draft -01? > >>>>> > >>>>> I understand that it's there to derive the two keys, CEK and CIK, > >>>>> from the CMK and that it is to be done when a non-AEAD algorithm is > >>>>> used to encrypt the content. But what is the value of deriving the > >>>>> two keys as apposed to using the CMK for both encryption and > > integrity? > >>>>> > >>>>> Perhaps naively I assumed that using the CMK for both would be > >>>>> sufficient. It's randomly generated and used only for the one JWE. > >>>>> It's not clear to me what benefit is provided by the additional > >>>>> complexity of the derivation function as well as its conditional > >>>>> application (and the potential interoperability problems that come > >>>>> with such complexity). I assume there's some security benefit? But I > >>>>> can't see what it is. > >>>>> > >>>>> Any help would be appreciated. > >>>>> Thanks, > >>>>> Brian > >>>>> > >>>>> * > >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se > >>>>> ction-7 > >>>>> which is referenced by > >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se > >>>>> ction-5 and > >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se > >>>>> ction-6 _______________________________________________ > >>>>> jose mailing list > >>>>> jose@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/jose > >>>> > >>>> _______________________________________________ > >>>> jose mailing list > >>>> jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose > >>> > >>> > >>> - - m&m > >>> > >>> Matt Miller - > >>> Cisco Systems, Inc. > >>> > >>> -----BEGIN PGP SIGNATURE----- > >>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > >>> Comment: GPGTools - http://gpgtools.org > >>> > >>> > >> > iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq > >> zQj > >>> > >> > YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR > >> 8kx > >>> > >> > c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL > >> y > >>> > >> > LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb > >> + > >>> > >> > ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb > >> Y > >>> > >> > LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG > >> z/I= > >>> =174E > >>> -----END PGP SIGNATURE----- > > > > From ve7jtb@ve7jtb.com Thu Apr 5 09:11:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A1921F86D3 for ; Thu, 5 Apr 2012 09:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbpXj599ej3K for ; Thu, 5 Apr 2012 09:11:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11D0A21F85AD for ; Thu, 5 Apr 2012 09:11:08 -0700 (PDT) Received: by yenm5 with SMTP id m5so878967yen.31 for ; Thu, 05 Apr 2012 09:11:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=2u2WHqbJEI6jzPEdLCMQ/B48eVkQr1h8LgzLInjtkYo=; b=Jn0WL5yPBIxTUurUNntjrxaakYwuvsY1CuJonU7Lv+UUwJk0QaZSctDPzIHG5hY4f+ BxhVhxg0ibV3ux5KOyTxQeB88JDhUZHydQ8782oPZEDBydVrZBkvp0jYkFqfYNepzIx8 k0B0VhBSRhJX6ZmKnMqzn/bRiRVXb0xe8m1p5zLffBBUi8986GI88uXDqHSjEL/l2AD5 cEORCXU8U1arpYBtUMyHzJsX8kC+/zcnNry42wR10XSdopoHy6UFwbGM3nMdAmTc9iVb 9lBwSDZW0bxsMDdWDCONwV5mK0vaKpPWgsxPrx3PazcnF8Gv0A+4d9GvG4EhbIsYyZ8Y CNpA== Received: by 10.236.114.169 with SMTP id c29mr2748667yhh.37.1333642268455; Thu, 05 Apr 2012 09:11:08 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id b4sm7432290anb.22.2012.04.05.09.11.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 09:11:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_E1063749-382F-470B-A29F-55CCA0C614C3"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> Date: Thu, 5 Apr 2012 13:10:58 -0300 Message-Id: <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmkrhFxAiwzb7HvIg9QTN/JJmffekgH2vw6p2ZCxMx5OZ6ha8dmEzb2w6tXmTx3E32h13OZ Cc: 'Brian Campbell' , jose@ietf.org, 'Matt Miller' Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:11:10 -0000 --Apple-Mail=_E1063749-382F-470B-A29F-55CCA0C614C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Then we should look at including the header as the additional data for = GCM. I will have a look at it, and make a proposal for some text, unless = someone else is volunteering? John B. On 2012-04-05, at 1:05 PM, Jim Schaad wrote: > Ok - I see you problem. >=20 > Yes, in JWE the headers are not encrypted. > GCM provides integrity over both the encrypted content and the = additional > data fields (hence the difference between AD (authenticated Data) and > AEAD(Authenticated Data with Additional Data). >=20 > All AEAD algorithms provide for the ability to have data which is not = part > of the encrypted data be included in the authenticated data. In fact = AEAD > algorithms can be used as MAC algorithms in many cases by simply = having an > empty string for the encrypted data (it depends in part on the = internal > construction of the encrypted data stream). I believe we verified = that this > was a true statement for GCM at the last IETF meeting (in a hallway > conversation). >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Thursday, April 05, 2012 8:45 AM >> To: Jim Schaad >> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >> Subject: Re: [jose] Understanding the motivation for Key Derivation? >>=20 >> In JWE the headers are not encrypted. >>=20 >> GCM provides integrity only over the encrypted content. >>=20 >> In the composite AES-CBC + HMAC the integrity is calculated over both = the >> Header and the encrypted content. >>=20 >> The advantage of not using a AEAD algorithm is that the composite can = be >> more JOSE aware. >>=20 >> I can't rule out having missed something thats why we review these > things:) >>=20 >> John B. >> On 2012-04-05, at 12:28 PM, Jim Schaad wrote: >>=20 >>> >>>=20 >>> John, >>>=20 >>> I am at a loss, why do you believe that a new AEAD algorithm would = not >>> protect the headers? >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf >> Of >>>> John Bradley >>>> Sent: Thursday, April 05, 2012 7:28 AM >>>> To: Matt Miller >>>> Cc: Brian Campbell; jose@ietf.org >>>> Subject: Re: [jose] Understanding the motivation for Key = Derivation? >>>>=20 >>>> A couple of observations. >>>>=20 >>>> The current proposal provides integrity over the header, a new = AEAD > alg >>>> doesn't do that. >>>> Low level crypto is a challenge. Re-using standard underlying > algorithms >>> like >>>> HMAC and AES-CBC allow for JS and other libs to call standard lower > level >>>> crypto functions. >>>>=20 >>>> I am not against having another AEAD alg, but want to help people >>>> understand the current design choice. >>>>=20 >>>> John B. >>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>>>=20 >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>>=20 >>>>> Another way around the conditional in application-space is to = define > an >>>> AEAD algorithm composed of an encryption and hashing function. = This >>>> seems like a reasonable place to start looking at one: < >>>> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. >>>>>=20 >>>>> On Apr 4, 2012, at 17:42, John Bradley wrote: >>>>>=20 >>>>>> The use of a single key across two functions is one of things = that is >>> not >>>> provably without problems. >>>>>>=20 >>>>>> I agree that from an implementers point of view one key is = simpler. >>>>>>=20 >>>>>> There is a related-key attack that using the same key would = enable. >>> This >>>> can be combined with differential and linear attacks on symmetric = key >>>> cyphers. >>>>>>=20 >>>>>> Generally this can be thought of as a bad thing. >>>>>>=20 >>>>>> What is certain is that it increases the possible attack surface, > and >>> if the is >>>> a problem discovered as we have seen with AES-CBC it is going to be > hard >>> to >>>> change later. >>>>>>=20 >>>>>> We need key derivation anyway for ECDH-ES to produce a key of the >>>> correct bit length. >>>>>>=20 >>>>>> Doing key derivation on CMK is the theoretically proper way to do = it. >>>>>> Making a simplification might bite us in the future. >>>>>>=20 >>>>>> I suppose one way to get around the conditional application = argument >> is >>>> to always use it to produce the CEK even with AEAD algorithms. >>>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> I was hoping someone could help me (hopefully it's not just me!) >>>>>>> understand the reasons for the introduction of the key = derivation >>>>>>> stuff* into JWE draft -01? >>>>>>>=20 >>>>>>> I understand that it's there to derive the two keys, CEK and = CIK, >>>>>>> from the CMK and that it is to be done when a non-AEAD algorithm = is >>>>>>> used to encrypt the content. But what is the value of deriving = the >>>>>>> two keys as apposed to using the CMK for both encryption and >>> integrity? >>>>>>>=20 >>>>>>> Perhaps naively I assumed that using the CMK for both would be >>>>>>> sufficient. It's randomly generated and used only for the one = JWE. >>>>>>> It's not clear to me what benefit is provided by the additional >>>>>>> complexity of the derivation function as well as its conditional >>>>>>> application (and the potential interoperability problems that = come >>>>>>> with such complexity). I assume there's some security benefit? = But I >>>>>>> can't see what it is. >>>>>>>=20 >>>>>>> Any help would be appreciated. >>>>>>> Thanks, >>>>>>> Brian >>>>>>>=20 >>>>>>> * >>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se >>>>>>> ction-7 >>>>>>> which is referenced by >>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se >>>>>>> ction-5 and >>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se >>>>>>> ction-6 _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>=20 >>>>> - - m&m >>>>>=20 >>>>> Matt Miller - >>>>> Cisco Systems, Inc. >>>>>=20 >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>> Comment: GPGTools - http://gpgtools.org >>>>>=20 >>>>>=20 >>>>=20 >> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq >>>> zQj >>>>>=20 >>>>=20 >> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR >>>> 8kx >>>>>=20 >>>>=20 >> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL >>>> y >>>>>=20 >>>>=20 >> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb >>>> + >>>>>=20 >>>>=20 >> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb >>>> Y >>>>>=20 >>>>=20 >> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG >>>> z/I=3D >>>>> =3D174E >>>>> -----END PGP SIGNATURE----- >>>=20 >>>=20 >=20 >=20 --Apple-Mail=_E1063749-382F-470B-A29F-55CCA0C614C3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NTE2MTA1OVowIwYJKoZIhvcNAQkEMRYEFLmsw3Kvhga1JvVjNpNKh1e4hGrYMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACjJBN0z9Q9reHN8QUMpNgGPAA7tco3JlRCrkWZzej0cqV6UMWvka9+wIbnAJ7lOXRk6Iiwxlu9k XwqdfCSEoQitDvKFgKZ+r3m+0xaLjjY0pSgg6BTmvPKRRH9WIRJwI0Xwt916M23HiH/XPE+NLvoG Yb8QHFiaqXSoKSYS/tLQLwb0fZUrpcnb485v3CCL53mWjsEB+PIpB7bwasl4GosqV3S9L1q8pKuo HWzoaxDmw5yqUhyGPw+7WIqG89gzyuEHpV72K+kr0zsg5PxowTttdcE4+9eJooTYubOUWjVER7gm ofm2L3xGUCIRFeuRwfIx/mG3D2Ci92hPBvWNRGQAAAAAAAA= --Apple-Mail=_E1063749-382F-470B-A29F-55CCA0C614C3-- From bcampbell@pingidentity.com Thu Apr 5 09:17:12 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224CC21F8686 for ; Thu, 5 Apr 2012 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMXMqezDTi9x for ; Thu, 5 Apr 2012 09:17:11 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2121F865D for ; Thu, 5 Apr 2012 09:17:10 -0700 (PDT) Received: from mail-vx0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKT33FhtMVN0nbC7mI/EQ7F9Qbed3FV+fT@postini.com; Thu, 05 Apr 2012 09:17:11 PDT Received: by vcbgb30 with SMTP id gb30so697391vcb.9 for ; Thu, 05 Apr 2012 09:17:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=vJdZfNONkwLiM+shIB/Cm9NBPWA+iX8JRLaxbmAqMAs=; b=M9A9rsTfCHNROGUvFS+0ZPh0UGRuUvfqnABdY0yJ7HyNofPKtwnx9ZrZNVQedrGnaD bVp4qVIXz7ewkLHfS218/ijclj3EEsQgrsaL3lMAd8FpjT/dwPvJCdHwLLf/DcLD2ljm Jz2mLvRREng2gXX/QgglWdoX2yRWfymZStLVHu4Hlol3f14UNZZsdYZZlExP3QlJaWGG XQ/Nhf7WLW/uSPydQCMmkPVgPE7eVYA9zgQpOMLslxPv3Ttr42EmvzuFSyPAvxJUt9iU EayLCybf3kyWOP0ctnwGggotLITglywUzlbEpIPzJpIFmclFupcsfsE/HzVDKsNF3pkQ whpw== Received: by 10.52.91.225 with SMTP id ch1mr1882143vdb.31.1333640883705; Thu, 05 Apr 2012 08:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Thu, 5 Apr 2012 08:47:33 -0700 (PDT) In-Reply-To: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> From: Brian Campbell Date: Thu, 5 Apr 2012 09:47:33 -0600 Message-ID: To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlqfKJ/QbcIhMeUkd1dktSocIiSJTBPV7MRdqLQtmBA00NEc0FuxZSxzg00V5E62bCImI+B Cc: jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:17:12 -0000 Okay, you had me at "not provably";) Thanks for the explanation, John. And yep - from an implementers point of view, one key is much simpler. I'm working on an implementation now and I'll admit that laziness was my first reaction to seeing the KDF and having to go find NIST Special Publication 800-56A. But that thought was also followed by thinking that the application of the KDF looks like a likely place for implementation, interpretation and interop problems to show up. Maybe that's not a valid concern but I wanted to ask about it. And asking seems to have sparked some additional discussion which can't hurt. And yes, ECDH-ES does use the KDF but it's somewhat different as it's encapsulated in the algorithm rather than part of core JWE. I assume that generating and sending two keys was not considered due to the goal of having the JWE compact serialization be as compact as possible? I don't know if always using a KDF for the CEK, even with AEAD algorithms, simplifies things all that much. Maybe it does. I don't know. The conditional based on one aspect of the underlying algorithm does feel a touch awkward but I (now) understand the reasons for doing it that way. On Wed, Apr 4, 2012 at 5:42 PM, John Bradley wrote: > The use of a single key across two functions is one of things that is not= provably without problems. > > I agree that from an implementers point of view one key is simpler. > > There is a related-key attack that using the same key would enable. =A0Th= is can be combined with differential and linear attacks on symmetric key cy= phers. > > Generally this can be thought of as a bad thing. > > What is certain is that it increases the possible attack surface, =A0and = if the is a problem discovered as we have seen with AES-CBC it is going to = be hard to change later. > > We need key derivation anyway for ECDH-ES to produce a key of the correct= bit length. > > Doing key derivation on CMK is the theoretically proper way to do it. > Making a simplification might bite us in the future. > > I suppose one way to get around the conditional application argument is t= o always use it to produce the CEK even with AEAD algorithms. > > Regards > John B. > > On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > >> Hi all, >> >> I was hoping someone could help me (hopefully it's not just me!) >> understand the reasons for the introduction of the key derivation >> stuff* into JWE draft -01? >> >> I understand that it's there to derive the two keys, CEK and CIK, from >> the CMK and that it is to be done when a non-AEAD algorithm is used to >> encrypt the content. But what is the value of deriving the two keys as >> apposed to using the CMK for both encryption and integrity? >> >> Perhaps naively I assumed that using the CMK for both would be >> sufficient. =A0It's randomly generated and used only for the one JWE. >> It's not clear to me what benefit is provided by the additional >> complexity of the derivation function as well as its conditional >> application (and the potential interoperability problems that come >> with such complexity). I assume there's some security benefit? But I >> can't see what it is. >> >> Any help would be appreciated. >> Thanks, >> Brian >> >> * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect= ion-7 >> which is referenced by >> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sectio= n-5 >> and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se= ction-6 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > From ietf@augustcellars.com Thu Apr 5 13:25:28 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0A21F8659 for ; Thu, 5 Apr 2012 13:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu6UfTv11MfZ for ; Thu, 5 Apr 2012 13:25:25 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9AB21F8652 for ; Thu, 5 Apr 2012 13:25:25 -0700 (PDT) Received: from Tobias (50-54-163-12.evrt.wa.frontiernet.net [50.54.163.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 56D9538EFC; Thu, 5 Apr 2012 13:25:24 -0700 (PDT) From: "Jim Schaad" To: "'Matt Miller'" , "'John Bradley'" References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> <4CD31FEA-9079-4964-A943-1AD6C69BAF92@ve7jtb.com> <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> In-Reply-To: <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> Date: Thu, 5 Apr 2012 13:24:32 -0700 Message-ID: <065201cd136a$1ca94990$55fbdcb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKHZrmAco3AbGqXh0I+g1KfPwtE7gGNJkrMAtHy7j4CTGAGGAIHYJz4Ai1qYyICy+gM6pSqpUCA Cc: 'Brian Campbell' , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:25:28 -0000 +1 to defining new AEAD algorithms that combine the necessary CBC + HMAC together. > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Matt Miller > Sent: Thursday, April 05, 2012 8:42 AM > To: John Bradley > Cc: Brian Campbell; jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Apr 5, 2012, at 09:12, John Bradley wrote: > > > > > On 2012-04-05, at 11:50 AM, Matt Miller wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> On Apr 5, 2012, at 08:28, John Bradley wrote: > >> > >>> A couple of observations. > >>> > >>> The current proposal provides integrity over the header, a new AEAD alg > doesn't do that. > >> > >> The current proposal does not provide this for existing AEAD algorithms. > > > > True that is an advantage the composite CBC + HMAC has over GCM. > > > > Maybe we should find a way to correct that. One possible solution is to use > the base64url-encoded header as the additional data (possibly truncated > based on algorithm requirements). > > >> > >>> Low level crypto is a challenge. Re-using standard underlying algorithms > like HMAC and AES-CBC allow for JS and other libs to call standard lower level > crypto functions. > >>> > >> > >> The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and > HMAC-SHA-256); it's not any more low-level than the non-AEAD path > specified in JWE. > > > > I will have another look at it. > >> > >>> I am not against having another AEAD alg, but want to help people > understand the current design choice. > >>> > >> > >> The benefit is to have a single path through the use of algorithms. It puts > the differences into the algorithm implementations, which is where they > should be. > >> > > There is no AES-CBC option without HMAC. Perhaps we should net be > calling it AES-CBC in JWA. > > > > I get there's no AES-CBC sans HMAC, and I completely agree that encryption > without integrity protection is not worth it. All I'm suggesting is we (or > someone) define an AEAD algorithm, say "AES-CBC-HMAC-SHA2-CONCAT- > KDF" or something, which pulls together the non-AEAD path from JWE into > its own algorithm. > > >>> John B. > >>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: > >>> > > > > > - - m&m > > Matt Miller - > Cisco Systems, Inc. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJPfb09AAoJEJq6Ou0cgrSPFQgIAObHB26bX7zdqcyzdWdMQ > YpA > H7JmkjMZSLCG1WMPUJWgg9w3+/SbxBkoTFKQC5SLzZrYXTErXD3sfzEXt5U5i/ > 2v > buvnqNd4ELZDsf3kosBmn6Y2h45DPlLVMT1JE2wbQDqfx6PZPdBISGdZYlPAqX > Wl > cMyLKdVIBYE/4ADa2Rwswnke3dLvv4vkJUzcItAeBA0khLzS25B1Q2JpunOSKM > yD > i0SPxEJ9aZHghxmjGQtQIU9DBI7kuvCap8eD9zYj6DPGoAnEKWMr/hoWUjMh > B7HH > wEVm6dKbmH7aTVSkl4suUnU2uclurmwCB42xDNPieULQy/2T2/oKU9ERwIm0 > M4k= > =dvxJ > -----END PGP SIGNATURE----- > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From bcampbell@pingidentity.com Thu Apr 5 14:06:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FF521F866B for ; Thu, 5 Apr 2012 14:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnLQJ-DkVQO9 for ; Thu, 5 Apr 2012 14:06:14 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id AD0C321F8686 for ; Thu, 5 Apr 2012 14:06:13 -0700 (PDT) Received: from mail-yw0-f46.google.com ([209.85.213.46]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKT34JQk4k4B2ZN0fezo2btP3Kw0aqEO27@postini.com; Thu, 05 Apr 2012 14:06:14 PDT Received: by yhmm54 with SMTP id m54so1007208yhm.19 for ; Thu, 05 Apr 2012 14:06:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=jGEkAoOf8cnwjUUMxDNiK7C/Yfgbj73WyKnImDHIHrA=; b=hoSSOG8Ble4SBT/XGqSCpmDWoHok0Koxnv/DNjeW+NJRoVIRkfcuI0nBehdLGH4iPT 2cnSSKEO/sr0oyO3/FqEhJ7faMh2/xLlFKsLgbabUTs23iu85uyNWom02RRdJdlT70gG ecvbX70YbKEc3aIcnrK0uULXBq/x32lZCqMJ0Zf+ngW2pPxppJE9YR9FQtHzJ0MtTSqG IHrN6l2L71q50fZwGe5/SHfbc2fK4RwsLtsAelZYUWB9GUug17O9qtiUupnrR8/86VXR 6ElBj7bqXNHTEKEwnhy9enNKuMR0VoKEiuNXqar2xB0v5lZcVmKTIhOPPdeudSZCrAAP RbYw== Received: by 10.236.193.68 with SMTP id j44mr4178163yhn.31.1333659969466; Thu, 05 Apr 2012 14:06:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Thu, 5 Apr 2012 14:05:39 -0700 (PDT) In-Reply-To: <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> From: Brian Campbell Date: Thu, 5 Apr 2012 15:05:39 -0600 Message-ID: To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmy1IDXbeE4jpH2oekCOG4+KB2mdbXT6UtJNrWY/0CNal0hmotBja8QAqUT6XATFvoIOiue Cc: Jim Schaad , jose@ietf.org, Matt Miller Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:06:16 -0000 Is it worth considering (I'm guessing the answer is no but what the heck) going the other direction and making the separate integrity check required regardless of the encryption algorithm? It would mean, when using GCM anyway, larger JWEs and also not utilizing the inherent integrity checks provided by that class of algorithm. But it would also mean a cleaner encapsulation of the algorithm from the JWE perspective and less conditional logic in JWE. Perhaps that suggestion might be more realistic if the separate integrity check was required but then also allowing the "none" option from the list of JWS cryptographic algorithms to be used for integrity in addition to the HMAC ones. And lastly, define some kind of mapping or requirements between the "enc" algo used and allowed or required "int" algorithms (i.e. "A256GCM" and "A128GCM" are the only ones that can be used with "none"). That would provide integrity protections, simplify the treatment of the various "enc" algorithms in JWT (no more conditionals on the algorithm), avoid defining composite algorithm identifiers (like A128CBC-H256), and also allow the AEAD to use their own integrity protections. Just some thoughts... On Thu, Apr 5, 2012 at 10:10 AM, John Bradley wrote: > Then we should look at including the header as the additional data for GC= M. > > I will have a look at it, and make a proposal for some text, unless someo= ne else is volunteering? > > John B. > > On 2012-04-05, at 1:05 PM, Jim Schaad wrote: > >> Ok - I see you problem. >> >> Yes, in JWE the headers are not encrypted. >> GCM provides integrity over both the encrypted content and the additiona= l >> data fields (hence the difference between AD (authenticated Data) and >> AEAD(Authenticated Data with Additional Data). >> >> All AEAD algorithms provide for the ability to have data which is not pa= rt >> of the encrypted data be included in the authenticated data. =A0In fact = AEAD >> algorithms can be used as MAC algorithms in many cases by simply having = an >> empty string for the encrypted data (it depends in part on the internal >> construction of the encrypted data stream). =A0I believe we verified tha= t this >> was a true statement for GCM at the last IETF meeting (in a hallway >> conversation). >> >> Jim >> >> >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Thursday, April 05, 2012 8:45 AM >>> To: Jim Schaad >>> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >>> Subject: Re: [jose] Understanding the motivation for Key Derivation? >>> >>> In JWE the headers are not encrypted. >>> >>> GCM provides integrity only over the encrypted content. >>> >>> In the composite AES-CBC + HMAC the integrity is calculated over both t= he >>> Header and the encrypted content. >>> >>> The advantage of not using a AEAD algorithm is that the composite can b= e >>> more JOSE aware. >>> >>> I can't rule out having missed something thats why we review these >> things:) >>> >>> John B. >>> On 2012-04-05, at 12:28 PM, Jim Schaad wrote: >>> >>>> >>>> >>>> John, >>>> >>>> I am at a loss, why do you believe that a new AEAD algorithm would not >>>> protect the headers? >>>> >>>> Jim >>>> >>>> >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>> Of >>>>> John Bradley >>>>> Sent: Thursday, April 05, 2012 7:28 AM >>>>> To: Matt Miller >>>>> Cc: Brian Campbell; jose@ietf.org >>>>> Subject: Re: [jose] Understanding the motivation for Key Derivation? >>>>> >>>>> A couple of observations. >>>>> >>>>> The current proposal provides integrity over the header, =A0a new AEA= D >> alg >>>>> doesn't do that. >>>>> Low level crypto is a challenge. =A0 Re-using standard underlying >> algorithms >>>> like >>>>> HMAC and AES-CBC allow for JS and other libs to call standard lower >> level >>>>> crypto functions. >>>>> >>>>> I am not against having another AEAD alg, =A0but want to help people >>>>> understand the current design choice. >>>>> >>>>> John B. >>>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Another way around the conditional in application-space is to define >> an >>>>> AEAD algorithm composed of an encryption and hashing function. =A0Thi= s >>>>> seems like a reasonable place to start looking at one: < >>>>> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. >>>>>> >>>>>> On Apr 4, 2012, at 17:42, John Bradley wrote: >>>>>> >>>>>>> The use of a single key across two functions is one of things that = is >>>> not >>>>> provably without problems. >>>>>>> >>>>>>> I agree that from an implementers point of view one key is simpler. >>>>>>> >>>>>>> There is a related-key attack that using the same key would enable. >>>> This >>>>> can be combined with differential and linear attacks on symmetric key >>>>> cyphers. >>>>>>> >>>>>>> Generally this can be thought of as a bad thing. >>>>>>> >>>>>>> What is certain is that it increases the possible attack surface, >> and >>>> if the is >>>>> a problem discovered as we have seen with AES-CBC it is going to be >> hard >>>> to >>>>> change later. >>>>>>> >>>>>>> We need key derivation anyway for ECDH-ES to produce a key of the >>>>> correct bit length. >>>>>>> >>>>>>> Doing key derivation on CMK is the theoretically proper way to do i= t. >>>>>>> Making a simplification might bite us in the future. >>>>>>> >>>>>>> I suppose one way to get around the conditional application argumen= t >>> is >>>>> to always use it to produce the CEK even with AEAD algorithms. >>>>>>> >>>>>>> Regards >>>>>>> John B. >>>>>>> >>>>>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I was hoping someone could help me (hopefully it's not just me!) >>>>>>>> understand the reasons for the introduction of the key derivation >>>>>>>> stuff* into JWE draft -01? >>>>>>>> >>>>>>>> I understand that it's there to derive the two keys, CEK and CIK, >>>>>>>> from the CMK and that it is to be done when a non-AEAD algorithm i= s >>>>>>>> used to encrypt the content. But what is the value of deriving the >>>>>>>> two keys as apposed to using the CMK for both encryption and >>>> integrity? >>>>>>>> >>>>>>>> Perhaps naively I assumed that using the CMK for both would be >>>>>>>> sufficient. =A0It's randomly generated and used only for the one J= WE. >>>>>>>> It's not clear to me what benefit is provided by the additional >>>>>>>> complexity of the derivation function as well as its conditional >>>>>>>> application (and the potential interoperability problems that come >>>>>>>> with such complexity). I assume there's some security benefit? But= I >>>>>>>> can't see what it is. >>>>>>>> >>>>>>>> Any help would be appreciated. >>>>>>>> Thanks, >>>>>>>> Brian >>>>>>>> >>>>>>>> * >>>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#= se >>>>>>>> ction-7 >>>>>>>> which is referenced by >>>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#= se >>>>>>>> ction-5 and >>>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#= se >>>>>>>> ction-6 _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>> >>>>>> >>>>>> - - m&m >>>>>> >>>>>> Matt Miller - >>>>>> Cisco Systems, Inc. >>>>>> >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>>> Comment: GPGTools - http://gpgtools.org >>>>>> >>>>>> >>>>> >>> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq >>>>> zQj >>>>>> >>>>> >>> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR >>>>> 8kx >>>>>> >>>>> >>> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL >>>>> y >>>>>> >>>>> >>> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb >>>>> + >>>>>> >>>>> >>> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb >>>>> Y >>>>>> >>>>> >>> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG >>>>> z/I=3D >>>>>> =3D174E >>>>>> -----END PGP SIGNATURE----- >>>> >>>> >> >> > From ietf@augustcellars.com Thu Apr 5 14:25:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94A621F8686 for ; Thu, 5 Apr 2012 14:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpEa0vH92nYZ for ; Thu, 5 Apr 2012 14:25:28 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id C6F3321F866B for ; Thu, 5 Apr 2012 14:25:28 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8E87938F3A; Thu, 5 Apr 2012 14:25:28 -0700 (PDT) From: "Jim Schaad" To: "'Matt Miller'" , "'John Bradley'" References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> <4CD31FEA-9079-4964-A943-1AD6C69BAF92@ve7jtb.com> <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> In-Reply-To: <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> Date: Thu, 5 Apr 2012 14:24:35 -0700 Message-ID: <066001cd1372$80957390$81c05ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKHZrmAco3AbGqXh0I+g1KfPwtE7gGNJkrMAtHy7j4CTGAGGAIHYJz4Ai1qYyICy+gM6pSqtB4Q Cc: 'Brian Campbell' , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:25:29 -0000 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Matt Miller > Sent: Thursday, April 05, 2012 8:42 AM > To: John Bradley > Cc: Brian Campbell; jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Apr 5, 2012, at 09:12, John Bradley wrote: > > > > > On 2012-04-05, at 11:50 AM, Matt Miller wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> On Apr 5, 2012, at 08:28, John Bradley wrote: > >> > >>> A couple of observations. > >>> > >>> The current proposal provides integrity over the header, a new AEAD alg > doesn't do that. > >> > >> The current proposal does not provide this for existing AEAD algorithms. > > > > True that is an advantage the composite CBC + HMAC has over GCM. > > > > Maybe we should find a way to correct that. One possible solution is to use > the base64url-encoded header as the additional data (possibly truncated > based on algorithm requirements). > > >> > >>> Low level crypto is a challenge. Re-using standard underlying algorithms > like HMAC and AES-CBC allow for JS and other libs to call standard lower level > crypto functions. > >>> > >> > >> The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and > HMAC-SHA-256); it's not any more low-level than the non-AEAD path > specified in JWE. > > > > I will have another look at it. > >> > >>> I am not against having another AEAD alg, but want to help people > understand the current design choice. > >>> > >> > >> The benefit is to have a single path through the use of algorithms. It puts > the differences into the algorithm implementations, which is where they > should be. > >> > > There is no AES-CBC option without HMAC. Perhaps we should net be > calling it AES-CBC in JWA. > > > > I get there's no AES-CBC sans HMAC, and I completely agree that encryption > without integrity protection is not worth it. All I'm suggesting is we (or > someone) define an AEAD algorithm, say "AES-CBC-HMAC-SHA2-CONCAT- > KDF" or something, which pulls together the non-AEAD path from JWE into > its own algorithm. Based on the fact that we are not placing the attributes for a given algorithm anyplace except at the top level, I think we can probably define AES-CBC (maybe with an -AEAD tag) as an AEAD encryption algorithm. The definition of the algorithm would then include the parameters "iv" and "int" as parameters of the algorithm. The int parameter would then define an HMAC algorithm (or any other MAC algorithm). It would make a great deal of sense in this case to limit the number of items that can occur in the int field for interoperability reasons. This reduces the number of algorithm names. Contra-wise (as says Tweedle-Dum) - I have no problems with creating a very limited number of AEAD algorithm labels that include the MAC algorithm as part of the name string. I don't see any reason to go overboard however and would say that two variations are probably more than is needed at this time. Jim > > >>> John B. > >>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: > >>> > > > > > - - m&m > > Matt Miller - > Cisco Systems, Inc. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJPfb09AAoJEJq6Ou0cgrSPFQgIAObHB26bX7zdqcyzdWdMQ > YpA > H7JmkjMZSLCG1WMPUJWgg9w3+/SbxBkoTFKQC5SLzZrYXTErXD3sfzEXt5U5i/ > 2v > buvnqNd4ELZDsf3kosBmn6Y2h45DPlLVMT1JE2wbQDqfx6PZPdBISGdZYlPAqX > Wl > cMyLKdVIBYE/4ADa2Rwswnke3dLvv4vkJUzcItAeBA0khLzS25B1Q2JpunOSKM > yD > i0SPxEJ9aZHghxmjGQtQIU9DBI7kuvCap8eD9zYj6DPGoAnEKWMr/hoWUjMh > B7HH > wEVm6dKbmH7aTVSkl4suUnU2uclurmwCB42xDNPieULQy/2T2/oKU9ERwIm0 > M4k= > =dvxJ > -----END PGP SIGNATURE----- > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Thu Apr 5 14:26:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189FE21F8629 for ; Thu, 5 Apr 2012 14:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGksWe6C1gkY for ; Thu, 5 Apr 2012 14:26:54 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91B7821F8610 for ; Thu, 5 Apr 2012 14:26:54 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 857502CA22; Thu, 5 Apr 2012 14:26:54 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" , "'Brian Campbell'" References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> In-Reply-To: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> Date: Thu, 5 Apr 2012 14:26:01 -0700 Message-ID: <066101cd1372$b3c60130$1b520390$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKHZrmAco3AbGqXh0I+g1KfPwtE7gGNJkrMlQuumSA= Cc: jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:26:55 -0000 Another reason is that the algorithms may use two different key sizes and thus you need to deal with the expansion/truncation questions. jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > John Bradley > Sent: Wednesday, April 04, 2012 4:42 PM > To: Brian Campbell > Cc: jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > The use of a single key across two functions is one of things that is not > provably without problems. > > I agree that from an implementers point of view one key is simpler. > > There is a related-key attack that using the same key would enable. This can > be combined with differential and linear attacks on symmetric key cyphers. > > Generally this can be thought of as a bad thing. > > What is certain is that it increases the possible attack surface, and if the is a > problem discovered as we have seen with AES-CBC it is going to be hard to > change later. > > We need key derivation anyway for ECDH-ES to produce a key of the correct > bit length. > > Doing key derivation on CMK is the theoretically proper way to do it. > Making a simplification might bite us in the future. > > I suppose one way to get around the conditional application argument is to > always use it to produce the CEK even with AEAD algorithms. > > Regards > John B. > > On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > > > Hi all, > > > > I was hoping someone could help me (hopefully it's not just me!) > > understand the reasons for the introduction of the key derivation > > stuff* into JWE draft -01? > > > > I understand that it's there to derive the two keys, CEK and CIK, from > > the CMK and that it is to be done when a non-AEAD algorithm is used to > > encrypt the content. But what is the value of deriving the two keys as > > apposed to using the CMK for both encryption and integrity? > > > > Perhaps naively I assumed that using the CMK for both would be > > sufficient. It's randomly generated and used only for the one JWE. > > It's not clear to me what benefit is provided by the additional > > complexity of the derivation function as well as its conditional > > application (and the potential interoperability problems that come > > with such complexity). I assume there's some security benefit? But I > > can't see what it is. > > > > Any help would be appreciated. > > Thanks, > > Brian > > > > * > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect > > ion-7 > > which is referenced by > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect > > ion-5 and > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect > > ion-6 _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose From bcampbell@pingidentity.com Thu Apr 5 14:57:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6216A21F85C2 for ; Thu, 5 Apr 2012 14:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqD-+DKW94ha for ; Thu, 5 Apr 2012 14:57:37 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 80B1121F85AD for ; Thu, 5 Apr 2012 14:57:36 -0700 (PDT) Received: from mail-gx0-f171.google.com ([209.85.161.171]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT34VT6zWZa+bms08pBzCXmJ6lA7Sk7+H@postini.com; Thu, 05 Apr 2012 14:57:36 PDT Received: by ggcs5 with SMTP id s5so1218575ggc.2 for ; Thu, 05 Apr 2012 14:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=WFZmD6uuTQfsPd6uEHenHWu9wnrigtFwzytYtpvo32s=; b=oYeg5ePItelX8CKhQyUnJ8IJbxZACTTfNnkqvxkZxVKl4JEKsRU9B7t344x+3qww0L 0glRKGCsYP7JfL8WZp+GdX0FqF3ul00Z2WYuee4vcivtOnDfuOmFmNcHiadWZq2obFmp GIY5xi3Z/5pON6pCya1lSRYMa29XRyR7B2WE5/L/QMe7+PQkDIRkmagKc/GKKaxPIMDA sgbwQChJJ585CmBK7Fsdt2cVLhcS2nfFYFUFZc/v9pNoU0smxeuznwZSVfUQ9dKtAJUK aFu6aveHP6eY5i/wBmFTE5i9ZdS0VEhnRX7GHWv8WrTBDbt5nIvtIjqX8GXy9CHRLuSL RDDA== Received: by 10.236.193.68 with SMTP id j44mr4366153yhn.31.1333663055213; Thu, 05 Apr 2012 14:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Thu, 5 Apr 2012 14:57:04 -0700 (PDT) In-Reply-To: References: <20120405071758.cc40c4f3d92d2001859047cd8cabb9ab.b5b15f820c.wbe@email07.europe.secureserver.net> From: Brian Campbell Date: Thu, 5 Apr 2012 15:57:04 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=20cf305b0c64a7f69c04bcf5a03d X-Gm-Message-State: ALoCoQkQwGH4o+dejdfs7YMDsKecV+sZAAOpyTJV7kND2Rw0IX1p5t2iPWzzhtJKxbKjmno6yIb1 Cc: juraj.somorovsky@rub.de, Axel.Nennker@telekom.de, jose@ietf.org, Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:57:38 -0000 --20cf305b0c64a7f69c04bcf5a03d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From a developers perspective I will note that OAEP is required by SAML 2.0 Conformance* (because of XML Encryption**). SAML isn't ubiquitous by any means but has been implemented on a number of different platforms/languages which would suggest that OAEP availability is pretty widespread. I know, for example, that the standard Java JCA has had it for many years. * =A74.2 of http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf ** =A75.1 at http://www.w3.org/TR/xmlenc-core/#sec-AlgID On Thu, Apr 5, 2012 at 8:51 AM, John Bradley wrote: > I have been pro OAEP for a long time. I think we had OAEP as the default > in the earlier JSS spec. > > The question always comes back to deployability. PKCS#1_5 is available > more places. > > I am interested in peoples opinions especialy developers and library > people. > > John B. > On 2012-04-05, at 11:17 AM, Vladimir Dzhuvinov / NimbusDS wrote: > > > +1 in favour of deprecating RSA1_5 in favour of OAEP. > > > > On Thu, 2012-04-05 at 13:04 +0000, Mike Scott wrote: > >> Hello Vladimir, > >> > >> I would recommend OAEP. As I recall there were some obscure attacks on > earlier proposals from RSA. > >> > >> Mike > > > > -- > > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > > > > > > > > -------- Original Message -------- > > Subject: Re: [jose] JWT + JOSE for Java > > From: "Vladimir Dzhuvinov / NimbusDS" > > Date: Thu, April 05, 2012 2:03 pm > > To: Axel.Nennker@telekom.de, juraj.somorovsky@rub.de > > Cc: jose@ietf.org > > > > Hallo Berlin, hallo Bochum, hallo Welt! :) > > > > I just sent an email to a crypto expert at a partner company to ask for > > his opinion is on that. My feeling is that when we collect sufficient > > opinions on that the "truth" will eventually emerge :) > > > > As mentioned, I don't have a proper crypto background, so during > > refactoring I made sure Axel's code remained just as it was. > > > > > > Vladimir > > > > -- > > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > > > > > > > > > > -------- Original Message -------- > > Subject: Re: [jose] JWT + JOSE for Java > > From: > > Date: Thu, April 05, 2012 1:00 pm > > To: , > > Cc: jose@ietf.org > > > > > > Hi Juraj, > > > > As Vladimir's work is based on my implementation I guess that my > > implementation has room for improvement too. > > > https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap= /json/WebToken.java > > > > ENC_ALG_RSA_OAEP is better than ENC_ALG_RSA1_5. > > > https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap= /json/WebToken.java#116 > > > > Both padding algorithms are supported by my code and this RSA bulletin > > mentions OAEP as one counter measure against the Bleichenbacher attack. > > ftp://ftp.rsasecurity.com/pub/pdfs/bulletn7.pdf > > > > Does "your" attack work against ENC_ALG_RSA_OAEP too? Additional counte= r > > measures suggestions are very welcome. > > > > RSA1_5 is in the proposed standard because it is widely available > > although RSA recommends to use OAEP for decades. > > I think that RSA-OAEP should be mandatory to implement and RSA1_5 > > deprecated. > > > > Cheers. Greetings from Berlin to Bochum. > > Axel > > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Juraj Somorovsky > > Sent: Thursday, April 05, 2012 1:13 AM > > To: vladimir@nimbusds.com > > Cc: jose@ietf.org > > Subject: Re: [jose] JWT + JOSE for Java > > > > Hi Vladimir, > > > > I have took a look at your implementation and found out, that your PKCS= 1 > > handling is vulnerable to the Bleichenbacher attack (the adversary coul= d > > be able to issue different ciphertexts, send them to the server, and > > according to its responses he could learn the encrypted CEK) > > > > I will send you PoCs and instructions how to fix it by tomorrow...or > > just take a look at the document written by Eric Rescorla: > > http://www.ietf.org/rfc/rfc3218.txt > > > > Regards > > Juraj > > > > On 04/03/2012 11:24 AM, Vladimir Dzhuvinov / NimbusDS wrote: > >> Today I reached a point in my JWT+JOSE library implementation where I > >> wouldn't feel ashamed to release it to the public :) > >> > >> https://github.com/NimbusDS/Nimbus-JWT > >> > >> The library is fully documented: > >> http://nimbusds.com/files/jwt/javadoc/index.html > >> > >> > >> The Nimbus-JWT library started a month ago from code borrowed from > >> Axel Nennker's + Co OpenInfoCard project and at this point covers > >> fully plain and signed JWTs as well as JSON Web Keys (JWK). The JWE > >> implementation still requires a bit of work to add HMAC integrity and > >> cover the remaining elliptic curve and key-wrap encryption algorithms > >> from the JWA spec. I would be very thankful if somebody could help me > >> with that as I don't have much experience with cryptography :) > >> > >> For the listing of the supported JWAs: > >> http://nimbusds.com/files/jwt/javadoc/com/nimbusds/jwt/JWA.html > >> > >> Cheers, > >> > >> Vladimir > >> -- > >> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > > -- > > M.Sc. Juraj Somorovsky > > > > Lehrstuhl f=FCr Netz- und Datensicherheit > > Ruhr Universit=E4t Bochum > > ----------------------------------- > > Universit=E4tsstr. 150, Geb. ID 2/411 > > D-44780 Bochum > > > > Telefon: +49 (0) 234 / 32-26551 > > Fax: +49 (0) 234 / 32-14347 > > http://www.nds.rub.de > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --20cf305b0c64a7f69c04bcf5a03d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From a developers perspective I will note that OAEP is required by SAML 2.0= Conformance* (because of XML Encryption**). SAML isn't ubiquitous by a= ny means but has been implemented on a number of different platforms/langua= ges which would suggest that OAEP availability is pretty widespread. I know= , for example, that the standard Java JCA has had it for many years.

* =A74.2 of http://docs.oasis-open.org/security/saml/v2.0/sa= ml-conformance-2.0-os.pdf
** =A75.1 at http://www.w3.org/TR/xmlenc-core/#sec-AlgID<= br>


On Thu, Apr 5, 2012 at 8:51 AM, John= Bradley <ve7jtb@= ve7jtb.com> wrote:
I have been pro OAEP for a long time. =A0I think we had OAEP as the default= in the earlier JSS spec.

The question always comes back to deployability. =A0 PKCS#1_5 is available = more places.

I am interested in peoples opinions especialy developers and library people= .

John B.
On 2012-04-05, at 11:17 AM, Vladimi= r Dzhuvinov / NimbusDS wrote:

> +1 in favour of deprecating RSA1_5 in favour of OAEP.
>
> On Thu, 2012-04-05 at 13:04 +0000, Mike Scott wrote:
>> Hello Vladimir,
>>
>> I would recommend OAEP. As I recall there were some obscure attack= s on earlier proposals from RSA.
>>
>> Mike
>
> --
> Vladimir Dzhuvinov : www.NimbusDS.com : vladim= ir@nimbusds.com
>
>
>
>
> -------- Original Message --------
> Subject: Re: [jose] JWT + JOSE for Java
> From: "Vladimir Dzhuvinov / NimbusDS" <vladimir@nimbusds.com>
> Date: Thu, April 05, 2012 2:03 pm
> To: Axel.Nennker@telekom.de= , juraj.somorovsky@rub.de
> Cc: jose@ietf.org
>
> Hallo Berlin, hallo Bochum, hallo Welt! :)
>
> I just sent an email to a crypto expert at a partner company to ask fo= r
> his opinion is on that. My feeling is that when we collect sufficient<= br> > opinions on that the "truth" will eventually emerge :)
>
> As mentioned, I don't have a proper crypto background, so during > refactoring I made sure Axel's code remained just as it was.
>
>
> Vladimir
>
> --
> Vladimir Dzhuvinov : www.NimbusDS.com : vladim= ir@nimbusds.com
>
>
>
>
>
> -------- Original Message --------
> Subject: Re: [jose] JWT + JOSE for Java
> From: <Axel.Nennker@tele= kom.de>
> Date: Thu, April 05, 2012 1:00 pm
> To: <juraj.somorovsky@ru= b.de>, <vladimir@nimbusd= s.com>
> Cc: jose@ietf.org
>
>
> Hi Juraj,
>
> As Vladimir's work is based on my implementation I guess that my > implementation has room for improvement too.
> https://code.google.co= m/p/openinfocard/source/browse/trunk/src/org/xmldap/json/WebToken.java<= br> >
> ENC_ALG_RSA_OAEP is better than ENC_ALG_RSA1_5.
> https://code.googl= e.com/p/openinfocard/source/browse/trunk/src/org/xmldap/json/WebToken.java#= 116
>
> Both padding algorithms are supported by my code and this RSA bulletin=
> mentions OAEP as one counter measure against the Bleichenbacher attack= .
> ftp://ftp.rsasecurity.com/pub/pdfs/bulletn7.pdf
>
> Does "your" attack work against ENC_ALG_RSA_OAEP too? Additi= onal counter
> measures suggestions are very welcome.
>
> RSA1_5 is in the proposed standard because it is widely available
> although RSA recommends to use OAEP for decades.
> I think that RSA-OAEP should be mandatory to implement and RSA1_5
> deprecated.
>
> Cheers. Greetings from Berlin to Bochum.
> Axel
>
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Juraj Somorovsky
> Sent: Thursday, April 05, 2012 1:13 AM
> To: vladimir@nimbusds.com=
> Cc: jose@ietf.org
> Subject: Re: [jose] JWT + JOSE for Java
>
> Hi Vladimir,
>
> I have took a look at your implementation and found out, that your PKC= S1
> handling is vulnerable to the Bleichenbacher attack (the adversary cou= ld
> be able to issue different ciphertexts, send them to the server, and > according to its responses he could learn the encrypted CEK)
>
> I will send you PoCs and instructions how to fix it by tomorrow...or > just take a look at the document written by Eric Rescorla:
> http= ://www.ietf.org/rfc/rfc3218.txt
>
> Regards
> Juraj
>
> On 04/03/2012 11:24 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> Today I reached a point in my JWT+JOSE library implementation wher= e I
>> wouldn't feel ashamed to release it to the public :)
>>
>> https://github.com/NimbusDS/Nimbus-JWT
>>
>> The library is fully documented:
>> http://nimbusds.com/files/jwt/javadoc/index.html
>>
>>
>> The Nimbus-JWT library started a month ago from code borrowed from=
>> Axel Nennker's + Co OpenInfoCard project and at this point cov= ers
>> fully plain and signed JWTs as well as JSON Web Keys (JWK). The JW= E
>> implementation still requires a bit of work to add HMAC integrity = and
>> cover the remaining elliptic curve and key-wrap encryption algorit= hms
>> from the JWA spec. I would be very thankful if somebody could help= me
>> with that as I don't have much experience with cryptography :)=
>>
>> For the listing of the supported JWAs:
>> http://nimbusds.com/files/jwt/javadoc/com/nimbu= sds/jwt/JWA.html
>>
>> Cheers,
>>
>> Vladimir
>> --
>> Vladimir Dzhuvinov : www.NimbusDS.com : vl= adimir@nimbusds.com
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>
> --
> M.Sc. Juraj Somorovsky
>
> Lehrstuhl f=FCr Netz- und Datensicherheit
> Ruhr Universit=E4t Bochum
> -----------------------------------
> Universit=E4tsstr. 150, Geb. ID 2/411
> D-44780 Bochum
>
> Telefon: +49 (0) 234 / 32-26551
> Fax: +49 (0) 234 / 32-14347
> http://www.nds.rub= .de
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


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


--20cf305b0c64a7f69c04bcf5a03d-- From Michael.Jones@microsoft.com Thu Apr 5 15:18:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FAA21F85C0 for ; Thu, 5 Apr 2012 15:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ9iRdwhecbB for ; Thu, 5 Apr 2012 15:18:54 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1F76221F85BD for ; Thu, 5 Apr 2012 15:18:54 -0700 (PDT) Received: from mail19-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 22:18:53 +0000 Received: from mail19-db3 (localhost [127.0.0.1]) by mail19-db3-R.bigfish.com (Postfix) with ESMTP id 352D720236; Thu, 5 Apr 2012 22:18:53 +0000 (UTC) X-SpamScore: -46 X-BigFish: VS-46(zz154cP9371I936eK542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail19-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail19-db3 (localhost.localdomain [127.0.0.1]) by mail19-db3 (MessageSwitch) id 1333664331895759_14556; Thu, 5 Apr 2012 22:18:51 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.246]) by mail19-db3.bigfish.com (Postfix) with ESMTP id D7E3530004B; Thu, 5 Apr 2012 22:18:51 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 22:18:51 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0283.004; Thu, 5 Apr 2012 22:18:17 +0000 From: Mike Jones To: Jim Schaad , 'Matt Miller' , 'John Bradley' Thread-Topic: [jose] Understanding the motivation for Key Derivation? Thread-Index: AQHNErQOZlMb1ahKqUiwv3kEv/baLJaLU7cAgADcGICAABt4AIAABlCAgAAF7ICAAAhOAIAATv4AgAAeUrA= Date: Thu, 5 Apr 2012 22:18:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436645BD13@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <4837CEA5-CF8F-4B5C-AAE9-77C9BCE11775@cisco.com> <4CD31FEA-9079-4964-A943-1AD6C69BAF92@ve7jtb.com> <1E3DAA3F-8AFC-4194-831F-6F895AD77933@cisco.com> <065201cd136a$1ca94990$55fbdcb0$@augustcellars.com> In-Reply-To: <065201cd136a$1ca94990$55fbdcb0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: 'Brian Campbell' , "jose@ietf.org" Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 22:18:55 -0000 As an individual, I'm not against an IETF security working group defining s= uch algorithms, but it would seem to me that these should be separate RFC(s= ) from JWE, both as they have broader applicability, and because they are n= ot essential to the JWE functionality. Once they are approved, they could = easily be added to the set of supported algorithms in in the JWA spec. But= I worry about coupling the JWE spec to this largely orthogonal encryption = algorithm work. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Thursday, April 05, 2012 1:25 PM To: 'Matt Miller'; 'John Bradley' Cc: 'Brian Campbell'; jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? +1 to defining new AEAD algorithms that combine the necessary CBC +=20 +HMAC together. > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Matt Miller > Sent: Thursday, April 05, 2012 8:42 AM > To: John Bradley > Cc: Brian Campbell; jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On Apr 5, 2012, at 09:12, John Bradley wrote: >=20 > > > > On 2012-04-05, at 11:50 AM, Matt Miller wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> On Apr 5, 2012, at 08:28, John Bradley wrote: > >> > >>> A couple of observations. > >>> > >>> The current proposal provides integrity over the header, a new=20 > >>> AEAD alg > doesn't do that. > >> > >> The current proposal does not provide this for existing AEAD algorithms. > > > > True that is an advantage the composite CBC + HMAC has over GCM. > > >=20 > Maybe we should find a way to correct that. One possible solution is=20 > to use > the base64url-encoded header as the additional data (possibly=20 > truncated based on algorithm requirements). >=20 > >> > >>> Low level crypto is a challenge. Re-using standard underlying algorithms > like HMAC and AES-CBC allow for JS and other libs to call standard=20 > lower level > crypto functions. > >>> > >> > >> The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256=20 > >> and > HMAC-SHA-256); it's not any more low-level than the non-AEAD path=20 > specified in JWE. > > > > I will have another look at it. > >> > >>> I am not against having another AEAD alg, but want to help people > understand the current design choice. > >>> > >> > >> The benefit is to have a single path through the use of algorithms. =20 > >> It puts > the differences into the algorithm implementations, which is where=20 > they should be. > >> > > There is no AES-CBC option without HMAC. Perhaps we should net be > calling it AES-CBC in JWA. > > >=20 > I get there's no AES-CBC sans HMAC, and I completely agree that=20 > encryption without integrity protection is not worth it. All I'm=20 > suggesting is we (or > someone) define an AEAD algorithm, say "AES-CBC-HMAC-SHA2-CONCAT- KDF"=20 > or something, which pulls together the non-AEAD path from JWE into its=20 > own algorithm. >=20 > >>> John B. > >>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: > >>> > > >=20 >=20 > - - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBAgAGBQJPfb09AAoJEJq6Ou0cgrSPFQgIAObHB26bX7zdqcyzdWdMQ > YpA > H7JmkjMZSLCG1WMPUJWgg9w3+/SbxBkoTFKQC5SLzZrYXTErXD3sfzEXt5U5i/ > 2v > buvnqNd4ELZDsf3kosBmn6Y2h45DPlLVMT1JE2wbQDqfx6PZPdBISGdZYlPAqX > Wl > cMyLKdVIBYE/4ADa2Rwswnke3dLvv4vkJUzcItAeBA0khLzS25B1Q2JpunOSKM > yD > i0SPxEJ9aZHghxmjGQtQIU9DBI7kuvCap8eD9zYj6DPGoAnEKWMr/hoWUjMh > B7HH > wEVm6dKbmH7aTVSkl4suUnU2uclurmwCB42xDNPieULQy/2T2/oKU9ERwIm0 > M4k=3D > =3DdvxJ > -----END PGP SIGNATURE----- > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Thu Apr 5 16:56:45 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C3A21F85D0 for ; Thu, 5 Apr 2012 16:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wddOJ2nY+UGk for ; Thu, 5 Apr 2012 16:56:44 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2A21621F85CE for ; Thu, 5 Apr 2012 16:56:43 -0700 (PDT) Received: from mail154-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 23:56:43 +0000 Received: from mail154-ch1 (localhost [127.0.0.1]) by mail154-ch1-R.bigfish.com (Postfix) with ESMTP id 9C0EF160579 for ; Thu, 5 Apr 2012 23:56:43 +0000 (UTC) X-SpamScore: -6 X-BigFish: VS-6(zzc85fhzz1202hzz8275bh30d1K8275dh5eeeKz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail154-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail154-ch1 (localhost.localdomain [127.0.0.1]) by mail154-ch1 (MessageSwitch) id 133367020257956_11657; Thu, 5 Apr 2012 23:56:42 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail154-ch1.bigfish.com (Postfix) with ESMTP id 0C6C9220054 for ; Thu, 5 Apr 2012 23:56:42 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 23:56:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0283.004; Thu, 5 Apr 2012 23:56:41 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Open Issue for WG Discussion: Minimum key size for RSA signature Thread-Index: Ac0Th75vmoQ0AIB5Twqk9DXuD03g3g== Date: Thu, 5 Apr 2012 23:56:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436645BFC4@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436645BFC4TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Open Issue for WG Discussion: Minimum key size for RSA signature X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 23:56:45 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436645BFC4TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The JWA spec currently says that "A 2048-bit or longer key length MUST be u= sed with this algorithm" about RSA key sizes. During the meeting in Paris,= Eric Rescorla pointed out that 1024 bit keys are commonly used and ask whe= ther we wanted to allow them. The background for the current 2048 bit requirement is that NIST deprecated= the use of 1024 bit keys at the end of 2010 and disallowed their use after= 2013 (see Section 3 of NIST Special Publication 800-131A, Table 2 on p. 5 = and the discussion that follows on p. 6 - http://csrc.nist.gov/publications= /nistpubs/800-131A/sp800-131A.pdf). Given 2013 is right around the corner in standards time, does anyone want t= o make the case that we need to allow key lengths shorter than 2048 bits in= the standard? -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436645BFC4TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The JWA spec currently says that “A 2048-bit o= r longer key length MUST be used with this algorithm” about RSA key s= izes.  During the meeting in Paris, Eric Rescorla pointed out that 102= 4 bit keys are commonly used and ask whether we wanted to allow them.

 

The background for the current 2048 bit requirement = is that NIST deprecated the use of 1024 bit keys at the end of 2010 and dis= allowed their use after 2013 (see Section 3 of NIST Special Publication 800= -131A, Table 2 on p. 5 and the discussion that follows on p. 6 - http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf).

 

Given 2013 is right around the corner in standards t= ime, does anyone want to make the case that we need to allow key lengths sh= orter than 2048 bits in the standard?

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436645BFC4TK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Thu Apr 5 17:05:54 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CB721F871A for ; Thu, 5 Apr 2012 17:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXtP89j4qoNN for ; Thu, 5 Apr 2012 17:05:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3C7221F866B for ; Thu, 5 Apr 2012 17:05:52 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1212681ghb.31 for ; Thu, 05 Apr 2012 17:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=UjmlRCCiC18GX/GksOu8jcKzxcqUzgSP4V+Ldm2wbXM=; b=PhTmZlqubFPeIHeWKtP0ieBUbOlH4gcI1Ql/BB9I3NgOTfS9DRgmE2QdVcP6OKOJxf kQJb2oj5ZqaN6wIBztofHkOlRtQjK19ZlkdZNjCyu6FLD0p9tMOZ9VeXCASNWKwTmlVE MKy5h0Y1GqnYDKM7NIKWTIutZpnGdC8MbAFubXLbuCqi/WN3GS5MEkU389c+lGlIcn0+ VTpCvM+NESb8Uta3VaJ+vaU/O8PAERFKIvNUxknKtVwZNm+60+YmUzy6h9Rss1HTcBwB 6NzcvzURSn3KbwYuBiDDa4eIvtU5pXbb4YODSwgPByE8HNqQP9ASDWHvEp2nJcp3LC0v kWcQ== Received: by 10.236.109.66 with SMTP id r42mr4648476yhg.39.1333670752399; Thu, 05 Apr 2012 17:05:52 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id d25sm20850441yhe.4.2012.04.05.17.05.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 17:05:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_C5C1DEDC-2317-4F8B-82DD-8D7ECB6D9491"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436645BFC4@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 5 Apr 2012 21:05:39 -0300 Message-Id: <840C9C71-25A7-4460-87AE-A070E5ADA379@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436645BFC4@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkOXNDdOKPdnpGtSflMs4UA/WRWZTrD509BsDoTRO5ZTconFR9P09hLjKM86QvTrVpBkoME Cc: "jose@ietf.org" Subject: Re: [jose] Open Issue for WG Discussion: Minimum key size for RSA signature X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 00:05:54 -0000 --Apple-Mail=_C5C1DEDC-2317-4F8B-82DD-8D7ECB6D9491 Content-Type: multipart/alternative; boundary="Apple-Mail=_15FB278F-A3FD-4081-BDE4-3BC9E04DE5CA" --Apple-Mail=_15FB278F-A3FD-4081-BDE4-3BC9E04DE5CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1024bit keys are commonly used to verify existing documents. They are = also used in older systems and to communicate with older systems. If you unwind the NIST and FIPS tangle any new systems being deployed = MUST be capable of using 2048 or greater key sizes for signing. We are in the lucky position of not having a legacy JOSE infrastructure = to worry about. Let's not decide to add algorithms that are already = deprecated. John B. On 2012-04-05, at 8:56 PM, Mike Jones wrote: > The JWA spec currently says that =93A 2048-bit or longer key length = MUST be used with this algorithm=94 about RSA key sizes. During the = meeting in Paris, Eric Rescorla pointed out that 1024 bit keys are = commonly used and ask whether we wanted to allow them. > =20 > The background for the current 2048 bit requirement is that NIST = deprecated the use of 1024 bit keys at the end of 2010 and disallowed = their use after 2013 (see Section 3 of NIST Special Publication = 800-131A, Table 2 on p. 5 and the discussion that follows on p. 6 - = http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf). > =20 > Given 2013 is right around the corner in standards time, does anyone = want to make the case that we need to allow key lengths shorter than = 2048 bits in the standard? > =20 > -- = Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_15FB278F-A3FD-4081-BDE4-3BC9E04DE5CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 1024bit keys are commonly used to verify existing = documents.  They are also used in older systems and to communicate = with older systems.

If you unwind the NIST and FIPS = tangle any new systems being deployed MUST be capable of using 2048 or = greater key sizes for signing.

We are in the = lucky position of not having a legacy JOSE infrastructure to worry = about.  Let's not decide to add algorithms that are already = deprecated.

John B.
On 2012-04-05, = at 8:56 PM, Mike Jones wrote:

The JWA spec currently says = that =93A 2048-bit or longer key length MUST be used with this = algorithm=94 about RSA key sizes.  During the meeting in Paris, = Eric Rescorla pointed out that 1024 bit keys are commonly used and ask = whether we wanted to allow them.
The background for the current 2048 = bit requirement is that NIST deprecated the use of 1024 bit keys at the = end of 2010 and disallowed their use after 2013 (see Section 3 of NIST = Special Publication 800-131A, Table 2 on p. 5 and the discussion that = follows on p. 6 -  
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 06:10:24 -0000 SSB0aGluayB5b3UgYXJlIGFyZ3Vpbmcgb24gYSBwcm90b2NvbCBsZXZlbCAobGlrZSBTU0wpIGJ1 dCB0aGlzIGlzIG5vdCBob3cgSSB1bmRlcnN0YW5kIEpPU0UuIA0KSlNPTiBFbmNyeXB0aW9uIGFu ZCBTaWduaW5nIGRlZmluZXMgZm9ybWF0cyBhbmQgc3VnZ2VzdHMgd2hpY2ggYWxnb3JpdGhtcyB0 byB1c2UuDQpXZSBkbyBub3QgZGVmaW5lIHRoaW5ncyBsaWtlICJ5b3Ugc2hvdWxkIGNoYW5nZSB5 b3VyIGtleXMgYWZ0ZXIgbiBvcGVyYXRpb25zIG9yIE4gbWVnYWJ5dGVzIG9mIHBsYWludGV4dCBw cm9jZXNzZWQgKG9yIHdoZW4gYSBCYWRQYWRkaW5nIEV4Y2VwdGlvbiBpcyB0aHJvd24pLiBJIHRo aW5rIHRoYXQgbXkgY29kZSBzaG91bGQgdGhyb3cgYWxsIGV4Y2VwdGlvbnMgaW4gYWxsIHRoZWly IGdsb3J5IGRldGFpbHMgYW5kIHRoYXQgZS5nLiB0aGUgYXBwbGljYXRpb24gc2VydmVyICJhYm92 ZSIgbWUgc2hvdWxkIHRoZW4gZGVjaWRlIHdoaWNoIGFjdGlvbiB0byB0YWtlOiBsaWtlICJHaXZl IGEgc3RhbmRhcmQgZXJyb3IgbWVzc2FnZSIgdG8gdGhlIHNlbmRlciBvZiB0aGUgYmFkIG1lc3Nh Z2UgYW5kIHdhaXQgYSByYW5kb20gYW1vdW50IG9mIHRpbWUgYmVmb3JlIHNlbmRpbmcgZXJyb3Ig bWVzc2FnZXMuIEJ1dCB0aGlzIGlzIG5vdCB0aGUgdGFzayBvZiB0aGlzIGNvZGUuDQpodHRwczov L2NvZGUuZ29vZ2xlLmNvbS9wL29wZW5pbmZvY2FyZC9zb3VyY2UvYnJvd3NlL3RydW5rL3NyYy9v cmcveG1sZGFwL2pzb24vV2ViVG9rZW4uamF2YSANCg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg bGV2ZWwgdGhhdCB3ZSBhcmUgZGVzY3JpYmluZyBoZXJlIGlzICJiZWxvdyIgcHJvdG9jb2xzLg0K QWx0aG91Z2ggSSBnaXZlIGl0IHRvIHlvdSB0aGF0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uIHNob3VsZCByZWNvbW1lbmQgdXNhZ2Ugb2YgdGhlIGZvcm1hdHMgYW5kIGFsZ29y aXRobXMgZGVmaW5lZCBoZXJlIGFuZCBkaXNjb3VyYWdlIGNlcnRhaW4gdXNlcy4NCg0KSSBmZWFy IHRoYXQgd2UgZW5kIHVwIGluIGEgZGlzY3Vzc2lvbiB0aGF0IEkgZm9sbG93ZWQgaW4gdGhlIE5T UyBkaXNjdXNzaW9uIGdyb3VwIHllYXJzIGFnby4gIlNob3VsZCB3ZSBnaXZlIGRldmVsb3BlcnMg Y3J5cHRvZ3JhcGhpYyBidWlsZGluZyBibG9ja3MgdGhhdCBjb3VsZCBiZSB1c2VkIHdyb25nIi4g VGhlbiBOU1MgZGVjaWRlZCAgbm90IHRvIGRvIGl0IGJ1dCBJIHRoaW5rIHRoYXQgd2FzIHdyb25n Lg0KDQpJIHRoaW5rIHRoYXQgdGhlIHByb3RvY29scyB0aGF0IHVzZSB0aGUgSk9TRSBmb3JtYXRz L2FsZ3MgbGlrZSBvcGVuaWQgY29ubmVjdCAoaHR0cHM6Ly9vcGVuaWQubmV0L2Nvbm5lY3QvKSBo YXZlIHRoZSBkdXR5IHRvIHVzZSB0aGVtIGNvcnJlY3RseS4gWW91ciBhZHZpY2Ugb24gaG93IHRv IG1ha2Ugb3BlbmlkIGNvbm5lY3Qgc2VjdXJlIGlzIHZlcnkgd2VsY29tZS4gUGxlYXNlIGFuYWx5 emUgaXQgYW5kIHRlbGwgdXMgeW91ciBmaW5kaW5ncy4gaHR0cDovL2xpc3RzLm9wZW5pZC5uZXQv cGlwZXJtYWlsL29wZW5pZC1zcGVjcy1hYi8gDQoNCkF4ZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEp1cmFqIFNvbW9yb3Zza3kgW21haWx0bzpqdXJhai5zb21vcm92c2t5 QHJ1Yi5kZV0gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTIgNTozMCBQTQ0KVG86IFZs YWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTDQpDYzogTmVubmtlciwgQXhlbDsgam9zZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBKV1QgKyBKT1NFIGZvciBKYXZhDQoNCkhpIDopDQoN Cm9rLCBJJ2xsIHRyeSB0byBleHBsYWluIHRoZSBCbGVpY2hlbmJhY2hlciBhdHRhY2sgaW4gZmV3 IHNlbnRlbmNlcy4uLg0KDQpJZiB5b3UgY29uc3RydWN0IHlvdXIgY2lwaGVydGV4dCB1c2luZyBQ S0NTMSwgeW91IHRha2UgeW91ciBzeW1tZXRyaWMga2V5IENFSyBhbmQgeW91IHBhZGQgaXQgd2l0 aCBzb21lIGJ5dGVzIHRvIGFjaGlldmUgYSBnaXZlbiBtZXNzYWdlIGxlbmd0aC4uLiBpdCBsb29r cyBsaWtlIHRoaXM6DQoweDAwIDB4MDIgLi4uIHJhbmRvbSBieXRlcyAoZXhjZXB0IGZvciAweDAw KSAuLi4gMHgwMCBDRUsNCg0KWW91IGNhbiBlbmNyeXB0IHRoaXMgbWVzc2FnZSB1c2luZyB0aGUg c2VydmVyJ3MgcHVibGljIGtleS4NCg0KT24gdGhlIGRlY3J5cHRvcidzIHNpZGUsIHRoZSBzZXJ2 ZXIgdHJpZXMgdG8gZXh0cmFjdCBDRUsuIEl0IGRlY3J5cHRzIHRoZSBtZXNzYWdlIHVzaW5nIGl0 cyBSU0EgcHJpdmF0ZSBrZXkgYW5kICpjaGVja3MgdGhlIG1lc3NhZ2UgcGFkZGluZw0KZm9ybWF0 KiAoMHgwMCAweDAyIC4uLiAweDAwIENFSykuIEFmdGVyd2FyZHMsIGl0IHRha2VzIENFSy4NCg0K VGhlIHByb2JsZW0gaXM6IGlmIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgZGlmZmVyZW50bHkgYWNjb3Jk aW5nIHRvIHRoZQ0KUEtDUzEgcGFkZGluZyB2YWxpZGl0eSwgdGhlIGF0dGFja2VyIGNhbiBsZWFy biBzb21lIGJpdHMgb2YgdGhlIHBsYWludGV4dC4gQnkgc2VuZGluZyBhIGh1Z2UgYW1vdW50IG9m IG1lc3NhZ2VzIChhYm91dCAxLDAwMCwwMDAgb3IgbW9yZS4uLnRoaXMgZGVwZW5kcyBvbiB0aGUg c2VydmVyIG1lc3NhZ2UgY2hlY2sgYW5kIHRoZSB0cmFuc21pdHRlZCBtZXNzYWdlKSwgaGUgY2Fu IGxlYXJuIHRoZSBzZWN1cmVkIENFSyBhbmQgdGh1cyBkZWNyeXB0IHRoZSB3aG9sZSBtZXNzYWdl Lg0KDQoNCldoZW4gbG9va2luZyBhdCBib3RoIHlvdXIgY29kZXMsIEkgc2VlIHR3byBwcm9ibGVt czoNCg0KY2FzZSBSU0ExXzU6DQoJQ2lwaGVyIGNpcGhlciA9IENpcGhlci5nZXRJbnN0YW5jZSgi UlNBL0VDQi9QS0NTMVBhZGRpbmciKTsNCgljaXBoZXIuaW5pdChDaXBoZXIuREVDUllQVF9NT0RF LCByc2FQcml2YXRlS2V5KTsgLy8gdGhpcyB3YXksIHlvdSB0aHJvdyBhbiBleGNlcHRpb24gZXZl cnl0aW1lIHlvdSBnZXQgaW52YWxpZCBQS0NTMSBtZXNzYWdlLiBZb3VyIGZyYW1ld29yayBzYXlz IGUuZy46DQpjb20ubmltYnVzZHMuand0LkpXRUV4Y2VwdGlvbjogQ291bGRuJ3QgZGVjcnlwdDog dW5rbm93biBibG9jayB0eXBlIGlmIHRoZSBkZWNyeXB0ZWQgbWVzc2FnZSBkb2VzIG5vdCBzdGFy dCB3aXRoIDB4MDAgMHgwMiBvciBpdCBzYXlzDQpjb20ubmltYnVzZHMuand0LkpXRUV4Y2VwdGlv bjogQ291bGRuJ3QgZGVjcnlwdDogbm8gZGF0YSBpbiBibG9jayBpZiB0aGUgZGVjcnlwdGVkIG1l c3NhZ2UgZG9lcyBub3QgY29udGFpbiBhbnkgMHgwMCBpbiB0aGUgbWlkZGxlDQoJYnl0ZVtdIHNl Y3JldEtleUJ5dGVzMSA9IGNpcGhlci5kb0ZpbmFsKGVuY3J5cHRlZEtleS5kZWNvZGUoKSk7DQoJ aWYgKDgqIHNlY3JldEtleUJ5dGVzMS5sZW5ndGggIT0ga2V5bGVuZ3RoKSB7IC8vIHRoaXMgdGhy b3dzIHNvbWV0aGluZyBsaWtlDQpjb20ubmltYnVzZHMuand0LkpXRUV4Y2VwdGlvbjogQ291bGRu J3QgZGVjcnlwdDogV2ViVG9rZW4uZGVjcnlwdCBSU0EgUEtDUzFQYWRkaW5nIHN5bW1ldHJpYyBr ZXkgbGVuZ3RoIG1pc21hdGNoOiA0OCAhPSAyNTYgd2hpY2ggZ2l2ZXMgdGhlIGF0dGFja2VyIGFn YWluIHRoZSBwb3NzaWJpbGl0eSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHZhbGlkIGFuZCBpbnZh bGlkIG1lc3NhZ2VzDQoJCXRocm93IG5ldyBFeGNlcHRpb24oIldlYlRva2VuLmRlY3J5cHQgUlNB IFBLQ1MxUGFkZGluZyBzeW1tZXRyaWMga2V5IGxlbmd0aCBtaXNtYXRjaDogIiArIHNlY3JldEtl eUJ5dGVzMS5sZW5ndGggKyAiICE9ICIgKyAga2V5bGVuZ3RoKTsNCgl9DQoNCglrZXlTcGVjID0g bmV3IFNlY3JldEtleVNwZWMoc2VjcmV0S2V5Qnl0ZXMxLCBzeW1tZXRyaWNBbGdvcml0aG0pOw0K DQoJYnJlYWs7DQoNCg0KDQpSZXNwb25kaW5nIHdpdGggYSBnZW5lcmFsaXplZCBlcnJvciBtZXNz YWdlIGFsc28gZG9lcyBub3QgaGVscCBjb21wbGV0ZWx5IGFzIHRoZSBhdHRhY2tlciBjb3VsZCBv YnNlcnZlIHRoZSByZXNwb25zZSB0aW1lIG9mIHRoZSBzZXJ2ZXIuIE5hbWVseSwgdmFsaWQgUEtD UzEgbWVzc2FnZXMgYnJpbmcgYSBDRUssIHdoaWNoIGlzIHRoZW4gdXNlZCBmb3IgZGF0YSBkZWNy eXB0aW9uIChBRVMtQ0JDLCBBRVMtR0NNLi4uKS4gSW52YWxpZCBQS0NTMSBtZXNzYWdlcyByZXR1 cm4gYSBmYXVsdCByZXNwb25zZSBkaXJlY3RseSwgd2l0aG91dCBkYXRhIGRlY3J5cHRpb24uIFRo aXMgb2ZmZXJzIGEgbmljZSB0aW1pbmcgc2lkZS1jaGFubmVsLiBQbGVhc2Ugbm90ZSB0aGF0IHRo ZSBhdHRhY2tlciBjYW4gZm9yY2UgdGhlIHNlcnZlciB0byBwcm9jZXNzIGFyYml0cmFyaWx5IGRh dGEgKGFsc28gZS5nLiAxTUIpLCBzbyB0aGUgYXR0YWNrIGNvdWxkIGJlY29tZSBwcmFjdGljYWwg YWxzbyBvdmVyIHRoZSBJbnRlcm5ldCAodGVzdGVkIGluIHNpbWlsYXIgc2NlbmFyaW8gd2l0aCBY TUwgRW5jcnlwdGlvbiA6KSApDQoNCg0KT2ssIHNvIGFkZGl0aW9uYWxseSB0byB0aGUgc2FtZSBl cnJvciBtZXNzYWdlcywgeW91IHNob3VsZCBhbHNvIGNvbnNpZGVyIHRpbWluZyBhbmQgdGh1cyBy ZWdlbmVyYXRlIGEgc3ltbWV0cmljIGtleSBDRUsgZXZlcnkgdGltZSwgaXQgd2FzIGluY29ycmVj dGx5IGRlY3J5cHRlZCAodGhpcyB3YXkgYWxsIHRoZSBpbnZhbGlkIFBLQ1MxIGNpcGhlcnRleHRz IHdpbGwgYmUgcHJvY2Vzc2VkLCBDRUsgZ2VuZXJhdGVkLCBhbmQgdGhlIE1BQyB2YWxpZGF0aW9u IHdpbGwgZmFpbCksIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoNCmNhc2UgUlNBMV81Og0KICAgICAv LyBpbml0aWFsaXplIHNvbWV3aGVyZSBTZWN1cmVSYW5kb20gKGUuZy4gaW4geW91ciBKV0UgY29u c3RydWN0b3IpDQogICAgIC8vIFNlY3VyZVJhbmRvbSByYW5kb20gPSBTZWN1cmVSYW5kb20uZ2V0 SW5zdGFuY2UoIlNIQTFQUk5HIikNCglDaXBoZXIgY2lwaGVyID0gQ2lwaGVyLmdldEluc3RhbmNl KCJSU0EvRUNCL1BLQ1MxUGFkZGluZyIpOw0KCWNpcGhlci5pbml0KENpcGhlci5ERUNSWVBUX01P REUsIHJzYVByaXZhdGVLZXkpOw0KICAgICAgICBieXRlW10gc2VjcmV0S2V5Qnl0ZXMxID0gbnVs bDsNCiAgICAgICAgdHJ5IHsNCiAgICAgICAgCXNlY3JldEtleUJ5dGVzMSA9IGNpcGhlci5kb0Zp bmFsKGVuY3J5cHRlZEtleS5kZWNvZGUoKSk7DQogICAgICAgIH0gY2F0Y2goQmFkUGFkZGluZ0V4 Y2VwdGlvbiBlKSB7IC8vIHJlZ2VuZXJhdGUga2V5IGlmIHRoZSBQS0NTMSBwYWRkaW5nIGlzIGlu Y29ycmVjdA0KICAgICAgICAJc2VjcmV0S2V5Qnl0ZXMxID0gbmV3IGJ5dGVba2V5bGVuZ3RoIC8g OF07DQogICAgICAgICAgICAgICAgcmFuZG9tLm5leHRCeXRlcyhzZWNyZXRLZXlCeXRlczEpOw0K ICAgICAgICB9DQoNCglpZiAoOCogc2VjcmV0S2V5Qnl0ZXMxLmxlbmd0aCAhPSBrZXlsZW5ndGgp IHsgLy8gcmVnZW5lcmF0ZSBrZXkgaWYgdGhlIGxlbmd0aCBpcyBpbmNvcnJlY3QNCiAgICAgICAg CXNlY3JldEtleUJ5dGVzMSA9IG5ldyBieXRlW2tleWxlbmd0aCAvIDhdOw0KICAgICAgICAgICAg ICAgIHJhbmRvbS5uZXh0Qnl0ZXMoc2VjcmV0S2V5Qnl0ZXMxKTsNCgl9DQoNCglrZXlTcGVjID0g bmV3IFNlY3JldEtleVNwZWMoc2VjcmV0S2V5Qnl0ZXMxLCBzeW1tZXRyaWNBbGdvcml0aG0pOw0K DQoJYnJlYWs7DQoNCg0KSSBob3BlIHRoaXMgd2lsbCB0aHdhcnQgdGhlIGF0dGFjay4uLg0KDQoN Cg0KV2UgaGF2ZSBhbHJlYWR5IHRyaWVkIHRvIGNvbnZpbmNlIHRoZSBzdGFuZGFyZCBkZXZlbG9w ZXJzIHRvIGV4Y2x1ZGUNClBLQ1MxIGZyb20gdGhlIHN0YW5kYXJkOg0KaHR0cDovL3d3dy5tYWls LWFyY2hpdmUuY29tL2pvc2VAaWV0Zi5vcmcvbXNnMDAwNzUuaHRtbA0KDQouLi5pdCBkaWQgbm90 IHdvcmsuDQoNCg0KUlNBLU9BRVAgaXMgdGhlIGdvb2QgY2hvaWNlIGZvciBKT1NFIGFzIFBLQ1Mx IHdpbGwgY2F1c2Ugc2ltaWxhciBwcm9ibGVtcyBhbHNvIGZvciBvdGhlciBkZXZlbG9wZXJzLg0K DQoNClJlZ2FyZHMgZnJvbSBCb2NodW0NCkp1cmFqDQoNCk9uIDA0LzA1LzIwMTIgMDM6MDMgUE0s IFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTIHdyb3RlOg0KPiBIYWxsbyBCZXJsaW4sIGhh bGxvIEJvY2h1bSwgaGFsbG8gV2VsdCEgOikNCj4gDQo+IEkganVzdCBzZW50IGFuIGVtYWlsIHRv IGEgY3J5cHRvIGV4cGVydCBhdCBhIHBhcnRuZXIgY29tcGFueSB0byBhc2sgDQo+IGZvciBoaXMg b3BpbmlvbiBpcyBvbiB0aGF0LiBNeSBmZWVsaW5nIGlzIHRoYXQgd2hlbiB3ZSBjb2xsZWN0IA0K PiBzdWZmaWNpZW50IG9waW5pb25zIG9uIHRoYXQgdGhlICJ0cnV0aCIgd2lsbCBldmVudHVhbGx5 IGVtZXJnZSA6KQ0KPiANCj4gQXMgbWVudGlvbmVkLCBJIGRvbid0IGhhdmUgYSBwcm9wZXIgY3J5 cHRvIGJhY2tncm91bmQsIHNvIGR1cmluZyANCj4gcmVmYWN0b3JpbmcgSSBtYWRlIHN1cmUgQXhl bCdzIGNvZGUgcmVtYWluZWQganVzdCBhcyBpdCB3YXMuDQo+IA0KPiANCj4gVmxhZGltaXINCj4g DQo+IC0tDQo+IFZsYWRpbWlyIER6aHV2aW5vdiA6IHd3dy5OaW1idXNEUy5jb20gOiB2bGFkaW1p ckBuaW1idXNkcy5jb20NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tLS0tDQo+IFN1YmplY3Q6IFJlOiBbam9zZV0gSldUICsgSk9TRSBmb3IgSmF2 YQ0KPiBGcm9tOiA8QXhlbC5OZW5ua2VyQHRlbGVrb20uZGU+DQo+IERhdGU6IFRodSwgQXByaWwg MDUsIDIwMTIgMTowMCBwbQ0KPiBUbzogPGp1cmFqLnNvbW9yb3Zza3lAcnViLmRlPiwgPHZsYWRp bWlyQG5pbWJ1c2RzLmNvbT4NCj4gQ2M6IGpvc2VAaWV0Zi5vcmcNCj4gDQo+IA0KPiBIaSBKdXJh aiwNCj4gDQo+IEFzIFZsYWRpbWlyJ3Mgd29yayBpcyBiYXNlZCBvbiBteSBpbXBsZW1lbnRhdGlv biBJIGd1ZXNzIHRoYXQgbXkgDQo+IGltcGxlbWVudGF0aW9uIGhhcyByb29tIGZvciBpbXByb3Zl bWVudCB0b28uDQo+IGh0dHBzOi8vY29kZS5nb29nbGUuY29tL3Avb3BlbmluZm9jYXJkL3NvdXJj ZS9icm93c2UvdHJ1bmsvc3JjL29yZy94bWwNCj4gZGFwL2pzb24vV2ViVG9rZW4uamF2YQ0KPiAN Cj4gRU5DX0FMR19SU0FfT0FFUCBpcyBiZXR0ZXIgdGhhbiBFTkNfQUxHX1JTQTFfNS4gDQo+IGh0 dHBzOi8vY29kZS5nb29nbGUuY29tL3Avb3BlbmluZm9jYXJkL3NvdXJjZS9icm93c2UvdHJ1bmsv c3JjL29yZy94bWwNCj4gZGFwL2pzb24vV2ViVG9rZW4uamF2YSMxMTYNCj4gDQo+IEJvdGggcGFk ZGluZyBhbGdvcml0aG1zIGFyZSBzdXBwb3J0ZWQgYnkgbXkgY29kZSBhbmQgdGhpcyBSU0EgYnVs bGV0aW4gDQo+IG1lbnRpb25zIE9BRVAgYXMgb25lIGNvdW50ZXIgbWVhc3VyZSBhZ2FpbnN0IHRo ZSBCbGVpY2hlbmJhY2hlciBhdHRhY2suDQo+IGZ0cDovL2Z0cC5yc2FzZWN1cml0eS5jb20vcHVi L3BkZnMvYnVsbGV0bjcucGRmDQo+IA0KPiBEb2VzICJ5b3VyIiBhdHRhY2sgd29yayBhZ2FpbnN0 IEVOQ19BTEdfUlNBX09BRVAgdG9vPyBBZGRpdGlvbmFsIA0KPiBjb3VudGVyIG1lYXN1cmVzIHN1 Z2dlc3Rpb25zIGFyZSB2ZXJ5IHdlbGNvbWUuDQo+IA0KPiBSU0ExXzUgaXMgaW4gdGhlIHByb3Bv c2VkIHN0YW5kYXJkIGJlY2F1c2UgaXQgaXMgd2lkZWx5IGF2YWlsYWJsZSANCj4gYWx0aG91Z2gg UlNBIHJlY29tbWVuZHMgdG8gdXNlIE9BRVAgZm9yIGRlY2FkZXMuDQo+IEkgdGhpbmsgdGhhdCBS U0EtT0FFUCBzaG91bGQgYmUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBhbmQgUlNBMV81IA0KPiBk ZXByZWNhdGVkLg0KPiANCj4gQ2hlZXJzLiBHcmVldGluZ3MgZnJvbSBCZXJsaW4gdG8gQm9jaHVt Lg0KPiBBeGVsDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog am9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgDQo+IE9mIEp1cmFqIFNvbW9yb3Zza3kNCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA1 LCAyMDEyIDE6MTMgQU0NCj4gVG86IHZsYWRpbWlyQG5pbWJ1c2RzLmNvbQ0KPiBDYzogam9zZUBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2pvc2VdIEpXVCArIEpPU0UgZm9yIEphdmENCj4gDQo+ IEhpIFZsYWRpbWlyLA0KPiANCj4gSSBoYXZlIHRvb2sgYSBsb29rIGF0IHlvdXIgaW1wbGVtZW50 YXRpb24gYW5kIGZvdW5kIG91dCwgdGhhdCB5b3VyIA0KPiBQS0NTMSBoYW5kbGluZyBpcyB2dWxu ZXJhYmxlIHRvIHRoZSBCbGVpY2hlbmJhY2hlciBhdHRhY2sgKHRoZSANCj4gYWR2ZXJzYXJ5IGNv dWxkIGJlIGFibGUgdG8gaXNzdWUgZGlmZmVyZW50IGNpcGhlcnRleHRzLCBzZW5kIHRoZW0gdG8g DQo+IHRoZSBzZXJ2ZXIsIGFuZCBhY2NvcmRpbmcgdG8gaXRzIHJlc3BvbnNlcyBoZSBjb3VsZCBs ZWFybiB0aGUgDQo+IGVuY3J5cHRlZCBDRUspDQo+IA0KPiBJIHdpbGwgc2VuZCB5b3UgUG9DcyBh bmQgaW5zdHJ1Y3Rpb25zIGhvdyB0byBmaXggaXQgYnkgdG9tb3Jyb3cuLi5vciANCj4ganVzdCB0 YWtlIGEgbG9vayBhdCB0aGUgZG9jdW1lbnQgd3JpdHRlbiBieSBFcmljIFJlc2NvcmxhOg0KPiBo dHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmMzMjE4LnR4dA0KPiANCj4gUmVnYXJkcw0KPiBKdXJh ag0KPiANCj4gT24gMDQvMDMvMjAxMiAxMToyNCBBTSwgVmxhZGltaXIgRHpodXZpbm92IC8gTmlt YnVzRFMgd3JvdGU6DQo+PiBUb2RheSBJIHJlYWNoZWQgYSBwb2ludCBpbiBteSBKV1QrSk9TRSBs aWJyYXJ5IGltcGxlbWVudGF0aW9uIHdoZXJlIEkgDQo+PiB3b3VsZG4ndCBmZWVsIGFzaGFtZWQg dG8gcmVsZWFzZSBpdCB0byB0aGUgcHVibGljIDopDQo+Pg0KPj4gaHR0cHM6Ly9naXRodWIuY29t L05pbWJ1c0RTL05pbWJ1cy1KV1QNCj4+DQo+PiBUaGUgbGlicmFyeSBpcyBmdWxseSBkb2N1bWVu dGVkOg0KPj4gaHR0cDovL25pbWJ1c2RzLmNvbS9maWxlcy9qd3QvamF2YWRvYy9pbmRleC5odG1s DQo+Pg0KPj4NCj4+IFRoZSBOaW1idXMtSldUIGxpYnJhcnkgc3RhcnRlZCBhIG1vbnRoIGFnbyBm cm9tIGNvZGUgYm9ycm93ZWQgZnJvbSANCj4+IEF4ZWwgTmVubmtlcidzICsgQ28gT3BlbkluZm9D YXJkIHByb2plY3QgYW5kIGF0IHRoaXMgcG9pbnQgY292ZXJzIA0KPj4gZnVsbHkgcGxhaW4gYW5k IHNpZ25lZCBKV1RzIGFzIHdlbGwgYXMgSlNPTiBXZWIgS2V5cyAoSldLKS4gVGhlIEpXRSANCj4+ IGltcGxlbWVudGF0aW9uIHN0aWxsIHJlcXVpcmVzIGEgYml0IG9mIHdvcmsgdG8gYWRkIEhNQUMg aW50ZWdyaXR5IGFuZCANCj4+IGNvdmVyIHRoZSByZW1haW5pbmcgZWxsaXB0aWMgY3VydmUgYW5k IGtleS13cmFwIGVuY3J5cHRpb24gYWxnb3JpdGhtcyANCj4+IGZyb20gdGhlIEpXQSBzcGVjLiBJ IHdvdWxkIGJlIHZlcnkgdGhhbmtmdWwgaWYgc29tZWJvZHkgY291bGQgaGVscCBtZSANCj4+IHdp dGggdGhhdCBhcyBJIGRvbid0IGhhdmUgbXVjaCBleHBlcmllbmNlIHdpdGggY3J5cHRvZ3JhcGh5 IDopDQo+Pg0KPj4gRm9yIHRoZSBsaXN0aW5nIG9mIHRoZSBzdXBwb3J0ZWQgSldBczoNCj4+IGh0 dHA6Ly9uaW1idXNkcy5jb20vZmlsZXMvand0L2phdmFkb2MvY29tL25pbWJ1c2RzL2p3dC9KV0Eu aHRtbA0KPj4NCj4+IENoZWVycywNCj4+DQo+PiBWbGFkaW1pcg0KPj4gLS0NCj4+IFZsYWRpbWly IER6aHV2aW5vdiA6IHd3dy5OaW1idXNEUy5jb20gOiB2bGFkaW1pckBuaW1idXNkcy5jb20NCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g am9zZSBtYWlsaW5nIGxpc3QNCj4+IGpvc2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KPiANCj4gLS0NCj4gTS5TYy4gSnVyYWogU29tb3Jv dnNreQ0KPiANCj4gTGVocnN0dWhsIGbDvHIgTmV0ei0gdW5kIERhdGVuc2ljaGVyaGVpdCBSdWhy IFVuaXZlcnNpdMOkdCBCb2NodW0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gVW5pdmVyc2l0w6R0c3N0ci4gMTUwLCBHZWIuIElEIDIvNDExDQo+IEQtNDQ3ODAgQm9j aHVtDQo+IA0KPiBUZWxlZm9uOiArNDkgKDApIDIzNCAvIDMyLTI2NTUxDQo+IEZheDogKzQ5ICgw KSAyMzQgLyAzMi0xNDM0Nw0KPiBodHRwOi8vd3d3Lm5kcy5ydWIuZGUNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gam9zZSBtYWlsaW5nIGxpc3QN Cj4gam9zZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2pvc2UNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gam9zZSBtYWlsaW5nIGxpc3QNCj4gam9zZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCj4gDQoNCi0tDQpNLlNjLiBKdXJhaiBTb21vcm92 c2t5DQoNCkxlaHJzdHVobCBmw7xyIE5ldHotIHVuZCBEYXRlbnNpY2hlcmhlaXQNClJ1aHIgVW5p dmVyc2l0w6R0IEJvY2h1bQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClVu aXZlcnNpdMOkdHNzdHIuIDE1MCwgR2ViLiBJRCAyLzQxMQ0KRC00NDc4MCBCb2NodW0NCg0KVGVs ZWZvbjogKzQ5ICgwKSAyMzQgLyAzMi0yNjU1MQ0KRmF4OiArNDkgKDApIDIzNCAvIDMyLTE0MzQ3 DQpodHRwOi8vd3d3Lm5kcy5ydWIuZGUNCg== From juraj.somorovsky@rub.de Fri Apr 6 06:34:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBD521F84D9 for ; Fri, 6 Apr 2012 06:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR3mxBsrJpRP for ; Fri, 6 Apr 2012 06:34:09 -0700 (PDT) Received: from mx5.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.33]) by ietfa.amsl.com (Postfix) with SMTP id AC11E21F84D8 for ; Fri, 6 Apr 2012 06:34:08 -0700 (PDT) X-Queued: (qmail 20583 invoked by alias); 6 Apr 2012 13:34:07 -0000 X-Queued: (qmail 20570 invoked from network); 6 Apr 2012 13:34:07 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx5.rz.ruhr-uni-bochum.de with SMTP; 6 Apr 2012 13:34:07 -0000 X-Queued: (qmail 26328 invoked by uid 281); 6 Apr 2012 13:34:06 -0000 X-Qmailscanner: from 178.201.46.200 (7Cil8M2CiUwT9PxZdWAs+A==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.29/4.75. Clear:RC:1(178.201.46.200):. Processed in 0.03623 secs); 06 Apr 2012 13:34:06 -0000 Received: from ip-178-201-46-200.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUwT9PxZdWAs+A==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 6 Apr 2012 13:34:06 -0000 Date: 6 Apr 2012 15:34:05 +0200 Message-ID: <4F7EF0CD.9040109@rub.de> From: "Juraj Somorovsky" To: jose@ietf.org, tom@ritter.vg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:34:10 -0000 Thanks Tom, I know there is the Manger's attack and I already read your blog a few months ago ;) ...but considering Bleichenbacher's and Manger's attacks there are a few differences between PKCS#1.5 and PKCS#2.0 (RSA-OAEP): Manger's attack on RSA-OAEP is rather theoretical. As you also mention in your post, the security libraries handle it correctly: - if there is no 0x00 on the beginning, they simply ignore it and check integrity by verifying hash values. - even if the library would not handle this step correctly, the timing difference is really small (of course, if not considering the timing attack in the Manger's paper in Section 4.4) and not measurable over the Internet. Bleichenbacher's attack on PKCS#1.5 is practical. This results from missing integrity check in PKCS#1.5 after ciphertext decryption, which gives the attacker a possibility to create related plaintexts. The main point is: if the attacker creates a ciphertext resulting in a valid CEK, he forces the server to use this CEK and decrypt the payload data (encrypted e.g. with AES). In comparison to small timing differences in RSA-OAEP, the timing differences between valid and invalid PKCS#1.5 ciphertexts can be enlarged by sending a greater amount of payload data. Thus, even if the ciphertext is not valid, when using PKCS#1.5 the server should generate a new key and decrypt the payload in order not to reveal a timing side-channel. This must be explicitly handled by the application developer and cannot be handled in the security library. In comparison to PKCS#1.5, RSA-OAEP can be used directly...the application developer does not have to care about any countermeasures in his application. If the developer relies on a good security library (OpenSSL, BouncyCastle...), his application will not reveal any side-channels with RSA-OAEP. Regards Juraj On 04/05/2012 06:04 PM, Tom Ritter wrote: > On 5 April 2012 11:29, Juraj Somorovsky wrote: >> RSA-OAEP is the good choice for JOSE as PKCS1 will cause similar >> problems also for other developers. >> >> >> Regards from Bochum >> Juraj > > > I haven't been following closely, but if it hasn't been already I > should point out there's a very similar attack against RSA-OAEP you > need to take care to avoid: http://ritter.vg/blog-mangers_oracle.html > > -tom > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- M.Sc. Juraj Somorovsky Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum ----------------------------------- Universitätsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de From cantor.2@osu.edu Fri Apr 6 06:48:45 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1352121F852D for ; Fri, 6 Apr 2012 06:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsc91u8-Coj6 for ; Fri, 6 Apr 2012 06:48:44 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4348B21F852C for ; Fri, 6 Apr 2012 06:48:44 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q36DmcD8014063; Fri, 6 Apr 2012 09:48:42 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 09:48:31 -0400 From: "Cantor, Scott" To: "Axel.Nennker@telekom.de" , "juraj.somorovsky@rub.de" Thread-Topic: [jose] JWT + JOSE for Java Thread-Index: Ac0TQOywoVci1rfxSwCEC1LxOxoDCAAeHKagABBnA2A= Date: Fri, 6 Apr 2012 13:48:31 +0000 Message-ID: References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "jose@ietf.org" Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:48:45 -0000 PiBXZSBkbyBub3QgZGVmaW5lIHRoaW5ncyBsaWtlICJ5b3Ugc2hvdWxkIGNoYW5nZSB5b3VyIGtl eXMgYWZ0ZXIgbiBvcGVyYXRpb25zDQo+IG9yIE4gbWVnYWJ5dGVzIG9mIHBsYWludGV4dCBwcm9j ZXNzZWQgKG9yIHdoZW4gYSBCYWRQYWRkaW5nIEV4Y2VwdGlvbiBpcw0KPiB0aHJvd24pLiBJIHRo aW5rIHRoYXQgbXkgY29kZSBzaG91bGQgdGhyb3cgYWxsIGV4Y2VwdGlvbnMgaW4gYWxsIHRoZWly IGdsb3J5DQo+IGRldGFpbHMgYW5kIHRoYXQgZS5nLiB0aGUgYXBwbGljYXRpb24gc2VydmVyICJh Ym92ZSIgbWUgc2hvdWxkIHRoZW4gZGVjaWRlDQo+IHdoaWNoIGFjdGlvbiB0byB0YWtlOiBsaWtl ICJHaXZlIGEgc3RhbmRhcmQgZXJyb3IgbWVzc2FnZSIgdG8gdGhlIHNlbmRlciBvZg0KPiB0aGUg YmFkIG1lc3NhZ2UgYW5kIHdhaXQgYSByYW5kb20gYW1vdW50IG9mIHRpbWUgYmVmb3JlIHNlbmRp bmcgZXJyb3INCj4gbWVzc2FnZXMuIEJ1dCB0aGlzIGlzIG5vdCB0aGUgdGFzayBvZiB0aGlzIGNv ZGUuDQoNClllcywgaXQgaXMuIElmIHlvdSB3YW50IHRvIHVzZSBQS0NTIzEuNSwgdGhlbiB5b3Ug bmVlZCB0byBtYWtlIHRoYXQgdXNhYmxlIHNhZmVseSB3aXRob3V0IGV4dHJhIHByZWNhdXRpb25z IGJ5IHlvdXIgY2FsbGVyLiBJZiB3ZSB3ZXJlIHRhbGtpbmcgYWJvdXQgdGhlIGFjdHVhbCBpbXBs ZW1lbnRhdGlvbiBvZiBQS0NTMS41LCB0aGVuIHlvdSBtaWdodCBiZSByaWdodCwgYnV0IHlvdSdy ZSBub3QgaW1wbGVtZW50aW5nIHRoYXQsIHlvdSdyZSB1c2luZyBpdCB0byBlbmNyeXB0IG9iamVj dHMgeW91J3JlIHRyeWluZyB0byBhYnN0cmFjdCBpbiBhIGxpYnJhcnkuIFRoYXQgbWFrZXMgaXQg eW91ciBqb2IgdG8gbWFrZSBlbmNyeXB0aW9uIGEgInNhZmUiIG9wZXJhdGlvbiBmb3Igc29tZWJv ZHkgdXNpbmcgdGhhdCBhYnN0cmFjdGlvbiwgaWYgeW91IGNhbi4NCg0KSW4gdGhlIGNhc2Ugb2Yg dGhpcyBhdHRhY2ssIGRldGFpbGVkIGVycm9yIGluZm9ybWF0aW9uIGNhbiBiZSBwdXQgaW4gbG9n cywgYW5kIGRvZXNuJ3QgbmVlZCB0byBiZSBleHBvc2VkIHRvIGNhbGxlcnMsIGFuZCB0aGUgZ2Vu ZXJhdGlvbiBvZiBhIHJhbmRvbSBrZXkgZWFzaWx5IGRlZmVhdHMgdGhlIHRpbWluZyBhdHRhY2su DQoNClRoZXJlIGFyZSBoYXJkZXIgcHJvYmxlbXMgdGhhdCBhcmUgdmlydHVhbGx5IGltcG9zc2li bGUgdG8gc29sdmUgdGhhdCB3YXkgKHRoZSBDQkMgYXR0YWNrKS4gVGhpcyBvbmUgaXMgZWFzeSBh bmQgZW50aXJlbHkgYXBwcm9wcmlhdGUgdG8gZml4IGJlbG93IGFueSBwcm90b2NvbC4NCg0KPiBN eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBsZXZlbCB0aGF0IHdlIGFyZSBkZXNjcmliaW5nIGhlcmUg aXMgImJlbG93Ig0KPiBwcm90b2NvbHMuDQoNCkFuZCB0aGUgZW5jcnlwdGlvbiBoZXJlIGlzIGFs c28gYmVsb3cgdGhlIHByb3RvY29sLiBJZiBpdCB3ZXJlbid0LCB0aGF0IHdvdWxkIGJlIGEgZGlm ZmVyZW50IG1hdHRlci4NCg0KPiBJIGZlYXIgdGhhdCB3ZSBlbmQgdXAgaW4gYSBkaXNjdXNzaW9u IHRoYXQgSSBmb2xsb3dlZCBpbiB0aGUgTlNTIGRpc2N1c3Npb24NCj4gZ3JvdXAgeWVhcnMgYWdv LiAiU2hvdWxkIHdlIGdpdmUgZGV2ZWxvcGVycyBjcnlwdG9ncmFwaGljIGJ1aWxkaW5nIGJsb2Nr cw0KPiB0aGF0IGNvdWxkIGJlIHVzZWQgd3JvbmciLiBUaGVuIE5TUyBkZWNpZGVkICBub3QgdG8g ZG8gaXQgYnV0IEkgdGhpbmsgdGhhdA0KPiB3YXMgd3JvbmcuDQoNCk5TUyBpcyBhIGNyeXB0byBs aWJyYXJ5IChtZWFuaW5nIGl0IGFjdHVhbGx5IGltcGxlbWVudHMgUEtDUzEuNSkuIFRoYXQncyBh IGRpZmZlcmVudCBsYXllci4NCg0KPiBJIHRoaW5rIHRoYXQgdGhlIHByb3RvY29scyB0aGF0IHVz ZSB0aGUgSk9TRSBmb3JtYXRzL2FsZ3MgbGlrZSBvcGVuaWQgY29ubmVjdA0KPiAoaHR0cHM6Ly9v cGVuaWQubmV0L2Nvbm5lY3QvKSBoYXZlIHRoZSBkdXR5IHRvIHVzZSB0aGVtIGNvcnJlY3RseS4N Cg0KVGhleSBkbywgYnV0IHRoYXQgZG9lc24ndCBhYnNvbHZlIGxpYnJhcmllcyBvZiB0aGUgcmVz cG9uc2liaWxpdHkgb2YgYmVpbmcgaW1wbGVtZW50ZWQgY29ycmVjdGx5IGFsc28uIE90aGVyd2lz ZSwgYmUgcHJlcGFyZWQgZm9yIG1vc3Qgb2YgdGhlIHByb3RvY29sIGltcGxlbWVudGF0aW9ucyB1 c2luZyB5b3VyIGNvZGUgdG8gZ2V0IGl0IHdyb25nLg0KDQotLSBTY290dA0KDQo= From tom@ritter.vg Fri Apr 6 06:52:13 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A566D21F8542 for ; Fri, 6 Apr 2012 06:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSF6AqjfxZ8q for ; Fri, 6 Apr 2012 06:52:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD70721F8541 for ; Fri, 6 Apr 2012 06:52:12 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3563399obb.31 for ; Fri, 06 Apr 2012 06:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=kOWVhDgn9gRd4wNZrWWzltdTp7mOCkX7Evb+vavhago=; b=RKkdlBkRyu+AfSm84/gf7dG6DRc2fL6wsHSE9qNdV1R4VqvK/EFycAQHuE9/P0WTgB vJEoqRjLh3ZC2Xe/Tc8+6cchgCz7GbslRCcsbmmXkOvIWFmMaBjhoBP8+RXXzmnIU1x+ XaUmTdxdLjvLV84pO97UkyucW/F4gk1KC7Ys0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=kOWVhDgn9gRd4wNZrWWzltdTp7mOCkX7Evb+vavhago=; b=GP+5ymXhg6OWESul4cqotsjTCnh5NDGpTjrFcS6Ilg3eR76zbwREhlDTTJZx9Li4j7 gk/PLEVtUUfpfdsKDuKdaSAuu215NdQbEe3fP4kNWVeAd9pS4IOHjHOFy6G87B9zIXcE wveeMxEGB9PjB0UEbIm7CUhHwbyPV39wjlwWEVwfB9PR17+ryYN2nvQWqsWfkfqja3Pq MKSvtCh4ABD0Z2oUxeyN8ZFJkgWaUkMlOKN86bJ6LjHSJUAD4K8QrmWY5OgkXDQitbFf GK03g0uWHYfpUBUPJ9IV+8GqLsVq8qz6dJvK0Ymke/6dfeMtKmcnsMxwX8NNV+y35O3v FlFw== Received: by 10.60.9.232 with SMTP id d8mr9048148oeb.66.1333720332518; Fri, 06 Apr 2012 06:52:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.182.5 with HTTP; Fri, 6 Apr 2012 06:51:52 -0700 (PDT) In-Reply-To: <4F7EF0CD.9040109@rub.de> References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> <4F7EF0CD.9040109@rub.de> From: Tom Ritter Date: Fri, 6 Apr 2012 09:51:52 -0400 Message-ID: To: Juraj Somorovsky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlFVF7jB9HL8zTIrM4jfsD9j6pamjELDVNmxjBc5rMBjyX0rlTtUJ+a4VNcQmtcYAtC5n28 Cc: jose@ietf.org Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:52:13 -0000 There's two different opinions here: On 6 April 2012 02:10, wrote: > We do not define things like "you should change your keys after n operati= ons or N megabytes of plaintext processed (or when a BadPadding Exception i= s thrown). I think that my code should throw all exceptions in all their gl= ory details and that e.g. the application server "above" me should then dec= ide which action to take: like "Give a standard error message" to the sende= r of the bad message and wait a random amount of time before sending error = messages. But this is not the task of this code. > https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap= /json/WebToken.java > > My understanding of the level that we are describing here is "below" prot= ocols. > Although I give it to you that the security considerations section should= recommend usage of the formats and algorithms defined here and discourage = certain uses. > > I fear that we end up in a discussion that I followed in the NSS discussi= on group years ago. "Should we give developers cryptographic building block= s that could be used wrong". Then NSS decided =A0not to do it but I think t= hat was wrong. On 6 April 2012 09:34, Juraj Somorovsky wrote: > In comparison to PKCS#1.5, RSA-OAEP can be used directly...the > application developer does not have to care about any countermeasures in > his application. If the developer relies on a good security library > (OpenSSL, BouncyCastle...), his application will not reveal any > side-channels with RSA-OAEP. Axel says "It's the developer's job to use my code correctly", Juraj says "if the library is good, I don't need to do anything extra". There's good arguments for both approaches. I mentioned the OAEP attack because I hadn't seen it mentioned before, and I would rather look a fool and tell something everyone knows versus lose the opportunity to fix a bug in dozens or hundreds of applications before they're written. The templating engines, the database libraries, and the cryptographic libraries that make it _hard_ for a user to introduce vulnerabilities they don't understand, are preferable to ones that don't. Check out the near-end of [0], where Pascal Junod compares crypto libraries and what attacks they protect against: timing, cache, fault, oracle, and leakage. Protecting against power leakage attacks is way overboard - but protecting against timing attacks is pretty much the minimum standard these days. I *don't* understand JOSE, I don't know where this code fits in. I don't know the appropriate level to defend against developer omissions. It's almost certainly too high-level to make an API that _requires_ a developer to pass in a MAC along with the ciphertext - even though protecting ciphertext with a MAC is pretty much an "Always Do This!" these days with all of the adaptive-ciphertext attacks we've been seeing.[1] I do think putting in non-branching code for timing defense in the decryption routine is appropriate. And if it were _me_ were defining an API, I would make the cipher constructor or decryption function take an optional parameter that determined whether verbose or identical errors are thrown, and the default would be identical. Until developing becomes like bridge-building, and people have to take a test to see if they can do it safely - I think it's very important for anyone who's writing code that will be called by others to make it 'safe by default' and not rely on intelligence or thoroughness of the calling developer. -tom [0] http://crypto.junod.info/hashdays10_talk.pdf [1] CBC Padding Oracle, OAEP, Bleichenbacher, and more From ve7jtb@ve7jtb.com Fri Apr 6 07:05:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEC621F858A for ; Fri, 6 Apr 2012 07:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLmFB7IG+p4l for ; Fri, 6 Apr 2012 07:05:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4813321F8587 for ; Fri, 6 Apr 2012 07:05:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1444686ghb.31 for ; Fri, 06 Apr 2012 07:05:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=89dr64DJLM3mGQGrOxFzD+TqGaE8caAWZsvPFhitt+U=; b=GsHJQvrJyJc7mX3t8c08coqn96hc9djQ7b9q1rlu+EQgnKftlfL+H4kvHpYrhgiTFO R6ru7GPXHfz/5Orp0aNYDrP0+lsD5XD9d8uKs6JfC2SmdpGh4iIt1cJWdfrGPqV666vH mvSeM+ardv8zJwLo2D1bXLfEJAkFkyi89GZD+Vo6RmJUl+Ga41WwPoraf8slXEqTX41i 41q0A1ZBoUtDc/n8FGfyXcAL2oiZbOREdm8MTV0MDHHVdgWo5M1D0UGP9h5WnMXW+5vA RcJ2rkcLlsv9tr+mnxEnUuEDVILQOCb3rSEpiAvZXFBV1VDpy9v2PL+YUOEC4Frxcu0Z MO2Q== Received: by 10.236.155.6 with SMTP id i6mr7026687yhk.87.1333721121826; Fri, 06 Apr 2012 07:05:21 -0700 (PDT) Received: from [192.168.1.213] (190-20-46-139.baf.movistar.cl. [190.20.46.139]) by mx.google.com with ESMTPS id v26sm28270727yhk.1.2012.04.06.07.05.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Apr 2012 07:05:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_CCE22E4A-A339-4B2E-8542-CDEC0FF4A82C"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Fri, 6 Apr 2012 11:05:12 -0300 Message-Id: <2EFB0A5A-D2CA-4CE8-92F0-57BC9741F5DC@ve7jtb.com> References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> To: "Cantor, Scott" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnNTBld2EcSayHvyJKLSJ9m5NV0Tr5F09Hptxe8V0XyGB0g7RqcwDA734S0832oWRI4GaSq Cc: "jose@ietf.org" , "Axel.Nennker@telekom.de" , "juraj.somorovsky@rub.de" Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:05:23 -0000 --Apple-Mail=_CCE22E4A-A339-4B2E-8542-CDEC0FF4A82C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I largely agree with Scott, The security considerations for people implementing JOSE libraries are = going to be important. The upper level protocols like Connect are not going to cover all the = possible side channel attacks against a library. Yes messages should be available to the upper level application so that = it can decide what to report on the wire. However every effort to protect from side channel and other attacks need = to be taken by the crypto libraries themselves. If there are algorithm choices we could make like only supporting PKCS#2 = OAEP in the JOSE spec to reduce the potential implementation issues. That is probably the level we need to have the discussion at right now. John B. On 2012-04-06, at 10:48 AM, Cantor, Scott wrote: >> We do not define things like "you should change your keys after n = operations >> or N megabytes of plaintext processed (or when a BadPadding Exception = is >> thrown). I think that my code should throw all exceptions in all = their glory >> details and that e.g. the application server "above" me should then = decide >> which action to take: like "Give a standard error message" to the = sender of >> the bad message and wait a random amount of time before sending error >> messages. But this is not the task of this code. >=20 > Yes, it is. If you want to use PKCS#1.5, then you need to make that = usable safely without extra precautions by your caller. If we were = talking about the actual implementation of PKCS1.5, then you might be = right, but you're not implementing that, you're using it to encrypt = objects you're trying to abstract in a library. That makes it your job = to make encryption a "safe" operation for somebody using that = abstraction, if you can. >=20 > In the case of this attack, detailed error information can be put in = logs, and doesn't need to be exposed to callers, and the generation of a = random key easily defeats the timing attack. >=20 > There are harder problems that are virtually impossible to solve that = way (the CBC attack). This one is easy and entirely appropriate to fix = below any protocol. >=20 >> My understanding of the level that we are describing here is "below" >> protocols. >=20 > And the encryption here is also below the protocol. If it weren't, = that would be a different matter. >=20 >> I fear that we end up in a discussion that I followed in the NSS = discussion >> group years ago. "Should we give developers cryptographic building = blocks >> that could be used wrong". Then NSS decided not to do it but I think = that >> was wrong. >=20 > NSS is a crypto library (meaning it actually implements PKCS1.5). = That's a different layer. >=20 >> I think that the protocols that use the JOSE formats/algs like openid = connect >> (https://openid.net/connect/) have the duty to use them correctly. >=20 > They do, but that doesn't absolve libraries of the responsibility of = being implemented correctly also. Otherwise, be prepared for most of the = protocol implementations using your code to get it wrong. >=20 > -- Scott >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_CCE22E4A-A339-4B2E-8542-CDEC0FF4A82C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NjE0MDUxMlowIwYJKoZIhvcNAQkEMRYEFNht6+URw2xA/ovWKOhJw6zT58vJMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AIhnZvY6U6tVsHEffU5+06uaewdVhQe8MtgKF1rMB/Q7OkCGbvWMzEagi5Pb+RpQbgWdYqkvvNCP sRb20ihDavdS/sxqUEMjV8TKkmdzkp34cavXDIE0OnWeyjfVInQ2rfx3lvyptx4dWawCfvRsBoF8 gJ2jYBcpjZjYfnIg+yO08nIJv5XoD6OQxwlTqXzlgW3rrJjrcaCgji+e4nUqv1uGR1QS0ozPaQae NFIwoE/hNzQs/a5ou69S9gEtUs9zQIfLbNT/pZOxPLWFl7mmpluyQvIhwgu/OZaZRcYIOHwmu10Y budBqtEoVUTtgz07Xbi8cTgex05H22Mc/LoWzfsAAAAAAAA= --Apple-Mail=_CCE22E4A-A339-4B2E-8542-CDEC0FF4A82C-- From cantor.2@osu.edu Fri Apr 6 07:14:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6C821F858E for ; Fri, 6 Apr 2012 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz1rYuT6NiQq for ; Fri, 6 Apr 2012 07:14:31 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4080921F8557 for ; Fri, 6 Apr 2012 07:14:31 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q36EEFKY013185; Fri, 6 Apr 2012 10:14:30 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 10:14:19 -0400 From: "Cantor, Scott" To: John Bradley Thread-Topic: [jose] JWT + JOSE for Java Thread-Index: Ac0TQOywoVci1rfxSwCEC1LxOxoDCAAeHKagABBnA2AACTUFAAAILrkQ Date: Fri, 6 Apr 2012 14:14:18 +0000 Message-ID: References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> <2EFB0A5A-D2CA-4CE8-92F0-57BC9741F5DC@ve7jtb.com> In-Reply-To: <2EFB0A5A-D2CA-4CE8-92F0-57BC9741F5DC@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.3; boundary="----=_NextPart_000_0008_01CD13DE.06523250" MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "jose@ietf.org" Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:14:32 -0000 ------=_NextPart_000_0008_01CD13DE.06523250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > If there are algorithm choices we could make like only supporting PKCS#2 > OAEP in the JOSE spec to reduce the potential implementation issues. > > That is probably the level we need to have the discussion at right now. I would agree, and I would also question the need to include PKCS1.5 in this work. Every algorithm that's duplicative is just more work, let alone when they introduce risk. -- Scott ------=_NextPart_000_0008_01CD13DE.06523250 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCFR4w ggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAx NTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/ I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOM luLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJb BpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZ whZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGj ggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUH AQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUH MAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI2 2zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIB ivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIb rjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWT gBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSX ur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJ PWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75 oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd 83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxUw ggX9oAMCAQICAwNS6TANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTExMTEyNzIwMjIwOVoXDTEyMTEyODA3MzE1NFowXjEgMB4GA1UEDRMXNTc3MTk5LTlpd3VS NUNNZ3VWbDc0OFUxGTAXBgNVBAMMEGNhbnRvci4yQG9zdS5lZHUxHzAdBgkqhkiG9w0BCQEWEGNh bnRvci4yQG9zdS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDU6ccvM83KLdE2 wQEQjnydF1uDeQYYwpFnpcmzalPnHgSufs+SnzpWUHmzKjvoLJaXOECAg1KVZhVwyEfIIMvuvHS3 lzyCuBbcVtT+gdvYbNVG8pzcTbY29/9WsDUEpk3chSoU1P4QPVqmAR7x/87Uja7GeTFTUOeaulna wN3N+yWCXqp1N81Hf6XhS75Id2kZ+APZk6alMotEGKOiuCy727PrE5MgZvFJkF4gxeoCSgjtI6An UfsaK5+zXZb0Ska6igR2MhUSOIqil7bA7PT/znrmD51VbUnN6eN0kgG3gSmwWLPrR+qvqs4V3q9/ DUO+Cv71Z1/g+ttXzMkyA2G9AgMBAAGjggOrMIIDpzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFH1SgaZJFhK3aa8SD9a09zle 4zLZMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBsGA1UdEQQUMBKBEGNhbnRvci4y QG9zdS5lZHUwggIhBgNVHSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcC ARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2Fz IGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMg b2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4w gZwGCCsGAQUFBwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIa ZExpYWJpbGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2Fs IGFuZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEE gYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xp ZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xh c3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0G CSqGSIb3DQEBBQUAA4IBAQCeuvMt2HVZLqBX3/h4Lvnq1lpV+ss9SMhVGyCld5+iDfW2ouWE23La u5b1kB7DzrFrj92otyZx8wCWBvbUj0IqZ/RXqeHXMalZ1yKBxFJjj/j2WM70+OiACRAkzetmr1ST j3PO5OEKamNlusX9oSQ4xnLdBDJnH2QG3VIKNWA7WXXz4GnTokR67pZI2oOgy/mLGYMNEFfh0jgl B/kQT7PyvgrOyb3XUFyMzWyHzp9zRzkiRUE9ITvwRByk8SJDGf/NMWz6b1rUOyee6tz/z0wpzsgp ElZYp2n7bakZWIb4FSwmJXgH3OVE0CSmM6NQee3W9nms2EKQXru04nz+dowQMIIHyTCCBbGgAwIB AgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3 MTk0NjM2WjB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJ vGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v /uqwQVlntsQGfQqedIXWeUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9 ujPW3U3eCztKS5/CJi/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6 RtYTKqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBT ViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apd zK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVN WG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN 0nZPV/+Qt+OR0t3vwmC3Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOz EmDyei+B26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQAB o4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mH MMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNj YS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIB XQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVy Y2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBz ZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Bv bGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVl IFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQ hV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2g JsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU 424oh0TDkBreOKk8rENNZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNm ezwD7dOaHZrzZVD1oNB1ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQ i+fHLB5LEUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lw hceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vB tfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3h ZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7 N4RDYiDK51ZLZer+bMEkkyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggRNMIIESQIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMDUukwDQYJYIZIAWUDBAIDBQCgggKJ MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNjE0MTQxN1ow TwYJKoZIhvcNAQkEMUIEQAJIKMZB8rgAnpMbC3pqciCAvfdMBp8/CLCifJITUFel5imFFg2a11yu HjCA50mUz23BkQGdJ4b5JtLRh9zcsKgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMDUukwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0ECAwNS6TCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBFjALBglg hkgBZQMEASowCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDALBglghkgBZQMEAgMwCwYJYIZIAWUDBAIC MAsGCWCGSAFlAwQCATAHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASCAQBg+LgDAZnr+7g9OLfdNqw+ qdGoDmrutAXNY9G2ToxZidvDHAmerw0hSZ4p+Clp2Eek3lJpFtuv3zKnP3shTNcEcxd0M15U/EMZ ANy8Zp4V/xyAo7cDeqQTlMgsBbWnwsLnypIqR8rP1wmvgXq7K1KKQIGTMQa3QtR8pGRyhtV5u4GG U2seolkQ6ukF4gOvGmWMNihn7qsR6cBtgUzUXkhIdHqfwjup0NtEFzPwqaR+L6JWoDq/W3TukFLC BW23zvsyMPwbxmXNlNLHh76J7Bl3nZldEGRSbMvm9z5oPF+gogvKTt0sAKa4bxk73RLP2bzbUNU7 kKI9whuSPDeq/uO6AAAAAAAA ------=_NextPart_000_0008_01CD13DE.06523250-- From juraj.somorovsky@rub.de Fri Apr 6 11:53:50 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA7421F85AA for ; Fri, 6 Apr 2012 11:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-akyFzBWn4r for ; Fri, 6 Apr 2012 11:53:49 -0700 (PDT) Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id 4110521F85A0 for ; Fri, 6 Apr 2012 11:53:46 -0700 (PDT) X-Queued: (qmail 6244 invoked by alias); 6 Apr 2012 18:53:46 -0000 X-Queued: (qmail 6230 invoked from network); 6 Apr 2012 18:53:46 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx6.rz.ruhr-uni-bochum.de with SMTP; 6 Apr 2012 18:53:46 -0000 X-Queued: (qmail 18418 invoked by uid 281); 6 Apr 2012 18:53:45 -0000 X-Qmailscanner: from 178.201.46.200 (7Cil8M2CiUzBN8b9y3+x5Q==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.29/4.75. Clear:RC:1(178.201.46.200):. Processed in 0.034925 secs); 06 Apr 2012 18:53:45 -0000 Received: from ip-178-201-46-200.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUzBN8b9y3+x5Q==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 6 Apr 2012 18:53:45 -0000 Date: 6 Apr 2012 20:53:42 +0200 Message-ID: <4F7F3BB6.8030509@rub.de> From: "Juraj Somorovsky" To: "Cantor, Scott" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "jose@ietf.org" , "Axel.Nennker@telekom.de" Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:53:50 -0000 On 04/06/2012 03:48 PM, Cantor, Scott wrote: >> We do not define things like "you should change your keys after n operations >> > or N megabytes of plaintext processed (or when a BadPadding Exception is >> > thrown). I think that my code should throw all exceptions in all their glory >> > details and that e.g. the application server "above" me should then decide >> > which action to take: like "Give a standard error message" to the sender of >> > the bad message and wait a random amount of time before sending error >> > messages. But this is not the task of this code. > Yes, it is. If you want to use PKCS#1.5, then you need to make that usable safely without extra precautions by your caller. If we were talking about the actual implementation of PKCS1.5, then you might be right, but you're not implementing that, you're using it to encrypt objects you're trying to abstract in a library. That makes it your job to make encryption a "safe" operation for somebody using that abstraction, if you can. > > In the case of this attack, detailed error information can be put in logs, and doesn't need to be exposed to callers, and the generation of a random key easily defeats the timing attack. > > There are harder problems that are virtually impossible to solve that way (the CBC attack). This one is easy and entirely appropriate to fix below any protocol. > I fully agree with Scott, I want to add only two remarks: 1) timing and random amount of time: each security researcher interested in side-channels would tell you that handling timing side-channels with a random amount of time is generally a bad idea. Moreover, what should be the random amount of time for decryption of 100KB of data? What about decryption of 1MB of data? Should each developer test his server performance before deploying the library? ...thus, random key regeneration is needed. 2) Exceptions: as Scott already mentioned, the exceptions can be checked in the server logs. The developer does not have to get three different exception types with concrete errors since he needs to tell the application user only: "during the decryption process something went wrong". If you give the developer these three exceptions, he will most probably forward them to the user (which causes direct application of the Bleichenbacher's attack) JBossWS or Axis2 Web Services Frameworks e.g. return to the service client only "Security processing failed" or "Decryption processing failed" error messages when the request is invalid. If the user needs to get more information, he needs to check the server logs. Regards Juraj -- M.Sc. Juraj Somorovsky Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum ----------------------------------- Universitätsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de From juraj.somorovsky@rub.de Fri Apr 6 12:02:27 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F301711E8098 for ; Fri, 6 Apr 2012 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzutwZ0Xte4p for ; Fri, 6 Apr 2012 12:02:26 -0700 (PDT) Received: from mx5.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.33]) by ietfa.amsl.com (Postfix) with SMTP id D069521F855B for ; Fri, 6 Apr 2012 12:02:25 -0700 (PDT) X-Queued: (qmail 21938 invoked by alias); 6 Apr 2012 19:02:21 -0000 X-Queued: (qmail 21925 invoked from network); 6 Apr 2012 19:02:21 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx5.rz.ruhr-uni-bochum.de with SMTP; 6 Apr 2012 19:02:21 -0000 X-Queued: (qmail 25534 invoked by uid 281); 6 Apr 2012 19:02:21 -0000 X-Qmailscanner: from 178.201.46.200 (7Cil8M2CiUwIdnfJvORU+g==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.29/4.75. Clear:RC:1(178.201.46.200):. Processed in 0.034514 secs); 06 Apr 2012 19:02:21 -0000 Received: from ip-178-201-46-200.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUwIdnfJvORU+g==@178.201.46.200) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 6 Apr 2012 19:02:20 -0000 Date: 6 Apr 2012 21:02:20 +0200 Message-ID: <4F7F3DBC.4080905@rub.de> From: "Juraj Somorovsky" To: jose@ietf.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 References: <20120405060358.cc40c4f3d92d2001859047cd8cabb9ab.9b9e518b81.wbe@email07.europe.secureserver.net> <4F7DBA63.3020503@rub.de> <2EFB0A5A-D2CA-4CE8-92F0-57BC9741F5DC@ve7jtb.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [jose] JWT + JOSE for Java X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:02:27 -0000 On 04/06/2012 04:14 PM, Cantor, Scott wrote: >> If there are algorithm choices we could make like only supporting PKCS#2 >> OAEP in the JOSE spec to reduce the potential implementation issues. >> >> That is probably the level we need to have the discussion at right now. > > I would agree, and I would also question the need to include PKCS1.5 in this > work. Every algorithm that's duplicative is just more work, let alone when > they introduce risk. > > -- Scott Agreed, removing PKCS1.5 and supporting only PKCS2.0 is the good way to go. It will be much more easier for the library developers not to take care about the attacks resulting from the PKCS1.5 standard. Regards Juraj > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- M.Sc. Juraj Somorovsky Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum ----------------------------------- Universitätsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de From Michael.Jones@microsoft.com Fri Apr 6 14:05:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081BC11E8098 for ; Fri, 6 Apr 2012 14:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL0sHcKK7Kw0 for ; Fri, 6 Apr 2012 14:05:24 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE721F8516 for ; Fri, 6 Apr 2012 14:05:24 -0700 (PDT) Received: from mail180-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Apr 2012 21:05:24 +0000 Received: from mail180-ch1 (localhost [127.0.0.1]) by mail180-ch1-R.bigfish.com (Postfix) with ESMTP id 1F08D2A0246 for ; Fri, 6 Apr 2012 21:05:24 +0000 (UTC) X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail180-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1 (MessageSwitch) id 1333746322997073_8954; Fri, 6 Apr 2012 21:05:22 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail180-ch1.bigfish.com (Postfix) with ESMTP id E5F6714004E for ; Fri, 6 Apr 2012 21:05:22 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Apr 2012 21:05:22 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Fri, 6 Apr 2012 21:05:21 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) Thread-Index: Ac0UOPPLd4xE93YWQ0SPm6yk+Ezhmw== Date: Fri, 6 Apr 2012 21:05:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436645DE9A@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436645DE9ATK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 21:05:26 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436645DE9ATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The JSON Web Key (JWK) spec currently contains the algorithm family definit= ions and parameter specifications for the RSA and Elliptic Curve algorithm = families. An editorial open issue is whether to leave these in the JWK spe= c or move them to the JWA spec. The argument for leaving them in the JWK spec is that removing the definiti= ons of "EC" and "RSA" and the family-specific parameter definitions ("crv",= "x", "y", "mod", "exp") would leave very little normative text in the JWK = spec itself. It seemed like doing this would reduce the readability of the= JWK spec, and so was not done in -01. The argument for moving them is that all the algorithm-specific definitions= would then be in the JWA spec and good examples of RSA and EC keys could r= emain in the JWK spec. References to the pertinent specs are: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-01 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01 Feedback? -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436645DE9ATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The JSON Web Key (JWK) spec currently contains the a= lgorithm family definitions and parameter specifications for the RSA and El= liptic Curve algorithm families.  An editorial open issue is whether t= o leave these in the JWK spec or move them to the JWA spec.

 

The argument for leaving them in the JWK spec is tha= t removing the definitions of “EC” and “RSA” and th= e family-specific parameter definitions ("crv", "x", &q= uot;y", "mod", "exp") would leave very little norm= ative text in the JWK spec itself.  It seemed like doing this would reduce the readability of the JWK sp= ec, and so was not done in -01.

 

The argument for moving them is that all the algorit= hm-specific definitions would then be in the JWA spec and good examples of = RSA and EC keys could remain in the JWK spec.

 

References to the pertinent specs are:

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

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-algorithms-01

 

Feedback?

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436645DE9ATK5EX14MBXC283r_-- From ietf@augustcellars.com Sat Apr 7 07:26:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4221F8552 for ; Sat, 7 Apr 2012 07:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEKwdEb7Pas5 for ; Sat, 7 Apr 2012 07:26:23 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C35B121F8551 for ; Sat, 7 Apr 2012 07:26:23 -0700 (PDT) Received: from Tobias (50-39-221-206.bvtn.or.frontiernet.net [50.39.221.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 45B332CA0C; Sat, 7 Apr 2012 07:26:23 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B16804296739436645DE9A@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436645DE9A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 7 Apr 2012 07:25:30 -0700 Message-ID: <001f01cd14ca$49a853d0$dcf8fb70$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CD148F.9D4B9EB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+quRoy5Y2UsIs2yap/w0lQezfcpWsPqJg Content-Language: en-us Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 14:26:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01CD148F.9D4B9EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please explain why you believe the readability of the document would be reduced. There would still be the ability to have examples that referenced the algorithm draft. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, April 06, 2012 2:05 PM To: jose@ietf.org Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) The JSON Web Key (JWK) spec currently contains the algorithm family definitions and parameter specifications for the RSA and Elliptic Curve algorithm families. An editorial open issue is whether to leave these in the JWK spec or move them to the JWA spec. The argument for leaving them in the JWK spec is that removing the definitions of "EC" and "RSA" and the family-specific parameter definitions ("crv", "x", "y", "mod", "exp") would leave very little normative text in the JWK spec itself. It seemed like doing this would reduce the readability of the JWK spec, and so was not done in -01. The argument for moving them is that all the algorithm-specific definitions would then be in the JWA spec and good examples of RSA and EC keys could remain in the JWK spec. References to the pertinent specs are: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-01 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01 Feedback? -- Mike ------=_NextPart_000_0020_01CD148F.9D4B9EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please explain why you believe the readability = of the document would be reduced.  There would still be the ability = to have examples that referenced the algorithm = draft.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Friday, April 06, 2012 2:05 = PM
To: jose@ietf.org
Subject: [jose] Open Issue for = WG Discussion: Whether to move JWK algorithm family definitions to JWA = spec (editorial)

 

The JSON Web = Key (JWK) spec currently contains the algorithm family definitions and = parameter specifications for the RSA and Elliptic Curve algorithm = families.  An editorial open issue is whether to leave these in the = JWK spec or move them to the JWA spec.

 

The argument = for leaving them in the JWK spec is that removing the definitions of = “EC” and “RSA” and the family-specific parameter = definitions ("crv", "x", "y", = "mod", "exp") would leave very little normative text = in the JWK spec itself.  It seemed like doing this would reduce the = readability of the JWK spec, and so was not done in = -01.

 

The argument for moving them is that all the = algorithm-specific definitions would then be in the JWA spec and good = examples of RSA and EC keys could remain in the JWK = spec.

 

References to the pertinent specs = are:

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

<= p class=3DMsoNormal>http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01

 

Feedback?

 

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

 

------=_NextPart_000_0020_01CD148F.9D4B9EB0-- From ve7jtb@ve7jtb.com Sat Apr 7 07:46:27 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0003921F8566 for ; Sat, 7 Apr 2012 07:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T79vUUfFbVdm for ; Sat, 7 Apr 2012 07:46:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D771B21F8565 for ; Sat, 7 Apr 2012 07:46:25 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1670901ghb.31 for ; Sat, 07 Apr 2012 07:46:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=qEC1z1veyOtriWBRg7n/fcTlWTBV4GU5caSuEuGKXmE=; b=gcKc5o41dtMQWFmHD6xlvE+VNGtQrh5pal1WTiLahMFcy45m/z5XaIA0x4pl2UjGnA K1NQHfLWsgC9dNXKbXEDR7T7Y70sC2TOREWswDNRsF+hdgpR1SVcU1idqLseeXvVl3av UAMmvJgWZsycAv1H4LTaMUoK6vWz9oKaszWOtM5pbUE54LpyxOPfUUv9IW+x/z1E0mRV t4CG74beVuT3KwTmirncUzv5EWlRxEX9qpu90Gus41WThcE/pot1mXi5A11E70r7gPQT k1ES0sW2AYNrXTztkoCLN3F/6F2BqY51pC1Iz/bDs4PBOa6NzJkmNexh5WikcLI8iG2o FPMQ== Received: by 10.236.161.232 with SMTP id w68mr1196772yhk.56.1333809985112; Sat, 07 Apr 2012 07:46:25 -0700 (PDT) Received: from [192.168.1.213] (190-20-30-181.baf.movistar.cl. [190.20.30.181]) by mx.google.com with ESMTPS id e45sm41395000yhk.2.2012.04.07.07.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Apr 2012 07:46:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D01F053E-650D-43B6-B44F-6827A4A190C3"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <001f01cd14ca$49a853d0$dcf8fb70$@augustcellars.com> Date: Sat, 7 Apr 2012 11:45:47 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436645DE9A@TK5EX14MBXC283.redmond.corp.microsoft.com> <001f01cd14ca$49a853d0$dcf8fb70$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkZM0MUVaObyZ9WM14HMbHv2mkGWrP755GMKCUW/O9jQ1xnL8y4YYtyz919jQ1QSq7P9sOJ Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 14:46:27 -0000 --Apple-Mail=_D01F053E-650D-43B6-B44F-6827A4A190C3 Content-Type: multipart/alternative; boundary="Apple-Mail=_39234A5A-E686-49EB-94FE-1BC18C02B91F" --Apple-Mail=_39234A5A-E686-49EB-94FE-1BC18C02B91F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It is mostly a style question I think. Given that the elements can be directly embedded in JWE, as well as = being represented externally in a JWK, I think JWA is probably the = correct place for them as it makes it easier to add new crypto algs. The solution for JWK is good examples I think. I suppose the downside is an extra level of indirection through the = specs for developers. I don't feel strongly one way or the other, just have a slight = preference for JWA. (My track record on document structure is slightly = suspect though) John B. On 2012-04-07, at 11:25 AM, Jim Schaad wrote: > Please explain why you believe the readability of the document would = be reduced. There would still be the ability to have examples that = referenced the algorithm draft. > =20 > Jim > =20 > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Friday, April 06, 2012 2:05 PM > To: jose@ietf.org > Subject: [jose] Open Issue for WG Discussion: Whether to move JWK = algorithm family definitions to JWA spec (editorial) > =20 > The JSON Web Key (JWK) spec currently contains the algorithm family = definitions and parameter specifications for the RSA and Elliptic Curve = algorithm families. An editorial open issue is whether to leave these = in the JWK spec or move them to the JWA spec. > =20 > The argument for leaving them in the JWK spec is that removing the = definitions of =93EC=94 and =93RSA=94 and the family-specific parameter = definitions ("crv", "x", "y", "mod", "exp") would leave very little = normative text in the JWK spec itself. It seemed like doing this would = reduce the readability of the JWK spec, and so was not done in -01. > =20 > The argument for moving them is that all the algorithm-specific = definitions would then be in the JWA spec and good examples of RSA and = EC keys could remain in the JWK spec. > =20 > References to the pertinent specs are: > http://tools.ietf.org/html/draft-ietf-jose-json-web-key-01 > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01 > =20 > Feedback? > =20 > -- = Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_39234A5A-E686-49EB-94FE-1BC18C02B91F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It is mostly a style question I = think.

Given that the elements can be directly = embedded in JWE,  as well as being represented externally in a JWK, =  I think JWA is probably the correct place for them as it makes it = easier to add new crypto algs.

The solution for = JWK is good examples I think.

I suppose the = downside is an extra level of indirection through the specs for = developers.

I don't feel strongly one way or = the other, just have a slight preference for JWA. (My track record on = document structure is slightly suspect = though)

John B.
On = 2012-04-07, at 11:25 AM, Jim Schaad wrote:

Please explain why you believe the readability of the = document would be reduced.  There would still be the ability to = have examples that referenced the algorithm = draft.
 
Jim
 
 
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Friday, April 06, 2012 2:05 = PM
To: jose@ietf.org
Subject: [jose] Open Issue for WG = Discussion: Whether to move JWK algorithm family definitions to JWA spec = (editorial)
The JSON Web Key (JWK) spec = currently contains the algorithm family definitions and parameter = specifications for the RSA and Elliptic Curve algorithm families.  = An editorial open issue is whether to leave these in the JWK spec or = move them to the JWA spec.
The argument for leaving them in the = JWK spec is that removing the definitions of =93EC=94 and =93RSA=94 and = the family-specific parameter definitions ("crv", "x", "y", "mod", = "exp") would leave very little normative text in the JWK spec itself. =  It seemed like doing this would reduce the readability of the JWK = spec, and so was not done in -01.
 
The argument for moving them = is that all the algorithm-specific definitions would then be in the JWA = spec and good examples of RSA and EC keys could remain in the JWK = spec.
 
References to the = pertinent specs are:
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_39234A5A-E686-49EB-94FE-1BC18C02B91F-- --Apple-Mail=_D01F053E-650D-43B6-B44F-6827A4A190C3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQw NzE0NDU0OFowIwYJKoZIhvcNAQkEMRYEFG8MznKB/G2b+bRUb7YtR+RR10nmMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AD2nc9fCN7tZsClQhEpUGoaFMPv/OVQHQoTIuW2vU4XWg8obFN3r9/5a/C+wPwj5+BcpN9AQbJIk 7/6GFUMpeCv5fX93kT6f11shcu09o8SWvrhEp2sLTkPI00hSaQcR+UhxdnRzpI5WjtHKyf91BPX/ dqbdGhNbY99fSClFnF8iy8n9zwqCJttAJnzo6nmYB5vZAOwACftpkZpwo6DkEq6xPBb0/VJ4gjPR WW/D3xIz9lSuvdzZuUCRr9T054VFg/scfbcQckxjxUpG5Ocv3xfM7JnxqxUe32VJemoEbqpMuEyT ryisg1bjhzbXRwzg0kHCNQ46sBKz8+wDQTaGoBkAAAAAAAA= --Apple-Mail=_D01F053E-650D-43B6-B44F-6827A4A190C3-- From Michael.Jones@microsoft.com Mon Apr 9 08:46:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D966821F86C9 for ; Mon, 9 Apr 2012 08:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.038 X-Spam-Level: X-Spam-Status: No, score=-5.038 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmMRP8M1NLzu for ; Mon, 9 Apr 2012 08:46:47 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8E00D21F86CB for ; Mon, 9 Apr 2012 08:46:47 -0700 (PDT) Received: from mail104-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 15:46:46 +0000 Received: from mail104-tx2 (localhost [127.0.0.1]) by mail104-tx2-R.bigfish.com (Postfix) with ESMTP id D69A23003E7; Mon, 9 Apr 2012 15:46:46 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371I936eKc85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail104-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail104-tx2 (localhost.localdomain [127.0.0.1]) by mail104-tx2 (MessageSwitch) id 1333986404182559_2771; Mon, 9 Apr 2012 15:46:44 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.244]) by mail104-tx2.bigfish.com (Postfix) with ESMTP id 1C49B180137; Mon, 9 Apr 2012 15:46:44 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 15:46:42 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Mon, 9 Apr 2012 15:46:41 +0000 From: Mike Jones To: John Bradley , Jim Schaad Thread-Topic: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) Thread-Index: AQHNFMprBXeoX0J2x0ei69tE1/e6NZaPcKeAgAM009A= Date: Mon, 9 Apr 2012 15:46:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436645F5EB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436645DE9A@TK5EX14MBXC283.redmond.corp.microsoft.com> <001f01cd14ca$49a853d0$dcf8fb70$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436645F5EBTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:46:50 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436645F5EBTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The readability would be somewhat reduced by having to refer to the second = document. That being said, I believe this could be mitigated by the use of= examples. Since opinion (of the two participants in the discussion to dat= e) seems to favor moving the algorithm family definitions to JWA, I'll plan= on doing that unless others speak up taking the counter position. -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Saturday, April 07, 2012 7:46 AM To: Jim Schaad Cc: Mike Jones; jose@ietf.org Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK algor= ithm family definitions to JWA spec (editorial) It is mostly a style question I think. Given that the elements can be directly embedded in JWE, as well as being = represented externally in a JWK, I think JWA is probably the correct place= for them as it makes it easier to add new crypto algs. The solution for JWK is good examples I think. I suppose the downside is an extra level of indirection through the specs f= or developers. I don't feel strongly one way or the other, just have a slight preference f= or JWA. (My track record on document structure is slightly suspect though) John B. On 2012-04-07, at 11:25 AM, Jim Schaad wrote: Please explain why you believe the readability of the document would be red= uced. There would still be the ability to have examples that referenced th= e algorithm draft. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Friday, April 06, 2012 2:05 PM To: jose@ietf.org Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm= family definitions to JWA spec (editorial) The JSON Web Key (JWK) spec currently contains the algorithm family definit= ions and parameter specifications for the RSA and Elliptic Curve algorithm = families. An editorial open issue is whether to leave these in the JWK spe= c or move them to the JWA spec. The argument for leaving them in the JWK spec is that removing the definiti= ons of "EC" and "RSA" and the family-specific parameter definitions ("crv",= "x", "y", "mod", "exp") would leave very little normative text in the JWK = spec itself. It seemed like doing this would reduce the readability of the= JWK spec, and so was not done in -01. The argument for moving them is that all the algorithm-specific definitions= would then be in the JWA spec and good examples of RSA and EC keys could r= emain in the JWK spec. References to the pertinent specs are: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-01 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01 Feedback? -- Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436645F5EBTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The readability would be = somewhat reduced by having to refer to the second document.  That bein= g said, I believe this could be mitigated by the use of examples.  Since opinion (of the two participants in the discussion to date) seems to= favor moving the algorithm family definitions to JWA, I’ll plan on d= oing that unless others speak up taking the counter position.

 <= /p>

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

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Saturday, April 07, 2012 7:46 AM
To: Jim Schaad
Cc: Mike Jones; jose@ietf.org
Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JW= K algorithm family definitions to JWA spec (editorial)

 

It is mostly a style question I think.

 

Given that the elements can be directly embedded in = JWE,  as well as being represented externally in a JWK,  I think = JWA is probably the correct place for them as it makes it easier to add new= crypto algs.

 

The solution for JWK is good examples I think.<= /o:p>

 

I suppose the downside is an extra level of indirect= ion through the specs for developers.

 

I don't feel strongly one way or the other, just hav= e a slight preference for JWA. (My track record on document structure is sl= ightly suspect though)

 

John B.

On 2012-04-07, at 11:25 AM, Jim Schaad wrote:



Please explain why you be= lieve the readability of the document would be reduced.  There would s= till be the ability to have examples that referenced the algorithm draft.

 

Jim

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf= .org] On Behalf Of=  Mike Jones
Sent: Friday, Apri= l 06, 2012 2:05 PM
To: jose@ietf.org
Subject: [jose] Op= en Issue for WG Discussion: Whether to move JWK algorithm family definition= s to JWA spec (editorial)

 

The JSON Web Key (JWK) spec currently c= ontains the algorithm family definitions and parameter specifications for t= he RSA and Elliptic Curve algorithm families.  An editorial open issue is whether to leave these in the JWK spec or move them to the J= WA spec.

 

The argument for leaving them in the JW= K spec is that removing the definitions of “EC” and “RSA&= #8221; and the family-specific parameter definitions ("crv", &quo= t;x", "y", "mod", "exp") would leave very little normative text in the JWK spec itself.  It se= emed like doing this would reduce the readability of the JWK spec, and so w= as not done in -01.

 

The argument for moving them is that al= l the algorithm-specific definitions would then be in the JWA spec and good= examples of RSA and EC keys could remain in the JWK spec.

 

References to the pertinent specs are:<= o:p>

 

Feedback?

 

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

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436645F5EBTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Apr 9 09:25:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3237D21F8778 for ; Mon, 9 Apr 2012 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2Dn8GPSXKmN for ; Mon, 9 Apr 2012 09:25:47 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id D29F221F8738 for ; Mon, 9 Apr 2012 09:25:46 -0700 (PDT) Received: from mail103-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 16:25:45 +0000 Received: from mail103-db3 (localhost [127.0.0.1]) by mail103-db3-R.bigfish.com (Postfix) with ESMTP id 70FCD3C073E for ; Mon, 9 Apr 2012 16:25:45 +0000 (UTC) X-SpamScore: -21 X-BigFish: VS-21(zzc85fh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail103-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail103-db3 (localhost.localdomain [127.0.0.1]) by mail103-db3 (MessageSwitch) id 1333988743330732_20585; Mon, 9 Apr 2012 16:25:43 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.246]) by mail103-db3.bigfish.com (Postfix) with ESMTP id 42A3E2C004A for ; Mon, 9 Apr 2012 16:25:43 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 16:25:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0283.004; Mon, 9 Apr 2012 16:25:39 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Open Issue for WG Discussion: Disposition of JSON Serialization Functionality Thread-Index: Ac0WbWXHYX/Vund+T9CNkkvP3fJCBQ== Date: Mon, 9 Apr 2012 16:25:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436645F6F6@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436645F6F6TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Open Issue for WG Discussion: Disposition of JSON Serialization Functionality X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:25:49 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436645F6F6TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You'll recall that I created JSON Serialization drafts in response to WG in= put that use the same cryptographic operations as JWS and JWE, but that ser= ialize the results into a JSON objects, rather than base64url encoded value= s separated by periods. These representations also enable multiple signatu= res/HMACs to be used and content to be encrypted to multiple recipients. T= he current versions of these drafts are: * http://tools.ietf.org/html/draft-jones-json-web-signature-json-ser= ialization-01 * http://tools.ietf.org/html/draft-jones-json-web-encryption-json-se= rialization-01 It was decided in Paris that the disposition of this functionality should b= e discussed by the WG on the list. I think the questions we need to decide= are: 1. Is the working group interested in pursuing this functionality? (Evide= nce to date is that the answer to this question is "yes".) 2. If the answer to (1) is "yes", would the working group like to have thi= s functionality be in working group documents at this time (rather than bei= ng described in individual submissions, as at present)? 3. If the answer to (2) is "yes", should working group -00 versions of the= JSON Serialization documents be created or should this functionality be fo= lded into the existing JWS and JWE specs? Arguments for keeping this functionality separate for now are: - Different level of maturity: I'm aware of over a dozen implementations= of JWS a few of JWE, but I know of no implementations of JWS-JS or JWE-JS.= There's an argument that we should keep this new functionality separate u= ntil we have "rough consensus and running code". - Document simplicity for the Compact Serialization use case. Not descri= bing a second serialization in the JWS and JWE documents makes the document= s somewhat easier to read if all the implementer needs is the Compact Seria= lization. Arguments for merging it in now are: - Fewer documents needed to provide comprehensive treatment of the materi= al. Opinions from the Working Group? Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436645F6F6TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You’ll recall that I created JSON Serializatio= n drafts in response to WG input that use the same cryptographic operations= as JWS and JWE, but that serialize the results into a JSON objects, rather= than base64url encoded values separated by periods.  These representations also enable multiple signatures/HM= ACs to be used and content to be encrypted to multiple recipients.  Th= e current versions of these drafts are:

·        http://tools.ietf.org/html/= draft-jones-json-web-signature-json-serialization-01

·        http://tools.ietf.org/html= /draft-jones-json-web-encryption-json-serialization-01

 

It was decided in Paris that the disposition of this= functionality should be discussed by the WG on the list.  I think the= questions we need to decide are:

 

1.  Is the working group interested in pursuing= this functionality?  (Evidence to date is that the answer to this que= stion is “yes”.)

 

2.  If the answer to (1) is “yes”, = would the working group like to have this functionality be in working group= documents at this time (rather than being described in individual submissi= ons, as at present)?

 

3.  If the answer to (2) is “yes”, = should working group -00 versions of the JSON Serialization documents be cr= eated or should this functionality be folded into the existing JWS and JWE = specs?

 

Arguments for keeping this functionality separate fo= r now are:

  - Different level of maturity:  I’= m aware of over a dozen implementations of JWS a few of JWE, but I know of = no implementations of JWS-JS or JWE-JS.  There’s an argument tha= t we should keep this new functionality separate until we have “rough consensus and running code”.

  - Document simplicity for the Compact Seriali= zation use case.  Not describing a second serialization in the JWS and= JWE documents makes the documents somewhat easier to read if all the imple= menter needs is the Compact Serialization.

 

Arguments for merging it in now are:

  - Fewer documents needed to provide comprehen= sive treatment of the material.

 

Opinions from the Working Group?

 

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

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436645F6F6TK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Mon Apr 9 09:41:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0262C21F8581 for ; Mon, 9 Apr 2012 09:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMzzSLCW8EXC for ; Mon, 9 Apr 2012 09:41:56 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFDF21F8575 for ; Mon, 9 Apr 2012 09:41:55 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2133284yhk.31 for ; Mon, 09 Apr 2012 09:41:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=86UnOt++Gb1qI2rPr4udkHzwEkvlx8+oQVuF7GG+aQA=; b=Lb6Xo14bKVFdCy6m3mh6BMncXssayQk5c8+MuQPcxlC1JJQQxuFhOLpGKNcje3stcP Jat/LT9br08S7eTNMymXCnGjHLZYPfD2czysv00P3r0v0hWJ1ejhPbm9RDNwjkqdTiFy 02Fvfefo7hUxcssJsYe2j7uMnMsKl8FSwRkm8jhsR9rHtcgHkVI4tkcaTP59jHxfb00i 5WVR9UKaSr9WOaYtnmFEoQJQeFrPriIYogNgK6iVGJ5vS61mpBU9Fady7Kw6Y6CKV4li 76ZwSJJUR40pI6SXz50fjzEIDbxGWLOVfBfNiU1EQ4/11+HjOeSqQySeItOKGXTyeINO 9hQw== Received: by 10.236.82.134 with SMTP id o6mr6783233yhe.51.1333989715449; Mon, 09 Apr 2012 09:41:55 -0700 (PDT) Received: from [192.168.1.213] (190-20-49-231.baf.movistar.cl. [190.20.49.231]) by mx.google.com with ESMTPS id g49sm67706755yhk.20.2012.04.09.09.41.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Apr 2012 09:41:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_BD689EC4-10CE-4175-A7E2-A3B64C8A0E2A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436645F6F6@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 9 Apr 2012 13:41:20 -0300 Message-Id: <0A1F4C01-6F1C-409A-ABCC-A0F09729B45B@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436645F6F6@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlneBCKIvR2o8drWPa5Rnvfl/wGsdMdr9EqRPgeMcbS45LfWVwFpimANDrrEEHQ97N0i86q Cc: "jose@ietf.org" Subject: Re: [jose] Open Issue for WG Discussion: Disposition of JSON Serialization Functionality X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:41:57 -0000 --Apple-Mail=_BD689EC4-10CE-4175-A7E2-A3B64C8A0E2A Content-Type: multipart/alternative; boundary="Apple-Mail=_089C1EE1-DD5C-4E9D-9214-F152DFB83994" --Apple-Mail=_089C1EE1-DD5C-4E9D-9214-F152DFB83994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline On 2012-04-09, at 1:25 PM, Mike Jones wrote: > You=92ll recall that I created JSON Serialization drafts in response = to WG input that use the same cryptographic operations as JWS and JWE, = but that serialize the results into a JSON objects, rather than = base64url encoded values separated by periods. These representations = also enable multiple signatures/HMACs to be used and content to be = encrypted to multiple recipients. The current versions of these drafts = are: > =B7 = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 > =B7 = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 > =20 > It was decided in Paris that the disposition of this functionality = should be discussed by the WG on the list. I think the questions we = need to decide are: > =20 > 1. Is the working group interested in pursuing this functionality? = (Evidence to date is that the answer to this question is =93yes=94.) > =20 Yes > 2. If the answer to (1) is =93yes=94, would the working group like to = have this functionality be in working group documents at this time = (rather than being described in individual submissions, as at present)? Yes > =20 > 3. If the answer to (2) is =93yes=94, should working group -00 = versions of the JSON Serialization documents be created or should this = functionality be folded into the existing JWS and JWE specs? > =20 Create WG documents separate from the JWS and JWE and consider merging = them later after some more maturity. John B. > Arguments for keeping this functionality separate for now are: > - Different level of maturity: I=92m aware of over a dozen = implementations of JWS a few of JWE, but I know of no implementations of = JWS-JS or JWE-JS. There=92s an argument that we should keep this new = functionality separate until we have =93rough consensus and running = code=94. > - Document simplicity for the Compact Serialization use case. Not = describing a second serialization in the JWS and JWE documents makes the = documents somewhat easier to read if all the implementer needs is the = Compact Serialization. > =20 > Arguments for merging it in now are: > - Fewer documents needed to provide comprehensive treatment of the = material. > =20 > Opinions from the Working Group? > =20 > Thanks, > -- Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_089C1EE1-DD5C-4E9D-9214-F152DFB83994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Inline
On 2012-04-09, at 1:25 PM, Mike = Jones wrote:

You=92ll recall that I created = JSON Serialization drafts in response to WG input that use the same = cryptographic operations as JWS and JWE, but that serialize the results = into a JSON objects, rather than base64url encoded values separated by = periods.  These representations also enable multiple = signatures/HMACs to be used and content to be encrypted to multiple = recipients.  The current versions of these drafts = are:
=B7 =B7  
Yes
2.  If the answer to (1) = is =93yes=94, would the working group like to have this functionality be = in working group documents at this time (rather than being described in = individual submissions, as at = present)?

Yes
 
3.  If the answer to (2) = is =93yes=94, should working group -00 versions of the JSON = Serialization documents be created or should this functionality be = folded into the existing JWS and JWE specs?
 

Cr= eate WG documents separate from the  JWS and JWE and consider = merging them later after some more = maturity.

John B.
Arguments for keeping this = functionality separate for now are:
  - Different level of maturity:  I=92m aware of = over a dozen implementations of JWS a few of JWE, but I know of no = implementations of JWS-JS or JWE-JS.  There=92s an argument that we = should keep this new functionality separate until we have =93rough = consensus and running code=94.
  - Document = simplicity for the Compact Serialization use case.  Not describing = a second serialization in the JWS and JWE documents makes the documents = somewhat easier to read if all the implementer needs is the Compact = Serialization.
 
Arguments for merging it in now are:
  - Fewer documents needed to provide comprehensive = treatment of the material.
Opinions from the Working = Group?
 
Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Apr 2012 21:17:42 -0400 References: <20120410011554.8603.20808.idtracker@ietfa.amsl.com> To: jose@ietf.org Message-Id: <8148046D-E3AE-4646-977E-6C6C887C2CCC@bbn.com> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-use-cases-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:17:11 -0000 Dear WG, Here's a first version of the proposed use cases document. Comments = welcome! --Richard Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-barnes-jose-use-cases-00.txt > Date: April 9, 2012 9:15:54 PM EDT > To: rbarnes@bbn.com >=20 > A new version of I-D, draft-barnes-jose-use-cases-00.txt has been = successfully submitted by Richard Barnes and posted to the IETF = repository. >=20 > Filename: draft-barnes-jose-use-cases > Revision: 00 > Title: Use Cases and Requirements for JSON Object = Signing and Encryption (JOSE) > Creation date: 2012-04-06 > WG ID: Individual Submission > Number of pages: 13 >=20 > Abstract: > Many Internet applications have a need for object-based security > mechanisms in addition to security mechanisms at the network layer = or > transport layer. In the past, the Cryptographic Message Syntax has > provided a binary secure object format based on ASN.1. Over time, > the use of binary object encodings such as ASN.1 has been overtaken > by text-based encodings, for example JavaScript Object Notation. > This document defines a set of use cases and requirements for a > secure object format encoded using JavaScript Object Notation, drawn > from a variety of application security mechanisms currently in > development. >=20 >=20 >=20 >=20 > The IETF Secretariat From vladimir@nimbusds.com Mon Apr 9 22:56:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF5C21F84F8 for ; Mon, 9 Apr 2012 22:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehRKjJ6BpxBA for ; Mon, 9 Apr 2012 22:56:46 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id DBA5B21F84F5 for ; Mon, 9 Apr 2012 22:56:45 -0700 (PDT) Received: (qmail 3724 invoked from network); 10 Apr 2012 05:56:44 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 10 Apr 2012 05:56:39 -0000 Received: (qmail 3446 invoked by uid 99); 10 Apr 2012 05:56:39 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 95.43.57.246 User-Agent: Workspace Webmail 5.6.15 Message-Id: <20120409225638.cc40c4f3d92d2001859047cd8cabb9ab.4c1ea7ac92.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Mike Jones" , "John Bradley" , "Jim Schaad" Date: Mon, 09 Apr 2012 22:56:38 -0700 Mime-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:56:47 -0000 Hi Mike, hi guys,=0A=0A+1 for moving the algorithm definitions to the JWA s= pec.=0A=0AMy reasoning goes as follows:=0A=0A1. The JWK spec is about prese= ntation and format (JSON), =0A JWA is about the algorithms.=0A=0A2. The a= lgorithms is perhaps the most likely thing to change=0A in future (say 5 = or 10 years) and if that happens ideally=0A only the JWA spec would have = to be updated.=0A=0A=0ANon-normative examples in the JWK is indeed an effec= tive way to=0Aillustrate the spec without entangling it with algorithm=0Aim= plementations. =0A=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusD= S.com : vladimir@nimbusds.com=0A=0A=0A=0A=0A-------- Original Message -----= ---=0ASubject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK= =0Aalgorithm family definitions to JWA spec (editorial)=0AFrom: Mike Jones = =0ADate: Mon, April 09, 2012 4:46 pm=0ATo: Joh= n Bradley , Jim Schaad=0A=0ACc: = "jose@ietf.org" =0A=0A The readability would be somewhat re= duced by having to refer to the=0Asecond document. That being said, I beli= eve this could be mitigated by=0Athe use of examples. Since opinion (of th= e two participants in the=0Adiscussion to date) seems to favor moving the a= lgorithm family=0Adefinitions to JWA, I=E2=80=99ll plan on doing that unles= s others speak up=0Ataking the counter position.=0A =0A = -- Mike=0A =0A From: John Brad= ley [mailto:ve7jtb@ve7jtb.com] =0A Sent: Saturday, April 07, 2012 7:46 AM= =0A To: Jim Schaad=0A Cc: Mike Jones; jose@ietf.org=0A Subject: Re: [jose] = Open Issue for WG Discussion: Whether to move JWK=0Aalgorithm family defini= tions to JWA spec (editorial)=0A =0A=0A =0A It is mostly a style question I= think.=0A =0A =0AGiven that the elements can be directly embedded in JWE= , as well as=0Abeing represented externally in a JWK, I think JWA is prob= ably the=0Acorrect place for them as it makes it easier to add new crypto a= lgs.=0A =0A =0A =0AThe solution for JWK is good examples I think.=0A =0A = =0A =0AI suppose the downside is an extra level of indirection through the= =0Aspecs for developers.=0A =0A =0A =0AI don't feel strongly one way or the= other, just have a slight=0Apreference for JWA. (My track record on docume= nt structure is slightly=0Asuspect though)=0A =0A =0A =0AJohn B.=0A =0AOn 2= 012-04-07, at 11:25 AM, Jim Schaad wrote:=0A =0A=0A =0A =0A Please explai= n why you believe the readability of the document would=0Abe reduced. Ther= e would still be the ability to have examples that=0Areferenced the algorit= hm draft.=0A =0A =0A =0AJim=0A =0A =0A =0A =0A =0AFrom: jose-bounces@ietf.o= rg [mailto:jose-bounces@ietf.org] On Behalf Of=0AMike Jones=0A Sent: Friday= , April 06, 2012 2:05 PM=0A To: jose@ietf.org=0A Subject: [jose] Open Issue= for WG Discussion: Whether to move JWK=0Aalgorithm family definitions to J= WA spec (editorial)=0A =0A=0A=0A =0A =0AThe JSON Web Key (JWK) spec current= ly contains the algorithm family=0Adefinitions and parameter specifications= for the RSA and Elliptic Curve=0Aalgorithm families. An editorial open is= sue is whether to leave these=0Ain the JWK spec or move them to the JWA spe= c.=0A =0A =0A =0AThe argument for leaving them in the JWK spec is that remo= ving the=0Adefinitions of =E2=80=9CEC=E2=80=9D and =E2=80=9CRSA=E2=80=9D an= d the family-specific parameter=0Adefinitions ("crv", "x", "y", "mod", "exp= ") would leave very little=0Anormative text in the JWK spec itself. It see= med like doing this would=0Areduce the readability of the JWK spec, and so = was not done in -01.=0A =0A =0A =0AThe argument for moving them is that all= the algorithm-specific=0Adefinitions would then be in the JWA spec and goo= d examples of RSA and=0AEC keys could remain in the JWK spec.=0A =0A =0A = =0AReferences to the pertinent specs are:=0A =0Ahttp://tools.ietf.org/html/= draft-ietf-jose-json-web-key-01=0A =0Ahttp://tools.ietf.org/html/draft-ietf= -jose-json-web-algorithms-01=0A =0A =0A =0AFeedback?=0A =0A =0A =0A = -- Mike=0A =0A =0A = =0A=0A_______________________________________________=0A jose mailing list= =0A jose@ietf.org=0A https://www.ietf.org/mailman/listinfo/jose=0A =0A=0A = =0A =0A=0A_______________________________________________=0Ajose mailing li= st=0Ajose@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/jose=0A From rbarnes@bbn.com Tue Apr 10 06:13:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA5921F862B for ; Tue, 10 Apr 2012 06:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oMmRvn+u6ix for ; Tue, 10 Apr 2012 06:13:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A1ACC21F8604 for ; Tue, 10 Apr 2012 06:13:24 -0700 (PDT) Received: from [128.89.253.10] (port=55029) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHasd-000Fx9-3w for jose@ietf.org; Tue, 10 Apr 2012 09:13:07 -0400 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 09:13:58 -0400 Message-Id: <527EC464-7A5E-4165-BEE6-7FFD6AA301D3@bbn.com> To: jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [jose] JW* length constraints? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:13:25 -0000 Hey all, One of the requirements noted in the use cases document is that in some = cases, JOSE objects will need to be encoded for transmission in URIs, so = they need to be short. This requirement, as I recall, was based on the = idea that JOSE would be used to construct tokens for use in OAuth.=20 However, I just read through the OAuth spec, and there doesn't seem to = be any point where tokens are passed in URIs. (NB: At least *access* = tokens, which is what I understood to be the problem.) When they're = issued to the client, they're passed in an HTTP entity body, and when = they're used by the client, they're passed in an Authorization header. So is there really a length constraint here? --Richard= From stpeter@stpeter.im Tue Apr 10 08:07:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84D311E80FA for ; Tue, 10 Apr 2012 08:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd9gSB7q5AH1 for ; Tue, 10 Apr 2012 08:07:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 130AC11E80F4 for ; Tue, 10 Apr 2012 08:07:04 -0700 (PDT) Received: from dhcp-64-101-72-216.cisco.com (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 505B140058 for ; Tue, 10 Apr 2012 09:20:51 -0600 (MDT) Message-ID: <4F84471A.6050401@stpeter.im> Date: Tue, 10 Apr 2012 08:43:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "jose@ietf.org" References: <4F8356FE.7040208@w3.org> In-Reply-To: <4F8356FE.7040208@w3.org> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <4F8356FE.7040208@w3.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [jose] Fwd: W3C launches Web Cryptography Working Group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:07:04 -0000 FYI -------- Original Message -------- Subject: W3C launches Web Cryptography Working Group Resent-Date: Mon, 09 Apr 2012 21:38:16 +0000 Resent-From: public-identity@w3.org Date: Mon, 09 Apr 2012 23:39:10 +0200 From: Harry Halpin To: public-identity@w3.org Everyone - thanks for all the feedback and work since the Workshop, we're finally launching: W3C launched today a new Web Cryptography Working Group, whose mission is to define an API that lets developers implement secure application protocols on the level of Web applications, including message confidentiality and authentication services, by exposing trusted cryptographic primitives from the browser. Web application developers will no longer have to create their own or use untrusted third-party libraries for cryptographic primitives. This will improve security on the Web. Some of the chartered use cases for this API include: http://www.w3.org/2012/webcrypto/ http://www.w3.org/2011/11/webcryptography-charter * The ability to select credentials and sign statements can be necessary to perform high-value transactions such as those involved in finance, corporate security, and identity-related claims about personal data. * The provisioning and use of keys within Web applications can be used for scenarios such as increasing the security of user authentication and determining whether a particular device is authenticated for particular services. * The ability to check source integrity before executing Javascript code previously stored in local storage. Learn more about the Security Activity. http://www.w3.org/Security/Activity From bcampbell@pingidentity.com Tue Apr 10 08:17:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7311E80DE for ; Tue, 10 Apr 2012 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJbmfnUPFGMf for ; Tue, 10 Apr 2012 08:17:47 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3A53711E80D9 for ; Tue, 10 Apr 2012 08:17:47 -0700 (PDT) Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKT4RPGk0Uq6YKPEFvrVFVbFb5Jg3Y6YFO@postini.com; Tue, 10 Apr 2012 08:17:47 PDT Received: by vcbf11 with SMTP id f11so2588234vcb.10 for ; Tue, 10 Apr 2012 08:17:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=0EOG++GaW31DTeeesH3L0rmSiDbiAu3PiVFYRb/eVkU=; b=fJ5MLHyt2zhpkCHmNskuptpI6eHPJe6W5EQ0ypDG8+6FJHiC/P//4DqXmJbYUzD+iU huF81cOZbXQSmYIzC+7Wgc9swlcH8zNwEdAKkzK6UdnwxEch9qHt/oHDDSXJY1mHH8UC 20jQwBL1fCrlcgc0FMHzp0FWOUZKQc1g4m/m9qPKqNtEkvYY378a+cwvme0syM77FuB5 7z3YmPgCax69PHwAjaCLhnDk1/8fVT5WJ0F5LC5r1wXdoGGS8JEBvZgVRzsZrQWRTtmO 6ODxMOgtbLNhowRisSPMEFbNOhb4MKoh+BocStShTqh5N6QWHOYi55w6FgYCB3vlw4As uTBA== Received: by 10.52.95.238 with SMTP id dn14mr4807013vdb.14.1334071065898; Tue, 10 Apr 2012 08:17:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Tue, 10 Apr 2012 08:17:15 -0700 (PDT) In-Reply-To: <527EC464-7A5E-4165-BEE6-7FFD6AA301D3@bbn.com> References: <527EC464-7A5E-4165-BEE6-7FFD6AA301D3@bbn.com> From: Brian Campbell Date: Tue, 10 Apr 2012 09:17:15 -0600 Message-ID: To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=20cf307cff94fcf08c04bd549fdf X-Gm-Message-State: ALoCoQkVB/2ojA55ErB9HN+bAcpMrvnmPG3zhp4JFTlPQgIcXTraYLwddWaUHZ4ER+OWPY/pXPTr Cc: jose@ietf.org Subject: Re: [jose] JW* length constraints? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:17:48 -0000 --20cf307cff94fcf08c04bd549fdf Content-Type: text/plain; charset=ISO-8859-1 In practice there are often limitations on the size of HTTP headers so length is still a consideration in that respect. There are a couple different flows in OAuth and access tokens can be passed in URIs when using the so called implicit grant - see the example in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.2.2 where the access token is passes in the fragment OpenID Connect, which builds on OAuth, also has some constructs similar to the implicit grant where tokens (access and another type called the id token which is a JW*) are passed in the fragment of the URI. So I do think the length constraints are still valid. On Tue, Apr 10, 2012 at 7:13 AM, Richard L. Barnes wrote: > Hey all, > > One of the requirements noted in the use cases document is that in some > cases, JOSE objects will need to be encoded for transmission in URIs, so > they need to be short. This requirement, as I recall, was based on the > idea that JOSE would be used to construct tokens for use in OAuth. > > However, I just read through the OAuth spec, and there doesn't seem to be > any point where tokens are passed in URIs. (NB: At least *access* tokens, > which is what I understood to be the problem.) When they're issued to the > client, they're passed in an HTTP entity body, and when they're used by the > client, they're passed in an Authorization header. > > So is there really a length constraint here? > > --Richard > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --20cf307cff94fcf08c04bd549fdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In practice there are often limitations on the size of HTTP headers so leng= th is still a consideration in that respect.

There are a couple dif= ferent flows in OAuth and access tokens can be passed in URIs when using th= e so called implicit grant - see the example in http://tools.ietf.org/html= /draft-ietf-oauth-v2-25#section-4.2.2 where the access token is passes = in the fragment

OpenID Connect, which builds on OAuth, also has some constructs similar= to the implicit grant where tokens (access and another type called the id = token which is a JW*) are passed in the fragment of the URI.

So I do= think the length constraints are still valid.

On Tue, Apr 10, 2012 at 7:13 AM, Richard L. = Barnes <rbarnes@bbn= .com> wrote:
Hey all,

One of the requirements noted in the use cases document is that in some cas= es, JOSE objects will need to be encoded for transmission in URIs, so they = need to be short. =A0This requirement, as I recall, was based on the idea t= hat JOSE would be used to construct tokens for use in OAuth.

However, I just read through the OAuth spec, and there doesn't seem to = be any point where tokens are passed in URIs. =A0(NB: At least *access* tok= ens, which is what I understood to be the problem.) =A0When they're iss= ued to the client, they're passed in an HTTP entity body, and when they= 're used by the client, they're passed in an Authorization header.<= br>
So is there really a length constraint here?

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

--20cf307cff94fcf08c04bd549fdf-- From Michael.Jones@microsoft.com Tue Apr 10 08:23:45 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A5B11E80EA for ; Tue, 10 Apr 2012 08:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.77 X-Spam-Level: X-Spam-Status: No, score=-3.77 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKXr5vhrpHDr for ; Tue, 10 Apr 2012 08:23:44 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8845B11E80CD for ; Tue, 10 Apr 2012 08:23:44 -0700 (PDT) Received: from mail166-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 15:23:43 +0000 Received: from mail166-ch1 (localhost [127.0.0.1]) by mail166-ch1-R.bigfish.com (Postfix) with ESMTP id 849B936028D; Tue, 10 Apr 2012 15:23:43 +0000 (UTC) X-SpamScore: -25 X-BigFish: VS-25(zz9371Ic85fh98dK14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail166-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail166-ch1 (localhost.localdomain [127.0.0.1]) by mail166-ch1 (MessageSwitch) id 1334071422221491_12258; Tue, 10 Apr 2012 15:23:42 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail166-ch1.bigfish.com (Postfix) with ESMTP id 2819A2601AB; Tue, 10 Apr 2012 15:23:42 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 15:23:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0283.004; Tue, 10 Apr 2012 15:23:38 +0000 From: Mike Jones To: Brian Campbell , "Richard L. Barnes" Thread-Topic: [jose] JW* length constraints? Thread-Index: AQHNFxu6VEVgq7NijkaNkjbRe9LGvpaUK82AgAAAYLA= Date: Tue, 10 Apr 2012 15:23:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664610CF@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <527EC464-7A5E-4165-BEE6-7FFD6AA301D3@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664610CFTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] JW* length constraints? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:23:45 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664610CFTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And sometimes tokens are passed as query parameters, per Section 3 of http:= //developers.facebook.com/docs/authentication/canvas/ and per http://tools.= ietf.org/html/draft-ietf-oauth-v2-bearer-18#section-2.3. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bri= an Campbell Sent: Tuesday, April 10, 2012 8:17 AM To: Richard L. Barnes Cc: jose@ietf.org Subject: Re: [jose] JW* length constraints? In practice there are often limitations on the size of HTTP headers so leng= th is still a consideration in that respect. There are a couple different flows in OAuth and access tokens can be passed= in URIs when using the so called implicit grant - see the example in http:= //tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.2.2 where the access= token is passes in the fragment OpenID Connect, which builds on OAuth, also has some constructs similar to = the implicit grant where tokens (access and another type called the id toke= n which is a JW*) are passed in the fragment of the URI. So I do think the length constraints are still valid. On Tue, Apr 10, 2012 at 7:13 AM, Richard L. Barnes > wrote: Hey all, One of the requirements noted in the use cases document is that in some cas= es, JOSE objects will need to be encoded for transmission in URIs, so they = need to be short. This requirement, as I recall, was based on the idea tha= t JOSE would be used to construct tokens for use in OAuth. However, I just read through the OAuth spec, and there doesn't seem to be a= ny point where tokens are passed in URIs. (NB: At least *access* tokens, w= hich is what I understood to be the problem.) When they're issued to the c= lient, they're passed in an HTTP entity body, and when they're used by the = client, they're passed in an Authorization header. So is there really a length constraint here? --Richard _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943664610CFTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And sometimes tokens are = passed as query parameters, per Section 3 of http= ://developers.facebook.com/docs/authentication/canvas/ and per http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-18#section-2.3<= /a>.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, April 10, 2012 8:17 AM
To: Richard L. Barnes
Cc: jose@ietf.org
Subject: Re: [jose] JW* length constraints?

 

In practice there are= often limitations on the size of HTTP headers so length is still a conside= ration in that respect.

There are a couple different flows in OAuth and access tokens can be passed= in URIs when using the so called implicit grant - see the example in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.2.2 where = the access token is passes in the fragment

OpenID Connect, which builds on OAuth, also has some constructs similar to = the implicit grant where tokens (access and another type called the id toke= n which is a JW*) are passed in the fragment of the URI.

So I do think the length constraints are still valid.

On Tue, Apr 10, 2012 at 7:13 AM, Richard L. Barnes &= lt;rbarnes@bbn.com> wrote:

Hey all,

One of the requirements noted in the use cases document is that in some cas= es, JOSE objects will need to be encoded for transmission in URIs, so they = need to be short.  This requirement, as I recall, was based on the ide= a that JOSE would be used to construct tokens for use in OAuth.

However, I just read through the OAuth spec, and there doesn't seem to be a= ny point where tokens are passed in URIs.  (NB: At least *access* toke= ns, which is what I understood to be the problem.)  When they're issue= d to the client, they're passed in an HTTP entity body, and when they're used by the client, they're passed in an Aut= horization header.

So is there really a length constraint here?

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943664610CFTK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Tue Apr 10 08:33:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECF011E80FC for ; Tue, 10 Apr 2012 08:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3oFOIsFV+hL for ; Tue, 10 Apr 2012 08:33:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74F6F11E80D9 for ; Tue, 10 Apr 2012 08:33:08 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2694887ghb.31 for ; Tue, 10 Apr 2012 08:33:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=KVyXahDEa5MGw36QWcdRaqbElDlde8RWEv3rcBZLjNE=; b=flah+Rgw1YvceCjLV/inET9CYXGyU8WLpJ2EbSxDFWqlVyj5R/1K2yvVe32FBCc3R1 Kgahdfdj+/dXKTWYJZzn/Ek16XuxydYXbX5w4zGsNwY6zK7PKPNHLw3dIyzPdkoJ49R4 E/4MpEzhdjV1D/VtpmmugjA0GhnBAs6W1hjECLMjIKMqyYH6UCG37td8I/Qf3cUYaGNc 9+u2NNLjBji4fKnbuaqNFkbVTOW2zP5cemQ7IBRFWPDmmPw/Q/AlRxBszLQ5l9Dw/qKC BqXuGZH+M/9QWAxBsw2ntA0fLzYZAynsW390adYo/c1u9Wdkh+KVT0RvigAQSIExobXa 5CJQ== Received: by 10.101.180.1 with SMTP id h1mr3055024anp.71.1334071985158; Tue, 10 Apr 2012 08:33:05 -0700 (PDT) Received: from [192.168.1.213] (190-20-7-64.baf.movistar.cl. [190.20.7.64]) by mx.google.com with ESMTPS id j24sm32544894ann.18.2012.04.10.08.33.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 08:33:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_3E3F9492-CDC7-4425-85FF-CB1918563666"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <527EC464-7A5E-4165-BEE6-7FFD6AA301D3@bbn.com> Date: Tue, 10 Apr 2012 12:32:55 -0300 Message-Id: <64F0EF52-EBC9-4FB8-95D7-57B85488FB2D@ve7jtb.com> References: <527EC464-7A5E-4165-BEE6-7FFD6AA301D3@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlRIZ5UBDdlM0aZu7vDM79l4OZUjr0xX/zbwAfxKjfoi8CRty12Hb9/TOzK7Kd3ze+9OBPk Cc: jose@ietf.org Subject: Re: [jose] JW* length constraints? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:33:09 -0000 --Apple-Mail=_3E3F9492-CDC7-4425-85FF-CB1918563666 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the implicit flow they are passed in the URI fragment from the = Authorization server to the client. Agreed mostly they are passed to RS as headers. Though there also = limits to header size in many environments. John B. On 2012-04-10, at 10:13 AM, Richard L. Barnes wrote: > Hey all, >=20 > One of the requirements noted in the use cases document is that in = some cases, JOSE objects will need to be encoded for transmission in = URIs, so they need to be short. This requirement, as I recall, was = based on the idea that JOSE would be used to construct tokens for use in = OAuth.=20 >=20 > However, I just read through the OAuth spec, and there doesn't seem to = be any point where tokens are passed in URIs. (NB: At least *access* = tokens, which is what I understood to be the problem.) When they're = issued to the client, they're passed in an HTTP entity body, and when = they're used by the client, they're passed in an Authorization header. >=20 > So is there really a length constraint here? >=20 > --Richard > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_3E3F9492-CDC7-4425-85FF-CB1918563666 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx MDE1MzI1NlowIwYJKoZIhvcNAQkEMRYEFDGECeUyc0PuWFR7oanFTTl4Mr/TMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AB4za8OOoZzmaaLxE8d6FNmMagaN0fGp8ofKDCur87ah0yQF11cnF2wG5atDdqNc9IEyeD6MWaac P7chtD94+SjVejLQUURdwtu3eFmkPxr7g+AMZQhdSctfComrCUHDXtRgFc2YVXlBMp6Ktl14SmIq FHXmnK/u0+R7fzJMyNggY9KEAmsVpm0sJrWLu8m0HufnoP5P+P2XbVFYQiLUS9yOF6b9kt0tK+zX Ax47gBNowjEwZSlapX1CsIh0g6pEMXLkVZCL5DjQ+5/9oaX0dIM/C3ik+yrZvWf1itXUI0iwHx1j PtwukKXUSbP7uab+D7mFOaEmQF5VqiHlz5tdScAAAAAAAAA= --Apple-Mail=_3E3F9492-CDC7-4425-85FF-CB1918563666-- From rbarnes@bbn.com Tue Apr 10 14:54:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672ED11E80D2 for ; Tue, 10 Apr 2012 14:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG4exZhdg21j for ; Tue, 10 Apr 2012 14:54:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D802511E80B5 for ; Tue, 10 Apr 2012 14:54:54 -0700 (PDT) Received: from [128.89.255.242] (port=55872) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHj1I-0006hp-IF; Tue, 10 Apr 2012 17:54:36 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <64F0EF52-EBC9-4FB8-95D7-57B85488FB2D@ve7jtb.com> Date: Tue, 10 Apr 2012 17:55:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <527EC464-7A5E-4165-BEE6-7FFD6AA301D3@bbn.com> <64F0EF52-EBC9-4FB8-95D7-57B85488FB2D@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1257) Cc: jose@ietf.org Subject: Re: [jose] JW* length constraints? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:54:55 -0000 Thanks all. Understand better now. --Richard On Apr 10, 2012, at 11:32 AM, John Bradley wrote: > In the implicit flow they are passed in the URI fragment from the = Authorization server to the client. >=20 > Agreed mostly they are passed to RS as headers. Though there also = limits to header size in many environments. >=20 > John B. > On 2012-04-10, at 10:13 AM, Richard L. Barnes wrote: >=20 >> Hey all, >>=20 >> One of the requirements noted in the use cases document is that in = some cases, JOSE objects will need to be encoded for transmission in = URIs, so they need to be short. This requirement, as I recall, was = based on the idea that JOSE would be used to construct tokens for use in = OAuth.=20 >>=20 >> However, I just read through the OAuth spec, and there doesn't seem = to be any point where tokens are passed in URIs. (NB: At least *access* = tokens, which is what I understood to be the problem.) When they're = issued to the client, they're passed in an HTTP entity body, and when = they're used by the client, they're passed in an Authorization header. >>=20 >> So is there really a length constraint here? >>=20 >> --Richard >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From bcampbell@pingidentity.com Tue Apr 10 16:06:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444BB11E8081 for ; Tue, 10 Apr 2012 16:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvKilyOI2dF6 for ; Tue, 10 Apr 2012 16:06:22 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9A11E21F85A8 for ; Tue, 10 Apr 2012 16:06:21 -0700 (PDT) Received: from mail-vb0-f54.google.com ([209.85.212.54]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKT4S87JLzo3rG4SNC/+49FQbx68r2GoMu@postini.com; Tue, 10 Apr 2012 16:06:21 PDT Received: by vbmv11 with SMTP id v11so333815vbm.13 for ; Tue, 10 Apr 2012 16:06:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=OvvmyxkHZWdpAjGFAytD2xS2FyemEt3K7Ohb+E+IH3I=; b=j9uio9xxwMvjT0rDtCHIyHoOGK4UylwNgkpjnpfDfsHJtV64qPy/sqnK5WPhGm+Czz G7jSXG3ekUS3ZTlnE2be5mOqD7hatdc8c/IWp5RxJhm1iDNpw11Lc8bBE5AbgCXQiuCD EYVwUhHjjuXB3JR4cuxJo9hZF0WkWq+9dMSJ88v+MW/QRhlxPcNhUoVmgdBrKep0rTbY Du7fTDAtVSXlEsSsIuV7nMq2yfxjiGnncrZ6JyrwBhjMZMGO1/dVQwCqmInfuDQrnF8N UnJ+9Ss3Yl/0kW6/41QPnIK804+3F3oYNf1FjRKkq8QCGGYrTQJ9HvZwtuYSjUUisBXV jbfA== Received: by 10.220.116.7 with SMTP id k7mr6738110vcq.13.1334099179319; Tue, 10 Apr 2012 16:06:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Tue, 10 Apr 2012 16:05:49 -0700 (PDT) In-Reply-To: <066101cd1372$b3c60130$1b520390$@augustcellars.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <066101cd1372$b3c60130$1b520390$@augustcellars.com> From: Brian Campbell Date: Tue, 10 Apr 2012 17:05:49 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=f46d0438942badb32f04bd5b2ba9 X-Gm-Message-State: ALoCoQkwA0cDb5zxXzIrFoIoQXwFOcn1y2Ip2jXrdgnV63G4ON8t4Y6SSPFhhxaPiSxrKtxL7oUE Cc: John Bradley , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:06:23 -0000 --f46d0438942badb32f04bd5b2ba9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's a good point that I hadn't considered. But it leads me to another question. What key size(s) should be used for generated the Content Integrity Key? I ask because HMAC can take keys of arbitrary length. I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message Authentication"* and it seems to suggest that an optimal key length would be equal to the hash output length. But for the sake of interoperability, it seems like JWE/JWA should be very specific about key lengths for derived keys for each integrity algorithm (if this is already in the, I couldn't find it, so please excuse me and point me to the text). * =A73 of http://tools.ietf.org/html/rfc2104 On Thu, Apr 5, 2012 at 3:26 PM, Jim Schaad wrote: > Another reason is that the algorithms may use two different key sizes and > thus you need to deal with the expansion/truncation questions. > > jim > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > John Bradley > > Sent: Wednesday, April 04, 2012 4:42 PM > > To: Brian Campbell > > Cc: jose@ietf.org > > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > > > The use of a single key across two functions is one of things that is n= ot > > provably without problems. > > > > I agree that from an implementers point of view one key is simpler. > > > > There is a related-key attack that using the same key would enable. Th= is > can > > be combined with differential and linear attacks on symmetric key > cyphers. > > > > Generally this can be thought of as a bad thing. > > > > What is certain is that it increases the possible attack surface, and = if > the is a > > problem discovered as we have seen with AES-CBC it is going to be hard = to > > change later. > > > > We need key derivation anyway for ECDH-ES to produce a key of the corre= ct > > bit length. > > > > Doing key derivation on CMK is the theoretically proper way to do it. > > Making a simplification might bite us in the future. > > > > I suppose one way to get around the conditional application argument is > to > > always use it to produce the CEK even with AEAD algorithms. > > > > Regards > > John B. > > > > On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > > > > > Hi all, > > > > > > I was hoping someone could help me (hopefully it's not just me!) > > > understand the reasons for the introduction of the key derivation > > > stuff* into JWE draft -01? > > > > > > I understand that it's there to derive the two keys, CEK and CIK, fro= m > > > the CMK and that it is to be done when a non-AEAD algorithm is used t= o > > > encrypt the content. But what is the value of deriving the two keys a= s > > > apposed to using the CMK for both encryption and integrity? > > > > > > Perhaps naively I assumed that using the CMK for both would be > > > sufficient. It's randomly generated and used only for the one JWE. > > > It's not clear to me what benefit is provided by the additional > > > complexity of the derivation function as well as its conditional > > > application (and the potential interoperability problems that come > > > with such complexity). I assume there's some security benefit? But I > > > can't see what it is. > > > > > > Any help would be appreciated. > > > Thanks, > > > Brian > > > > > > * > > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sec= t > > > ion-7 > > > which is referenced by > > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sec= t > > > ion-5 and > > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sec= t > > > ion-6 _______________________________________________ > > > jose mailing list > > > jose@ietf.org > > > https://www.ietf.org/mailman/listinfo/jose > > > --f46d0438942badb32f04bd5b2ba9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's a good point that I hadn't considered. But it leads me to an= other question. What key size(s) should be used for generated the Content I= ntegrity Key? I ask because HMAC can take keys of arbitrary length.

I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message = Authentication"* and it seems to suggest that an optimal key length wo= uld be equal to the hash output length. But for the sake of interoperabilit= y, it seems like JWE/JWA should be very specific about key lengths for deri= ved keys for each integrity algorithm (if this is already in the, I couldn&= #39;t find it, so please excuse me and point me to the text).=A0

* =A73 of http://tools.i= etf.org/html/rfc2104

On Thu, Apr 5, 2= 012 at 3:26 PM, Jim Schaad <ietf@augustcellars.com> wro= te:
Another reason is that the algorithms may us= e two different key sizes and
thus you need to deal with the expansion/truncation questions.

jim

> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> John Bradley
> Sent: Wednesday, April 04, 2012 4:42 PM
> To: Brian Campbell
> Cc: jose@ietf.org
> Subject: Re: [jose] Understanding the motivation for Key Derivation? >
> The use of a single key across two functions is one of= things that is not
> provably without problems.
>
> I agree that from an implementers point of view one key is simpler. >
> There is a related-key attack that using the same key would enable. = =A0This
can
> be combined with differential and linear attacks on symmetric key cyph= ers.
>
> Generally this can be thought of as a bad thing.
>
> What is certain is that it increases the possible attack surface, =A0a= nd if
the is a
> problem discovered as we have seen with AES-CBC it is going to be hard= to
> change later.
>
> We need key derivation anyway for ECDH-ES to produce a key of the corr= ect
> bit length.
>
> Doing key derivation on CMK is the theoretically proper way to do it.<= br> > Making a simplification might bite us in the future.
>
> I suppose one way to get around the conditional application argument i= s to
> always use it to produce the CEK even with AEAD algorithms.
>
> Regards
> John B.
>
> On 2012-04-04, at 7:40 PM, Brian Campbell wrote:
>
> > Hi all,
> >
> > I was hoping someone could help me (hopefully it's not just m= e!)
> > understand the reasons for the introduction of the key derivation=
> > stuff* into JWE draft -01?
> >
> > I understand that it's there to derive the two keys, CEK and = CIK, from
> > the CMK and that it is to be done when a non-AEAD algorithm is us= ed to
> > encrypt the content. But what is the value of deriving the two ke= ys as
> > apposed to using the CMK for both encryption and integrity?
> >
> > Perhaps naively I assumed that using the CMK for both would be > > sufficient. =A0It's randomly generated and used only for the = one JWE.
> > It's not clear to me what benefit is provided by the addition= al
> > complexity of the derivation function as well as its conditional<= br> > > application (and the potential interoperability problems that com= e
> > with such complexity). I assume there's some security benefit= ? But I
> > can't see what it is.
> >
> > Any help would be appreciated.
> > Thanks,
> > Brian
> >
> > *
> > http://tools.ietf.org/html/draft-ietf-j= ose-json-web-encryption-01#sect
> > ion-7
> > which is referenced by
> > http://tools.ietf.org/html/draft-ietf-j= ose-json-web-encryption-01#sect
> > ion-5 and
> > http://tools.ietf.org/html/draft-ietf-j= ose-json-web-encryption-01#sect
> > ion-6 _______________________________________________=

--f46d0438942badb32f04bd5b2ba9-- From Michael.Jones@microsoft.com Tue Apr 10 16:15:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2017A11E8081 for ; Tue, 10 Apr 2012 16:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veANRsRHLne7 for ; Tue, 10 Apr 2012 16:15:50 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3F46821F8598 for ; Tue, 10 Apr 2012 16:15:48 -0700 (PDT) Received: from mail48-db3-R.bigfish.com (10.3.81.252) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 23:15:47 +0000 Received: from mail48-db3 (localhost [127.0.0.1]) by mail48-db3-R.bigfish.com (Postfix) with ESMTP id 1B28860141; Tue, 10 Apr 2012 23:15:47 +0000 (UTC) X-SpamScore: -45 X-BigFish: VS-45(zz9371I936eK542Mc85dh1432N98dK4015I148cM14ffIzz1202hzz1033IL8275bh8275dhz2fh793h2a8h668h839hd25h34h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail48-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail48-db3 (localhost.localdomain [127.0.0.1]) by mail48-db3 (MessageSwitch) id 1334099745156728_24006; Tue, 10 Apr 2012 23:15:45 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.241]) by mail48-db3.bigfish.com (Postfix) with ESMTP id 1D121801F9; Tue, 10 Apr 2012 23:15:45 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 23:15:43 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0283.004; Tue, 10 Apr 2012 23:15:14 +0000 From: Mike Jones To: Brian Campbell , Jim Schaad Thread-Topic: [jose] Understanding the motivation for Key Derivation? Thread-Index: AQHNErQOZlMb1ahKqUiwv3kEv/baLJaLU7cAgAFsRoCAB/eKgIAAAfFQ Date: Tue, 10 Apr 2012 23:15:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664621C2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <066101cd1372$b3c60130$1b520390$@augustcellars.com> 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.78] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: John Bradley , "jose@ietf.org" Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:15:51 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric Rescorla recommended that key sizes equal to the hash output sizes be = used in his presentation in Paris (attached). Thanks for pointing out that the spec needs to nail this down! -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bri= an Campbell Sent: Tuesday, April 10, 2012 4:06 PM To: Jim Schaad Cc: John Bradley; jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? That's a good point that I hadn't considered. But it leads me to another qu= estion. What key size(s) should be used for generated the Content Integrity= Key? I ask because HMAC can take keys of arbitrary length. I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message Authentic= ation"* and it seems to suggest that an optimal key length would be equal t= o the hash output length. But for the sake of interoperability, it seems li= ke JWE/JWA should be very specific about key lengths for derived keys for e= ach integrity algorithm (if this is already in the, I couldn't find it, so = please excuse me and point me to the text). * =A73 of http://tools.ietf.org/html/rfc2104 On Thu, Apr 5, 2012 at 3:26 PM, Jim Schaad > wrote: Another reason is that the algorithms may use two different key sizes and thus you need to deal with the expansion/truncation questions. jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf Of > John Bradley > Sent: Wednesday, April 04, 2012 4:42 PM > To: Brian Campbell > Cc: jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > The use of a single key across two functions is one of things that is not > provably without problems. > > I agree that from an implementers point of view one key is simpler. > > There is a related-key attack that using the same key would enable. This can > be combined with differential and linear attacks on symmetric key cyphers= . > > Generally this can be thought of as a bad thing. > > What is certain is that it increases the possible attack surface, and if the is a > problem discovered as we have seen with AES-CBC it is going to be hard to > change later. > > We need key derivation anyway for ECDH-ES to produce a key of the correct > bit length. > > Doing key derivation on CMK is the theoretically proper way to do it. > Making a simplification might bite us in the future. > > I suppose one way to get around the conditional application argument is t= o > always use it to produce the CEK even with AEAD algorithms. > > Regards > John B. > > On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > > > Hi all, > > > > I was hoping someone could help me (hopefully it's not just me!) > > understand the reasons for the introduction of the key derivation > > stuff* into JWE draft -01? > > > > I understand that it's there to derive the two keys, CEK and CIK, from > > the CMK and that it is to be done when a non-AEAD algorithm is used to > > encrypt the content. But what is the value of deriving the two keys as > > apposed to using the CMK for both encryption and integrity? > > > > Perhaps naively I assumed that using the CMK for both would be > > sufficient. It's randomly generated and used only for the one JWE. > > It's not clear to me what benefit is provided by the additional > > complexity of the derivation function as well as its conditional > > application (and the potential interoperability problems that come > > with such complexity). I assume there's some security benefit? But I > > can't see what it is. > > > > Any help would be appreciated. > > Thanks, > > Brian > > > > * > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect > > ion-7 > > which is referenced by > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect > > ion-5 and > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect > > ion-6 _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Eric Rescorla recommended= that key sizes equal to the hash output sizes be used in his presentation = in Paris (attached).

 <= /p>

Thanks for pointing out t= hat the spec needs to nail this down!

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, April 10, 2012 4:06 PM
To: Jim Schaad
Cc: John Bradley; jose@ietf.org
Subject: Re: [jose] Understanding the motivation for Key Derivation?=

 

That's a good point t= hat I hadn't considered. But it leads me to another question. What key size= (s) should be used for generated the Content Integrity Key? I ask because H= MAC can take keys of arbitrary length.

I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message Auth= entication"* and it seems to suggest that an optimal key length would = be equal to the hash output length. But for the sake of interoperability, i= t seems like JWE/JWA should be very specific about key lengths for derived keys for each integrity algorithm (if this i= s already in the, I couldn't find it, so please excuse me and point me to t= he text). 

* =A73 of http://tools.ietf.= org/html/rfc2104

On Thu, Apr 5, 2012 at 3:26 PM, Jim Schaad <ietf@augustcellars.c= om> wrote:

Another reason is that the algorithms may use two di= fferent key sizes and
thus you need to deal with the expansion/truncation questions.


jim

> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> John Bradley

> Sent: Wednesday, April 04, 2012 4:42 PM
> To: Brian Campbell
> Cc: jose@ietf.org
> Subject: Re: [jose] Understanding the motivation for Key Derivation? >

> The use of a single key across two functions is= one of things that is not
> provably without problems.
>
> I agree that from an implementers point of view one key is simpler. >
> There is a related-key attack that using the same key would enable. &n= bsp;This
can
> be combined with differential and linear attacks on symmetric key cyph= ers.
>
> Generally this can be thought of as a bad thing.
>
> What is certain is that it increases the possible attack surface, &nbs= p;and if
the is a
> problem discovered as we have seen with AES-CBC it is going to be hard= to
> change later.
>
> We need key derivation anyway for ECDH-ES to produce a key of the corr= ect
> bit length.
>
> Doing key derivation on CMK is the theoretically proper way to do it.<= br> > Making a simplification might bite us in the future.
>
> I suppose one way to get around the conditional application argument i= s to
> always use it to produce the CEK even with AEAD algorithms.
>
> Regards
> John B.
>
> On 2012-04-04, at 7:40 PM, Brian Campbell wrote:
>
> > Hi all,
> >
> > I was hoping someone could help me (hopefully it's not just me!)<= br> > > understand the reasons for the introduction of the key derivation=
> > stuff* into JWE draft -01?
> >
> > I understand that it's there to derive the two keys, CEK and CIK,= from
> > the CMK and that it is to be done when a non-AEAD algorithm is us= ed to
> > encrypt the content. But what is the value of deriving the two ke= ys as
> > apposed to using the CMK for both encryption and integrity?
> >
> > Perhaps naively I assumed that using the CMK for both would be > > sufficient.  It's randomly generated and used only for the o= ne JWE.
> > It's not clear to me what benefit is provided by the additional > > complexity of the derivation function as well as its conditional<= br> > > application (and the potential interoperability problems that com= e
> > with such complexity). I assume there's some security benefit? Bu= t I
> > can't see what it is.
> >
> > Any help would be appreciated.
> > Thanks,
> > Brian
> >
> > *
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect<= br> > > ion-7
> > which is referenced by
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect<= br> > > ion-5 and
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect<= o:p>

> > ion-6 ____________________________________= ___________

 

--_000_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_ Content-Type: application/pdf; name="jose-crypto.pdf" Content-Description: jose-crypto.pdf Content-Disposition: attachment; filename="jose-crypto.pdf"; size=90758; creation-date="Mon, 02 Apr 2012 21:32:22 GMT"; modification-date="Mon, 26 Mar 2012 18:50:08 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUKJdDUxdgKMyAwIG9iaiA8PAovTGVuZ3RoIDI3OSAgICAgICAKL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtCnjabZDLTsNADEX3+Qovk0XM2PPIzA6BUkQ2CJpd1UWVJqiiUSAp Qvw9zqsCCc1irLHPvZ7LqDIDSg5fq6qNFLxK8XC978roZsMOKEMma6BsgIgxkAFWBrWyUB5hF9/3 3++XLkk16fg0DJ/1MNYmbrqEXdzPjeJpmyf7shBFKzIYrOVR0Tg0zkFqHSobZsG8P1VCCfxSD5Wo ZHF/Pix09ptOLWpHkJKoWD/T9Vt/21+aFquu/c9RZjPSkLJGtzKPebmZHb0emSgvo4+IpmQIjEYd 9AQaGpPa7RUcpVWAQvYavqbBFjjYJdAzbKPnOUGTgcHgxXL87izl0fNfa2tGa1lKOV4DkLclgDAF kLJjiZLWDX8AA+xoQQplbmRzdHJlYW0KZW5kb2JqCjEyIDAgb2JqIDw8Ci9MZW5ndGggNjY5ICAg ICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqdVEtT2zAQvudX6CgfLLSS/NCJ SSGU0vZQ8AwH4GASEXvwg8YONO2f78prQoA2B8YHr/f57be7VkImhkl81Faa1xPJlih83r4/ZZOD E5MyAGGjSLHsjsVamNQyZRJhlWXZgl3xabVsAw18VfZFHYQ6Tvixu5ZgmrIv26YjVd4svBDzr25D mm+uWfbFaL6WkTy7DKziUxQhuMnOtjgOTsAwK2ysYo8hBCUAxdCgzgKBwHrJmyC1G+QljYbB+TJQ KQLqsbTWvG/92/DuIQhR7+bl3YYsXVs7kuqyKet1TY6PebV2na+GWAZuWKhAQJTsEIKZRkJASTl2 jcHU9QB1lk1+TmBgH5jRQlvNIAERSe3HcXUj2QJtZ0yiKWVPg2eN5EdCxT6uYheTHzSmV80iMToB BpEVJjIE6vxiigBMrDhIZQ6D0JiIK2lSFCFRdlBTs2VHUJ98Ey6/J+3tuif1vK3rthnal0hAjJuQ Uo3Z0fEpchjHhkMsx7Cy7/7le/p96tMfob9JJL8of49Ut3fje90/YMk9i4DUW4VZsds4+cAaZMVz yb5wK2ou351dR+Yifxwd/VYjXfyXW4QVDXLQ3w9Mbbq9a0u1Pdw0Nh/Z2iIfNza/HTa1XY/frulX 7YPHsDl8kw7P9yWdP96ExpBGlPTPvvIghRkWjTbI+cm74Y49U+8u42V2oFJyGqb/yuQ8f00AnCAn fLOXNKWFBRhZ0x9gbfpuoJJ3RbuuFiQTlY4+1p0b1U8lzVbyOu/nRdksx9B+tf1teTdcnDGW/h5t 15W3lfv/fcciMfD2vFWqX87bRuNPeee8TcIMDg30cN6UKhXp8zF9mWUniCIyPNUIQ0s889mqnJPu 3HVz5MDyVZX781SguXpG+BfY8XGsCmVuZHN0cmVhbQplbmRvYmoKMTggMCBvYmogPDwKL0xlbmd0 aCA2MDggICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42r2VTVPbMBCG7/kV OsoHC60k6+PSAylhYIaZNphegIPjKOCpP4jtkIH++cqWk9BM8UzLtOODpdWr3WdXa4sRqgSi7mH7 UVpMKHpwg/P9+zSenMyERgDERBFD8QoBjQiLDGJCk8gIFC/RLb4oszZL8uw1abOqDEIuJf4WcIpt 2lYBB1x3NoXPbWlrr7mPL/dhTmYgkCFGMtmFCCNOtJEoFM5mmA9xR0EdbWJvN3Uj7hZ68dyuN1lt ly4q53hVBUz1CG6S5LkftI/WD5qXIggBF7ats9SbbJnWL09DLv2mB+dD4zprH4tmlN1zhGCIdu8/ R5+eTo+0rv4HLSdCK+deEqMjv+PHmG+gREjYOb+6uY59RosgdPkMFUi6l8DFJm+zp3wwVqtf6iTw Iq/cJoXT737eZK+D9I5GtLXpY5mlSe4Xa7tuibPDWDLhQDeaDsC76XzqpMcJA6HS7BSeWQ/MfM8s cLIMAC8bPykrv/yc5Bs7erxcONIPHO/59OrfHe/s4st1qCkNuf687/a++beNn0PoS/Y2ptHEULXz wbxAIYeguO4EXcrg0CQMSFL8vvBKMlehg26RtQ0ZbwAmCQD8dcaEkMWm9bnVNq2Kwpa7QzVyaHVH 8eEuHGGY7+L6sNvg8GFtGvt/Wd75wB/8f9cOiM9Z4u3zWQc79VZQEe0jncWT9QT6OwGQ4IQbjhyP EtDdEbf3FC3d0iWihGmOtr2wQMxEw1WSo+vJ1+HuUL57eN9H3pUmmunh3jiLZy54JLDmjpdTyfCZ /ws729w2qeteg+vc8TLJgGO+I/wJrn6RegplbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqIDw8Ci9M ZW5ndGggNDg2ICAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNq1k01v2zAM hu/+FUJP8sGq9WFb2q0rnKIFBmyL0Uvbg2YrjVB/ZLK7LNifn2wq2dYBHYZhyIEyRZEP35CMpIVA qf+x06nuohQ9+sPVyb6tovOVkIhSorKMoWqDqJAkUwViixWoatAdvtQxp9i5g+0f44TnBZ62Bg7X t/FDdXPKeL6iAimicpbP2RJVEMYFSoT3KQbZ7lNavHjEfn40n7i/gNLPzpl+8sU4x43Tm3C042wF frJ9A55hA/a5r1ujY1Zg9zraUiahikhv/56s/Kq7XWugKCcUeMbtEDOJ9yP4L8p1cnX5Du72dtqC W4MZzU7P0U5PBkL+JOc/Mq9NPdmhh+qSMCjamLF29lOceM08B8UB3gatddD6nnKxW3jNzgdLbLz2 FJ40Z/8V/L0boOQw6vZNnAixaPXLKNSgpbOm+V3e9gBBNjQ/92K/nIWPlIqli7Z5QeSX4wcRJ0IW vomcKJkB17fXOqApETk9tnBxHNROP81U4R8/itzpvtHTMjzusGQtq+hzRJfdpUhwwhVHvnYh6LzL dw8pavzVDUoJkxztl8AOMZWFlW/ROvoQdrxAwkNTPmOFVJJIJgHtuqxWniITWHKvMk9zhktna/B9 9OPhuRR2rZ9bljPKsTgSfgc5IAaCCmVuZHN0cmVhbQplbmRvYmoKMjcgMCBvYmogPDwKL0xlbmd0 aCA0OTMgICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42rVUTW/cIBC976/g iA8m5sMYcmy1WzWVqjaxlEOag9dLdlH9sQG70ap/vmCwm6bSKopa+WCYGWbePB5DUFYwkLmPLKu6 XWVg7xYflv+7cnWxYQJgjGSeE1A+AJxjJDggTKBcMlDuwB38pE5JSnkBbxOKoamOR93tk/vyakl0 scEMSCQ54T5JirMMMVmAlDmjJCHNtwwXL06R56f8ijrHFHybEAGVK0sZrEdjVDc0HgWl0B6T1Dtr /RAt1xsf/T5EUyrZizKuxd9lKGLCIcMcSZGHYj/PwcKuFY5nXOVB21DUqMdRG2VDVc7SrR6Cp2r0 vlO7sNHdcRzsWbYIRRJjB0k66ukbyPqj/5wzOeNoeu94ihgrvzEOpgmr02vh/kP+PnahTl3ZeLsn j6Ufg/lQ/Yhm27dqOHihTY5Gf3+miOGQYFgN/5fVz328z7pRjrACmrAdFgnoSGyn1G4mcDsuKrB9 bEWp1s79Tcy3jbLnNRGQvB38F9OHZ9LbqrlMUsYYvPnr4WxDiKPT512Xq8cVnoYFBowiKilw11ww 7IfH3X0Gds51BTJEBAVPU2ALiMzjjGnAzeprHCoFYE4fmHpgMZVAgoiognW5cQhyBgV1EGjGCVwb XQfbtbK1E66EpqmclxNMYT4j/AWErCQzCmVuZHN0cmVhbQplbmRvYmoKMzggMCBvYmogPDwKL0xl bmd0aDEgMTQyMQovTGVuZ3RoMiA1OTQzCi9MZW5ndGgzIDAKL0xlbmd0aCA2OTAyICAgICAgCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42o13BVTTfds/0gyRFEmZCtyEwEZ3d0qj5BgD RmxjmzRId3eDtEo3iICSAqKkSiMhoaB0CLwz7ud57uf/P+d9z87Zfld/P9f1ub7nN45b9wz5FOyQ tjBVJALLB+YHSQKVdHQ0wCAgCCTEDwIJAjg4jOBYF9jfegCHCQyNgSMRkv/hoYSGQbA4nTIEi3PU QSKAmg9dgGAhIFhUEiwmCQIBBUEgib8dkWhJoDLEHW4H1OEHaiIRMAyAQwmJ8kLDHRyxuDp/PwK5 oNxAsISE2N1f4UAFVxgaDoUggDoQrCPMFVcRCnEBGiKhcBjW6x8puKQdsViUpICAh4cHP8QVw49E O8hy3wV6wLGOQAMYBoZ2h9kBf0IG6kJcYX+g8QM4gEaOcMxvgyHSHusBQcOAOIULHApDYHAhDxF2 MDQQVx1oqKEN1EPBEL+dtX873AX+aQ4QzA/+V7o/0T8TwRG/giFQKNIVBUF4wREOQHu4Cwyop6rN j/XE3gVCEHY/HSEuGCQuHuIOgbtAbHEOv44OAaoq6AMhOIR/8GGgaDgKi+HHwF1+YhT4mQbXZhWE nRLS1RWGwGIAP8+nDEfDoLi+ewn8Ga4zAumB8Plbsocj7Ox/wrB7iBIwRsDdHsI0lP/44FSAf+sc YFigCEhcTEhcBAhzA8I8oY4CPwsYeaFgv4zgn2ocBj8fFBIFtMfBgPnB7WG4H4APBuIOA2LRD2F+ Pv9p+KcEAIOBdnAoFmgLc4AjAP/OjlPD7H/LuPmj4Z5AcxCOfmAg6OfnX0+WOIbZIREuXv92/zVi AX0NFW1NRd4/kP9lVFREegJ9+IQEgXyCIiAgGCQsDhTDPfj9M8+/OvA3+l/aexD4n9P9R0YNhD0S +LPETxS49v2NxP0PNbj+7A038J8ldJE4QsOAXP/mvwVIBATFfYH/z1vwK+T/R/6fWf5X/v/3iVQf urj8snP9dvh/7BBXuIvXHw8coR9iccuhg8StCOK/XU1hvzdaB2YHf+j631YNLAS3JAoIBxzR+cDC /CDh33o4RhXuCbO7B8dCHX+T6e9p4Gq4wBGwe0gM/OfFg4sCgf7Lhts9qDPucsHgZvbbBMHgFhH7 a7w/ZRhu1f55DhUEFGn3cycFRUSBEDQa4gXAUQIniQB9wLjltYN5/uI8UIAfgcTiQoA4zH5AeyQa 8HPQooJAAYefNxyuDTgD4B/JoQ/RaFz1X6zAVf5b/rX9MJgnDAr4OIWESoU41YW0H9coMHvwrY5I E+1kHJsJ8o0UW5Fie1XGrJeSDHNzprWeqn7sAataOXXqKrod582/3/NZqWdr8BI+5GNTXXdgs02Y ujy8MpHsc8Rye4qyBe+xaZriTckydC/ePdZoqi4yOTuHXkMOSt+/6ro/JHtw0pWrimmGtut2dNWU 52jTs0iYfPlkgG21HTBaFdln+Cv/k2t88HKMRWS6btZtLemOE0CSRzXVYv/gwCx1D+vL6EBN96DV b+xhWGoVqQEWZWGSapPZwms/8svct7JofGzVaOW37HqfLXCnHdfp7jqu7G5Z3uJK6RJztEmxjwF/ 8T5hpUbN0ilmoAuK1qLsZvLC2Qia+2WTjzAm3Zlw9VfzlZ9YnTXDQ7W8pie6Rxd/PNRK1zB/2xfC dVcnSeaiYuWLXyPHi1h3+zD8tr9q0qhXVHjpc7g3/eyDC/vYXXJnD7lCJ0wFzcUzHNuNZEtnJULa AsyohYQo3OEZVcbXBBo/95OU3D/08Ra+KNzr6FDknHarjkbE0sR4L9bP+mYVPz7dAQu8boBm1sYo eXu4Lh36VnsuWWr3uyJL/Cq9211Fvi6+p46LQUoC2fKebHZGhcQy8LdF3q6cWe6JOLhZgZ9gh1eu W/DsdD+Q/k0fsh1PCOBeHhhzuuV9voWfBdQFoBq8iZ7euy5lMtbpINpf2EuOL/vx7uV32bZ0vQBN YVcF0PC5gVDTVCsP3YBPB28hfdsKjQT1Uij84epbnZQVPXlKRz8+2hmuOIogOv2B4I2k+Jh2hcX9 1vxo7vFa5omvV9vLZQJJ+SWefM7Z2hdyYGbay5G5xmbeYc12aXuJtL7+TZHFpHjhtC9oiKRp1/Q2 21dG/JWm3OxXi5DdDeQDVYxeIndISjHHjp3gbqtHjO7zynF12QNlv4NvpDO5ib33U6+1f22oBTs9 qAp2KL9G3Am27WjN0XwK8bXpcIwts33E/dLjfvAO1JwT5JTyrc4MT8zr2AFAm+HIaNgcWshJ9MiP BnXBN7ZpP2UFhJxNWQN6mV2EvU029tYRBnuLnazWsTD56noefG/ftMRUUzh/s8Qwd1x/ZrZimGHc AkbobXy8c8FdqxjbpKxv3kOtpBDyoVBha0Xi5U1aIprZs76RU/AO7+g09fgVyi+mjXWCgyhkjvJZ zrNIgg5P2UH79+r1p+ZslkYqhy+dsgwGovwFeM/IV1boN4FZGVRzLuIr3mazSai6/fzsXPVbJkez gXZNt5oCpOyEC4uMSig/ikjeXT51p7sD1YrnmZ2S4vV+e53ELKaaxpvCGXijWH98waNXFuLWZyu6 Co7VOG0d0aLiDJWDvZs8SpSJ2LRvbZL+5qT1I26c3bnF5XCew3rfld2SKlNima8nuGD1hjNEe+gR 0+xJhtHbe2Cfd4G0THSIgsi4yTzVaR9boxfD7fbEYZ++FlT6RGqPbXFGdHUBBs1yJZYHSxdPj7Yb F2TlAmmnVxqMCj4MILcNPLLGlyQB4TezYa07AIFdssi2dVaWlwz0XmdfW675hRSEY9emzQqD226L Bey6YUMW7U/9umjWRlO4a8LECQ0Nxs1SvW7QSOdgGgSdUvWs2peC26g4uq7GG+e2hS76yE7EChRU VD9RckUurIJGOCr8HqNmbth99nGkF5aNookisfJQLv0mD9Pft7vWQ7AJgdvdH7ValO9slCNFXYUL SbHUBSr2tiqwws7ObvbvH1wlGL1dqQXdWLMGAPZlf7z+YYQclSnmYaFteT106lUc8PEOipaYPdN4 hAVSGlAXkCuiL/hASJIht5l5QPq+2qgP+PgSaqLBWEMgymWN1rl9HIkNtQsICJ57qrsVJmgJhUOW DoX3LmV2WN+gM5+7e81UO1rxvFTX+ljra7H/4X6kB20jk85WkdBdnsaeKHcRP/6nJRKlN2ryb4tC 2huor8Hub2T5JRCIPhH00woGbVub1NCPPI8hmRkWKBPt8h+KBO06KyZF9F24bMt6JM2bbUp/Ur8f W9NH6OlO84LWL2BFlY89+3a2Ld0trkZvZ2V9A1usVH3/tQ2n4paeXGfyFV3GQ+HKcWLhk8z9hfrZ SycFnmwbh7Fw/ae1dWRcpZ+lhgJr9CmM2UKUULbrb+SljruV8CRgG5yq5lzRgMIfoScJJ6VyIwyx aLyorxntbdb7VaEk1GP2eqSm8+/wl8vzyx+egOaOEmOdBZKqOKtFDq6+His/aZz8QBZYy7egfd/k wVPbL8JmeebDoIfDTvSyKhPOdQF1t8x6u7QTOpqOH/cnGqfXHGYvA3XCXU6N1FkGEGMXXtk9MOO+ vssfmFAFwtmcKGSoENuIryUbsNoyc2WN2bs1cE63ijOVKUVt0hgs3xjGLyCBL9U/qnFl862qdwp7 aUeA8QcBLXwCl/f2op5uiwWsZF6AOg+/2iB1dYF6Ho7TGdtU5+TqH/drvZCe75qcqrbTPYvqDF9k EFh4NXIjbsi15ZmsB2k2Md48IeZlG2B2hoQWmNN7zw7bZ9QG0KS/t9fgmTO3Z5TB16GhFxrn5mj/ /qSKKtntaVWTHhdRpwXfg1sxjDfztjS7AercLGj9w4RGVn2Rw6JHRgy22n4CsiMizjRfGI5k9D0K 9S7E6EV+RNxhlkx9f7fQ2Jpe+55cYmP/4A1dpao1Q53DSfjOJMW0bOo16r63RxGrV1e/C/G8d7pj 2p2rvCm+Hs2+O+67m3erWTVqYXA4quWCaWNaO1nK+hHATj9NU4O9qS2t+/4A1wcGelcDt3XaoyJN c4Ykf/spKgKJu2nPROs/3bAGnxaN+3sAyZ9vPWExvEskB46XCyYl35tSmOhd8HLhClrWvtL6Fvu8 gI1gxziBZvvLOlkX4zNX+TEe+rMEIzqJhBmVVvwSUz0Hvum0qZcxlDXqG6g1hmsQdeKbt0ktvIvP X1EJjI3fDFFxMiHyyQVH7oGHg41qU020z8dEvEy1fL0DxvaW07/5TjdhSYqdFO02Qk1kqrw/Ck13 GU1p+revmdd1NF5MCtmcuxdcoBDoYOOrOiamT7MP+T/T3ufDrmdmbNRU1gl6505+TwwpwQsHSBuK YsGNLj1zNs9ts9ai8PLb8DS26EdZrblzH2TuTVjDqFSuGWIpSoyhIl/eKC3JRwche0Wo+j21ld90 KmRENT0679UtZX1nQArUjv6aY9/nuSaozJUWNIwoqJueypmBz8Y+fTv6JAZD0f2xPTb40yk/ep60 huDmnor5Ez6CivPmLwfX1oPLA71fpK3Go6uIKDcXx9hLFJ+Sa+MLRCV8lmxRpD8ATs2/5wxQY84b GwE/FAVZYmwCAUn7qb5ZbclctfTC+QtlXBvfFOvO+aid25+35vWlOZcs7Z8917pZ5Ro9Jz9vXazw 19r7rgdt4100pHfZDWBkrhPK5gSVsV2xKP+hb1XfIsmJzWaTFc7FXRW8Px58ziG069CVur2S6c9A PJpU3oFaaD9Mv97CqKRWei0gWfddfk1cz4KvFFCLZFuUqkth4Wii38ZmpcNJUoAc/wbeg/r4gMsL 41IOnlNRZosPe02Ka0vJ04nSg5ur92LYUQROlQFdfRse3dhQXnj5PLyqWPPpRF7zjwngC+OS3qFv mPX7bblOoX6FAItXWHWlTZKdwZObmQIA5aVV4PNBMh84rGf5aiZBhfTjauaOzbfnvq/4fdKhNeEu x6C4ogiuMvrpR0qkGbzbb1haWD4+aLlAsQM5v1NByigb2FWeJqmqx7ricS/cmC8WIqrALhiswrNd 2EEcns63zpUyJQMkNj5bj/A993P21x6V//y14hXFkJpMj9Uzxw+b3M7V2a1wMnHb8cRjeYzVjWNP tUv+xDBSyi0GvaOwrAfR207Vy6p0RrPt7yjuskN2gpkMZmpOMfYpDUXFHyxcA6DOYGQt79oj0vDh tQXCgJcqm+G2O9F3larc9ro5w87NaLc0irL7JjII0S8sZppeBb2+/HRmAEPauCcttaHtbqDkvryd qKrOsZ9UGrlOXPtkqtWU6BAVNrHnTFwYPDKgUMBGxfXRUmeF8T01JRkV3eFsglVg5eikXmqty9zb d14yLPvlVt4iKjGBjN7sF0FD0K/zoCFnwyhU/AuFb/iOZWgMeeiLCBsizTfJF87R7a3DaiqOE5zr cteDQ4FFtItVzDapucvyEtG3MpAW8trJEKN0SwMs+RdK787qv5h4Xh4ZS4XxqYwyrYYmI58b2X6a 6xRZqW7u/PFCMKVD9tkXLU83oe6SxdfW2DLWyuyNhHe+o6bvOSJARcMyayqJ8tVtKfw7glaL6PoS yXwuVnXZCtj69L3hufoJqeqjD/3vH4f4uZrmbPB9b9RZUhjxxthgbP0S8mI+nndjWuTprJMx7QL4 6XnLqhGdIZR6SSqvnqW7bEfPO1qo2dheOYTcFC/Oambnmt8dsDIWoq12y2qYONhZ3lMiuv3s0r0z uuXA6YIaL1YuI/90dkiBdbx5TYS/HCPZYdnPLKUuWBX6ok7OpbOhDkpHs3KBd6/kaP8WjLRoZpMP C477IMAk0J9oKx2Wmjx77nwmsOqzQLwxmoLMHimgDYl/00ew/KVEXI2DOhI10v56q69Z57vkeOop 4vwVO9QwYItZ5NbTpLw2UGrUp2n50FtpTf4rymTjd8Slrj56vNtwuYchZM232qyRcVD6VpjYEDgn d7K+9d6bRCrW2jK5He2P+8OnnlwdKYD9Qd69ty6q9ERMzSGuNePkNbMk5YmijAT7Acn3/i0G9mye ZtHEg9MBRzTlwa1gMjZYhdT60LWAMdNe/nI7/yO1C5BKxtIIGV7xvDx4pakk1hNeE2Xy1O1q4nBL 9bOUSqop1GeHYt0rHl6WC1MWObMYQTfX7Qu5PP4PJVpNp4dSPgcHRq3CQVRhXfmv4st0C3cmqBaJ O5y3FnvsFj1fajiqyPQHl0WUWCZZooFGSV1+FG3bGkFnX7MF5xir7lCUhBNmXmz2mpPVpAMmk6AP z71ajQ0CnRcJEnBvJI2DkczP3gR2hoX4tpvdmygwedHLteE9P7rp6uP+Iq5bF8uTP/w9C0qFp5xZ O8yURG4thXWemOfLzt0UZuUoK2siUi0/2clkvHo897WO6QqBgl4+V1UY5rV9LQfX7BlqRHlG/bYg J1EGHyqKXGvHvybSdnlf6JbMQ5U9/Y2UdFKuLWVpqXqnmp7B5tOFjxqrJ4IYOtbCpoUzhQaHMLXk N7qG/VHQPsGJH23v0TT8YXPLYpNKcVZKigVL0es1dDJz6IRRm7RduhwXt0ouQcu5zkxdGHOu1noK qJ71i1zZGAqcdvSd3Co2Y/ca3XVqm3v+hpdsMlpzl3IqJ2tazNnZnPW8e5FFaAt2QTJ28/cxAp5T KKEOvK1P940fV7gFEzXy4NsUoIFPjhTIK5ONxfv6e5EJPCjMVZYTCpWSQxfnMlt5hD7v3rCUQWIM Ii8pUtDrbVg1fcjHJr+bz9e1Nj5omRgF33kmzrQUk5eKUpHs8BjMzRulV4HSkCfnd1d0y2gcbESW afbbfHudYsZt4Lkzn7SRQNDjSSYyyj/tWH6HtE1ZnXEz/yNoAB/a6P+ylV6z5OpyWMtOYImkGyF9 34Cjl9Zcw4WqlPT9y/x3oT/8u313nzUvkE1Q0+4bCaA7z0vZqncUemw32/uLGs5WXCo4XLz3QVkQ f8znZOV7SrrCWhZNc7trcip3vhsgxo5Sb28uOd+Zy99PkjcsOPXVJOe+3Fe3IGQmpvO7mzLmbiyn LM0dMJS2Y1mcfV68nfr8W1LFp/kNtXf91C+TifCas4zY1zV0Dpe8ovGyxOmFBXRYfWuaO+/ky9iI MvUR4RMlYiloR8SdB2/CC9eJpW1PUnPyW68AlvMZInhvSslQZBOqzTx65C1OJWaIRnGG1bFHOh+s vJFfJm0szYiG6AREvEq7QXdnsA7me5axb1v96WYm+VWsdrj4aC0ofTDC9+34ZofeTe4Ft3erVKqp WLI0vXz8IhnPupK2XqLoaYoPpdZrvTKXyVTnvOnVY3oSq2EKfsMMjy3Il7ysKO/KeFrHvHxmTPQ8 vmvhsageabiT4vSyuFyoXMjnVWWi57F4iSzmcfteyikfO0lcTUut7yTZRkMu03w9uKk1bBYpK7vh EIgvpA/zgo9fM9cIdVtoQEGec81L/sVX+k/jQQLExKH4XWlIgcN47CgTuSd56t4B7zA9j1jTjvpb 62N96X0GsDtGL6A12OhK/YzzpEi6nRnmNE09rjbYztkUJbbq5mUwJt1/c8mTXGafL8c9gvCH2ls6 v5r7rdve0MyJ/eq3fNxw/O+uJlMLXBXaWWnLpg7RT65coEdkBGopOznBqkZ+Kpbf24UeL5QZcrBw 6rR4xRbdVypOIbM9WW4pjeUlU/C4rlUEOHoBZKlMzCErUhFdYXUxRYdLEwtfHOsMWjNZGkVk+v+V 4V7Neian7wVwWgx9l1e8lPLoJXmGL18NVJuKMGS/wYiQOn/b23+Amho/55JZ+5QpTGyipFKN90HX UL5iTO1CVOemTAspD+dwoJHYM3H/R+EJdzLGFvs6XVJfibNdb2Kr633R4qh51lz6soClkMsp9tJ2 lYdexhcbw3wXOpYMoukFuTTv1DS8wUibtHngVfSDx1KOHrPxsMWrMgbvpvOVd8/Un1A/8kaKBA+U zD6rt6sgoFJ5lHw2yNlNF/SBuK+s+PiRdiu/HKhhjm9yedrQRukqXpCYG8woq5i+TNq2hByFwtY1 z4/VYI1M9WzCWMa+CfPrebJ7Jnl+pv4ed2zWwlhQMeQgrqVGZ70Nqr8VOIXc9y41Df42PASX7Cc2 befdJUzXqm/v/DFlROjx+QnGLdyoosMxSBQ9vbmrncwpaXo/qqc9MxG47PC0uFHbTjYmMhxfiySb Qv5MaNJi21BXUvxxEf1fDoQbpQukxnLz3CsTBrYco2fTyJjmgIx12ShRiuWefn/uDDK9JMCzJ/1m HiJvBG4PLfk6Z5ZzwRjZBRjmNZ91qJG3LCbf7D94mccC0jlA3nFEjRptcPTsrl7hMyjgki3hGTkl Gyv/MiAoEuHYvr7T5qvBL/LwpY3+vaKjqSBum+9P0vX1+5s2uH6QHAknizCk1luVBc+HBNHpLFQj I1hJRdR4bOTeGKjqlFMsdgdcTA47LMdtorrspxfwEQQXeB0ifWBKu4ri1sSvWj1bNObaAK8WN7IG xa4m9m75vxgjBkU3bpluLQJGEk5Vrjf1abTuiB7fPdMweskeHnsx4pX9MXw7+Yp6GgreunZpAnXM s2Rw4ZxZeKzaPSfZ+opKr3iD/c5AFOktZclyvGhqvFAObnwSOgjDcraOZ/L5QP9ta+30UzmWV3Y0 PKeS4VOgHUFLMU+uL23CKPKqe+LtPCz8hO4irHmYIVvpg7h6S239MNAOz3GT1tfU97zN8rIwfr5p 5NPx+PULJcYqRkrCtMd9AS6DVDt9oxb+jAa819ndu5FpyiWZ0w5hC6QXXoEnmwXrELaIq5+VdRHo dZ6d4cMq74Iqx+Pgj8fmgZylvZzhXZdrEz/c+KuiB49ZO+felYTf6Bkp2ep3STHxFDowyn169ZBD 29abidjW0Hu8QRopmTBp+ALhH3ID7uF7j19n8iz6uhITpDKb8w288f1YXbg7ia6PzxbHNJ95zHIe XwZvfisNP1KeZTpLO656xF85gmUc9RXLrZCftkvysKkxP2dMHl94HHnAXNFTvkk3tFRITgosk8zZ 6pBMDpPicD3NDX09REh3WtVol64pPHmOXTEMAfnl9s5vaeTYf5ovWOb+RsKt+p4cEbG0KdIVP7i6 yjKPjhvTDJspTvwS72mFH/5VbHEWRHYt/jb2xZFyDCQOKPzaheykXemG850rhBKfnrN1iqp4Pk/v oLWh0Dfg8rN8dS1+7Q6gkIRT73EQ1usGUTxbJ6hkT1fEJoHtkJvFInj79bVx2r3uiwv7OcovrkOr FWD3WLIUAqtKQIpDcPquBHXV5/hVozxzHnaz1f8BtEhrTwplbmRzdHJlYW0KZW5kb2JqCjQwIDAg b2JqIDw8Ci9MZW5ndGgxIDEzODcKL0xlbmd0aDIgNjQ5MQovTGVuZ3RoMyAwCi9MZW5ndGggNzQz NSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqNdAVUlO3WNiXCIN1IDEj3 kBLS3Y1IDsMAo8MMDEODtPpSSoiSgoDAUIIgISApISBId4fSIF3fGO855z3/v9b3rVnrmefece37 2ntfDxe7kamQshPSEaqBRKCFQMKiskBVfROQKFBUVFxYVFQMwMVlBkPDoX/MAC4LKMoThkTI/keA KgoKRmNtamA0Nk4fiQDqeMGBIHEgSEoWJC0rKgoUExWV+TsQiZIFqoG9YU5AfWGgDhIB9QRwqSLd /VAwF1c0tszfr0BeCB8QJCMjLfgrHajsBkXBIGAEUB+MdoW6YStCwHCgKRICg6L9/gHBK++KRrvL ioj4+PgIg908hZEoFwU+QaAPDO0KNIF6QlHeUCfgT8JAA7Ab9DczYQAX0MwV5vnbbop0RvuAUVAg 1gCHQaAIT2yGF8IJigJiiwNNtfWAhu5QxO9gvd8BgsA/vQGChEH/gvuT/RMIhviVDIZAkG7uYIQf DOECdIbBoUBDDT1htC9aEAhGOP0MBMM9kdh8sDcYBgc7YgN+3RwM1FA2BoKxBP/Q84SgYO5oT2FP GPwnRZGfMNguqyOcVJFublAE2hPw835qMBQUgm27n8jvyT5AIH0QAX8OzjCEk/NPEk5e7iLmCJiH F1Rb7U8I1gT4t80FigZKioqKSsuIA6EeQKgvxFXkJ7yZnzv0lxP004xlEBTgjnQHOmNJQINgzlDs HyDAE+wNBaJRXtCggP90/PMEAIGATjAIGugIdYEhAP9Gx5qhzr/P2OGjYL5Aa1Hs7oGAoj9//3qz xa6XExIB9/t3+K/5iqiommrf0xP4zfhfPhUVpC8wQEhCFCgkJikKBP1cMmnsS9A/Yf7VgL/J/7Ia gWF/LvcfiNoIZyRQ5jcHbPP+5uH9Zy14/0iGD/jPCgZI7C5Dgbz/Xn0bUUlRCPYB+j8L4FfK/2/v f6L8b6v/3xfS8ILDf7l5f/n/HzfYDQb3+xOAXWUvNFYW+kisOBD/HWoJ/S1lfagTzMvtv73aaDBW HsoIF/i/2gjz1ID5Qp2MYGiI6+8d+nsKWHg4DAE1QnrCfn5sgELYgf2XDys4yAPsB8UTO6tfLihW T/8sqY6AIJ1+Ck9MUgoIRqHAfgDs6LEnSWAACKtQJ6jvr9UGiggjkGhsChBLLwjojEQBfk4UiyuC 9kH+NAL+AQzxQqGwivs1emzVv8+/5A2F+kIhgPERJEQu4n5FRP3xW+WbPkLLfXcGuZYtX/IJBYyj GrxOya4/5ytLD5tFHSo/72qhmFpU5z1QmmC7CFivrbz+uC7R+MNZ4Ll9vMnA8gfAWD/dpy+568rv 2lmImYXMlFYCLzwCLUIf4NfiftThyvLwuk1m9Jr62KdN0/ddO2ay59HIsvFKmZQuyTnmq1CseYxN aP4QV7ZjxjADByFaiIWIn2rHl3zo4HCQ6tWXKzadeAFA0EaseF7AvTmxuJNh/+liMzHPJkZOxnsM LPgHVD0D3AEqa8k69KMBBXlTn8Z8a+Xz2F6RCr6YEqIQXhNLK4OZRCOqW8u9e8YbQUtZz4ERPDc/ US8llhdW09ijOAxpyz7YR1Ojy8UfQFnWGp1VpusPLZqd779gnpD5+u4KOERq5boeUtMccFbpMd3V /Uno6NGLuuOu6u7F5iDLfMV2RWYXHxC/uqt11NSkbBrLi2sYdC9ekyVUm4ZCcML7+e3za+BI+YCw XZVTJtBCrqjovdvXWnF7mLckswJ344JKqnYMGueGKEfhPlS24VfhUgZXjh9f7OzkMrqKqzukP+LN TlNv/it75imPsVwFtGooHCOyM1dCJ6xW6Meml7AgObbbwZknoa3Zujxa2hVlE+Z3/0QmR3jLosT8 wzPJHGP2pY1ood61qtBOlfDINplDp7WFw6IiFTvab0iLk50SnycqXXHzZtIR2X81moS8avI0TNFU jsZ7c7Q43ErseGvTTMWb3a36Kbml2Z3Txd6mN+c+ghhtNS6evHH9dt1v8o8Dx23H1PJaGd+GKNH9 dVAdIlbRYHjMi3MjnWI6jit9ZRL/ln1DV7XF7iWTyk1Ts+PXt/zncFpHv/Yusn8eWOQMgJfY5Eu0 1QDlJGNS8OHx3OyjiyGp+7N3eGOiLp2jambMfZQrJ5jL04Y+QWc3OnsIVG5dbxAXpVHo29AC5hby pM/o5QnQXI0kZt5f8M9QOmV7WnOn1NOmYobmQD6y6I5NkxUu56ya4hPz78T9K+dSz1999dXMNkZ0 FN1MjWJcgpVxjSRlso8OAPTEcOjLrTNTKX8s5gXzscc4R94NI4KsUUYT4SzKD/PQdFY8Td41oTYS V89mjxCSLafkoZy77Fcm0yEvE7423lahqtOHo4PG4HC3BkgTPpMqB9wKtehv7W9aHx7RGr6ZuB8t UthNpjHq4sOhIZn01GfX9AlnYNlVKNJYvm+17wUJyYDDw/fyGawg0cJAopQr+Q/f3LYrq0/G0me6 XHdmsiJmS76FEFVVvX2bptjF6KC4L528Tkdi35N1zfp54/5tXyN5CdAwy/4d9JdjLZwJclI5qZTa miCUrhfom/hZqrkqzjVYKl2lFrqkYmAw6NCPgXXk8iGElctm1mM7xKaubkXCUMKb3TrN/ki77vXb 7Xdl57SfViDRTKKzLEV7+jon+q+sRIt7nnoHSM0yJI3YHLcC8VCvPLpSOcQZ7xzhJ2WYfbXSFZ7S ZfjexdcsSK/ZrRsAfqJ6T0UzswHAyuI3yUsWpcvzqFXMUHTQ4kWplLYRJyf87NtpcY1QIv2cdRPD +hC0tyv6uIOJiFG3Z5RbjMslybHM//GRTg9jiqAX8qF+sVgbg/+MV0JK1uMhKf7UD/xvSNtbSIsG rmQ+9hXMKrbl6CbRQfgYPn85mrfZcXmFLuFWLFyM+9L24wxBaLbu05C4Us+Z5WRgo1qTlts3YXg4 8kUpz1LMl23ttge7ntPX0sWbyPWHSyALkZhOlTtK5T9ON9lFE5qtspH+J5ybJ/1HHSFcbSUfB7po feZn5sVskZjWWWCp/YWitutncq+1bBW3LQ1CetkqEBnRWLITUWGnn9RRWNPEDJBFg7QggkEPIWm6 58NdKLQ++LYsU9P/uEDmO8OdTp6EJd6ei3rtc1eD08qRgCVDKiDZSxC+njdk2I32GqzqTRN3J4f+ xne3NqVqy+FHJQy5JW5Tjlyi4y+v8Z86pK5fb8tOnE0UcT5ozYA3cBmpi2XLsloo85mq6ImsyGPo tiSpMaqZyjmzRxlwudKAz00kvLfqxu5eQ2gQJnAQReO8xIm4HWAyhkygbG4zo+ddsrfcwXNUvgzW DUTqk9hTjwy+sKScvWSObyD1W9Jfu5IKKcoqt2s4AqMz2YiUDEHr2SIZOBq7bEnvxf1Yb6UsQsj1 9Uf7NdvvXUxb47sVX9X5f4nRCCYkpoJjToo4WnQUSqEEYxYqTy1VmINWLfieEUyZdk7CGAWzt0Nn 8rdNqOhq6PIaPmjEduBjGowyhNca9AgGQnyPCd4w2Fv33bV4Qknfsf/DOKuM1Mzo6sA7POsEAO0W THC/nGAKRwW7Jp7WJHrR7T6LiHEQgAcwER1BjY9GntkrOdNLiTNpzRqBvQf8Gc17ae3fvuql+XSv CMTKj1nqiKUqe6ov0OHoHvJILmAa00McWmIsTrdmYSE3ll3f+2SQjJSq1FDYMHMOJlh/+3bRCGv4 RuujSJdXd2zuzClxaMyd6mocm2U7nr2Mb7QIjYPzwl1KmzMmHL+WxE6z16xhhpOHP9vMX5yAJYxB 9G97HgKLZBY8LPJq8nvygAmedg82X3s6xaUhyPzjm4mul+Ss5sqOMOtl+jPaxlHuYFAkUXmvMeHe BmqN0fqa0jKc2nqwS+5E5TGXm/MIuJQf7mMd4qcahlV78rrEy+tGvbmGccrKDN3ejxKDZ77CX3Ov Vh1bLY9W8oz34VhO9C+Hcze9Fg3VBV4y0qaKwIhh41+9iB0zmVpUAbc72vyVtfKGX4njAvyE96yz fGsXptEgZa8STMYNd+UvwtYSOaZjYo4+SQIQILowd8sAysTgyqzWUzFN0s6Rws76cKlITkDa3SbX x5eRympBE2A3Lale2ju1lkhLxfzKfqo2WbPqaH7nWwgvq/INeDX1wBbIYeq2l/C+l8DW4jjH6b6C 3I5gsH9X5QAXAPmhbDbLF79T9KVnGOVIJyOVJUjD98vW0NqLWaDLpVt8bJWvhd9B1QTlQAaH7S3/ hwwv8t2995pJM1gexaccjrUXCKNUZP7ipEXUWKmWqIJO29AYJ6VbRwW3cfofGDweitZ9i5s1KJfT 9H0oER6qccpLSDIWY7Af9QZXbm4+z+myuOVsEzehhOJ8lr8+Sv7Tm+zni+3UEdQYfM+mNzLyVZpP SVXVHSItvr12nWvoauOiNU7s08hDGjW0LQxQhgdzYp41cAyIi9cfGcmMymzci/WUeYzL47BYwkq6 gZqwPJE1SMrb6PQcPOhIqmZTInQOv5Fux2I5HcktJuFDVQj3J1nhHBKz3Kau8JmO/LRhKON4lbPM YfjmFXV3r2UrvwaV7bTIGwc/TIxxOfGTriQb4+ctNzX4MVMwM7rd2DU7A+Chk32OvkN47iNTLrN3 BnW60k/LiARMUkY2rFF5aeedVgft1JtWHtCg+vIx5ht50UdjVo+NTn8A+jRwzdVfb+xfxuwM6oY3 DZNrxfBUVCng3jNW6iPXHp9Dc+UsXSWnN1kX8Em3cTeeZ7n2ITJulDN+s+IZmgS3vDdr3eW5iwoe mk0RQdgjnuPr6GXTkRDxJisBKlazPvenAkqqDFgCdDWqZid37B6kOc60IL4/pNt00CvLsSWaBOea Z+PWtgecP6HyXtjWm52qW3ktkfgD9JIzmBrlpny15fmcpuXT/h7i3iw+f8qHO4VH3Z4HO8g0Gkel gHi/ERIidlVVtugAegiRsGXwvfcb26wrovQIkjlH90gXT6OXTpxCAzaHZX1Dadx68u4fCahqyOHU NwJrH6ZV3l47Fe5qS34v4NzX4e9X4B3ONm9foeJf2v341aMfYoreQ/VEhHjf9+sPRh+33sUF57Df ZhzOdQMkTz5mcPEZZ78OIDqWXtYgtlLyM7V9uBv5Ci+l5ASOVBn5VpxIzJac4c0uerJWHaWRFHZj evZ0q1B9Fmz9JMz52MhXIkQrMos28Pt1y/NKuUlN1hEaCitqDnGVH5Lj++crx/NaNhyDRdaEx6Dk vpRNiKTBsQzGXUFMWueDysV+lacI/lbUexfeH4W+tMaCZGgF69KF272Jmp7tNaGybCacMrZSNNxP Tt38SvlgVYxR3l3f7rccWhZE67WZqNixmKiA4R/Xfd/ZZ41aZchWSOrnlxHMrmxN0mxHXaeO+1BC XnUzuOBM5H5u5Fz7eDZ70IxD0ta6Grclc0gnZmnE+G4tJ6HWbP4qeQ9aO7eknji4c1h43Ip5V2kM QVuESqaw/7GBmAptISJtNDxfRCsbXBPSI0UkR79QvGY/Q2dnHznpQpNQ9TCT7tNTuVgH1rf9mwW6 Ko9ndqSgbe+bp9jK4msACklr8I/G7vGPmIpeBw/yNT16n3FSlbcnEit33ZSR54Zd7YHsEppAp/y+ 0nca36J34eq8oprdcn11tJPGHnhxhR1JD8x4ancyKeQy5Z953ESMLXmFouF6qqDEu21AyV6mFwCP +NE2j695oYpL0f3+IFVTgSbmHCNQ60NWaBeeqVgviXiRTrL+RHfEczjv7mAVJxFrHbTLeFnEzd1A Ulca1/ICGhXI1zo5NgOO0koumbtXO1gm4RVrHvSxvW219UcBIY05cID9c7LV843vOCfsQ7jaRENW ywWDrxh1udYgeeplNRusZ2l3VMZ7tG1vhpgSgo6At/YH6yhdyXqsjR/puWKshJbDHpqiLv3AkkB9 IyvNwuF+OVYZglhmW4LCAXorHLroSCXJkITp2QFeJsBxerwCSUZreHWXmtb9x68pFj1pUbRhvlPJ gBXhFoWJ/pGysuwvD16UTsDb5LiTy27Jr06kvt2DPuNzHljS8E9zqO6oVny9qA3BUTLV4k6Wv7pW n7BFAPVG4NymDs3QCGO2WbQox4i374NLlNn9/OoXZXcHBWgyIew5vjvXksMcv+hfjvw1L+IcJD6b nLb++U3HIodmYTJlySqPs77nwPUhtruW5hdB54dV1TVWbVWxdiQhQ6Nc93s72LUat6MNta6Iunrj 2OxP3kfLrT2u6NsLjl/QqfHOJqsItZ26BeAcv44hn+RRdVUMlUyRjzBluGD5sPn5bfOuUmIJQwZx Kri4MkSIJkU5GBL16BscaYlbqc+795QQhVOdf2vSYbQfYRVwf9JBPBCO581S6lDHow3PugieK2df rjzPPhg0auneCEh6Tahe9nL7Tp87eM2OJHTMdd3wAb5DRvVW2qL78emNktteflOcqL3k6f3nXgDn IIhHq4Bks99D9otp2+GM05vHTRtk5oIluI3oLL4VmKzWXlajYWTbJG+pPdQw9BuLhkXjpUc/IZ1C sdfaXJuQpuyT+d02//DMyDStezZcT803vceacFhJ+/0X7RjmPqvE+nGFGJgt1LwXv8NQend9TrHe jUYn4ZhOaFA84ogFtjiqpTT1LNT5S/jFgxoT4fW0gwtvnpAON2Eqnl7TxRa1Dz3jcL9zNgbpRLrX N6wORlTflbS7fauye1+m6SVpr5l2/bhqHPTmjBwtEjNEcjkX27OwA5iT+KscVIJ4Yn+mphDkTiiw 4oxxkXHlZDktaMe1VdrWP3EYs/taq6l7KCdZRJjr07H+gWBJG+WxrVwg7qwcNmtFCfMqDmmZXmrd axjY3vhKZYWi+MaidnAo+zR2won1ukke/jQwURlNeWNdCPNMkIZvoQ6Mye2qc134ImM9lO91RWS6 yiCjm8AYQdlmplsIvsu55OPSlfjeMNx6Ac83+qZHR3iOH4E2b/JV/X0KSb18jHYTpCoo0JW1iTPe X22B2vxLyzOfD1axAg0Xxfdk+7ZX277ktqeDPu5VwYPHoU03O3AdvI6V8JgCCYo32GhHpp6sVaZ+ spuQurklkuk3cOYA3smmetNJGmVd1hdF4fC1sUc9M6fFh6n52gaY9eaNbP8V2J4eOIKeKuh+99vV LqWznKjloPZgX/KVbcv3166nLCMee8a9FEXwkwWQlcEV7xX670c/76aKVqhZvb3J5i6kN8DdmXOG v63roAB0qCzganFIfr01/bHLE6NY5/35wyc7m/O/+BNoRy6Mu+cLDBydIwUm6xtnIjKRHMSx4/nm xPX+A/su3116wUtxz7wqNbIGUuRbqe+e+k3XYIr78U756/E6XQ6vJBTvitm2PJMo0ErtfZ02updq 19zvoQdFVqS/NN/cf3jjKC8hoV9aYYPvU+5+ihbiWSZeXUGJsjTHtwC1RybyImLoC/32jh8nnstv Qs4eyGjf/ZHgnFOYPoC/cPXl4kyAevzNXfWN/GSKTuHv8+xN/a0c/DqTptJkTRNWrGVEzGvXtu9P krJwfx1XXtO5IVC08uRj7QciqgmqOwfJBtnLnFLeFaZMZlaUf92aZCjVe3El0Ze/taqYhvOF53Dj qPUkWIPeyUJTb0RQYJXOk7ZY8zJ3zk6kptCjspWg6xDXNaadvPjk5B5rsX+EWiFa6Yb4EZQqNe3V mv6YksJ9PnlLV4cl/fonClejr7uuHs5D5zYt1HSGA1/U1d0lDxrIV0VFddJ/MutU7lwjcWa4wHuZ k5BkFCR3LYpjsF73cPBWX7xZVjWZxtGpzSrTxZHdUCI+CxM+iVwKcVPgdxOgmk1bGKmW15DUlXH7 Rf9Lngxj8U5HOd9bNXFs4vtspj2ymPuOlJuTXDVonfjrIgrd2YZXW+ksKIuZ0BZGX9u3tYT1CnwL 26+aq2xD4Bkn+JLIRgrr1ex+DTkKQQPuAh5qWGGUTbmBcbP2ntZQ749+tiZFM9lNpTGNbfpVgyuS 66Z3m6dFy+WL+T64zlmOEIY2SDjXaqhVuz6dFB57Z4bHZ2d6bUCINRLhE3QhSPLknkGNOm2/Ku6P siMSK5JYk2vQKv+WocMd8fqvNoD3Y+jNy0ureUmHp/QaD+3TfJtjw/HNMwOjee4mVHU8jtBUIjcf oZDSJrFhS4lYnTpUOJftsrA/w+tSGH4jw68tGkQ3WGXDETBGS7Qtbj7h/2m3y2tJI90Zv2c8N/LA aLagm0/92ZPb5GHn5nnppz58pTsu1FGfaT2GZOec7t/Kqy2bon3iet2jgyQvvd4TSSpUq5QA0MXX lH66yFESaNz/GG8Fc7oMvLfn7xkYGRaU06Y3XGlKHZUnG+KMGXarz29RFt9+OrJjSiLWdocxfsT6 nVP1WOK5TrrN1Ds61hLmPTrIxgRDyPkJeSDhZ3TjfdDApzTlVdRlFG1p00DpJWOPjneLoC5bIC7x XmXkl+cWM8+epQNenqcZR1RaT83ImzfflWUmCJuYVIQIHHLNlRNvGnyYUjGVlHl0HN78DjcWk8nR OtKW/s5lzexb/fSSnWOhZTsR4SRvBT8nMMaHsPh4jY82KiZxMdKOxoAdVdJq5Z8nn/eImx71Qk7Z SVv1poPIk9AggNB9IK6Uv81n+B55z0VUuq4EE39vqK4Q4+i0ZZ7pslF0b6kyRpMnvI2ubeqU/l3/ 1x71bbGxfi0j6Wb6MtZNqyXLLqEKje7OHbGIk7gJQN0ShEGDtNzkzYKbSWOLPDssFUNuhcE07G98 BmZvsfKQtymIUS3EdYuOPY68oJukEqhUjiqvzcOcBdcaXBa2ExOOtVXT83cOAPZ01K/Ya/SBH8Mp lLa/eKxPw0QJZJsmJRSljpfG5k18rXiER/Sk4vYwXUNQdqFmTd54Id1qoW6XkgP+9lxC/oxi8g2p aMre6xKsRY78Xjba87SyXOvfO5AbDsw/BsihE4ubtUc1WqjIZ2PSxIWPngQG1Uzs/FBfn8yYFpnR 4zM2bmRjTmdSeni7blf840Gxembe4E7Qs/RUtgVrPKFM67l6XxHIWBLXi0B6/dfSoL+o7QCNDRfV uUxs48FtD959fv4UQmAFJQTnVxYKroRRxdPp0kxQntE1rXi8oVAKSxpcSoxyl44hCi410QL0E0u4 AmzY5Rp9TKQoDgF5In8pZqaJy1dfrsg8cEE34CZyUzVarbV919XMycjw/J58uReRn7VKZjN3proG xHxRCqpw3fMmlzrtlWpW7+E6vruo68YzL2vgIxfreJP7yp55MT7Z1RIHsMFsOtel02b5lWPZtdrC 5arUR9zD2IVJQzi+SZN1LLBhIL8prvfrgFBTve2eqmKGLQXBcvXVfhdVR3ygx7fYNF+yuuZHM8LM x1oqE9Z0e3XRHbaiC/C++3kzNZGDLzqVYmiauj4QknW/f0Yw6PjYIqfwPWc9yWlrfpNTeP6l9jfK mKSj1EleMpvWCPJALifaPqOo2nto6ZpvXo639q6sTejaNC7Z5Nz4aOcfWCTxsneHRIyIBH0iojRL PnNWIlnmKBbwxbfhHpR1XVGl8VNbD5myOE0m/OFKPY7jcqkUQq+60TgYV0sPZuAhgSjerlx5Hv8w PHTUkFUH9tgcEZacKF18o4dDaJo9/crEr4DYaPvTuMuYSW5hFtHofVKc5biKk+HPtmK1isU+OnMx XtuORGnzH6U+1qxlqGlnn7xsZSjQulLRCghbLIHoddjnHJeDC+jY3QWY08xiUzfFxIgrUxPufX/w dWWpeH23pzpZsjRnMpxKgXvRB3Ruecq2Q1uXxVqz6rVpiwza3cuvBW2LBN8q9SMnYBRGUlgR0knL UQWQSkHMVXe4JOOjaiDJbvOTF6dj3l7z5MQrL8fzeToO3uLlMELVMF7xRHjkLhDfEiHyk5f4h7TC 6Q9DNzXx50USY8w0ObZy4KK+oIJPJ7r2Q4FFNDNvbBulk72ZGxh3QyKDYnTm9d4fUGYxyd4JYGIC tP8Ph3RxHAplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqIDw8Ci9MZW5ndGgxIDEzOTYKL0xlbmd0 aDIgNjE1MAovTGVuZ3RoMyAwCi9MZW5ndGggNzA5OCAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29k ZQo+PgpzdHJlYW0KeNqNdgdQU2vXLk1K6EXpEilKT0IVpPfeu7QQEgiQBEKooaMIiApSFaRKV0SR Lh0ERJoUKUpvSlUB6fxRzznff757Z+6dPZP9rr6edz1rTwSumJiLqbpiXOBaGDRODCIOlgeqG5rJ AsFgSXEwWAIgIGCBxHnB/2gBAlZwrC8Sg5b/X3Z1LByKI+g0oDiCmyEGDdTz8wJCJIEQGXmIrDwY DJQAg+X+dsRg5YEaUH+kK9BQHKiHQcN9AQLqGO8gLNLNHUeo8vcRKAgTAkLk5GRFf4cDVVFwLBIG RQMNoTh3OIpQEQb1AppjYEg4LuhfKQQV3HE4b3kQKCAgQByK8hXHYN2UhESBAUicO9AM7gvH+sNd gb/gAo2gKPhvYOIAAaCFO9L3j9ocg8AFQLFwIEHhhYTB0b6EAD+0KxwLJNQGmusaAI294eg/zgZ/ HESBf10NECIO+SfdX9G/EiHRv4OhMBgG5Q1FByHRbkAE0gsONNYyEMcF4kSBULTrL0eoly+GEA/1 hyK9oC4Eh9+NQ4FaqqZAKAHfX+h8YVikN85X3Bfp9Qsh6FcawiVrol3VMSgUHI3zBfzqTwOJhcMI tx4E+j1WTzQmAI3/c0Yg0a6IXxBc/bxBlmikjx9cV+MvD4IK8B+dGxwHlAaDwbJyYCDcBwgPhLmD fiW3CPKG/zZCfqkJ/YfivTHeQAQBAjwUiYATXgC8L9QfDsRh/eCh+P9t+LcEgECArkgYDugCd0Oi Af/JTlDDEX9kwuSxyEDgTTCBeBAg+Nfzz8mBwC1XDNor6D/uv4cL0tTR1dbQE/kN+B+TmhomEIgX k5AFiklIg4EQiIQEUJZwCP13ln/w/439t9YEivyrN/B/MuqiERig3B8IhLv7G4b/X5wQ/GtdhID/ rmCEIfAYDhT8D+3twdJgGOEH8v9N/t8h/zfO/8ry/6D9f/ej5efl9dsq+Mv8f1ihKKRX0F92Aov9 cISNMMQQ9gL9367W8D9LbAh3Rfqh/tuqi4MSNkMV7eb1zyUifbWQgXBXEyQO5v6HQH/PgJDeC4mG m2B8kb8+M0AxCBj8XzbCrsE8CZ8SX8KkfpvghFX6d0lNNAzj+mvnJKRlgFAsFhoEIAyeIEkD8RDC crrCA3/zGggSR2NwhBAgAV4oEIHBAn7NU1oCCEJg/LC/tH8UUkCQL4GNv+R/VYL5YbGE7fvNBEIb f8u/Vx0OD4TDAJPjGNiNWx6vbr05qFTlDBBbHlAcEVi2zhASw09im/yO6ChShV5kRc1i91VTe9sZ Pi1qCu6pTPGc4tfrX1PcaUg2bTwOOXFKMhtebgRMDF16O/h0XbWqi5uKS8xCZSXk1CfEKtKTtJ64 RU8g18fvOp1JPvNBQKd2YFVX2fT7mPFl05UXMvrUJ2UfxO5ZJthHFo8K5Lk8GWPjJceJcVMKM+0E 0o/u7Y8w5Qye8+gliQBCN+5JFuLt5iTuH44Ff35mIeHbys7PbsfGTbrH9H74Kl5tLU2P9SO+pHCm YNTeryhO8lMrkYN22PgClaxCEDLp+kvlHtIrK27zPzdaqOv60KLasRVTaU9XTkXLwyu8SaRXVk/A ezk94Qxb+HHuMqaaV7wtJ09l1Q9eP7q4IBMXocd3hUNRce9aCs8O9u6UP4/SFI/2LntaxZUYEC2P Ka0WneHrsC4ECHWZUzgPeVcwm/cKsrQtB6AfIc2sRNNVcELlmiyq51hefZuTnUx0Z9AhyjEfELzK ysrxQZiT6nu1SKyne+kIiYdxwFrTJ58NEqodz6uiyStOyhGP3p/1xsIu8yajlfeLBsasY5OFspPT xu7yMLdyDHCTFlHd8+xIW4lPdd68Z/e8NqUDtPvAnImWOk24Xzm1mjwcFkKxlLJs3eWGaU7aSjod 43hX8cqlDXndHe570FxpSo88utXbICWklZd0yOxf927/cYQJjdXWcsmlicRWb6RnUp2zx/bYzpJz a2Z1m2a5pRCGcutrtfUOtYeaEeJu23RrXbRJr0XCBHlD0QeoE//2F4bntL1+Gq4sMROS900p99PV 2O3MEUF+UjRr2SWB7XNFDfOzw0aHCmc5CZAJzg8LeTbznqmyrCO6mfVKApwna6Ej4YCJa9PLFo/O hUrDLvLrCgyc+8w9NNHlqxIzZEoeXLMK9Bygaw/s2lCZeTM6ncVsN6sn4x6x/XxhStFddapyduA9 uTxDC18ixmXcv2GGBQxvtj/l2aXP2yRuz+viBif3rl3Yg5m8UAvGd3HkI4gUZw9qXCHxXz9rP76G 74B8bFVxHdAIC7LBNqdqVBjbJZZo9ooPJn5SXE8WFHAsaQJJWLXWsQrVNXM8+fqhq3tJcHZnE7Xd wI5oYKe4wMRldl8CzOY8E1drYYDaBRHvL5ky3zd4+I4rijZYf8KQG/WSp7/wZWHWzskElYjjl7px f9WqNwCMZt+ZdiBPmT/XxqZNrW6gKknvD+vXOU8peo7GlAKn1NvLWtalh8miU3a3rwTkjTh+SaY5 ZJnoLJzwTxEk3R2WEhUriIK3f3sz0lhAqQwyi1vcSFe+r1HlA/dpS2tnfHKvnIuySiwvt4QyUHNz C8i/9ynj3qXEfGFJzJv5iowo21ERMF7ESPzotDqiS2kwNvaaYm5kbbeu3jFXBwDh8P6OOq+vNzqq MlciCkKFlzxS1DyZ8qhYJ5HaG7UzeicBIHqxpx8mHBDZoHxGvHvp6doWX9rr3BgyuTKOG7uA12Sq F4QemwTRUcvGhn5yrEb5cWptZU10SxzF56U8qwwMQ8m0kytYOep7kfIMBFs9CPpZ8ZRXs/A6vTbD Qd5K11JnbWezWqxHE93qm/gO8wznRHtHeo7zx8cihQ7Z/NAum2sm6h4pU9oUqnARgJwtP7vLcVnN x4Gh1IxtOvqcj+tcOituHxEn9B0iimWMQdvnkbjlvvdZDsmSX86oH1mGDmGO81QSqH7cpNP+7BBY 0CMt9+pxTSjSuxi6S3GcexDG+64FOMXs2kXF6OSQPQxPxedbpDrFTiMGuDicBnaSimSuttqIcWxj F+NeDqQeKC2V0/NIXaXU7lLGFtqHyGSW0D3qMRCCB7QXsSV96shQE8GOqiXCVqezcyVvt/kDMtPn rrx+Jg/G+7EbAC535A+pXqaY9gjF+0haO6oRlV578lnwlJnNtpCoxx0NHrfuNFt7YD6vTOTHdEg0 1UlzSrKRbtfFU1mTGvsAmYR+vTj2TnGyqW4qtztDaD0ZX+37QnENZR8VGZXa4sfo5ajtbtTDM0Gu crw+J8iVnuhLG0jWeCRzMXmS6yWZy5HhnchrTMJfKWuukZYVdcksKy8tr6NbVHPr8VnZlY94RBsf QWLxmZr7sRvi42aBKCMp9gbP2RVBFqIA5sx6L0mw4SFDGWlLzvTKvL0mUTx7FRZwvkbyepby0Z73 6WY/bjPoMxXHLGaTXukQQIwvPoM6pb+oNd9vbSsD3NR4VC6etoUb1mXMYNMcadoi7qOOc4i8h+g6 WrX6WjGWXD7jIWsFdYL2tv7Y4xXD822ObLKuFHOKRR5dBOzLr3K5GKdP3/wmxLil8/wNxaiqDcmU 5npjSud58U9LtxwFz2qfYiID9o4qtfKV8XfCHs9GGhjd6cZ1E67R8F9oVpmSR4mLx4B80gXKvL2A ahEgTlp7xJdlPz3Y5fQmOv2c5Z3H7in3/AMdUCQp0jSbq8K82K2DtNqWhBv217el/cK2lm/K84ho q0fI777SEuE1YgAMjXCEr9+xy0Cxp6viVMwHQzb2B3NQ0yKKlWVWncw65Na5JkNzkt9DjklyvVGP wLyNhc2WrrKrNR+b2XtuWtlkb6eKF+GaXmi9aw7FjtUE1duG5Ra8ZkNMVTcNjQlc7Ik+CObZu61t OGcaNqp436RvW2PQi2hp14DRwrvb9q233uI+DXusE2zG9In81iyRR/KXxZJZ+bEj4EB5dm4cw1qf vbS8nI3lMNAjnsQsc9aNz2GbxNqnOmvbrq4kabEx4nFbH3pkJFed9MnadhBvdhzl+isPPpHuhe4e +0fj+OT+lPCg1NWyVIehJnrjgyKO6QBN+ENvSqvjH8chwBchJ7oOdq7PVrPA1dWY5hVXKz1+lYqQ 7buXm2JYE6iFv5ZwNGcGBexcOmVgpNHPoR+88j1/jA5csbYueUDq40+WLq5V4cRto5qWpxW6f1fa Wi3IkYQhNMFaaXREItg41WeFrLg43KcyuiCBkzcbePsMq9sb1vuJh79YyXeFYmZzr4D8ArjSVqXk sKGnRPqodI2hFq/bdH+CRIn5fdCF1ahXmCH11583onlUJRRb1Q6VtwretPGaxTJWAtrcnHpFw2qO f/qIa4YA0Zj3g+kWMjeQyjbxLu+loj/vhuJ+wrNbz0jZSEanzmsNBiFh61eTDVzt+kN3JWKsf2Qy iq9LFd+PFt9qdBToFy4c4q661KcxGbJtp1y1eUv21n1ryA7xcxphWg0Fk0VIn4fDYdwcdbBeM/NB au5n8q8Plbi/sWhw5CibOJ1v44Ywef0/9ONTEw3ir8HK4vdquYn2Zqg+cc3eyb2LYmMxJ1diaRN7 kjDBF5J0n+ZG+MDCTTMI6fJU/t1U511AtYoKpmYAfeDOtfNGfLTLavyzlkhfgCTz55z0JSEzG3o+ 7rqiw3y5Qt9gqW82cbyv+FwW6ANIDfDZMKIYrQij50RE8x6U1zLfJuSaxo8m4er3uQ4lOD9aTKHD tsQ3y6OBt1r6OFNDypy6LjPvsM0m1p15Dgo+1zpHAdCL14WzT7hsiSQPecXdiMK+SJqrTTy70p/+ vd935vobKpGBxc8xtGmpyIy6yS8asvW9lzROGg8rfvAtv9ibbsVoHhuagEfA3qXosvd3Ne0jOycr jkUmuGXT3jlRN5r+pAyONuuMox1kQ2pg1B5mKYbk5qL5SSVcLlp1ZDZb8+xuV7OY7fjtPHbcqHd4 LSvBF/O85c7OM0CgLMtyrbnmpUbpyoJU4+yJoW3Ld/LKmOc+NFUM1vb0Z+8uflvmyfGJJyliZTWZ JXqHU9i76E68WN3e3T9vJur/QvYuvaYLUVTXSoOdNIsix55SR+ZhOsWjna7xLJaDAr6Lje7mTGaq VRtKEp0z5NGUxmPKXvS8PjOC9MMaX41j7uz5ee6RSjmF8kx3Z/OV0hAVOhu1xB6BjcopohgandSX n02qKSwolrut6xvTQUBH0KYrm1fujCYLOuv1Pf/ILid+p9usoK8kCELhQVH0zQudblD10/kIcTh4 KaIsiu35eFh/mV9jvN5LjwCNQTaI3E6PvqO1rME5sWD1hxZPnbXr2K5w1g11UMKlbnInytvlX4YX rzDTNN2Kgbh1uDkDaz+4fLtQ45dGVXO8YOWKsah3KtfkjymOAQ4zGdipr0e6fKWbYxh4kMgmVMzn dwYvWPs8R7EmrJDPgCLvCuUkP78cGndXIdzudS2E7tnuQaqDbE36Inrt9mnqSgudIoNM3P46LOwy n/NzMoyhc53u3NJDbfV4dljXnO49s3ZBBCPxaxoIvfJC6hclEQpbfQpOdTuW2wJlKb4sQt4fBn/O BO7sn+sYs2qYfXS/ZXBMEpdwZ5pxobRUGaAl+nVfZbo28XF3h5fYgkAgHXO19Zzf6lsDklaL9Ny0 WFlobr80YHmYvecszkVxAXMwfP9SXQnsXlYc9AywgjWx9amp5WZuR3BezJmQtIQXZZvKeDyk8GPY irtSTZtUhAtftjUQ5dP8euYf3Td+WnddOYJeZUjhC+M5Srl0u+PW44X2utORFtutdNZW2TFHS/Cd 7m+Gzs2TNqKTvfsYkuCix1Q000YOMSVnn47J6dTNd/K9Xcb7Rlp6zu17BvGxh11sEqKQ2QKLq3pm 2+p+V6lOQRr3+CrhzQPJIX3HoZf1jm99WRgRwzxhyww2HrC1SFN3WEGOdoOO3n49BuqzO1YX3TEl h/aoX0bm4RPIbxDPPy1lorjlXHxn8wZApcpa/XPfT884CVudOYaURG3+db3Jzr3R5HTjaiV9kUha LhGt6R/i1AL6nzbzzz9aT9HTTX2Zsba7QJPqB+MyZcg/HjO7z1KUuGrxFJJd/RT4WWkbuxa9n5m2 GZ9wQ2vosvZ48bdrp83c8q+6SgtcL25csrkziA7RfbPn0F9SEOgDWmWDUN45afBFFhnxu3inRXzw rlWwdNkD8/Umlepore8cVl3r/kRsy/rgRc+QaHFfXkHnpXdR7RZF16439nqnPvUH+qYWg4gi5ToV yVVPyeQoR6+Nq7vYgSjkis7i0Ff5PbvKIcwzvsP3VpNj5gOFJi4zerPUQMeu2G+28gy5NxPX7/an m2NZSD9fxNBSUfnZTRs2k/mrv3LKPwNZxGCGLolZS+JvnafNl9YodrWNB+yLDyX4drWbzYulcccG QVqHKmc+IxT6hKT8i11LeBJnWtq0yBMm0zd2bm7uNDtPAuYkx/xbDxJuROPTNjjZwngfrSNHf07C Ztb72XQ83eYzvk0rgvrmNWgxLngi/qu+jsJO9w/XqkB33aftP1/a5mdFXbVzN4qkuEFRVcP3WlVb Rk25hqerG8R0Dne8wnK1iPRkVyTOqXRjMJ1uUrWJuE2nqG3LIpz+O5ChU6vK+XtUQ2qFN3DKm5nu 8j25WpwotBQ2XRxEMfEwbexZ/pRHwCLg5LI44/Fkv/QK9XvcfD6qf2rDq2/Vz7IEhmOJ7xADdfWp SftSc0mKpg281IZNrIxyYt504C6xx5xKqw4TcT0IZhOpFJmHal6k6UmG9JDO7W8rq6vuuFRfpAq0 uQaBv5dZKIwYkTM1WM274AU10XLWuO8QSxGafXHB7mfSK6FnD657RxXdvEMX8KWuX1iwnLfx5tVy v3z5XmHSJ9jHflti/VTxihkl1bxYdTW0r9sY5/6tnax+t5GDQfSr0jLN4CkFl1cD5VDqH0HBk3cW OEWYXhH+45wHDz4ZnQZpSSUnrm3FKNbLPMO8LHnG+v3w6RhdBTditN8pOdF2vQ1so1MqIFUpYjit Q4oL2GQDDiW03R2jFAw99Ir40Tn1BhqmVnDqGAhLkkTjRUrwGS6DP1LBHSWPK6AxD3SZIUseRYv2 lxiYSN3rqSyHPagKdYj7OksfpOgaRJmOn9zLcxdaCzcaGCiZvrRYpq9EDa7GFTkt0go7GxdTyku/ oY4z3Mh+vBiaFHKwbGfUaNn98/76Fb5ZWtMPTfTqlWnZui2A+rAVDOdPamBINln8Ar8+hBndHRIo l9UQuzkm93Se4jseapJY7XKBVZ8VhGBEDZOziYIfKJ8g5LxLUNcTxWSCGSwHetjcSL4yZIivarvm r9HdjeDhUNVbvSggRaUwPRRW4jUyzuwk0beZYl3tUdboamjc0cKzRBS/bD6NgpdytvN2NM1SDyrm o4jL5JLjYT8QvS4ht+8oz9Isp9YAbLlNyVVao0kcMvdes5tIuBeCPlqvRwnZfPOfbkm2BfSekH6f FGlNvoHWz5qVqzOIbGNOqBBmKXduELsHoYkQeUna9j09c5utwqNr6P20zvcf1jj7hJ9bb4e+a7fq RSO82DeWm9dVH31H7CKUoNIa6gz8pTL1C15uic2nqTXCUtugPGHmDK5FfsM5zvKiM9SCKz9FVXIJ PxM4gQy+Mu4lC4V+OqmIpRXk3AqQjLX/8sjeJntRtaclM1wq0/m9w4vNtJBk/5jF6CkJSIvQA+rs 09s5rk0yZOKyWg2e6iugOSLIhJ60a+YKGzxLu+Nl3BFHtE9URVp9BM88kX+UBeds62y2UffgWoiK fZMA6VuKGLi604ZSBzO/zd51mNr3umsIPE1hDjrH9PIrO6O3WCqzqgfonKJQs6ZEyAyFWjDtypdH rE5DWQkfH6+2r4rRj1BqFux5eqwMrn9CoT15H3J+lC722AdJJIQ9W3S5+2BPs+K23I9YvjatNJTt dOlqWIiRhvfzdAsuCxk7gW/HQzpUMIaTLpxH2fdgyZysKfuLQOEUhioQuIGrUM6M+2bm23zJjjHQ HOyL1OR42WYSkf7MyQvHqnDqeUmXbQE1DhX+MkPXmg3+64Lrvsl3Td5Zw4psz3fkJVKHja5+92Ek 6/8klbGXyJ8HKLGy9a9qf6tTQ17Pag6MYtfGUosoPygvleldUlrwxe9cra0oVaG1CWakWTp+xbcU yKSjI6IhkOBvF2ZtfE/ZilKyS5LUiFrr9khkltwQMUUu4CYvDW9jNRb1DJ4Vm76e0YefGD2TNODh kH2w6pb1pLsq/c26GZmzqf71lzz2BztbU6kRCLD7Xu5LYIRCxfl1lrzbtEHRE28BcrF99m9MZg83 NGLqHZ93QwxmIO9v2d/mJ2KoVG/Wctn+4WVoShx8T5ynoW8hb0d3+gVR5fU6hD9NudjkwByJwFR2 oXHkiJqF1UMyVp3SaVtWkVZvvVBzwGzvK5R3sx67ZExJr+3tU2i+L83nnHayamFzU1uDBjUTp5tR OtZkakydpm6IFaDzTjNXGCdjyf2Nm4Hvp0kfgMhIgrwXAUn+uUjqOqXMYPbAd0wT3ct+Q33ejp3N Ko/4/AKGFKQWXRhEL6CEQ8u8n7ffNkrCNyJ2czUjYlUQRrlzbnR54tzOrrxd1dFMbCXPsNQLy4wT HL7YBilp9gRzsQ5Lll4GVqfAxyRz587vtfjoZpdbEvEDRA8ULGdKLAt94eHCPEOYl/odw9NFgp7O lRFHL2tRYaSV8geL0eCuC16z+Psp8/2SMmJ3mL3KR5VZI3cmox3ukdCMEXe9/nE1Phbyo75fV9zc 8JG9cRL85TYrihqTUsWxtLnG9/3DtFluSvhRqbf4zaUty5d8HmF89MogW0F5UofxsVlp/qNPcXx9 W21QfpkDGFtrga9YxvDGae5XYaV3RzfNZLnS8PGexSjZCxj9u9SqVP3XLg7VxV7GyI4lLs5k6oSX s0axtbt8eM1+mCFmILHJMZAFnrrlqFP4NjuT82CfBhqkL7Ign2In8e0r6bFd5FcqORPDBhpofs1n KlkrhoJ2p3DjTP+blCEDH+Lr4bs0mOmHJZwK5zylBUQOItNFzZfZv2/9fGQc7rh6okrx2Iu/nJeG 6ssTqnEbIT45mZcKJO0lMjg/lpWh43bODLAh1bOtd1JB0TOZjGgK95vjVix1pv6KDieBFxKmVqCy CbS5U+HXS0SoOiOU0DUUP4sZON5JAE8eJIKpjWc+XbvUkAGIJIsSuqU7FuOqawrhNzrq4J2p0MoJ pIppM7yotfLcxL0SaQNT5ZxtStBp+CqbMIl6bUJlTF5r9iz3Y4aZv8I24Id0zU01p6V919KTBCMO JutGqB7MeT0mUP/ULB3qUGeZd8FQMxzFx3EDNoHgn1/mqpDJQFOeRpVamfouubsnVYrueFkcALe/ mW+kXv+EQImkFDH2nXyTDZOC64z8+Bn7NqCDKG8ggXWi7SEjQ/pSqA//i1WxrxxnRAZMgpJv5Mfj EikagoazapaIl+cm7R6nPxcdvr+JymTtiXj+bWzo1otmz69e/wPGNaIPCmVuZHN0cmVhbQplbmRv YmoKNDQgMCBvYmogPDwKL0xlbmd0aDEgMjM4OAovTGVuZ3RoMiAxMjY0NgovTGVuZ3RoMyAwCi9M ZW5ndGggMTQwMTggICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqN9wVQHFjX BYoSgkOA4E6jwd3d3d29gcYad3cnuLsnWJCgwTU4wSG4O4EQLHA7M/NNMv97VfcWVdBr2zprn71P F1RkKuqMohZgM6AU2MGVkZWJhQ8grqiuzsoCYGFhZ2JhYUOiotIAudoB/2dHotICOruAwA58f0SI OwNNXSE2CVNXSKAi2AEg52YHYGUHsHLxsXLzsbAA2FhYeP8XCHbmA0iYuoMsAIpMADmwA9AFiUoc 7OjlDLKydoXw/O8jgMacFsDKy8vN8Fc6QNQe6AwyN3UAKJq6WgPtIYzmpnYAdbA5COjq9Z8SNALW rq6OfMzMHh4eTKb2LkxgZyshWgaAB8jVGqAGdAE6uwMtAL8kA5RM7YH/SGNCogJoWINc/naogy1d PUydgQCIwQ5kDnRwgaS4OVgAnQEQdoC6rAJA2RHo8Hewwt8BDIB/mgNgZWL9t9w/2b8KgRz+SjY1 NwfbO5o6eIEcrACWIDsgQFlKgcnV05UBYOpg8SvQ1M4FDMk3dTcF2ZmaQQL+OropQEpUFWAKUfiP PhdzZ5CjqwuTC8jul0bmX2UgbZZ0sBAH29sDHVxdkH6dTwLkDDSH9N2L+Z/LtXUAezj4/A9Zghws LH/JsHBzZNZ0ADm5AWUl/omBmJB+26yArgBOFhYWHhZ2ANAJAPQ0t2b+RaDh5Qj8y8n6ywzR4Ofj CHYEWEJkAP1AlkDIHyQfF1N3IMDV2Q3o5/On478IiZUVYAEydwWYAa1ADki/q0PMQMu/MeT+nUGe AH0WyPixAlh+/fz7yRAyYRZgBzuv3+F/XTGzgqaupqQs/T+S/3WKiYE9AT6MXKwARjZOFgAvLy+A m5MX4PffMv824H/i/7KqmIL+OdwfBWUdLMEA3r81QJr3Px3u/wwGzT9bQwv4L4MSGDLOQADN7+k3 YOFkMYf8Yv3/vAN/pfz/G/1fVf5fp///nkjKzc7uLz/N3wH/P35Te5Cd1z8RkHF2c4WshiIYsiAO /zdUG/j3PisCLUBu9v/XK+tqClkRUQcru38bCXKRAnkCLVRArubWf0/R/+4BUt4O5ABUAbuAfr04 AEZWFpb/44Msnbkt5FVxgdzWXy4gZKf+SynpYA62+LV8bJxcAFNnZ1MvJBbIhLFxcgJ8WCFbagH0 /Gu4AcxMDmBXSAoAIs8PYAl2Rvp1p1ycAGbRX6a/EReAWew34gYwi/9GPABmid+IF8As+S/iZgEw S/1GrABm6d+IDcAs8xuxA5hlfyMIu/xvBGFX+I0g7Iq/EYRd6V/EA+FT+Y0gDGq/EYRB/TfiADBr /EYQPs3fCMKn9RtB+LT/RbwQZPobQdjNfiOIdvN/ESfEZw62g1zg/yy/7pHZ4g8I6QfwdzyE9e8h +h0AEWD5G/5CoN/x7L+g+x8FfvnBbs5/5ENCrP6AEM3W/0IOiGZrL0dr4J8HhNhAf0CIWNs/IESR 3R8QItf+N4Q8Ocy/S3FCUh0gk/qHH6IW/Jsdkgz+jxtyesffbkgxR8hXk4Md0PJ3QzhY/7E6/6dP HJDOOUIeDfAfvYV8MzM7/Z7KX8gN6PLXPv17XWy/jGBXoIWZ3X9o2Dl+O/7LxMoKcf3RYFZIv1x+ a/6FgO5/NJQTEu4Cecd/J0CO+rsc5OFjdrV2Bv5xhxDdrh7gPxIgfXT7A0KuwP0PCOmixx8DAsn+ g4wNUt7rDwjR6/27aZBK3kDnv6n+83SYuzlDWuz61/MOeVf+h//6EgcCPYHmSEvzYHP+UJv60I7b OlFCD8bdcbj1zc6ot7oDkZyu1AsFPtYK8FnSM05iJhbVeKPpKouV4dPzvoR0Z7cTngY9OUFraTL5 rlCSA9tiF4yFI3dXPVZAEgswgdUkd3rU9uvzRFViNBN9GP03ydrzj2Hcvez7NXslPztd9vV4jwH2 gLIbdLI0Qtc40bzOY+gYXTLKTdfPugbo8RjO+hluGrKakz+hY0DxP8Q6YvHvvLb14zM/f/06nDM4 kM7+rUi+r5arOhwTH8tbjixvNGkIHzsxR67ZBYpajPNGvDKZ/Xy2D6pg9DPczAmKn5lq37Vqbrr7 y6iX8K3mOi8JjrU+ppyRKrTEIhDw8IGlaD0EzZie0Fh62mEqBpfa4uvTXo/xc/QtkrzpVC+pMMPw jY6d/THItgYrpQddjMFiubqfGA5Dt8tJXoOK84Dm8wUOeUTyNnGjcC3dd3OM2hvdh9sGc6fr4+fd fQQCOPGSNPFx++5iEsqy0OD07zUhS0Po4pba+4rUB7zaQ5JRIeLcgMOPb7NfcD6qvnBB/igKzXKl faITCzDl+GEJTzR4E17GzpVBXJ+KQoQrQXTQxXN2VFnoyTsbIFl47frS5xjJzRfekY+YtW3N/OOt dzTnd4Jko5x7mZHAWLYoM0+cuqaR42IR422RDG9EqzCcteAlw7UrWBZqBpRpsxerHWo1q+RZgI1P ph0BAz/u9cnpu7ppDyvq6qluNgHUkTztmL6IESscym/Gi9+Voy5mEHyFapqOqG2iPSN84qXcyt6x OiqMag4qsgJd5zvYuiddqpkzdljZINUUrXv2cJhjHGoFzkbC+jmeiabQUpnQBw0D+Vk90HQQWvbt ji1TPrWbryqQjfAqnCqjwmyEGBNWIJifAjsdrdMviA3EFYaGbZSXnvtp98atveCdg+lzO5wKvzK2 SoJQ9+oEWj+kjx7O20xKhYlm0N85jmkt0p039Jh8Ug8T8pUwP9HFOTp2fzUOHb3NSN/psbW0fODW gD1goU/mtxGk6qB4eZecfPLWjbeDH6qsCao95F1zpI1cReOB7ek7ulKLID4OdVu7JpeZPL8ADsSy 7ntEQofgq7jnYEL3zytS1Idaq7o8xDaZaIPeHsLfO4qPWPzOewNWr6lccdNWYTSSQ4OeqLL40x3Z VEW15UOduG+4sBpt8i3xl4UlcuDp6ri8E3qBH6/ts85ChRD4k2vCM3YJSxRsZI9vDC2re1+PmhhV pPGpls8SZlKfogtdK6mHEsbjQkc3zBjkSetqZTBcFxfwmIZQEgfasawiKUxcTf8s9nmZUxrBY6Wj 7+wqSLhLLOLrMuJOVG9gCo1yc0GQutORf2PWhK+dp6ilvn7pfuVgdI8XgG6NqnkhfiLAGLVWdSqj LNxTc95Ri+2qBuco8bQGflgyMhNwdDyStGRNgd846hN5eUdyZWX5eCzPqaDYc2KvvOy0X3oYwGdf 80YGjoRCx+B2hWXb4KEnSReQRu1lvjCtijPuJ7otPzlSprUckwLyFbLmbw9XvsJFx/KLa4n5+qRo PJj/He3cmytcR6pvccy4Ta4kINivh++wCiNClwwLdu38cXbjuSrc8sd3BvWKRKqml+3dT7zD16lg Pfyer/LqzcmlUU2OZSgEIcw3PDzKyql8wmVNdMcGmpGomVrNQTHM7hGjXixvlVetBttSbNKQBJIt ypJ4DwadVSUrcFh0t16RlQstH4pKqj2+30GDHXIkClt7vw5lKzdyZI6LPuN/nqqOvV2UijMxgfOu QTTFuBwrm4nMKeWdLR+byiNit1Xp6H0n4RskE2Bb7Uyex6ltmdOCjbiucIJR0x6IoD9aRzSFDvar Sx4tvq05L1Fi+XJQSj5/gbwTSXLGNa/V2TNnDYKQcP+XtOAJVyOr7x+42TwznV8JbzuwCXDSNB8a FyMaejDJfSy4dkFMEyEBdr+5WyX4OAey/JQsYMy9ynIlCspCJsU7NhvBWGnIyCz96IA/abjSzSuk EoaXkWfRVTuD/75RbFTONmuB4WeJvz7FJrQoO9bthsPpPdbt99wEgIF17HsvUjjdF+rPP474mClM Zy8jj/fmed5cCXzaFcJnaZGyko/6Xj8mh+vLhhNhB30UDHvyCLISIi3YQuUzyQ7a93ckWWsQusYq c+rqE/d6AWvXyJ01auKd1zCghHm9dHPub3h9FxA+foXrZ1eypZFI3F1H1iR7bhAveXPshLS7EzIE T7jCskomRgudLBa2XoMF9iTrjaGvYqilmoBDPjq0H0wjV9JFB2ZZc2UH4IQbrTJ9G6tIjvE/Quv9 ES+KHIGdyGG9zEXfPdO6MNHprkDIQnJd+e3p6sdaAe+MA0VVG+G7QmgCvWku2kJizH7sWYkYgWqm 5bsDDLdHNfQQpYdZenDpY5hyeuJrJa/az984svG09bl6I0gw4UHVMCcXRwku0j8wn1PCkhJLsZ1H 4sW0xoHR9ibOQqXfeQi11McCr3h8uIneT/i91DphHCtANPpx6x5U6DxJ/PakkJIn/gxP3+stp4u6 iojW8WBAkay+PZ3a2cZBSOa6hQHJi63TXmGdONjz/bjIty6EehK67141fhGtOxylHKj/XHK2GDP/ qnutmQcgSNe3fcsY/p422VjpYGh4Q/mNjeTbLks0pZwjuMwyg6KtZD/2sZrS4dnyPo2exBqPkCUT i9Xv+G71PlBVzrXa6V+MWOlF6Wim0JlpN7SRHQZ0ps0WFYSudlW9+tHv6GsN5fQkK/rGeCa1OsG6 p+EEffGsUHC2PTrV/sin92/EG5Krua69PRu+h15hOHpNS321eOLOD4uzGrEe9UaiXv2yp/D+W3Eo xeXrh/4XdAxc8ugDjlZvhb8ojfHF52I0F6CLAdekviBReyXfuOm85WxXMX+DjXdYiuYQNbHW7lNt ZJdu1YwKI+OORN4SpmNnibNbK7qEOyHJCTq5GjnE//Sh/QTJuMgBtnXsIju+4aSe6v08FNBPcYSL +EsKu25GrTtxNP9Df1v2D4oe3IR47Q6dpohvMsGV+bJfGArnhWhOzH6w4b6B7s9sNK7a9zslaOLn lpNCKuIP/f7DhXO5FPfnqpm7kznP4i5JrpJqqUz8gXVlUEdSQzAwxzYkLJvhsGrOiM1O3esLsIBp pD+t57D8G3L/Zc7w7J6u2viYRAkH+IZvvnVbB/UddkCrZYTuoZPNhGS1Hz+SSe2AGDeWry94Da2L 8L0E9TwykAKWW/AzVKsi9pifH3ZdtdJkMtdlkZ+tTcgTTOfsSvsGnpvmJiAYqyb0hvijaxlyI0Pn 8CiuTuqUamqR7HKuSY7NR1ycEpX8Bu/XV5UBX+ugsVpKxA9uAx8PzlRA6zekK5Sr+QLq9Gk7wCMn liYNPmAGCwd8sSLzm7oqg7ueqVeWT13rbq6BKwwfH8VNi3IbAt5eugz6ZU9Lop/3tlea+yi/y/7x gkZWC0R+a53FN58702NEz6107fp1kwglJugumCzSBVv3Gg9lsHLcVy6gArUpstla/NMLrCaNa2RX idwQDeGfS5JkJgKG1m3rcN278DCNalloJV6zpy9CPWG/j1LEdwxZ5p3qboSIGOc/WlMb9P2gXLfS zqwxzoXacSrg4J/UOl3Oxputm+Zqe86sl4dqHRjhb+XEjUClGE/HQrLJ5N1mfL97yfuyOo3t248v wx7sqq/fzb+qvC3LjZe4VL9oeEUwVp7fl2VmZY5X0i8/0+2DPilFDyQirOQYf1hy3T/yQh+991sz UO/3etsCmGelJ6UMNqVFmitRMrwiq6t6HlTF6xLVC7LuKBECw8HgV/grt6SdHSczAwgQeZ7aK3jC mjlf+NOFR/VaBnu+Lmt9+/QqZheH1/0z9ezh3fA5pXRnwEPT0pbUcUPuSLq6/micAkDsyL4t3i4f L+5oU3yhpp1yHxZ1/naaeSvPxIgcE0WPhMuAOkjqiXKTuR97Ll2YIFYwcxSc3ttgwJ0DfWJwqWYZ /tPe+/21SbXjfZWDRmLJbRflLLnDi6Z9rTahyvTOxAUJjHjYs8IYoE8vqz8R9+7BpvYrLSGSH5mJ 3TFzUyFP7Aibm3GXH41cbxQE5j+Twzo5XviWzTRgkbxr+BQHpz/1kU9UWLYHbJgiNzOUomiW4eu6 r6iiQ/6zhXaxN4/rCcf0ZejUDYAs12RL3bBeXCt1KGVYci8WIYRdC2SGOQULlAPCvRJEI40ZeUzj JL1kswkZhgGLEVBj0focYKnDHE+8DGUF7hRAp/effgPJ8JgeUEgCsjKta0zZedNNE6CFu8sKkM+G yV6ofT08SvPHTwtJLDAztes6aXtJNiHHY1teJjtFaTLMBIP78Txohlx6LHYxIEofdYmJTCjxm7hd rnyamEEHJz8l95Le4pUTHot2QwGqnkCNH5bRCjoC+qtH69NCW+YwVwQoTHAA/m11YZZEFR4fztvd x07LsiOQUFCCVAMjwSlUEEGQr/LihMnGOsWGPr2hGdzcru+UUPf5XnicjFnVMSnY92OObNZXjqyy g/1wTH5W/cQaFwkFwzKy5Cf2na7eLeKVi2l9jV0W9TI6GBnaiRmGU6/wPFBMjdw3u5ovGK4XnEuB MlHo4lpoUWRJBCmzr5g+3pu6bHncSXpyCoeyzKfGkquZjuMLcKOxsk7wNq5URp7S2F4smx4NwCE7 uPkkOVnhhToDv3gcEn/MP38Dl0TT6z5GCH7p6o8kUnF3wtqtdfGpeGVadpEhmaX09Zj5LZNZ2X2e 96mHI0ZwO6zp0cMR8hrUN/Fz5wuBNMNE3j2UCxW/AySFiLOClyaAVo6bvIHZ/JRLRzpU+4FYf08m Scy+gh+GihMPuR6qonQ7CHJmpxFt8LQpk2mqKMGTOTlrt+ntvDPCycX4aJ0+wtzIVBzo2ffk2x9K X2scle9It7/nO7NJgXJYfOpIFu+Ox1dYDAhXAGU0NMYwfi9fy+UfqGJyJPtQsMuWlXh+HSmEPSdI f8vSMSKr7D0FPeiqm0ewkCwzB8NkWKCJQUC6WdLSJ9vuliYf9IF/jcXmak2ok7tdc1Gji8o2daEp OLgM61rPztiHBk+77jIEVKg9hiK82UKkp7ubMSIpJCYxZyg8csybHcy2pmDVkG4cj4H5atMunGaE B18r7lSINEahMM5e+EwXIJXxXvXxp9BIYnhO8IkSsaCET59DE7/4axaKlMUxbaHGt6I15cxtb429 zG8jP/cTyYDpv9J1eQnCPn6qyASpZrPjDVCN3dCx86H1AKydNwq9QjV/sigtLYDWZTL8GOMT60vc vwXYJvuXf1d7yu7P9wjJNEHBaI5NeTwWwFm0WTo1jKxUuVr6Ucv8goYWX/54L3PYkaIXq+vKxSHq 0kPWHoPREbrRhXNQgKA8mSK2y9o54o3qBoFWrTz+tYrigaAqJ2mQBQJj7bSHexfZnfBOGAonwYam thX/eVf05LcHhhX9NabeuXah4/SqHKtcWYbUWKlmZjqtILYF4BMpv40e1PrcrvgOlafAjSzfIpb7 E4JiWkpTLKB7wLZapFft1jIQmCvnptxp8epEt//4Embrm7XtN7sqSWi6GoYPz8XXvZEIMCyqMYiC vP75nTXfmS4Ln6R7Ug4SUUdvOKigSQjAdKOuVXseJMbtbfgqWXp7z8hemrFiMNb+lS+XDUlJI8Ap CMQF3lIwIyMG+qTHiBNAlrw5xHzsbCodUpv62GhkHcoQGo0PjryI0TBRi0JGiqGOiHdp89uf9x2C 3mk2iXOmMdAi5+8h64dXi0f0fkKP8SC8Y0wAPK51iqHRf9PqZBJdPlt1O5IbxBB4mhzsvEkUw1H3 TCewJb4nsOT2V6ukNvIIX1+OWl9uD2MPwo2Q/FrNxuWL5X5dXCikNp1878sxVwmONse4fXgd6nHr fyjjjCyXGxEMc9+/ga28wMe2naef4+zvxx4w4yS9jTP4xYyA8A2WuI2SpNMopjVvvyRd1kda+0aa qB8uDGRNSagrtctVZBJSSJpSZyn5Bz8KH/f2Fh/oX1kaVYc41ZIyH2fHMRG1cCUQgrnuoS5gDr1G 9D1mjjqgDNPxyeNbJQK6ZySqkj2jd+FpTCVwbIaslde/pbGMZKbP8eosb4tGUT1fHzQoUVUUtZM3 VXPHvHhzhbjHqEo797Cysb5YyWpasZLaJiThXMGauIdhLxehSHEFxfIhOJbmflpigPGAdQqXpYvk 5LhB/WZ/Dr70mWRO5o2CHL88ki5OFlsu+QLX67laU4uJLrFRVIOdqR1Nh9tqOJ7lN14yzZHNPtsS Vg0ojWe6oBNKLIQKMQYmmOrQ3Ba6sLcg46rElXAFtZlNGJ71gLVGKczhXEkk0ULm86is4KNapONb tBKMJoPBuN3Qlrem0RKae69hLq4DGTrwrh+hu5vLn0nF2Otc8MbQJKF/ZPcl3LzkcGsBTsqjy67F V3zNe1TQYrj0avu+oDLFTmkM+9Od7lJ0tffq/F0tMVQ87sIsqc2ZSx/FSBtVdTYqcUIqpttEEFUz 9SWC+aiO/EP8PInb7us5hP6JMp5X3xLr3l1Evw9PVDIa3mGRpMLP3JKc0Gb/Xg8SqOJrVq5gUWqS nUVZf9AnFxOzlxW4brnQg9nsabwfb+jVlPJf/F5MOBgvbmuZUPLGmAEWAGZ/C71RHKzip4EA7WiI iEw2rg0n8RWuAc28XjWqAtn0RvTglEWwFV2RsXMkOqx8nZfTLaa877w5DWX3vql2Chw3XLOnrN0d uai+KX/C1dvtwZdd32XRUoH86KLnzs6v7kxzPRKxKEjdSUmZ2atqkeP0UJLTSYFKUL9YcLYDbqur SKRNlqNWXaTC0zCO4hgfIVEjl9nA1UXRn/4YOa9eyfVz2Siu6NLkSNzvhJGiwY7VKm6sAi7Plr1u iQ+Rh/qemui2uEjzVIHn/Osx7YMkZ0GkmorYST7s3pdryH/Yhll6xMlLVnae3n2isfVLZiebBE2V R5LXuRNgAJ42WwCfRQtoz/Qkeb5VO5Bucv2NSqJ3zEr9QK2x4sDPpQ+J83ALR1WX8Ee4g6WGzpYM QuLMvmSH0mTZlQxeSGsSISjiTvFCC1Pn6HhbNNmh6RcZH7p/gtTCItc5Km/xqG9Wx2An7dwCU4zK sRJw594E0pJMq2MKKx8arKh9dInF8cLtZN3l1+Gt2KtzhVHJ20gmWWTTIbC+f1Xn0nWWYtZTniga uvysUuN1NirIMEqxLgBGXOzZaifbbtmv6iG7iv9JbsGrc3p9wafJ/lORSuDuViwjgrFra3vwHnk8 XC+0W8PQwMxZfPd2c3Pak53qWOjG3uGBEVc0EI/oOZrw57CcXSW0S0VxiBRrq5JwBgC3T97TFxbB ak8Qx0p9LPQDR6ZxhghzQEKhD5a1Qfb7Xv/CHY+5okbrH1Ovq/26/XvHqh4GjImOL9rVnwxruYn0 emYXD+6NRmWpUaVXuAHYX9API21tWziuojcpzShIXLvRFZZtPXTR9nX6XWXB+MGCi04vraYvFQcV EifFiwagrDqlw7EOAVQ6VNg8S1WYUPCCNxQIjRgN9FHv48h2FrpIgHbf9fPX8c8zy/poeh7DDI1S 2QicWDX8Ud7CEXp5T/Bw29fVD3/qdhVwmhClaAvS05xPgPmuOFTjMjRe8DVXjC28cbFf4tPTMYiW Yo2jvFvvaSwiPE7awDgQu86gdefzSaEbNfTbxbqHsjW/r+IWgAXAKLqYGMbRW5xiKY7JyCihLvXF mTA0Kdu0ozyu53sGHrehqMkylSN3D4yiGCPRcCVWkoKrS/FQdIyOVB8p07KY6e/UDIKLoj4FFE9D RY/O5/A6k5LPCO1Hxy0w5x+bGvYr9FRs4LwkUJgQFc6X2TB1L16WVVKiMfOH22NtB2tlMQMP9Fb5 XzEJ7xcUy+/C4pxydTSHNmE4nr2bMWhGYSzlmhhRGwrBUtAASMDpbQpizCVmRGrF7ZB59DS9LY77 So37ulZIPx86f4uIbmfl4U22f7pPpJxtwGquIh9jSuB2RkXNdGvlzPo5fqQFpT1ileTo683mY78z CZ317kn5uKUJZ//W1dun3Yg35yXvvQamtW6KAxBiFKMnPhOdEyLhUnWk1En0au5BZ11Jt65S25mk 9JG3WDO3RmYIrALf+m5h6BH0KkfJ35/cQ9teP+E6xqvVO7N+7rARLauZkrnUcjR5Vc/plhgvIuAw OUqcGOltOqJTbVj8albJjtR7ZJsaHouNZJC3YEXBXbn+jZD69U7M40fPEMIFhpT2BFlvb5WvgYSU ua4ueifomtYlTHMJvUpVwmQJgKmIqWP3o0fje6b41KgTKHAwR35Gp8kXMX+Xoxz3aNNwPLTX3FY1 0bUsR9xl8Een73ZcqTKH6sXXv27x9U4iVVp8+jjdJDIz51r/U7CNPcKD6dTo7maQTr+jMg7nSdTL XH2oRQA2PB7zRd97wkq1BZr2QT7+EW+0irQSsls4mCWmd3LwaERaqkwRgbF+Qz7aYkkt0Ld1QT4t JhpY/VuvzFut8Mnruu8pKUeh2C5TZxcpT9aeJDxmZOoUEy8XntEHHZMdhNObpfh1JZ9x93vYilyi Tqu0iTVOyxe2sxnx8xsjMtvUZQziHWZNE3OcdswV4+X2227pYBtwBcZTMn4udngfrI4KxgqLsLi/ B0xOqTAEAjA+Qt0Yxt4K9TczxFVmG5CeFHSE6vkKXJXXIIzOXPO1it3jfWCCElmsym7KrDQiJeJc IkoAjb5okw730L8i6PU6lnNADxNnT0w3KRMXb2L9pjsdnrC9Er4wQuchAz55p+V1tY1oGenMSUZP rmOsDVxj0US+lY0IwtOTU2T/rrqpT51azhpNWJsUsBi3uPLqajZPyJsqYQmjwkmElAFBmShzNSIK GshKXyRSH/e8H0VcUdNeOixJfHUzMM3Q2kZRROARNfJsJ80/WNBV0HX42v3+wjUY6LqPCUvGZre4 xU7ufpVDqcOx3LqGkzYFGhP11ooWYiGd9C36uFpLB9u9Hx8RVlIKJ/MxtEypzOiEWZSmzkNusa/9 nZZGSuYPNX2o18wvuHwd0/U+4fGKOe1qJmiPKdsZiSIz5Gaja2zjKdkfhcm9bSn+0F1YXcsX6yJ3 VSZedGI13V0t8lN+jcs4r1WhJeYZHa5pfq3ZCym01pcMGUfTztYiRLANkeSAAueTVo8VwJIanZQh uo6rqzVXuTde9IEqZJSazt9ANXW2atVSCqeGQojk2w93GisUcul8+UyZCJEKZfYuhQ3LDQsYpe9T i1PRYG7jdP5XtK+zni5U5xmqTGpOkODOtECJmqOeHzkiYmmXu5LMM4tW2BEoPmFHUqSHw5xwHET3 pZrYSC6nFSzgCdotmTRTZTg/LKMg1oeXNZws/jSalvM+z6s/ZXkz5WtsJxLk5wlcxyQ4dGkwJ0b9 oiZF94XuyvLb/KjLnDW2Zl6bYRiZF9II7HeVmxMaye2dj6B85fZAM/ZSqkkNmHaOS8q3qEmlevuW 4ws5tBNSp4nQux88KxJu0bOGaBU0sddfp+96Bwfuc6eKGHNdb/vKcDpLCFZ2TaLiggJTI52dNMTm xw3HxwtvS9/MTOi/rpY1SyS+l7BOHCHnd6gCJHfnAklXYxt1emJpF03nvywkXbut93CfweVW7tqV auw5ISBoqbXBtkuTaqjrLHZfv3tAuleZ8Al1oz4C5GcoNiG/bVo/jarf5ZUnzchznUtzBQoQOHck 2D7PP/LavNBF/ooS70bZrMKZ9xWD6oXWTXPOBf3twHgz7ok66ydKXM7zVVHaGAJtqoY6RdR3UIk0 B/i8X9zvDL04dg+yG5Aa56e1ScQz/T6FJmXccmbCVYm9Gijq2XDHDL1jX5M/k759LqNOBXIMrNQU wwtb3qdF19Mg4Rv5UDZi2CBw5m0o4lG6P7u9O3jLrHXhO7kXXQoOUOnlEPOhvF+lx012kyAR5n+a TJG+1+vU2qiJmdioFkU2jV4q2udSYCGUrUHSy2R/8wrFXBM2t3VD7DRHihNgSzQcR0qGKt2vRPFy UctR3j2/hfneRXlOuUjf464mhOLUAcdHlBdZzxKdrlYvvD/D5XoCrG5kz+JcOubAbN5wllX8YcwZ GfAKreHJn0OUonhtevkJN+B4K1I5OXz0kzs74wHg0UT3cQqfpQMqybIDNNgG8warLMUdmRn7VXLe eE2M7YFS2LePuxT9tDE2zh3QQ4mASJoTG2XBQfW23OoPqSWenrMyITgMDbqLGuaBrMgeCzlAW8Qc vOKE0TsnQUdEWsOeDne11n2gtMBoU33XMYy23Xqc33c19yrgSLVA336GG4XYtncRA6ucYUhqAB5D TQiBNjHKmVMXokryIAH58xQosoSeuivN+nXXHNLzl6eF0bEfyjwtQlCij5Mer0+WN5owqA0StGIy UKceiRnZN4dWcnDIWZNc2lc1hg8kjXoDggt1vhbrdrmVZinUxJsIA9RFWKXOiNsXXuF7Qk2ZUxKW J6wxLwjjWzRqiokbVMZqUIXSliVX5T3NjXM1Tkv1c2ErkJO/q6HPicFMGk1FqJ5eOv6cxf6JiGWi ezpUvVvWXSXU9HXz+HHHGOHkT2/TujXjUTnRfa0oFiUXB5cCWJSE96cbmRX0jqENleYr1B7UUvxm 4mLsN1XVS6sUrGk/uH641aW6kSe5LqCFO1tAb2/dxuOYY8zA3mB5wmu1G2h82RuWve1qhXvwQoDC 1nolrEjdBI88Aj/DVomCFidZWDo7RzHoezvwnrbHrrVYKwrLJf5IeMjMutnbOVTTpW++8pzZSrZE oVGRJxIvwCynZZMiPI1laO81p2k1QXXci/5cEzCsFjonWeMc98CbRlEOclg4VNka27PRw8n3ik9+ jX6WpXEDdjQ5JBEX4JpUDdPqaul4MqUGfvfS0NAgMdSJ73ME1+ll72q7wboubqoz3+vyKh9Cv8aF LwRQn9DZf/p5wbfl5CWYr2utY+IdKlWvVmJjOEOR0LDIqhuDrCtgyvYB9scKrN8Tg4Dtys+QRq6f YI+XcLsPe0qT4qJQx9j+b8U2nSOWUUO4izkOCjViKCuWIiwe7EbVqW9gjDZfww8iHXGZwBvB3hPo 5Xx0iKSThPUiH6cz5NeiVvX60a3VcoQLq5zCOGyRcWK7NYrIyqsOTQqGSTCGD8ba+GgznF9TSrVD o12lYfNk/vglmLm6ru+TMHTTUhXzsIr6yyJM3A+wdoFtYcYTih9Akeg+sV0Dcm8ab5cnozEzNLaQ k4o3O+93KjQcnUI2BYVO4M6BKFxHKdnYjGQJR+0YuUZgPOJufmWznnX5wINjRJGozNxGoWjyWH8X 39ouc2iV7NvGQfpC6VibQKcNSr8CzJaH+dETv08rtQ+6rFa2D+Yu+rAbBPk9J3l66lcf6EqBUy1n iPRN1HYd1rpMHjEe957H2Gefr4xhkxUSGgSisTOXiT9itsYc4If1uZyOuOemwGTn4jykDO7GUHRm ishS4nipTq8CjyS50hQpXl94qE8xqPbW9gxEvMw+Mbn1u0axz5PueL1l2LTJRvDolp291ItrkSzh mUga0ZIQx6dFvGCeBwefk7tVGihiMIyEY6nfhfLYUkXtfHn8mq6Lbyej92VNf8g2Pz8ruTlVkW+9 H5CaaSfZMGzLRT4DGyaysZH6GKFK12FTQQqzRuLt4nP9KAjQSvsC7+bnO+XpNrCZXq8S7ms7p2SB nRSqgayIu9uYMPah8yr9gRsKqYzrp2RJsdHqGSlEtcecGGYE6qmsXdBuzJr1UQOJb5f+HY/U9HqW LAlT3nyNSbmlZxmc+wcmiRkU5L65Dr75Hrt9Ppyuq0eL/mj4fDH85ZZHYP2CBTQ7xuFuno8M2yhM nfDwQc1BoPqUrB/38WisCFQolk4xUApZrwJL5PhnQYTFDpHu8KqsICuqRLIeqmSlwhGDmj7V5NfE p/f2YrtHT7rCptVRllL4tm+iPIxpPiPh6IRRj92kmrC+uDPRt3HOHiDD2LRnlExrpeaZVV28XhyK 3lDhPrEymtKZtsrY2YJdZMXwUOWAztmDo070Sl3kM8ariiIqMZjBQX9PN/HQnIWbIJepwG4+EGxw FHZYm91expLdYxWIjnExFLQbxGj6A4pzkOYOevAjl2xxkLlQ1x3upxifRX9zHLzrOHOhZpyHh5tj 8+5xWIP0ZFzJnpJNO4TuhcWenogwB8Ond0bvxFQnbanCitUX9jW3AaOt90uuXfef4slXslKIczr8 D2TtLQ+2QZbcQ+U/wAmDDbd1hPFrWcRhPJuvkQMU3abvYc2/31lNGu3HVxBpueqhT0/H0PWrkdHd fN+icWX55EBUoR+66c2mkMRvBwXcP/dipxQ1UKvSvtp6YrnAxzmb0ZJwjTw+hcbD3EHj2D9YT219 2CaS6TKVD+Hg1Qtx14ainaWqWlxDM2D5vGCyutULT9+5Kg08194e0Wu8/jQvdjUtUYhtDYdrl+Zd ZbP+AVHwpra87dWlYpJakhG+C1Sb/PcZ45JTFKuoIrF4bA+1x/dPziiypwebXITtNGqsp2/XWGMp /EiuI+hpuOzFCFF66YxwbsKEGoobUUeCC+2AxcwunxvWKrgNwTTzg9TShzdDBzUnll9YgMzM9Lfn Qcuo6YsVDaf83FLoLnoSN272BoN5YIGv8YkPUl4iDIeaz4yt4t+WzZJ8VGvaTx5rqNkw6wotleYc k8y158JcXXn3DWR2kox+cCC6fJEuD/4+xAaM+EaPWug2i/opvL9WFOHzq8/I30ZK9D+IumgYf93K 5/NHn35J5BpQ5kzFASf3KbKfsUV8S7uyYtRlfmVWwYf6CsZZVwXYlVHi+KrOHpaKw/CW7LNGdtk0 100eVeuek4IVsXpn6wNW5vPhiz2jz1jESqzxzCDRszezaLa6cFvF+Qh6Ah84mqcxU9jESw3UXTH5 pYx3y1QvCT2qdL0tZ14GEBMP88fyNHQNaWlv7Dn6ylyzO+juM/PUp4RcxjCWy4ne22iP9MDa81Au xv00wnwzLbAc7W4Wkn8az/J9/p1ZUwU7S+GYjaZcPWpN6GfheYlEd4ayF0y1+F9zsz+sAzrZSWT0 rzukbA3aDik1VHzaGoPTI0mPH97jp/plg5pV4JT0QsFq/ozt61NwyG7OvBVSDzbhO718ITIRyKWS bh+oVnF/tprG6moK8ouh+lIZp4TXia8o7xtaCrqFzvrQwMtpbHjqzxHbo4fZPNjp7wDzK03HbXHD yy7qooBt8A7hMfK47jrQwB0M1dkrq53Yg+Q3+KPtlEQwEuH3EnnQAXP6GIUu1tyYiC+uk0pphNtV vKD3KbQQmaWiP2tYlhtwzJnqld4/0OCSvrSjhp2+XOXf7+XqZ1wf1hteLvUdJvLvOqzt++K6Cc3T jLBMBEJhJ/iGGPS2brqyQiovrO5NgVmd5lnJcHksnGJOh2M8S1zxkGg8iofqgzxNjSjsUZBNf8B9 6xLZYHIDOhRsElzksRMbCq1wFh9NasGq+drIR/JWAyaSvAabNDEMV6anQKuVj/ykuATL66vjufIx WUQBppUkClJad2YBz4NY8CENjZoS1lMmhDj1YdiRfVbHiaJJcKqHWyVpgbhX0yIrQzi7r1ZIKBkn d7RY1zVWbbGAAi/jC15xu5UAw4pyD9bGTrFFEHZTJs4m7m6jmd4jaDn3oXRUIuqnv9zmiCO2Vdju tn5jSSbAAIXok/q2wqQNuh37hfLjR7LMFt6TEdef76OKJsaV7RmkA8WQ5M2a6RFPXrRh9JiHW3fL 0xZh21XoNUyr0zVsmpDABJ6itpKk4Hw1hM2ImUKC3gvcfzk0O8DC5W0QAGWcEqUYlaWytdGAif+q xNj5onYOHouYRqh6sZxG9aw1SO+9QSefTlpQnm1INKD67hlevCdCcY+OlWpgZgGQjH0n/RnHTWmA bXnR4kCFFtMBu50Tui7SMNNf3HuzIzFgcgNZyFpf6Njo8qvbnVyIB1x16kftiNWZKo6HfEI/zG1u 9ptRxOJaW1we9m/WWtyS+AjUrqFhixranaFOBYJaT77OwSgCkH9doW6ZKL5jk/GGmGUOt5/61wD6 Tx1p6OvET5/ZnOhnxinuHM9DikVGRy02h0XPLVpZUtzEzXq21Agz0MbKeOa7yg7gRN7AjBSnJqvL K/su67/1yHysTLeOgbMzTEpaN/l8mZX2uHd0qSREJKvslJQ8VXemQ5hI6eZHSp27Jv353UW7wAiA 3tKaNv5RxPzFMpfODPuNR4P9o8wTktjIApOMIgNrUtOHntCyNRetz/NRJ7WNtb1GBBhr0oFAZTbE Q7dGmRDovIHKm8WjRDbBSkmjjc/lno3+nh6GGzOAauyE0YzasBWjjj03FV3vGBFjCkrY9kBjKU/N 5XzOz09h3iNEjxtveeQNdGYotdQijXaGnmVvv7rpkcVMIMEs5aeWDKni7Fu/Gx4munN8oFPAq7UB JzsmVWeJdNCrvLe6e2vDxHCG5vIUeuYC79sSLu8i1RIreISCwLrCTamtrajH7zFMFktusFIdr6wB OFt2Eek7CTZ5mvlaf1EtmAo26Xlx45mvEnbBBEDotdWo3KBj4MwZnSrd/LFYgOE2zBvwKWZgVtQB L545wGfogB69fK/8Df/t52/wX4oVKrEcX6i1w/EfhZmIw5AJMqOM7jryuW0uDfSbECKlR9/KS+hm 2QnHFAJ1zoIt0iN3zG6qDoIIaTIWo0qDkmDK0GhUCoXOv2+dyrqJjQgbU5d8F1luf4Mn3feuulds sEen2ZDLXW5upjrWeBzAnecLRVz6Ht0xeaN4DqDjPsTi+TbZpUlJwwr5wbKKpFWkNJWwHTybKNmS YD7avehCnX4QavNW32i88ZydnLX+3YGFpoKIuTxB/RXBjW6G4IBJSGplb1vWS5EZSp0kJDuVg9AF 27xPP1JJFGo77RXc54N4Xt5Kg4UXJpdJiKkXjivG45gdsclmW8pzThx/gGKdWEW53VM+beSPmYdb HkrG0JX02Abrvkdz0/w60or/3pUwgyOd/koBp/EOzVhaZMdpR4mhE6sITauoKicSWK63w9E7A1fO wFpXhPQthfuTduPI8DnDYvKzXvTgzzoVbu5UOGTSQ5iFJEfgp6oVO7cKRuHjJX0x3y85wfDQOrfR PnKqhvgD6PxkjZwhtcqCUF3uNF9kKL/Eunch+CDPaugtq68oZNF2n/LW3UsGedJRClzhbL+jV1N+ ZjEZlerR2w0Tx+mcJ8HBRDpE22/AqE+pAomVj4RdiboxtwV6GW49i5+xXaShJyxwF/Zv91LYB/1c hCX5FKak5r7RtOnHmuV/XO6pMDzPENkN3hkV8Yf65CmI5c1+ybHPe4bZs3avsfKDTVRXz6TGUPjF Iu49Ef/F3Y8+Bhi2d9fs0RucdijzhCRXJeFdIHJTs0A5Bb2vitUUFjSSXD8lySTblGHvDzO6Vuyp ZGo/qLjQmn0f3xHXNilECDZKEl077ntvI7ThNB96VQkKFLtENqTImsGJ48JHg2sbVtJHWOmEee3A UuVHvvyhf+FQ8nFKKf6gvt+GkfquO7Pes2iiux6+xM9dk1PTwK38ZCsJKoTrIGZHZzn/3VqI4SJR As2ZX+s3d2K30I7rT4roTpfNPrcOZASaFgJ1k0cGb9nHc7dxNr/taRRWrXUykfq++FD2reLccKSN 5NC8QumayC+z+br07mJGSxInAgbALmVXMlcX/d67uMTQ8kqFSwsnfTdtY54OumV+NXOSt4Bvtzk/ YEBc2lo1aPzz1XEoqy1p4BVzMXTzSfyYzcypGVtiICh4E9TUrdUgulbRjKy2OYWVPHfPRFkInb/f WxoyznTJIPFd7Rr25acAoUrSD5qR+Uyuw7gaO/P3ZHDrrh7N7uYglrFzj/n4ugn6VIcuim2XsVz+ /rzD6FUva2IBnEQFQvvJWfnW7Aptssz4bkazZBzpjUACetQgLjj97669Ok2mk+rpq1Ah4OIzqGbf kpDNAjCMXj062nOWgEhQ8GwlkEkqSIUBnuSQUv6C57h22HZd58cbmajx4iH8ZcYshyGaYAJ+QqIQ DrtxV8zOBJBKURDv5+eXyGz+1uJhJM8rGLJl5Qi3BHfvuao56gl1Um7u40ZsQfZH2UE3N94x+Td5 /vKvq9vY6uB1sLNaMZ4UYXaQuZ2dXnydMNrLIVVRjk/IRkDlggXLC11ySv78blDIvvK+gr5eFqWt EwnuaC0Yv6Pr4sm+FRWTT/z2fpLBsfalqdtKWvFnXc2kcQpMUIU1ofEljBNbk4QedSXm43o9pUjp jqUw+8oYeTO6xbzi2WS/mHTkcBSuNhtyOdXA0VN7J3gs8QWZ61PyBiK3Ad40NKM7ZQhh6iVMe6+L /gJuQZg5kptdUTrZvOciby5CaE9ZF0/ryxK/NRKbLyNOmjzxsiBSDymiMDezwGeyPe6RGOpQhsaa d/XUCpPQTu0hIappOH3iR/aZhTrCfF2vSlyUpr2hjptVVv0nW0AJ+4laNczMlLZa7+p0XNme9moW 3H0Jk1RA2y5F9ZL98BxTQ57lA4FSlSt4zkYymBvawdYdOAlO8Cqava0BTA53T9SnvkJc7AGDqnVs p5H32z/1dDNY3k+I75VJvBrIlujbMJEut+zekko4wA9NvW87XDXkY6G55ox2UjzUv8lOKL15KJzT J/MeiL1RLXFVoyM4xZFPnk7FFc9QQU38IQLvixRUzzTccZNffnMqUSt8Fs/63P5oWvP+xgP6veJO T161x9k7a9FkjIOQxcPXL0Q7R3Lv2UNskgnTBfOIxYdPmD88c28kLymuW39bg7pOc/n0NjtMnEG8 P677aqTY1xlmVw53goPQtkiL896pLfcQSRAsPaTMdqSGuI9GXzOKJ+0Fz5XOOsKdGPxFurUav6wq j5gR7Hqt1GI6cGJM4klgtfI0tCAog3Zsuyuh+BnW6WVxseSTJTzqvHPS+vdXR1c67g8UXeB+jT5M tkbb5M9Ay3ZV0hZpT6jDhhUp3s8vah4sV282RhBEsltAsIQBLtT/D/guh0EKZW5kc3RyZWFtCmVu ZG9iago0NiAwIG9iaiA8PAovTGVuZ3RoMSAxNjAyCi9MZW5ndGgyIDc2MjIKL0xlbmd0aDMgMAov TGVuZ3RoIDg2NjQgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjajXYFVJRt tzbdJSENQzcMIA3SLd3NAAMMMcDM0CLdKaCESIOkhAqChHR3g4g0SDdKHfSt7/3+f61z1qw181x7 X3vve9f9DAuDth6PrJ2bDVjJDYrg4ecFigPkNfT0+AUAQKAgLxAogMPCog9BuID/kuOwGIJhcIgb VPw/GPIwMAhxL1MAIe6JGm5QgJqnC4BfEMAvLM4vIg4EAgSAQLG/iG4wcYACyAtiB9DgBai5QcFw HBZ5N3dfGMTBEXEf569HALstB4BfTEyE+7c5QNYVDIPYgqAADRDCEex6H9EW5ALQc7OFgBG+/3LB LumIQLiL8/F5e3vzglzhvG4wh8cc3ABvCMIRoAuGg2FeYDvAr5QBmiBX8J+p8eKwAPQdIfA/FHpu 9ghvEAwMuBe4QGzBUPi9iSfUDgwD3EcH6Kk+AWi5g6F/kJ/8QeAG/FkcAD8v/9/u/rT+5QgC/W0M srV1c3UHQX0hUAeAPcQFDNBSesKL8EFwA0BQu19EkAvc7d4e5AWCuIBs7gm/jw4CKMnqAED3Gf6Z H9wWBnFHwHnhEJdfOfL9cnNfZkWonbybqysYioDj/DqfAgQGtr2vuy/fn811hrp5Q/3/QvYQqJ39 rzTsPN35DKAQD0+wqsKfnHsRzj8yBzACIAQEAkWBjwBgDwDYx9aR71cAfV938G8l/y/xfQ4B/u5u 7gD7+zTAARB78P0Pjj8c5AUGIGCe4AD//1T8G+Hw8wPsILYIgA3YAQLF+cf7vRhs/we+7z8M4gMw A96PHz8A+Ovz95PF/YTZuUFdfP+h/24xn7KprLaqCdefKf+tlJNz8wH48wgLAHgEhPgBYiKiABEh UUDAv938XYC/kv8t1QZB/jwc8B+HqlB7N4DYHzncF++vPLz+HAz2P7eGA/DvCJpu9+MMBrD/M/3m QCGg7f0X//95B36b/P9G/5eX/3X6//tESp4uLr/17H8Q/h89yBXi4vsn436cPRH3q6Hhdr8g0P+m GoH/2GcNsB3E0/W/taoI0P2KyEIdXP4uJASuBPEB22lDELaOf0zRX324d+8CgYK13eCQXzcOgIcf CPwv3f3S2Trf3yrw+279VoHvd+rfIRWhtm52v5ZPQEgYAILBQL44wPsJExASAvjz32+pHdjn93AD +Hihboh7E8B9egEAezcYzq+eCosB+BR/iX4jESCAT+kfJAjgU/0biQoA+HT/QY8AfPp/IzERAB/o H3Tv0/ZvxH8/znzgv+H9Kfn+qOE/BCEAH+Q/oCiAz+UfeL9FfG7/Ae8Dw/4D3tvC/3F+z0U4wsB/ hPtXoWw9YbD7W+T3MN9X8S/8+8oCg33Atjhz0262EmFOtWFNl9Wy1N4860MYS8st0UkmXVFCCNaZ XH/HJ5iZyuMectZ2lRQDadqzpRFj00+pOfcvh33M27KCv75UyUEgKXatyh3y5PX9OGlzANPZuVE5 jIikRa8+OHiuQ0tobYZmxpZiNH0dLtIuuPl2o/CmBb5pKrYDcAUUnxMxvKRGxMtmt+ygxJowMC8j +k3MiRKIYWbpnvqqBiM3KLGQhAu5pjjKH76rZgkZ/YuLvVndXWmCx/nqHVXClREklKR+agzZA8k9 lGTPs9Tq4UisckLn8qVJUWWfZ2LRKmZgFrqmnIb7VeFmU4G7TmxemHg7A7LSxnfuIFwjOmpTgpq3 GRr8JqZCBZ+5wdOlk96czcqA+EumtuC+fvgPIvVN9RJHvOnyBEJSb+DhFWOcXLI4e42Qf+hHUOlL G1IyEpn0weRX8t1w4S/LcrTpszRu1GGQrVJf25msE5asYXWtQm/STUamyBKD91vIIk+32YUHVE8s 7FPPkEytL1V4q3TbGrcqDaulBvFDOkzmjWyxL3Q37PjzVxsj3OjiyN/vvPNiXd303/Vtbw/wMdco DfVxVRIzUKaa8JN47lrAuYij2pDrVb6s3V7zCuHjokP08GLkgUPcLM/EtJaIpURiXIrLkjdKs3OX oaUgT9tBuT+iIx84wCu+6tfDQyn0GIfrFZ+bgDzBuL0A8iNhrAOWeGXKa4nmwiz7GDYUx1r5og9D zkc/pfbMyxkj49tLjK0vYDPYhbVUYOjck4JOY5zgnyPzlB6I29S4TaMuz2Og+03YV2JKg5k5oP+P iK5Nsbsrl3pHxg7Zq7lrXkGfihSB93iYUx8RFohVQlqP7Kq3C2dXnfjoSueZ9pg8Mars44O8Xg01 B2PPvzV5ErX3elHP8V7fVLAKyuWSpBe5UhBTmdCfDanN1hpmvIl+Zt2YiircRN6wm5PWrqSBSv8i pkA/Hi+tC88YF3owehsK3OeqHt+8oX0rqBCtp6+mTmOR8ME7fXRPnTEp57vP7kLnbB7zPHpDRrLc dEQwMiw8tweCRkPvq8Doe7XKDn+cWwzRcGyMhucsJKe14B0FxWFefDo/0ou/xdLs/bzLPBt6PohV RHub/3gbcKpeZHVnvG3d07Kucz0+FayxuXopZB0Ebx8I2jUiwrtReRLqE+ygmVxLfjr2ACwXUDHI 0caBZIz4bP7V6hPPcybH71zpnaZ7szH4zCnnBCeO2L3dO00+hudgaLxY7ADHfMXkxSQQBxf5Ic2B DqUFt/HiVf81DeppClrlIVt0VDrr0QruIGmIJ/i40LwoYBD0gVfQNgbPxdSkRnGLK8SI9igI2kn4 ectWs0DNl5qExYiO8qSC9/zWMU8dp+Vi59teQSpv+Prbl36keKY7d5zCX0oiHJAG3EPGy9fcI54o vF0+HwuaegB8EoEY5SsnfoOZ2fpyuV9y6bWnHgPTlpdtzRQzq+mB7Y45A6TOD0xFREfzbAEpXqra teaaKvg9NQeti5rxlVF6znXho/mwd881aINq/AqKTN0/fXZRXbQKWES9rUbXjjJIzEsuYiX1jk43 GjGJr5fZ4kG1DBshfwdUGdnjGdhprzfv3/le11VGA/G5egedi09SRgm13pPHwSnO7DVNDA2xLFZd rrWrtab0x8hXo52DDO8vC1+huXpIYQBrlZpl+9mtMK1FLy7lKUk+ZT5256dQmGznLFRa7Wfwe33j WZKe4QFkfcVRqVY/Z89uuOF9xfN2BjNCbIS/e8P2KeIrlwXOQFQz6GRY0sJwYvLdLtWA4PeBb5Z6 eYI7tynDTnhNiczNXe+oW80eG0y/x6XZE03yQlZyWIn9NI2smOv8dXgLmYrbDWP0OdzLL0hx+DiP qI6UNGffR5xJ54pDtPRCshBDL6EypKKrYGniKxIjHbVmqXdVXLQ9idFdAB/9cKXL9WunWfoXRPjf 6QVCVCvD3oYlAzZMpBSRzTSevmA7wXic41q3DsPmpKdXwnjJGGBFWFSkok6PH6smhGGnYy+xpjLH vNA6EVU3PTPS+zTbs37Et7AP8IzjW2PZzM0Zx0frCzhdqc+qkOATkgE+HDntsxf+Cv25DmpbQm7G Tsw3JB6oaRKZ9B1EST29Gl0TQTLqQye3gO4LrZvZZtotxe3X3bfYKfRIoo92e7G65mwwcV0UfiC/ iRw8QIvhNlZjDNd21tAMqWklIWAE1PW+Y8Z58mn4YaWwV624dr1VyFDU2MdjWmAe20M5EPE7pqWv po/i+74Mrn+y+CAvbtrG8pWY467s2yz/Kw6OdOh3w1KJvKuFDfITLN2CL3EePOeIh1muYDfPFV0K Pywztihmh0GN6niVfaf0buouS+gVpejPNxRBXJ6RDU8SSb23P305/8Zl6XArPjf7VIBmrglvSLih s8maznlK9/vH5T6ZYXHGk3ZtGsmUrPdHT7c97Q9zlVDG8znRh4dOC7OqpgV5jN2XT6jKrCIiAj1A eAuha/CGcdxc/OiIGdIEgj3UCIuXjBHqutWvib91XS+iSHFMldNU/Eyuuya9Dtu2kvEBTXHtCyJX ieXM7KEtfbX3LVDMD9m8xpp8Jt378rUEUsVM/aXXS+XpyVMiW5kD+ItQEQ0USTaUzsQKajsJ47Tx mYUBOIs3ce7N/k56LsM4xdDXTwVKkSuSKuwzP1ypFn/uPSuq9RXgdTW4UnGaPSnZrO32JTPUWnfD S/bOdeboDKwfxXxQtfjumppcQlMhq7smHY2mH4N5llpF5tbMtgVG5te9ibq+bcHLvbKGOxykUHJc pnhpoKIWTZ1DmOhOEdPtFL9/Om04sPJwY65CsDF+1NFCBUtwmdEhTCmTkTanoN8ap8cA8YHRXrW0 M25AXjBD7jqJ6NK5jIeCakfFL7nU+XjvyPqkQXrplMSPpeRtV+UlCEg5VIP6Rd7hQCpmR2uPwPnC hvPbkGQZKsO4SyE73pX1aPwL6/KYIkgIPzl1FPV2fmDzCL8NiSwrA7euiOg4Qxn6Ks0+fG6SEN6p XfeWm859qsPDpvnMRB4jgyk/qbgHgMZiv27KMBTcaR0cFVqO7PIwcXCMxdQ+LaCtjYiV1kuO8rWS 68S4qjiPMkQrjFG2E0GuW42f+xgy9LAkT30nRp6K34Ky4FWpzxq0hiIp+vZc+cfCh5i3ztLNypYa /eOyuTqLRDgtwZM4SxSFXYR6rYic6Yveb5yG4PeVFItvfbFdJ5UvmwW6E3PSDi2RPOa2q/ZZ/F9O xjRnAGQTyHsP2ba3Pddy468oozaJnnxq6z8x/O6tXeZB1PLA6agRUqrstSYEhr8Lg5XkcXDbupPJ V5+QgagI0F+8Q2POI0H4NLpl4PR0lGvUZXu2M9aRn8C7GCaZoS80042qTMY2OuyI6+ThkmfLfajR BwSW+EUW4mO8aZu2ePxWsFzJKsZvFatlVW2TL0c0TZtU2xctWdU3d1jTq06soz8scust0NCPtNBF T1K9WBz3Ga593Ws1thAb2l+zI9LFv/0pzH7POdaaJV5SyJB1qFBcIFSj9/XVg/VrV0dCn5ESjwdS H6keJrHguIVxzpPBn9QtPXUanp6dimjSpEo9AOpeEcam6ovhRnF/gpKYHv3o8a4Q5ub0jBNPf+AB gHev/Lwyxnw4WRuVKc8/CI55m2Gj6GiWJpVFoSgrahj0tv0FCHO+GgV4JdaSPtEfHf/8mRUg6til USvW7IGZnXykniCxYA2Wrjtfu+vryb6kNsm10S/fmaY5Q5zUtcas3a2ERT8X4QjCC6T7i0/sVD2r Rg0J1o/Hhg6jACKPHNdu7X3zOaZfmN9cVJQllzxzDfeopBgxudSKKkbUprod47A3+CaUMSowk+0o NajGfyFUL66cUC6X3+aQLGt5G0QM9yF+bdGd43rXXFU0bRDElJ2w5Cg4+tX1wopwNKlE8luaekWq f3kzNY1H6uLbAn+8cmW/1lTB62/MkvHAMGy5ANqBhLVr4Z714WW0JHVdXGmog59Z8nlqcxO3b8Zz +2cEbU8aLN8GLIern+rzob+vkqE5D+xYgxblfhHmkzzyrvF1LfYUL0HdZB6D0S5SD+ARD2OZLMPG C9w7ILCIS/xskpib3H1kR/RL5WbgGG1sNJ1+j98HqqflF8416hhkkoHB9Gsp1+pPj0DoVIoJS14B P7RUAhrE8hG4cnKt+0xanlgaXwHPwvSAaA2Ck5IefHge82pId9MzDDt94jedAAKJ+DXBxxPLC76v ytj0Y76Ei99ZvHae47HTlDxJ9cnKmPuCrsbq7V5l0dUMtk3OXKZelT0UNtaYgk+cSr1O00U+8G45 CBrbX6RVm5qcnD+faphsg7vUPJi+RrQLe2fhzMujMpWwYH+Px6vxZgRUsTcA05vfQUjIkrHGamf2 FINiL+oiZLPMCaTKzfpCCZckVDVsNLcwYs/PGLims0/tG/JJ0PzH0D+qHBp+0VeL23DRd6bSGFDP zzrc0RjKYtY9ZoBVnUhwbD8jnj2cIK6WmFsX8T/spY3SovNdsN8i1SJyvWHxrWTtTumqSxTvdD6c ZicSmJxs3GGUJ6OqqcCd5xxa1DDBSzp+JWhxeRbQlfLlc/CVYbIM++pDqs4IM9Wx6nNpyy37OT8P chrs6kyF6lU+VFWN7GJpyeizTVgLS7FB4IPkjO3ojEa0h6l7QaaFJ5+WkGaDPfomxZPC8yMLnOgJ UyKOS2NeBpsX0WMsDx3jevqGdt2cIknrizIxmJywdAuawbXmQkiZGr1HD0YVRKmuRt01pbYtmN4Q MLNvlwmZZsawdPeoq6jEkX7tE/eCPuBB9Ap57QlZkZdgb0386DbXfEx6oKKlZLz0wTNtpVCJNkhh 21hBjIbYc1qanUskKi6MU0cnxU8RyVOZVcqd0nQQOUZESjU2qiuXvcl+72WB/P6mBmj/3Zwyl5N+ 1k5Exuk7Hf3clT3GiGda2Wpe/HS1fT8wExuDQxMKszjsG+3awPIaBdgCGPXIES1B1rjRtBm+F8Cb nlSL6dlabLxuP1t1jxwFouQ8PAW/iMr6+LeKIY+Hp66/z+8W8QpLPZfKviaYizGlD5GaF9TeZzvM Il3r4Yj7fGWD9LXJDs+xl8e9qv5No30ira+Kow1GlLLwEOrc+cZIGkrrap/A8Mkw5lXr8GdlaPHW 1GRXtyJeYq3wx1cfeXSibGTM3ijxaZckQhjjB5ZY61kIkt4tJaRW5PUvZl+Zww9eTymhM5FOKg4m 63Dl819kYucfzlF61Vh/7GtEtygsawPiqz5I2bUv/krcgry/1yTO+Hyenq3cy8SJydlzOafr6Mpp nmpWqB+rbgi1wf9JXuvAIgvSJ+yjvGr5BDXPFPeDAopDm8YcKSEW2DATr1vjYpmebVAAfpcAblDg uop5XPUrZ9y9HDMSpDsRFN2vjX0LLMO8nalb+4VW3dbqkkSawbWRe5M5Ugjg7nOvPGet4a4lxy9t VEtJzXoiK2sfXh1UhKSv73EHdiVHCMkR1rzQ1UlhI2FyHWZH5o44lyKuoq17NIob9zGDK5JJP9i7 2ZGxBOuOkSpbtPrLQNuJPM6rt/PRQxU7zbODRcuBNB3PhHLp0GPLyp03ieVJ5ylfclXWa25KJdZI n1fV3f3wZe1HM7NpiC3zFK++9vkYPPHzLnvl9nlcwsJBpG0gGXB1Wfxz0l3wKQkUa+oELs+2IT90 zsAWKZvnt9MFZWDwiSru/bAnB4FTEm2uGKaMNE/uqAlAEpmVnyjOPA7GtQmIpFxb1Ug88flRF3tF mtntL0FncIyPHdhWhZh0MxVj6pa6be1nIHRmCbQ6Oa54NCzbZp7hbaupLMkoxGGO3rHkDMTuCVc/ oulFeAx8C/cV/9E1aq7v27AZRFpUfHK+uJ4XIn//5uIeYa1cwzN0bZK0qadV+hqZx+1k97QiWUB/ ZVPtMmRhqm8Zq/QhakrXELGh00Uv88H3LqgbegM3/I0jc9ceuVBTYzd1+hQ2C174kyNtPAY+Iw2K aQXWjzqE2z5mwWrum+bJjyaZQzeFRx1fC4G29g21T8SFp5DZjFORxx0a7eS2QFDuBXr75xPXapwi zyzJVGFbSYvWA0qPs0uLv4OwAk51fxoqnb/a8hV8VkZoUSifeChsyKYp8TCchg9r2+sm3+9UZ/Bg D0nErWP6W5v1YROlvsZKdMvwQSZG4Ayt/ry4FvwQyqfLleupw2FDuljoT/2JmPjbA6SKD+dWE3hg 00covUDjy91blZ/WdQVfIjoz7EhJkFPtvXYDRRRlmMr1tuf2rZkzWyF6m67D/EyLrLHNqszELeCZ jvWitdCOYArORMoPGIdVrkMGelzR4Ty0L1GoGbeX5kZhzQGTiujeG8bvBUu0kj25WHF+8nbmUSCe tq461c+4Wsw5PcjMax69Geioml+/g3k8fu9gkusy+sr8Z9N89Xa4yQuMCswyXROfcjLEy4fi5aKB mNl9P+mznze0Xw317bqzzbg/9EIXq0A9altg5mGf3k91kVtktJnlnYwTD03Xa0xzVzo8EBG/i1Lr eMDD945SjoYfvFTkgXuV2WBiSnT6Gt1dPZuR5OlxoDpP6fD5bBCtlS8HpHY98YPYR9T4UxnXFTxU kjdNY25syUmVjibVG0aDQNme5Li3Qg0TxcHHBTwyl3tVD9g29dnAhn2WxCE66tC6NenTw5937D1k qyeZIgpkddz0Vgn83zCmy3uE0X2JCmCZ3ajWw8u1vXMXcGGx/k49jgIYwGpKp2H7u3aILDGmstTr pE2QcJk7BTJsowp6cuAsWpPknKS+3ayrc4DhLRqGxx7pZVKn2t3ZL5BIfRCTtctdbePOZzyIG8+D HdjElpgzm7qMM0y7qwgcuFxbc6hbyDJxPeyYfOw0QwisF9zfSG7fmY40HG2D0iPVVSJTW+TC30A+ SPLkb/bVV3af6bRqnHZk2SsIJ3d8sRmq+ZaKLC2sgdbC1zpE488uTEGQxPhNXoHhrpDfTxvbPmwE N1LmwJGQ7bRErYqzlNsuSqLKqLkbz86hZPJbtu3Du1ebQD00SyuhiHmJMY74NgtPSpIrOthBEFqg s6AJddrEUuWjHUYNuwPrs/cV3Ttyyy14tcF8xyftdpW8Cmc7hbIOeLnFBHByp6HONV7E5Wl0z6Pg HQulYvp5GsIfl2EazRnD/becsNDHiozp9HkiJGU/L48YNgjL3ERecUchRo4lEnc3MfTXwy11TWVE kEpdLi4fUB9/CI1YeSkzy0c7C0H6toJ6smcghz0wzwkqsqNVF5uLM5efNDJUGXX+yOWioXYovwuq eQqI23p/Ku4/0GIcI0WSFzqTqSwjx4QaOFJ4tMgEV1iPPgJ9etUqXcnLjkjRXshEfM6OVm8qMQvZ RFvJ8IlltuMMICScs0ceoVoLzm7p/5jOnPuFBrVRXR86AZ1vilcdKdMbLy1adH7Ev2rXlz0qIESi 7PJlX7VJ9rF2q85OiqHUZwmbyydWL/c8pNnjibJ8yTN3ZeVUGL0BAqimMlsypGetMqmJ6FuG3Bls YhxJjAYZqZgiFTsyTzaTekZoZkdcCUiq8wdcS52Hs6/74mfQ8iOjngs1QgKZ7PIokew1Jzf0A7dY TfBG44OVY4vgUuG3pIfZHHcGI6pyeqJ5Z2j0Qdz7xzHhiZthCmpRvu9WLAj7F594AmpIk6cuUNRk xSNIMvsKKxxFybRXt+MNkhaDU+6ShZ0a1GVce73d81kS5n8Mxs9MO0wGJeT0HoeQrHc0r70XQlbh YUCrjSTHx3Lun+pp/5RFoWYl/TzuBdymcqNIN6zSK0GZMKdlevN0YHk3NHTdcAwjkNWyFmVP2pLU t4PUtSyVx5Yla2OJUEQ0oAsWceZqJ0Gevr+6hf+6iJreMvBZBssq9SPm6Ycos13jlVfWFwqAZbLX mzgJLFKfbz7Xre6VoWuaPHzvqJ4vf+Y2iuktWWBIHHhrTZcwWpm+vVW2zdWKoXg6DGtEqrWBsg1n e1fu3voJVSg3CLU6Y45uDO2SG+mL+Qw2IXoqmOSojWeKgDd+Yp2aLCkG25iPkLGCfGpwdp6VM72c HapiIVIcbzcKz7EYjLPWwjzKWJKWyhJshGalvtZ+MW+su5YQdpu5VGeCEy+8ywMnfZNmvI0dTplN KZBXhHAxG8M//4AbF841YSkcRVJpKJQoodmlyTHWqOkZ7K5AeeuDckYThlKbQd3kQj5fDzNOInMW tMb+ShHqep6tNQ3FMweVZjrJ81uWc1rgL64wz3RWLSILI9t2Hz6wJUGqiC8YjVTDtDeOOhVw7vMJ LyY708DqTa1u/zCIWL3ZbtMYPWcY6ztbMoyorRJMpvfY1VO9RLw0BDI3h0V7xc93aC20+07mEscw 16i8k1wdk4cPvXbglrt6k8Lav70SNoVrzoAO1acwzpX0agCgVWqpYQ03XyLZeQ1VNKsXyzQfqvmF W3ttCJDD6WfQcD6rPHrlil3o8fhE7xWx8oPuw6f9BxMGc+vFkhqZx8EwedWdnjiNU2D8zAvNmHUG 3g65Fy9q0u7kIsNfWqU/o7lxOJtzzDLFyB8OWQKOYWIM4czgYu2vYvNSjbhIPx+H9SAe5UmN1/8w /rKkbHCKSpZEFNyQeCIXSNsQtHWsbEGT8pj8kppz1IaZvsR0nuHACgXeqeLmsJF2ItV2xSLMAfU1 bujiZZ1yWMsEhTSjTCkQFX803Cx1cIxUoSLXw3/HwFmFN4lTJpr0mqPrnWUif61QhZoKH6ISJWVX GsZyfsb5xCVoKLJFXpzDaS5AbKuuwybX25C/L7ypFPtydaVFlf8IY/kpkFP+Bnlv2L4oSK5fjvwO f6msntdQyWYP6Num5YRhg/GTdA6ILxi1X5vRn0UzRyE2J/zFzPD7ZwmaKxWHskcW+IV3C+E7gFsG /ganVLh5W2F2hvHI3rBJkELHfNPVoobxEXFygta3aomRMn2Tt1KLhe+nM6S8+l9OL/y4qUxSmJhl t+kwVJ+1/kRgGIxAqvbQ1e45IQy8gjWT1hOpH+TFLiC5d3l6dGeShGjtCyrShQZEAQynkEyUMxf3 9qY8QnoVuhknjgGND7AHuFtjPbVgT0RlMOhb6d9ECIDsnTNQ35/m2vddC+HRairhprdVgAZWrmOS F0MaMD0ocuWM8vy1Q2vl7Ma2vT7ukz2EmS1UtJHhs70hOzOGeTVhXmXgW/OpbpCh9K3UPWBQNDp/ qnxE3y8B1xE3CiZPuPpMV/+iYFlD5Lae6x2O6SvbgTrqIsqJTQ4JrhqYdNNqMhXKucZnsYhXVnPb uVGL9fpteV6rHkwzfbLDWeRzwuaPSt8JCmjZFhFjYrtYT9RHL9Tj1/lSvXgqM01owlLz1nvwLt+d DBa0b5l78A2uiTuw/Qw6IoPZQJ4ruxnc3ybxsSm5IT4gu+lDVyXtnuNzthfGCymrJzXU/T+DnxWk GuLomc1HagYKO+aApjwpTbFcC+jQyaKTheon3Lu50WrmHPcfo74nCJeKD67auP/fzeDAGkP74bQy NSPzkJ+fRe0tf1f2GSV+n/SNAeOzuKqAlm0scZul71rPCNoms8K/z0SpZiiIbyZkrtxMzb3Ioc92 0J2YiR2jCo0u/iiBKWhAwMsmL5qmGfx05Kf+Hu8pZ3o87KluTQNLUED0q8rGwsviQUaYFmWgptmn D+ebBFV43C11+YH4g7cIaZd3hw2b+IJ9RQHbNuMxUrStEvpzSnwdJDmseZwY2GivdpUm2kd+wh3l TyQ85Odkl8O7XDRmzLisNMsFyo2xVb4ntgahLov267heyd3RU6W+h+CzliIVtuHhCKdL7nRSl88S trmbe8ruv/E4SHi0FnQ8xVDrYKvrWFu7j31OOC9GfUXXGEGtOo7/fSZOQDM82eLxIIl6hhleYv45 qv3ckrpWldHSc65eReeL2rRSwfKHZlJjJcTUCijhoc8GDM6Ssl8IfdlOZ3f9svcjsYZYnJgsYNm4 v7zVNXW0PekDRRc9Jn8BHfYIbZjlFd37DM0rUyJdNKRpaJiPVo/lt/AyQqYefzUM26FtFHNCM37R ocNQ87T+ClUH4yIF1wXQgt1d9NpVey4p7nJYrIqWYVds4c3ca3x9mSmdNBIyRkdFz7q0Ou2uN2w3 bcxcJXRu3EnkuQz1LmeE0BxUU1kZemRp5PoeCJsDyabTSMgHVCGWYYqbr/vclZdihJkcnF28jimI JKuq0ChNo/WtUAJNb1STPSz3/qE44MRDNiMutrP6R5DGHxHjCuGqRyAV1f8BFgvfhgplbmRzdHJl YW0KZW5kb2JqCjQ4IDAgb2JqIDw8Ci9MZW5ndGgxIDE1OTgKL0xlbmd0aDIgNzY0NQovTGVuZ3Ro MyAwCi9MZW5ndGggODY3NSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqN tAVUE+4bNoyESIPSOVKajS7pTumOMQZMYsCGNBIi3RKCdAlIp5R0SXd3CdKogAIv+uv/953zvmfn bLvufK77ue6Hmf6pDpe0NdwKqgB3QnKBuIGiAFl1HR2QEAAI5OMGAnmxmZl1YUgH6F92bGZ9qCsC BncS/VeErCsUjLyzyYGRd4HqcCeAipsDAMQHAAmKgoREgUAALxAo8lcg3FUUIAd+DrMGqHMDVOBO UAQ2syzc2dMVZmuHvOvz118AK4QNABIREeL8nQ6QdoS6wiBgJ4A6GGkHdbzrCAE7AHTgEBgU6fmf EqzidkiksygPj7u7OzfYEcENd7WVYOMEuMOQdgBtKALq+hxqDfhFGaABdoT+SY0bmxmgawdD/OHQ gdsg3cGuUMCdwQEGgToh7lLcnKyhroC77gAdZTWApjPU6Y9gtT8COAF/DgcA4gb9Xe7P7F+FYE6/ k8EQCNzRGezkCXOyBdjAHKAATQU1bqQHkhMAdrL+FQh2QMDv8sHPwTAHsNVdwO+jgwEK0loA8B3D P/khIK4wZySCGwFz+MWR51eZuzHLO1nLwh0doU5IBPav88nBXKGQu7l78vx5ufZOcHcn77+QDczJ 2uYXDWs3Zx49J5iLG1RZ7s+YOxP2PzZbKBIgAAQChYECAKgLAOoBseP51UDX0xn62wn6Zb7j4Ovt DHcG2NzRgPrCbKB3P9jeCPBzKADp6gb19f63478IGwQCWMMgSIAV1BbmhP1P9Tsz1OYPfHf/rjAP gAnwTn4gAPDX5+9/ZncKs4Y7OXj+E/77inkM9KWfKqhy/En5b6eMDNwD4M0lIAzg4hUAAkT4RABC d8D3v2X+HsBf5H9bn4Jhfx4O+E9BZScbOEDkDw53w/uLx/M/hcH659awAf7bQQN+J2cogPUf9ZsC BYCQuy/Q//MO/E75/5P+ryr/V/X/74kU3BwcfvtZ/wj4//jBjjAHzz8j7uTshrxbDXX43YI4/W+o AfSPfVaHWsPcHP/Xq4wE362ItJOtw9+DhCEUYB5Q66cwJMTuDxX9dQ935R1gTtCncATs14sD4AIB gf/ju1s6iP3dq4K4u63fLujdTv23pbwTBG79a/l4BQQBYFdXsCc28E5hvAICAG/Q3ZZaQz1+ixvA w+0ER96lAO7o+QJs4K7Yv+5UUAjAI/vL9AcSAfDI/42E+AE8Kv+gO5/m30iYD8Cj8zcC3UmWB/ov yAvgsfkXFADwwP6Bd3vBA/8XvAt2/he86+r6L3iXi/gXFATwIP8F747v9g/kvavs+Rv+Z0gQN1fX uxfkt5DvJvgX/v1cQaEeUAj23DQcIvbyWdXL5osKaSp3rq2h+ytrrWGxRt2hAkiWmSxvOzXMVMVx FxlL61LyT8lPZ4tejU37ULEfXgx7mLa/DVhOUspEosh3b8gcc2X3X56120JpreGUtiNCyWEbREdx WjQEliboJo8TDKZ/Bgt18O2UbeddtyJ2jEX2AY6Agm+E9ElUyCjpjNZ91AgjeqY15ICRKWH0Q1eT FDddZb2Ra9QIWPR3meZIikvPDZPoNwNLS31ve7qT+U5zVDvLBUtfPaIg9lKhz/gU30tBEvdWpR6B wiIj8E222KifydR2yfu8bholQAytN11ql9RyXF1BdB9jnCBGS8fve4gzoqmiJR2zF/C5ZKgym2TM nEbcQO16+Nin4/girbtYRyAnUvGZUYpx9ECObrxi6AE9Xm7HQV2Nkof3O8NHTtGADh1eGMqY5rPT rPP5l682fV6Pnh+uPkbNDWO8LSDswPbRtuw2X2shv2SnlQ/Qttzjlk0gl+2f+lpiIvpTeEu6ENPN z3mYJirBz9O3agYs1/5zY+g56amN6ZTMhumETwX2PhrKMxk96ppJylQI8l32qmDlCT3LeTfoUvo7 R7+RPqyrd9ICQUydPZQegZCigGz2tDJMAHD4LqglXj4JrSoPP2/ACod7UpvnuVCeaxLJDgdv8lFN 7Mje6xtod0bKNyOvsR4+t3ut8J6xB3HOlpZxonUs7M815efVdjWnR4YMRT11XiJKVR3TSxpROi8W PCwc2NYv7s3c9cnDofmmMN8hxXZV4tMGj4rwIN/79Cxk3DLpsbh0gMRDEmEnF9Elc7m4KaqO5s7n Mx7AcKT2IwJ/rOvuAv1MhKxksgMgSUUkHcD9RT7+x3zyx3PXmh9uDepm8oEqzroPTyS6c1YEnwjt rKElWPVT9kjmN2w5P96SpL9wccnFoMiQ1FnxbBxBj9F7IkqshpdR4fDSXT9QzswBKV+J6+p9iI65 bu3Ho6Q6HfCUq8UrlbUDmPKRIXBz4oZBG8vulM+Uor80SA2Yc/sTE0b4SCcI2p1SSuKW7zSoqXte qWjh/K18j01CWrmaIwj66QqF7hHt6vTGssnPhUJmjiH63NS1K7/WqeD2t8wPy+xWCwsMlntKrnRW dGsxCqPq55My4ufI+2qyCHXswakfsoe6jTqkPOIjmptuKsQfmnDxYOtoLwq3JrIJZuiybRR89q19 koFNcaTzVQrckmns+9n803I5/+JTRXpf7Hm6dlKzUzYaX5lqLhsVA+ee5Mb7ls7iVok5nEXXIjNj XEV91cxeuMYRF3k2SGUz2TFlDrwSG5nkEFaFJ7Md0iM7N4pLq/Tu/suTy9PTY4bHLD9vmcie93h9 oeYbtApOLusMOuZrlmq/oHPOg6UxdDCPc2CZOV/zcedY6EmgvmnxvlR9VOzoEll9QEAzOeDWo8YR kQoKRDlaFOuvmstgP2LfJknLpizwsYyk6xELyHlgy8l682PwBRfxFgP+ougtrYGy3dvIIEyRaizV bRsy1dx+mkLXGV1SBRTRtSxM/tj00mNmqcp8inO3oFvQT+/Q97TRzicHYD2NR7Q7YgfQsbnso4Yi Zfo9Q+0N1yUNxOMO3qo00rzMDYVG090wJraXkwff+Yobu9yej4XWTtuNuxhtfJkLAHBzY8immIvM 33DVjE8VRn3iemXj3yYuY+cgupBU9TUl7QndK8L1fPGURq46i14YVPzdSuyHH2sjh20LJoWbfq81 kr1MF9BynKNnPnF70UfhBBvRdAuDYtA0Dylp9snkG9UZsimj6QWDW/b3MSGK+X791x0Y9TU6MThO oadftjYYCjiUB1YBi0cvTrWI1aWG+pU9TS57Qm9iwui0JqSB9kYn9+rFfc+LClv2L5Grfg/3BkdN O8Uxh4MaREWzIbhHo98eFoVRhy8sS8jloZmcGUkvex8adnBD5oHM61oYm6aVlRn7tjytBIPILukX dWphx94jOh3+X0u60RsamziWoZSL947a+tO/Vc+jGHmy7F3Sn4adZb5uNzlfG+fLYMsAyqCNh/MZ lDjE6eETrqqf99GYWGk6RpdELOqxN0bV1zQzQNLJnPeXem1n0uizgiotCd9pBxFFFOkZFL+nG6Pd yJ1RqizeH/OCBNQm+ACMc0CkJpLvbx50O2qxYGv0SH0ib7ctvyAbEWOM3Q/R9dXf8Ls5MCYs3w8r hlGaCnPj6e/AwpclSV6zS6t9s88vbXu3WlYkXHowe0NAPIxn2IlBfXCqY0RwaxxOiqkqcBGti+yI eK7h783Xp1oKoJ2DfFzP7pTCC39gR0bX+DDaHIfc+IllaDjFLkjWq4JnboQG8mDciB7fJd4k1DnP 5elXqUJRloExbPpJH+JdK4LGRRHBAL/s2H2xdFeRxphXwlRR09+Ig+KjqgkrDu/7sLzuxaP5jkoR nZbQIAM2Du+Gvzlgm27Hj//OwEbViuWnAl8oR9W1EP2Is38cdyXgFW5zLMeK903M0EvfqkRZ0Lv3 sdpABWN8TueAykB9ZMb2+UT2E6YK4ZO4gDrcdllxfxt+U20+RG+5YQx2WuEEViiG5cJaLxkxV8Fu bsfWkLCIyfTMe5HSpZrL78etWnuGC0N4B5hspR7ytcwBW61D3QW+UmoGrWm7nTO9qUSsc+qrNNWw eoVPzVPMhOlWXdCkG18fJgl9AkNCmQoHf4qUEQQcD/u9/kC1/HJ/OXE54PpJgqoQP78H76X20RTa xI85kiV+WsnzykdLqU2fd/3g7ybvVyuYDQOvw8fLAszCNKitgPlhJoUK1Ow9mcsuYqdB0im4aC7G rVQ+OJORJdtBgC+XKTErbzYEz4pde6Z1K9NmIVSnFsNPzgIOriODG072H+RGpjeRiBbjMDpg19YX DZb0JQCoc7I2M+OiDfcwtjANtkj3tF0qGnbQS/sCSlm+5ppf5QdyGql2IezcE27fQdqin1oWvtpt u/Qvslnmpyoh3fWE5uBWr2CYMu2uuGcdLnR1K7ZSXtnJv3xGxt/z42B4SYwQRe7NBuAHoazFGZ5c 1TqjMCPOccuCsIkAUxe3n7DXxzAba/Ma5d1o+1d7uYsbdW8/5qoqdOniMq6+sNwhQ8jUiJifiyUP BKsLpMTjNZt+sGggi7DpC/r6UGpxaKGNzNUxcZY9Ow+kT1Qd0JK1YsUAAt8nFeWLy2uHnUuXXHVf 68hSnk1qvAirkiqGyK8FnvSPZ4pXBPJ/2/Zo6R1qGf2iRLeVGWdxy3UmbCx8QzYcZxOJzgAEEwsF jWgJHUoH1pErmAg9FNnWLZWNGvOlaabbt34Yke3DYHH89aPBuFlfylajhbXJQbGD5tIHiNt+duuN Rq7jPTHxhAIm0ZTDcg3Pbb6haJVxayXOCHSLud76sDpZ30uRKVdjOuyHdrQU5DXlDK7ORYf+1Yqg iTn5U/SJ6t72ay/2reKoTxMZ9h3uj9MkFizKUPywiKOOqgqxNqhcdrmzlpUo8Z5YxDoOguXrw9Dt MMeLmcnD8Fn7lTCp3BwcvfxHWC8Sw1jND7YQbRT0qxjkHz0aP3SQFCx5Z02nNsgZck5VpXM19Cxv bnrcl7XPZjl+ZrSQbIadi9v5Fs80zAa30jUHVTMeMaapxC7ppaQgFNN60/TBLMPXezU69JOA8Ona QfexuZ9P906S3JKLn9u5tR3x49tWQuYDNSpswAhFEq5M/xXFkhU7tY6g6xdKXjn/RIZstqrACraQ C7geU84Y35tTKRppthY4PReasN8QUWqB5Sv7pBi8vepjiMOB6QtGZXW9ZYb4gqyaN+vPSnDzuYKd HeYBUyRZOj3FTbcKLXQJUu/wTlm2agi4pnB4Z9JdBjmJWp1KNFsPtBEUoP4fuBb5sxEQDL2tFSeT 15x5pmUxLVi2rPB5VDVcB7ryKq1NffYLDYeXrwu8hKgvZcdsD4maiX1EpIibsC/LmFn2+38e/7zn sy7DNvU1le9mvejoG6YP/lbD6tjFsoAHBk1M7b2lTWt1nAfPd51XDq5OPm5h3TB6fnSouheNy93Z PIJy3d+aRLDuE7md2iJiGkiZ36ReQY2u+ZUTVtD85B75noxGGsYRkU/5C73YWahhSav4PYKkhemy PU/zH99LvzZ/uz+uFbh7xsnqzkiQYXWpoqZ+racG49b8oRHaBPZguS43SidxZMNZXslZYSDXE3cq PjLosg7nEv/epGYo8XHzxDVuypWrh3xjdD1/Juv7pEMy0D3pZhkb0rWuRQ+JHp5vvs9KXPCmbnbz tu9Dcz3JExLv8j6a2Q95N4HXUSFxHhe9HPXkq9rlARdXtPSf2yhyp1W2DOE98VGmPpQi5pq05S0c 67PWKVM4u7cPO4nzVKZoCgQ1wlorWjajHr4w+dIpVZ0l/ux4WIszODTFTlctJvXRDH6HIj2OFxi4 2JAUx0Q/Sn/MU7sm/yHgiJojPYyz3lOA4wlOMHXjArCnvdpNUKh+159J7bgbHhY/hcWMe2pXO4/d 11g+Cy2+t+CJxUnNLKtnabysYJZngxORmCEx/nzIGJN2Uz9IAF/bzQr3rYHXNhpC6Nkn2SjG1xkn ZcHOT6wwTg+GRGzTwxgF6+9HzPfsBFRI7/5sWXob1JR5ILRudbrC8iJERmWvnaCgqNZqVteGpm6g c2YLniFH//15MqvjB/njBu7a4yeoM8ZM5/dz6eh9pk/2ptdcEnmxXq2nedNOQvqVJwDOE03dci/U 2yJsD3jzaXsfisPIYzPAt2fZbDZRRQOc7/YcMx/LrTNQMmKp8UuKesT0M7ymhHa+rbnYMPGGxOGk dvPOQIr8DX0WRnBswFG9kUzZ3IQxi3IUY6bDZZgmMNHKLVfzdwGaV8+rzpkY6bPIqtPsTIs88pdI 8xHDjPXSr7BJPj7Pxb0xMRu8Fw6SmTIXJGbJQWt+c1Ch9HmYm7zOcCMvTOfJKf9jWk1yFgQXEFnM 8lo7tAYyYOdGMTV2s508GuZfmDyenbo/z+DLSY2V6Gyi2TZLMVWW4bdBomEgSFJHnMytlGZFW1zb xeQvqECI+Uhu89hB8jT0w7x2bufM/KMVq+jSwnb75OTBXN0QKCkhf10SByVTawBGQo0By3yKQWjb N2mKyzD0oF0/Ru3qyhrG6OwHWAKSiav3aKLnciNINA/fQ24yuakW5cyIjNdYUgtRS7E9Hz0Dv016 I5TjHvdyKS287ao2e2sYDtJ9QMSskCSRwi9M/W4sgpcq4LsBqBPfaz+PNtmb6Aj7/XS7gihmxM6D 6JVeivjCK8bEEu9kdjTzmWhPBuu+7rMQaVJAh6KbxLswuqSBKP6ypaeqoT8xOCueTtXGZnLicHHe J3vhWx7Vqr0XYjVVJc5EJDdJ//kmR++jRQ+lfY12hnyXCaeLST/J5dwx06EewcrasqvzUYq25WFH YUsV+/FCAl21L+9UbAxqrvzVlf5TZQraW3ujVDlxsQs2HeAITcK7zPSfnWdBtrrrLrp1QnyY+9z+ fQ5HP+CFAyqfrr+q74Kt6+lLmUlKtjm+W6bLsx7VEAn8BLSxY5Q6rRe/85LebiO+Pgt1EyPl48+n IBDfTxzdj4TlJktVtB35VSiMdBMDwkLkt1GNsmKN7+3F3ujMaD4B9/iH0O8w5IEenKnFVDn2b6Bo F0xmFIZTK24mJ66VtoWyVvsFsR1kfuJ1qVPJkdzl8KM93WW3+bLphCEapkTQPxaa642KxSw/UEjc jPtm717cfPb7ABSifR65BMn8MgrSEtaTV7nxLVWSDiCvsiYZlUs+Fbecsq9fnxGVrK9CzUI1mcOY bjoXT/gd3Nc68oVeuOM+3sZ4TZywMejsHi1yEb6d6Rfte4/fB44mozw3/EjVQ/TepejTk2oFmzCl 0eBhiUkv+tSXtmY5X+z8Bvj0rQYbDwvqA/HZdeIU3OeVlHfE8xJoMHmLXY49MJVbNGqtSxi/T63Y 4aJCaFK07CmLMsqGrHHeYTmyjWS8DRUBUK7KCdwrenWk47PxJGRUY546y8ln+Me+uG76UzMuv0r+ PMXMuRx7Z51aOF+jk0P1GpCCKtDlyLyvh2Ij8l2chHzaxygjI1uIzW3qi8tvdEv4eWUEYOUZ288v J5PCXNkWbx9S0BouvDw6bmymrhWeUem6nnjWade+D8Ipkhx/ykjZHqLTLhfMZ0BkM1WoBebqkVAM fmtruYzpifNzLDgh51NjbkGqj+sCPD487YG8n0G7YsDkQRaX6GaqTUMuaRBK0zoWMcxwOWh9T2n/ p5PMhJrGeJ5/x9AnBs9YCoNMF5ltJd74yPpcQkNhBfQObatMX3bqnR6zqg9k5dHPOcURo29EX9wk 1SsQfn4oUP2JhXZMdJdN/j6kMA0/rR5scpmngfSLXjH3ERb3pP0cVzayO6D0/ktT3LPTZ9bEIaHs 7FnzlFFLYkM0p9SHN6HQEkzyR0DZK3SuV+Fq9O8yK/2C9KG59JEkj8PnoEMJY+X3fFIq4zvRcU9j nh0bDpMqrbGgjhK/ETje/qDB3v6xj244xrkllwCP6IUVemlytrpo/V6X+RCOjlRiHN3ssSm+VeIF XU0iesvCp09CkxxsH6U6+LW7nwYQd13f+rdBCnvTKrvJrpWzt36KSiXO0SpygGYKQxee4OGwG1tk qn1sxBBkplZTnbDGz/+OJePy/Bv2tY2NTfWV5LHz/dRv9qGmGp7UASpEY00EZ+FzmhL2b2vh51n0 UwagyPV553D4wcAXgxhngjxVeVO/np5rWT9On2YH8p+XZ+j74ecAn/moSsufwZ1Nm7UpQamnpa9V vLtPhG4nGt6C0HclbeKB3I2c+8WT2zJS4TeqRQ/jXb9dXOlqzmrJ33RPHn0sFBn1yyraftlENKjx JcQkQabX2UxEilS184K1gdoiqO2MqVt5OCfRDu69Z/M2ecZmtpVa/et1+QtjA8GOW4mZrlm5WG4y TrL3qZkDIixwqmfnhm8OL/H9CytsGDHEzB+48nlqbYAwFoqYk2Jyo49iitSudnaCr34O7oFa18o/ SADHZB7j6Ej4huja9OL7ClNUfn/Hql9LWp6ADfnixWGyH8HpWovNo8rKk1PgpZEJiul6nEpYqoim MaL5/h350WpQ9LavK36zOl4z/IE2xFfZEsQzan/4EqGvIXaN3A0QRBfS2blyKu9zQ59t35z//PMw nloVRZnMJYNZ2KihSD7/dTfyCrNF0Kh5qUPDrfu2KVC5j9199Afmts+NZ4O9cLkm+1ywCUDdwul6 5AQWuaElubhfeVv9zeig23we9mHcdH4rp8HYKHsx8iyNbGpRgz55Mbm0uH6gqUZQz5uGK7Lu3Vig TBjVpUzgkaBQMHYqsDZ6qkSj0qOFa3slo6JKrPCz/wEG8DvWaB/6mzAFyk+eEzEeB4DhiNxBsrff kctUbO/piTIkDUH6YVfrC+28nH0DgEFs9dAqoq4s5x6mRgemGBM52Kf3qTZoU7nLUZueMlYC5849 GBc82F+e8cR8OQp8KtQyGo2hNuiaYOwbivJjF0aDRt0Dw0QAexwsa/QrBFZJY+UI0WzeEYbIH4uV UotuJOgS3jcQVfOvqSRhbuGIlNx7Xb+72lYlNvDG4iLD+/60plCthuxUw83YI9uChAsLXiUZDL+b 74y++I7XoOkFRnxi2fRkkGG/peF3YzelanDs+DBeUROemrzl7Ip00IRRzAdDFTm+/ke0nVGCC/2P K0s7KUX7YeYpGsNZG94hUSHzaxqer3CEHAIx+wichMjIsfmpJ2VXL3E7HaH6Juwg59cj677JVeC3 PmcoV7klpflRVMOm6V/WvYSvB7eoHswDYlYj1Nq9vJVcj0XJH9Gm3VpIfZlBdFU05l+YFYSX9xm/ yG7PAKDr4McgoCZJsTKskcG6wg9Ndj5IrZY9B9Wuum9zl5nZC4RzzpQK41+1u44z/wC470GTAs+1 QvZKDdBfEz4xirknkS1N+y1SHF8ZvCkpgRSQjyDYkonukG1j5PzaGGA53yw9j5meV6i1kgrG8nSk 7EsgQkdSOqTI88XgkZGjfUHv19HIpTnNEtj3LlVhEIQ+Mpp4zZPSxmIw/bo9VfIoJ2rXlvV7Yk7+ glhpTBmyoU0Cweyfg5xBkTonrJwoIVtIwtXxteo94z8WKx/tvNV4WqYduHsiuv0zFTHQIXNh5eqo g1/8vYMg9LWoGaBr0sJfyWHpVT11del8zSNSywoOCpIRpaFwufMxsBOGrW9iPtm80uCSCGduwIQ5 J139yW1OXiTs1gg1UN6nLtCqc1EgQ0lO3BIUk9RI9miTW8klDifhVqneI5grreEGlzuQ7pSMX3I9 PslyFHgcE5VEC/yJE7+TpEvgWlisHVGxJmVf6qnGoet3LtryTMX/R7Hiw1cHD/oxiJ8uGp1MzbeI fha2J7GqnffRiNfOFd94FjTNI76va2qRYtsTB0DFL/SWlBjEVUsZwDjnZyddD8QLdNvso5i/adKi tPDeM9MISD9z2ZrooqnbLjeuwzwLrmjQTy8ipJQGXn/VDNk7ntkbQpdBsy1Fjz4tsaGTytmoECTq ReE6UJxnG171u78SBL6KDDzDU94p29t96r77IYvmSoZrZTpgc9rL6/g+bZNTWImUIVbGGLtSfz1o CstkD9QlUjtrjtZvIPeZM+eICjaZ/NxfVppb4elL1LVJsfldI/oSrXTOYGAqSnbCCUHbK8ynxKUI mvRinKaM5NFTN3oUpfzOWSC6Bt37Dv70lpZOIWC9Xudc+3QGSuwsz0ysvf8R6qFvQaJ544BpRxgj 96NLnR4O1KCihX3RLhl8Ee3jO9qqfsakWssiRgPExVZUvLZ1Vyy6WLZ9FCLSNPX+8zqOk1iTSqOE 3HEFsSQ0CsjPsaajj5me5cGG5vfR7Q9S6D56HVJgcublzcbFkp9leoZsCLKsnU3PJ0e5UESjsi8U iD6fSu3mvpVOhNvnUSfnn3tMvM7fVdR+RkL7eBNQrk/r8oH/h5S4oBCnKbNLiEVb+OXCam61BQh1 0OJyNOVN89ua0ajFx19rDCl/sFEPcDEQiRZfsUv2d7ih6M3pdwzei6SZUqNV/tr+gAjfRvpmQL46 X3KTqr9IzUdFWXtgjxYnse6tk0T2Yjki26ai43DGPhJFpNLPH+1bEWjZfpGncdBCdhJbOLCxKzHB gwg9vIcCTIR+/MX4barq4yLRCynvw7GhYZS8EE40vpERb3lptu2lB2ihU6qfJkp6SS/i60+wmuQQ Nxkr24QKDt4v7wsa4W6zMDzAfflNfTMbs40ghkKIXspqiDyD2qLpfsLFPA1rU0XKmOT96xd6TPYy CR8tRZnPi5g96srM0tCvedAeGsQdf5HOzooGX/oMJDYHfVOs2qyfU8Ya9LQgku+4rVQV3Hol8Wa2 aFDQVPjM3V3+5QL9bJStszoIpi9EqPxVLKj6gTUVi/nLPbejbZCl1CJik8SeIcSyAZC1uFQzoBZL ArEgDtDAL9MRpljet83HCWk0Ix5bMp7yv8VLzIlJ9NCLUPL7kuXk/LM06GOaHg2z9UhQRtoujpRC w/U00tziaPjzRrgu6aG58jsScKomTAwNxNBjeRatPLCujJZ2JivCzNDZLsNAO6YWJrUS8Eh1dUu9 s79hkK6EXq9T0pdRDX2yClricmK/sNJdXKaSzdze/8YxZa3CteYn6YQzxhmpBhQL4kvtCHTUPGbS NrMP4v0+U5+fRqe6A8hvxapJzwkIfNB0+55ykeJAMGr08HmH4akSAleTCdXio0yFdgpuby1L5xC/ tUSIpiCO97YaDe4oP2WVDj2nWD/X8ogkiJ7vsKY8qPRMFGffjYhXJRLE2YJvZX0waQYQE/KOF24z K6MRBsepO7JdUWWk5WPVtFjBV2c6RHtI74uSClUFuOzdo6jTAKcaNmlRhAvZFboEODPy6DG5T3wv yqTFxhiIePR2jvImjdLFqownfEmSd/WztgIqTC2Ejnq4TjVihhQzV3Ev3LI4WPEewX4w1msb/Xdk pj5lgqGKbyhKlA+8DN2fSwyvzTlVztREF0+/1hoBAOePyZWtkUp+C73GPSVaeudBThy145O3OxsC H1759IrPVJm6rYvNl9aQCjACq0g13WzB+06vXFebYXZMVcUIiMdaRrzzsgNKUxVaYWq3tBZqEkOm m/5GITB2Kd77DSOSYEDl8YdK35iLzWLRau5ghLAnxrdzg5Mfgki/jYivqLD0zt4shdw6R/zN3Y6H xCtznIpHV+ZiBTPE4ZGPPbCSNDNVMXeOEWiN7o7y0UIBFMQc1dxxXV+pGZJfU12Ou32kfGoMHE06 sFH5P4xm6lEKZW5kc3RyZWFtCmVuZG9iago1MCAwIG9iaiA8PAovTGVuZ3RoMSAxNjYxCi9MZW5n dGgyIDgwMDQKL0xlbmd0aDMgMAovTGVuZ3RoIDkwNzQgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCnjajbcFUFTvGzZMKBLSIc0B6VoaSSnpLimBBRZYYheWpVtAurtDkUakUTqk Q0okpFNSEQQB39Vf/79v5n3nzOw51x3X/dz1zCwLo7Yej6wN3AqiCIchefh5+cQBeQ09vQcAH58g Lx+fAC4Liz4U6QT5U4zLYghBuEHhMPF/GcgjIGAkSqYARqLsNOAwQNXdCeAXBPhFxPlFxfn4AAE+ PrG/DOEIcUAB7AG1ATR4AVU4DOKGyyIPd/FGQO3skagwf30C7NYcAL+YmCj3b3dA1hmCgFqDYYAG GGkPcUZFtAY7AXpwaygE6f0fCnZJeyTSRRwE8vT05AU7u/HCEXbSHNyAJxRpD+hC3CAID4gN8Cth QBPsDPkjM15cFkDfHur2h1wPbov0BCMgAErgBLWGwNxQHu4wGwgCQAUH9FTUAS0XCOwPY/U/DLiB P2sD8PPy/033p/cvIijstzPY2hru7AKGeUNhdoAt1AkCaCmq8yK9kNwAGGbzyxDs5AZH+YM9wFAn sBXK4PfJwYCirA4ARiX4Z3pu1gioC9KN1w3q9CtF0C8aVJUfwWzk4c7OEBjSDffX+RSgCIg1quze oD866wiDe8J8/wS2UJiN7a8kbNxdQAYwqKs7REXhTxOUCPcfmR0ECQjz8fE94OMHIK4AxMvaHvSL Xt/bBfJb+VuMysDf1wXuAtiikoD4Q20hqBeurxvYAwIgEe4Qf99/K/6LcPn5ARuoNRKwgthBYbj/ sKPEENs/MKr5CKgXYMqHmj1+gO/X8/fXE9R42cBhTt7/mP/uL0hDTdnEyIDrj4z/1snJwb0AXx4R YYBHQJgP4OcTEQBERfgB///S/F2Av5L/LdUGQ/88HN8/jCowWzgg9kcOqOL9lYfHn2PB/ufKcAD/ jaAJR80yBGD/Z/TN+IT5rFE//P/PC/Db5f9v7n+x/N9G/38PpOju5PRbzf5b//9Rg52hTt5/GqBG 2R2JWgsNOGo5YP9r+hjyxyprQGyg7s7/q1VBglHrIQuzc/q7jFA3RagXxEYbirS2/2OG/uoCit4J CoNow92gvy4bgIefj+9/dKiFs3ZEXShuqF79VkFQ+/TfkI9g1nCbX4snICwCgBEIsDcuqvUoJAz4 8qM21Abi9Xu0ARAvDI5EuQCo9PwBWzgC91dHRcQA0KNfot9IlA8AKf6DBAGQyt/ogQAA0v0HCQEg /b+RmCgAAv+DUJzWfyN+1ISBIH9D1ClBf9TwbwkqjC3U418mqEi2cHfEvyiEARD0X/ABAHL6B6K2 DAT/GwqhoqMu4X+pUUf9Fxc/isvtn1goX6Q9AvKv6KgaID3/4PtPqa3dEQjUHfR7GVB9+Av/vvAg EC+INe7HWbi1RKhDbWjr9xpZGk+ezVGs5dX2yATjvghhJOuHAl979TtZSpOucpY2VZTD6dpzZc/e z/rRcB5+H/My68oJ/pSmnI9Ee9S3LnfMUzh48bXLDkJvA6e2GxdNj1wnPkrUoSO0NL1lypb8ePYq TLRbcLt668V1u9u2idhnwBl4eUbEmEaDjJXNa/+MEW3MyLyKHDI2I4ojQZhmuOurGIxfY0RD487l WmOoLrzXTeMyh5aWBnLe9aULfilS63klUvWMlIrMR5Uxbzipn4o8MUe1yQ2NVU74TL4sIaK880P0 rcoPiCe6JpwGwLRku4XRjcyESXGoe5sfGn1HCJNHyVZK1GJAdqfGibQvjyJR/+7Fo4FOI6a3KZw/ H6qjIVSqykTMGCssHLStZcl0BzpXdnLoWlaGYs0mJ4pVEp9ToZWp6daGEem5aOQ+Eu6VnitfhxJN huB3MLYHOGa7VcT3EqX8OON4NcJtxdV6w5Fiw+wOnzoasD6Oq2yJcP4EGWBoluwgo+9oxGd09+Vw Y/cXPej8anI9dcmTGvbIzXbpxs0qPjPuy0Gv9nGKI/oMiVGJFu38wON8VXYZ8WrsdiHtolC1FHsb w6TF683baX7LWW+fTL74sGKrd1JEnjbM9nGq+Ir1m/GFDDpTPtlliYjsOuWXtVf7tMr6jHnCX5IP NBNjEQgL2u8HlmMyO2uPdUQjsBv9jCvkaXeqH6jUfV222Yb3XeEI+/bK5nsndj++zecUmJdzIERy i7pSBNLgY/nCvatSK6xVgKJdviyIfoiWmTIiM3lAVX4v2/pB6mvt+bzSqT2knX0ORW6K1sG6kPV9 X802KhJl4fI9uoRCbkWqPicJxuKS9mJDGhIeY9+x0NVzsqWmsNsKWi/MqCcrHzMNeb6+34XlloEV T1yCFrYUxhK/83znfqDhtMJa2xd0j6EIrrxGtAFTdqG6gMChm8kH4DPJIrLZKbHS7GdZHGn9P87k 2BLEXQR+nlftye2/lzUwuDfBfBRAMu+z2OF6LJya9eWs3OEUruwRllboUzPzBGpXe5rTVOqgobc9 lsr+/YLRu5yjzWz9FrZLfc7pmyxTWA5d9wNGuIGSPSlL5mMBykjOWXMnL9WaPHfc97wsogA7d9w4 77C+YeuG2BmVh9qlz3yqfiXFCYdaHcXEI5kSDIKjsqsq6smTiFDc3OWytwlJmzTL1SXLnwQz5wgU S7JsWPa2G0Qu3cjfOdZUVuB0FUEZluKSjR+d6xj7sajs2BnJX9iShAxblDXyQZ6VL1HU0gq0w5l5 28arNsrpP6GB9A+H2t2aF3navVVcNX2ZMRT3qiijexdodd5/5i4abmrEaiI+bTZokU2+fVuHDUxq nTyc9VoADnOgFC1Xktkyf0/wCRc0S/GpW19qRj9xXGMOVL4wZ/vuzY5iKNvxrMBZBMRY6DL0pB2K q8XlYOnwsc5j7y747MIz5usbD84x8lt2T4mnlEB1iEzC94Y7vEF5G9CSKY4F26aFRQh5Od2PpBql JNwE7uEIHy0+p7TG+m8ZlXQnVk9962rMhNnO5cWrT71LzcicYLzO2IEDzV/pRIl8ZjDZmX7UFBlB nDxy0WV/3Mwv2BlJKEulr27kdc5Pk6HBNYVZRh+6u7GL/vCfVBtyXexxWGM2yKdmN2eoSco6NGpQ q1oRNCCZt7LbX7nd8cKNrlmBZtdG+OQR6d6F8RONBpKtKAnIktoosYv0kKDybQnlZxOM5kIEG23T 8KJpjfbdO5lvdorsJfcaXR9TNCbr3LwNqF6CLXArDuqrlObEWAteznK3ttj4y0TxEl+e5qzPZB8a oZ202mryl3PNNFjQU2kHpZxSY+iFmx5L9skJKJgXkUAVzfFe3ZWJcOVJMMJ6DKIRSEiHihfQRWsZ k3je169henBxHH7w2T6UiZKraXJC3oBzRke+Ec/TNbOl4ynvWCMBjfE25Tvayniyy+/0JNsFpapY 0qdgWVIRzblxavhzU4/Qu4KNtY72okdGUwHCTJZ3dbOFkOKEd3auW767NdK59ORLXVt72UpHRpLr upO/tVCNHb56adpKZxpyP5MATjY5UXlLaSon094g5d4MmYU5JX5XZRJ1oaS934j/Jk7IPcvIlrYy B226UB0/TbEfGYP9zre2gb65ZHMyv2Na5MIz2s0JcwqhSGyckTTkSpsHVeyjRRcCwwVPL3y20pp2 g4SuO0yLHnR7gHpR9dv5TAnjSpCE/9GRbzF07sUPl8rGr+Y4gk5eJ3eXt9pSq85oszybuj6A7w9V fCujlYtmQEZo4cekhnyjgSlJPI9BFPYLBtlVBJblXV7GqLFk6T00F5SlzhPa9qqJ17ySxqsDhY/K +b5LP4Mq6+3aGMx8bI75wMZ+EbLFGyh2Dzi+dcWFT5Ra4AzB1CVzvOhhUsIjaR/ginPxcDkFqU97 yb3kPBJl7KJw16paRG4GxmOs12W66HNj8e96ynslGB2fcRUDcpbCfOVTdmaIYFZ2Bd1R1gg/etGK +wQ26EEp1vJ1uJ2kb78bhIhuhvt4TrMtzvY9aPWJ21kreqDQPX+6ySlejF0fTir/LuPlOJiwo51S dMau/3UyXTTOibSQ4X2r2nCBj4S0nZYOyPvfkgdqxNWA9ZTJIzozQzKrkIhFLHVKGNd1CYWBg/MK DhFhxUP8wsmtMMyYSDMeSzD76VzvbIz/VsZpENjijaOZPJpogLwMdZ6A4Nu12dcgngQGYTZf5hdY tjS+qUQlh/eumNcT8Ec6xQbvCdW4naq+S4MzlchQe4273HTiD3UN3vR8edjRRE1G5qpM/aqhbvNm +sEJ+JJYedHioaVfR5oDri26atZgvzGIIgbtQ9hw7eanK0Mz1ZRp+ovSvi3DR/YUW++v7KU/m7kq xSs4frCMF3sIfr9qKErO2EwYPtfEWgrbjDiVzpPkmKmgrbxsJhE+t9BS1m+lGNILWcLMvF5OYs1z v8/FziJA/tTi6XeGg4ECmV4iOaqe4RQNm8EiFwnLWBptfFKq51PBMUd7UbWOhRWLrqO5BzXaaJZ5 sXt43UkwiaJb+5qWhz+P67ZqoA1cuLTEMLbr5Rzr0/WxCT3uQG9zjfe6Qs372tUedxjzs3SvvPbB 2ZCe77bGDOQvGnejwP18qoQTH775NdVZBROJHDt+nlyMvcs6AEQj9hgk1o2/S5nUQLhyy+8z2xxB nrnFS2wsSotqi/FTSOkVvsLI/hbFmq4gycKbjMvCzqje2DePidueXogvPRGc+2HQfu+pRV8WGE+j tOT5RRTavFOgE0bd8YCvQVXWfMfEqt4WC4jcrJsRk2MzIdPl4NnkG3v15+JDYc64Exg/vYZf2h5C Ynl6BetqIyaH93jQL+cDDSVHY9jHxsuSq9HvqJScPvzEajDXWOvGlAgk83F/6p2MuwVpKObA+lk9 YcZ2vrtTRdJHy/CmDu+i331bMKHeudBi3soCUYKW5Fgqty+g5pZdcWMrB2V5m8FeBt99FNvbZDIh k0fwHNtE+XHZkawYJ/uQOgeNfjpbopChKQgK2+sj+nn69M7x86jv32M+BXcfEhBJNsWkz1ll2h5E 5NLRoKU5cKfv1PQGW5JHTPfccAwWz+IIy2+6CvpGR77XCgG10peJ3TJpUYKkUBead0tOTXRY8sdy lh694r5eO6pQB4uLiUzi+KtS0HzC22TmFV9pwWsboXxNfWwKtvBkiKiK6scwB4lHtH+EJpjtbuRt eEI/M0lbMnGM9ObZjEzbbLNdRnNPsnkmD/mreMr5SCH75RoOcgZFrLcaaaaQHeQ4A22p15m9Gdmw anEFWsDhOia6WoTkW+2c1cz9V0jsgaullVGcTu6xEYcGNKMxwdToCYOs8j2S+1ltfu0XtxXYpdvG WC5xGnoAdI2U6hBH5VSbN1YyH1K0Vt95xB88UAyW2FDYDigRjYZbgpQ2T3fibO2WZbc6u3XJqvwf iElLXw1C0nYErg6exqy5ZH3ZvQ+04xsEM3gRun5YNoyKBwJclDwedSlJ4EcMXYfMP8k6M3i1bWFJ 0Tm5KBMOcya6/i67TtckazRWH1dy6fbe70LtOfVTZnrK7G696ufR8wxive+rD7OsLlIE3dNO4PSb McQl4lyJ0gy0lrmKAcvl3sOrFQIB+fS+pK+aqCwmS9MS6hzFvuv2pK5qBmLuS65gruhaeEjPMCv9 PCZCywucdSaAu3z53LGjwmhor11Lm13icLA4TGPw7H5mUYIybkBCTJrV8WSIjZKYIdm5ukPxxMSE U5XkkxH8WKYWxloP8mobGLsWt0CuEMFORxePUpx/bct8zNgxo2vybtpTprnQtvVIicWj6w1hqtf2 DW36DYWaodLdsSeHZ+FhU6pPfOGNo7gerOlMtczblcQLvUJv9N1Yn4z5XssYRPDeorDCARpME3ga VC0CntW8pmzXHn+i2ZQ1lXQrddD2bmx6VZjid7s7lmf9Gdqg/vF6mB7t2o1hkzD6oe00uvgag9Q2 g9PXngINoJCqYYcylfITg13KRjhJphpn07PgHqU6XJFFLwUTjcrBWZqv6qRjciotreK18bb+kAn0 56Hxk/X1ZqoGCFBapySNmZ/9eBUso9d2wYaTiDcXQ4iJOS1jJd8vBBxOG2lZSBMgktBXqa0syHl+ mBnjLUJD3ao50kq6i4+rx9j14VsCI8bWdU32t46HAbeDl46BeA8DhhX+MIKhkU0BXWZNPjdSrpTO CQbqyyvTcgxConmT+RqMqg6BsqRjHpNTYYj+gXlROYdSvUEb+eItKX3G4Rt7tJIO30Qt6gXBbmbr uC/uFV+9ltWke0YRTRHnT7EunlTr2h5r6MvbOdWW34j6AMIG1519aD1FWgqf8yiFMettrVbe11W5 3AF27zrtXQuhVx1b5rnlOIpF7a+tM+XbjbxS/Ir5SAR20aPmo5xFdIAgzv4Wqx3UDzn3qO+1Ur0n dOfRqcTHyacOtYbxexcLDVYGoz9dMsZxUq4Ovj2Xr80rvR2r9UbwtRtPsznOZxX0r9LtOEpq+er9 8fZ6LHTMYSWf095HL+uR5eJM9KpKm5s74evS3tKv7N+91Ke+e5ceic3+8+aqFpTYyk23waxg7CHt f3jmrh1sKrAYXitA4qtKo6lzw4t3vXcIuGVv89tvVd08bEKg9TbRnw+k6zK1Bc/XrUtwvTfLHsbO SnZ8R1gh03M3TshJfQlPfsVj5mFaw3copWEGbTcx/OOXHffTmg0xdPmXu9+lCZuog1hZ8XLxv6c2 57jWeZxmF5HKiRexZPxckbjzoW90UF3nTZ497u4HmomF7eUUEsHZx/4thc2R0VD6W9wnQYRLuITJ T2lgUqKBmEtHT0gEyBqRLGzM0vKC5z2QgXcVhYveWOyYxHkfKmHYwhjdHe+Txug9qerGFFR/enV/ /kHOk25QbF+fcES2gkNVkZUmi6G1CaXws7hf6tC7+twzzk5DuO5i476PsjgW5zbYHNlt9vZkN2zb UTdt68Zc69wJI0VwC3LYZhq/0yq0vJf5pveBomfI0WoEjLaYn/bmaStMgupuhkWO0XP9Eyz1dlmm 72bIbeK04xtl3ylxvLOu7XiA+TEo9G7bx0EQBGJ1S0ByPJiNoGcsrzD85lv26TMrJ0Z8zY+C8xm5 q5I2q+Fnu+r2XTUGjA625DXt/cLB3g6huvnsVLYScFc72+NZb0AFIW5m0VXbN6aLA+F5Y8tW4bwB saNg7lvyAjoM+qL6A3LbiMLI+3LSu3w8apO0ET+IMZOtrTx+EAbKYRHOtrDhFBIdaOVbtPKQ9L15 ihhvU9bb2FpXYRBlfVWAmZCuMy/txvmEAfi8aytg/BFatiduihPGqOPopPKhaIAgx9N207irQFMQ M9a+OMmvVJHFpNmUlt82zPQeAa5SyXTKmlRLcaHSK7ZNRuiVgO5h8fkQumxOdO6OFknLXkbyXs+5 1RMFLabxT2LZouLJFrchRybdAYebUptPt/GjSyXJGdkaitE5ptIWHhu/OJtld9/21ZquFZo2ff3O g35esiMEv3y/LfrnRXnhqJK/cnQbZpYEuQlRsrp/tp3lDuHtBa00IoEvQyZ0ovbySIbYAP2tgnIi LrxuyYExOcVoatkawVZq99YAnA8tVHO6I2HvYi7KB3XXEA6cmjMv7Q6mEZ75quiCeBNUPST1Sj8/ fDE7heCXJ21tMMHb35JMjNFzmR8P4zXVx5kttFoWmI8M5b+dXn3ZNKtIY7R4mucg0u3s5/FGLV2M bLr/h/ST+vESYofAZ1qEc5PRPPmjWgRO2z3p5KoQybr37Y+GE3sLjwqELZgeu1OQ9l0Fh0rsKzqO WqYF5CW8WBDRbZ9o9dKhhjORpPe6JMUP+w32gsp9fPF/CrZdnPjpwF6n4sk2bjZIp8f1Twyf3h7I fFfRRb2geB6Pfp9ehUfudp7QObosK7/z2V41kd4EJpfWko38Iy6A/qUgy7yDUu/qJJAohYa+YD2Q Lcpz9/mdNuwz0fzLhrB3TeY/w6kXcCpzEz8FeRkHGNQM7ToYkjS1Sm3W9+7kGie7TmOl+Iokeuq6 ftyLry5nfZeZFXevxG2ucvdc/gfaTdOK5baPQwnO2E716UIn4QeXrZzSkh/UBb448v2Yxh6+XLsj zieQp0sxDPqORIM2Ub66x7CiH5VgmVeMx3OB8r7Tr8qmDq7MghOp/c8lUkLePONZ+EkWM7KhlLUT /0w9uJktf8Em70Uq6LpxbqCGu8n8I6sq9elALHy9n2jbzlMLHOpDY/doVJiypl5W2fSxP94Va6GC H6a9PeMKs6A31onyi5oNgrx7JWCSVf7hcKzHJCdJSvuCyubsd7aIYuKWQBYBIbcISngF5ZXEMskN jnmUZ4QfzJqRLoNeVkViQTl05GPQtVXFPXYbKxTUpYhP4t2abd+yRx1zkUQFKQw0x8mctIZ7newl Y84RYXHufRMkJ6Ka1YrWE2dTYV5j2BHtvffEmVkn++N0ApW0I6ZkvY+cNZf4i5fXhcKVmpO3jsLJ 7p3xCjFYVSqVMBNp6NM45XBpeW/TKFYcOPldh1vlS+OuZvZ94zZUcat26XEgceN85KAGC+SyAQsn tAkScLTWMiPo5wxjI6tVNIJPs4vbphKwS2W7ZpdKSZB7T3AAx9u9pgext+OfGsTBduRKBFogPR7G PUIgnyfm2qN7wAmabDcdEfJubiSt3UiEPsek3YO19dlJuDDNDypVK6qAYhWH1f0jMrNHXArpRm3J a+DXAilUFzZPo9QfT2PAfGfX7g4iy73rz9yjXALBsaxz6BuJo1fZ4jpGhguyC8TTryDlFPcMKv0E cnlDsezlu3OfUQryaOlaVZY/TqJ/HJyxVF/f1NEyQzM9SCq7S3XuVw4t3jRLXZ2XE+tbHsbEpaWj L8PKDRLr77wni/cUVCvW8LNJtWm8BfXnkvqTC+yzgfvdtCuteUUTzuXzTFyi1z/falLJS92ekZIU /KZZdjJA9DyaF3t9rUNF15exFbrnKn89wJrhxFwAam3HifoAJF97yeacu8WvBkt3HvS+IiKkdI/1 t3vVEt+2tO86jzEQh7Yyz+zs9yy3QXnUq9wBPk6gomplTYjT0SkhyRR8PWANhA9BeT9z4oi9vBUs 9n7bDGMxflMayu3I3WaFR/V9xehrxSBnUs8pSBa9MgJDObSTsn9i2TKrx/CbEdPhDSY+NkbitG7l Qd/EvmokaWTVW3NuTuGCakEjWmnMirzXruLUr4rorqhKQs+7Igf2XhqvXe7ZmuqPD5m2p9XlQaci PjLl0IvQ2bbzZHUnjj65GPnknLNElgmES3ucRr41j7BgkIsTnX4gRf+5flpOZUDvyHX8B56YUypj opaf4DeVqdtG9fzpcg7Uz3bJ8cXpe78nFR0nPd8wflFw2XzKkyCvqrx+mim1bLGcPLhG2aWz/SVY cYQ5pLfAW3zYVSvb25cVthxtB8wYrpevvxsFrvjWo6oVZ5Y00ZQzBT/m9qoo34vXScLtzFbw4sPS LT5iZO/Ji3+xilwNejvy+vashiXmmEzT/cK079jovWhf/fMTBZmO68GCTiw3cl5hs36NIFC/C9/x ERq6WkjvTd21tCj2Vp/OZyLypCL2K/+f3nWqP81rk5+VuT/foiV59ohuopj+rNv585fn3dk4zQdF ownkNYsaptha7gr6lR29P7pDh0sttalU+a/CL1qNKiDs/FFP+m1sOY10P+82LkvzroiI683h4xUI zEW1ktV2B1qTOk1mwDh73S+dp3mlUvXtvTTErYxJmIFk0hq5OsKV+j6OjBQK9Dn9WBIy4enxnBZs Z2Jnw7K5tZOCiyEL5ocrKUNTOa4GTQvh1FEqRKkvXj2BEL8Z9JF5WYaNGBMVqysIr9L3HiCFS3w2 yzQZeOAodWYUzmnlfZ9sC6O+BMvohKWKjxjrmMHkCed5m1p7QanUGHqMQVSVIGtR99OgI/+p4m5j 4QsVXdFIx0G3gRfRXfqsG5cqn9PyfBMt2undQ9LGsGhUbxt5KxjaO79wy37U3zeHQeV9EUGc3tre +uN28/XbHyXdLvJ1n8GnGhwASWc2tHyuXRbhIpIu/bUSjxw6OZEj+PVpaDkHKyu+cAHN4QJ/0COf +thSP6zguSK7A1ctQ/rK+IGSt8Q5gwLMNS4Ur/yZg+ATXarr2GWf4rDk7uyCYilm2EmZN2IfI50r 2E4YfZxk4yNqloUaHT63cCRc+CmaDYXPSqGJIXVeIBw+LN5/1gXiY/Qt03LDMj4wx5az7RQI0acO SkHg9ddjhliVKOfU4oIR7vXtuMdkpt/tNxfJuwuC9d8LX8vLveSqDRHdIUjZu/G9lWvpuFtD2n7R a4Lj+RVdQd5BFC8nHXr43ocj4ONhlj2UkyizDeu7lsBNtrEQo1RlfeQN1yldfuJ8DkB5NWQmm55n Mx3ksGqVqNVf9SW1Zvw84bEkEW2eTVrFndJzf65eKZdNbTJCd+gBlxFfeQCjaABGl8m9LRrN4Gc2 vFwc6FEuggRNp1lE4bHkJUHjnhn7U0U9dCYROvl3VNgFfFcbJsHarvd1ZILip8j3Kb7cHPdwjxZH 34bWf4S7zdg3ZTN7Lnm6fUO30/R3nTzLxdZ7dRauf3PootH5QGZBbKEzccCz6bysOfsM8ab2tHrU mQr6hTluGYiuN9k+v1tKIoCQN+DTn4sJF61tNv8iFejVPYV4/i22NChqSnqGTe/2S/T3Xcnf0gdk XIP2Ze1C+kTJg0aGf1wVpfNYm7VOiAkyPalVV+cBGA8y+CtM5NgZzfT5EuwJKx2NLWizMowQPROx 14PYWDS9S3M5pgn73Ri3NN1T3oU622pvoSdxK68NHUeTKbVJegu0x7ycmIg9FyM+LHrOhvZeohu/ PVdo8NCkdaA5kDiqACEcvRog7HIrslkpD98gDb2htoU5+l7DJ5pYE1kBsIBfuklZBvjWcIZmPXON CkGKsd4a7xlaTaVi3pmvhXT2VvsmQeBTo31z4sNMDQP+IK35GM1t6uSVr0Mu41ND568ep2LmMxsT MDjBOnUp9gnzEF/P+aS/Fd2YPSE9lDLuQyfMkCBiP9RaDFgbYSX7meKn016dtSXRm12Ma8pV+OGb bbB5oUgJNyMLTvobtFd66h3m9nGn5PQiSlnVb3/erRS7Kheq8iDB+2TSXkdT0TGgJ8K8FyHrNaIj uViZSGA4vdR8y6Px9cW+RmmDnZqMBlPWnqzq4v6nyU+hOs+h7985FMVIaW5gfZUeHoddvcpnxCJL P8Thon4sSMepUpiN8UbOhJatqYuLjCBcq/VxUXgAH9A2PmdyX7YPHEncKlX3IPt1rQYduaux3xsp 9Ei5IH7id98ZN526Hhvi5n+mOYC3mPkUO6Zqqa0ofqHoOqQoXF3tV0j1I6O6AhFydr7IXVUKbBzT jo8FtXmm390OH3kCBJfp4TpGyvAuxA3lhrDfO4lcmHG0hWV3LEn4W5SXv1QrfnMG5Bx0kisYJTes CSJBralhL04/6Tkk/LhRM+PP2WZfCO0MpCyLAPCBDF0pD9ZwTltFtpX+b11Jc108J6lKusQPhzRz L+QcbsssiPdcOt8hmQrB/vJ2fslJ8z5TMsbHQGxr4ZdfiheZ91lJt+VDzsJvfN3mX8xgOPr3e6t5 R/iQvrwikFmD2h3mTItrTiS1cLGCv96TnLxO+eLu0gSuJSVeYGhWzvm008okmSbnwCeDJyr9yItr +kuBdFBR2wXVV/ScaelDHNN3JKtzdebdW7VvC3NW9+Qrcrtx8K+KjiQqLC3tSLg1kYOsIj0r7IfS b/F/jA0JXqLVt6nG2OAUWPIncYtIYry0sC9FE6JsOKNpmn85asnfX3thFFzTRlocc+FasK+zQ5Wk xoeYuIAZzyuasVWLG8SKyJtn2SfSbFQgsA5e0EVCZllnkwzRnmPhEt5poWa6zbkRNXU8r08xPcon gjnzFC/SBwYjGGgJ74ijCxtg+niHr4IhKdb0cvQ4VMUuyWr/3BE/kuhszJ48r4VYfSQxkggTT5ah oeg9yDnWPXJXvSXZeQ03iH6mUCQnssvZI+SSfqMsAu1DD9Gp+oiVWnWYiM+mgVKYunD8dyuNNlWl nHRf4fK+h3RdH+mpCJuZ7PsoM3A8ky7m5DX4R38s+5g3bUoNXE1wYkyyIk1U1ounovOlqcTSthyq AzlpWe5IjxgnHH6pTmiQUFFesfvmS3d/z1sKZhN8oBU6oVzqsob2NjLwk3eeXB/kmJqxMHQ/hYWl yavVvaAI12bBtfWTj4hXM1b0/wFCsIrtCmVuZHN0cmVhbQplbmRvYmoKNTIgMCBvYmogPDwKL0xl bmd0aDEgMTg2NgovTGVuZ3RoMiAxMDEyMAovTGVuZ3RoMyAwCi9MZW5ndGggMTEyNjAgICAgIAov RmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqNdGVYFOoWLiAl0ik9dHd3d3eLAwwwMDAw dEuDdHdICEhKl3R3I4hIKiHSDXJx7322nnPvj/vM88zMu9b7rfrW+9FRaeqwSVlBLUDyUEdXNi52 TmGAjJqOjrQhFyeAk5OHnZOTG42OThfsCgH99qDR6YNgLmCoo/AfHBkYCOj6aJMFuj5S1aCOAGU3 CICLB8DFL8wlIMzJCeDm5BT6DxEKEwbIAt3BVgA1doAy1BHkgkYnA3XygoFtbF0fM/3nL4DRkgnA JSQkwPrXcYCUAwgGtgQ6AtSArrYgh8eMlkAIQAdqCQa5ev1XCEZRW1dXJ2EODg8PD3aggws7FGYj zsQK8AC72gK0QS4gmDvICvCrbYA60AH0b3PsaHQAXVuwy98uHai1qwcQBgI8GiBgS5Cjy+MhN0cr EAzwmB+go6QK0HACOf5NVv2bwAr4ZzwALnauf8P9c/pXILDjX4eBlpZQByegoxfY0QZgDYaAABry quyunq6sAKCj1S8iEOICfTwPdAeCIUCLR8JfxQMB8lJaAOBjj/906GIJAzu5urC7gCG/uuT4FeZx 0HKOVjJQBweQo6sL2q/6ZMEwkOXj5L04/r1ie0eoh6PPb2wNdrSy/tWKlZsTh54j2NkNpCT7D+vR hPbbZgNyBfBxcnIKcvIDQM4AkKelLcevJLpeTqC/nFy/zI99+Pk4QZ0A1o+tgPzA1qDHHzQfF6A7 COAKcwP5+fzp+G+ExsUFsAJbugIsQDZgR7Tf0R/NIOu/8eMWwMCeABPOxyXkAnD++vz7z+xxz6yg jhCv3/S/LppDX11eR1aO5d+m/3VLS0M9AT5sAlwANm4+TgAXp5AQQECQE+D335H+ncF/+v/LqgkE /1PfHxGVHK2hAKG/23ic339acf9nPxj/kQ8T4L8zqEMf9xoEYPwtA1NOPk7Lxy+u/28x/HXk/6WB X1H+P2TwvzXJu0EgfzEY/0P5vxhABzDE6x/O42a7uT6qRA36qBXH/6UagP4WtzQUYvW/PiVX4KNW pBxtIP+OEuwiD/YEWWmCXS1t/16l/9zEY3AI2BGkCXUB/3p8AGxcnJz/43tUn6X94wPj8nhff7lA j+L675RyjpZQq18q5ObjBwBhMKAX2uP1PyI+gA/Xo1ytQJ5/bTiAg90R6vp4BPDYnB/AGgpD+3Wr /HwADqlfpr+RAIBD5jcSBHDI/oseV4tD4TfiAXAo/Ua8AA7l3+gxpspvxA/gUP0XCT4i/d/oMZ/B v0joEQF/IyEAh+W/6NdsOKz+gI/VgH5D7sdyHmcDdLH9wwbgsAb/ceKRYvMHfCz5DzLnY81/kh9b h/wBH2tx+A0fhcfh+Ad8rAX6B3xM7PQv5H3kOj2+wo4QkLXrbyvXP9a/JfL77GNVsD/gY1Uuf8DH 4f1B5n4M4vUHfMzr/Rf8rw2xdIM95nH9S8ePI/oP/uvRBoE8QZZoSwtQS5EQu9qQ9qsaKVIPtu0J UaTD9CtDbraJoheorv1yM+briTo52csq7+SX+rjkX9h1qks7X+WuLp76bNVR1nvxXrBRyu/YUFrE LzxcwM8l+VySUS9gNcO9MUiVphAugfXDaZJHYXc9lbCy6dehw/JlqO39mORBj18qL6Ac2q7e0VVT mq1KSCak/31D27XFYkh3m+/sOUPehkNc8Ga0aWSaeia1imjHNVqiRzX22uDI0ApOH3l3VKCye9D2 EW2YK46cyBCZLC9Ktf5KAeZdXon7fiauj4UCnuS+VX/5kldrtkiBpwZflnZdt+4JagKbT698z8db 1QJo6rsMWx50yp4bTZ+xme61SEgxz8G9qoTLk3oR+XFprl1dS29iDxsV4MBKgYgfIRJjuJ+Y4Y5d JyN5kqlaMzzYc5t2DFFLUIHiXrahFuj6vChjht9FSYDYoYtWujOEItNeimIxoeo7RTr9ioMVgpXU QLSZfEzzdGE+18LLDT7s91UjyWZPPiEo2EO4bVO7OgXXK4WDSF8pfY5VD5C85ZRDDlh2N9ZeYDyI fO9RlJ2pt5s35X92JvnGZJ2v2x7LKmpzIJBFGjBb4ajvQXoUEik2lDfRjYlz3s4buCuHzLqNeJE4 SwjhjvUKOZd/Sptf38pBNjv8drjJgKk37l1QMDdsAuuNSkfEtFa2/A5+wiolxiHS0iEvOsrWpVd4 qABd36WCdvB+JqwIzofX/8y6lzHWsYwytu8o7DtJD7dx8nnmcOmtApv6zUsbXys3f7zr1w2OamAR 8pdyiC+oFLpbMl/ZFcVcVk89kTDgiBKTu69Mv7QIjm4ed76vkThCX/0YeVXheI+yMjAoTnlZmSNH 5jQVUin+1U0hX2jnoUNerZA4uhvZRGiIQDC+rjpPwuJK1bxdSqBdGb8Q1Dw5Qd9ebJZwU4ZwW2lp rhVoTESHPlqsaXftdCQ0jxqAwZOHFlkTXaY40e4tUSLqlJ7ZxDs1IPrlRVtPGHSNIGgyu4rzWXnB Vm0PerJwOr5nJic4mho9fiQt8voK5VVL7vFhxWEaylVGZZAinX+G/EKP0To06FYpkYlOIO/H6y1K w4BmVOaKhulO5tUCHP9bINmQlcrM56CFJ6bTb1w2xKaqMnZHmWK+8oMNxgdyWUZx1hgDneF/fEnV OJH5xKZPsd/PQWpk+MJGNlB0jLiY7eanx88jlljISWLtUJaYK4cFZvOMkYRUlXN/dA7yz3e7VerF 7iZobww0UnPxeaCkKU8BF/YZggWfhraQGpSQdFnHuHN5vvmN2gh2iqO97RIB4uSCp+vebiVKFFep yQmx76e5re1yvc+x6mJZhnsaDPtIxBHd3MuqJTK009NoM42oczxiOk9I/OmEsF6Uz7Il4dB2t/N1 w8xlIjEFIAMKwVPDM4fONTiOrKIsp458F6J4ctHTIOJNOSVs5DGGC0dGYtWSAKTVdrqHlX2dnxGH 8jrg+WRUrN31ygEHYU5OBN+2YwdFUKrR585B34i9lys2JvkD9HnHTTap1fYudSrM+ryxTedmV8UT dlSnqO3M1GFJe9m8bpWxvC6aatZCc7CZ8v2qV1zYZNA4c/hUbWqBL6JKpR2xJijXlVmv3iNhx/YJ igVwXSRIB/trhsgaND8oJguXSApTLhDHaEZSGzmZ5hlppPrRhQU/VQhavy+54QqrJIGhv4wxyENI vNOc1JDO+1w7wc4lhWaYZd0s6DElZH+sRr05Aoxa6SpqBX0mj18brr8BAD9JV54Qen8KWkyqpkDt o8z9oZKPMlh47ceQH2xDkj3Mc0U7Seh/uGT0FbwyzBwLjCRHDLKpV6NRa/q2BJJm9epqFnrIfTYu j2cXHMr7I/11UNxr12TGVQWq5KFF4eiASJoc7Hf9cCI8XjuVwYdIxYHXzZLNX3mCQ/I0c+G/TWk8 ZFL0lo/Ri3eD32s+KQhKkK7G+yBanmbZzoXnz/rs+qWZB6xsQ59+QS+rLiHqU5k6ujJXTkVKrWPc sZ4XoefM/g0hZ4FX9Iv6it4djgrWF59aE3+IARNxu31UbsDAzKQRjgJUBCufKXiCnioReJWPz9cs 61L6PMPGiHabnAV/fOf3qejJL+KWjnO0oFi3ZsAlCNo+5Q0ZmrG+aWPYMyoy+4baJN+1rKa2MBj1 VhNSviJCiDePgL/GMrjdAZpuvltB7ks+sRfPn22TVT75yPAOJXqdwFk0lxHWGHq6pNmyT/kmIXOj K8fwCYbJA6+jjobw9rw4CtrwZKWnw3RheFusI+VNxB3Zu7deYaMhoDt9khIi5yma1CMe9PvnJ6eM aTlqnosQam0DrLFzU2xusX05HkU1IPZYWDGeTaoT68+DUTj+i3mJq3o2O2X5F9kGsSN9wbwjRe+S JDwud79WNf7YMuX0inrbRTqxxwKL7WNbwdKbpkklSRyrFEG4lpUVD5QbvMrM2YMPcsAwCqoLX0Ao ktuvJZvPYjxomi0Sxc1wT4dvvnX4QqDG9NZz3ieE+ATYthnCNOmRZveJ7Qk6jZdrRzaL9Xhk8BLG sa2xSTrZmy90zAxUPRXNKekZP9dyni0zpmJuxsMTJZInoJpOzffXerxt73hxZgfGDjo+lUJYPXBA 1KG0rFMHglPjCpXHB46jTWLRFhf4NgOFh7Pu9o1vQg50spYMEFMLun0OJ98fzGDzI5lAtE77WmLm 1bPTCilMfb7S30u58/v52XpekjhtOTmkLyBHI7tA9lTzdHQNAP2bVZR2yrIetvknhvsx5D6nHzy9 Ut50VFhtv7Sh/hJ3q1p8X4UPOS1UxE/xzhM1yDkv+Ubeg3SCOF05HB729mz65tOkOhvaU/qq7DRH tfiZcnFdMGxliYJv69CJJORDwdltx7XByDm1Va2eK9/8oVThmh/5sUas6UXvMOZuvW+nXD2EI2pP KyDZoV0LzQk/TaYECXxiCRQb6sEOC9g149qwVGWQIqLj4LxL+LEA+Yi7bmmDRIST8GX2RGR95Ls5 Do3GS5xyxVHxEbc86oO19Lsewkzu2Fi8tvE24C5ehd5zVAZFAiYcqvOqKlclifwzhqTLA5sfFolo XFmN6Hy+FYfY0ycFVHBflbiS+5aBP0HK98j3Ph/66N6sTb56P60lJ6sLY5qdQiehoqQLZe7jqOR5 WDJ+MSad4/7m+264jJZOXFcWJ+am4WmkyudypI+ktlby7aWfRAaHesaORzeOXjvRWyrPJJe980nP G+4LTeCensociVeXZh/Oqr4cSfugearBwxWZgjGxzvI6s5r2rYWwl9Q3/rLESuacnAPtAuGkpAo8 tRWYs5AohDq5S0Ok51quJu4LC/PQe5ITzJ4vG5cIePAN1LNQf1SQrhJ15sk6AqXPuVwYjhe1Jwdt kFitWNz3DEm1w58HnqHI3tFFcz1CPNgubPoZ8PIG35BBnmldg1OTpNWqmGOaNZI800dxD9woUjX7 azvxTnFzSqXemIm31tYH5gahTCn4+uQD/AS+Ch2EViPWqCazzHPakukBRW5qzDhbSkdPm/xQeTF7 OjvvS45LU/yY019VvMjUYnpbcas2y8u3alkelTGBtLGL8PbEKXNHvfHSA88xxcLUN5+v+2gyZfc2 5AcdiT8kywGuUJ+tJWkxaEsxhnxYR0DsKRETTW4eJ5eu46ey60gZVX7B4pSOvPdo2sg+lA05SixZ nvtZ7XoZr/phimrv46nZ5fJo6Q+Iwc/RVxHxb7C56vP24DQe6JB7XQ4M8xLSAnp9GmYQ+W4y8e6M Y7PSA5Uu5Ocs43UXlz+Y2QtScMDXxxoephXPHBcX5e8U6X0Jjm5PVhTrrgk/XmkJNWbfrIigatEI RIsgieZxqkexzNh9uf6eQVC7IelWnof8aVJMsI57VqAJ71Ky5HzgoIV5Rh2K4PHbkMb3aLuqyjd7 ca/NMerIdbcK8UI+vzhdD63yJbvRUIcj50ut7T6zhqt7YY+JzbBFnA77UpXj9FnE8tmI0rW9qSir OXf4RXSliA2f6WaJ79D4zdZ9M/f5x21+GpG3hinGrYYWsu5epn3RarZt25jdoYyxcEVlq+HnuwqR xZ7AotasMo8EgfVb1Xrd+TEUN3of/jWdF5oZJ0PeK7YcwoCKb18cx4YXirJiU6Ups2cP93+s338T 7vh4mZT7flnQShGkRT3j8RXKyf3Ohqvz8Nz9ginV00pdWhqRtpXze0+laRkWRQrqsH2RuXB44oV4 pcHW3dV1rypHJpb656TVfKjVQeKuGlvUmpMl8rWzL+JsvtT7tv5vbgHounArO59OAGMUPBDis3I2 9ioxvn7G+4zPmUGyF0l53LhvCgrNlOeoFsljG7Nzlki269FrAHce9y+GCD3H0FUkZNSkPEJ6DbTl LzBElirHeZfaw2TMJQbQty6v0Y32R28ewEV+BLSMEbY+1kTv2YiHfHeLSJje+RzXcH0NPVvaVkBs o3sFx2WhOLPG/1qvgrHukGczSwHN36nIjmBz77Dk5s7VplhFhWH8Sw0pGZcDwxpBIBcz8U8TdU5S 73wCv0LKi2jGzsqX5dk8RsTp6Zl6zMl7PxnPopTaZnj2ZC5pVE7iynHmYxJ8hk7NEVXx9g6/mBR2 6cGLmyP1nEd/A+FyNVxnpqQxiW71zFKaIKmTuJiw+PVzvMuiWXZVKZ5t7Q0UGBPrqbbwP/Gp4oI6 rKsiRI83kLGmnfa/IZ9+W5Q1gb51bxZ5rp/fv+d+dq1xlSXerv9eInkKFOWp1e1j5hPlFbQQrbXc DzV+viDo/Dajb40WjeKrfjL9G531S9xsLInOetGVImE6TvfpkZdmdE0Cd0qe/eRbHWZCHzONqf1C 3p/5XOLa1mimTw+fPmVLsGBQ7ya78Lkd79oluB9b2ENu+jglvWM4a2cXxtxoG1SvMGA9WmVv2WF5 aJCLt8UprwZdOcciAwAKP0udLRGnY2373w2i63dp9sRf4uYJR9HDBxB/uuMoD3HkShGaj7EchGWo b3/E5hJcZa9NphrBHFza6CWTeblwhnGQV9BtpPcEKc5w/jhu3mjI4765Y09cJAHNM8/oWIJqG2yc mFzvEqLbAmYc1RErvnxphCS7T30kgs76tQvzXuxBkfcejd8Wk4erhzXaGrQEbyd576vGEYYccaW4 /7IGl+O4fGLQdwLqXl+7jB8bfnc7uxNA7Lh9VdDfXfjdzZSonBRebF+pWqIBK0hPdNFbQgutpHfY 0ktec5HCurxiwcZ4cMz5h74GeMGMzSUggvrJJpf8E8lv+lI+ttPJOW/2tpx2bGynvqXu3sdUvWy8 Dtj+kpvDemv70vqDXzOn22yb92R4yfFcYpE/SSwOweuO2NxmBnFA2zCehY+tQIezBssUHoZ9Qlzd +/PQj4YDMcuBQNcXglplDAYyWLubuZAhJYpBItME2U6srKTR1UDzCq+CFEY8f16TKli203CtmdGM TeOG0zfoDw2WDL/7+akccHUkFkY9gZ/P9Bk9VUoAMWxXvYC34tzfpJFgxHosNip8o/XpaWp8XwBd Iv7TeNhKd1mAPIJBbAZnuCad7xhJq/A6MgmkXPtz6YvTeC0C3s/WGV4YhhU+ETOUntOnI+wk3utY 83pH0Suh7LL7QXPDBRL9zeLwJcP7BKlT5B4rpPPTR3ZIkRZen84FuTXOcNFZyjb9BqexLjyEm/J6 qh8OxFf6hhpVKkJJ0QgReFWbi+Lxg+5dlgmHGyuITHFMvjqes/dLB09MmmYjDWWhwfz6974v6jmO pX1a7o0hjl4gFXg3ugK+2qR719o8pWIvBPUu2kIx/xLy1aqicwr1OdNPjWNF08E9tIP+RS3jsqoa Z6rDCEVoGI+hyN4t21Bb0Ha0ZOcVx+f5neHqHeRArAosZHy3seAEoT2TynfOd1tn+c2xAlQFMAzt zi/suGKjlPM++aNhziFhbOPS03ysvCESdEpNfBBZ5maj4Qxs+7eWu3dhbZRsapkPmMySmzdkxjBF djxhJ2dfeeOcy5fUTDz+Oz9yTWDDTSkS4xlpK9e8lWvC7sSDm5ZfxCRJ5a4+pa46iMXwZ2scvyma /FH43bh4Mdmew1lITPBEILNKy90GrroKcSbcJbJ9p5MB7RNJNo308KrA3TIE1+SAFRMdOynfIPUA Xzv8FZGJHNk+IVGptwoaNvlPnDAZZwqM1/wT7qTpOOl1MtSlsh2ujVYZ88oe775pq9jOcn5Ew7zF Q2n+akTCh2na4g7NVExSJnhtt4ZIkeGD26c/QcC0jBtw/MJ40CZgP1E16cLu+Q6owkkYQsTZ42lU v0E+vKqgX8VTC0dD5G8+ZVYjMF3ucDQlb0ZZaC5tg8gVTYocYSNpZGBEkO9h+/Yng6cN/bF9cBrf xY1izMfnee3vuoLMtLRT233hLCrOxlhaU53DhUn8blS6xKIPYmj2YxbM7i8HZtdA4as4+hfCROzX /F0kbgtfaFWxgoa6AOLIZG9dKRoVThJC+Al0qpfW48672+rogWZpKUzJLvrjHig5sNJ817Eh605a ZwppczRz2+e0XFseVOxnKOx29/EDlxllQYpf6oAK54HDZDuii8IY8GyLCAV8pHcs2raQGqlm9eoo 0GD7cJUnh4qwZzktPnKoqfGHmzP0rA9OLzrMgmui5t5+s6c6r6Wlz/MsgV4UGWXuHCasCXf2zW6c W+e5EWiU3GBUBsSGnavKIHpiH6CzZBW9soxGUIDoRNISqnLiGqvsYnpHf5u47S1XNN7JVh5NWIhW OrJ27h3C8jJhEY306+8X1ZnfPWrbaWklGhAS2w7fTjv3CPQohqaHPstSBMslYr7RyXm73/GiQEqF B7VscAtjf+UhYGLx6bM3/USN3EvbnCHeLYIco6+Jn137fantphXe+ojxhdRpxUCTdL/76WhmjJSR 6oMyV4aQTk9mIRxXaWPG8ubepQINsjSVsQbq3QyR85OPuUzJT5AG8U/kt1TrVh4GP48ld3TRSvC5 xaZXhQOgDwyKb7Muh/D6zALqz9PfX6HRbz7BJyH3ztBrDxcPPjEX+Zq0dPuDdblnsHR23oGXCDM8 jSJR6iEBMwSvrny9UD5Uqf35pCPuZdbPe0fhBbned/wYNAPbuCsJGwawB1VXFsufpmvx53duvvuF ztrDo1ECbOQLy8ANdqPopm0ZBNZZR5O5+OWK17ULjdwun/e7sx6y5TcOGKAVH7geRmtGP9C16bEe 1gp0F+0fkjLm3b9H2D/Rq/mytQ10eXBXesC/PWxt8ILHYZVi2HZY9+DTmgwz8FJAZM8gb0Y6IT5x Pz0cUzXCn6Q/0QFvP1k/FpB806slLNkdyak7LPh5mn2ofQsiRUx5JGCAvaIclJ7qYYLOGv05Yckj e5fbrbC7LSV1oWBVEg6WO/jssKd3qOlJKEc6zqGzuw7ita18Lu259PFHX5Kvd2wY4R+eaVC+EefV Kgvlvia6sFtXUtDu6kTb/OFQT/YsXqNbW9N5+lsc3dAhU0V9Ko9sY553fwC9AHMFjhDElmnoi7zw hX/eF+hpfggrYaOqci1Tcpt0Uz1hPC1kPbj9QWYP/mjXirzNycDb1uHMcbZ6bVKokIYQ1dc23CSR oKMadiTlnBnznvVJHBWiHxzxdxokBMPRKAm+q+9dPm3+tmftNfVM0/jQ1aCWm/aysjBbietRdmKB JO/7VkVXLW/yfBsZyEGnJqskXnffbXqE8zQdlz9+swD+dFzIdt/2s0F1qX4buy1I97bfXG0ptYD+ wHn5QKzCR7LPD7gDvQbPvHqn4Um7Ej2JhfN4NzqAxk5BAB/0srkVLoXvlptE59M82wYGHmcgcE2v 2mdSZf0sYoccmgD4696QCUZ31jXWJobmxqsmUqHjcnbM6vXAV7n6H7yy7JJCg3ISYYgiyyAwmIhp Lz9ikzTjk5FNFMpoiZKAZvjK4ZTICrAN+3aXReIVKYk+bcpqZlAm3DSeyksTku/q5i/SahmE2Xt8 kmoS3NaMxYly0jCIrGlm3dpDFl8+p7veX1YaQuza6FNhlTLZ81lFi26/ZFGpbDMNm9Wi25ZnPytp pcc9lVlUaMUXHV87dyAl3ZDs9bsK5jYNICuEf+bP90w7wbCuwXicIV127uWSdFW3LeMZMWQ6PuxM +l6fuFCWh92Cf/DqhIrVxxdeLo9N2zJY8slzl9TPHEH5/fBSp/RU2STab8JOyF4f7WrL7se6+gt8 1gAW7Cs+VZWCvlmZPhm3zR0Rl1HNBdl7imz40tbUVA7KH8nqtrnYNdPCL5DPiMYReGxnbA9SzXxt UqXAjEO6Cd3Gn+zlSZE0rvF1FrdgnfCreqFUe54QE4ke2cKA7lQLcNAnuCWrpsjwN13NbXi6WfB5 U3IBsBAcsOBCWz8Q5FL6sdeFkR8ARO88+uhWSKkid3270YmXQ4xwroTBYTJGvYChMwEzNqlsYM8W kUHD3O9PapZt8uV1lSzpXy36ufF8haJkAb3gVHN9jSrvKc5nvhrBibGw6vm4WAukaJsDW76ykTla mUAEw2WmG9fj+rjQbUO5uDYt7BaUUYqbcWmB77fv36niVg9RLn/Yem5JSV9N+DDIR7F3uqurw9zk UsKo5mzdW97p7NENFMDm7lBCQMLNa2HEGRl87hN5LyAFIH630ypIQi3Qd1cm36bjz0E1P5imCmXC HSh8M2ohuaatvje5Y+runQiXtHd/FZCSK240mmBZWRILfZlC3MyKF9Cey+enAkHSHhpHE8SME550 fWeCAS37MBrPWyGjTFhCifeQPmwRKtH5ic0tK5HefIGtXw1ebbFmSIefdi9CyrPdWg7fw10nopjy tNh4O0zFsiRCnHMF5Jb3uTSDjTKx5L68noVnnt6aBCpmJ6tifpVylx4X6wuHg516+v1sG+x8QEq1 5kP5asHlprNCSYjZxHNXz0cnjVodVXuErVx0UBWTao6bFvM9/WhhZpXAJqJ5eAB0G7JCYWdRMkw3 GkNkQ6/1/YVyGiraJsvwAKHdXa73BCmB2zPxqEk8h9uxpUxT+LoSOY5aEoSeRpZD0CEr+4wjLnJZ zEZT5osU+qx1s4hk+U7p3TpsreGSsAvohOz0SFTzsXTxdbwVKb7BW5X4VZP3yDgfd91tIMkwMFKU uO2rEpFSnBDEW37qlg4bGKPxLc8ORzKv/8rkT2mVbcnrIm73/Dl/JuX9Z6C0ytTJkzwrOLSyiA+r XksnhcvqMmu+lawrfjZXwWrIE5wdi/7EMYdSG29IsA7evXj6c91ZeVRPKMa71p6Zx0CWgPN0WN/5 Quk85EjUPijzug4tROt5gtPelaJ52+VZSYmXAJKMgTK+GhJ3wHAuqtUBvRyP6nZl76wUTEZ0QBup d20UT8vdw1W109ckuQ9v/QgNDI1fGvDtw8tU75XbDgcEEm6/p31W9+Qwftmqks/sRZz7c/ZrPqWT bQ91NI3vchhEew59yt2Oo9sNhwPenGrr1TyISPbfWbPwJukPfqz1r6SowydKvNXkWmCOX2tETkW0 U47UU+gVDyw1OHknH3wvEHvk0435hRmbjeMMAYeJelc1KMIknqdUYo7p+mCdmzv/FTeRAIdAmlpH g/R6CkrExTdCeZwRjheN8d0PyHu1521gORBwdGdIxEOvg+xznnve3UBLK2mGxHuOpOSSgSGWSt4Y wBivmxzdu7NxuJw2EyMx7YfXhjSNLBQUJ2mv3Tu6qy3JkkyOWAbZaBzgzhuBpGJ9yucRS95x9Lll +8JPPxyA5p2/zUuLdaC43/y0+OHAWCk4EEhBc2919HHrZ+nAakGCSeSXzgxMuOhhcjhL7Gd6CG/5 UiCYlHxxXw2dmwgBT2FC2IMV9EDD4Eg8wbs834aK29kMvVZCA9zWFN2rbgG92Jpa0+fk/tvFjTfy M4LP0I10GZmSUJay+pyv0hN0kD5GFshwNGkx3EDKvzX2GttORYWlFD9EaBRZ7mRHm+BwO6t3xZsw PHGzHKe6jbQsvSYdGEHGPWJ+Gyg3L5aFR5KL6JQPODTzameEqIu07IsEN1pZG2uHv464Yu+t5sVA fb+znbT8ekM99y5DK4S5Dgmjw/3tm7XVU5s3FIOO6a2CgoPeE0jFHF7YHua94KP4GwiOk/l3fJWz wsVcR7L59apYgapjrfr5Fka8u8Z1N4WmlfLyNO6VBzVVxCenOK+rQH4JnIQj3eIktsPWoXi1Mbb5 mC/ihc/cNJxSNiDwIrlrQHroh1mNkw8yTWJt/hqcnOxrpjS25oUdQ/gWIl/fZUZ5ftTHfdbmSumg aWjsGcvdcivuOMBccvmU7vVQ2IIQwIkLtYeTqjy2NGusaY/jEt4X1Jo7Fo8tIohI6KH70lUBfv0r 21yIPWJzKdcbf9XrenvRIXQGs/hN4gHJyUjbMw7XXWGZYBEsCc26nzMFKhkGXGq18yqGcjYKrFof 5CcjVz8lVGgNf8cVSefWtMWgkFhudujZgkUJsBAhqrm9m5qnltzYgg+yB1iWTL67SX4QtGLJ9pIq 2oA3djLtW0ywBFCZMydI8USvf/1ZOeTT+ykWGH7eMGqS1ofstpk5hToFVS7FIpt4qTEgsaVwnTrY T6Ml6xOJfeEGqA6tSEebVpe9Yt1CpBOQlxkZTq04QdZiUXfmw4+eqk9yb4PfG+kPSptwEqyRDPWg qQDy6CkmWE0bUw8yYPKSLZJkzCIO5DecFWtW9sytFi/I8LYGeNykdo1+85m3X+IvvdqeY1HkAMdE BNHRWtZVz9//lI6MitRn8OE9UZOa5tk4ZUEi3pniq1owrRpUF39NyhN8NcWdSLHLnAb/JBYsNkyb u1/7fCYUrvdrfItKjyujFmJLBcayBDCgKtts2GPUy1e0daEU+zZq3JRJXpFZwoNceKVX0s46K05R z++Nml/b9WKIoYR+DGfRpS2lfIH9FtYsQ7P3c5UiM7fysQxMHU9Vl3H6WfQjvAmUem0qN5uUOFRT pMJAjp9DNHXdhbEk9m8BX4hyuPiksWejT/AkseTYflRliRqH8tBjSs4j3OPey05W28JdMRlsTgXA eRAA26Lq/Yt0+UB2INcQN6rnzK/h5fifKRRipgs79DbjINIzHoyHhdvzxXzHeBap/QSLoOsC264D F5VxdhL840CbcBJNZ8bRh/vefyAk+nhIzPO0rNmRiz80iQmvdCYPxV76LQ1x3wVEqcCGwWwq7Rmm B7feiBOV4tcc67j4NXZseYguK1+8Va3AvRpl5WCrgaFBM8V3U1khJFAqw09Vbacc1mctnrJu358x QuF0hdZfmXZ/Rusi8C8N8VktMmk0JzbiqkXPhKl658jeoxoDtDY/GveHj6K991XdeoZ8J1B0I5RY 8xC+hVOYHbkgoLuQWNc1vpLG3yEwM2j14CwOmVWZZ7WQg6/omYWbGmDQP+87+fKwtDgXBZ24YBT1 WEtKl2uR9of/ij7BWSM+s3uh3xx1798VbDAj8aqxhN4QGem4Fbb6Krbd0rCloqhYGtzn3Z49haOi 3KPFrbj4xIOStmA+hwD9debnwCANP+BeS6qoQY6eypBsjr4os/Un65uOigPkNen3Q0x3AM2vRS9L iVbpvy9nFljIrOFbIM4Ru5yFz3UHLFBj4B+mMDSpVQx0CR5SKXL4OudRgSIE6to7eFBiJeOhT4/s ahklDgzUhrZJIYyc0FDErQ1BmIg/qX0+Nn7HtdfF+Q/nGGWlFx6a0sMYJD8x0AxXGq4EvXF5hWWq 7r4WikxwHo0L/wDs8JUADzY5AFolrGyMmSDt1aQbGlvOta1Ht3YkLhNqngs0Nc/0i7328FO80YD1 V8+FmuDoYz4UcxRKj+LzXKksFuwpveGSYfY9MH8d66RcQhacaond1O4UnKSJt6tityJMi7nUV5vO Hjg3syTofv6l84NzQgd+qGuufEvJZEblFQdR1Anl2PFCUs7LiHasAmnB9c5854BCvvWgpFTs28Rv 4rGqOH0p2XNFUjgiyIjWgD75QDU2mrTb6KiVEjBszL/mHX59dWnXzGHHCQrKJ/7h7T517TNZpvX0 udvLYFKc2/spFsZoj/HR6i4N5ZDth1sNHBD9ijPhFNUHuQoyqsyGFsrXdKXrxpRTm5x7zmtjmEZ7 u+ejmf1DJPdR3N4dxzvm8CoCAi9RjvfSpbWC9dYZinhV2CGXTML8y9EN2/HXJJLgpkt2vuBvn2eo hext9rxhT0wb/fvIWg+yluvR7u38dhIU82feYqLtrrSHetl2XHn2UWOcuPvutMDmY+xFd5mTSpVl bDoUSaTXZEsMvhWZd38cmQxOdtXGUQhQiUT4vnlDqPPdCWvc7siR0JhK5IVUb7uSn8pjgajxPPhw p6fT3ayOlBZPq5V03oAZr84v48gU33/d/jA8358e8QaeTSvHCqWB1tN4M/1qux012e8AD2Wx8J4i qoFMlBZepfHpqiZiQb9PF15fowXdSp+jR3d0dJGAOMg376fBrulY9/K2PjYBnYtmXSXuuEGGxwLn ZKM7OzeVQMgTaXW91/sv9X/UlqT8UPiw0KgeFTsSMcXMbwAZMrRF+eDVxPTJkavBa4vN5kOZAArr ucSR1e6AWdH6WQv9nhKcj08k7ahtEuaH3fsrpwL5UQi25GduFe/i2pEB27kpNxEaBl1yQHO05IeP L/BSn19zRnFC14kq4xFahuHXgfEsm4TvQ0vbsdhlfSOUPmKneygksK5QIM3atKX44gaWuTb159Xx vtYFX8NoL749U4mav1NrDWhNczL0eSaFbnE0D0b1ehBfLcr3T3zSP5C2QRd3OCjZXCJjKByBS92f LozUVwSu4U8t41rxn4qsGLfkppVy9aSbGKCbrZz6Gil3bR69DvRiICG/QrlkwAxi90As7kDRyBIy TFS+SPgCCXR6ugAkyKLRGnt+XayhCDn7DJeM6OIi0K/7VC9jwS+H+JaIEElq4OW0+XmOxrLI67xv gzwBd6vuCXhmEcFG5WPUfuf81k0K4WpW+7GGCPAhVccXiVMbVMr+VZc32lrbknpFBHHDH37Yvkvs QcWK69uUvWcZTIM48bhiqTVY2GiaMlxazi1bI4i46WwMQvRQ1bfjZz7chsz8jCQtFNsZ2JS7bGAt ZY2euAsziUxT3q3ne5rGdhOEssjv40LxFJAdTnV3ST91JRpb6DOkGrGRGGqlwkt+Ku3ydGtxMdEJ NnmERoE3bbNSrKb5ZpNGqKzqazl8VIyjggUWNoE9XcQwUiRNz8pBuRTamMTmsj0HVbfFayL5DqJW 7eFKbZGmKBh/28zgCI3YaOqUzChO9yLgK3GSIeGGTo5WPzatv5Qngg4GtoS6oepgXa+7kDD5tOmJ jvkB2KXBwyG2ECZQomtfo0ukMYVb7t2qkLHTMru93ckBavWqyVxjSfMThJvAQ8LkYRNxpT9n2vYY tFzowyIYXN31WdMwo/5WfR1kRQGhvwS8W38mKNtc6vtUqOmIDqCnpp5PggjnUvHNJ7A9LPjOuiBu JWR5Jih+7TjnngJEKW+z5LdSG7Idt2tmnZgj6VCkHxbBlZ1vHjsVN5vJhmQS3XaHl9VEzRdL0KMn CG1ylvQMwixprxYp3TNmYHypg8+ruOh2JqpqZFz9fK6n6qHhUNa+njYFOjz/MpLYMaOGcDTS+v8A VIUYPgplbmRzdHJlYW0KZW5kb2JqCjU0IDAgb2JqIDw8Ci9MZW5ndGgxIDE0MDMKL0xlbmd0aDIg NjAyOQovTGVuZ3RoMyAwCi9MZW5ndGggNjk4NyAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+ PgpzdHJlYW0KeNqNeAc0nO3WtiBa1GjRh+h1hujRe/RORBljMIwZzOhEr9F7CyE6CaL3IAiiRw+i J0oIggjxTfLmPee85//X+r41az3z3Htfe+/72ve1n5n1cLDqGQoo2CFtoapIBFoAJAiUAihpG5qD gAAgUEQQCBQm4uAwgqHh0L/tRBwmUHcUDImQ+g+EkjsUjMbYlMFoDFAbiQA88IADQCIAkJgUSFwK CAQIA4GSfwOR7lIAZbAnzA6gLQh4gERAUUQcSkhXH3eYgyMaU+fvWwA3hAcAkpQU5/8dDlBwgbrD IGAEQBuMdoS6YCpCwHCAIRICg6J9/pGC+74jGu0qJSTk5eUlCHZBCSLdHWR5+AFeMLQjwACKgrp7 Qu0AvygDdMAu0D/UBIk4AEaOMNRfDkOkPdoL7A4FYAxwGASKQGFCPBB2UHcApjrAUEMLoOsKRfwF 1voLwA/40xwASBD0r3R/on8lgiF+B4MhEKSLKxjhA0M4AOxhcChAV1VLEO2N5geAEXa/gGA4ComJ B3uCYXCwLQbwe+tggKqCPgCMYfiHHwriDnNFowRRMPgvjkK/0mDarIKwU0K6uEARaBTRr/0pw9yh EEzffYT+HK4zAumF8Pt7ZQ9D2Nn/omHn4SpkjIC5eUA1lP9gMCaif9scoGiAKFBSTEwUBIC6AaDe EEehXwWMfFyhv52/zRgOAX6uSFeAPYYGNABmD8V8EfmhwJ5QANrdAxrg95+Of66IQCCAHQyCBthC HWAIon9nx5ih9n+tMefvDvMGWAAx8gMBgL8+/7qzxCjMDomA+/wb/vuIhdRUFUwN1Pj+UP6XU1ER 6Q3wExCWBAhIigEBIBBIDCAuLgoI+Geef3Xgb/a/rXpg2J/d/UdGDYQ9EiD5FwlM9/4m4vlHGdx/ xoYH8M8KOkiMnqEA7n/L/xFQFAjBXED/5yH4HfL/0/6vLP+r/P97R6oecPhvP/dfgP/HD3aBwX3+ IDB69kBjZkMbiZkQxH9DTaF/DbQ21A7m4fLfXg00GDMjCggHjM4FQPcEgff+ssNQqjBvqJ0eDA1x /EtLfx8GpgYchoDqIVGwX88dTBQQ+F8+zOhBnDHPFhTmyH67oJjJ+mddFQQEafdrBIVFxQBgd3ew DxFGAZiVKMAPhJlVO6j3b4kDhAQRSDQmBIDhGACwR7oT/TpYkChAyBbTI4zsMXaif+SGeLi7Y8bv twgwhf9e/551KNQbCiGan0FCpMOcXoW1n9coMHgJbI7grax2Riea90WJojlnn/k5auFnq026KdrY vbgznKE3Vx4xMePPwPvlfNT7UXdu8HK6ej4aS6VvXfFQoGDw+3G3A5TZDknvMCaeEb1OcZCkz0Rm Y4FrwZViOnMZLt4jsv1yq+iqE7X9UHIX4AIoOSVnTWdAxynkde5iPzFnZV9FD5k/Io+/7W6R6WGk YTx2hf0EFn+m2B5L991n3SI+a2hp6W1uf1+GyFGhZm+12IsISjoq3wesecPJA3TUSbkPmlBYnIqi p0rlaYlsdMUuEZzLODbiyz+mCvvbkgZEPBocdJSCb+k+ftfoUYcUnZHJ61k+YrTeyDH6LkRypzk5 2pG/JoNdkaPaDut0KPOgWgSe34tLwwzAq+tcvNaeQpaWnZlrYS80xuI/DhWx2hq/c24Tl50EErZM k4FLDHx8riimB2d2HbY3Xbi8nwagpOeg1NPA0WF1WvUYvssv+O15H6zSjCUFcfKp+W37UE/kIZL9 CxP1ZHCiWUf27pudpCYN0dP3FCa8KmLoWs1ZZJc1T0JewlSgQX4erl5bp5r0Q3nJuXG2BBMRsgIj ilkjrW2sTB1Cc6lwhaApclJK5y/lTC8XqsTePZMJaZZJkwgCPl4cP7yhrL+XQF67fku/5/tNq0Rb 90MhYQIrzfzOh442pTpcD9D3EmGNu4mXnxTNJ4MPxWeW8xV/GgdaU5Y9fpRvH/cj/tv2ScNBvplC XdRDeHRq12TguvXzd0wdD/vjGTNfj+/1dnClbXurN1yc4h5S2g6pSQ2whRXDKxsTRFuVlvqpo40t +sFa7SfNBO497+wbT74TgyzOpO9tBLtafWrQOXD9UeGmqAy4TcY1Fy4psv5CO4hT0g+XOMokUJnk m8RtEvB4Q4jwDEIQy9G+kWgDLqe5QFO4a8H+pDmGou5CzfXwtJdxibK1llHowYAv5AynOERV4oen nsiHj0JmumJvfRSQXbVfHu9uW5q6MSiHaLfgRZnfWyk9jmimKDRPmH5XaKancqh1JbxuLdxy60VL OVI9zY8IROs9SUc1uMPV1e5B59+GJDk/vTDVYWEyyFZJPSrZz2pJmMI++cGZup4JZ1G9pnkUqEWB beAIesmsmmf7teTFWABfJJxE6dwSUFK82MNNEMboaT+NDOWzH7uTq727z1IXcAaXY4TwLkexfXlh FWhQtWVZ4RKxQf4eVhqmWaE7OBnPqnEr9tXUqx/bd74ZUPy0Rk+ZSmd1vfuaOeAhz323As37rpRy 6pbxs1w///Vv3/QDwCKbqmVwnLTOYwlv3CoG/KJJdLK6qUJZz4s16TrWBZPl8Z8kSq1DVKEmyLqM Rc/WvL1kuZ66VBbp1NxameEPsvxh/eullZ2P2Cq/N6Zl004Y7N/0NFBKmyvGzdVXdiSiI52St+bP G6AZziXrcL5NE2drD99W0DjXs8KuqMvyms+mLLHTGFT3deaGnImEev9IZI4ZDN4zHDLW06iz99Mc LR9B0YcTfxkxr24v2Bfa8+xOGLMoaPkxx9ysxaFbIL+bpR4akXL7/rIeV/yD58OLgZ5J0/z97PVs jsal2nIndbtyqymuvDNh4p6ks7Qyi3ogVMC6GlmKfJFOsqjVoUhatNFmnYR9awSA3ke/JDK0RZcn rJ6kCig+tTXJQRpOGKZGXHSRbOD7nPL42P6zX+S4FYWy44eT+xuFfllZa4ppwzszARev++fzUML2 XErHPstrNdYDL6deyltCmCVSahH04m5coXRbNzSjLu8568rQ7v+slJ8xBiSXfYDzL+khVZ4s0245 Y7/P4iUVJ3DDsVhgxds7u2ganfs09QjZFmI1y97EGbt5fGRJIQFPS9hoQrVwhoV1CyWurVnxZLMa bb4JApMcY69WfZkfr1ulCe4wZCuQTviUdulhhWUYTaQgepQlpihDsVjoiVjMMloneJGVUDvWzhY+ cVZOaSmENyIQGOAXNdE/KJ8/lc73hDEbRnrjqhwCHnVFDC6u1099nParINEpD8E6cORAfa/4fJgH wGqZXdUpognZ2KwyWdgYHQjtApdnW558kpvmJ8beP7JFF8BTMh3JxZKudaM8e6xL8Qw+v6uTTDQE WOHo7bPqu54RdicynLW4i521d0sX1z1M/9TVv+E5xyzpTOxDEU/ToJ7s4ypNrzw4uw5IcaLbB+WO Sx0ahFlWLeXY+qopybFxhPhDl4q9WD/Vpo+IxQ0XG+h9Yt9qapG67njPM9gRr3J37lOxHVdV72YX g0BLI/FbYSwhhj4Ax9f4gMj5LobYuQ+0xC7D4dUPL+nfFGqRSoy9PpmPgwwfN4whqeaxq2JytNSL 37dqfjg5bszjyfyG75bHN7sIMfdJ6xtpK87PuUFEaa39LvbKRkC+Dh942wTvioHrJHesdvy0HG1Y NlhEZie3VGtGjUvJHWoeGv7mzFnHtMH89b7q3P1PigF16Z+d6xZ78VcM9rkXpseshOc4yIHYCpdX ey5hbVixo2Sf4f4uocipt3vl9+j0N1upX4QV+Dyl9E9JWPBkuX3A9zixKJ/5TapKAyT+/at5nGTt /t1ZoRenTDS76LlwnEt1aHbEvJ5S/WdPnS/bbGpiAcQleyRf8PPzLBtABQq0ia9jU/n8t2u4N1pM pr+uxKiVVcHFQzTtGUypfJfd8633ZX6osflxVdwbjjDTBpRwd93pTauNOKDzFfpQ1zjvO6nV+zDM vyVa+QZz/z0Bsu+rQJV918YY+oeGF83HCgOrkVUEUXVvV+nmmhU2Ulu6O9DwztpR9asCCyyjYG/U qHYhU7heNG/9Myi0PKHEvqQTy8t5IfIO87k6iEecoCwBxhY33nsQwg5kmvsZXF/ZayIH67p9O9r3 eFuiv8+/q1jW7trJxyg7Lri3wcRlYCtjlc6t9J2D0hBd0nHSwdzr1uwbkr432zaNopSWA4XeoB+3 JvVlRtwsRTLx7mdIxva7j01rPClAOlUb72ueUno7FbQKEvLjjZzz2YJqZl59Je7VyIErax3oP8QR CT5r1BNAIE/ajzq47o+bd6zgQQX2QELnpLH54sGxvCqidzPsIr8WIePT/SyVKmTZf+KoEvo6sI5H 8T5HtmJN3XSKeS+g8yN4f6R45AXySCKhT9NL32EpzjWXF2RFSRoiOBMT9XS0Z7eWWMsk+vHJ2+vL cxcSKjh4lMSSg2pPkK3EJrGt3PqlfhOMMZB+w/X1aV888xA+PioZW9RH0Cw0AYdxcuQlz9ctxkKj gn2sklM7kGZ+oXNl5bsYp6XAykICBgTQl7ZC7SXTKotbdFPCLrjcVP8zh2/Y1J0Hr1rmzIroC3tE 0Bo+wDedzwVxp+5G91mk3C1iClW+q/I+JNnVtVqVt7LsW+1ypueBu+6U3ShCHHGriGISx14ylLea Yc9M6lvntuxAe7YU78iyFpM99kgcda9kMic42Umaj8mPug0YScgzvqCQ7NBbo8m7E2ym2YO9aNLI 5Tv/8PidAtMCDyHiy+nYrbppo/ZUit6sxEWt0RXSB7sHR5+tlGFlVxYlh1Ko+08/NAv3sH6lWjaO vPDPwUq/i/dd1CRs137COGbHTS844Oxy0l/mOjYb83+mR1TXX68X7xMqW/JrKXN8wMZmCi8RE5+D q0IQfw1/t4y/U6WwKIXSYIh4zrdp4uSD9OqGjDlG8kDBz0KqZQwMgy3DwMJ0tEHuamsMtiAboxeU 2JGerotUL+gZdGPGxfXoy4NIZL18Te1aevC19eGOwmSgSOmaPvXnLkVmk5PH7IeSKoWtNIlOMkRP LOUAlZ+e+nndrLYmExU5K1b94jDVVXfvqWLWp42cPYWyyturHW6vxg6HyVhWXi9P3GvAj2GOLEoc /wJ6qWd/5z1h1TH/jGFfvtjJevtNxmfuRaUWSUvdnjYfidsban/E0Z50BXqfqbFf5zOEFe+MCQYU tIzeepfaVEb7YaxTdSQrFVJTm50UInPnRbc9K+0NFt7hjgpBPKFtL7w30QYSrdzy8/NPsn1JIM0d 8r06nBouGXlLz2XNWN+6pEG/DsmPwmlITa/ZJk2U1D+dP5V470w7nXTzvs95ro4HCTgVf6e4rKNP sKT/AButU1/8Jgou/Iq82VlBwzKSh1b7nCyw0bBw69o8fR7RQB8Sh4eXlTDNWcZrFc80kMR1CZHH Ilu7c8nZNOh/f2W0ryjjrJN5gn6/5vb1znwFXyqE9EVQ4/2Cxz5cLnuo+1nGn4MlXVmtO7FL9dsX vm1wlejkqNUfrN7MlCXF7isbee1kWX8bcSxiJvugwFduXnk/SEbnPPxGhy2ChCnOz43W1pxblm1e gvfTk87BEecyH5Fz5FrMOdYHQNBxtPp6D0mCstday7llURBxB0Mi9a7dMz+VZOqh4t4nXsHzdKtZ FILs1Car24706NxTX2d2Z2d2y3u71dS4hxD75oKLavI2JVzTdPmj4eMfIk9PM1xZ4PrVz1L0t7Ki cW1Xy6iFXI9vNBw/YzRKcetUnZDAtf45rUCR3IXYpdR/j39d6KIZ78fpK31/uisPL9jlaN0CJv5u jKZ+N/f5Vy5emis3syCjG4gj9H2G6VjnIyECuXJhFzqevOEx+5OW6v201bXCc5+73OvVNhwLfhUM 5KWs7frMuUJATtSKd8uJ/bZiJV/VtPuTA5WVAwv0xIKDriZjnP5z9gv2VzJU9B9DZnPlduzkRSA8 5JYiFfTppDvTjNNYHLzaAeqMvfRZn4vzpJXsnq9m3hx0d+2gqwFROV3lq1LQk3dFQcJRTOi0fTWu szWlR+mtrjy4L3hO8X7mWrNkUxTy1E5zt1zkFDfc0tZuJWqoCyNx6/fkbKweOlNa2RTRwWrUeoiq 8zLS8/BLokG1t47VnOvlPeETePqivMD4SUat6jfjcz22Ns3RiAi+yvZJ806oOKUcsJI77ZQAZsfA kK1VL+3gjC/ZfZvbXEMgMRZu8/LbF2mbaertLYVxAnWp+pfPVs3VmWxBKQ1rbeoDfs1eoQMGVuYT 2XSk/ETP2FXL3qerK88fmdDLuR7h+0xktFDpLXOoyrSF9Az0K0binc6fFqhpzuk51j3WqbdoxtUY st6JClIiODSi8V2etCfcJrw/lZ4aexl8w+Ye5ldZBTTzgKv9anWJ3SbAgBCPLAR/IfBRWRDFmo6w s30h+Bjp8UBc5Gkg+U79kefqTtdJoOaiqV+u9tSyiNxsQly59pHldylTOmkqCk+WxHDyzJtma9I3 wxRZkgmjS80oEwT1VjWk5fJZjYqiAIK3mlA0ezinxpYbL0OTZSbMYn7eukoWrX8dE+QepI2W9ZGp juBdD7ZVwul8bEXSge5jUHCvLYBzNZ73laRdHt94dHI2lz/IqBWMvRtaoJfCKY5Gk2Gfeqj5Sms6 3Fs4nohjlm7y4GH7XCd98cEwLb3Hs2P48PKb0uM6ua4HoW1CyapsYsaCNUDZbTzsE74PmvpTYUA6 tqGpygmZ3eCvqM/L+6HeyAeWq7MVrO+8LsV0lwQDnuQFoXeHA0UpDgtN1obL6/iqKIqbql68vmQS j6kzRoVkv5wp7/fZ3hx6k4JvlB+rJHqp5u6wZoz3hlz0HXtCZEYsp39NQkNXDMHjtCW1io05ibyM HZKCajxtz80VbidadGno+gqA5OtYIeLrfo7lqGWfPvY70zvhunNJ9FEupIKxz+NfHBIaWHTSjmci de473d0i+MkVsv2mHfSCco70tXQAC9lh+CPtwKeQGW6pOWhCrdxpeMQ65cOse8yaUQ6RuOV9n4p6 yrfJKOVjc42qUgHTXOBTNo5+TX8bfc2Aj4Vv1488lCNyU6JJA445g67eSEgKXs2Utm3b0nsqQvgC Vbr45IgHRUuiOOGSJ2YterLjCIcTQg3VbSm5HnTqXCKeobHuKKSf1ElYycWi+GOlrrhssLPphXNx YXkH9rBZNVfoqy9MJTS5ZNQ9941LX83qLEpoIe2cFlGzpCLkkbLEWXcZ6L+mT6C5zNLsqCX5VMRr D3U28Aiy7GIl/Posj2JdWp4KRdLd6v9Kntc2G09dbEfvSffEHDsCzzz99CeLF9KV8uRzFmuWyhu9 p+Kqcsg7Y2+c9Mgk145esOV0O6QoxjyNHe2b1/sSfyKtaKWfoFueIvK9i1fxlkhdqAeiDYe9aUWj n3TnOt9aFw/60+Y9EUsm++sVm5AAAUlqfaE3xZvaddCgPLm57oHBncmahhvM5HuOGziWMSW2h12E V5/bdiqtd4TvT5yPpPfz4ZLvoRl7KmosxnJro+geFPws15Uv4tBO0ghZ/kyCLmmY88QLjZh+RN8i ZLs+0XukbaJKPQQUvR7lc9bYFDaVlLVPDyhvApCPn79pPBFBRzZWXrcWOFVElPT6s5XWb518SZwh yh8YtKCe0opxzMeON79NXcczhxQVd6Ze+ZlylyMQXz35ERZ/lfeo/wmqGuW9X6yed19Vk2J9I3Lu 5si+Y+mtlodi43fCsVz4lyccDQVMH95OIMUZfXCHq6nmbEimbOODl87m0zowvEIqmv1cV3RFbyPM q9d6PFoFGMOquSwSPT7MZrU58d3B7acksNZepZ9b2pVN5ueQPWRWMMdZDbU/rTS8G7weQ6j7/euu ze0hglLX5Ey/5pUyDTFapXTNKyUcIa+apy5U+JUfhgzfs7/U/8E8oaR1Unic1EzjnelF+LGzhClc tXk55yYnyWO2sA2VFNmRCP9GaRtcsj5izx8c5ywL1UYW+5AZPMuDECh2DJtahjG9U9xKJV6YT8wh 2tN7WsrDTj+JxuOhjzXVKyM7tpSK57Z82926EZZz8Grvj1xiXkfrYmavlMi7lDWZdfHpuiPtc7gd 5L0s7UtMsoZ7LHYCH+/GglS/f2a2IlMQ8awiHFjTzfGcrGZsFL7hSUzke7Fp1Lx8MQycX6KyvXua c8Mix9dnLHmaHRcKqlp0nhbNsDNQ2LPh7guX90uUueljKtt1GLUhe5FUve0jv9V33WK8ekHw+5VC r7r0AMQv/fC+j6KteDmcldM7ofXwpnx55PuDNAIBuwLcxQ6PjZ1HWD0j2FtsmYFnXB5fhvypWWUX RX4A6+Noe9ufW02/TL3DM50l4Nekm9BSoztzIUxuUNZTT+b99tMuAUuUfh/BiZeiw3jSWvuV4VVb Xg7bbAU8x/bw1Fe6pTZTw2f6kcrsze7hnWhX9zJnbeImeTz5Hijn62ciaZnw3qFotOHZ1hsOpuB9 nk9CrgYD58vzryvY7gg3eBBlqkCTRc/53szXoEofHnHRE1DVtpR+y/y4bRul/4r+5LDGEH4736nv FJBIR++L70mHRb4ctPaYQ5BS0/eRDlVBTNj25foZjcoOPv861ER4kkJGmxZJyUMlEPwAMmDysUhq kt54XniiWXYQFDX7NoWNrEvftPVZqO7Vt4mke7y6vj9aBSHNx06Q1EpzzsuVD3NzY5QJezsyu+K3 U83vZNWfnr893OFXEEUMaayoxqQJ5cpdvovJWiWxBKME63WErily0/zF55LgOhdVDrv+66p6Eszp 82qPjYAE7YScN46ZOos4vPQz4i1u5U64fK2Zwv2+t1VO0ZPCZ4BcaNSXvmC5m3+lz+U7G0ijcjDm x3EvGv+WtdrlaK4s6sPW04danrI9Be6c4nemXr/6kPGNFEeT9DlYcI68R4iOGitmwed2CI5Qh2g1 +Rhi/totaM1rwK3t7QMgfmrJl2HLgrmxaatmQeLwZ9GceUuOIidrclQEkOlVrUdPKKIfvt7OvcXK qLG3nVD/6qWq5t63iEdLoJCmSTokZ7DMrICvV6DIeNzSkmUHzmC1IFkl4gfJV9fum0RTOJ7RcPtI nkeNMaVSJq/e6ZsVdiNTs88CAfemWZ5TzVPEmBxHJvC5jvu8nDXr0w3Z4qxfKywvdxMx69bUcoZe fysvrY3U7F/siD19vmKL3xUrF9WUnzaQDl+Y2Dr03FE4VTlkGVOZFqsnjzh2smTXYBqXDic9YvI3 ZaizoBTxBZFUb9ggRhU/B7FspmlHqxaKOhiXGVa1dD/PVpunnl78LoelfXycPlavNkwrVr1pPGKQ yvssK+wDcWlkA/qWoOl18jXhRwgRXG9Bt6bJXAbq3Ot8vM5B9T/Fs4sgCmVuZHN0cmVhbQplbmRv YmoKNTYgMCBvYmogPDwKL0xlbmd0aDEgMTUyOQovTGVuZ3RoMiAyNTYxCi9MZW5ndGgzIDAKL0xl bmd0aCAzNTIxICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42o1UCThU+/sP N2mYFlFoOypMllltY8vYs4SQipYxc4bDOGfMYshyE1oIbUTZu9JNiUJcRfpluSmlqSilshVZMkY3 4t7fIW33/3+e//+Z5zlz3vf9vO/7/Xzfz3s01N089GhMxA+0Q2C+HglPNAGsXTw9SWSASKTgiUQy RkPDE+Kzwa9+jMY2kMuDENjkB4Q1F6TzUZ8NnY8CXRAYcBSwARIFIBmakIxMiESATCRSvwIRrglg Qw+FmIALHnBEYJCH0bBGOOFcyD+Aj/b5+grgGBsBEpVqpDubDtCCQS7EoMOAC50fAAajHRl0NuCB MCCQH/5TCZxZAJ/PMSEQhEIhnh7MwyNcf4uNuoAQ4gcAW0EeyA0FmcAMZWALPRico4bHaACeARDv S8ADYfGFdC4IoA42xABhHpoigJkgF0C7Ax6bnQFXDgh/ATt/AegCc5cDkPCkb+XmsmcKQfBsMp3B QII5dDgcgv0BFsQGAVc7Zzw/jK8L0GHmDJDO5iFoPj2UDrHpfihg9uh0wI7mDtBRhnP8eAwuxOHz 8DyIPcORMFMGvWZbmGmNBAeDMJ+HmTmfDcQFGei9hxPmhhsEI0I44qvFgmAma4YGU8AheMFQiADc bDOHQV2Y7z5/kA8YEIlEYwoFAEMAMIwRQJhp4BnOAWeDpBk3yiEqgoNwABZKA4yCWCD6h4ng0UNB gM8VgFERPwZ+tjAkEsCEGHzAD/SHYMz36qgbZH2x0flzoTDAh4jKjwQQZ37f3nahCmMiMDv8O3x2 xAQvN2+nbV46c5S/Ba2skDAgQo8E6JEp+oABWR8wpBoAUT9X+cb/K/dZrxsdmjsb8Xu9zTALAahf KKB395VG6JwucHNLsxH4ucMWBFUzCOC+i9+XaEBkoA/S/3sFZlP+N+XPVPk/xf/vE9kJ2OzZOO4L 4H/E6cEQO3wOgapZwEc3wwVB9wP+N9Qb/LLOLiATEgT/O7qZT0c3hAb7s79dJMSzg8JAphvEZwTM KubrGNDqbAgG3RAeNPO9AfRIROK/YujKMYLQbwoPHdZsCEQ36ueOtjADYc6sHtnAEKBzufRwDBHV F9nAAIggoTvKBMNmpQ0Q8DDCR1MAlF0UwEK4mJmRGuoDBDp/xjdrUqkAgfHNIqE6JIA/mGSAwPrB NAIIQT+YaG7wdxPVPgH5ZuobAgQOOm+E+QMC7c39wUQhX07yE0OGgMtFl39WhCj9r/bslwYEw0AG 5tlThGEaF3g17sanEtpKoV5vC1kf2yBOkMh599iqhr51P2BtNjFGOZfYTrv1uC9x4rXie/KFf64H bV9ODNr9KjIj0WT5s7Ib81l+3bqRDxXNJ9/znAXkPqfa2p17KTDTf/lI5dYmocRStHGFbsho75PM fnszzcrivy4HjCzQqhjEK0i3JCUuUDE2pihIx92kZd4stiqliR7XbN7AE1u2DJ1cbdc/kVHfTDbo anh+UVcKepOxcmAAy3GSZA5YpL+7bajmtPchINLouW2r8vkY7oDkRlwMzo93z+1Ygb4ay1N8/X2B wHVdXAy3cuhqj8ODokvk7kebJJ5bB43itP19jvfiFz93tpIr/qOLS66QO+aGu2G2Q8/28MNoK//i +x8LNq3fwbPM3RyxvXZUa03L0zavh7iNlChSzDKDoKGtTxhrD0PnToxKhvNL5h8++kY82R45mcex zHK0v1bRfXfxGLpm4nHx+lt33+R+7sQ9Cuua77cjncgaWZuy/a/8/Bd5hJ3aJYPnt5f5iibizZYm hKnYtawa1GSmZj09EGLDXaed7io0P7rHLOHKViXSHXmHD8Lbr61S0903VI691P6MjImw9heXHbl1 Jkuof7xj9ElUkYTbvOdl5cHdl0QalZexVftepEpkrvFv3U18txBO/ugerWt+q36buqQWr/BcrbTK cUCypObwiIy689KKyayukrPbr6w89EClY2HIobSAfSE7AwuW5fhesxYUS7u25ncn9wcoNfi+XooQ CU0TElMWVtu3ZJ2fZbpW3/Dpp3+3WpSsp21wIrlJ8c9zx+LjWGfiQuT3tzEO53t0Ut8tNtn5Uets VaFoUSvjldLCtzUu4r7yaUnhNu74i16B3FM15xyqT4wgauUl3ELNZO71/c4pMZKyUNPpN79VRtF1 YmBhjKcHZl5+6/BGQnaHw5Rmm22Znerfh/rtmH7LcnTT8zuumIaFNJwen3Q8t3QLBsAIgwarT+no 2fesqzBTLp447HqaMNHAqe/KjfFd29hLq0/9deS02onmmqxqluYrE2eD30rr+4Zu2sqU+JeXaWEU 7Zfe7Y5W3evksShZ4OWQflTG817hSt+UZlV87hHN7JcBFElPZiDlbGyG/ZuuiNig5D672mzzEBHE yFJNihzSBngHIFq/dnTIwj0HO1aQRkc3LI4stVFWa7TcMQYZH68TNLnvzrlaQNkvXNZ9JFb/ZsaD Gtad6ZvPqlRkgc6tNCybPtiU1+ooGfYjjSTvVKkwPYWzn+726jCjpiI5x11qlurGHsvJW63uwzI6 xpn/fDGnk0uXNfeHM0asyZV7kTjexRrAn+IwnuPwdulxw5rPFaPRSf3wCWXpz6ofbq/FbAlzIBmK M8+bMx4J9+pIgCmi3nEFGSvChqMc9lg+OUPfmF1dJaduY3JhzUpsHIgP/rt4SqRa1y+2DgfCLJUi sMalU26KGlRr1dauzNRm9xovdKMW7/oAK3vdoq5sfha727pIhnbP8wRB7kLJvN+OY3Ftq6vt03JX DHtOqzifVenwLSdgjcGi4pqEQPKe4aTCoVMV57YJnQ7suC2XKB6YJjzRjppuPNBf3XyhsLv9xqNy ueb48yO1aroyZZKzhJ5LuOW3lq3aMj3cz/JMLc9YFfg2GbexdYGm+dEipTMtd918hQ5LAr2TF+CT x61dhEsihFLx9v6vvKrT9TFD78DrvSVNw2fdV7jjB7dBUp3Ow94kNomQ86BI7C7/bqBzEnOxQSqj G5+eJsCGaPYBlqdT1COe76hKuzqdcjXJveTDCZ1U27Bm1yPneiANN43r1pK2z8qFqUSPrNtqHp8M r3zCHfxLpB00WRZh8YtF7z+/w/aKW+TXGJyLbIseejH+ZCowum/vyySvZ71bPVwy588D6kwsOc4V TlzWkwNppxcbG4sSf93nFB+u4RkQYwFHvkrHJ+7HPo+pV9ZBrkyL8H2cNwXSqUv2iIaW0zRiuX3r 7FKTm38NlD1RdSA7Hi/tPTyQwjv/4GlPki8xyloJPw4/U5Ys8JGrNrmzzdxCmHzn3ttJo/rE+1Oh lzB2pdGftOLXaVGfIf7/YRgl6S1ynNzmfC79gtplJ2KlIckOuqcmZ1yWlvfWPCJYH/pT4W50cMwb Q3FXUlivzpFpgtSm0L/Ee5Q6Rkldlzfzbq29quTqFYkEpKxPp/2nFsoeuio1pJ4t06JicaRwMj63 7tS9m3k2n+JX+Bbtt9P7GDe163T5s9iJD+N/KEtPhofS+0i4lLabntnqTaMiXkh1xUlab8h8a62O 9gufVufQ7Bqfg4GXX2rXd9vG2vZf1DFXO79E+e/9dXkPZZ+UFezrKbPKwSpVb5Rp3xVnkLvAPTj5 hu+mCKeu9spV586mONu0l0dOLzK7r4VP8Kn/+1fS0mHf7ZXzToqczGoUHHLoNueR8zne+w/dF13S ccM2RCELUoiqChiVa+sLlzhBVMra7HvqsXXXqCotjWZusab7LFsGqXsTaA/r+XnrV1hoCuQj7kTL VheSRIoXj1JfrjnZ46XM8pT+81KGmre6iWj6zzAjtum+cKdHFx4c8u8rvdvvgmWJalMLa493AJSK Qznm4ouCx1HtTh52fr8dkrmYzNjtHQCY8t5NGYtJY1VF621G3Wjl/sTLd+Vv7mL4tBW150QfflYh a27kIzyN+Gqmj1YtXCFqVWcr9Iubfe5nmL2QXRocG+lVILUJzHzxlOG4nX5GX52/61iqrFbGgWLG o0N6ddTAPu1r3YvtG4v15LB5Sb+s6yBLG3iHxDUE7Es/uyFKc/5pkHPdBCfdnkm+fyN/oKrEzSKu 8b1catpYEYVtyP+85nLmueCUxgwuYU+rpGk66i5urDh91aLLL3X7fKRu/lP+ni1WSsgda56yX35y z/v6P+RW2/DnPzd6dysEAVkJB4tKjSPmIb8siopu2LGq8+P5o2k3ogMScQ8d+CaN3q8I92I7HbWU k9S0R2SX6DyeHLlDOeHnuuEscHvJYFrQ7wUNS4KXF6xmfFLwLBTANopHPffiOqOyI5rlUrsC2gJd AvV/33FCdngNW5WV5FOem5m+6n22vMmihQz+MWZDrO51/4djPdtNsjRip/qfRxI68BP2pFNl0pml 2FXzTYGGR2lNkwG2F2IejQdmPF6Z5amYa2gCd/X6sJXlL/Qb12F11/cZ7TV9JdV0MPIam7oFm7dW qqGhvaCJKzPv2sAkrSh255ktr4dXaL4LU3eaJ7TravIN13iyY9kmmYeHHyU84T6GxOsmbC6tiVn+ 5777WlnOOOIGq07XvnjNhMfDcfYNjxuUZdtb9SYNh23Wra/Dtrxb1IpbXdrsPFXrfS8Kk6LiqPq6 yWBQfM3VlddmPrhBVGjniSjpn7FSuOJmpGg8UTdCHH/tQ1Qolr6YT+GM8tsHpi+r/0JLXTzpYb9L yYiu0KgIc8zyTKfVtgQXplB429K6fS3ffl4uL/9fyWXbSwplbmRzdHJlYW0KZW5kb2JqCjU5IDAg b2JqIDw8Ci9Qcm9kdWNlciAocGRmVGVYLTEuNDAuMTIpCi9DcmVhdG9yIChUZVgpCi9DcmVhdGlv bkRhdGUgKEQ6MjAxMjAzMjYyMDU5NDMrMDInMDAnKQovTW9kRGF0ZSAoRDoyMDEyMDMyNjIwNTk0 MyswMicwMCcpCi9UcmFwcGVkIC9GYWxzZQovUFRFWC5GdWxsYmFubmVyIChUaGlzIGlzIHBkZlRl WCwgVmVyc2lvbiAzLjE0MTU5MjYtMi4zLTEuNDAuMTIgKFRlWCBMaXZlIDIwMTEpIGtwYXRoc2Vh IHZlcnNpb24gNi4wLjEpCj4+IGVuZG9iago4IDAgb2JqIDw8Ci9UeXBlIC9PYmpTdG0KL04gNDIK L0ZpcnN0IDMxMgovTGVuZ3RoIDIxOTEgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnja7VlZbxtJDn7Xr6jHWSyiui8gGMCXHMV21uszB/KgyG1bGEdypHYmmV+/PNpSdyuNieJg MQMMYDHsKhbJj2SxqtNGKKFFtkJroWMWWgkTHbDCBhgMwvkkjBU+aWGMCDEIE0QMXhgvUlA9k0R2 WZgscsjCKpGjFxZUJiusAQ1KC4uaFKh0oANELKwOsN4GWOBBDqeM7llQEJ0XDpZkD/9aYME+Dlkw 6SL8JSfAnldGCw9/xisBKrxXHojwEbD4KIJSpqezCAbcNUoEC3KwJLgIzngRfAZhwANzToQEJmBR jhANK6LKEAInosEVIlrne1lEB7PgTfRO9Z4/78mzr/eFkMejm6Ind2bTspiWC2EhoCc9eVIsZg/z cbGA6NLAUXE1GW3Pvoh3CgZi1v2cwT1t3vdAxRzWikySv/5KygegUDx/LuQAADicQRZ9rlhwt2Ih LJFYWCqP57PxaVGKd+DZ7kDIs+JLKd4/av2my9qs+aye6rRLGEj2T1MwK7cdRv8n+Z3W/A7/D79x q+SKT1hczEasr5+DzLg2MmP+Dhkxcc1v/xfy+50PuQ9baEXfw5hSQGOM/YRPNvShqxBN2vZzRY1N SEPoR+g9au0XaMY514f2lFQ/YPPoG0F6SSIFDTpzXI2yTqszrCEJa/u2xkWfgBqStYlkiaJEpYHn SNosLX3vz9R1kBes1ZGPTBlXg5LXjM7niDTgWp6NauVzpSFjTLzTMJvgbGCJSBGudDHvPPrvPcQu UARDipAn1pshsr7ph8Z4mmVEalwNF+fC61V26jycPjiL8aDRepYd6eORmFcrV9JMLSGzCXNgKceV BeIDjTNfUev6cVl3PlG9EU2ZYkTUUBwMz+IR1/pFyjn76IPHiJKPidahRHaYG60oOTzMSi0XMRVX ZiAgrpXJ6IPFeHFcnKEIEkURVsJzrKSK3zf86/pVq2s6Ko95F3AVcvXXqTLgAyMMFG/OfjVL49aq pZ4YcM96yn2mOmCZita0Md/QRmuZ16oq0JUrgYraOkuJwRg+8k1wHs9qTniVJC4NpNYu00qjjWQT DB5JnCleuZRmanmTGgyGU462Ic1ic+BCr7a5iwGfPJWb1dhiNqQme/SSKPqeRDKkU2naEHq58es0 xIRhDhGTZrEY4Q6IjZFl8D5GGqv1IAFRgjXQJKHkNEnAbQ+TzZqYp6bgs0IdxuNKKFxTadVK2b5v uuEyJknlCsyKq8PyWlGXSlj3FNo6bw2arkJC48ajHQOXXKw4XT0nKIVUSdSlmdpgAKKDIFhMhXZU r//QvziFXLmUsRa+g5po6Ge1pl6icQby7ioaPPUbuLBgXeL7iact4bBW6Kzwnk5DloOWYOk8gq3u 8dYSIm11gy0lORohGT6P4W2HNgTx0EiwivFkxg5YnZpgOeN7kWPe5wReYR1X/q+4CokLiTa5wfPG etRZ403GzccreBxe8JB63KYu0g6jkRgJI6+tyTO1FvFakMe9AW9v6HFM2NRgJzmKVEAaLO02bAjO 4X4Knvq+wpEEezFVMiGjRp/REvNBUdMylAdHNwzar8Hg3SIlbCbMM/URdz3EAHdtxGg2eMjtI3Xg A4wnPDmcTjXOQLuy1QoeNWAfousIAUQpViPw4kuHhV1aqHii1ii6Xyjwy1quN5q1mnAgGuaJvq/d 0fEqvVssxvPJfTmb89X61egjzPx3uHf4cvvfO0dHQ61g4m50sxCOJbbpsv4MXuGfGboeOHzzhTNE bi3GeF2Hex3c/Ef3L4rJzW2JF52eRDM490zj5LAc3U3GW9ObuwJGYOC0LD5eQHn25OtqFTgLSm5H c7yw/yJv5sWoLOb/YhcGE1hoU/214M8Qbe+cDt8eAqKTLkBOPQKCc+AJgNQjnJA74ZS/z+pQnNoE yt6L4f7uS4QSv40EXrYYiYaXw5+BJHYjuYbXObmYfGnAMZvAOTx/c743BDinp12pga1OgPDNMPrc jQcfvwdPquFxro5nS27LHbkr9+RA7ssXcigP5KE8kq/ksTyRp/JMnssLeSlH8oMcy/HsbjaVV7KQ pExey+sJ/H0uOC438lbefr2/LaZyIn+Td/KjnMrpZFrImZwBvZf3+IZ7V1yXzM1Jy30xn8yu5Cf5 6aFYlBOw8OlhVhZXH+5I8vGBhSH6clF8BhOQBVnK8nZeFFhg8kF+lr/LL/Kr/EP+UcybFec2SdH+ 263j4RtOkelIEbUDfI3FbpCenqLQmSJMzRCScQZJGC9DP4HwzigaFIEG2LAJ2MuLrePBAYPt2GA+ VfVo80Zg/feAtaoOdgfgvpT/gcqDmgKQMygaAgnp/doAuVE7PDp48fb1OYFMHQn1j+0QUgvXlSdn NMUNM7raR5xb3DHL/LZbqN+ohV68Gpzu7hH87dddXSfqxwhg20nqyRHQtp5nn5p9B7vOPoThJXUc 7jFj7i3Tq9HiFlsLNpRJ1UdmXe2DywN2fSM+G/Xk/cHW5ck+xudNV3RMFs9ywENGwxUl+lV04MT5 sfPfqc5j5sMD9L6yAWijDnZ+fHlwgfV+dtbVwTDbFm+BcAfMNThB6wYcfFzCgRta1+nvO8GMSqry azgSPmIaud3PZRNfR9MC/Q8fSnrEQVC8PVoU9L+ia9e2RjiE5f9HlYPJfFGiN3Cb7cnDUe3hcnJV 3i7wY83GtlsXrKZpp9umsUaWpvGhMm3y5qabF6KWZbtmuQ7au5XltLnl9t2lZdu3beu6bW1qEdeb G2+fyi3jcQ24rhvXfmX8B0qtfUq2jK+XWmwg1yvjcXPjrdOraduv1ZrLXcDd5rbXj46WefsnSbcr 8/YHkt7qzC3j6xXn68Zr0M3mtttNtGV7reBcaMQ9rIz7deP4wWiBX4wewBT4eTC5Woh35CV+gqZ/ +FOO4Y8+hqq29dlpZwS9eHbTY3WrL0f/A/ZTi4cKZW5kc3RyZWFtCmVuZG9iago2MCAwIG9iaiA8 PAovVHlwZSAvWFJlZgovSW5kZXggWzAgNjFdCi9TaXplIDYxCi9XIFsxIDMgMV0KL1Jvb3QgNTgg MCBSCi9JbmZvIDU5IDAgUgovSUQgWzxDREE3RDk0ODJDQTU5M0MzNkM4MkVDOTkzOEUwRTZGRT4g PENEQTdEOTQ4MkNBNTkzQzM2QzgyRUM5OTM4RTBFNkZFPl0KL0xlbmd0aCAxNzMgICAgICAgCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42h3L2QnCUBSE4ZkYTeIW933fBbEKH1KBvood CFqCYAdWIPZgLUJAsAEbUOa8fPz3DBcAfg7gU4BACNVYjMRcTMjd24aFSAiH4NluUzETQ5EULuEe bO2JvhgIT6QIr2RrIHwiiOyZFhmRFTmRF6EoiKIoiTKRudi3CjH7WlWJzcmqRuzvVnXiFls1iOfa qkm8rlYtEkerNrn6WHXI6GHVFUtyG4Pcx/gDPo8UswplbmRzdHJlYW0KZW5kb2JqCnN0YXJ0eHJl Zgo5MDMzNQolJUVPRgo= --_004_4E1F6AAD24975D4BA5B1680429673943664621C2TK5EX14MBXC283r_-- From bcampbell@pingidentity.com Wed Apr 11 08:19:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212F121F8565 for ; Wed, 11 Apr 2012 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 585a0V+U26Mg for ; Wed, 11 Apr 2012 08:19:29 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 6171B21F855F for ; Wed, 11 Apr 2012 08:19:28 -0700 (PDT) Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKT4Wg/yOnrUN4pxIVMUtyE5PbcNkPk0+w@postini.com; Wed, 11 Apr 2012 08:19:28 PDT Received: by vcbf11 with SMTP id f11so692318vcb.10 for ; Wed, 11 Apr 2012 08:19:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=4dbhZUKYPAUka97dAGHhXuV739O3HEZkH3xJrSF4wEY=; b=iEp9j37lCew5pECBH2b9ZqKDxgfHKkr4AlugH2UEjngsasTLoxpnYMwtcW5ov62uN1 npV2l8P0Os71oN1TjMbAOS0jFF/Dk/OQExSiK66r3eegtfJFgbFBS/f6pXfjKJJNXNvF S3NO2623ueg9zcaHfydbfTSy3ZuGZs0fz7zO5Cu9dNFmUu1yqwg6b6B2GriYExmTiX4K dKGA6/kWsfsvnCc+Pmar8ytH/T2bPVjRBVPrt9YHZfjrnZTJFdfHb9jcLgeYV6d/XatC GQjv9kf60cbamFz3MzizFC39NSROEPx2uEErjymzMYhNBpcfgpefDJaXHi4C3LYac7hJ BgQA== Received: by 10.220.116.7 with SMTP id k7mr7968064vcq.13.1334157566942; Wed, 11 Apr 2012 08:19:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Wed, 11 Apr 2012 08:18:56 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664621C2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <066101cd1372$b3c60130$1b520390$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943664621C2@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Wed, 11 Apr 2012 09:18:56 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlmJ/gXHO+mdsftBXYA0OPlWcMqtIoo+LNPFJUg2iJJi49cQzKpLd/mGLWqw6d1kl6CjdDR Cc: John Bradley , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:19:30 -0000 Thanks Mike, I guess I should have stayed for the week in Paris, eh? Just to be totally clear - and it probably already is so this will be redundant but what the heck - that presentation talks about minimum key length recommendations. Which is useful in general and also as input into this discussion. But JWE (or JWA - I'm not sure) needs to define the *exact* key lengths as input into the KDF for the various HMAC integrity algorithms. Key sizes equal to the hash output sizes makes sense but it just needs to be made explicit. Thanks, B On Tue, Apr 10, 2012 at 5:15 PM, Mike Jones w= rote: > Eric Rescorla recommended that key sizes equal to the hash output sizes b= e > used in his presentation in Paris (attached). > > > > Thanks for pointing out that the spec needs to nail this down! > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Brian Campbell > Sent: Tuesday, April 10, 2012 4:06 PM > To: Jim Schaad > Cc: John Bradley; jose@ietf.org > > > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > > > That's a good point that I hadn't considered. But it leads me to another > question. What key size(s) should be used for generated the Content > Integrity Key? I ask because HMAC can take keys of arbitrary length. > > I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message > Authentication"* and it seems to suggest that an optimal key length would= be > equal to the hash output length. But for the sake of interoperability, it > seems like JWE/JWA should be very specific about key lengths for derived > keys for each integrity algorithm (if this is already in the, I couldn't > find it, so please excuse me and point me to the text). > > * =A73 of http://tools.ietf.org/html/rfc2104 > > On Thu, Apr 5, 2012 at 3:26 PM, Jim Schaad wrote= : > > Another reason is that the algorithms may use two different key sizes and > thus you need to deal with the expansion/truncation questions. > > > jim > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> John Bradley > >> Sent: Wednesday, April 04, 2012 4:42 PM >> To: Brian Campbell >> Cc: jose@ietf.org >> Subject: Re: [jose] Understanding the motivation for Key Derivation? >> > >> The use of a single key across two functions is one of things that is no= t >> provably without problems. >> >> I agree that from an implementers point of view one key is simpler. >> >> There is a related-key attack that using the same key would enable. =A0T= his > can >> be combined with differential and linear attacks on symmetric key cypher= s. >> >> Generally this can be thought of as a bad thing. >> >> What is certain is that it increases the possible attack surface, =A0and= if > the is a >> problem discovered as we have seen with AES-CBC it is going to be hard t= o >> change later. >> >> We need key derivation anyway for ECDH-ES to produce a key of the correc= t >> bit length. >> >> Doing key derivation on CMK is the theoretically proper way to do it. >> Making a simplification might bite us in the future. >> >> I suppose one way to get around the conditional application argument is = to >> always use it to produce the CEK even with AEAD algorithms. >> >> Regards >> John B. >> >> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >> >> > Hi all, >> > >> > I was hoping someone could help me (hopefully it's not just me!) >> > understand the reasons for the introduction of the key derivation >> > stuff* into JWE draft -01? >> > >> > I understand that it's there to derive the two keys, CEK and CIK, from >> > the CMK and that it is to be done when a non-AEAD algorithm is used to >> > encrypt the content. But what is the value of deriving the two keys as >> > apposed to using the CMK for both encryption and integrity? >> > >> > Perhaps naively I assumed that using the CMK for both would be >> > sufficient. =A0It's randomly generated and used only for the one JWE. >> > It's not clear to me what benefit is provided by the additional >> > complexity of the derivation function as well as its conditional >> > application (and the potential interoperability problems that come >> > with such complexity). I assume there's some security benefit? But I >> > can't see what it is. >> > >> > Any help would be appreciated. >> > Thanks, >> > Brian >> > >> > * >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect >> > ion-7 >> > which is referenced by >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect >> > ion-5 and >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect > >> > ion-6 _______________________________________________ > >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose > > From Michael.Jones@microsoft.com Wed Apr 11 08:26:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD31421F84DA for ; Wed, 11 Apr 2012 08:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.219 X-Spam-Level: X-Spam-Status: No, score=-5.219 tagged_above=-999 required=5 tests=[AWL=1.380, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ1tOjftiMLz for ; Wed, 11 Apr 2012 08:26:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id E44D921F847F for ; Wed, 11 Apr 2012 08:26:22 -0700 (PDT) Received: from mail152-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 15:26:22 +0000 Received: from mail152-tx2 (localhost [127.0.0.1]) by mail152-tx2-R.bigfish.com (Postfix) with ESMTP id 622F72A01B1; Wed, 11 Apr 2012 15:26:22 +0000 (UTC) X-SpamScore: -45 X-BigFish: VS-45(zz9371I936eK542M1432N98dK4015I148cM14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail152-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail152-tx2 (localhost.localdomain [127.0.0.1]) by mail152-tx2 (MessageSwitch) id 133415798057592_23989; Wed, 11 Apr 2012 15:26:20 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.251]) by mail152-tx2.bigfish.com (Postfix) with ESMTP id 03B5D3A0056; Wed, 11 Apr 2012 15:26:20 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 15:26:17 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Wed, 11 Apr 2012 15:26:15 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [jose] Understanding the motivation for Key Derivation? Thread-Index: AQHNErQOZlMb1ahKqUiwv3kEv/baLJaLU7cAgAFsRoCAB/eKgIAAAfFQgAEN8gCAAAH/4A== Date: Wed, 11 Apr 2012 15:26:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366462FEC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <066101cd1372$b3c60130$1b520390$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943664621C2@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: John Bradley , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:26:25 -0000 Agreed -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bri= an Campbell Sent: Wednesday, April 11, 2012 8:19 AM To: Mike Jones Cc: John Bradley; Jim Schaad; jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? Thanks Mike, I guess I should have stayed for the week in Paris, eh? Just to be totally clear - and it probably already is so this will be redun= dant but what the heck - that presentation talks about minimum key length r= ecommendations. Which is useful in general and also as input into this disc= ussion. But JWE (or JWA - I'm not sure) needs to define the *exact* key le= ngths as input into the KDF for the various HMAC integrity algorithms. Key = sizes equal to the hash output sizes makes sense but it just needs to be ma= de explicit. Thanks, B On Tue, Apr 10, 2012 at 5:15 PM, Mike Jones w= rote: > Eric Rescorla recommended that key sizes equal to the hash output=20 > sizes be used in his presentation in Paris (attached). > > > > Thanks for pointing out that the spec needs to nail this down! > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --=20 > Mike > > > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Brian Campbell > Sent: Tuesday, April 10, 2012 4:06 PM > To: Jim Schaad > Cc: John Bradley; jose@ietf.org > > > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > > > That's a good point that I hadn't considered. But it leads me to=20 > another question. What key size(s) should be used for generated the=20 > Content Integrity Key? I ask because HMAC can take keys of arbitrary leng= th. > > I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message > Authentication"* and it seems to suggest that an optimal key length=20 > would be equal to the hash output length. But for the sake of=20 > interoperability, it seems like JWE/JWA should be very specific about=20 > key lengths for derived keys for each integrity algorithm (if this is=20 > already in the, I couldn't find it, so please excuse me and point me to t= he text). > > * =A73 of http://tools.ietf.org/html/rfc2104 > > On Thu, Apr 5, 2012 at 3:26 PM, Jim Schaad wrote= : > > Another reason is that the algorithms may use two different key sizes=20 > and thus you need to deal with the expansion/truncation questions. > > > jim > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >> Of John Bradley > >> Sent: Wednesday, April 04, 2012 4:42 PM >> To: Brian Campbell >> Cc: jose@ietf.org >> Subject: Re: [jose] Understanding the motivation for Key Derivation? >> > >> The use of a single key across two functions is one of things that is=20 >> not provably without problems. >> >> I agree that from an implementers point of view one key is simpler. >> >> There is a related-key attack that using the same key would enable. =A0 >> This > can >> be combined with differential and linear attacks on symmetric key cypher= s. >> >> Generally this can be thought of as a bad thing. >> >> What is certain is that it increases the possible attack surface, =A0 >> and if > the is a >> problem discovered as we have seen with AES-CBC it is going to be=20 >> hard to change later. >> >> We need key derivation anyway for ECDH-ES to produce a key of the=20 >> correct bit length. >> >> Doing key derivation on CMK is the theoretically proper way to do it. >> Making a simplification might bite us in the future. >> >> I suppose one way to get around the conditional application argument=20 >> is to always use it to produce the CEK even with AEAD algorithms. >> >> Regards >> John B. >> >> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >> >> > Hi all, >> > >> > I was hoping someone could help me (hopefully it's not just me!)=20 >> > understand the reasons for the introduction of the key derivation >> > stuff* into JWE draft -01? >> > >> > I understand that it's there to derive the two keys, CEK and CIK,=20 >> > from the CMK and that it is to be done when a non-AEAD algorithm is=20 >> > used to encrypt the content. But what is the value of deriving the=20 >> > two keys as apposed to using the CMK for both encryption and integrity= ? >> > >> > Perhaps naively I assumed that using the CMK for both would be=20 >> > sufficient. =A0It's randomly generated and used only for the one JWE. >> > It's not clear to me what benefit is provided by the additional=20 >> > complexity of the derivation function as well as its conditional=20 >> > application (and the potential interoperability problems that come=20 >> > with such complexity). I assume there's some security benefit? But=20 >> > I can't see what it is. >> > >> > Any help would be appreciated. >> > Thanks, >> > Brian >> > >> > * >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#s >> > ect >> > ion-7 >> > which is referenced by >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#s >> > ect >> > ion-5 and >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#s >> > ect > >> > ion-6 _______________________________________________ > >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Wed Apr 11 09:11:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49621F844E for ; Wed, 11 Apr 2012 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO3D01Fa2IoI for ; Wed, 11 Apr 2012 09:11:38 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2D71D21F853F for ; Wed, 11 Apr 2012 09:11:38 -0700 (PDT) Received: from Tobias (unknown [50.34.251.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 495132CA4B; Wed, 11 Apr 2012 09:11:37 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> In-Reply-To: <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> Date: Wed, 11 Apr 2012 09:10:22 -0700 Message-ID: <01c001cd17fd$a67606d0$f3621470$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHZrmAco3AbGqXh0I+g1KfPwtE7gGNJkrMAtHy7j4CTGAGGAJ3LV1+AWIsXygChPtv4AG/s34ilKrgonA= Content-Language: en-us Cc: 'Brian Campbell' , jose@ietf.org, 'Matt Miller' Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:11:40 -0000 John, I would be nice if you did this. Personally I would like to see the text move back to the -00 version as the base to start from. I would be nice if the description was strictly in terms of how AEAD algorithms are processed. For the S/MIME work, we would still use the term CEK for the key fed into an AEAD algorithm even if the algorithm later produced two different keys for use in the encryption and authentication processing. The details of that would be purely internal to the algorithm description. As a part of this I think it would be more reasonable to move the details of how to do the CBC/HMAC algorithm to the algorithms document rather than putting in this document so that this document is simpler and clearer. Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Thursday, April 05, 2012 9:11 AM > To: Jim Schaad > Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org > Subject: Re: [jose] Understanding the motivation for Key Derivation? > > Then we should look at including the header as the additional data for GCM. > > I will have a look at it, and make a proposal for some text, unless someone > else is volunteering? > > John B. > > On 2012-04-05, at 1:05 PM, Jim Schaad wrote: > > > Ok - I see you problem. > > > > Yes, in JWE the headers are not encrypted. > > GCM provides integrity over both the encrypted content and the additional > > data fields (hence the difference between AD (authenticated Data) and > > AEAD(Authenticated Data with Additional Data). > > > > All AEAD algorithms provide for the ability to have data which is not part > > of the encrypted data be included in the authenticated data. In fact AEAD > > algorithms can be used as MAC algorithms in many cases by simply having > an > > empty string for the encrypted data (it depends in part on the internal > > construction of the encrypted data stream). I believe we verified that this > > was a true statement for GCM at the last IETF meeting (in a hallway > > conversation). > > > > Jim > > > > > >> -----Original Message----- > >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >> Sent: Thursday, April 05, 2012 8:45 AM > >> To: Jim Schaad > >> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org > >> Subject: Re: [jose] Understanding the motivation for Key Derivation? > >> > >> In JWE the headers are not encrypted. > >> > >> GCM provides integrity only over the encrypted content. > >> > >> In the composite AES-CBC + HMAC the integrity is calculated over both > the > >> Header and the encrypted content. > >> > >> The advantage of not using a AEAD algorithm is that the composite can be > >> more JOSE aware. > >> > >> I can't rule out having missed something thats why we review these > > things:) > >> > >> John B. > >> On 2012-04-05, at 12:28 PM, Jim Schaad wrote: > >> > >>> > >>> > >>> John, > >>> > >>> I am at a loss, why do you believe that a new AEAD algorithm would not > >>> protect the headers? > >>> > >>> Jim > >>> > >>> > >>>> -----Original Message----- > >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > Behalf > >> Of > >>>> John Bradley > >>>> Sent: Thursday, April 05, 2012 7:28 AM > >>>> To: Matt Miller > >>>> Cc: Brian Campbell; jose@ietf.org > >>>> Subject: Re: [jose] Understanding the motivation for Key Derivation? > >>>> > >>>> A couple of observations. > >>>> > >>>> The current proposal provides integrity over the header, a new AEAD > > alg > >>>> doesn't do that. > >>>> Low level crypto is a challenge. Re-using standard underlying > > algorithms > >>> like > >>>> HMAC and AES-CBC allow for JS and other libs to call standard lower > > level > >>>> crypto functions. > >>>> > >>>> I am not against having another AEAD alg, but want to help people > >>>> understand the current design choice. > >>>> > >>>> John B. > >>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: > >>>> > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA1 > >>>>> > >>>>> Another way around the conditional in application-space is to define > > an > >>>> AEAD algorithm composed of an encryption and hashing function. This > >>>> seems like a reasonable place to start looking at one: < > >>>> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. > >>>>> > >>>>> On Apr 4, 2012, at 17:42, John Bradley wrote: > >>>>> > >>>>>> The use of a single key across two functions is one of things that is > >>> not > >>>> provably without problems. > >>>>>> > >>>>>> I agree that from an implementers point of view one key is simpler. > >>>>>> > >>>>>> There is a related-key attack that using the same key would enable. > >>> This > >>>> can be combined with differential and linear attacks on symmetric key > >>>> cyphers. > >>>>>> > >>>>>> Generally this can be thought of as a bad thing. > >>>>>> > >>>>>> What is certain is that it increases the possible attack surface, > > and > >>> if the is > >>>> a problem discovered as we have seen with AES-CBC it is going to be > > hard > >>> to > >>>> change later. > >>>>>> > >>>>>> We need key derivation anyway for ECDH-ES to produce a key of the > >>>> correct bit length. > >>>>>> > >>>>>> Doing key derivation on CMK is the theoretically proper way to do it. > >>>>>> Making a simplification might bite us in the future. > >>>>>> > >>>>>> I suppose one way to get around the conditional application > argument > >> is > >>>> to always use it to produce the CEK even with AEAD algorithms. > >>>>>> > >>>>>> Regards > >>>>>> John B. > >>>>>> > >>>>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: > >>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I was hoping someone could help me (hopefully it's not just me!) > >>>>>>> understand the reasons for the introduction of the key derivation > >>>>>>> stuff* into JWE draft -01? > >>>>>>> > >>>>>>> I understand that it's there to derive the two keys, CEK and CIK, > >>>>>>> from the CMK and that it is to be done when a non-AEAD algorithm > is > >>>>>>> used to encrypt the content. But what is the value of deriving the > >>>>>>> two keys as apposed to using the CMK for both encryption and > >>> integrity? > >>>>>>> > >>>>>>> Perhaps naively I assumed that using the CMK for both would be > >>>>>>> sufficient. It's randomly generated and used only for the one JWE. > >>>>>>> It's not clear to me what benefit is provided by the additional > >>>>>>> complexity of the derivation function as well as its conditional > >>>>>>> application (and the potential interoperability problems that come > >>>>>>> with such complexity). I assume there's some security benefit? But > I > >>>>>>> can't see what it is. > >>>>>>> > >>>>>>> Any help would be appreciated. > >>>>>>> Thanks, > >>>>>>> Brian > >>>>>>> > >>>>>>> * > >>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- > 01#se > >>>>>>> ction-7 > >>>>>>> which is referenced by > >>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- > 01#se > >>>>>>> ction-5 and > >>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- > 01#se > >>>>>>> ction-6 > _______________________________________________ > >>>>>>> jose mailing list > >>>>>>> jose@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>> _______________________________________________ > >>>>>> jose mailing list > >>>>>> jose@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>> > >>>>> > >>>>> - - m&m > >>>>> > >>>>> Matt Miller - > >>>>> Cisco Systems, Inc. > >>>>> > >>>>> -----BEGIN PGP SIGNATURE----- > >>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > >>>>> Comment: GPGTools - http://gpgtools.org > >>>>> > >>>>> > >>>> > >> > iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq > >>>> zQj > >>>>> > >>>> > >> > YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR > >>>> 8kx > >>>>> > >>>> > >> > c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL > >>>> y > >>>>> > >>>> > >> > LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb > >>>> + > >>>>> > >>>> > >> > ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb > >>>> Y > >>>>> > >>>> > >> > LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG > >>>> z/I= > >>>>> =174E > >>>>> -----END PGP SIGNATURE----- > >>> > >>> > > > > From ve7jtb@ve7jtb.com Wed Apr 11 09:28:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420DA21F8595 for ; Wed, 11 Apr 2012 09:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzX0GU5Xw-T8 for ; Wed, 11 Apr 2012 09:28:56 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D919721F8547 for ; Wed, 11 Apr 2012 09:28:55 -0700 (PDT) Received: by ggmi1 with SMTP id i1so640073ggm.31 for ; Wed, 11 Apr 2012 09:28:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=X4cR1cKP3JzAZnmlbElRidrXLkWEbkfUbgpt9HA0afQ=; b=YyZZqUV1a29ULXGMcuG4PcYmXcbcC53NDqKe2DgcRVuo+8DAvgUO1IWANCpqGMo51o SfgHpgoSX4BklXyH+pL0ANywexph5QYuaukm69MNcMgXvljqpOKXmXYOrSzcULmDBzWc gS1c7i7pGknkDetSnpp5Qn4QG9XdfMeBUNDiTSXgvISZlIzzwTFlI7GX8Iheng706MQg k8tXcJ/2h5DTWVO/2tE47CutGiwNcC00/yYbyrl6CWQWRWBdxM69eu8ebTcNx5IhQdRg VnVVtGfHL3hxEux4nYKlSn0Igs/lcrR7NH9l71Nr0si+7yZRusui/u3hbmVjz+VX/XvM Z+/w== Received: by 10.236.168.6 with SMTP id j6mr13519130yhl.115.1334161735269; Wed, 11 Apr 2012 09:28:55 -0700 (PDT) Received: from [172.20.10.4] ([201.220.233.202]) by mx.google.com with ESMTPS id g49sm12021396yhk.20.2012.04.11.09.28.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 09:28:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_FF55D4CC-1BC3-47E1-A6AD-5DDA3250B155"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <01c001cd17fd$a67606d0$f3621470$@augustcellars.com> Date: Wed, 11 Apr 2012 13:29:13 -0300 Message-Id: <63AD1F34-D6D0-4E7D-B059-41FD1D14F35D@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> <01c001cd17fd$a67606d0$f3621470$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkM3kYyxya2UDs8bkSarPBChDMU9pnq7AiazXpbHlzbYZfRFpI9Eo+7nRcwAR9kOKdNZQwc Cc: 'Brian Campbell' , jose@ietf.org, 'Matt Miller' Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:28:57 -0000 --Apple-Mail=_FF55D4CC-1BC3-47E1-A6AD-5DDA3250B155 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes making both AEAD and our composite HMAC process the envelope in the = same way so that as much as possible they look the same is a good idea. I am just off to Munich for EIC. I will try to get to it next week when = Mike and I are at EIC. John B. On 2012-04-11, at 1:10 PM, Jim Schaad wrote: > >=20 > John,=20 >=20 > I would be nice if you did this. Personally I would like to see the = text > move back to the -00 version as the base to start from. I would be = nice if > the description was strictly in terms of how AEAD algorithms are = processed. > For the S/MIME work, we would still use the term CEK for the key fed = into an > AEAD algorithm even if the algorithm later produced two different keys = for > use in the encryption and authentication processing. The details of = that > would be purely internal to the algorithm description. >=20 > As a part of this I think it would be more reasonable to move the = details of > how to do the CBC/HMAC algorithm to the algorithms document rather = than > putting in this document so that this document is simpler and clearer. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Thursday, April 05, 2012 9:11 AM >> To: Jim Schaad >> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >> Subject: Re: [jose] Understanding the motivation for Key Derivation? >>=20 >> Then we should look at including the header as the additional data = for > GCM. >>=20 >> I will have a look at it, and make a proposal for some text, unless > someone >> else is volunteering? >>=20 >> John B. >>=20 >> On 2012-04-05, at 1:05 PM, Jim Schaad wrote: >>=20 >>> Ok - I see you problem. >>>=20 >>> Yes, in JWE the headers are not encrypted. >>> GCM provides integrity over both the encrypted content and the > additional >>> data fields (hence the difference between AD (authenticated Data) = and >>> AEAD(Authenticated Data with Additional Data). >>>=20 >>> All AEAD algorithms provide for the ability to have data which is = not > part >>> of the encrypted data be included in the authenticated data. In = fact > AEAD >>> algorithms can be used as MAC algorithms in many cases by simply = having >> an >>> empty string for the encrypted data (it depends in part on the = internal >>> construction of the encrypted data stream). I believe we verified = that > this >>> was a true statement for GCM at the last IETF meeting (in a hallway >>> conversation). >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Thursday, April 05, 2012 8:45 AM >>>> To: Jim Schaad >>>> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >>>> Subject: Re: [jose] Understanding the motivation for Key = Derivation? >>>>=20 >>>> In JWE the headers are not encrypted. >>>>=20 >>>> GCM provides integrity only over the encrypted content. >>>>=20 >>>> In the composite AES-CBC + HMAC the integrity is calculated over = both >> the >>>> Header and the encrypted content. >>>>=20 >>>> The advantage of not using a AEAD algorithm is that the composite = can > be >>>> more JOSE aware. >>>>=20 >>>> I can't rule out having missed something thats why we review these >>> things:) >>>>=20 >>>> John B. >>>> On 2012-04-05, at 12:28 PM, Jim Schaad wrote: >>>>=20 >>>>> >>>>>=20 >>>>> John, >>>>>=20 >>>>> I am at a loss, why do you believe that a new AEAD algorithm would = not >>>>> protect the headers? >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> John Bradley >>>>>> Sent: Thursday, April 05, 2012 7:28 AM >>>>>> To: Matt Miller >>>>>> Cc: Brian Campbell; jose@ietf.org >>>>>> Subject: Re: [jose] Understanding the motivation for Key = Derivation? >>>>>>=20 >>>>>> A couple of observations. >>>>>>=20 >>>>>> The current proposal provides integrity over the header, a new = AEAD >>> alg >>>>>> doesn't do that. >>>>>> Low level crypto is a challenge. Re-using standard underlying >>> algorithms >>>>> like >>>>>> HMAC and AES-CBC allow for JS and other libs to call standard = lower >>> level >>>>>> crypto functions. >>>>>>=20 >>>>>> I am not against having another AEAD alg, but want to help = people >>>>>> understand the current design choice. >>>>>>=20 >>>>>> John B. >>>>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>>>>>=20 >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>>=20 >>>>>>> Another way around the conditional in application-space is to = define >>> an >>>>>> AEAD algorithm composed of an encryption and hashing function. = This >>>>>> seems like a reasonable place to start looking at one: < >>>>>> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. >>>>>>>=20 >>>>>>> On Apr 4, 2012, at 17:42, John Bradley wrote: >>>>>>>=20 >>>>>>>> The use of a single key across two functions is one of things = that > is >>>>> not >>>>>> provably without problems. >>>>>>>>=20 >>>>>>>> I agree that from an implementers point of view one key is = simpler. >>>>>>>>=20 >>>>>>>> There is a related-key attack that using the same key would = enable. >>>>> This >>>>>> can be combined with differential and linear attacks on symmetric = key >>>>>> cyphers. >>>>>>>>=20 >>>>>>>> Generally this can be thought of as a bad thing. >>>>>>>>=20 >>>>>>>> What is certain is that it increases the possible attack = surface, >>> and >>>>> if the is >>>>>> a problem discovered as we have seen with AES-CBC it is going to = be >>> hard >>>>> to >>>>>> change later. >>>>>>>>=20 >>>>>>>> We need key derivation anyway for ECDH-ES to produce a key of = the >>>>>> correct bit length. >>>>>>>>=20 >>>>>>>> Doing key derivation on CMK is the theoretically proper way to = do > it. >>>>>>>> Making a simplification might bite us in the future. >>>>>>>>=20 >>>>>>>> I suppose one way to get around the conditional application >> argument >>>> is >>>>>> to always use it to produce the CEK even with AEAD algorithms. >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> I was hoping someone could help me (hopefully it's not just = me!) >>>>>>>>> understand the reasons for the introduction of the key = derivation >>>>>>>>> stuff* into JWE draft -01? >>>>>>>>>=20 >>>>>>>>> I understand that it's there to derive the two keys, CEK and = CIK, >>>>>>>>> from the CMK and that it is to be done when a non-AEAD = algorithm >> is >>>>>>>>> used to encrypt the content. But what is the value of deriving = the >>>>>>>>> two keys as apposed to using the CMK for both encryption and >>>>> integrity? >>>>>>>>>=20 >>>>>>>>> Perhaps naively I assumed that using the CMK for both would be >>>>>>>>> sufficient. It's randomly generated and used only for the one > JWE. >>>>>>>>> It's not clear to me what benefit is provided by the = additional >>>>>>>>> complexity of the derivation function as well as its = conditional >>>>>>>>> application (and the potential interoperability problems that = come >>>>>>>>> with such complexity). I assume there's some security benefit? = But >> I >>>>>>>>> can't see what it is. >>>>>>>>>=20 >>>>>>>>> Any help would be appreciated. >>>>>>>>> Thanks, >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> * >>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >> 01#se >>>>>>>>> ction-7 >>>>>>>>> which is referenced by >>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >> 01#se >>>>>>>>> ction-5 and >>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >> 01#se >>>>>>>>> ction-6 >> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>> - - m&m >>>>>>>=20 >>>>>>> Matt Miller - >>>>>>> Cisco Systems, Inc. >>>>>>>=20 >>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>>>> Comment: GPGTools - http://gpgtools.org >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq >>>>>> zQj >>>>>>>=20 >>>>>>=20 >>>>=20 >> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR >>>>>> 8kx >>>>>>>=20 >>>>>>=20 >>>>=20 >> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL >>>>>> y >>>>>>>=20 >>>>>>=20 >>>>=20 >> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb >>>>>> + >>>>>>>=20 >>>>>>=20 >>>>=20 >> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb >>>>>> Y >>>>>>>=20 >>>>>>=20 >>>>=20 >> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG >>>>>> z/I=3D >>>>>>> =3D174E >>>>>>> -----END PGP SIGNATURE----- >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 --Apple-Mail=_FF55D4CC-1BC3-47E1-A6AD-5DDA3250B155 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx MTE2MjkxNFowIwYJKoZIhvcNAQkEMRYEFB/tpRObmT9THn/C7drvxzrvl9TsMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJSIq6UuqTzyV/4ldLGuX9h8fNKLfxPz3Y5Cpry1qopDEFVuRftluej0uoYyTuFaEgetr0vLz2ZR Lwpo+8cl68dzAucJuxS9LkRKFZe/if0scypI4Ei0Y0svgjBhoWfZ/gf/Z16EsaTvkoZApw6IneQV RBGLo2ekc5Hb0ufb6XgQchgy+gg7pmxg2kcpO+BEVemCtZHv/RJpjWg+RCbiXDPdUHfF+GlOqRUw U+fpzO8jQfh5Uk/Pzk+oF9LAwl4W+9Qmtef30AC9AdkGg1qXDB8lKYkWH58wlJCvILzz7xJU3zNN m47fUJ7dgu0BKIlqs+tgDa5mDoIq/LqazCVbh5AAAAAAAAA= --Apple-Mail=_FF55D4CC-1BC3-47E1-A6AD-5DDA3250B155-- From mamille2@cisco.com Wed Apr 11 09:31:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E75421F8595 for ; Wed, 11 Apr 2012 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsmHuld2uVDS for ; Wed, 11 Apr 2012 09:31:23 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3A21F858E for ; Wed, 11 Apr 2012 09:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=13721; q=dns/txt; s=iport; t=1334161883; x=1335371483; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=08Uv4KKXkP36dNbt9FPn8ORvwJbgyxu1+JH1oDsA2TQ=; b=mJ3vMVkEcJRBRY8OdvovIjkivpffi7CdTnuyKtvvzvema9BQrpi357Jn aw05/uJ5XSIqqFDFpBYl/Su8MABZVb2phDVsOBHc02qJgTJHBKqZHrOY+ iF26XvD4nklzbE/bi48fsY0lAGmPVA6x4keAlcCmmjE2vrlJly3Qf3ntl 8=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFWxhU+rRDoJ/2dsb2JhbABEuU6BB4IJAQEBBAEBAQ8BWwsMBAsOAwQBAQEnBwIlHwkIBhMih2sBC5pqoCSQY2MEiFqGEocAgRGNPIFpgwY X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="sig'?p7s'?scan'208";a="36937596" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 11 Apr 2012 16:31:23 +0000 Received: from dhcp-64-101-72-210.cisco.com (dhcp-64-101-72-210.cisco.com [64.101.72.210]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3BGVM9Q018535; Wed, 11 Apr 2012 16:31:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-72--627602004" From: Matt Miller In-Reply-To: <01c001cd17fd$a67606d0$f3621470$@augustcellars.com> Date: Wed, 11 Apr 2012 10:31:23 -0600 Message-Id: <032E5880-9B76-4693-A337-7C0F50CEBAD0@cisco.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> <01c001cd17fd$a67606d0$f3621470$@augustcellars.com> To: "Jim Schaad" Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: 'John Bradley' , 'Brian Campbell' , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:31:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-72--627602004 Content-Type: multipart/signed; boundary=Apple-Mail-71--627602011; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-71--627602011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was planning to start writing up a composite CBC/HMAC algorithm, based = partly on the work done by David McGrew. Is there still interest in = this? On Apr 11, 2012, at 10:10, Jim Schaad wrote: > >=20 > John,=20 >=20 > I would be nice if you did this. Personally I would like to see the = text > move back to the -00 version as the base to start from. I would be = nice if > the description was strictly in terms of how AEAD algorithms are = processed. > For the S/MIME work, we would still use the term CEK for the key fed = into an > AEAD algorithm even if the algorithm later produced two different keys = for > use in the encryption and authentication processing. The details of = that > would be purely internal to the algorithm description. >=20 > As a part of this I think it would be more reasonable to move the = details of > how to do the CBC/HMAC algorithm to the algorithms document rather = than > putting in this document so that this document is simpler and clearer. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Thursday, April 05, 2012 9:11 AM >> To: Jim Schaad >> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >> Subject: Re: [jose] Understanding the motivation for Key Derivation? >>=20 >> Then we should look at including the header as the additional data = for > GCM. >>=20 >> I will have a look at it, and make a proposal for some text, unless > someone >> else is volunteering? >>=20 >> John B. >>=20 >> On 2012-04-05, at 1:05 PM, Jim Schaad wrote: >>=20 >>> Ok - I see you problem. >>>=20 >>> Yes, in JWE the headers are not encrypted. >>> GCM provides integrity over both the encrypted content and the > additional >>> data fields (hence the difference between AD (authenticated Data) = and >>> AEAD(Authenticated Data with Additional Data). >>>=20 >>> All AEAD algorithms provide for the ability to have data which is = not > part >>> of the encrypted data be included in the authenticated data. In = fact > AEAD >>> algorithms can be used as MAC algorithms in many cases by simply = having >> an >>> empty string for the encrypted data (it depends in part on the = internal >>> construction of the encrypted data stream). I believe we verified = that > this >>> was a true statement for GCM at the last IETF meeting (in a hallway >>> conversation). >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Thursday, April 05, 2012 8:45 AM >>>> To: Jim Schaad >>>> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >>>> Subject: Re: [jose] Understanding the motivation for Key = Derivation? >>>>=20 >>>> In JWE the headers are not encrypted. >>>>=20 >>>> GCM provides integrity only over the encrypted content. >>>>=20 >>>> In the composite AES-CBC + HMAC the integrity is calculated over = both >> the >>>> Header and the encrypted content. >>>>=20 >>>> The advantage of not using a AEAD algorithm is that the composite = can > be >>>> more JOSE aware. >>>>=20 >>>> I can't rule out having missed something thats why we review these >>> things:) >>>>=20 >>>> John B. >>>> On 2012-04-05, at 12:28 PM, Jim Schaad wrote: >>>>=20 >>>>> >>>>>=20 >>>>> John, >>>>>=20 >>>>> I am at a loss, why do you believe that a new AEAD algorithm would = not >>>>> protect the headers? >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> John Bradley >>>>>> Sent: Thursday, April 05, 2012 7:28 AM >>>>>> To: Matt Miller >>>>>> Cc: Brian Campbell; jose@ietf.org >>>>>> Subject: Re: [jose] Understanding the motivation for Key = Derivation? >>>>>>=20 >>>>>> A couple of observations. >>>>>>=20 >>>>>> The current proposal provides integrity over the header, a new = AEAD >>> alg >>>>>> doesn't do that. >>>>>> Low level crypto is a challenge. Re-using standard underlying >>> algorithms >>>>> like >>>>>> HMAC and AES-CBC allow for JS and other libs to call standard = lower >>> level >>>>>> crypto functions. >>>>>>=20 >>>>>> I am not against having another AEAD alg, but want to help = people >>>>>> understand the current design choice. >>>>>>=20 >>>>>> John B. >>>>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>>>>>=20 >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>>=20 >>>>>>> Another way around the conditional in application-space is to = define >>> an >>>>>> AEAD algorithm composed of an encryption and hashing function. = This >>>>>> seems like a reasonable place to start looking at one: < >>>>>> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >. >>>>>>>=20 >>>>>>> On Apr 4, 2012, at 17:42, John Bradley wrote: >>>>>>>=20 >>>>>>>> The use of a single key across two functions is one of things = that > is >>>>> not >>>>>> provably without problems. >>>>>>>>=20 >>>>>>>> I agree that from an implementers point of view one key is = simpler. >>>>>>>>=20 >>>>>>>> There is a related-key attack that using the same key would = enable. >>>>> This >>>>>> can be combined with differential and linear attacks on symmetric = key >>>>>> cyphers. >>>>>>>>=20 >>>>>>>> Generally this can be thought of as a bad thing. >>>>>>>>=20 >>>>>>>> What is certain is that it increases the possible attack = surface, >>> and >>>>> if the is >>>>>> a problem discovered as we have seen with AES-CBC it is going to = be >>> hard >>>>> to >>>>>> change later. >>>>>>>>=20 >>>>>>>> We need key derivation anyway for ECDH-ES to produce a key of = the >>>>>> correct bit length. >>>>>>>>=20 >>>>>>>> Doing key derivation on CMK is the theoretically proper way to = do > it. >>>>>>>> Making a simplification might bite us in the future. >>>>>>>>=20 >>>>>>>> I suppose one way to get around the conditional application >> argument >>>> is >>>>>> to always use it to produce the CEK even with AEAD algorithms. >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> I was hoping someone could help me (hopefully it's not just = me!) >>>>>>>>> understand the reasons for the introduction of the key = derivation >>>>>>>>> stuff* into JWE draft -01? >>>>>>>>>=20 >>>>>>>>> I understand that it's there to derive the two keys, CEK and = CIK, >>>>>>>>> from the CMK and that it is to be done when a non-AEAD = algorithm >> is >>>>>>>>> used to encrypt the content. But what is the value of deriving = the >>>>>>>>> two keys as apposed to using the CMK for both encryption and >>>>> integrity? >>>>>>>>>=20 >>>>>>>>> Perhaps naively I assumed that using the CMK for both would be >>>>>>>>> sufficient. It's randomly generated and used only for the one > JWE. >>>>>>>>> It's not clear to me what benefit is provided by the = additional >>>>>>>>> complexity of the derivation function as well as its = conditional >>>>>>>>> application (and the potential interoperability problems that = come >>>>>>>>> with such complexity). I assume there's some security benefit? = But >> I >>>>>>>>> can't see what it is. >>>>>>>>>=20 >>>>>>>>> Any help would be appreciated. >>>>>>>>> Thanks, >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> * >>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >> 01#se >>>>>>>>> ction-7 >>>>>>>>> which is referenced by >>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >> 01#se >>>>>>>>> ction-5 and >>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >> 01#se >>>>>>>>> ction-6 >> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>> - - m&m >>>>>>>=20 >>>>>>> Matt Miller - >>>>>>> Cisco Systems, Inc. >>>>>>>=20 >>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>>>> Comment: GPGTools - http://gpgtools.org >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq >>>>>> zQj >>>>>>>=20 >>>>>>=20 >>>>=20 >> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR >>>>>> 8kx >>>>>>>=20 >>>>>>=20 >>>>=20 >> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL >>>>>> y >>>>>>>=20 >>>>>>=20 >>>>=20 >> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb >>>>>> + >>>>>>>=20 >>>>>>=20 >>>>=20 >> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb >>>>>> Y >>>>>>>=20 >>>>>>=20 >>>>=20 >> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG >>>>>> z/I=3D >>>>>>> =3D174E >>>>>>> -----END PGP SIGNATURE----- >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-71--627602011 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMTE2MzEy M1owIwYJKoZIhvcNAQkEMRYEFNMeNGsC2ZgMKRP+NrTe5R8ar8uJMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQA4uQwKsxd/hT6CbadAG1OAMMw35/i6rqQgCL1+9LMDJKDYfLf2kXZZ+DrS sky3nUL7ldJfOpSYIcBusfsZdb6yk2/p/QbNh4hH5AY20HJ5N2MgpwvXyny/1RRWteinWPyj0/ZQ q1IpItR045nW3TPWbz6ilpySGupdAmt/V0YxS9CuqVnrxQPEidsI4vEcE3mSKpJjjc2i8LXsCr15 RRX46JDuWxQAehJTeiYIfnkDUEcSKoz6xC6ic5vAGiAalc3nhpQCejNejidLOq4zCjRc3ujnJ6dR sO2Oegjrtl5DocWM+HT+wqteMQmpN3FmLY23ZMM1JOT0zYqCuZuTaIHfAAAAAAAA --Apple-Mail-71--627602011-- --Apple-Mail-72--627602004 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPhbHbAAoJEJq6Ou0cgrSPMIgH/1mwUkL+/44C5Ah0T0NbNTwP VrBILYYznJQVfmeLlE1H4J6taILtCdzg6ad1nzmwDKRJMxCyyNsZyEodWNvZr6JM r66/yoCivsxdKLMidYV7QUfxv4P/0ns0GrAcU/KdtgLD1qhGGp1m0tDj9q6XiCDr Xjg47adGRT92yhlZ0SUVqpgANAZnhBA/Seird9uVanxEwNAGDgs4yNkBfAWtGKj9 tURIUK6194byB1OzSDyxzY+NxFRc3rVZVbpo2K27Q5bqO9LIHTdiydXF/YT9dAMs jg2A9IRDXijfprJyethiyFuK8VOQInnj+jz1xTuvcyHIJKWdgl8J9lyvBctCJ14= =7kIB -----END PGP SIGNATURE----- --Apple-Mail-72--627602004-- From ve7jtb@ve7jtb.com Wed Apr 11 09:43:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB611E80A3 for ; Wed, 11 Apr 2012 09:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbqXUjsueP9O for ; Wed, 11 Apr 2012 09:43:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5558211E8089 for ; Wed, 11 Apr 2012 09:43:34 -0700 (PDT) Received: by ggmi1 with SMTP id i1so652863ggm.31 for ; Wed, 11 Apr 2012 09:43:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Gx6ylFYjUhj1zqvMImWGQqwoP9vxYHQw/8hFbORvz9Q=; b=oCH5VIbVHUJlGPTt6i6Nx38yBq2pRrrp6YvfdRtuw1gA2pJFTSGqslRT+4eiFbhCHD kw5qhGvndX2qNcGjlCbYPzKBRnsUoGRqiNmu1n/UnCuWBBQo/MbA+d3PFTucGeDRDwlU oBlqiZ9VX8bgoR+FlzQkPshYoAg8RP552OD80hbMxECY+IIKSwFMOvSJl3Hz6JOvNT08 tI9E4RxpvbMEHjhPHz9aedg2mDeijhkeXieKhXUTagxy20wtV8R4cdI90kjB5HFavotm NunItSLqUfip3rUS27qB/7Uu4rM21SrgCT7TELEvPAIHZg5pV6hj9jNeLs05XrgNJIiY L9xA== Received: by 10.236.154.2 with SMTP id g2mr13523986yhk.103.1334162613853; Wed, 11 Apr 2012 09:43:33 -0700 (PDT) Received: from [172.20.10.4] ([201.220.233.202]) by mx.google.com with ESMTPS id v26sm12217775yhk.1.2012.04.11.09.43.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 09:43:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_55A2CD78-FC53-48D5-9200-5E7186571956"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <032E5880-9B76-4693-A337-7C0F50CEBAD0@cisco.com> Date: Wed, 11 Apr 2012 13:43:53 -0300 Message-Id: <813B5464-08BC-4C3A-B4BD-A42D821B133D@ve7jtb.com> References: <49C79A1D-B97E-428B-BAD3-52F5868550EA@ve7jtb.com> <9A484F01-FB44-4E15-82BC-6C9525BB2214@cisco.com> <62BA4C02-ACE8-4B00-8A64-FB0649D39582@ve7jtb.com> <05f801cd1340$df3b42d0$9db1c870$@augustcellars.com> <74E726C7-2B52-4A8D-BAD2-501C54A4DFA6@ve7jtb.com> <061601cd1345$fd1d9d20$f758d760$@augustcellars.com> <8D4D2A64-53FE-4DD3-BF9D-3347FE116E18@ve7jtb.com> <01c001cd17fd$a67606d0$f3621470$@augustcellars.com> <032E5880-9B76-4693-A337-7C0F50CEBAD0@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmXz13XgMEOuC+zEg0OLD9uh5ngXtdAHb/Y0msMkFTOInrpc/BVs5u8j+goiWwiRwlVfRyt Cc: Jim Schaad , 'Brian Campbell' , jose@ietf.org Subject: Re: [jose] Understanding the motivation for Key Derivation? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:43:35 -0000 --Apple-Mail=_55A2CD78-FC53-48D5-9200-5E7186571956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have the mandatory HMAC for non AEAD now. =20 While it is possible to do it as an algorithm it requires munging the = HMAC and the CMK together in some way. There is no reason not to improve on the current RFC for AES128+SHA1 as = that is quite specific.=20 I think it remains to be seen if that is preferable to allowing the = integrity and symmetric encryption to be defined separately at the JOSE = layer. John B. On 2012-04-11, at 1:31 PM, Matt Miller wrote: > I was planning to start writing up a composite CBC/HMAC algorithm, = based partly on the work done by David McGrew. Is there still interest = in this? >=20 >=20 > On Apr 11, 2012, at 10:10, Jim Schaad wrote: >=20 >> >>=20 >> John,=20 >>=20 >> I would be nice if you did this. Personally I would like to see the = text >> move back to the -00 version as the base to start from. I would be = nice if >> the description was strictly in terms of how AEAD algorithms are = processed. >> For the S/MIME work, we would still use the term CEK for the key fed = into an >> AEAD algorithm even if the algorithm later produced two different = keys for >> use in the encryption and authentication processing. The details of = that >> would be purely internal to the algorithm description. >>=20 >> As a part of this I think it would be more reasonable to move the = details of >> how to do the CBC/HMAC algorithm to the algorithms document rather = than >> putting in this document so that this document is simpler and = clearer. >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Thursday, April 05, 2012 9:11 AM >>> To: Jim Schaad >>> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >>> Subject: Re: [jose] Understanding the motivation for Key Derivation? >>>=20 >>> Then we should look at including the header as the additional data = for >> GCM. >>>=20 >>> I will have a look at it, and make a proposal for some text, unless >> someone >>> else is volunteering? >>>=20 >>> John B. >>>=20 >>> On 2012-04-05, at 1:05 PM, Jim Schaad wrote: >>>=20 >>>> Ok - I see you problem. >>>>=20 >>>> Yes, in JWE the headers are not encrypted. >>>> GCM provides integrity over both the encrypted content and the >> additional >>>> data fields (hence the difference between AD (authenticated Data) = and >>>> AEAD(Authenticated Data with Additional Data). >>>>=20 >>>> All AEAD algorithms provide for the ability to have data which is = not >> part >>>> of the encrypted data be included in the authenticated data. In = fact >> AEAD >>>> algorithms can be used as MAC algorithms in many cases by simply = having >>> an >>>> empty string for the encrypted data (it depends in part on the = internal >>>> construction of the encrypted data stream). I believe we verified = that >> this >>>> was a true statement for GCM at the last IETF meeting (in a hallway >>>> conversation). >>>>=20 >>>> Jim >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>>> Sent: Thursday, April 05, 2012 8:45 AM >>>>> To: Jim Schaad >>>>> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org >>>>> Subject: Re: [jose] Understanding the motivation for Key = Derivation? >>>>>=20 >>>>> In JWE the headers are not encrypted. >>>>>=20 >>>>> GCM provides integrity only over the encrypted content. >>>>>=20 >>>>> In the composite AES-CBC + HMAC the integrity is calculated over = both >>> the >>>>> Header and the encrypted content. >>>>>=20 >>>>> The advantage of not using a AEAD algorithm is that the composite = can >> be >>>>> more JOSE aware. >>>>>=20 >>>>> I can't rule out having missed something thats why we review these >>>> things:) >>>>>=20 >>>>> John B. >>>>> On 2012-04-05, at 12:28 PM, Jim Schaad wrote: >>>>>=20 >>>>>> >>>>>>=20 >>>>>> John, >>>>>>=20 >>>>>> I am at a loss, why do you believe that a new AEAD algorithm = would not >>>>>> protect the headers? >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>>> John Bradley >>>>>>> Sent: Thursday, April 05, 2012 7:28 AM >>>>>>> To: Matt Miller >>>>>>> Cc: Brian Campbell; jose@ietf.org >>>>>>> Subject: Re: [jose] Understanding the motivation for Key = Derivation? >>>>>>>=20 >>>>>>> A couple of observations. >>>>>>>=20 >>>>>>> The current proposal provides integrity over the header, a new = AEAD >>>> alg >>>>>>> doesn't do that. >>>>>>> Low level crypto is a challenge. Re-using standard underlying >>>> algorithms >>>>>> like >>>>>>> HMAC and AES-CBC allow for JS and other libs to call standard = lower >>>> level >>>>>>> crypto functions. >>>>>>>=20 >>>>>>> I am not against having another AEAD alg, but want to help = people >>>>>>> understand the current design choice. >>>>>>>=20 >>>>>>> John B. >>>>>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote: >>>>>>>=20 >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>>=20 >>>>>>>> Another way around the conditional in application-space is to = define >>>> an >>>>>>> AEAD algorithm composed of an encryption and hashing function. = This >>>>>>> seems like a reasonable place to start looking at one: < >>>>>>> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 = >. >>>>>>>>=20 >>>>>>>> On Apr 4, 2012, at 17:42, John Bradley wrote: >>>>>>>>=20 >>>>>>>>> The use of a single key across two functions is one of things = that >> is >>>>>> not >>>>>>> provably without problems. >>>>>>>>>=20 >>>>>>>>> I agree that from an implementers point of view one key is = simpler. >>>>>>>>>=20 >>>>>>>>> There is a related-key attack that using the same key would = enable. >>>>>> This >>>>>>> can be combined with differential and linear attacks on = symmetric key >>>>>>> cyphers. >>>>>>>>>=20 >>>>>>>>> Generally this can be thought of as a bad thing. >>>>>>>>>=20 >>>>>>>>> What is certain is that it increases the possible attack = surface, >>>> and >>>>>> if the is >>>>>>> a problem discovered as we have seen with AES-CBC it is going to = be >>>> hard >>>>>> to >>>>>>> change later. >>>>>>>>>=20 >>>>>>>>> We need key derivation anyway for ECDH-ES to produce a key of = the >>>>>>> correct bit length. >>>>>>>>>=20 >>>>>>>>> Doing key derivation on CMK is the theoretically proper way to = do >> it. >>>>>>>>> Making a simplification might bite us in the future. >>>>>>>>>=20 >>>>>>>>> I suppose one way to get around the conditional application >>> argument >>>>> is >>>>>>> to always use it to produce the CEK even with AEAD algorithms. >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote: >>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> I was hoping someone could help me (hopefully it's not just = me!) >>>>>>>>>> understand the reasons for the introduction of the key = derivation >>>>>>>>>> stuff* into JWE draft -01? >>>>>>>>>>=20 >>>>>>>>>> I understand that it's there to derive the two keys, CEK and = CIK, >>>>>>>>>> from the CMK and that it is to be done when a non-AEAD = algorithm >>> is >>>>>>>>>> used to encrypt the content. But what is the value of = deriving the >>>>>>>>>> two keys as apposed to using the CMK for both encryption and >>>>>> integrity? >>>>>>>>>>=20 >>>>>>>>>> Perhaps naively I assumed that using the CMK for both would = be >>>>>>>>>> sufficient. It's randomly generated and used only for the = one >> JWE. >>>>>>>>>> It's not clear to me what benefit is provided by the = additional >>>>>>>>>> complexity of the derivation function as well as its = conditional >>>>>>>>>> application (and the potential interoperability problems that = come >>>>>>>>>> with such complexity). I assume there's some security = benefit? But >>> I >>>>>>>>>> can't see what it is. >>>>>>>>>>=20 >>>>>>>>>> Any help would be appreciated. >>>>>>>>>> Thanks, >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> * >>>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >>> 01#se >>>>>>>>>> ction-7 >>>>>>>>>> which is referenced by >>>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >>> 01#se >>>>>>>>>> ction-5 and >>>>>>>>>> = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption- >>> 01#se >>>>>>>>>> ction-6 >>> _______________________________________________ >>>>>>>>>> jose mailing list >>>>>>>>>> jose@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> - - m&m >>>>>>>>=20 >>>>>>>> Matt Miller - >>>>>>>> Cisco Systems, Inc. >>>>>>>>=20 >>>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>>>>> Comment: GPGTools - http://gpgtools.org >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq >>>>>>> zQj >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR >>>>>>> 8kx >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL >>>>>>> y >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb >>>>>>> + >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb >>>>>>> Y >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG >>>>>>> z/I=3D >>>>>>>> =3D174E >>>>>>>> -----END PGP SIGNATURE----- >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 --Apple-Mail=_55A2CD78-FC53-48D5-9200-5E7186571956 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx MTE2NDM1M1owIwYJKoZIhvcNAQkEMRYEFAKpCoxAzkGVHFU+s5gAv9hzSnnuMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFJRqyeC1d7IEo6wjlvXvPZfNdHuLXzIPL1gCkBgk+PGqwZw1yN9QBTozgsZQ7f85N5hyuetZ8Dy +MS09VOh442G7m5WVv99aynhoAoIgWC7SCHYDo4USbRy4Pi/DA5G/l7lSdEx8u3scaBgQ+wEGNcF b/UWAiYV7L9xVIQdqe3hdgZHOQPUW22RBTgf7qakPjskSZdnC3VNPSLB71puqejP6JsnhrEtLRgz MS4dwPlSeABG+ZZBhV2hsMM8zt0Ru+BS2ENIgMeCc0lEkOjQ8bFSJjJkNCWcoSAidtpDncuD8FeL F6dKkaRZZjnsFBVLgoPxSXHsklnB1WIPvq629ZwAAAAAAAA= --Apple-Mail=_55A2CD78-FC53-48D5-9200-5E7186571956-- From ietf@augustcellars.com Wed Apr 11 13:08:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6911E80D0 for ; Wed, 11 Apr 2012 13:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24Lio09QInwO for ; Wed, 11 Apr 2012 13:07:59 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 755D111E80CC for ; Wed, 11 Apr 2012 13:07:59 -0700 (PDT) Received: from Tobias (unknown [50.34.251.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 351E438EA5; Wed, 11 Apr 2012 13:07:59 -0700 (PDT) From: "Jim Schaad" To: "Mike Jones" Date: Wed, 11 Apr 2012 13:06:52 -0700 Message-ID: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0YFumdEsd+H7NuSBmmwJ3ugtJ7Yw== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 20:08:02 -0000 I am starting to come out of the normal sickness period following an IETF meeting. So I am looking at the smallest document first. I am going to skip section 4.2.1 & 4.2.2 as they appear to be heading for a different document. Abstract: 1. Are JWK items restricted to just asymmetric algorithms? Can/Should one be able to transport symmetric keys via web key structure? 2. There was a request at one point to allow for encoding of private keys. What if any response does the working group have to this request? Introduction: 3. The introduction text appears to be incorrect. While the jku field refers to a JWK Web Key, the epk field holds a JWK Key Object. 4. I find the terminology to be very difficult to understand. A JSON Web Key (JWK) is a set of one or more keys while a JWK Key Object is a single key. The fact that these are all dealing with the same string JWK is part of the confusion as is the fact that the JWK is singular in name, but plural in content. 5. I would like to see the "non-goals" of this document to be pulled out into a new paragraph and expanded into a number of different non-goals of this document. This includes certified keys - that is any form of binding of keys to names that has been attested to. Terminology: 6. I am not sure that the definition of the JWK Container Object is useful. Is this really a separate object from the JSON Web Key object? Overview: 7. This section starts "It is sometimes useful.." There are a lot of things that are sometimes useful but we don't standardize a lot of them. I think that this text would be better started as: "A large number of operations, such as digital signature validation, require the public key in order to be successful. In many cases the public key is provided in an X.509 certificate, however there are cases where it is more convenient to provide the public key in a different format. Examples of this include ..... This document defines ..." Actually I think that this text might be even better placed in the introduction. And section 3.1 be promoted to become section 3. And the current section 3 be omitted. JWK Format: 8. Does a JWK consist of a JWK Container object - or is it identical to a JWK Container object? JWK Container Object Format: 9. Why is the member name jwk - it would seem that this should be the name of the member that holds the entire object not that of the array of key objects. I would think that "keys" would be a better name for this member. 10. The last sentence in this section again conflates a container object and a JWK. 11. Should the text that is in the signature and encryption dealing with adding fields (urls vs simple names) be included in this section as well? 12. Should there be an IANA registry for the member names of a container object. JWK Key Object Format: 13. Should there be an IANA registry for the contents of the alg string? 14. Should there be an IANA registry for the members of a Key Object? 15. What is the function of the value of use? Is there supposed to be a requirement on items that use a key that the "use" value be of specific values? Do these values need to be registered? 16. I don't understand the sentence "The "kid" value MAY correspond to a JWS "kid" value." - First this seems to make no sense to have a protocol requirement statement on it. Secondly if the value does not correspond to a JWS kid value, what in the world would it possibly correspond to, how could would it be used for choosing among keys if it did not have such a correspondence? 17. Should the "kid" be present if there are multiple keys of the same usage and algorithm? 18. Should the text dealing with adding members be present (copied from JWS)? Is it just the key and not the entire key set that is to be ignored? Open Issues: 19. I think that a section on adding key families would be reasonable. Security Considerations: 20. The key is no more trustworthy that the method that is came to you. 21. This structure is not intended to replace X.509 certificates. Jim From bcampbell@pingidentity.com Thu Apr 12 11:34:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36C221F85C4 for ; Thu, 12 Apr 2012 11:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0aby05B7pv7 for ; Thu, 12 Apr 2012 11:34:00 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id ED7FE21F85B6 for ; Thu, 12 Apr 2012 11:33:59 -0700 (PDT) Received: from mail-gy0-f175.google.com ([209.85.160.175]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKT4cgFyT/7gmL9XoKcx509ys79MDUKSWR@postini.com; Thu, 12 Apr 2012 11:34:00 PDT Received: by ghbz2 with SMTP id z2so1371449ghb.20 for ; Thu, 12 Apr 2012 11:33:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=R6PUxyWRPI+XQxDF6kKRFHv5LFr2NJIb2M2gQoByJTE=; b=csOYX4q5rR82ZjPmbIRJuOQMRf5WwadgopqY2siEIvaZYy8BUrtEFstyBGu2krkgue PLN1XZDs64ssryIE3I9tMMn3lhUB/d5AEg+PPcOC6UQ2ONToc9yRnE2IwbHdDh5JDwqU 8/zWLDQ+silo8nVkpDeh14ekaMd2g/mZhTyaQeP5yHPy4mgfJHeRAKQdwkCab9HIr3QE quliXlWLkxra9Crepy0ZMhg96Q5IyGvyXasPhZPTok2k9Rd3fYwYNckYeIKu7dM4EuJ+ DFNkEW/2pexMBw0b1VkPgm+QN/nTpFtvTxq5cGIWexrr2OMCdKvJcifNALGJTwt3p6KK nAyw== Received: by 10.50.45.167 with SMTP id o7mr4110935igm.22.1334255638688; Thu, 12 Apr 2012 11:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.175.73 with HTTP; Thu, 12 Apr 2012 11:33:28 -0700 (PDT) From: Brian Campbell Date: Thu, 12 Apr 2012 12:33:28 -0600 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnNZt+0Kvn1YE4JAXSZpHaknoMS/GWWLEsSoj9PYSr5EPaqaK94uH+Htcl3V+IP8YoWgpoq Subject: [jose] WTKDF? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:34:01 -0000 Hi all, I'm trying to do an implementation of the Concatenation Key Derivation Function from =A75.8.1 of NIST SP800-56A for JWE but I'm honestly having some trouble making sense out of some of the language in the NIST document. On page 47 of NIST SP800-56A it says, "The subfields SuppPrivInfo and SuppPubInfo (when allowed by the application) shall be formed by the concatenation of an application-specific, fixed-length sequence of substrings of additional information that may be used in key derivation upon mutual agreement of parties U and V. Each substring representing a separate unit of information shall be of the form Datalen || Data, where Data is a variable-length string of zero or more (eight-bit) bytes and Datalen is a fixed-length, big-endian counter that indicates the length (in bytes) of Data." =A77 of JWE-01* says "the SuppPubInfo parameter is the Label [Integrity or Encryption], and the remaining OtherInfo parameters are the empty bit string." So the label is one such sub-string and is concatenated with the key and the counter and hashed as part of the KDF algorithm. I'm a bit confused about (among other things) what the byte sequence should be for the label. Using the CIK as an example, the ASCII byte representation of "Integrity" is [73, 110, 116, 101, 103, 114, 105, 116, 121] but does the text from NIST page 47 say that the label bytes should be the following sequence where the Datalen, as a four byte fixed-length big-endian counter, is prepended to the byte sequence above? [0, 0, 0, 9, 73, 110, 116, 101, 103, 114, 105, 116, 121] Or is it something else? Can anyone set me straight here? Anyone else working on or have an implementation of this? Or know about existing implementations that could be used as a reference to test results? Thanks, Brian * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section= -7 On a side note, it looks like =A77 got a little mangled in the HTML version= : http://tools.ietf.org/id/draft-ietf-jose-json-web-encryption-01.html#rfc.se= ction.7 From sakimura@gmail.com Thu Apr 12 12:44:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E857F21F86E1 for ; Thu, 12 Apr 2012 12:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFkgh8RldrdM for ; Thu, 12 Apr 2012 12:44:33 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C80FA21F86D9 for ; Thu, 12 Apr 2012 12:44:32 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2318205bku.31 for ; Thu, 12 Apr 2012 12:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SS3aU+pHszdJT/4lJeREtnB+8JXwCvgZ5tAyJlnqO+E=; b=Ys8z7Nzmdw4UN/1ALygEDhtWZ2391aTnqxCQQ1UtNldoaGp86fZjodRU+DQEDndSh2 eOIxrMtHikONRo/Co6AKuT1kVepj3bYHWt8EWU1Fr6f6jno0b5tC00nJaf85xdwbV70U wVqFkn8vBADILN6msEHW45S9wdw9kbVUit7jlS7Fj6oaH3od7oXp9Is+4P4pIBlvMPHK zDe9lu7bdFxgXpWfr5OeQMWBP8AmPKIcdxB5ZwvO6U78R0oKey2LnHO8pDlqs/vv5QPW /q1rvDCD1aotVcjzDyekCncGynxeWcYNhGjQXOjx10CSJj08AnFzqPc6qhLFK/c1ypUn 7AmQ== MIME-Version: 1.0 Received: by 10.205.132.141 with SMTP id hu13mr1149260bkc.87.1334259871772; Thu, 12 Apr 2012 12:44:31 -0700 (PDT) Received: by 10.204.152.215 with HTTP; Thu, 12 Apr 2012 12:44:31 -0700 (PDT) In-Reply-To: <0A1F4C01-6F1C-409A-ABCC-A0F09729B45B@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436645F6F6@TK5EX14MBXC283.redmond.corp.microsoft.com> <0A1F4C01-6F1C-409A-ABCC-A0F09729B45B@ve7jtb.com> Date: Fri, 13 Apr 2012 04:44:31 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Open Issue for WG Discussion: Disposition of JSON Serialization Functionality X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:44:34 -0000 On Tue, Apr 10, 2012 at 1:41 AM, John Bradley wrote: > Inline > On 2012-04-09, at 1:25 PM, Mike Jones wrote: > > You=92ll recall that I created JSON Serialization drafts in response to W= G > input that use the same cryptographic operations as JWS and JWE, but that > serialize the results into a JSON objects, rather than base64url encoded > values separated by periods.=A0 These representations also enable multipl= e > signatures/HMACs to be used and content to be encrypted to multiple > recipients.=A0 The current versions of these drafts are: > =B7=A0=A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-jones-json-we= b-signature-json-serialization-01 > =B7=A0=A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-jones-json-we= b-encryption-json-serialization-01 > > It was decided in Paris that the disposition of this functionality should= be > discussed by the WG on the list.=A0 I think the questions we need to deci= de > are: > > 1.=A0 Is the working group interested in pursuing this functionality? > (Evidence to date is that the answer to this question is =93yes=94.) > > > Yes Yes. > > 2.=A0 If the answer to (1) is =93yes=94, would the working group like to = have this > functionality be in working group documents at this time (rather than bei= ng > described in individual submissions, as at present)? > > > Yes Yes. > > > 3.=A0 If the answer to (2) is =93yes=94, should working group -00 version= s of the > JSON Serialization documents be created or should this functionality be > folded into the existing JWS and JWE specs? > > > > Create WG documents separate from the =A0JWS and JWE and consider merging= them > later after some more maturity. +1 > > John B. > > Arguments for keeping this functionality separate for now are: > =A0 - Different level of maturity:=A0 I=92m aware of over a dozen impleme= ntations > of JWS a few of JWE, but I know of no implementations of JWS-JS or JWE-JS= . > There=92s an argument that we should keep this new functionality separate > until we have =93rough consensus and running code=94. > =A0 - Document simplicity for the Compact Serialization use case.=A0 Not > describing a second serialization in the JWS and JWE documents makes the > documents somewhat easier to read if all the implementer needs is the > Compact Serialization. > > Arguments for merging it in now are: > =A0 - Fewer documents needed to provide comprehensive treatment of the > material. > > Opinions from the Working Group? > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From jlaurens@cisco.com Wed Apr 18 07:07:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86F421F85AF for ; Wed, 18 Apr 2012 07:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSOb3Tlc1XRJ for ; Wed, 18 Apr 2012 07:06:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 371C421F85A1 for ; Wed, 18 Apr 2012 07:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jlaurens@cisco.com; l=21417; q=dns/txt; s=iport; t=1334758017; x=1335967617; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KtBbijQR8yb/XolJdVa48/0Q2lZvLl5l8GzMnJ3qqNw=; b=b0BZgoTYBDMYMkyeY1D5G4SiYkZTTy1dG4bOkm3bonfCid7wfvX5bnXd iABZGpORWqaKBnrXxT/sUQC2zKf/DjNMS1gVEIlrki0gyW/iw7l6nlCuI U74PbuDvtFvou0OarEQjJ4ajhh5xhVlSTGJWFqU+AxyQYNbOBN8J2oPse U=; X-Files: smime.p7s : 4391 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAAnKjk+tJV2c/2dsb2JhbABEgkalbgGJCYEHggkBAQEDAQEBAQ8BWwsFCwIBCA44AiULJQEBBA4FDhSHaAULmkSgKJAFYwSOboEjhV6BEY1AgWmCZw X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="p7s'?scan'208,217";a="75724814" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 18 Apr 2012 14:06:56 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3IE6uaZ031213; Wed, 18 Apr 2012 14:06:56 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Wed, 18 Apr 2012 07:06:56 -0700 From: "Jeremy Laurenson (jlaurens)" To: Mike Jones Thread-Topic: [jose] Open Issue for WG Discussion: Disposition of JSON Serialization Functionality Thread-Index: Ac0WbWXHYX/Vund+T9CNkkvP3fJCBQHOclKA Date: Wed, 18 Apr 2012 14:06:56 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436645F6F6@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436645F6F6@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18846.006 x-tm-as-result: No--34.841100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_B271B52B-BF68-4073-8CF8-DE45B96BE5B6"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Open Issue for WG Discussion: Disposition of JSON Serialization Functionality X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:07:01 -0000 --Apple-Mail=_B271B52B-BF68-4073-8CF8-DE45B96BE5B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_635A1F9A-6EBA-418A-AB56-950710E536F9" --Apple-Mail=_635A1F9A-6EBA-418A-AB56-950710E536F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 9, 2012, at 12:25 PM, Mike Jones wrote: > You=92ll recall that I created JSON Serialization drafts in response = to WG input that use the same cryptographic operations as JWS and JWE, = but that serialize the results into a JSON objects, rather than = base64url encoded values separated by periods. These representations = also enable multiple signatures/HMACs to be used and content to be = encrypted to multiple recipients. The current versions of these drafts = are: > =B7 = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 > =B7 = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 > =20 > It was decided in Paris that the disposition of this functionality = should be discussed by the WG on the list. I think the questions we = need to decide are: > =20 > 1. Is the working group interested in pursuing this functionality? = (Evidence to date is that the answer to this question is =93yes=94.) > =20 Yes > 2. If the answer to (1) is =93yes=94, would the working group like to = have this functionality be in working group documents at this time = (rather than being described in individual submissions, as at present)? Yes > =20 > 3. If the answer to (2) is =93yes=94, should working group -00 = versions of the JSON Serialization documents be created or should this = functionality be folded into the existing JWS and JWE specs? > =20 > Arguments for keeping this functionality separate for now are: > - Different level of maturity: I=92m aware of over a dozen = implementations of JWS a few of JWE, but I know of no implementations of = JWS-JS or JWE-JS. There=92s an argument that we should keep this new = functionality separate until we have =93rough consensus and running = code=94. > - Document simplicity for the Compact Serialization use case. Not = describing a second serialization in the JWS and JWE documents makes the = documents somewhat easier to read if all the implementer needs is the = Compact Serialization. > =20 > Arguments for merging it in now are: > - Fewer documents needed to provide comprehensive treatment of the = material. Keep them separate - Id like to see fewer documents, but no need for = mass extermination ;-) > =20 > Opinions from the Working Group? > =20 > Thanks, > -- Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_635A1F9A-6EBA-418A-AB56-950710E536F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 9, 2012, at 12:25 PM, Mike = Jones wrote:

You=92ll recall that I created = JSON Serialization drafts in response to WG input that use the same = cryptographic operations as JWS and JWE, but that serialize the results = into a JSON objects, rather than base64url encoded values separated by = periods.  These representations also enable multiple = signatures/HMACs to be used and content to be encrypted to multiple = recipients.  The current versions of these drafts = are:
=B7 =B7  
Yes

 
3.  If the answer to (2) is =93yes=94, should working = group -00 versions of the JSON Serialization documents be created or = should this functionality be folded into the existing JWS and JWE = specs?
 
Arguments for = keeping this functionality separate for now are:
  - Different level of maturity:  I=92m aware of = over a dozen implementations of JWS a few of JWE, but I know of no = implementations of JWS-JS or JWE-JS.  There=92s an argument that we = should keep this new functionality separate until we have =93rough = consensus and running code=94.
  - Document = simplicity for the Compact Serialization use case.  Not describing = a second serialization in the JWS and JWE documents makes the documents = somewhat easier to read if all the implementer needs is the Compact = Serialization.
 
Arguments for merging it in now are:
  - Fewer documents needed to provide comprehensive = treatment of the material.
 
Opinions from the Working Group?
 
X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C94121F8775 for ; Wed, 25 Apr 2012 19:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGul9GIefpVF for ; Wed, 25 Apr 2012 19:39:28 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3130921F86FF for ; Wed, 25 Apr 2012 19:39:28 -0700 (PDT) Received: from mail89-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 02:39:26 +0000 Received: from mail89-am1 (localhost [127.0.0.1]) by mail89-am1-R.bigfish.com (Postfix) with ESMTP id 608D6C02CF; Thu, 26 Apr 2012 02:39:26 +0000 (UTC) X-SpamScore: -21 X-BigFish: VS-21(zz9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail89-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1 (MessageSwitch) id 1335407964154751_18954; Thu, 26 Apr 2012 02:39:24 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.235]) by mail89-am1.bigfish.com (Postfix) with ESMTP id 20FB2340236; Thu, 26 Apr 2012 02:39:24 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 02:39:23 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0298.005; Thu, 26 Apr 2012 02:39:21 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) Thread-Index: AQHNFMprBXeoX0J2x0ei69tE1/e6NZasgU3Q Date: Thu, 26 Apr 2012 02:39:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366499C9A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436645DE9A@TK5EX14MBXC283.redmond.corp.microsoft.com> <001f01cd14ca$49a853d0$dcf8fb70$@augustcellars.com> In-Reply-To: <001f01cd14ca$49a853d0$dcf8fb70$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366499C9ATK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 02:39:30 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366499C9ATK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having gone over this in detail while working on producing the next version= s of the docs, I now believe that the readability will be fine. I'm moving= the JWK algorithm-specific definitions to the JWA doc, while leaving suffi= cient examples in the JWK spec to help implementer's "get it" at first glan= ce. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, April 07, 2012 7:26 AM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Open Issue for WG Discussion: Whether to move JWK algor= ithm family definitions to JWA spec (editorial) Please explain why you believe the readability of the document would be red= uced. There would still be the ability to have examples that referenced th= e algorithm draft. Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Friday, April 06, 2012 2:05 PM To: jose@ietf.org Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm= family definitions to JWA spec (editorial) The JSON Web Key (JWK) spec currently contains the algorithm family definit= ions and parameter specifications for the RSA and Elliptic Curve algorithm = families. An editorial open issue is whether to leave these in the JWK spe= c or move them to the JWA spec. The argument for leaving them in the JWK spec is that removing the definiti= ons of "EC" and "RSA" and the family-specific parameter definitions ("crv",= "x", "y", "mod", "exp") would leave very little normative text in the JWK = spec itself. It seemed like doing this would reduce the readability of the= JWK spec, and so was not done in -01. The argument for moving them is that all the algorithm-specific definitions= would then be in the JWA spec and good examples of RSA and EC keys could r= emain in the JWK spec. References to the pertinent specs are: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-01 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01 Feedback? -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366499C9ATK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having gone over this = in detail while working on producing the next versions of the docs, I now b= elieve that the readability will be fine.  I’m moving the JWK al= gorithm-specific definitions to the JWA doc, while leaving sufficient examples in the JWK spec to help implementer’s &#= 8220;get it” at first glance.

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Saturday, April 07, 2012 7:26 AM
To: Mike Jones; jose@ietf.org
Subject: RE: [jose] Open Issue for WG Discussion: Whether to move JW= K algorithm family definitions to JWA spec (editorial)

 

Please explain why you= believe the readability of the document would be reduced.  There woul= d still be the ability to have examples that referenced the algorithm draft= .

 

Jim<= /p>

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, April 06, 2012 2:05 PM
To: jose@ietf.org
Subject: [jose] Open Issue for WG Discussion: Whether to move JWK al= gorithm family definitions to JWA spec (editorial)

 

The JSON Web Key (JWK) spec currently contains the a= lgorithm family definitions and parameter specifications for the RSA and El= liptic Curve algorithm families.  An editorial open issue is whether t= o leave these in the JWK spec or move them to the JWA spec.

 

The argument for leaving them in the JWK spec is tha= t removing the definitions of “EC” and “RSA” and th= e family-specific parameter definitions ("crv", "x", &q= uot;y", "mod", "exp") would leave very little norm= ative text in the JWK spec itself.  It seemed like doing this would reduce the readability of the JWK sp= ec, and so was not done in -01.

 

The argument for moving them is that all the algorit= hm-specific definitions would then be in the JWA spec and good examples of = RSA and EC keys could remain in the JWK spec.

 

References to the pertinent specs are:

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

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-algorithms-01

 

Feedback?

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366499C9ATK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Wed Apr 25 21:22:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E373321F8898 for ; Wed, 25 Apr 2012 21:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.913 X-Spam-Level: X-Spam-Status: No, score=-3.913 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9WyHwiW5OJK for ; Wed, 25 Apr 2012 21:22:40 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 24FD721F8897 for ; Wed, 25 Apr 2012 21:22:39 -0700 (PDT) Received: from mail86-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 04:22:37 +0000 Received: from mail86-am1 (localhost [127.0.0.1]) by mail86-am1-R.bigfish.com (Postfix) with ESMTP id 91659400052; Thu, 26 Apr 2012 04:22:37 +0000 (UTC) X-SpamScore: -33 X-BigFish: VS-33(zz9371Ic85fh542M1418I111aI1447Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail86-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail86-am1 (localhost.localdomain [127.0.0.1]) by mail86-am1 (MessageSwitch) id 1335414155142878_7138; Thu, 26 Apr 2012 04:22:35 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.243]) by mail86-am1.bigfish.com (Postfix) with ESMTP id 1E38A220094; Thu, 26 Apr 2012 04:22:35 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 04:22:35 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Thu, 26 Apr 2012 04:21:58 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-key-01 Thread-Index: Ac0YFumdEsd+H7NuSBmmwJ3ugtJ7YwLQf9Tw Date: Thu, 26 Apr 2012 04:21:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com> In-Reply-To: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366499F0BTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 04:22:45 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366499F0BTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the detailed comments, as always, Jim. Replies inline... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Wednesday, April 11, 2012 1:07 PM To: Mike Jones Cc: jose@ietf.org Subject: [jose] Comments on draft-ietf-jose-json-web-key-01 I am starting to come out of the normal sickness period following an IETF m= eeting. I got sick after Paris too. Hope you're feeling better now! So I am looking at the smallest document first. This is a good one to start with, as it has probably been reviewed less tha= n the others. (Maybe read JWA next, by the same logic.) I am going to skip section 4.2.1 & 4.2.2 as they appear to be heading for a= different document. Agreed Abstract: 1. Are JWK items restricted to just asymmetric algorithms? Can/Should one= be able to transport symmetric keys via web key structure? Yes. During our scoping discussions for the work, I believe there was cons= ensus to restrict the JSON key representation spec to representing public k= eys only. This is reflected in our charter as: 3) A Standards Track document specifying how to encode public keys as JSON-= structured objects. 2. There was a request at one point to allow for encoding of private keys. What if any response does the working group have to this request? I believe this would require rechartering. Introduction: 3. The introduction text appears to be incorrect. While the jku field ref= ers to a JWK Web Key, the epk field holds a JWK Key Object. You're right - I will tighten this description. 4. I find the terminology to be very difficult to understand. A JSON Web = Key (JWK) is a set of one or more keys while a JWK Key Object is a single = key. The fact that these are all dealing with the same string JWK is part = of the confusion as is the fact that the JWK is singular in name, but plura= l in content. Yes, a JWK represents a set of keys and a JWK Key Object represents a singl= e key. I'll think about how to make the terminology more intuitive. 5. I would like to see the "non-goals" of this document to be pulled out i= nto a new paragraph and expanded into a number of different non-goals of th= is document. This includes certified keys - that is any form of binding of= keys to names that has been attested to. Good idea. The set of non-goals should probably include representing priva= te keys, representing symmetric keys, representing certified keys, and repl= acing X.509 certificates. Terminology: 6. I am not sure that the definition of the JWK Container Object is useful= . Is this really a separate object from the JSON Web Key object? Given there's a 1:1 mapping, it's probably not. I'll work on simplifying/c= oalescing. Overview: 7. This section starts "It is sometimes useful.." There are a lot of thin= gs that are sometimes useful but we don't standardize a lot of them. I thi= nk that this text would be better started as: "A large number of operation= s, such as digital signature validation, require the public key in order to= be successful. In many cases the public key is provided in an X.509 certificate, however there are cases where it is more convenient to p= rovide the public key in a different format. Examples of this include ....= . This document defines ..." Actually I think that this text might be eve= n better placed in the introduction. And section 3.1 be promoted to become = section 3. And the current section 3 be omitted. Agreed. I'd independently reached the same conclusion. JWK Format: 8. Does a JWK consist of a JWK Container object - or is it identical to a = JWK Container object? (See 6) JWK Container Object Format: 9. Why is the member name jwk - it would seem that this should be the name= of the member that holds the entire object not that of the array of key ob= jects. I would think that "keys" would be a better name for this member. I agree. WORKING GROUP: How do you feel about this possible name change? 10. The last sentence in this section again conflates a container object a= nd a JWK. (See 6) 11. Should the text that is in the signature and encryption dealing with a= dding fields (urls vs simple names) be included in this section as well? Are you thinking of the text about the three classes of names: reserved, p= rivate, and public? With the possibility of a registry? What do people in= the working group think? I think the chances of this object being extende= d are small, especially since we only define one member. But then, it's in= credibly hard to predict how a standard will be used, if successful. I'd b= e more prone to think that extension made sense if the spec defined more th= an one member. 12. Should there be an IANA registry for the member names of a container o= bject. Per 11, I don't think so. I think this case is better handled by the stand= ard JSON "you can add fields if you understand them" logic. JWK Key Object Format: 13. Should there be an IANA registry for the contents of the alg string? In the JWA spec, yes. 14. Should there be an IANA registry for the members of a Key Object? In the JWA spec, yes. 15. What is the function of the value of use? Is there supposed to be a r= equirement on items that use a key that the "use" value be of specific values? Do these values need to be registered? Part of the function of this field is to match keys with the correct usages= . For instance, I believe that it's a potential security problem to use th= e same Elliptic Curve key for both signing and encryption. One might have = two keys, one with use "sig" and one with use "enc" to specify which key (o= r keys) are to be used for which purposes. Unless the experts in this group want to bring to our attention public key = usages other than signing and encryption that may also need to be defined i= n the future, I think what we have is sufficient. If this is a more open-e= nded set (looking at the X.509 key usage description may tell us), we may w= ant to consider a more robust treatment. 16. I don't understand the sentence "The "kid" value MAY correspond to a J= WS "kid" value." - First this seems to make no sense to have a protocol req= uirement statement on it. Secondly if the value does not correspond to a J= WS kid value, what in the world would it possibly correspond to, how could = would it be used for choosing among keys if it did not have such a correspo= ndence? I can tighten this to say that when used with JWS and JWE, the JWS and JWE = "kid" are intended to be used to match JWK "kid" values for key selection. = (When used in contexts other than with JWS and JWE, the "kid" values could= be matched against something else entirely.) 17. Should the "kid" be present if there are multiple keys of the same usa= ge and algorithm? I think this would be up to the particular usage profiles. We could maybe = so far as to make this RECOMMENDED for some use cases but I wouldn't go for= REQUIRED. For instance, in some cases, including key roll-over, it may be= perfectly fine to just try all the keys without having identifiers for any= of them. 18. Should the text dealing with adding members be present (copied from JW= S)? Is it just the key and not the entire key set that is to be ignored? Again, are you thinking the reserved/private/public treatment? With a regi= stry? Or maybe just a registry? I didn't find "ignore" in the draft, so I= 'm not sure what the second sentence in your remarks is referring to. Open Issues: 19. I think that a section on adding key families would be reasonable. Yes, probably in JWA. Security Considerations: 20. The key is no more trustworthy that the method that is came to you. Will add. 21. This structure is not intended to replace X.509 certificates. I'm thinking this belongs in the non-goals section. Jim Thanks again, -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366499F0BTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the detaile= d comments, as always, Jim.  Replies inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad
Sent: Wednesday, April 11, 2012 1:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: [jose] Comments on draft-ietf-jose-json-web-key-01

 

<no hat>

 

I am starting to come = out of the normal sickness period following an IETF meeting.

 

I got sick after Paris= too.  Hope you’re feeling better now!

 

So I am looking at the= smallest document first.

 

This is a good one to = start with, as it has probably been reviewed less than the others.  (M= aybe read JWA next, by the same logic.)

 

I am going to skip sec= tion 4.2.1 & 4.2.2 as they appear to be heading for a different documen= t.

 

Agreed

 

Abstract:

 

1.  Are JWK items= restricted to just asymmetric algorithms?  Can/Should one be able to = transport symmetric keys via  web key structure?

 

Yes.  During our = scoping discussions for the work, I believe there was consensus to restrict= the JSON key representation spec to representing public keys only.  T= his is reflected in our charter as:

3) A Standards Track document specifying = how to encode public keys as JSON-structured objects.

 

2.  There was a r= equest at one point to allow for encoding of private keys.

What if any response d= oes the working group have to this request?

 

I believe this would r= equire rechartering.

 

Introduction:

 

3.  The introduct= ion text appears to be incorrect.  While the jku field refers to a JWK= Web Key, the epk field holds a JWK Key Object.

 

You’re right - I= will tighten this description.

 

4.  I find the te= rminology to be very difficult to understand.  A JSON Web Key (JWK)&nb= sp; is a set of one or more keys while a JWK Key Object is a single key.&nb= sp; The fact that these are all dealing with the same string JWK is part of the confusion as is the fact that the JWK is singular in na= me, but plural in content.

 

Yes, a JWK represents = a set of keys and a JWK Key Object represents a single key.  I’l= l think about how to make the terminology more intuitive.=

 

5.  I would like = to see the "non-goals" of this document to be pulled out into a n= ew paragraph and expanded into a number of different non-goals of this docu= ment.  This includes certified keys - that is any form of binding of keys to names that has been attested to. 

 

Good idea.  The s= et of non-goals should probably include representing private keys, represen= ting symmetric keys, representing certified keys, and replacing X.509 certi= ficates.

 

Terminology:

 

6.  I am not sure= that the definition of the JWK Container Object is useful.

Is this really a separ= ate object from the JSON Web Key object?

 

Given there’s a = 1:1 mapping, it’s probably not.  I’ll work on simplifying/= coalescing.

 

Overview:

 

7.  This section = starts "It is sometimes useful.."  There are a lot of things= that are sometimes useful but we don't standardize a lot of them.  I = think that this text would be better started as:  "A large number of operations, such as digital signature validation, require the public ke= y in order to be successful.  In many cases the public key is provided= in an

X.509 certificate, how= ever there are cases where it is more convenient to provide the public key = in a different format.  Examples of this include .....  This docu= ment defines ..."  Actually I think that this text might be even better placed in the introduction. And section 3.1 be p= romoted to become section 3. And the current section 3 be omitted.

 

Agreed.  I’= d independently reached the same conclusion.

 

JWK Format:=

 

8.  Does a JWK co= nsist of a JWK Container object - or is it identical to a JWK Container obj= ect?

 

(See 6)

 

JWK Container Object F= ormat:

 

9.  Why is the me= mber name jwk - it would seem that this should be the name of the member th= at holds the entire object not that of the array of key objects.  I wo= uld think that "keys" would be a better name for this member.

 

I agree.  WORKING= GROUP:  How do you feel about this possible name change?

 

10.  The last sen= tence in this section again conflates a container object and a JWK.

 

(See 6)

 

11.  Should the t= ext that is in the signature and encryption dealing with adding fields (url= s vs simple names) be included in this section as well?

 

Are you thinking of th= e text about the three classes of names:  reserved, private, and publi= c?  With the possibility of a registry?  What do people in the wo= rking group think?  I think the chances of this object being extended are small, especially since we only define one member. = ; But then, it’s incredibly hard to predict how a standard will be us= ed, if successful.  I’d be more prone to think that extension ma= de sense if the spec defined more than one member.

 

12.  Should there= be an IANA registry for the member names of a container object.=

 

Per 11, I don’t = think so.  I think this case is better handled by the standard JSON &#= 8220;you can add fields if you understand them” logic.

 

JWK Key Object Format:=

 

13.  Should there= be an IANA registry for the contents of the alg string?

 

In the JWA spec, yes.<= o:p>

 

14.  Should there= be an IANA registry for the members of a Key Object?

 

In the JWA spec, yes.<= o:p>

 

15.  What is the = function of the value of use?  Is there supposed to be a requirement o= n items that use a key that the "use" value be of specific

values?  &nb= sp; Do these values need to be registered?

 

Part of the function o= f this field is to match keys with the correct usages.  For instance, = I believe that it’s a potential security problem to use the same Elli= ptic Curve key for both signing and encryption.  One might have two keys, one with use “sig” and one with use &= #8220;enc” to specify which key (or keys) are to be used for which pu= rposes.

 

Unless the experts in = this group want to bring to our attention public key usages other than sign= ing and encryption that may also need to be defined in the future, I think = what we have is sufficient.  If this is a more open-ended set (looking at the X.509 key usage description may t= ell us), we may want to consider a more robust treatment.=

 

16.  I don't unde= rstand the sentence "The "kid" value MAY correspond to a JWS= "kid" value." - First this seems to make no sense to have a= protocol requirement statement on it.  Secondly if the value does not correspond to a JWS kid value, what in the world would it possibly corresp= ond to, how could would it be used for choosing among keys if it did not ha= ve such a correspondence?

 

I can tighten this to = say that when used with JWS and JWE, the JWS and JWE “kid” are = intended to be used to match JWK “kid” values for key selection= .  (When used in contexts other than with JWS and JWE, the “kid&= #8221; values could be matched against something else entirely.)

 

17.  Should the &= quot;kid" be present if there are multiple keys of the same usage and = algorithm?

 

I think this would be = up to the particular usage profiles.  We could maybe so far as to make= this RECOMMENDED for some use cases but I wouldn’t go for REQUIRED.&= nbsp; For instance, in some cases, including key roll-over, it may be perfectly fine to just try all the keys without having identifie= rs for any of them.

 

18.  Should the t= ext dealing with adding members be present (copied from JWS)?  Is it j= ust the key and not the entire key set that is to be ignored?

 

Again, are you thinkin= g the reserved/private/public treatment?  With a registry?  Or ma= ybe just a registry?  I didn’t find “ignore” in the = draft, so I’m not sure what the second sentence in your remarks is re= ferring to.

 

Open Issues:

 

19.  I think that= a section on adding key families would be reasonable.

 

Yes, probably in JWA.<= o:p>

 

Security Consideration= s:

 

20.  The key is n= o more trustworthy that the method that is came to you.

 

Will add.

 

21.  This structu= re is not intended to replace X.509 certificates.

 

I’m thinking thi= s belongs in the non-goals section.

 

Jim

 

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

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366499F0BTK5EX14MBXC284r_-- From mike.scott@certivox.com Thu Apr 26 01:14:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9F21F8704 for ; Thu, 26 Apr 2012 01:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC7ssWLT8k-6 for ; Thu, 26 Apr 2012 01:14:24 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id C8C6A21F86AB for ; Thu, 26 Apr 2012 01:14:23 -0700 (PDT) Received: from mail40-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 08:14:22 +0000 Received: from mail40-db3 (localhost [127.0.0.1]) by mail40-db3-R.bigfish.com (Postfix) with ESMTP id C419B3E027D; Thu, 26 Apr 2012 08:14:21 +0000 (UTC) X-SpamScore: 0 X-BigFish: PS0(zzzz1202hzzz2fh2a8h668h839h946hd25h) X-Forefront-Antispam-Report: CIP:157.56.248.133; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0310HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail40-db3: domain of certivox.com designates 157.56.248.133 as permitted sender) client-ip=157.56.248.133; envelope-from=mike.scott@certivox.com; helo=AMXPRD0310HT003.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail40-db3 (localhost.localdomain [127.0.0.1]) by mail40-db3 (MessageSwitch) id 1335428060620847_19353; Thu, 26 Apr 2012 08:14:20 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.236]) by mail40-db3.bigfish.com (Postfix) with ESMTP id 9181522004F; Thu, 26 Apr 2012 08:14:20 +0000 (UTC) Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 08:14:20 +0000 Received: from AMXPRD0310MB353.eurprd03.prod.outlook.com ([169.254.3.38]) by AMXPRD0310HT003.eurprd03.prod.outlook.com ([10.255.55.38]) with mapi id 14.16.0143.004; Thu, 26 Apr 2012 08:14:20 +0000 From: Mike Scott To: Mike Jones , Jim Schaad Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-key-01 Thread-Index: Ac0YFumdEsd+H7NuSBmmwJ3ugtJ7YwLQf9TwAAqtf/4= Date: Thu, 26 Apr 2012 08:14:20 +0000 Message-ID: <0C8F9A45306BD9499EAD612A10CFF8940E9E0D23@AMXPRD0310MB353.eurprd03.prod.outlook.com> References: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com>, <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.7.209.233] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: certivox.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:14:25 -0000 Hello List, Mike Jones said "Part of the function of this field is to match keys with the correct usage= s. For instance, I believe that it=92s a potential security problem to use= the same Elliptic Curve key for both signing and encryption..." Anyone got a reference for that? I did note some chatter on the Internet po= inting out that different algorithms are needed for encryption and signatur= e (ECIES and ECDSA), but not different keys. Assuming of course the same cu= rve is being used for both. I did a quick check in Hankerson et al. "Guide = to Elliptic Curve Cryptography", and there is no mention of it there.. If true, it needs to be propagated... If false, it needs to be quashed.. Mike Scott Certivox=20 From ve7jtb@ve7jtb.com Thu Apr 26 07:27:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38221F8731 for ; Thu, 26 Apr 2012 07:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2a7jzfNP3Hl for ; Thu, 26 Apr 2012 07:27:23 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF59A21F8714 for ; Thu, 26 Apr 2012 07:27:22 -0700 (PDT) Received: by qcsq13 with SMTP id q13so839305qcs.31 for ; Thu, 26 Apr 2012 07:27:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=K/Dg8Rgt3sgOlLdxUx2iyh8dTTeINlushAtGuH0jVpc=; b=btyKPBbpFlb8luI3V0mk5xUB5FMTDU9LIAkrXsRnX5/x41euPvUPYBdbBzMXHOt3f9 ZPVSxa7a5UlXCOnxL0OgmPbMhUKgB6DoBcljha5O9g/VVJ0EJiblW6qSF4/vGoiKf22T sK3VlkhfntEr9fbOTgO3LQA2lRT3PsLSKgfWPkP7fNg0p1ioaondGiVgx1b+GIaqyUEp 6L5hlc4nJ5H6XwAVZXwzjHw4QapQ0dpKHUUJIPXTwb2mB/3HkGcyoc6Gr38jIhBTN0MY qw4wwQ5KJuace1VFFXAGg5R4q6dHr879UNuaosanPFb7J6ctbuNvIJejo3I8WyjxgZW3 LXNw== Received: by 10.224.185.8 with SMTP id cm8mr5505291qab.72.1335450442448; Thu, 26 Apr 2012 07:27:22 -0700 (PDT) Received: from [192.168.1.213] (190-20-34-220.baf.movistar.cl. [190.20.34.220]) by mx.google.com with ESMTPS id z3sm5349278qao.9.2012.04.26.07.27.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 07:27:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_159CC889-D3E7-4C88-A50C-B530B9C1D3CE"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <0C8F9A45306BD9499EAD612A10CFF8940E9E0D23@AMXPRD0310MB353.eurprd03.prod.outlook.com> Date: Thu, 26 Apr 2012 11:27:11 -0300 Message-Id: <2C3A1C83-E891-4CAC-B8EC-0A3A4008770C@ve7jtb.com> References: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com>, <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> <0C8F9A45306BD9499EAD612A10CFF8940E9E0D23@AMXPRD0310MB353.eurprd03.prod.outlook.com> To: Mike Scott X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQn354BOlrlXEbfAI73lLq86twMp1VfKwd+nt5S8k2v/X3xYmPy6E35Adzg7O2Jev31dKb43 Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:27:24 -0000 --Apple-Mail=_159CC889-D3E7-4C88-A50C-B530B9C1D3CE Content-Type: multipart/alternative; boundary="Apple-Mail=_22F7F701-A550-4A09-A969-AD5021359F11" --Apple-Mail=_22F7F701-A550-4A09-A969-AD5021359F11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 http://www.math.uwaterloo.ca/~ajmeneze/publications/static.pdf I need to dig up other references. Using the same keys in different = protocols is generally a bad idea. Principle 2 of Anderson and Needham=92s robustness principles for public = key protocols [3] advises: If possible avoid using the same key for two different purposes (such as = signing and decryption)... Section 13.5.1 of the Handbook of Applied Cryptography [17] states: The principle of key separation is that keys for different purposes = should be crypto- graphically separated.=20 For RSA you are always encrypting even for a signature, so key reuse is = less of an issue. =46rom http://www.rfc-editor.org/rfc/rfc5008.txt As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve Diffie-Hellman (ECDH) use the same algorithm identifier for subject public keys in certificates, and it is repeated here: id-ecPublicKey OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) ansi-x9-62(10045) keyType(2) 1 } This object identifier is used in public key certificates for both ECDSA signature keys and ECDH encryption keys. The intended application for the key may be indicated in the key usage field (see RFC 3280 [PKIX1]). The use of separate keys for signature and encryption purposes is RECOMMENDED; however, the use of a single key for both signature and encryption purposes is not forbidden. While I don't know of a specific related key attack between ECDH-ES and = ECDSA it is RECOMENDED not to use the same static key for both. Will the world immediately end, probably not. John B. On 2012-04-26, at 5:14 AM, Mike Scott wrote: >=20 > Hello List, >=20 >=20 > Mike Jones said >=20 > "Part of the function of this field is to match keys with the correct = usages. For instance, I believe that it=92s a potential security = problem to use the same Elliptic Curve key for both signing and = encryption..." >=20 > Anyone got a reference for that? I did note some chatter on the = Internet pointing out that different algorithms are needed for = encryption and signature (ECIES and ECDSA), but not different keys. = Assuming of course the same curve is being used for both. I did a quick = check in Hankerson et al. "Guide to Elliptic Curve Cryptography", and = there is no mention of it there.. >=20 > If true, it needs to be propagated... >=20 > If false, it needs to be quashed.. >=20 >=20 > Mike Scott > Certivox=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_22F7F701-A550-4A09-A969-AD5021359F11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 ht= tp://www.math.uwaterloo.ca/~ajmeneze/publications/static.pdf

I need to dig up other references.  Using the same = keys in different protocols is generally a bad idea.
=09 =09 =09

Principle 2 of Anderson and Needham=92s= robustness principles for public key protocols [3] advises:

If possible avoid using the same key for two different purposes = (such as signing and decryption)...

Section 13.5.1 of the Handbook of Applied Cryptography [17] = states:

The principle of key separation is that keys for different purposes = should be crypto- graphically separated. 

For RSA you are always = encrypting even for a signature, so key reuse is less of an = issue.


As specified in =
RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve
   Diffie-Hellman (ECDH) use the same algorithm identifier for subject
   public keys in certificates, and it is repeated here:

      id-ecPublicKey  OBJECT IDENTIFIER  ::=3D  { iso(1) member-body(2)
          us(840) ansi-x9-62(10045) keyType(2) 1 }

   This object identifier is used in public key certificates for both
   ECDSA signature keys and ECDH encryption keys.  The intended
   application for the key may be indicated in the key usage field (see
   RFC 3280 [PKIX1]).  The use of separate keys for signature and
   encryption purposes is RECOMMENDED; however, the use of a single key
   for both signature and encryption purposes is not =
forbidden.

While I don't know of a = specific related key attack between ECDH-ES and ECDSA it is RECOMENDED = not to use the same static key for both.

Will = the world immediately end, probably not.

John = B.


On 2012-04-26, at 5:14 AM, = Mike Scott wrote:


Hello List,


Mike Jones = said

"Part of the function of this field is to match keys with = the correct usages.  For instance, I believe that it=92s a = potential security problem to use the same Elliptic Curve key for both = signing and encryption..."

Anyone got a reference for that? I did = note some chatter on the Internet pointing out that different algorithms = are needed for encryption and signature (ECIES and ECDSA), but not = different keys. Assuming of course the same curve is being used for = both. I did a quick check in Hankerson et al. "Guide to Elliptic Curve = Cryptography", and there is no mention of it there..

If true, it = needs to be propagated...

If false, it needs to be = quashed..


Mike Scott
Certivox =


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

= --Apple-Mail=_22F7F701-A550-4A09-A969-AD5021359F11-- --Apple-Mail=_159CC889-D3E7-4C88-A50C-B530B9C1D3CE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy NjE0MjcxNFowIwYJKoZIhvcNAQkEMRYEFGpUrHvPZMttbZcZtdKZoLnfWquOMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AIBFv5OCTbLJ5UvvC1r5g1DbR+aBhnBCO6LOdCQ3Lb3DeFcCrnzu3maekJGUwdqwoFjXJuOCjM12 owYwZ+iqX6T/KEieWgU1n2qAfggELfTIDvs2q3uvIVlxjUCqqxl5JEiJrGCZy63H8y2HQ5jp28rE 85qBEVSMBbVAJylHJbhjYvVY1htfLLYbMSrNZjmzGokaST12KK/XB8fseeJezuudBjVy+uuU1b+T okX8Ie5rgCdBwhJ0iwaszchXvISeghvBnLZerFYRtJIeBUrUq+zXxe6WER6CMR2SDH1kNgrvxb3u MBLt39AljFzLAgzsEQ1Rzajz2rVotAiSNv9fENMAAAAAAAA= --Apple-Mail=_159CC889-D3E7-4C88-A50C-B530B9C1D3CE-- From matthewdgreen@gmail.com Thu Apr 26 12:09:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28F621E8160 for ; Thu, 26 Apr 2012 12:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxp7F+n9-tJ6 for ; Thu, 26 Apr 2012 12:09:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22D21E817D for ; Thu, 26 Apr 2012 12:09:40 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1053877qcs.31 for ; Thu, 26 Apr 2012 12:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=L6ppqSqP4o898Qfs4eSSs0Wtw2jmNUXjYLH7pgl4YLI=; b=GZYHD32+Sk5TUu8p2mJWRxcPavjSLOU2zRR6LQ7XiYVzHu4X6SnvSP9HBxu16yDgme 53oKbAQFQHKnDtJ+V+VFMSb3Yb6Hr6I3lHB5G/J9BgtpJfuvmtR5jQ0Sx89sjL7tukxU 3+zt9edGu7tkTGrxmYBjLKGEDZyFmSNFaB7e8mXi8QjpOnVmmLhsyAzeb0ugG5O/PCqp So+FZTeixovbxXLqbIsPFlfC7UyQD1EYg4A/vxBVepOcCNroIt7NrE50G+ux7Ht1tsaz SCcFyLoQzKvXABbW6ZrTUEzphYBlnk/O7L6Z+IW0P8Ks8JHlZdD7onfqQkGdwbC11rNw RU+A== Received: by 10.229.69.17 with SMTP id x17mr1795894qci.137.1335467379892; Thu, 26 Apr 2012 12:09:39 -0700 (PDT) Received: from [192.168.15.2] (c-76-21-153-251.hsd1.md.comcast.net. [76.21.153.251]) by mx.google.com with ESMTPS id cp17sm6524285qab.5.2012.04.26.12.09.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 12:09:39 -0700 (PDT) From: Matthew Green Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Apr 2012 15:09:37 -0400 Message-Id: <7394014B-9374-4504-BB3F-199B803DA47D@gmail.com> To: jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:09:41 -0000 Is there any good reason to share a single key across signing and = encryption? There seem to be many instances where one key gets attacked = (e.g., due to implementation errors), and sharing the key means that = both algorithms are now compromised. See e.g., Degabriele's timing = attack on EMV from CT-RSA 2012. They used the same key for signature and = encryption. J.P. Degabriele, A. Lehmann, K.G. Paterson, N.P. Smart and M. Strefler, = On the Joint Security of Encryption and Signature in EMV. In O. = Dunkelmann (ed.), CT-RSA 2012, Lecture Notes in Computer Science Vol. = 7178, pp. 116-135, Springer, 2012. Full version. But I think Mike (Scott) is asking whether there's a formal reason to = use different fields/keys. I would ask Mike: is there a security proof = stating that it's /ok/ to share keys between the schemes used here? I'll = bet we could contrive some schemes where it's /not/ ok :) Matt > As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve > Diffie-Hellman (ECDH) use the same algorithm identifier for subject > public keys in certificates, and it is repeated here: >=20 > id-ecPublicKey OBJECT IDENTIFIER ::=3D { iso(1) = member-body(2) > us(840) ansi-x9-62(10045) keyType(2) 1 } >=20 > This object identifier is used in public key certificates for both > ECDSA signature keys and ECDH encryption keys. The intended > application for the key may be indicated in the key usage field = (see > RFC 3280 [PKIX1]). The use of separate keys for signature and > encryption purposes is RECOMMENDED; however, the use of a single = key > for both signature and encryption purposes is not forbidden. >=20 >=20 > While I don't know of a specific related key attack between ECDH-ES = and ECDSA it is RECOMENDED not to use the same static key for both. >=20 > Will the world immediately end, probably not. From ve7jtb@ve7jtb.com Sat Apr 28 13:23:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2498A21F8666 for ; Sat, 28 Apr 2012 13:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2Kjnhktp+53 for ; Sat, 28 Apr 2012 13:23:29 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3104721F8664 for ; Sat, 28 Apr 2012 13:23:29 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1083990ghb.31 for ; Sat, 28 Apr 2012 13:23:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Z4yDCapGukJIdCD/VjbzMEGsEuVUVapI+Jp354LRVZw=; b=dXWYD3qwHEktkbEJ1CUzXAQociUYIY+9t17iy6q+qF5laq5wQG3DNnV6XREWD8wD+u 0Pe4Uj5MiY4RxUS5ZGYH4ABpkX5tIYqegqTF4wtLrUJuxA+2o6TGi8fR59Gba5RrFjeu D4GBa07BRrv23s2yqxu6klkzY/lIGbhXM4bTrYwYA29PNEm2zeXlBDJFIZQy1RNL5cvZ eA4GUTPbxyxoRdmK+U16wZWhmAYQhRFE55HkfD/UDck2JouqWxuxgxqWNrLiWwklrd+9 9WK5M/MspsEiduq9AesxKVorsvWIP4fAuBsgVGKPe+f9AynyBgzQMMwgsGCrGeF3LT5X 1PjA== Received: by 10.236.109.198 with SMTP id s46mr16768270yhg.43.1335644608609; Sat, 28 Apr 2012 13:23:28 -0700 (PDT) Received: from [192.168.1.213] (190-20-34-122.baf.movistar.cl. [190.20.34.122]) by mx.google.com with ESMTPS id e1sm48479403yhi.9.2012.04.28.13.23.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Apr 2012 13:23:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_5329B6CF-CDF9-4FCA-A67D-697F1F610B68"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sat, 28 Apr 2012 17:22:52 -0300 Message-Id: <23467A10-BFB1-4C2A-9310-57F03E77593C@ve7jtb.com> References: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmNqx4ePew73sp4IOw9zpxO3nD5XQQVQ2JcEkApOqYs4f11Td5PCeWkbMISWKeWNbJ9WXgi Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 20:23:31 -0000 --Apple-Mail=_5329B6CF-CDF9-4FCA-A67D-697F1F610B68 Content-Type: multipart/alternative; boundary="Apple-Mail=_AA612FE7-70DC-4FEC-8141-F5AB1E1E31F5" --Apple-Mail=_AA612FE7-70DC-4FEC-8141-F5AB1E1E31F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Point 9: I agree "keys" probably makes more sense than "JWK". =20 John B. =20 On 2012-04-26, at 1:21 AM, Mike Jones wrote: > Thanks for the detailed comments, as always, Jim. Replies inline=85 > =20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Jim Schaad > Sent: Wednesday, April 11, 2012 1:07 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: [jose] Comments on draft-ietf-jose-json-web-key-01 > =20 > > =20 > I am starting to come out of the normal sickness period following an = IETF meeting. > =20 > I got sick after Paris too. Hope you=92re feeling better now! > =20 > So I am looking at the smallest document first. > =20 > This is a good one to start with, as it has probably been reviewed = less than the others. (Maybe read JWA next, by the same logic.) > =20 > I am going to skip section 4.2.1 & 4.2.2 as they appear to be heading = for a different document. > =20 > Agreed > =20 > Abstract: > =20 > 1. Are JWK items restricted to just asymmetric algorithms? = Can/Should one be able to transport symmetric keys via web key = structure? > =20 > Yes. During our scoping discussions for the work, I believe there was = consensus to restrict the JSON key representation spec to representing = public keys only. This is reflected in our charter as: > 3) A Standards Track document specifying how to encode public keys as = JSON-structured objects. > =20 > 2. There was a request at one point to allow for encoding of private = keys. > What if any response does the working group have to this request? > =20 > I believe this would require rechartering. > =20 > Introduction: > =20 > 3. The introduction text appears to be incorrect. While the jku = field refers to a JWK Web Key, the epk field holds a JWK Key Object. > =20 > You=92re right - I will tighten this description. > =20 > 4. I find the terminology to be very difficult to understand. A JSON = Web Key (JWK) is a set of one or more keys while a JWK Key Object is a = single key. The fact that these are all dealing with the same string = JWK is part of the confusion as is the fact that the JWK is singular in = name, but plural in content. > =20 > Yes, a JWK represents a set of keys and a JWK Key Object represents a = single key. I=92ll think about how to make the terminology more = intuitive. > =20 > 5. I would like to see the "non-goals" of this document to be pulled = out into a new paragraph and expanded into a number of different = non-goals of this document. This includes certified keys - that is any = form of binding of keys to names that has been attested to.=20 > =20 > Good idea. The set of non-goals should probably include representing = private keys, representing symmetric keys, representing certified keys, = and replacing X.509 certificates. > =20 > Terminology: > =20 > 6. I am not sure that the definition of the JWK Container Object is = useful. > Is this really a separate object from the JSON Web Key object? > =20 > Given there=92s a 1:1 mapping, it=92s probably not. I=92ll work on = simplifying/coalescing. > =20 > Overview: > =20 > 7. This section starts "It is sometimes useful.." There are a lot of = things that are sometimes useful but we don't standardize a lot of them. = I think that this text would be better started as: "A large number of = operations, such as digital signature validation, require the public key = in order to be successful. In many cases the public key is provided in = an > X.509 certificate, however there are cases where it is more convenient = to provide the public key in a different format. Examples of this = include ..... This document defines ..." Actually I think that this = text might be even better placed in the introduction. And section 3.1 be = promoted to become section 3. And the current section 3 be omitted. > =20 > Agreed. I=92d independently reached the same conclusion. > =20 > JWK Format: > =20 > 8. Does a JWK consist of a JWK Container object - or is it identical = to a JWK Container object? > =20 > (See 6) > =20 > JWK Container Object Format: > =20 > 9. Why is the member name jwk - it would seem that this should be the = name of the member that holds the entire object not that of the array of = key objects. I would think that "keys" would be a better name for this = member. > =20 > I agree. WORKING GROUP: How do you feel about this possible name = change? > =20 > 10. The last sentence in this section again conflates a container = object and a JWK. > =20 > (See 6) > =20 > 11. Should the text that is in the signature and encryption dealing = with adding fields (urls vs simple names) be included in this section as = well? > =20 > Are you thinking of the text about the three classes of names: = reserved, private, and public? With the possibility of a registry? = What do people in the working group think? I think the chances of this = object being extended are small, especially since we only define one = member. But then, it=92s incredibly hard to predict how a standard will = be used, if successful. I=92d be more prone to think that extension = made sense if the spec defined more than one member. > =20 > 12. Should there be an IANA registry for the member names of a = container object. > =20 > Per 11, I don=92t think so. I think this case is better handled by = the standard JSON =93you can add fields if you understand them=94 logic. > =20 > JWK Key Object Format: > =20 > 13. Should there be an IANA registry for the contents of the alg = string? > =20 > In the JWA spec, yes. > =20 > 14. Should there be an IANA registry for the members of a Key Object? > =20 > In the JWA spec, yes. > =20 > 15. What is the function of the value of use? Is there supposed to = be a requirement on items that use a key that the "use" value be of = specific > values? Do these values need to be registered? > =20 > Part of the function of this field is to match keys with the correct = usages. For instance, I believe that it=92s a potential security = problem to use the same Elliptic Curve key for both signing and = encryption. One might have two keys, one with use =93sig=94 and one = with use =93enc=94 to specify which key (or keys) are to be used for = which purposes. > =20 > Unless the experts in this group want to bring to our attention public = key usages other than signing and encryption that may also need to be = defined in the future, I think what we have is sufficient. If this is a = more open-ended set (looking at the X.509 key usage description may tell = us), we may want to consider a more robust treatment. > =20 > 16. I don't understand the sentence "The "kid" value MAY correspond = to a JWS "kid" value." - First this seems to make no sense to have a = protocol requirement statement on it. Secondly if the value does not = correspond to a JWS kid value, what in the world would it possibly = correspond to, how could would it be used for choosing among keys if it = did not have such a correspondence? > =20 > I can tighten this to say that when used with JWS and JWE, the JWS and = JWE =93kid=94 are intended to be used to match JWK =93kid=94 values for = key selection. (When used in contexts other than with JWS and JWE, the = =93kid=94 values could be matched against something else entirely.) > =20 > 17. Should the "kid" be present if there are multiple keys of the = same usage and algorithm? > =20 > I think this would be up to the particular usage profiles. We could = maybe so far as to make this RECOMMENDED for some use cases but I = wouldn=92t go for REQUIRED. For instance, in some cases, including key = roll-over, it may be perfectly fine to just try all the keys without = having identifiers for any of them. > =20 > 18. Should the text dealing with adding members be present (copied = from JWS)? Is it just the key and not the entire key set that is to be = ignored? > =20 > Again, are you thinking the reserved/private/public treatment? With a = registry? Or maybe just a registry? I didn=92t find =93ignore=94 in = the draft, so I=92m not sure what the second sentence in your remarks is = referring to. > =20 > Open Issues: > =20 > 19. I think that a section on adding key families would be = reasonable. > =20 > Yes, probably in JWA. > =20 > Security Considerations: > =20 > 20. The key is no more trustworthy that the method that is came to = you. > =20 > Will add. > =20 > 21. This structure is not intended to replace X.509 certificates. > =20 > I=92m thinking this belongs in the non-goals section. > =20 > Jim > =20 > Thanks = again, > -- Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_AA612FE7-70DC-4FEC-8141-F5AB1E1E31F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Point 9:

I agree "keys" = probably makes more sense than "JWK". =  

John B.  
On = 2012-04-26, at 1:21 AM, Mike Jones wrote:

Thanks for the detailed comments, as always, Jim.  = Replies inline=85
 
-----Original = Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of Jim Schaad
Sent: Wednesday, April 11, 2012 1:07 = PM
To: Mike Jones
Cc: jose@ietf.org
Subject: [jose] Comments on = draft-ietf-jose-json-web-key-01
 
<no hat>
I am starting to come out of the = normal sickness period following an IETF meeting.
I got sick after Paris too.  Hope you=92re feeling = better now!
 
So I am looking at = the smallest document first.
 
This is a good = one to start with, as it has probably been reviewed less than the = others.  (Maybe read JWA next, by the same = logic.)
 
I am going to skip = section 4.2.1 & 4.2.2 as they appear to be heading for a different = document.
 
Agreed
 
 
1.  Are JWK items restricted to just asymmetric = algorithms?  Can/Should one be able to transport symmetric keys = via  web key structure?
 
Yes.  = During our scoping discussions for the work, I believe there was = consensus to restrict the JSON key representation spec to representing = public keys only.  This is reflected in our charter = as:
3) A Standards Track document = specifying how to encode public keys as JSON-structured = objects. 
2.  There was = a request at one point to allow for encoding of private = keys.
What if any response does the = working group have to this request?
I believe this would require = rechartering.
 
3.  The introduction text = appears to be incorrect.  While the jku field refers to a JWK Web = Key, the epk field holds a JWK Key Object.
You=92re right - I will tighten this = description.
 
4.  I find the = terminology to be very difficult to understand.  A JSON Web Key = (JWK)  is a set of one or more keys while a JWK Key Object is a = single key.  The fact that these are all dealing with the same = string JWK is part of the confusion as is the fact that the JWK is = singular in name, but plural in content.
Yes, a JWK represents a set of keys and a JWK Key Object = represents a single key.  I=92ll think about how to make the = terminology more intuitive.
5.  I would = like to see the "non-goals" of this document to be pulled out into a new = paragraph and expanded into a number of different non-goals of this = document.  This includes certified keys - that is any form of = binding of keys to names that has been attested = to. 
 
Good idea.  The set of non-goals should probably = include representing private keys, representing symmetric keys, = representing certified keys, and replacing X.509 = certificates.
 
6.  I am not sure that the = definition of the JWK Container Object is useful.
Is this really a separate object from the JSON Web Key = object?
 
Given there=92s a 1:1 mapping, it=92s probably not.  = I=92ll work on simplifying/coalescing.
 
7.  This section starts "It is sometimes = useful.."  There are a lot of things that are sometimes useful but = we don't standardize a lot of them.  I think that this text would = be better started as:  "A large number of operations, such as = digital signature validation, require the public key in order to be = successful.  In many cases the public key is provided in = an
X.509 certificate, however there are = cases where it is more convenient to provide the public key in a = different format.  Examples of this include .....  This = document defines ..."  Actually I think that this text might be = even better placed in the introduction. And section 3.1 be promoted to = become section 3. And the current section 3 be = omitted.
 
Agreed.  I=92d independently reached the same = conclusion.
 
JWK = Format:
 
8.  Does a JWK consist of a JWK Container object - or = is it identical to a JWK Container object?
(See 6)
 
JWK Container Object Format:
 
9.  Why is the = member name jwk - it would seem that this should be the name of the = member that holds the entire object not that of the array of key = objects.  I would think that "keys" would be a better name for this = member.
 
I agree.  WORKING GROUP:  How do you feel about = this possible name change?
10.  The last = sentence in this section again conflates a container object and a = JWK.
(See 6)
 
11.  Should the text that is in the signature and = encryption dealing with adding fields (urls vs simple names) be included = in this section as well?
 
Are you thinking of the text about the three classes of = names:  reserved, private, and public?  With the possibility = of a registry?  What do people in the working group think?  I = think the chances of this object being extended are small, especially = since we only define one member.  But then, it=92s incredibly hard = to predict how a standard will be used, if successful.  I=92d be = more prone to think that extension made sense if the spec defined more = than one member.
 
12.  Should = there be an IANA registry for the member names of a container = object.
 
Per 11, I don=92t think so.  I think this case is = better handled by the standard JSON =93you can add fields if you = understand them=94 logic.
 
JWK Key Object Format:
 
13.  Should = there be an IANA registry for the contents of the alg = string?
 
In the JWA spec, yes.
14.  Should = there be an IANA registry for the members of a Key = Object?
 
In the JWA spec, yes.
15.  What is = the function of the value of use?  Is there supposed to be a = requirement on items that use a key that the "use" value be of = specific
values?    Do these = values need to be registered?
 
Part of the = function of this field is to match keys with the correct usages.  = For instance, I believe that it=92s a potential security problem to use = the same Elliptic Curve key for both signing and encryption.  One = might have two keys, one with use =93sig=94 and one with use =93enc=94 = to specify which key (or keys) are to be used for which = purposes.
 
Unless the experts in this group want to bring to our = attention public key usages other than signing and encryption that may = also need to be defined in the future, I think what we have is = sufficient.  If this is a more open-ended set (looking at the X.509 = key usage description may tell us), we may want to consider a more = robust treatment.
 
16.  I don't = understand the sentence "The "kid" value MAY correspond to a JWS "kid" = value." - First this seems to make no sense to have a protocol = requirement statement on it.  Secondly if the value does not = correspond to a JWS kid value, what in the world would it possibly = correspond to, how could would it be used for choosing among keys if it = did not have such a correspondence?
I can tighten this to say that when used with JWS and JWE, = the JWS and JWE =93kid=94 are intended to be used to match JWK =93kid=94 = values for key selection.  (When used in contexts other than with = JWS and JWE, the =93kid=94 values could be matched against something = else entirely.)
 
17.  Should = the "kid" be present if there are multiple keys of the same usage and = algorithm?
 
I think this would be up to the particular usage = profiles.  We could maybe so far as to make this RECOMMENDED for = some use cases but I wouldn=92t go for REQUIRED.  For instance, in = some cases, including key roll-over, it may be perfectly fine to just = try all the keys without having identifiers for any of = them.
 
18.  Should = the text dealing with adding members be present (copied from JWS)?  = Is it just the key and not the entire key set that is to be = ignored?
 
Again, are you thinking the reserved/private/public = treatment?  With a registry?  Or maybe just a registry?  = I didn=92t find =93ignore=94 in the draft, so I=92m not sure what the = second sentence in your remarks is referring = to.
 
Open = Issues:
 
19.  I think that a section on adding key families = would be reasonable.
 
Yes, probably in JWA.
Security = Considerations:
20.  The key is no more = trustworthy that the method that is came to you.
Will add.
 
21.  This structure is not intended to replace X.509 = certificates.
 
I=92m thinking this belongs in the non-goals = section.
 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:43:50 -0000 On Thu, Apr 26, 2012 at 1:21 PM, Mike Jones w= rote: > Thanks for the detailed comments, as always, Jim.=A0 Replies inline=85 > > > >> 9.=A0 Why is the member name jwk - it would seem that this should be the= name >> of the member that holds the entire object not that of the array of key >> objects.=A0 I would think that "keys" would be a better name for this me= mber. > > > > I agree.=A0 WORKING GROUP:=A0 How do you feel about this possible name ch= ange? > I support the change. This will make it much more descriptive. Nat From mike.scott@certivox.com Mon Apr 30 12:56:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A16C21F867B for ; Mon, 30 Apr 2012 12:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u2hsHYfJHcv for ; Mon, 30 Apr 2012 12:56:56 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id B262621F867A for ; Mon, 30 Apr 2012 12:56:56 -0700 (PDT) Received: from mail82-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Apr 2012 19:56:50 +0000 Received: from mail82-ch1 (localhost [127.0.0.1]) by mail82-ch1-R.bigfish.com (Postfix) with ESMTP id F3DFE2A0455; Mon, 30 Apr 2012 19:56:49 +0000 (UTC) X-SpamScore: -27 X-BigFish: PS-27(zz1432N1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.56.248.133; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail82-ch1: domain of certivox.com designates 157.56.248.133 as permitted sender) client-ip=157.56.248.133; envelope-from=mike.scott@certivox.com; helo=AMXPRD0310HT002.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail82-ch1 (localhost.localdomain [127.0.0.1]) by mail82-ch1 (MessageSwitch) id 1335815807588815_31818; Mon, 30 Apr 2012 19:56:47 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail82-ch1.bigfish.com (Postfix) with ESMTP id 8422840262; Mon, 30 Apr 2012 19:56:47 +0000 (UTC) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Apr 2012 19:56:46 +0000 Received: from AMXPRD0310MB353.eurprd03.prod.outlook.com ([169.254.3.38]) by AMXPRD0310HT002.eurprd03.prod.outlook.com ([10.255.55.37]) with mapi id 14.16.0143.004; Mon, 30 Apr 2012 19:56:08 +0000 From: Mike Scott To: Matthew Green , "jose@ietf.org" Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-key-01 Thread-Index: AQHNI+AfEsd+H7NuSBmmwJ3ugtJ7Y5azy/SP Date: Mon, 30 Apr 2012 19:56:08 +0000 Message-ID: <0C8F9A45306BD9499EAD612A10CFF8940E9E0E61@AMXPRD0310MB353.eurprd03.prod.outlook.com> References: <7394014B-9374-4504-BB3F-199B803DA47D@gmail.com> In-Reply-To: <7394014B-9374-4504-BB3F-199B803DA47D@gmail.com> Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.7.209.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: certivox.com Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:56:57 -0000 OK I guess this one falls into the PCS category (Plausible Cryptographic Su= perstition). Key management is tricky enough, and surely the less of them to be managed = the better. Personally I think a concrete reason or real threat of attack s= hould be demonstrated before counter-measures are taken which may add to th= e complexity - as with complexity comes mistakes.=20 But points to the contrary accepted, and thanks for the links and info. Mike Scott =20 ________________________________________ From: jose-bounces@ietf.org [jose-bounces@ietf.org] on behalf of Matthew Gr= een [matthewdgreen@gmail.com] Sent: 26 April 2012 20:09 To: jose@ietf.org Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01 Is there any good reason to share a single key across signing and encryptio= n? There seem to be many instances where one key gets attacked (e.g., due t= o implementation errors), and sharing the key means that both algorithms ar= e now compromised. See e.g., Degabriele's timing attack on EMV from CT-RSA = 2012. They used the same key for signature and encryption. J.P. Degabriele, A. Lehmann, K.G. Paterson, N.P. Smart and M. Strefler, On = the Joint Security of Encryption and Signature in EMV. In O. Dunkelmann (ed= .), CT-RSA 2012, Lecture Notes in Computer Science Vol. 7178, pp. 116-135, = Springer, 2012. Full version. But I think Mike (Scott) is asking whether there's a formal reason to use d= ifferent fields/keys. I would ask Mike: is there a security proof stating t= hat it's /ok/ to share keys between the schemes used here? I'll bet we coul= d contrive some schemes where it's /not/ ok :) Matt > As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve > Diffie-Hellman (ECDH) use the same algorithm identifier for subject > public keys in certificates, and it is repeated here: > > id-ecPublicKey OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) > us(840) ansi-x9-62(10045) keyType(2) 1 } > > This object identifier is used in public key certificates for both > ECDSA signature keys and ECDH encryption keys. The intended > application for the key may be indicated in the key usage field (see > RFC 3280 [PKIX1]). The use of separate keys for signature and > encryption purposes is RECOMMENDED; however, the use of a single key > for both signature and encryption purposes is not forbidden. > > > While I don't know of a specific related key attack between ECDH-ES and E= CDSA it is RECOMENDED not to use the same static key for both. > > Will the world immediately end, probably not. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose