From rbarnes@bbn.com Wed Oct 3 12:09:19 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 127EC1F0422 for ; Wed, 3 Oct 2012 12:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAvoWUFueSB2 for ; Wed, 3 Oct 2012 12:09:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 93F661F0423 for ; Wed, 3 Oct 2012 12:09:18 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:60072) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJUJq-000DMG-7f for jose@ietf.org; Wed, 03 Oct 2012 15:09:18 -0400 From: Richard Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Oct 2012 15:09:17 -0400 References: <20121001114217.11467.31415.idtracker@ietfa.amsl.com> To: "" Message-Id: <4B7001BB-9156-48CA-BAB8-4C1DE0368A89@bbn.com> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [jose] Fwd: Expiration impending: 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, 03 Oct 2012 19:09:19 -0000 I haven't updated this draft because it didn't seem like people were = that interested. If you think that a use cases draft for JOSE would be = helpful, please speak up now. And, ideally, suggest some use cases / = revisions. Thanks, --Richard Begin forwarded message: > From: IETF Secretariat > Subject: Expiration impending: > Date: October 1, 2012 7:42:17 AM EDT > To: "Richard Barnes" >=20 > The following draft will expire soon: >=20 > Name: draft-barnes-jose-use-cases > Title: Use Cases and Requirements for JSON Object Signing and = Encryption (JOSE) > State: I-D Exists > Expires: 2012-10-11 (in 1 week, 2 days) >=20 From Michael.Jones@microsoft.com Wed Oct 3 12:23:07 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 2C42511E809A for ; Wed, 3 Oct 2012 12:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUXpT-Kz0QOT for ; Wed, 3 Oct 2012 12:23:06 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAF911E8091 for ; Wed, 3 Oct 2012 12:23:06 -0700 (PDT) Received: from mail62-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 19:23:04 +0000 Received: from mail62-db3 (localhost [127.0.0.1]) by mail62-db3-R.bigfish.com (Postfix) with ESMTP id 9F523360063; Wed, 3 Oct 2012 19:23:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zf7Iz9371I936eI542M1432I4015Izz1202h1d1ah1d2ahz31iz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail62-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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail62-db3 (localhost.localdomain [127.0.0.1]) by mail62-db3 (MessageSwitch) id 1349292182739477_18392; Wed, 3 Oct 2012 19:23:02 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.227]) by mail62-db3.bigfish.com (Postfix) with ESMTP id B1BB9320110; Wed, 3 Oct 2012 19:23:02 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 19:23:01 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.31]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 3 Oct 2012 19:22:55 +0000 From: Mike Jones To: Richard Barnes , "" Thread-Topic: [jose] Fwd: Expiration impending: Thread-Index: AQHNoZrejbKdrZ7XnEOfEfMbAXbRpZen9Zqw Date: Wed, 3 Oct 2012 19:22:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366800B02@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20121001114217.11467.31415.idtracker@ietfa.amsl.com> <4B7001BB-9156-48CA-BAB8-4C1DE0368A89@bbn.com> In-Reply-To: <4B7001BB-9156-48CA-BAB8-4C1DE0368A89@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Fwd: Expiration impending: 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, 03 Oct 2012 19:23:07 -0000 Yes, I'd like to add several use cases. Could you please send me the .xml = source so I can do so? Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Wednesday, October 03, 2012 12:09 PM To: Subject: [jose] Fwd: Expiration impending: I haven't updated this draft because it didn't seem like people were that i= nterested. If you think that a use cases draft for JOSE would be helpful, = please speak up now. And, ideally, suggest some use cases / revisions. Thanks, --Richard Begin forwarded message: > From: IETF Secretariat > Subject: Expiration impending: > Date: October 1, 2012 7:42:17 AM EDT > To: "Richard Barnes" >=20 > The following draft will expire soon: >=20 > Name: draft-barnes-jose-use-cases > Title: Use Cases and Requirements for JSON Object Signing and Encrypti= on (JOSE) > State: I-D Exists > Expires: 2012-10-11 (in 1 week, 2 days) >=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Thu Oct 4 17:16: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 AFF4F11E8091 for ; Thu, 4 Oct 2012 17:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[AWL=1.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRc8ppqwxvRX for ; Thu, 4 Oct 2012 17:16:05 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA031F041E for ; Thu, 4 Oct 2012 17:16:05 -0700 (PDT) Received: from mail42-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 00:16:04 +0000 Received: from mail42-tx2 (localhost [127.0.0.1]) by mail42-tx2-R.bigfish.com (Postfix) with ESMTP id 8D26444014A; Fri, 5 Oct 2012 00:16:04 +0000 (UTC) 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 X-SpamScore: -25 X-BigFish: VS-25(zz98dI9371Id6eahc85fh168aJ148cIzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail42-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=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail42-tx2 (localhost.localdomain [127.0.0.1]) by mail42-tx2 (MessageSwitch) id 1349396162534301_32224; Fri, 5 Oct 2012 00:16:02 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.235]) by mail42-tx2.bigfish.com (Postfix) with ESMTP id 7EFEA240046; Fri, 5 Oct 2012 00:16:02 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Oct 2012 00:16:01 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.31]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 5 Oct 2012 00:16:00 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2ELoc7hDZ21YmQR8aBkF8crw0gfQAWHlqAAAAxeYAAAelbgAAAlU+AAAHAOoAAAXXfAAA+SIoABz0bhlA= Date: Fri, 5 Oct 2012 00:15:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668025FD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com> <05f101cd8597$cff358c0$6fda0a40$@augustcellars.com> In-Reply-To: <05f101cd8597$cff358c0$6fda0a40$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668025FDTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Karen O'Donoghue Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter 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, 05 Oct 2012 00:16:08 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668025FDTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As editor, I'm going to make the observation this is the one poll question = where the results are not clear enough for it to be obvious what I should d= o. There were many people who made comments about the question being uncle= ar and the intended use and meaning of the potential field or fields unclea= r. Unless you feel differently, Karen and Jim, I believe that the best course = at this point is for me to add nothing to the specs as a result of this pol= l question, but for the working group to try to make decisions on much less= ambiguous proposals (should any be made) than the one in the poll question= . -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Tuesday, August 28, 2012 8:38 PM To: 'Dick Hardt'; Axel.Nennker@telekom.de Cc: beaton@google.com; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter The question from my point of view is that common fields from many structur= es should potentially be supported in the base specification so that they c= an be common rather than having each structure define them separately. Thi= s is only an issue if one wishes them to be placed in the header structure = and not in the data structure. If one is looking at signing an unstructured data object - such as a file -= then it becomes difficult to have the fields such as a time that it was si= gned be part of the file itself, especially if one is applying multiple sig= natures at different times. This is not an issue for the token specificati= on but could be for other uses of the signature or encryption specification= s. I would agree that "iat" is a timestamp for the purposes of this conversati= on. If one wanted a formalized timestamp from a third party authority then= a totally different way of going about it would be required. I chose the = term nonce or timestamp because both had been discussed in the past without= any specific resolution about what is needed. Jim From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, August 27, 2012 2:55 PM To: Axel.Nennker@telekom.de Cc: dick.hardt@gmail.com; beaton@google.com; ietf@augustcellars.com; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter I was considering "iat" to be the timestamp. I was not thinking there would= be an additional timestamp. On Aug 27, 2012, at 2:13 PM, > wrote: We have exp https://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -03#section-4.1.1 and iat https://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -03#section-4.1.3 in JWT. Why do we need a timestamp? Replay attacks of the same jwt can be mitigated through the jti claim https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.= 7 What do timestamp and nonce add to these? Axel From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, August 27, 2012 10:23 PM To: Brian Eaton Cc: Nennker, Axel; Jim Schaad; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt > wrote: I have an application for JWT that is not OAuth2. Should nonce and timestamp logic go in the application level protocol? I prefer to NOT have the application level deal with token validity. Having said that, nonce's are difficult to implement at scale and I have he= ard of many sites that don't implement them fully. Nonce alone can't be implemented efficiently. You have to have time stamps= as well, otherwise you are stuck storing ever nonce you've ever seen, fore= ver. Even nonce + time stamp is challenging in distributed systems. It adds a l= ot of complexity. That complexity is sometimes merited, but not always. Thanks for confirming my statement. I have stopped using nonce and only use time stamps lately and have made th= e system relatively stateless so that a second submission of the token is o= k. That may not work for everyone, but I have found that architecture to be= easier to implement and scale. --_000_4E1F6AAD24975D4BA5B1680429673943668025FDTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As editor, I’m goin= g to make the observation this is the one poll question where the results a= re not clear enough for it to be obvious what I should do.  There were many people who made comments about the question being unclear and th= e intended use and meaning of the potential field or fields unclear.

 <= /p>

Unless you feel different= ly, Karen and Jim, I believe that the best course at this point is for me t= o add nothing to the specs as a result of this poll question, but for the working group to try to make decisions on much less ambiguous = proposals (should any be made) than the one in the poll question.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, August 28, 2012 8:38 PM
To: 'Dick Hardt'; Axel.Nennker@telekom.de
Cc: beaton@google.com; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

The question from my poin= t of view is that common fields from many structures should potentially be = supported in the base specification so that they can be common rather than having each structure define them separately.  Thi= s is only an issue if one wishes them to be placed in the header structure = and not in the data structure. 

 <= /p>

If one is looking at sign= ing an unstructured data object – such as a file – then it beco= mes difficult to have the fields such as a time that it was signed be part of the file itself, especially if one is applying multiple signatures= at different times.  This is not an issue for the token specification= but could be for other uses of the signature or encryption specifications.=

 <= /p>

I would agree that “= ;iat” is a timestamp for the purposes of this conversation.  If = one wanted a formalized timestamp from a third party authority then a total= ly different way of going about it would be required.  I chose the term = nonce or timestamp because both had been discussed in the past without any = specific resolution about what is needed.

 <= /p>

Jim

 <= /p>

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.c= om]
Sent: Monday, August 27, 2012 2:55 PM
To: Axel.Nennker@telekom.= de
Cc: dick.hardt@gmail.com= ; beaton@google.com; ietf@augus= tcellars.com; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

I was considering "iat" to be the timestam= p. I was not thinking there would be an additional timestamp.

 

On Aug 27, 2012, at 2:13 PM, <Axel.Nennker@telekom.de> wrote:

 

We have exp

and iat

in JWT. Why do we need a timestamp?

 

Replay attacks of the same jwt can be m= itigated through the jti claim

 

What do timestamp and nonce add to thes= e?

 

Axel

 

 <= /p>

 <= /p>

From: Dick Hardt [mailto:dick.hardt@= gmail.com] 
Sent: Monday, Augu= st 27, 2012 10:23 PM
To: Brian Eaton Cc: Nennker, Axel;= Jim Schaad; jose@ietf.org
Subject: Re: [jose= ] DISCUSS: Nonce/Timestamp parameter

 

 

On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote:=



On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

I have an application for JWT that is not OAuth2.

 

Should nonce and timestamp logic go in the applicati= on level protocol?

 

I prefer to NOT have the application level deal with= token validity.



 

Having said that, nonce's are difficult to implement= at scale and I have heard of many sites that don't implement them fully.

 

Nonce alone can't be implemented efficiently.  = You have to have time stamps as well, otherwise you are stuck storing ever = nonce you've ever seen, forever.

 

Even nonce + time stamp is challenging in distri= buted systems.  It adds a lot of complexity.  That complexity is = sometimes merited, but not always.

 

Thanks for confirming my statement.

 

I have stopped using nonce and only use time stamps = lately and have made the system relatively stateless so that a second submi= ssion of the token is ok. That may not work for everyone, but I have found = that architecture to be easier to implement and scale.

 

--_000_4E1F6AAD24975D4BA5B1680429673943668025FDTK5EX14MBXC284r_-- From dholth@gmail.com Thu Oct 4 18:01: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 6A1C61F0C44 for ; Thu, 4 Oct 2012 18:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euzoecsWyZ5v for ; Thu, 4 Oct 2012 18:00:59 -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 590141F041F for ; Thu, 4 Oct 2012 18:00:59 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1417766obq.31 for ; Thu, 04 Oct 2012 18:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=uUjhpREkotqc8fZYXA+R3J/PdJ6Bnbaw+jF5aWi9U8s=; b=MPkLDJe2keYdzkGtmQHdzcciZ8/zCKvxJObwXo2B4IJyhBqdt+LLMIJVmYvClJavPB TQYcQ3qZGz2vVx3ao345ZGrLphjYe6vXG1WYjXq71Nb1a/RGptYbMgDD2FSS/1riGqE+ hOMRA4DVN3TApgb1pkc6IQcfE6iWxlkkSyf3i6o+oD8nN1RzKWHbJUsXdd4Ni+PaBEaW AKswz6LdVEyL2BDusF4yCM+iwNv+ukReJJFdO2CZ/DvNOqszdJCPGzbZD8XTw7uFfWeZ 02g8mxAXg42xxH7ZSoEacKHYgaAkR59SJs3Xnpq1eJVWQlwyIJhTBPRJV6RPUPVjrOf1 HIqQ== Received: by 10.60.11.1 with SMTP id m1mr5784476oeb.47.1349398858896; Thu, 04 Oct 2012 18:00:58 -0700 (PDT) Received: from ?IPv6:2001:470:8:e7c:908a:6c87:73c6:e647? ([2001:470:8:e7c:908a:6c87:73c6:e647]) by mx.google.com with ESMTPS id hz6sm8116891obb.1.2012.10.04.18.00.56 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 18:00:57 -0700 (PDT) References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com> <05f101cd8597$cff358c0$6fda0a40$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943668025FD@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668025FD@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Daniel Holth Date: Thu, 4 Oct 2012 21:00:53 -0400 To: Mike Jones Cc: Karen O'Donoghue , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter 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, 05 Oct 2012 01:01:00 -0000 --Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Would it be too confusing to ask for a sat "signed at" field for the header?= In my application this makes more sense (with the multiple signatures seria= lization specification jws-js) than a payload time stamp. Daniel Holth On Oct 4, 2012, at 8:15 PM, Mike Jones wrote: > As editor, I=E2=80=99m going to make the observation this is the one poll q= uestion where the results are not clear enough for it to be obvious what I s= hould do. There were many people who made comments about the question being= unclear and the intended use and meaning of the potential field or fields u= nclear. > =20 > Unless you feel differently, Karen and Jim, I believe that the best course= at this point is for me to add nothing to the specs as a result of this pol= l question, but for the working group to try to make decisions on much less a= mbiguous proposals (should any be made) than the one in the poll question. > =20 > -- Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ji= m Schaad > Sent: Tuesday, August 28, 2012 8:38 PM > To: 'Dick Hardt'; Axel.Nennker@telekom.de > Cc: beaton@google.com; jose@ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > The question from my point of view is that common fields from many structu= res should potentially be supported in the base specification so that they c= an be common rather than having each structure define them separately. This= is only an issue if one wishes them to be placed in the header structure an= d not in the data structure.=20 > =20 > If one is looking at signing an unstructured data object =E2=80=93 such as= a file =E2=80=93 then it becomes difficult to have the fields such as a tim= e that it was signed be part of the file itself, especially if one is applyi= ng multiple signatures at different times. This is not an issue for the tok= en specification but could be for other uses of the signature or encryption s= pecifications. > =20 > I would agree that =E2=80=9Ciat=E2=80=9D is a timestamp for the purposes o= f this conversation. If one wanted a formalized timestamp from a third part= y authority then a totally different way of going about it would be required= . I chose the term nonce or timestamp because both had been discussed in th= e past without any specific resolution about what is needed. > =20 > Jim > =20 > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Monday, August 27, 2012 2:55 PM > To: Axel.Nennker@telekom.de > Cc: dick.hardt@gmail.com; beaton@google.com; ietf@augustcellars.com; jose@= ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > I was considering "iat" to be the timestamp. I was not thinking there woul= d be an additional timestamp. > =20 > On Aug 27, 2012, at 2:13 PM, wrote: > =20 >=20 > We have exp > https://tools.ietf.org/html/draft-ietf-oauth-json-web-toke= n-03#section-4.1.1 > and iat > https://tools.ietf.org/html/draft-ietf-oauth-json-web-toke= n-03#section-4.1.3 > in JWT. Why do we need a timestamp? > =20 > Replay attacks of the same jwt can be mitigated through the jti claim > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1= .7 > =20 > What do timestamp and nonce add to these? > =20 > Axel > =20 > =20 > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Monday, August 27, 2012 10:23 PM > To: Brian Eaton > Cc: Nennker, Axel; Jim Schaad; jose@ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > =20 > On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: >=20 >=20 >=20 > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt wrote:= > I have an application for JWT that is not OAuth2. > =20 > Should nonce and timestamp logic go in the application level protocol? > =20 > I prefer to NOT have the application level deal with token validity. >=20 >=20 >=20 > =20 > Having said that, nonce's are difficult to implement at scale and I have h= eard of many sites that don't implement them fully. > =20 > Nonce alone can't be implemented efficiently. You have to have time stamp= s as well, otherwise you are stuck storing ever nonce you've ever seen, fore= ver. > =20 > Even nonce + time stamp is challenging in distributed systems. It adds a l= ot of complexity. That complexity is sometimes merited, but not always. > =20 > Thanks for confirming my statement. > =20 > I have stopped using nonce and only use time stamps lately and have made t= he system relatively stateless so that a second submission of the token is o= k. That may not work for everyone, but I have found that architecture to be e= asier to implement and scale. > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Would it be too confusing to ask for a= sat "signed at" field for the header? In my application this makes more sen= se (with the multiple signatures serialization specification jws-js) than a p= ayload time stamp.

Daniel Holth

On Oct 4, 2012, at 8:15= PM, Mike Jones <Michael.J= ones@microsoft.com> wrote:

=

As editor, I=E2=80=99m goin= g to make the observation this is the one poll question where the results ar= e not clear enough for it to be obvious what I should do.  There were many people who made comments about the question being unclear and the= intended use and meaning of the potential field or fields unclear.

 

Unless you feel differently= , Karen and Jim, I believe that the best course at this point is for me to a= dd nothing to the specs as a result of this poll question, but for the working group to try to make decisions on much less ambiguous p= roposals (should any be made) than the one in the poll question.<= /span>

 

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

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, August 28, 2012 8:38 PM
To: 'Dick Hardt'; Axel.Nen= nker@telekom.de
Cc: beaton@google.com; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

The question from my point o= f view is that common fields from many structures should potentially be supp= orted in the base specification so that they can be common rather than having each structure define them separately.  This= is only an issue if one wishes them to be placed in the header structure an= d not in the data structure. 

 

If one is looking at signin= g an unstructured data object =E2=80=93 such as a file =E2=80=93 then it bec= omes difficult to have the fields such as a time that it was signed be part of the file itself, especially if one is applying multiple signatures a= t different times.  This is not an issue for the token specification bu= t could be for other uses of the signature or encryption specifications.

 

I would agree that =E2=80=9C= iat=E2=80=9D is a timestamp for the purposes of this conversation.  If o= ne wanted a formalized timestamp from a third party authority then a totally= different way of going about it would be required.  I chose the term n= once or timestamp because both had been discussed in the past without any sp= ecific resolution about what is needed.

 

Jim

 

 

From: Dick Hardt [mailto:dick.hardt@gmail.co= m]
Sent: Monday, August 27, 2012 2:55 PM
To: Axel.Nennker@telekom.d= e
Cc: dick.hardt@gmail.com;= beaton@google.com; ietf@august= cellars.com; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

I was considering "iat" to be the timestamp. I was no= t thinking there would be an additional timestamp.

 

On Aug 27, 2012, at 2:13 PM, <Axel.Nennker@telekom.de> wrote:

=

 

We have exp

and iat

in JWT. Why do we need a timestamp?<= /o:p>

 

Replay attacks of the same jwt can be mit= igated through the jti claim

 

What do timestamp and nonce add to these?=

 

Axel

 

 

 

From: Dick Hardt [mailto:dick.hardt@g= mail.com] 
Sent: Monday, Augus= t 27, 2012 10:23 PM
To: Brian Eaton
= Cc: Nennker, Axel; J= im Schaad; jose@ietf.org
Subject: Re: [jose]= DISCUSS: Nonce/Timestamp parameter

 

 

Thanks for confirming my statement.

 

I have stopped using nonce and only use time stamps l= ately and have made the system relatively stateless so that a second submiss= ion of the token is ok. That may not work for everyone, but I have found tha= t architecture to be easier to implement and scale.

 

= --Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C-- From ietf@augustcellars.com Fri Oct 5 20:11: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 794B821F865D for ; Fri, 5 Oct 2012 20:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1FEzRwT9vdg for ; Fri, 5 Oct 2012 20:11:45 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 117B821F8653 for ; Fri, 5 Oct 2012 20:11:45 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CC3C62C9BB for ; Fri, 5 Oct 2012 20:11:44 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 5 Oct 2012 20:10:18 -0700 Message-ID: <00ae01cda370$1da15770$58e40650$@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: Ac2jb/LYlFfsAfXcRGe1LUhwg0eCOA== Content-Language: en-us Subject: [jose] Meeting agenda 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, 06 Oct 2012 03:11:45 -0000 If you want to do a presentation or have a topic that you feel needs to be discussed face to face, please let the chairs know. We would like to see the document title, who is presenting and an estimate of time needed in the request. Jim From vladimir@nimbusds.com Mon Oct 8 01:20: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 79F1C21F8753 for ; Mon, 8 Oct 2012 01:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[AWL=-2.436, BAYES_50=0.001, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, J_CHICKENPOX_43=0.6, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFiRhZog7gAs for ; Mon, 8 Oct 2012 01:20:24 -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 66AE021F8732 for ; Mon, 8 Oct 2012 01:20:22 -0700 (PDT) Received: (qmail 961 invoked from network); 8 Oct 2012 08:20:19 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 8 Oct 2012 08:20:19 -0000 Received: (qmail 472 invoked by uid 99); 8 Oct 2012 08:20:19 -0000 Content-Type: multipart/related; boundary="=_f11bac9d6d5732d2e9749468ed5085cf" X-Originating-IP: 79.100.90.16 User-Agent: Workspace Webmail 5.6.25 Message-Id: <20121008012018.cc40c4f3d92d2001859047cd8cabb9ab.335b22f95d.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Mon, 08 Oct 2012 01:20:18 -0700 Mime-Version: 1.0 Subject: [jose] =?utf-8?q?Example_DEFLATE_vectors_for_JWE=3F?= 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, 08 Oct 2012 08:20:25 -0000 --=_f11bac9d6d5732d2e9749468ed5085cf Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" www.NimbusDS.com : vladimir@nimbusds.com


3D""
 --=_f11bac9d6d5732d2e9749468ed5085cf Content-Transfer-Encoding: base64 Content-ID: Content-Type: image/jpeg; name="sigimg1"; Content-Disposition: inline; filename="sigimg1"; /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQIBAQEBAQIBAQECAgICAgIC AgIDAwQDAwMDAwICAwQDAwQEBAQEAgMFBQQEBQQEBAT/2wBDAQEBAQEBAQIBAQIEAwIDBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAT/wAARCABfAaQDAREA AhEBAxEB/8QAHgABAAICAwEBAQAAAAAAAAAAAAgJBwoEBQYDAgH/xAA/EAABBAIBAwIEBQICCAUF AAADAQIEBQAGBxESEwghCRQVIhYxN3e1I0FCURcYJEdhgYbFMjhxhbYlJjNSgv/EAB4BAQADAQEB AQEBAQAAAAAAAAAHCAkGBQQDAgEK/8QAShEAAgEDAwIDBAUHCQYFBQAAAQIDAAQRBQYSByETMUEI FCJRMjZhdLMVN0JScYG0FiMzRXJ1hJGhF2KDosPEGCRDU7E0gpPB8P/aAAwDAQACEQMRAD8A3+MU pilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUp ilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpi lMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpil MUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilVmfEk3DY6XXuMdXq raZX020yriVfRYZ3Rks/kG1jYwzK1UVw0WaZyjXq1XIxVRVa1UtX7Lmi6Zfalq2rXkKvPbiARlgD w8QyliufJj4ajkO4GQDgnNe+vuq39pY6dp1tKVimMpcAkcuHh8QceY+MnHlnB9BUUvSR6nbPh/bI 2t7bbTZfGOwFZDnAlHfKFqhnL0HPjMVV7Boq9DsZ07mL3dHOG1FmHrN0otd7aO+qaNCq6tCCykAA zL6xuR5n1jJ8m+HIViRGnTDqJcbV1NbDVJS2nSkAgkkRH0dR6D9cDzHfBIAq9sJgyQikRzCkR5Am mAcJEKEzHojmvY5PZWqioqKnsqLme0kbxSNFKpDAkEEYII7EEHyI9RVzUdJEEkZBUjII7gg+RB+V Qi+IFtN/rHBcFlBaTKl2xb5D122LBO6MeTDfBs5RAd7VRyNe+IHuRF+5qK1eqKqLPfs36Rp2rdQZ G1GFZPBt3lQMAQHEkSBsHtkB2x8jgjuAaiDrfqV7p2zUFlIU8WZI2IOCUKSMRkd8EqM/Mdj2JqK3 w39s2FeSNx0x9rMLrR9FNsf0k0hxYYJkexrY7DCYq9GOcOYZrlb07ujOvXtb0l/2odH03+S9jrqw qLoXCxcwAGKNFKxUkeYDIpGfLvjGTmNugep3x1+70lpSbcwmTiTkB1kjUED0JDkHHn2z5Cs7/ET3 jdNY0fSKPXJ1hVUe2W04Gzz64r4pT/LCjOiwnlb0VBm80l7mdU7/AJVOvVEVFjz2ZdA0LVtf1DUN UjWS4t0jMKsAQOZYPIAf0l4oAf0efzIrs+u2savp2j2dnYOyQzM4kZSQTxC8UJHo2WJHrx+Wair6 At53WBzTA0qBPsZeobDUzz7BVEM89dAWNFIcE1o1XtG/zMCBXp07kk9F6/b0mD2jdv6DcbEk125j Vb2F4xE4ADNycK0ZPmw4Fnwc4K5GO9Rt0S1nV4d2ppELs1rKrl1ySq8VLK4HkDyAXPrywfSrvsoL VwKYpTFKYpTFKYpWsmvK3IC79/pM/FFx+Mvq31f6t88Ty9/k8nh6deng6fZ4P/x9n2dvb7Zq3/I/ bf8AJ3+Snuie48OHDiMYxjl5fT9ef0uXxZz3rPT+Uuuflv8AlD7y/vfLnyyc5znH9n04/R49sY7V s2ZlJWhdMUpilMUpilMUpilMUpilY75evbLVuJuUNmpjJGt9c47u72qkKxCJHkw62TIA/tX2XteN q9F9l6Zym+9Tu9F2PrOsae3GeC0uJUPnh44XdTj7GANcT1L1e+2/053Br+lvxubayu5o2xnEkUEj ocHscMoOK1cbKzsbmdKtLefNtLKcZ0ibYWMp82bLI5ernkK9Vc5yqvVVVVXMYru8u9QuXvb6VpJn JLO5LMxPmSxJJJ+ZNf8APxfX99ql5JqGpTPLPISzu7F3Zj3JZmJJJ9STmuE1zmORzXK1zV6o5q9H J/6Ln4AlTlT3r5QSp5KcGsxce+oHmTi6bHladyBsUGOB6OdTTJ77XX5KIvu0kEyuCvVOqdyNRydV 7XIvvnfbV6pb/wBmXCz6BqkqKP8A02YvEfsMb8k+zIAYehBqTtl9Z+p/T+6S42xrU8aKf6JnMkLf Y0MnKM58shQw9CD3q6/0r+r7X/UBFfrl5FiaxybXRFky6YJVWr2ALETySq1Xqr/t/N8d6uexF6o4 jUc5uh/RXrxpfVGE6TqSLb6xGuWjB+CVR5vDnv2/SjJLKO4LDJGq3s9e0tovWW3Oh6tGtrr0S8mi BPhzKPpSQFiW7ebxMSyDuGdQWEyJMgEOOeXKMOPGihdIkHK5GCANjVc97nL7IiIiqqr/AGTJ+lli giaeZgqKCST2AAGST9gFWenmhtoXuLhgsaAsxPYAAZJJ9AB3Na+PqV9YG/cx7La1ms3trq/GUOS+ JS0lVKJWHvAtVWpLsnsVHkcXp3oBy+MbVanarkcR2WnV7r1uff2rz2ej3L2+joSscaMUMijtzmIw WL+YQ/AgwMFgWbF7rt7TO8ep2u3FhoN3JaaAjFYoo2aNplHbxJypDOX8xGTwQYHEsGdow6pv27aL aiu9P2u+1y0EVCpLqbMsRxVRevQrUXtI1fyVhEc1yKqKipkN6JujcW271dR0G+lgnBzyR2XP9oA4 YH1DAg+RBqAdubx3XtHUV1bbGozW1wDnlHIy5+xgDhwfVWBUjsQRV+no39RM/wBQHH9gTZQgFu+m TA1eyGhhQEO2Ydj3xJzBp9o3FQJ2vG37UeBzmo1r2sbp50B6r3PVHa0r6uoGo2jKkxUYWQMCUkA8 lLcWDKOwZSRhWCjY72Yett51m2ZM+uoBq1iyxzlRhZA4JjmCjspfi4dR2DIWUKrBVl9k71ZamKUx SmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSqp/icf7kf+pf8AsGXA9lH+v/8AC/8A c1Wv2hv6n/xH/QqqxoDuASU0JXRglYA0hBqoBPIhHDY5/wCSOcgiq1F91Qbun5LlvTJGJBEWHIgk DPcgYBIHngEjJ9Mj5iq2hHKGQA8QQCfQE5wM/M4OP2H5Va96EPUt8yOHwdvFh/tABq3ju2mF9zDa iudUEev92Iiuj9fzajhIqdomrTz2helfhM+/9Aj+E/8A1SKPI+k4A9D5S/bh/VyLL9GOoPiKmztY f4h/QMT5j/2ifs80+zK+ig5L+JB+h+q/utB/iL3OV9l76/3n3OT8e3roOvn1PtvvKfhTVFP4b/64 bV+1M7+XosmD2ofqBZ/fI/wLio16B/XC5+7P+LDVg/rE3rVtD4Ymzdq0uq30F3eRteqqG67m1vzh RSZDJBCMVCs8Q40hyOC5pFXo1Hs7lclbeiO39X3DvqODSL97Roo2leSPHPgCqlQDlTyZ1BDBlxkl Wxgzj1U1nTdF2m8upWi3KyOsao/0eZDMGJHxDiFY5Ug57AjOajX6BOTNKv7vb9OquLdV0bZB0n4h W51k0+YlrDFJBHLHMSdIkSW+MkqO5rUMrHdzl7Gq1FdKftGbV17TtPstbu9Xmu7UyeF4cojXg5Rm DKIY4ozlUYElOQwPiIPaP+ie4dIvry60q202K3uOHic4y55IGVSpMjyOMFlIHPByewx3lz6l+bX8 Ccav3KLUBurefdg1ujhSyuFASScUiR5JCt+9RsFFO7taqK5yNb3N69yQv0r2EvUXdQ0OaYxQpG0s jKAW4Kyrhc9uRZ1GTkAZODjBlDqDu87K2+dWjiEkrOsaAkheTBmy2O+Aqk4GMnAyM5quVfiS8tfI sGmj8dJZIRVfLUFmsFzOidrUj/N9yKnv1d5VRev5Jlnv/C5sz3gsb+68LH0cxcs/2vCxj7OH7zUD f7ftzeCF9zg8T54k44/s+Jn/AJv3V7zQPiTzPmvByhoERYT2OVLPRDEHIA5EVWtWFKK5Ho5eiK5D t7fz7XflnO7j9lqDwfE2lqLeJ2+C4AII9T4kajGPl4Zz8xXtaJ1/l8XhuOyHD9aEnI/+x2Oc/PmM fI15bYviUcgGsiO1Lj7Tq2oQioEWxGm3dkRqL7OcQJo7Gqqe/RGuROvTq7p1X19M9lrbcdqBrOpT vNjuYhHGoP2B1kJA+eRn5Dyrzb/r/rb3BOmWMSRegkLu2PtKsgH+Rx8zUlPT365Nc5XvIWlbvTA0 rbbN6R6WXGmOk65emX8o7XPRHgM9fYY3q9r1TtQne5rHRZ1K9n/VNn6fJr2gTm6s4xmRSuJY1/WO OzqP0iApUdyvEFhIGxusVhuW8TSNYiFvdP2Qg5jc/qjPdWP6IJIPkGyQDPXK7VNNap+bAVmvVkmw fEo5EPMI7VePdLqoHeqCFsEidfzFb19lcQJYzUVU/sjfb/Ncq5pvstbZjgA1jUp5JPUxCONf3Bll P+tT9fe0Brryk6bYwonoJC7n/NWjH+lZI4u+I7BsrOLV8s6hGoYsoiCdtGqlNKgwVVenceATvL40 /NXiI9yJ+Q3Zy+7fZguLW1e72bemV1GfBmChm+xZF4ry+QZVHzYV7+3OvUNxcLbbmtRGpOPEiJKj +0hy2PmQzH/dNWb1tlX3NfCtqmbFsqyyisnV9hCO2TDmhK1HjKIjVVrmuaqKiovRUXKpXVrc2NzJ Z3kZSVCVZWBDKwOCCD3BB8xVhbe4guoEubZw8bgFWByCD3BBHmCKrv8AUx62tm4g5Ml8daXq2vWL 9fjRC7DY7Kko/wAwSXGFMYGKMJRdiNCcKqR6v6ue5OxEb1dZjpV0F0neu1E3Nrt5KgmLiJYuAwEZ kLOXV85ZW+EBcAA8jntBXUHq9qG1twtoOk20bmIKZGk5HJZQ4ChWXGFYdyT3Pl27zP4a5Jj8vcZa nyLGr31TdjhFIeueb5j5M8aSeHJG0nRO5iGjl7XKiKre1VRF9sgvfO1pNl7rvdsyyeJ4DDDYxyV0 V0JHfB4sMjJwcjJqWdp6/Hujb1rr0acPFByuc4ZWKMM+o5KcHAyMVXE34kd8u+oxdGoU41W1+WX+ rJ/F6Q/J2fNebyeDv7P6nh8PT/B5P8eWgPsuab/J3I1CT8qcM+SeBzxnhx48+Ofh58/97j+jUCjr 7e/lrBs0/J/LHm3i8c45Zzxzjvx4/Zy9atE3Pcde4/1e63Hap7K2hoYazbCU5qvcidUYwY2J7uIR 7mDYxPdz3tRPzypOhaJqW5NXg0PR4+dzM3FR/qST6KoBZiewAJ9KsXq2q2OiadNqupPwgjGWP+gA HqScAD1JAqqbbPiT7oS4N+BtB1eFQDMrY/4rfLtLeUNF9nv+XOEYnOT37E8iN69O93TqtwdH9lrQ Usl/lBqMz3BHfweCID8hzR2YD5/DnzwPKq16n1/1dro/keyjWEHt4vJmI+Z4sgUn5fFj5mpc+mX1 dU3Pkubq1pRLq28V1c60WICUs6nuY7HsGUsYjkR7HscRncF/cva5Fa9/R3bDHVbovfdOoE1ezuPe NPduHIji8bEEgOASCCAcOMdxgquRmT+nvVC03rK+m3MPg3irywDlHUEAlT2IIJGVOe3cE98Zr9QH 6D82ftHsn8NNyqvVH82e4vuF3/DyV9vWX8z+6/7tvv4WWtdf0/8A68cJ/u5rf8zCzKPpd+czbv3+ 0/iI6xJ6Nfng2p/eVj/FRVtBPGwrHDIxhBvTo5j2o9jk/wAlRfZc2UZVdSrjIPoa39dEkUpIAQfQ 9xURvUH6PeM+Z6Kxk1NLUadyGMDz0+0VEJlcKadEVWhsxCajTiIvRHEVqlZ7K1yoisdBfVPoLtDq Dpss1jbx2uqgExzRqEDN6LMqjDqx7FiC6+anAKmtnWj2Zdh9UtInn021jstaAJiuIkCBn7kLcKgx IjHsXIMidipIBRqEq6fuPEPIIZsV0jX920DZHNcx3sWDMhGcMoSIi9HMVWPG9vu17HOReqOXrmRa XWvbD3StxCTBqNlMf2rJGxDKfmCQVYeTKSDkGseLG83N003ot3blrfVdOnPY+aSxMVZWHkVJBVh9 FlJByDWxpabCTl7033uxasJ7ZvIPDs+TURBO8ho0ufUHa2Oi/wB3jM9Rr0/xMXNZb3VX330ludV0 VT4l9YSmNR3IklgYBP2q54/tFbgahrT9Suhl5re3lPi6jpkzRKO5WSa2cBP7SyHh+0VraalYVFPt es2uw1f1qhq9hhWF5Sr0RbaICSMkqL7+39UbXj9/b78yM0O6sbDW7O91WHxbaOWN5I/141cF079v iUFe/wA6wt25e6bpm4rDUNat/Hs4p4nmi/8AcjSRWkj79vjUFe/zq67c+R/Qz6mNeqdQv9wqNfmR xsZQTTVptGu9WcqIngBOkRkiNZ79rgq4gXKiKiKrWuTQ/cG7fZu6waVBoWqX8cEigeExRraSH/dW SSPwgPQoS0Z7HBIBGqu6N8eyT150W221rOpxW8qgCFzG1pLbn9RJZYhAF9ChZ4icEAkKwlNwZwXx 5wTqxqPj9s2WC5kMtbO/tZo7G0vHdnaF7yjYwfjYxVRjRMaxEe5eiq5zlmjpv022r010VtN2uGZZ SHeV2DvIcfCSyhV4gfRCqFGScZJJsJ0k6R7K6Q7efSNmB3SdhJJNI6vJMcYUllVU4qp+AIqqMk4J Zic15IlSrTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpVU/xOP9yP/Uv/AGDL geyj/X/+F/7mq1+0N/U/+I/6FY79DnGWtcvaR6htG2kHfBsw60+JNGxHTKaUxNg+XmR1X8iCcvX/ ACc1XMd1a5yL03X/AHXqmytf2zuDSG/nIzdclP0XQ+7ckb/dYf5HDDuAa8Lo7t7T90aPrujakuUc W+D6ow8fi6/aD/mMg9iRUM+RNB2/hbkCw1W889dfa5PZLrbSE98dkwbX+SJYQyp0d2v7Wva5FRzH NVq9HNciTltncei7623FrGn4e2mUhkbB4nGHjceWRkgg9iO4ypBMT67omqbS1x9NvMrPEwKsMjIz lXQ/I+YPmD2OCDUs+bPUXF5z9LWqQbo4A8i6rydWx9miJ2iW2F9IvGCswsT27S9EQrWp0GXqnRrX j6w3sPpjL0/6uXlxYKTplxaSmJvPgfGtyYmPzXzQn6SepKtiTd378j3j04tobtgL+G4jEg8uQ8KY CQD5H9ID6LfIFa+/w3/1w2r9qZ38vRZ+ftQ/UCz++R/gXFf30D+uFz92f8WGpWfEg/Q/Vf3Wg/xF 7kP+y99f7z7nJ+Pb1JXXz6n233lPwpqin8N/9cNq/amd/L0WTB7UP1As/vkf4FxUa9A/rhc/dn/F hqVnxIP0P1X91oP8Re5D/svfX+8+5yfj29SV18+p9t95T8Kaq2vTDwjD575Ldp9pby6amrdfkbLc Sa9rHWRQANFjIKOr0cxr3EmB+5zXIjUcvaq9Ey0nVjf03Trav5btIRLO8ixIGzwDMrvlsEEgKjdg QScdxUA9O9oRb13D+SrmUxxIjSOVxyIBVcLnIBJYdyDgZ7U9T3CMPgTktun1dvLuaay1+PstPJsW sbZCAc0qMopCsRrHPaSGb7mtaitVq9qL1THSff03UXav5bu4RFOkjROFzwLKqPlckkAq69iSQc9z TqJtCLZW4fyVbSmSJ0WRC2OQBLLhsYBIKnuAMjHasy+lH0j0HPmobRt+z7NdUsWuvH6xTxqJkfyr KFFjyinkqVj0cNElgRBs7FVUf96e2cN1h6z6j061q00TSbSOV3jErmTljgXZAq8SuGyjEscgdvhN dX006YWO9dLudU1G4eNUcxoE455BVYluQOR8Q7DBPfuKh1tdFP0Pdtk1l03us9M2mZROsYbnAVx6 6WSOphL16t+8Pc1evVPb3ybtH1G33DoNrqyx/wA1cwpJxbB+GVA3E+h7Ng+hqK9Ss5tF1e408v8A zkEjpyHb4o2K5HqO4yK2UeM7+VtfHHH+0zlRZuy6RVX8xUb2opZkCPIIqJ/b7iL7ZlruvTodH3Rq WkW/9HBcTRr+xJGUf6Cr/wC372TU9AsdRm+nLDE5/a6Kx/1Nawuaw1ndVpvDXw86vYtOq9k5U2fY qm1vYI7KLrusfKxC04jMR4myznCXvKrXNV42MajFVW9zlRVyo2+PaWu9M1ubS9oWkUkMTFTLLzIc qcMUVGTC5BwxY8h3wBVj9qdDLa/0qPUNyXMiSSKGEcfEcARkcmZWy2PMADHlk1GD1P8Apgs/T5Z1 MyHbE2PStjIQFVanjpGsIMgSI98SWxqqxXKxe5hG9EejX/a1WqmSz0m6s2nUm0mhmhEF/AAXQHKs p7B0J74z2ZTkqSO5zUd9RenVxsa4ilil8W0lyFYjDKw7lWA7Zx3BGM4PYYqYPw4+UbKzrtu4ntZR JUfXwM2nV0K9XuhRzG8M6O3r+Q0MSORrU/J0gq/3yEvaf2la2tzZbxtECtMTDNj9JlXlGx/3uIZS fkq/KpT6C7juLi3uts3LErEBJHn0UnDr+zkVIHzZqh563f8AzP8AJ3/sv/x6pybegn5ptJ/4/wDE zVFfV/8AOJqP/B/Aiq1j0Rf+WDjH/wB6/wDkNtlP+vf52dW/4H8NDVlOkH5u9O/4348ta/eaQVSG rzfiDwriX6f/AC1jTOh1+7103YPEiq1sNRywtUnT/D8yaF+ft17cz+9myeyh6j8Lsjm9vKsef18o xx9vhrJ+7NXG64xXUmyOVvngs0ZfH6mGAz9nMp+/FUmUZtdDKM7Za66soL4jxxxUdyCklAOqt8ZX vLFkNINqI9FEjWK5XJ0I3oqOvnqCanJCo0uWNJOQJMkbSAr3yAFkiIY9sNlgMH4TntUSyewSUnUI 3dMHAR1Qg+hJZHBA75XAJ/WGO9o3oEr+CB31zZUF9sEnlMtS+G2l2qNHrmxYKvYQ761BPe2QqqMa EI5yEa1vsJjVc51SfaNueoTadBa6jbxrpAcN4kJZsyYIUS8gpTzPEAFST9NmAAsZ0Tg2Yt7LcWM7 nUipHCUKuEyCxj4kh/IcjkMB+iBkmenqA/Qfmz9o9k/hpuUJ6o/mz3F9wu/4eSpI6y/mf3X/AHbf fwsta6/p/wD144T/AHc1v+ZhZlH0u/OZt37/AGn8RHWJPRr88G1P7ysf4qKtoTNlq3/pila4HrR+ nf6z3LP0vxfLfV4fl8XTt+Y+lwfnOvT27vP5+7+/Xr19+uZKe0H7p/tj1z3LHDxI84/X8GLxP38+ WftzWG3tS+4/7fdx/k/Hh+LFnH6/u8Pi+Xr4vPP25z3q5T0RfNf6rnFPzff5fkrPs7/z8X1uz8H/ AC8fj6f8OmX/APZ08b/Yxonj/S4zefy94m4/8uMfZWoPsoeP/wCH3bvvOeXC4xn9X3ufh+7jjH2V E71LfD6stm2W03vhOTUxyXcl9jc6NayPpscckiq4pa2R0UbWkcquUBexrFV3aTtVo2Qh1e9lu71j V5ty9O3RWmJeS2c8BzPdmhfHEBj3KPxCnPFuOEWufXf2ML7XtduN39KpI1adi8tpI3hqHbuzQPgq A57mN+KqSeL8SEWurkz04c1cQV4rjkHRLClpjSEisuI82Hd1bCO/8DCnilK0Sv8AftQqtVyp7IuV Q3h0l6h7DtRf7p0xorcnj4gaORMnyBaJ3Ck+gbiT6VSPfnQ7qr0zsl1PeejvBalgviq8UsYJ8gzw vIELfohypPpUx/h9+oy9pdxgcIbRYnsNU2VhW6c6YVSv1ueMbz/LCcq/bHktYRPH+TTditRveRVn 32W+rGpadr8XTnWZS9jccvd+RJ8GUAtwUnyjkAI4+Qk4lccmzZ72Met+r6VueHpPr85k066De68i SYJlBfgpPlFKAw4eQl4lQOb5uqzQ2tUqYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTF KYpTFKqn+Jx/uR/6l/7BlwPZR/r/APwv/c1Wv2hv6n/xH/Qp8Mf/AH3f9Nf9/wAe1d/UH+K/7ans 8/1x/h/+vUqvVh6dofOmkrJqAAByJq4CStWnO7Q/U2f+MtYd6+3YXp1G5y9Bl6L1Rrid0Q9HOps3 T7XvCvWJ0y4IEy+fA+QlUfNf0gPpJkYJC4knqZsSLeWkeJaqBfwgmM+XIeZjY/Jv0Sfot37Atmga bCmVsyXXWEU8KfAkvhzYcoTgSohROVhBEY5EVrmuarVavuioqZozBPDdQJc2zho3AZWByGUjIII7 EEdwR5iqTTQy28rQTqVdSQQRggg4II9CD2IqfPw3/wBcNq/amd/L0WV09qH6gWf3yP8AAuKmvoH9 cLn7s/4sNSs+JB+h+q/utB/iL3If9l76/wB59zk/Ht6krr59T7b7yn4U1RT+G/8ArhtX7Uzv5eiy YPah+oFn98j/AALio16B/XC5+7P+LDUrPiQfofqv7rQf4i9yH/Ze+v8Aefc5Px7epK6+fU+2+8p+ FNUU/hv/AK4bV+1M7+XosmD2ofqBZ/fI/wAC4qNegf1wufuz/iw0+JB+uGq/tTB/l73HsvfUC8++ SfgW9Ovn1wtvuyfizVKz4b/6H7V+607+Iosh/wBqH6/2f3OP8e4qSugf1PufvL/hQ1VPzv8ArhzL +62xfy8zLgdPPqBof3O2/ASq17z+uGrfeZ/xXrYE4I/Q/hr9qdd/iIeZv9Q/r/rn3y5/HervbM+p +k/doPwkrXI2/XJuobXsmq2Qnhna5eyqWUN6dFR8Y7wqqf5ovZ1RU9lRUVPZc090XU7fWtHtdYtT mOeNJAfsdQ3+mcEeh7VQvVbCbS9TuNNuBh4nZD+1SR/+u1bFXC/NGmcxaZUbBr9vXLYrXC/EGv8A zLGWdBKaxEOEwOvcjEcjuwnTte3oqL/lmTvrYuu7I12bTdShbwuR8OTB4SJn4WVvLOMclzlTkEVe 7aW7dJ3VpMV9Yyr4nEc0yOSNj4gR54z5HyI7iq//AIhnMunbFV6xxXrdpBvbSp2L8T7FKrZDJkWn cGLIiAiOK1VapX/Nme9iL1Ygmd3RXImWQ9mnY+t6Zd3e79UhaKGSLwog4Klwzq7OFODxHBQpxhsn HYVCPXPdelX9tbbbsJFkkSTxJCpBCYVlVcjtyPIkj0wM+deX+Gvrs4/IfIO2NG9K2r0tmulMqKg3 Hnzo0kbUX+6oytIq9Py7k6/mnX1val1O3j2zpujk/wA7JOZQPXjHG6E/5yj9v7q87oBYzPrt9qYH 82kIjJ+13Vh/pGf/AONYL9cASC9TnI73sVrZIqYwVVOiPalDWDVU/wD6G9P+WSB0CdX6UaWqnupn B/b7xKf/AIIrjesKMvUO/LDsRER/+GMf/INWR+jPf9OqfSzr8my2Grhj0X6x+KkkTBiJUd9rYTh+ Vqr1TvDIE5n/AOyu6J1X2yrvXLbeuXnV25itbZ2N34Hg4UnniGOM4OPR1YH5Yye1T70n1vSrXpvB JPOqi38XxMkDjmR3Gf2qwI+fkO9UYACWScMcLVeY5WhExPdXueqNaif+qqmaBSOsSNI5woBJ/YKp wiNI4jQZJOB+01sxct7Xx7p2gbBacolhpph4i1dpDmRnTktkkoo0iDA1FcR5OqojW/kiK5VajVcm VezNH3Lre47a02kG9+Dc0ZTx4cO/MseyhfUnz8gCSAdB90anoelaJPc7jI90I4sCOXLl24hR3JP2 eXn2AJFTFT6bOA+aoW17JwrzDN1VtDFNZy9L5CqB/MVQ2tc9r3S0OxzYnVO3zo06jToj1V353JvO qXUXYlxZ6XvvRFuDMVRZ7ZzhyTggJwIMvrwzGG/RAHlWS22BsndsVzf7R1UwiMFjDOoyo888uQIT 05Yfj+kSfOFeh7VbaPuer7dRmKG01+7j2cRQuVHFUZGq8Sp/dpG9w3NX2c0jkX2XJ23DpFnr+h3e i6goMM0bIc+mR2P2FThgfQgEeVRJoupXOj6tbapaEiSJ1YY9cHuP2EZBHqCRWxR6gP0H5s/aPZP4 abmLvVH82e4vuF3/AA8lXM6y/mf3X/dt9/Cy1rr+n/8AXjhP93Nb/mYWZR9Lvzmbd+/2n8RHWJPR r88G1P7ysf4qKtoJ72DY55HtGxqdXPe5Gsan+aqubKsyopZjgCt/WZUUu5wB6moj+oP1g8Z8MUVj Gqrqp3HkIgHhp9WqJrLEUM6oqNLZlG5WgExeiuGrkK/2RrURVe2CuqfXrZ/T7TZYbK4S61UgiOGN g4VvRpmU4RVPcqSHbyUYJYVt60e0zsPpbpE8GnXUd7rRBEVvE4cK/cBrhkOI0U9ypIkfsFXBLLQh XwNw5e5BDCjNkbBu2/7I5znu9yzpk0ziFMRUTo1iK95Hu9msY1yr0RuZkWttr2+90rbwgz6jezH9 rSSMSzH5DJLMfJVBJwBWO9lZ7m6l70W1tw1xquozk/a8srlmZj5BQSWY/RVQScAVsbzbLVvTDwHG lWKSZevcXahDriJCEiTLczfBDH2NVe1r5UkrOquXtap1VfZM1lubzRejnTFJ7vLWunQRoeI+KRhx jGM9g0kjDuTgFsnsK3Bu7/b/AEC6OpcX3J7LSbaJDwA5SuOES4BOA00rDuTgF8nsKjLwd8QjRuTd ofqm8UIeMZU8vbrtrM2BtnRTnKvtGkyHBCgCr/gc5FG9ere5ju1r4e6ce1NtveOsnRNx2o093P8A NO0oeJj6I7lI+DH9EkcWPbKniGgXpL7aO0t+7gO3d2WY0qSQ/wAxI0wkhc+kcjlIvDc/okgo5+HK txDZh9YPIegavwJyDW7PZ1R5236rJpNXpFkDPYWk2SNWxDgD1VysjkUchxena1AovXqrUXvevO6t saN0x1W01iZGkuoHjhjyCzyOMIyr5kRtiQt5Lx884Bk32md67N0Do7rVjr9xG0t5byRW8XJS8ksi 4jdFzkrE/GUv5KEznJUGj/0xV8+z9Q3DUatYR8gfIdZYEQadzkjxJLJUtV/4IAJlX/gi5nL0ctbm 86qbfitAS4u4WOP1UcO/7gisT9lZN9A7K8v+tW14LEEuL23c4/UjkEkn7hGjE/ZmtmvNhq3spilM UpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUqsn4k+qbBbUHF+zVlXMnU2sy7iHey4 gHSGViz21bozzdqL2sd8kZve7o1HdqKvVzUW13staxptnqOraVdTKk86wNGpIHPwzMHC58yPEU4H fGTjANV66/6ZfXVlp2oW8ZaKIyhyATx5+HxJx5A8CMntnA9RT4bGqbBU0HKGzWdXMg02zS6eHRS5 YHR2WawG2jpLw9yJ3Mb86Fve3q1XdyIvVrkT/Pal1jTbzUdJ0q1mV54FnaRQQeHiGEIGx5E+Gxwe 4GDjBFOgGmX1rZajqNxGVilMQQkY5cPE5EZ8wOYGfLOR5g1ZtlUqsLVYPrl9MEi8SRzPx5Ulk2wm Im+0VbHUp7ETGo1loETU6uINERp2tRVcxGk6IrCOdbL2f+rMVhx2LuWYLCT/AOWkc4Ck9zCxPYKx 7xk+TZT1UCu3WPp095y3ZoURMo/p0UZLAeUgA9R5OB5jDejE4z+G/qOxN5H3HdSVUwOtA0Y2t/VT gcGIeZIsa2Q0InqiI9zWQjK9G9ezqzu6dzevVe1DrWmHa9joSzKbo3Cy8AQWEaxSqWIHkCXUDOM9 8Zwcc/0D0u/GvXertERbiEx8iMAu0kbAA+pAQ5x5ds+YqVPxAdVv9o4LhPoKuXau1ze4exWwYIHS ZEeGyDZxCG8bUVytY+YFXKifa1XOXojVVIh9m/V9O0nqDIuozLH49u8SFiAC5kicLk9skI2PmcAd yBUkdb9NvtR2ahsoy/hTJIwAyQgSRScDvgFhn5DJPYGoqfDf1PYU5I3Hc31UwWtA0Q+u/VjR3Chn mSLGtkMCJ6p0e5BwzOcjevb9vXp3N6y/7UOsab/Jax0NZlN0bhZeAILBFilUsQO4BZ1Az598ZwcR t0D0y+/L93qxiItxCY+RBALtJGwAPqcISceXbPmKlX8QHVb/AGjguE+gq5dq7XN7h7FbBggdJkR4 bINnEIbxtRXK1j5gVcqJ9rVc5eiNVUiD2b9X07SeoMi6jMsfj27xIWIALmSJwuT2yQjY+ZwB3IFS T1v02+1HZqGyjL+FMkjADJCBJFJwO+AWGfkMk9gain8N/VNhTkncNyfVTRa0DRD679XLHcKGaZIs a2QwA3qnR7kHDM5yN69v29enc3rMHtQ6xpv8lrHQxMpujcLLwBBYIsUqliPMDLqBnz74zg4jXoHp l8NwXWqmIi3EJj5EEAu0kbAA+pwhJx5ds+Yp8SDVNhXknT9yZVTS60fRAa79XFHcWGGZHsbKQ8BX onRjlHMC5qO6d33dOva7o9l7WNN/ktfaGZlF0LhpeBIDFGiiUMB5kZRgceXbOMjLr5pl8dwWuqiI m3MIj5AEgOskjEE+hw4Iz598eRqVfw/dVv8AV+C5r7+rmVTtj3uZsVSGcB0Y8mG+DWRRn8bkRyNe +IZWqqfc1GuTqjkVYf8AaQ1fTtW6gxrp0yyeDbpE5UggOJJXK5HbIDrn5HIPcEVJXRDTb7Ttmub2 Mp4szyKGGCUKRqDg98EqcfMdx2IqrT1EaJt9Zz/yTWSdduFnbNyDaXWvRwV5ZBLuPYzzyopIiNav l7mGYnRnXo5HNXoqKiW66Z7g0W76caVdxXKeHBbQxyksAI2ijVHD5Pw4Kn6WMjB8iDVcN96Nqlvv fULeSB+cs8jxgKTzWRyylcD4sgjyz37eYq+3iaksda4r4z1y3Asa2oOP6aktIyuRyx5EWujAOzqn sva8bk6p/lmde8r+21Td+q6nZNyhmuZ5EPzV5XZT+8EGrqbZs59P23p9hdDEsUESMPkyxqpH7iDU LfWB6QJ3J043JvGQY67r8s0Wx64QrIg9oaFiMFIjlcqMbKaxrWK16o0jGN+5rm/1J16Kdarfaluu 1N1sfcMkxSgFjCWOSrAZJjJJIIBKEnsVPwxL1T6WzbhmO4dvAe94AkjJA8QAYDKT2DgYBBIDADuC PiqD2LUNr1GcSs2nW73XbAT1G+JdVR60/Xr09kI1OqL/AGVOqKnuirl1NM1rR9atxdaRdRzRn9KN 1cf8pOP2Hyqrl9pepaXMbfUrd4nHo6lT/qBWTeLfTtyzy7ZRYmr6nZAqzERsraLmKWr1qAxV+57p L29CK1PfxhR5F/s3++cpu7qZs3Zdq82rXimYDtChDysfkEB+HP6z8VHqa6HbexNz7ouFi062YRk9 5HBWNR8+RHf9i5b7Kvi4P4b13g7Q4Gl0L3TDIRbC+uzCQMq9nEa1pZDmoq9rURjGDH1XsYNqKrl7 nOzz3/vjU9/7ik13URxXHGOMHIjjBOFB9Tkks2BliTgDAFz9n7UsNnaKmk2XxH6TuRgu582PyHYB R6AAZJyTFf1rel265WbB5I4+itm7lS1yVlzQI9oTbFCG55AvjKqo1ZAVIROxyopGOREXuYxj5d6E dW7DZ5k2vuV+FjK3OOTzETkAMGx34Pgdx9BhkjDMyxv1c6c3e5Qmv6GvK7jXi6eRkQZIK+nNcnsf pDsDkAGnGy1rY6axfT29BdVdsMihfWWNWeFYNcnt2qF7Uf1/4dMu9a6ppl9ai9srmOSEjPNXVlx8 +QJH+tVUuNPv7S4NrdQOko7cWUhs/sIzU8/SP6Rtv2Pb6PkXkajm65puuTRXNZWXMZ0K12iUFyEj IkZ6I9kZr2sI8hERCI1GNRyOc5leOs3WjRdL0W42zti4We+nUxu6EMkKMMN8YyDIRlVVT8JyzEEA NNHTDpfql/qkOva9CYrSIh1VwQ0jA5X4T3CA4JJ+l2ABBJFjfqg4Zlc5cU2GpVcsUS/rrIOy64+S 9RwjzIwziQBnJ+TSikHGjvya57HKio1UWsPSbfMXT/eEes3aFrZ0aKXHdgjlTyX5lWVWx6gEDuan rqLtOTeO2pNLtmCzqwkjz5F1BGD9jKzDPoSD6VQLtugbtodsaj3DVrvXrQJVD8tZQCBadUXp3BJ0 7CsX/C8TnNcnuiqmaNaNuPQdw2a3+iXcc0RGcowOP7Q81I9QwBHqBVJdT0TV9FuTZ6rbPFIDjDKR n9h8mHyIJB9DUsvSl6Vdx5D3Oh3Db6KwoOO9fsA3Jz3ER8Eu0vA9CCiRBPRHPE97WoUyJ2IxHojl eqIkOdYOr+ibZ0O40XRbhZtTmVkARgwhDDDO5GQGAPwL9Itgkcc1JvTTptquu6tDquqQtHYRMHJc EGQg5CqDglSR8TeWMgHNXF8vUVltPE3KGs0wUk2+x8d3dFVR1eg0kSZlbJjgZ3L7J3PI1Oq+ydcz R33pl3rWx9Z0fT15Tz2lxEg8svJC6KM/axAqyPUvSL7cHTncGgaWnK5ubK7hjXOMySwSIgyewyzA ZrVwsqyxp50qrt4EyrsoJnR5tfYRnw5sQjV6OYQT0RzXIqKioqIuYxXdnd6fcvZX0TRzISGRwVZS PMFSAQR8iK/5+L6wvtMu5NP1KFop4yVdHUq6sPMMrAEEeoIzXDa1zlRrWq5yr0RrU6qv/LPwALHC jvXygFjxUZNZi499P/MfKMwEXTeP9inAM9GvuJcB9Vr8ZFX3cScZGBTonVe1HK5ei9rVX2zvdq9L t/7zuFh0DS5XU/8AqMpSIfaZX4p9uAST6AntUm7L6M9T+oF0lvtjRp5EY/0rIY4V+1ppOMY7d8Bi x/RBParrvSt6Qdf4Aiu2S9kxNm5NsYixpVwES/S9eC9E8kWtR6I9e78nyHo170TojRtVzXaIdFeg +l9L4Tq+pOtxrEi4aQD4IlPmkOQD38mkIDMOwCrkHVb2efZo0bo1bnXdXkW61+ReLSgHw4FP0o4O QB7+TysAzjsFRSwaT/IGj0XJOl7Jomyheal2erJWTfE5GyAd3RwjiVUVEIIjRlYqoqI8bVVF/LJk 3RtzTd3beu9tauube4Qo2PMZ7hl+TIwDKe+GA7Gp+3ltPSN9bWvtoa6pa1uozG+PpDPdXUnIDIwV 1JBAZQSD5Vr182ek3l3he2mtm69Y7PqTCudXbnrsAk+rOHqvYspjEc6KTp0RzDdE7kXseRPuXK/q J0P3309vpBcWj3FiCeFxEpZCvpzAyYmx5q+BnPFmHesWeqvs49Sulmoyi6snutNBPC6gRnjK+niB eRhbHmr4Gc8GcfEcD69p227dYCqtW1m+2KyMTxMg0tSeykq7qie7RtVUROvuq9ET+/TI00rQNd12 6FjotnLPMTgLHGzn/JQcfbnsPWof0TbG5NyXq6dt+wmuZycBIo3kbP7FBx9pPYetXT+ir0g2PEBS cm8khjs3+fAdBo6ERWS26jGMiId5itVWOlFb9i+NVaMbnt7nKRyM0K9nnoPd7Dc7w3coGqOpWOIE N4CN9IswyDK4+H4SQiEjJLELqh7K3s0X3TORt+76VRrMiFIYQQ3uyN9MswypmcfD8BIRCy8mLsFs Vy19XcpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMU pilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUp ilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpi lMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUqPO ncxXNrzbyvxjsdXWV9Fr+zRtd43vYXlbIvTh1TWtiuIM/ve5iSWJsLDR/EjPLHjyvs6xSEepXP4k 5Ul75rHAlre2VDXbJyrwQzlSx1WuoJy/Nm+X1YkyTAnOkPFGiwy37ArFkIU5/qEdzDNSKfyqV1db 6sOCrmsDcVG0X9nBm0ItnqVgcZ7TKl7FXka1z5VVGbXKaewHciSfk2FWIqOSQgVa5EUr67Pz9ruu bnxYD6lDsePeSeKtj5ArrqjpbHarm4fWzNNSsdWghNKQsckPYLGUZWAIqDisL3iGIquUr2JuQDm5 U441CofUWGq7xxVtHIC24FdJknfT2OlRa90U7SeJY5g7LMe/qxyvUcdWvYiPQildrqnKOkbtbWVJ rlrMlWNZHScrJuv2VJFtoqk8Xz1VJlRxBsYnf2t+bgPOBFexPJ97eqldtuO665oVQ272aZKjQzTh VcMFdUTdiuLSUdVQUaFXQxFlSTO7XuQUcT39o3u6drXKilYk425nZvWuaLsMm716vHvHNO6cfa6G Lr8+cPb4Wv2G6irRRSofpDkvga0KwNKko8L/AJSSFgRPkgUKle3reY+O7eBuNpX3U09dodzK1zZJ rtZtY8YNjDsplRIgRHvjIk2S2ZBNHQELzEc58fta5JEdSqVzIHKei2On2G9ht5MbXakxIlqttRWN HeVckb2DWFJqZIBzxSnOKFrIpAIYinCjBu8jO5Sscbl6lNI1zj+JyDTwtq2WCTk6i4xsaiJoexB2 eil21vXQJCT6hK51hFKCPO+ZECTHG6U98MAlUsyMhFKyLt/K+h6Ja1tLs9zJg2FmBJiNi0NjcxKm M4yAbNtZMYBA10VxFUaS57wAVzHohFVruilc03I2oh34XGDrCaTdiUUfZnVEahsJkeLAlvtBxpUi aMDooBkJTWA0UxWf1BDYvRxgNIpXz1vkzSNvNr0fXbv6kbadUJu1MJtbLjPNWhPHikOZCCb8u9DS hD8EjxmVzSog18JexSvpvnIuo8aVcC32+fNiAt7kOu00OpoLHar28nnYUoocGsgAPLklUceQVWAE 9WjjleqIxjnIpXXry1oS6XX8gR7ebY63bSHwqtafXLO62CykjIcJoQKaPHfYElBfFlNLFbHUwliH 7xt8RO1SuLbc0cb0uuajtc2+lEpt8tlodSfV65aXllcz2wrCwdCZAjRiSmSGhqrDuCQTXtJGcJWo VWjVSu2h8l6TYT6yrh3Xmsbfa7XSYEP6bLZIfZUjJRLMBGqJPEwLYZnIcvaEiOD4yP8AOHyKVxWc ha/ATk2bcbNWkrePtnBRWw4tBNhS9cIeko7MVeZznk+oyTfV45xEhDajm2UeK0TzhI8qlfmo5a0K 71S23SDbzR0lDPfU3QrPXLSj2Kqms8PSBIppMcdgyWT5mL4orgIY3zYPGx/lH3KVxScz8cA0K05K l3sqv1OklJXW5bPXLSrv6yY6QGKOAelLGbYsmFNJjDFDdHQ5XSgowbvIzuUr0Olb5q/IVXKttWmz ZMevsyUtpEtaOfrF5TTBDEV8WdWzQhlxjIM4CeM4mOVhxvRFa9qqpWNIfKV7deo6+4fq44oGvaLx tW7rs8200W9JJv5NzKso0WPW3K+KsCKO2CIjnL806W80oIUY+vnKJSvb6hyvoe+WljT6vcyZ86tE 6V/tVDY00O2jsMsd8yqlSQDDYxWl6DdKgPOFrnsRSIrmoqlc3j3kbUeVNZhblo1hNttZsxiPW2sq hsKANkM0YEoZo7JgAvKNRyBp5GNVqPQg1VCCIxilfOZyZpECws6qXd+Gyp9rqtJnwvpst8hlldji lrADaglUjDMmBcpxdwRo03kIzwG8alcaw5X0Or3KNoU65ki2SSWPFVo6Gxk0cKRLar4cOZbsA6BF lSWoigiyTjMZHs8Y397eqlcmZyZpED8Q/N3fi/Cu+U3Gd/8A/TZZPkLzYPoX0iF9ol7/AD/iWk/r D7gj+d/qEZ4zeNSvpUcjajfbjtOg1FhNm7PpRBg2mKyhsB19OQsKtsAhJYOAkRSEjW8ErBsK5z2v L2oqgOg1K/NtsdnH5B0zUILILIVzr15tFzJlAJIlKGqJTwxRoytI1o3kNdhKpXoRPHDIxGI4iEH0 FnpdpLtq/wBbuCxkilt4YwCAOUwncs+VJYKkDKFUqeTqxbClW8a5v7lNctNLhC8JI5pHJBJxGYkC rggAlpgxJDDihXGWDL8ovKOhTJNBDBsUf5naNbk7dSBNFkRnyq+H4klHf3jTwqPyt6iN2E+0n2f0 ydv9zbR3HBFczSWp4QSpBIQVOJXzwUYY8uWDhk5L3X4viXP8x7j0WWSCJJxymjaVAQwzGmOTHIHH Ge4bDdj2+FsJfJ2lQY9DLk2ktkXY66NbwZI6CxOCHEmIny0qxewCpAERVVqEneFvcx7evVjkRDtP XriW5hiiXnAzIwMkQLOn00iBceOy+ZWHxDgg4wwJ/wBl3DpEMcMskh4yqrKeEhAVvotIQp8JT6GX gMgjOQcdHZcpVuv8j3uobDJBBrIWm0Ow10kNbLmy2ksrDYYc0s0gkeMMMKVcBPmCtGMTpK+Qv9Qa N++12jdalti31rTFLzNPcRMC6KMRRWzoIwxVnlfxZPgUu7hBwT4WJ+K43Hb2OvzaXfMFjWKGRSFY nMjzo5crkLGvhp8bBVUt8TfEoHpJOxWETkem1MiQiVN/pNlsMNWRSDsIcmonVUaQhDKVWPGZl1G7 GINrhuiFVXkQjWj8yLTLaba8+sryE0NxFE3ccWWaOZlwvHIZDA/IlyGDqAqlSW9CS+ni16LTWwYp IZHHY8g0Txq2TnBDCZcDiCCrEk8gF4W/cp6TxmOudt1hZhPbMkmrq6h1a23O6lBhtG+ZJSBXRpEh I8dDBU0hRoIXmH3vb3t6+BXr10Oyc98VarD1CdZbHMmA3/V5W66W3WdVuN0lbJVwmVpZUyKCvinK 9gx20Aqp29yiK4iIrBFcxSu1u+YuN9fotV2WfsrD0m7w2WmrTqSrm7KlvCfGZMWxaOGEr2QhgIMx ZpGtjhGRrikYjkVVK/XDG5WfIvD3E/IN2CBFud741otyt4tUIgKyNKtKuLOkDjMI95GiaQ70Y173 uRqIiucvVVUr4arvzpmsbXuG1Hraymqt5v8AX65sOIdTx4lLcyqEaG+8jpMiTIgGKxAMYqpMAFon vYpC8bou52uNHvde1pkjt47m6iTirZCW9w9sOXdjJJJJEzqEVciRIlRmXk8f7e3i11oGo7m3C8cV rFd3kKcVfIjtbqSzXl8TmWWWWFnURouRLHCsbOpeThXfKsA2oRtn04jZrk5I1vRbOJfU0+ln1a22 yUtTNFJgSGglAkMjWimG0zG+7wvVj2ORHfNqO9bV9BTWNAPM+92ds6yxyxsnj3dvBIrxSCOVJFjm 5oHUdyjlWQ4b5NV6h2cm2o9f2w3M+/WFpIs0U0Txm5vrW2lWSGUQzRyrFcc4xIo7mNyrocN6mZyH qNfs4NQlWZx3hyBArWVE09TFNIaro0aTZNCsMEg6dFFHOVhSo9nYx3c3r7VxurQrXWF0GeYi5JUf 0chRWfuiPMEMUcjj6EburvkcVORnobreu2rPX02zcXBF2xVe0cpjVnGY45JwhgjlkHeOKSRZJAV4 K3Jc/eTveqQ/rXzFr4/w9t1Zolx/sMl/ydrc/SPpsX2Gvf5vrtV/VZ3DZ819729hOz9Jty6JB7x4 s+PAnhtpPhf4Z7jwPBTsvfn7zB8S5RefxMvF+P6z7v27be9ePcY92ubezl+CQ8bi6928CPsvxc/e 7f41zGvifGy8H4+I5G5ep9QmVuv1soMnapu6atrpoUmonSqyOG92CsrpAyTRtSOKX8lKlyQgIZCK gUJ4iDa5F5zdm+7DQZ4dLtHDXr3FlEVKSMgW5uoYmBkUCNZfBd5I0Zw5Ch+DICDym9+pembauYNF sZA+ovdafAUaOVo1W7vYIHVpUAiSfwJJJYo3kDkKJPDeMEH1dTsljI5D3XTpyQSRaXXqPaqc8WKS NIZHtiXEN8eS5xXtKRh6OQVCDaJEHLExWK4biE9ux1e7l3VqOgXPEpFFbTxlVIPGc3EZRyWYMwe2 dgyhBxkVSpKl26HTddvp966rti74GOCC0uIiqsrBLlrmIpIS7B2WS0dw6rGOEiIVLIXfo9+5t404 xnjrd0v5dbJ+msuproWs22wxKGCQz447C2kQ4xhV8RxBGYkqc4IVUBej/sf06Wuvr+bVzfxjpO1p pOy7FIgbIlRA2GTDFrlpZRayvspc6BEsJ0wEZ8aLFWRXShPkyCDEFyCQrx+YPkUptXN/GOk7Wmk7 LsUiBsiVEDYZMMWuWllFrK+ylzoESwnTARnxosVZFdKE+TIIMQXIJCvH5g+RSv5u/OHGXHV8DWtu 2CXX2xKZmxzGQ9Ytr6DQVpJD4o7G4mRIxY9bEeYRhtk2BACcsc3R6+N/apWWMUpilMUpilMUqPM3 h26mu5smstKuuvdw5Xr+VeL7oHlkm1idV6hqlHFJNYrGr0fKopwzhC5zTQZrhq9FMRjFK4HFnDez 6R/q2/Vp9DI/0O+mqfw3s306VIL89ZyvwD4zwO8DO+Kn4WsOry+In9aP0Evc/wAalfnivhjZNG/1 bfqkzXz/AOh302T+Htm+myDl+etZf4CVkiB3gZ3xv/tey7iF8RP68f8ApL3E8aleU1/hvlzRqv0z l1h/G9xecL+nedw7tEK/urKuq7WbNDo4kk18oUEpECJ2szCq4oWvI1RC8Y/M80dSsiaZw5O0m+4I WDaRbDXuHuAbjhyQeW4gbq1PKNonyMpgka4fYotWmqVXERzXnCjWvRXuYpXgvT/6ebjiO/rD2jIk uv0zjn/Rpq99K5b3PkS8uYzjVjzSEqbIzaqiEVKiG58CtEdO5g0HIEIXiIpWZuU9Q2LZE0K+1FaU 2zcb723dqmq2Seeqob3yVFxRSosmWEEgoOsa7lFGVoDdpgC6jVOqopWL9L4X3elqeGQ31jqZrXQv UJu/L+0vpiyxVsuJtAuR0ihr2PD3eVj9wrvIIqtYxoJCNMVWD8qlcidwXcWnCu08azrKKK1tOY7r lSvk01/Y6+MzT8lzN8q4j7SM0c2GR4nRIppURFLGe4rwuIoxucpXXUHBWwwuLNl18waSm3G85Tp+ XBx15E2nk6FIna9Y67Pro1nsl08ljJQzdahxinHHAwQXo0cRzhueZSvU7nqfMG+8YSIFzF41gb7E 5I1ne9foay+tCaiCPrWzUOwDrpl2+F8wUkhamQxZg68TR/NjakZ/icQqldRzBxBuu6W+/t1eRq6U fM3EcbhjepN9aS6621GFFPsL22dQEMUw5h3D2ae1Y5yRGo+NGd51TuZilZRq9MsoXMW9chmNXup9 m401TTK+OMhHWoJNFabnOmPMxWIxBPZsUFBq17nOcE3cxiNYr1KwR6W9ahpf82b9T3sHZtJvt8kU XFVvVvSTTmoWzJ+xSlgyEVWFClzs99FaUSqxw6wCNVzRs6KVl3nTj+fyRpkairtf1HZjxNhi3S1W 3bDb6WjkjtMiFrb+ra+bVzRuIxzJgRG+xDCUfQyvYpWKbPgzkS94d4s13adjfs/IPGm4SNxa6Pyl smjMt2libBVxKom5QBJcokODeiCtj4VNNdWopxIkkrUUr0mtcKXNFR+nuuYmvQn8Ycp3PJG2xY9/ ebEKQt1Q7vDO2JYWZJM6bI+f2kBSSJpR+VGSCtaH+nFRSux13hy4pvUFuXKR7atNpttQqbWtdG0n 1KqvLMNRC2CWRFYg0ESNrFF4VY9XeSTYqrWeRXFUrj3PDuxWMbmtwbCmZM3fm/V+Y9MYSRIbG7tW rNBSPCtHILuE2RO044yOAhu2PKY9Ec/uC1SubuOg8icrcUXur767VaHZZu1VWzU9boe03UOvrxUd vVXUOCTY2Cjz0Kc1Y9j7KHGikjsltUQXEAhCqV5Ok4Nu4nDXI+mWGuaJL2HkPY3bHZUGzb/uPKVB PVoaqGwVhs1mf6sWR8tVBYKfHFHbEeyM8cMjgOU6le/4E0fetA1C1pN5swSnm2qTY6tRx90teSB6 VUkDFYCq/ENmAM+w7TClyELJE1w2zWgb1GBjlUr0lVptnB5h3vkEp4DqbZ+NdT02BFGUi2gZVFab pOlkMxWINBPHscFBua9zlcI6OaxGsV6lYt4e4g3XS7Xj9u1SNX+jcM8TS+GdFk6/aS7Gz26BLPrz 1s7cBooWQ5DBaxAZ8uEktrnyZDvOidrMUrKPC+mWXHHDvFHHt0avk3Oi8a0WnW8mpIQ1XJlVlXFh SCRnkYN7hOIF7mOexjlaqKrWr1RFKwRa61D2n1i0ljSXsGdXaVoY73kyghPSU+mvoQ7CFqaTu1Va I0iBuF9JaInR7mVsQnTtaF2KV6bYeIN1st12YUGRq/8Ao+3rlnU+Zr+2lWksO5Us/U26wgqyHXti ujnjy3alWq6QSUFwklykQBerVxSvP7hw7yzZbfuYdfPx4uhb1zxoXN1nZW9tZRdur/wqbSRT6kME cMkd/lFpwpAZbpDf6khwHga1UksUrOOiaZZavtXNF7PNXljcjclRNxpWQyEJJjRY+n6pr7hy0cxq NL8zRzHo0avb4iiXuRznsYpXAtXBq+bNNlFMwLNq49u6BHSzorCy66bUTocaG1y9GFJHkXJitF0c Ydcxz+5IzFZ2dmHu9hX0SKSbe5t5PhHkksc0bu+PNVdYEQt2RpSFwZW5czclbfd1pIxwJoJk7nze N4nRUB8mKNKzBe7LGC2RGMYW2H05bTak20sHYKWGSftni1QvkkDLUa1YrereQ3q0a9sh34qukA0f Vn+yV/V7Oz+n3em9T9ItFskuLaRgkOZhhcPdRe7+7yDLd0HucHiE4b458KeXxclfbD1K4N00M6KW l/mj8Xw28njeMh7dmPvM3ADI+CLJGPh9zydw1N2+/kWNUGJJr7zUIOjW1bN5A2TSqmuhwpNkbyPr 6kg22jSMtTDWLKKBrUCnaVEIRM5/ae+YNF05bW8ZllinkuEdba1ndnkSJcCS5VzblTCreJGkhJY8 kJVa9fcO05dUvWntwDHJEkLKZ7iFVRGkOSkBUTAiQjg7IAB2Ycmrn77xxuGy7Jvhas2tN1rkfi+u 4yuCz5sqNfU7AydkdMnRWMA8ZFaG6YgwueNCE6q4gkEiG+bbu6NE0rS9OW7WX3uyu5btAqoY3LLa hI3JdWUF4CWcK3FcAK5clP31rQNU1C/vWtzH7vdW0du5YsHQBrgs6gKQcLMOKkryOSWUKA3fXhA2 XNnH9W0qPdrmi7Dtc0cUnZKhlkSaasrklK37vBIGW6VgX/0ylrUf2q+K1zPO09XtdhaldlcCe4to VJHZgqTyy8M9ucbCAFh8SJLxyFmIb7bwpcbusbcH+ihnlOD3BZoo4+WO/FwZsKfhZo+WC0YI6Hm7 SOUt0fq4dA2UFVTxmTwbTTv3G14+kWBJCRGwJzLStASY9sJBzu6AMkVJKzGKssKhaq8XXUV0nFvD WzaSvpsW3m0EleG/TXP4d2Ra+TIMs20lJoSDkQO8DO+KiatYo4hfET+vH6CXuJ41K6XXeGuRtL07 05D1+VpFjufEPCa8L7HGu504WrShTa/WxTrGEVkVxjOjytaivEAogfMBOZjixlcjkUrM3DGm2fHX D3E/H12eBKudE41otNt5VUUh6yTKq6uLBkEjPIxhHCcQD1Y57GOVqoqtavVEUrGmn64XY+JLHSqu bEHcaDytNBEBNlOIRhNa3RbqlDalajzd82HFqzHkPa8xWWPnchXE6viLQdJfVtjS7ds5FFxZX0gU MxJzaah7xbrOw5PymiSF5JGDSOsvjEOX+KCds6HJrfTebaunyqLrT9RlCh2JPKx1U3Vqtww5PyuI I7eSWVg0siz+Owdn+L293re/7lqEaBsjdPq7wXI+tbUKDST5s+pr66k2OluDx3TigGSTIeOulqwi Ro7FeYQ1a1GuM7otR0jdGv6Elrq4t47kXdnOFjaRkWK2u7edlMjIrSSFYn4t4USlmRCoAMh6vVdC 3lujbUdnrgtYrsX1hcBInleNILS+tbl0Mrxo0srJBJxbwIULMkZVQrSt0tzxttE7ab0cU1B+Ddt5 F13k+4sZFhJFs9XM11tCg4EaGkdwShkLrkFXGfIE4aSJCeIn2rnn6htHWbnWrlYGi/J9zd2l5I5d xMkloLbESRiMo6SG0jy5lQpzk+B+1eVqmxdwXe4btLdofyXeX1lqErs7i4jlshZ8YY4hEY3jlNjD mRpoygeUCN+xrptl405EnbJs4qY2mLqG28u6hyrPnWVjOj7HC/DxdVHMrhRGRnhf5B6yMwpCmb95 lE4SIvnb5+sbQ3Xc6veJp7W/uFzf2F6zO8gmX3U2QkiVBGyHktmHSQyD4mMbIAfEXzNe2Hva712/ j0trX8mXmpaZqLvI8qzp7k2nCWBY1haNuaWAkjlMo+JjE0YB8ZeTtvGG7WOwXX0GRqq61tHKeoco 3Mm4lyw3sEmuy9dbLgxQsA8bmmja+AozOK3oV5BuH2l84/113Z24rvVLj8mPB7ncXtheyGRnEim0 e0DxoqoykPHaqyuXGHLIVw/iJ++5Ng7rvtZuvyO9v7jd6jpmoStK0gmRrGSyEkUaLGyESRWSOjmR cSFo2TjJ4qelpyBtueN4kiM0w9Q41odfV0MvaIM2zn3U+bFmdq9HmFGjUhxML1cAdk9zEakt6v8A XsGjvupmpTI2Ra2drF8J7CSaW4lkSTH0nWNLZ0DZMaTFlwJ25e7pjxaj1f1aeNuS2dhZw/CewluJ rqaWOXHZpEijtJI1fLRJOWTiLhi+HPVFwtzLzHX7Rrmk7ZUwdU2bjKXqIqe03a50mJU2khtgw0+W KuiFfagkiPBjrFkmEECRSPUUtCvAvf1J9dRyZpu6chc385aHrf4WDQ736ZNN0jdbO8nSodzRQbS6 5OjEnVTBRyskHGJZTUjGfHY55Av87fEoyKU5M03dOQub+ctD1v8ACwaHe/TJpukbrZ3k6VDuaKDa XXJ0Yk6qYKOVkg4xLKakYz47HPIF/nb4lGRSvWc/8Nchb/s1NsvHCadQ7LW0Tain5HLuewaRu2kH +cWQ47o8ERod/BRqtc2msmgD5Gm7jubIcg1KljilMUpilMUpilMUpilMUpilMUpilMUpilMUpilM UpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMU pilMUpilMUpilMUpilMUpilMUr//2Q== --=_f11bac9d6d5732d2e9749468ed5085cf-- From Axel.Nennker@telekom.de Mon Oct 8 02:18: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 0BD5B21F8549 for ; Mon, 8 Oct 2012 02:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.159 X-Spam-Level: X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, EXTRA_MPART_TYPE=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k697dzvqvtkA for ; Mon, 8 Oct 2012 02:18:43 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 20BD021F855B for ; Mon, 8 Oct 2012 02:18:34 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 08 Oct 2012 11:18:33 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.163]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Mon, 8 Oct 2012 11:18:32 +0200 From: To: , Date: Mon, 8 Oct 2012 11:18:31 +0200 Thread-Topic: [jose] Example DEFLATE vectors for JWE? Thread-Index: Ac2lLdB0fS/aLQTLS1ihyF12UrUT8QABloBQ Message-ID: References: <20121008012018.cc40c4f3d92d2001859047cd8cabb9ab.335b22f95d.wbe@email07.europe.secureserver.net> In-Reply-To: <20121008012018.cc40c4f3d92d2001859047cd8cabb9ab.335b22f95d.wbe@email07.europe.secureserver.net> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/related; boundary="_004_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [jose] Example DEFLATE vectors for JWE? 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, 08 Oct 2012 09:18:44 -0000 --_004_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_ Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_" --_000_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBKVU5JVCB0ZXN0IGZyb20ganNvbmNyeXB0by5vcmcgaXMgaGVyZToNCmh0dHBzOi8vY29kZS5n b29nbGUuY29tL3AvanNvbmNyeXB0by9zb3VyY2UvYnJvd3NlL3RydW5rL3Rlc3RzcmMvb3JnL2pz b25jcnlwdG8vSmNCYXNlVGVzdC5qYXZhIzEzNjYNCkFsdGhvdWdoIHRoYXQgZG9lcyBub3QgY29u dGFpbiBmaXhlZCDigJxzdHJpbmdz4oCdLg0KDQpCZXdhcmUgdGhhdCBqc29uY3J5cHRvIHVzZXMg dGhlIG5ldyA1LXBhcnQgandlIGFscmVhZHkgKElWIG1vdmVkIGZyb20gaGVhZGVyIHRvIHRvcCBs ZXZlbCkNCg0KVGhlIEpBVkEgaW1wbGVtZW50YXRpb24gaXMgaGVyZToNCmh0dHBzOi8vY29kZS5n b29nbGUuY29tL3AvanNvbmNyeXB0by9zb3VyY2UvYnJvd3NlL3RydW5rL3NyYy9vcmcvanNvbmNy eXB0by91dGlsL0NvbXByZXNzLmphdmENCg0KVGhlIGNvZGUgd2FzIGJvcnJvd2VkIGZyb20gdGhp cyBwb3N0OiAoY2xhaW1zIHRvIGJlIGNvbXBhdGlibGUgd2l0aCAubmV0KQ0KaHR0cDovL3N0YWNr b3ZlcmZsb3cuY29tL3F1ZXN0aW9ucy82NzE3MTY1L2hvdy1jYW4taS16aXAtYW5kLXVuemlwLWEt c3RyaW5nLXVzaW5nLWd6aXBvdXRwdXRzdHJlYW0tdGhhdC1pcy1jb21wYXRpYmxlLXdpdGgNCg0K aGF2ZSBmdW4NCkF4ZWwNCg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpq b3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWbGFkaW1pciBEemh1dmlub3YgLyBO aW1idXNEUw0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDA4LCAyMDEyIDEwOjIwIEFNDQpUbzogam9z ZUBpZXRmLm9yZw0KU3ViamVjdDogW2pvc2VdIEV4YW1wbGUgREVGTEFURSB2ZWN0b3JzIGZvciBK V0U/DQoNCkhpIGd1eXMsDQoNClRoZSBuZXcgREVGTEFURSBpbXBsZW1lbnRhdGlvbiBpbiBvdXIg TmltYnVzIEpPU0UrSldUIGxpYnJhcnkgc2VlbXMgdG8gYmUgaW5jb3JyZWN0IGFuZCBJIHdhbnQg dG8gZmluZCBvdXQgd2hlcmUgdGhlIHByb2JsZW0gaXMuIEl0IHdvdWxkIGhlbHAgYSBsb3Qgb2Yg d2UgaGFkIHNvbWUgZXhhbXBsZSB0ZXN0IHZlY3RvcnMgZm9yIHRoYXQgaW4gdGhlIEpXRSBhcHBl bmRpeC4NCg0KSWYgYW55b25lIGhhcyBiZWVuIGFibGUgdG8gY29ycmVjdGx5IGltcGxlbWVudCBE RUZMQVRFIGluIEphdmEgNiwgcGxlYXNlIGdldCBpbiB0b3VjaC4NCg0KVGhhbmtzLA0KDQpWbGFk aW1pcg0KDQotLQ0KVmxhZGltaXIgRHpodXZpbm92IDogd3d3Lk5pbWJ1c0RTLmNvbTxodHRwOi8v d3d3Lk5pbWJ1c0RTLmNvbT4gOiB2bGFkaW1pckBuaW1idXNkcy5jb208bWFpbHRvOnZsYWRpbWly QG5pbWJ1c2RzLmNvbT4NCg0KDQoNCltjaWQ6aW1hZ2UwMDEuanBnQDAxQ0RBNTQ1LjZBREMyMDcw XTxodHRwOi8vbmltYnVzZHMuY29tPg0KDQo= --_000_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJw bGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+QSBKVU5JVCB0ZXN0IGZyb20ganNvbmNyeXB0by5vcmcgaXMgaGVyZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PGEgaHJlZj0iaHR0cHM6Ly9jb2RlLmdvb2dsZS5jb20vcC9qc29uY3J5cHRvL3NvdXJjZS9i cm93c2UvdHJ1bmsvdGVzdHNyYy9vcmcvanNvbmNyeXB0by9KY0Jhc2VUZXN0LmphdmEjMTM2NiI+ aHR0cHM6Ly9jb2RlLmdvb2dsZS5jb20vcC9qc29uY3J5cHRvL3NvdXJjZS9icm93c2UvdHJ1bmsv dGVzdHNyYy9vcmcvanNvbmNyeXB0by9KY0Jhc2VUZXN0LmphdmEjMTM2NjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWx0 aG91Z2ggdGhhdCBkb2VzIG5vdCBjb250YWluIGZpeGVkIOKAnHN0cmluZ3PigJ0uPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5CZXdhcmUgdGhhdCBqc29uY3J5cHRvIHVzZXMgdGhlIG5ldyA1LXBhcnQgandl IGFscmVhZHkgKElWIG1vdmVkIGZyb20gaGVhZGVyIHRvIHRvcCBsZXZlbCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlRoZSBKQVZBIGltcGxlbWVudGF0aW9uIGlzIGhlcmU6PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0 dHBzOi8vY29kZS5nb29nbGUuY29tL3AvanNvbmNyeXB0by9zb3VyY2UvYnJvd3NlL3RydW5rL3Ny Yy9vcmcvanNvbmNyeXB0by91dGlsL0NvbXByZXNzLmphdmEiPmh0dHBzOi8vY29kZS5nb29nbGUu Y29tL3AvanNvbmNyeXB0by9zb3VyY2UvYnJvd3NlL3RydW5rL3NyYy9vcmcvanNvbmNyeXB0by91 dGlsL0NvbXByZXNzLmphdmE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgY29kZSB3YXMgYm9y cm93ZWQgZnJvbSB0aGlzIHBvc3Q6IChjbGFpbXMgdG8gYmUgY29tcGF0aWJsZSB3aXRoIC5uZXQp PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMvNjcxNzE2 NS9ob3ctY2FuLWktemlwLWFuZC11bnppcC1hLXN0cmluZy11c2luZy1nemlwb3V0cHV0c3RyZWFt LXRoYXQtaXMtY29tcGF0aWJsZS13aXRoIj5odHRwOi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rp b25zLzY3MTcxNjUvaG93LWNhbi1pLXppcC1hbmQtdW56aXAtYS1zdHJpbmctdXNpbmctZ3ppcG91 dHB1dHN0cmVhbS10aGF0LWlzLWNvbXBhdGlibGUtd2l0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PmhhdmUgZnVuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkF4ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlZs YWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9i ZXIgMDgsIDIwMTIgMTA6MjAgQU08YnI+PGI+VG86PC9iPiBqb3NlQGlldGYub3JnPGJyPjxiPlN1 YmplY3Q6PC9iPiBbam9zZV0gRXhhbXBsZSBERUZMQVRFIHZlY3RvcnMgZm9yIEpXRT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkhp IGd1eXMsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5UaGUgbmV3IERFRkxB VEUgaW1wbGVtZW50YXRpb24gaW4gb3VyIE5pbWJ1cyBKT1NFK0pXVCBsaWJyYXJ5IHNlZW1zIHRv IGJlIGluY29ycmVjdCBhbmQgSSB3YW50IHRvIGZpbmQgb3V0IHdoZXJlIHRoZSBwcm9ibGVtIGlz LiBJdCB3b3VsZCBoZWxwIGEgbG90IG9mIHdlIGhhZCBzb21lIGV4YW1wbGUgdGVzdCB2ZWN0b3Jz IGZvciB0aGF0IGluIHRoZSBKV0UgYXBwZW5kaXguPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz5JZiBhbnlvbmUgaGFzIGJlZW4gYWJsZSB0byBjb3JyZWN0bHkgaW1wbGVtZW50 IERFRkxBVEUgaW4gSmF2YSA2LCBwbGVhc2UgZ2V0IGluIHRvdWNoLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+VmxhZGltaXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZl cmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPi0t PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPlZsYWRpbWlyIER6aHV2aW5vdiA6IDxhIGhyZWY9Imh0dHA6Ly93d3cu TmltYnVzRFMuY29tIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9d3d3Lk5pbWJ1c0RTLmNvbT53d3cu TmltYnVzRFMuY29tPC9hPiA6IDxhIGhyZWY9Im1haWx0bzp2bGFkaW1pckBuaW1idXNkcy5jb20i IHRhcmdldD0iX2JsYW5rIiB0aXRsZT0idmxhZGltaXJAbmltYnVzZHMuY29tIj52bGFkaW1pckBu aW1idXNkcy5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJk YW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM5OTk5OTknPjxi cj48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJW ZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM5OTk5OTknPjxhIGhy ZWY9Imh0dHA6Ly9uaW1idXNkcy5jb20iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iTmltYnVzIERp cmVjdG9yeSBTZXJ2aWNlcyI+PHNwYW4gc3R5bGU9J3RleHQtZGVjb3JhdGlvbjpub25lJz48aW1n IGJvcmRlcj0wIHdpZHRoPTQyMCBoZWlnaHQ9OTUgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6 aW1hZ2UwMDEuanBnQDAxQ0RBNTQ1LjZBREMyMDcwIj48L3NwYW4+PC9hPjxicj48YnI+PC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 L2JvZHk+PC9odG1sPg== --_000_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_-- --_004_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20485; creation-date="Mon, 08 Oct 2012 09:18:32 GMT"; modification-date="Mon, 08 Oct 2012 09:18:32 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQIBAQEBAQIBAQECAgICAgIC AgIDAwQDAwMDAwICAwQDAwQEBAQEAgMFBQQEBQQEBAT/2wBDAQEBAQEBAQIBAQIEAwIDBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAT/wAARCABfAaQDAREA AhEBAxEB/8QAHgABAAICAwEBAQAAAAAAAAAAAAgJBwoEBQYDAgH/xAA/EAABBAIBAwIEBQICCAUF AAADAQIEBQAGBxESEwghCRQVIhYxN3e1I0FCURcYJEdhgYbFMjhxhbYlJjNSgv/EAB4BAQADAQEB AQEBAQAAAAAAAAAHCAkGBQQDAgEK/8QAShEAAgEDAwIDBAUHCQYFBQAAAQIDAAQRBQYSByETMUEI FCJRMjZhdLMVN0JScYG0FiMzRXJ1hJGhF2KDosPEGCRDU7E0gpPB8P/aAAwDAQACEQMRAD8A3+MU pilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUp ilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpi lMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpil MUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilVmfEk3DY6XXuMdXq raZX020yriVfRYZ3Rks/kG1jYwzK1UVw0WaZyjXq1XIxVRVa1UtX7Lmi6Zfalq2rXkKvPbiARlgD w8QyliufJj4ajkO4GQDgnNe+vuq39pY6dp1tKVimMpcAkcuHh8QceY+MnHlnB9BUUvSR6nbPh/bI 2t7bbTZfGOwFZDnAlHfKFqhnL0HPjMVV7Boq9DsZ07mL3dHOG1FmHrN0otd7aO+qaNCq6tCCykAA zL6xuR5n1jJ8m+HIViRGnTDqJcbV1NbDVJS2nSkAgkkRH0dR6D9cDzHfBIAq9sJgyQikRzCkR5Am mAcJEKEzHojmvY5PZWqioqKnsqLme0kbxSNFKpDAkEEYII7EEHyI9RVzUdJEEkZBUjII7gg+RB+V Qi+IFtN/rHBcFlBaTKl2xb5D122LBO6MeTDfBs5RAd7VRyNe+IHuRF+5qK1eqKqLPfs36Rp2rdQZ G1GFZPBt3lQMAQHEkSBsHtkB2x8jgjuAaiDrfqV7p2zUFlIU8WZI2IOCUKSMRkd8EqM/Mdj2JqK3 w39s2FeSNx0x9rMLrR9FNsf0k0hxYYJkexrY7DCYq9GOcOYZrlb07ujOvXtb0l/2odH03+S9jrqw qLoXCxcwAGKNFKxUkeYDIpGfLvjGTmNugep3x1+70lpSbcwmTiTkB1kjUED0JDkHHn2z5Cs7/ET3 jdNY0fSKPXJ1hVUe2W04Gzz64r4pT/LCjOiwnlb0VBm80l7mdU7/AJVOvVEVFjz2ZdA0LVtf1DUN UjWS4t0jMKsAQOZYPIAf0l4oAf0efzIrs+u2savp2j2dnYOyQzM4kZSQTxC8UJHo2WJHrx+Wair6 At53WBzTA0qBPsZeobDUzz7BVEM89dAWNFIcE1o1XtG/zMCBXp07kk9F6/b0mD2jdv6DcbEk125j Vb2F4xE4ADNycK0ZPmw4Fnwc4K5GO9Rt0S1nV4d2ppELs1rKrl1ySq8VLK4HkDyAXPrywfSrvsoL VwKYpTFKYpTFKYpWsmvK3IC79/pM/FFx+Mvq31f6t88Ty9/k8nh6deng6fZ4P/x9n2dvb7Zq3/I/ bf8AJ3+Snuie48OHDiMYxjl5fT9ef0uXxZz3rPT+Uuuflv8AlD7y/vfLnyyc5znH9n04/R49sY7V s2ZlJWhdMUpilMUpilMUpilMUpilY75evbLVuJuUNmpjJGt9c47u72qkKxCJHkw62TIA/tX2XteN q9F9l6Zym+9Tu9F2PrOsae3GeC0uJUPnh44XdTj7GANcT1L1e+2/053Br+lvxubayu5o2xnEkUEj ocHscMoOK1cbKzsbmdKtLefNtLKcZ0ibYWMp82bLI5ernkK9Vc5yqvVVVVXMYru8u9QuXvb6VpJn JLO5LMxPmSxJJJ+ZNf8APxfX99ql5JqGpTPLPISzu7F3Zj3JZmJJJ9STmuE1zmORzXK1zV6o5q9H J/6Ln4AlTlT3r5QSp5KcGsxce+oHmTi6bHladyBsUGOB6OdTTJ77XX5KIvu0kEyuCvVOqdyNRydV 7XIvvnfbV6pb/wBmXCz6BqkqKP8A02YvEfsMb8k+zIAYehBqTtl9Z+p/T+6S42xrU8aKf6JnMkLf Y0MnKM58shQw9CD3q6/0r+r7X/UBFfrl5FiaxybXRFky6YJVWr2ALETySq1Xqr/t/N8d6uexF6o4 jUc5uh/RXrxpfVGE6TqSLb6xGuWjB+CVR5vDnv2/SjJLKO4LDJGq3s9e0tovWW3Oh6tGtrr0S8mi BPhzKPpSQFiW7ebxMSyDuGdQWEyJMgEOOeXKMOPGihdIkHK5GCANjVc97nL7IiIiqqr/AGTJ+lli giaeZgqKCST2AAGST9gFWenmhtoXuLhgsaAsxPYAAZJJ9AB3Na+PqV9YG/cx7La1ms3trq/GUOS+ JS0lVKJWHvAtVWpLsnsVHkcXp3oBy+MbVanarkcR2WnV7r1uff2rz2ej3L2+joSscaMUMijtzmIw WL+YQ/AgwMFgWbF7rt7TO8ep2u3FhoN3JaaAjFYoo2aNplHbxJypDOX8xGTwQYHEsGdow6pv27aL aiu9P2u+1y0EVCpLqbMsRxVRevQrUXtI1fyVhEc1yKqKipkN6JujcW271dR0G+lgnBzyR2XP9oA4 YH1DAg+RBqAdubx3XtHUV1bbGozW1wDnlHIy5+xgDhwfVWBUjsQRV+no39RM/wBQHH9gTZQgFu+m TA1eyGhhQEO2Ydj3xJzBp9o3FQJ2vG37UeBzmo1r2sbp50B6r3PVHa0r6uoGo2jKkxUYWQMCUkA8 lLcWDKOwZSRhWCjY72Yett51m2ZM+uoBq1iyxzlRhZA4JjmCjspfi4dR2DIWUKrBVl9k71ZamKUx SmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSmKUxSqp/icf7kf+pf8AsGXA9lH+v/8AC/8A c1Wv2hv6n/xH/QqqxoDuASU0JXRglYA0hBqoBPIhHDY5/wCSOcgiq1F91Qbun5LlvTJGJBEWHIgk DPcgYBIHngEjJ9Mj5iq2hHKGQA8QQCfQE5wM/M4OP2H5Va96EPUt8yOHwdvFh/tABq3ju2mF9zDa iudUEev92Iiuj9fzajhIqdomrTz2helfhM+/9Aj+E/8A1SKPI+k4A9D5S/bh/VyLL9GOoPiKmztY f4h/QMT5j/2ifs80+zK+ig5L+JB+h+q/utB/iL3OV9l76/3n3OT8e3roOvn1PtvvKfhTVFP4b/64 bV+1M7+XosmD2ofqBZ/fI/wLio16B/XC5+7P+LDVg/rE3rVtD4Ymzdq0uq30F3eRteqqG67m1vzh RSZDJBCMVCs8Q40hyOC5pFXo1Hs7lclbeiO39X3DvqODSL97Roo2leSPHPgCqlQDlTyZ1BDBlxkl Wxgzj1U1nTdF2m8upWi3KyOsao/0eZDMGJHxDiFY5Ug57AjOajX6BOTNKv7vb9OquLdV0bZB0n4h W51k0+YlrDFJBHLHMSdIkSW+MkqO5rUMrHdzl7Gq1FdKftGbV17TtPstbu9Xmu7UyeF4cojXg5Rm DKIY4ozlUYElOQwPiIPaP+ie4dIvry60q202K3uOHic4y55IGVSpMjyOMFlIHPByewx3lz6l+bX8 Ccav3KLUBurefdg1ujhSyuFASScUiR5JCt+9RsFFO7taqK5yNb3N69yQv0r2EvUXdQ0OaYxQpG0s jKAW4Kyrhc9uRZ1GTkAZODjBlDqDu87K2+dWjiEkrOsaAkheTBmy2O+Aqk4GMnAyM5quVfiS8tfI sGmj8dJZIRVfLUFmsFzOidrUj/N9yKnv1d5VRev5Jlnv/C5sz3gsb+68LH0cxcs/2vCxj7OH7zUD f7ftzeCF9zg8T54k44/s+Jn/AJv3V7zQPiTzPmvByhoERYT2OVLPRDEHIA5EVWtWFKK5Ho5eiK5D t7fz7XflnO7j9lqDwfE2lqLeJ2+C4AII9T4kajGPl4Zz8xXtaJ1/l8XhuOyHD9aEnI/+x2Oc/PmM fI15bYviUcgGsiO1Lj7Tq2oQioEWxGm3dkRqL7OcQJo7Gqqe/RGuROvTq7p1X19M9lrbcdqBrOpT vNjuYhHGoP2B1kJA+eRn5Dyrzb/r/rb3BOmWMSRegkLu2PtKsgH+Rx8zUlPT365Nc5XvIWlbvTA0 rbbN6R6WXGmOk65emX8o7XPRHgM9fYY3q9r1TtQne5rHRZ1K9n/VNn6fJr2gTm6s4xmRSuJY1/WO OzqP0iApUdyvEFhIGxusVhuW8TSNYiFvdP2Qg5jc/qjPdWP6IJIPkGyQDPXK7VNNap+bAVmvVkmw fEo5EPMI7VePdLqoHeqCFsEidfzFb19lcQJYzUVU/sjfb/Ncq5pvstbZjgA1jUp5JPUxCONf3Bll P+tT9fe0Brryk6bYwonoJC7n/NWjH+lZI4u+I7BsrOLV8s6hGoYsoiCdtGqlNKgwVVenceATvL40 /NXiI9yJ+Q3Zy+7fZguLW1e72bemV1GfBmChm+xZF4ry+QZVHzYV7+3OvUNxcLbbmtRGpOPEiJKj +0hy2PmQzH/dNWb1tlX3NfCtqmbFsqyyisnV9hCO2TDmhK1HjKIjVVrmuaqKiovRUXKpXVrc2NzJ Z3kZSVCVZWBDKwOCCD3BB8xVhbe4guoEubZw8bgFWByCD3BBHmCKrv8AUx62tm4g5Ml8daXq2vWL 9fjRC7DY7Kko/wAwSXGFMYGKMJRdiNCcKqR6v6ue5OxEb1dZjpV0F0neu1E3Nrt5KgmLiJYuAwEZ kLOXV85ZW+EBcAA8jntBXUHq9qG1twtoOk20bmIKZGk5HJZQ4ChWXGFYdyT3Pl27zP4a5Jj8vcZa nyLGr31TdjhFIeueb5j5M8aSeHJG0nRO5iGjl7XKiKre1VRF9sgvfO1pNl7rvdsyyeJ4DDDYxyV0 V0JHfB4sMjJwcjJqWdp6/Hujb1rr0acPFByuc4ZWKMM+o5KcHAyMVXE34kd8u+oxdGoU41W1+WX+ rJ/F6Q/J2fNebyeDv7P6nh8PT/B5P8eWgPsuab/J3I1CT8qcM+SeBzxnhx48+Ofh58/97j+jUCjr 7e/lrBs0/J/LHm3i8c45Zzxzjvx4/Zy9atE3Pcde4/1e63Hap7K2hoYazbCU5qvcidUYwY2J7uIR 7mDYxPdz3tRPzypOhaJqW5NXg0PR4+dzM3FR/qST6KoBZiewAJ9KsXq2q2OiadNqupPwgjGWP+gA HqScAD1JAqqbbPiT7oS4N+BtB1eFQDMrY/4rfLtLeUNF9nv+XOEYnOT37E8iN69O93TqtwdH9lrQ Usl/lBqMz3BHfweCID8hzR2YD5/DnzwPKq16n1/1dro/keyjWEHt4vJmI+Z4sgUn5fFj5mpc+mX1 dU3Pkubq1pRLq28V1c60WICUs6nuY7HsGUsYjkR7HscRncF/cva5Fa9/R3bDHVbovfdOoE1ezuPe NPduHIji8bEEgOASCCAcOMdxgquRmT+nvVC03rK+m3MPg3irywDlHUEAlT2IIJGVOe3cE98Zr9QH 6D82ftHsn8NNyqvVH82e4vuF3/DyV9vWX8z+6/7tvv4WWtdf0/8A68cJ/u5rf8zCzKPpd+czbv3+ 0/iI6xJ6Nfng2p/eVj/FRVtBPGwrHDIxhBvTo5j2o9jk/wAlRfZc2UZVdSrjIPoa39dEkUpIAQfQ 9xURvUH6PeM+Z6Kxk1NLUadyGMDz0+0VEJlcKadEVWhsxCajTiIvRHEVqlZ7K1yoisdBfVPoLtDq Dpss1jbx2uqgExzRqEDN6LMqjDqx7FiC6+anAKmtnWj2Zdh9UtInn021jstaAJiuIkCBn7kLcKgx IjHsXIMidipIBRqEq6fuPEPIIZsV0jX920DZHNcx3sWDMhGcMoSIi9HMVWPG9vu17HOReqOXrmRa XWvbD3StxCTBqNlMf2rJGxDKfmCQVYeTKSDkGseLG83N003ot3blrfVdOnPY+aSxMVZWHkVJBVh9 FlJByDWxpabCTl7033uxasJ7ZvIPDs+TURBO8ho0ufUHa2Oi/wB3jM9Rr0/xMXNZb3VX330ludV0 VT4l9YSmNR3IklgYBP2q54/tFbgahrT9Suhl5re3lPi6jpkzRKO5WSa2cBP7SyHh+0VraalYVFPt es2uw1f1qhq9hhWF5Sr0RbaICSMkqL7+39UbXj9/b78yM0O6sbDW7O91WHxbaOWN5I/141cF079v iUFe/wA6wt25e6bpm4rDUNat/Hs4p4nmi/8AcjSRWkj79vjUFe/zq67c+R/Qz6mNeqdQv9wqNfmR xsZQTTVptGu9WcqIngBOkRkiNZ79rgq4gXKiKiKrWuTQ/cG7fZu6waVBoWqX8cEigeExRraSH/dW SSPwgPQoS0Z7HBIBGqu6N8eyT150W221rOpxW8qgCFzG1pLbn9RJZYhAF9ChZ4icEAkKwlNwZwXx 5wTqxqPj9s2WC5kMtbO/tZo7G0vHdnaF7yjYwfjYxVRjRMaxEe5eiq5zlmjpv022r010VtN2uGZZ SHeV2DvIcfCSyhV4gfRCqFGScZJJsJ0k6R7K6Q7efSNmB3SdhJJNI6vJMcYUllVU4qp+AIqqMk4J Zic15IlSrTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpVU/xOP9yP/Uv/AGDL geyj/X/+F/7mq1+0N/U/+I/6FY79DnGWtcvaR6htG2kHfBsw60+JNGxHTKaUxNg+XmR1X8iCcvX/ ACc1XMd1a5yL03X/AHXqmytf2zuDSG/nIzdclP0XQ+7ckb/dYf5HDDuAa8Lo7t7T90aPrujakuUc W+D6ow8fi6/aD/mMg9iRUM+RNB2/hbkCw1W889dfa5PZLrbSE98dkwbX+SJYQyp0d2v7Wva5FRzH NVq9HNciTltncei7623FrGn4e2mUhkbB4nGHjceWRkgg9iO4ypBMT67omqbS1x9NvMrPEwKsMjIz lXQ/I+YPmD2OCDUs+bPUXF5z9LWqQbo4A8i6rydWx9miJ2iW2F9IvGCswsT27S9EQrWp0GXqnRrX j6w3sPpjL0/6uXlxYKTplxaSmJvPgfGtyYmPzXzQn6SepKtiTd378j3j04tobtgL+G4jEg8uQ8KY CQD5H9ID6LfIFa+/w3/1w2r9qZ38vRZ+ftQ/UCz++R/gXFf30D+uFz92f8WGpWfEg/Q/Vf3Wg/xF 7kP+y99f7z7nJ+Pb1JXXz6n233lPwpqin8N/9cNq/amd/L0WTB7UP1As/vkf4FxUa9A/rhc/dn/F hqVnxIP0P1X91oP8Re5D/svfX+8+5yfj29SV18+p9t95T8Kaq2vTDwjD575Ldp9pby6amrdfkbLc Sa9rHWRQANFjIKOr0cxr3EmB+5zXIjUcvaq9Ey0nVjf03Trav5btIRLO8ixIGzwDMrvlsEEgKjdg QScdxUA9O9oRb13D+SrmUxxIjSOVxyIBVcLnIBJYdyDgZ7U9T3CMPgTktun1dvLuaay1+PstPJsW sbZCAc0qMopCsRrHPaSGb7mtaitVq9qL1THSff03UXav5bu4RFOkjROFzwLKqPlckkAq69iSQc9z TqJtCLZW4fyVbSmSJ0WRC2OQBLLhsYBIKnuAMjHasy+lH0j0HPmobRt+z7NdUsWuvH6xTxqJkfyr KFFjyinkqVj0cNElgRBs7FVUf96e2cN1h6z6j061q00TSbSOV3jErmTljgXZAq8SuGyjEscgdvhN dX006YWO9dLudU1G4eNUcxoE455BVYluQOR8Q7DBPfuKh1tdFP0Pdtk1l03us9M2mZROsYbnAVx6 6WSOphL16t+8Pc1evVPb3ybtH1G33DoNrqyx/wA1cwpJxbB+GVA3E+h7Ng+hqK9Ss5tF1e408v8A zkEjpyHb4o2K5HqO4yK2UeM7+VtfHHH+0zlRZuy6RVX8xUb2opZkCPIIqJ/b7iL7ZlruvTodH3Rq WkW/9HBcTRr+xJGUf6Cr/wC372TU9AsdRm+nLDE5/a6Kx/1Nawuaw1ndVpvDXw86vYtOq9k5U2fY qm1vYI7KLrusfKxC04jMR4myznCXvKrXNV42MajFVW9zlRVyo2+PaWu9M1ubS9oWkUkMTFTLLzIc qcMUVGTC5BwxY8h3wBVj9qdDLa/0qPUNyXMiSSKGEcfEcARkcmZWy2PMADHlk1GD1P8Apgs/T5Z1 MyHbE2PStjIQFVanjpGsIMgSI98SWxqqxXKxe5hG9EejX/a1WqmSz0m6s2nUm0mhmhEF/AAXQHKs p7B0J74z2ZTkqSO5zUd9RenVxsa4ilil8W0lyFYjDKw7lWA7Zx3BGM4PYYqYPw4+UbKzrtu4ntZR JUfXwM2nV0K9XuhRzG8M6O3r+Q0MSORrU/J0gq/3yEvaf2la2tzZbxtECtMTDNj9JlXlGx/3uIZS fkq/KpT6C7juLi3uts3LErEBJHn0UnDr+zkVIHzZqh563f8AzP8AJ3/sv/x6pybegn5ptJ/4/wDE zVFfV/8AOJqP/B/Aiq1j0Rf+WDjH/wB6/wDkNtlP+vf52dW/4H8NDVlOkH5u9O/4348ta/eaQVSG rzfiDwriX6f/AC1jTOh1+7103YPEiq1sNRywtUnT/D8yaF+ft17cz+9myeyh6j8Lsjm9vKsef18o xx9vhrJ+7NXG64xXUmyOVvngs0ZfH6mGAz9nMp+/FUmUZtdDKM7Za66soL4jxxxUdyCklAOqt8ZX vLFkNINqI9FEjWK5XJ0I3oqOvnqCanJCo0uWNJOQJMkbSAr3yAFkiIY9sNlgMH4TntUSyewSUnUI 3dMHAR1Qg+hJZHBA75XAJ/WGO9o3oEr+CB31zZUF9sEnlMtS+G2l2qNHrmxYKvYQ761BPe2QqqMa EI5yEa1vsJjVc51SfaNueoTadBa6jbxrpAcN4kJZsyYIUS8gpTzPEAFST9NmAAsZ0Tg2Yt7LcWM7 nUipHCUKuEyCxj4kh/IcjkMB+iBkmenqA/Qfmz9o9k/hpuUJ6o/mz3F9wu/4eSpI6y/mf3X/AHbf fwsta6/p/wD144T/AHc1v+ZhZlH0u/OZt37/AGn8RHWJPRr88G1P7ysf4qKtoTNlq3/pila4HrR+ nf6z3LP0vxfLfV4fl8XTt+Y+lwfnOvT27vP5+7+/Xr19+uZKe0H7p/tj1z3LHDxI84/X8GLxP38+ WftzWG3tS+4/7fdx/k/Hh+LFnH6/u8Pi+Xr4vPP25z3q5T0RfNf6rnFPzff5fkrPs7/z8X1uz8H/ AC8fj6f8OmX/APZ08b/Yxonj/S4zefy94m4/8uMfZWoPsoeP/wCH3bvvOeXC4xn9X3ufh+7jjH2V E71LfD6stm2W03vhOTUxyXcl9jc6NayPpscckiq4pa2R0UbWkcquUBexrFV3aTtVo2Qh1e9lu71j V5ty9O3RWmJeS2c8BzPdmhfHEBj3KPxCnPFuOEWufXf2ML7XtduN39KpI1adi8tpI3hqHbuzQPgq A57mN+KqSeL8SEWurkz04c1cQV4rjkHRLClpjSEisuI82Hd1bCO/8DCnilK0Sv8AftQqtVyp7IuV Q3h0l6h7DtRf7p0xorcnj4gaORMnyBaJ3Ck+gbiT6VSPfnQ7qr0zsl1PeejvBalgviq8UsYJ8gzw vIELfohypPpUx/h9+oy9pdxgcIbRYnsNU2VhW6c6YVSv1ueMbz/LCcq/bHktYRPH+TTditRveRVn 32W+rGpadr8XTnWZS9jccvd+RJ8GUAtwUnyjkAI4+Qk4lccmzZ72Met+r6VueHpPr85k066De68i SYJlBfgpPlFKAw4eQl4lQOb5uqzQ2tUqYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTFKYpTF KYpTFKqn+Jx/uR/6l/7BlwPZR/r/APwv/c1Wv2hv6n/xH/Qp8Mf/AH3f9Nf9/wAe1d/UH+K/7ans 8/1x/h/+vUqvVh6dofOmkrJqAAByJq4CStWnO7Q/U2f+MtYd6+3YXp1G5y9Bl6L1Rrid0Q9HOps3 T7XvCvWJ0y4IEy+fA+QlUfNf0gPpJkYJC4knqZsSLeWkeJaqBfwgmM+XIeZjY/Jv0Sfot37Atmga bCmVsyXXWEU8KfAkvhzYcoTgSohROVhBEY5EVrmuarVavuioqZozBPDdQJc2zho3AZWByGUjIII7 EEdwR5iqTTQy28rQTqVdSQQRggg4II9CD2IqfPw3/wBcNq/amd/L0WV09qH6gWf3yP8AAuKmvoH9 cLn7s/4sNSs+JB+h+q/utB/iL3If9l76/wB59zk/Ht6krr59T7b7yn4U1RT+G/8ArhtX7Uzv5eiy YPah+oFn98j/AALio16B/XC5+7P+LDUrPiQfofqv7rQf4i9yH/Ze+v8Aefc5Px7epK6+fU+2+8p+ FNUU/hv/AK4bV+1M7+XosmD2ofqBZ/fI/wAC4qNegf1wufuz/iw0+JB+uGq/tTB/l73HsvfUC8++ SfgW9Ovn1wtvuyfizVKz4b/6H7V+607+Iosh/wBqH6/2f3OP8e4qSugf1PufvL/hQ1VPzv8ArhzL +62xfy8zLgdPPqBof3O2/ASq17z+uGrfeZ/xXrYE4I/Q/hr9qdd/iIeZv9Q/r/rn3y5/HervbM+p +k/doPwkrXI2/XJuobXsmq2Qnhna5eyqWUN6dFR8Y7wqqf5ovZ1RU9lRUVPZc090XU7fWtHtdYtT mOeNJAfsdQ3+mcEeh7VQvVbCbS9TuNNuBh4nZD+1SR/+u1bFXC/NGmcxaZUbBr9vXLYrXC/EGv8A zLGWdBKaxEOEwOvcjEcjuwnTte3oqL/lmTvrYuu7I12bTdShbwuR8OTB4SJn4WVvLOMclzlTkEVe 7aW7dJ3VpMV9Yyr4nEc0yOSNj4gR54z5HyI7iq//AIhnMunbFV6xxXrdpBvbSp2L8T7FKrZDJkWn cGLIiAiOK1VapX/Nme9iL1Ygmd3RXImWQ9mnY+t6Zd3e79UhaKGSLwog4Klwzq7OFODxHBQpxhsn HYVCPXPdelX9tbbbsJFkkSTxJCpBCYVlVcjtyPIkj0wM+deX+Gvrs4/IfIO2NG9K2r0tmulMqKg3 Hnzo0kbUX+6oytIq9Py7k6/mnX1val1O3j2zpujk/wA7JOZQPXjHG6E/5yj9v7q87oBYzPrt9qYH 82kIjJ+13Vh/pGf/AONYL9cASC9TnI73sVrZIqYwVVOiPalDWDVU/wD6G9P+WSB0CdX6UaWqnupn B/b7xKf/AIIrjesKMvUO/LDsRER/+GMf/INWR+jPf9OqfSzr8my2Grhj0X6x+KkkTBiJUd9rYTh+ Vqr1TvDIE5n/AOyu6J1X2yrvXLbeuXnV25itbZ2N34Hg4UnniGOM4OPR1YH5Yye1T70n1vSrXpvB JPOqi38XxMkDjmR3Gf2qwI+fkO9UYACWScMcLVeY5WhExPdXueqNaif+qqmaBSOsSNI5woBJ/YKp wiNI4jQZJOB+01sxct7Xx7p2gbBacolhpph4i1dpDmRnTktkkoo0iDA1FcR5OqojW/kiK5VajVcm VezNH3Lre47a02kG9+Dc0ZTx4cO/MseyhfUnz8gCSAdB90anoelaJPc7jI90I4sCOXLl24hR3JP2 eXn2AJFTFT6bOA+aoW17JwrzDN1VtDFNZy9L5CqB/MVQ2tc9r3S0OxzYnVO3zo06jToj1V353JvO qXUXYlxZ6XvvRFuDMVRZ7ZzhyTggJwIMvrwzGG/RAHlWS22BsndsVzf7R1UwiMFjDOoyo888uQIT 05Yfj+kSfOFeh7VbaPuer7dRmKG01+7j2cRQuVHFUZGq8Sp/dpG9w3NX2c0jkX2XJ23DpFnr+h3e i6goMM0bIc+mR2P2FThgfQgEeVRJoupXOj6tbapaEiSJ1YY9cHuP2EZBHqCRWxR6gP0H5s/aPZP4 abmLvVH82e4vuF3/AA8lXM6y/mf3X/dt9/Cy1rr+n/8AXjhP93Nb/mYWZR9Lvzmbd+/2n8RHWJPR r88G1P7ysf4qKtoJ72DY55HtGxqdXPe5Gsan+aqubKsyopZjgCt/WZUUu5wB6moj+oP1g8Z8MUVj Gqrqp3HkIgHhp9WqJrLEUM6oqNLZlG5WgExeiuGrkK/2RrURVe2CuqfXrZ/T7TZYbK4S61UgiOGN g4VvRpmU4RVPcqSHbyUYJYVt60e0zsPpbpE8GnXUd7rRBEVvE4cK/cBrhkOI0U9ypIkfsFXBLLQh XwNw5e5BDCjNkbBu2/7I5znu9yzpk0ziFMRUTo1iK95Hu9msY1yr0RuZkWttr2+90rbwgz6jezH9 rSSMSzH5DJLMfJVBJwBWO9lZ7m6l70W1tw1xquozk/a8srlmZj5BQSWY/RVQScAVsbzbLVvTDwHG lWKSZevcXahDriJCEiTLczfBDH2NVe1r5UkrOquXtap1VfZM1lubzRejnTFJ7vLWunQRoeI+KRhx jGM9g0kjDuTgFsnsK3Bu7/b/AEC6OpcX3J7LSbaJDwA5SuOES4BOA00rDuTgF8nsKjLwd8QjRuTd ofqm8UIeMZU8vbrtrM2BtnRTnKvtGkyHBCgCr/gc5FG9ere5ju1r4e6ce1NtveOsnRNx2o093P8A NO0oeJj6I7lI+DH9EkcWPbKniGgXpL7aO0t+7gO3d2WY0qSQ/wAxI0wkhc+kcjlIvDc/okgo5+HK txDZh9YPIegavwJyDW7PZ1R5236rJpNXpFkDPYWk2SNWxDgD1VysjkUchxena1AovXqrUXvevO6t saN0x1W01iZGkuoHjhjyCzyOMIyr5kRtiQt5Lx884Bk32md67N0Do7rVjr9xG0t5byRW8XJS8ksi 4jdFzkrE/GUv5KEznJUGj/0xV8+z9Q3DUatYR8gfIdZYEQadzkjxJLJUtV/4IAJlX/gi5nL0ctbm 86qbfitAS4u4WOP1UcO/7gisT9lZN9A7K8v+tW14LEEuL23c4/UjkEkn7hGjE/ZmtmvNhq3spilM UpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUqsn4k+qbBbUHF+zVlXMnU2sy7iHey4 gHSGViz21bozzdqL2sd8kZve7o1HdqKvVzUW13staxptnqOraVdTKk86wNGpIHPwzMHC58yPEU4H fGTjANV66/6ZfXVlp2oW8ZaKIyhyATx5+HxJx5A8CMntnA9RT4bGqbBU0HKGzWdXMg02zS6eHRS5 YHR2WawG2jpLw9yJ3Mb86Fve3q1XdyIvVrkT/Pal1jTbzUdJ0q1mV54FnaRQQeHiGEIGx5E+Gxwe 4GDjBFOgGmX1rZajqNxGVilMQQkY5cPE5EZ8wOYGfLOR5g1ZtlUqsLVYPrl9MEi8SRzPx5Ulk2wm Im+0VbHUp7ETGo1loETU6uINERp2tRVcxGk6IrCOdbL2f+rMVhx2LuWYLCT/AOWkc4Ck9zCxPYKx 7xk+TZT1UCu3WPp095y3ZoURMo/p0UZLAeUgA9R5OB5jDejE4z+G/qOxN5H3HdSVUwOtA0Y2t/VT gcGIeZIsa2Q0InqiI9zWQjK9G9ezqzu6dzevVe1DrWmHa9joSzKbo3Cy8AQWEaxSqWIHkCXUDOM9 8Zwcc/0D0u/GvXertERbiEx8iMAu0kbAA+pAQ5x5ds+YqVPxAdVv9o4LhPoKuXau1ze4exWwYIHS ZEeGyDZxCG8bUVytY+YFXKifa1XOXojVVIh9m/V9O0nqDIuozLH49u8SFiAC5kicLk9skI2PmcAd yBUkdb9NvtR2ahsoy/hTJIwAyQgSRScDvgFhn5DJPYGoqfDf1PYU5I3Hc31UwWtA0Q+u/VjR3Chn mSLGtkMCJ6p0e5BwzOcjevb9vXp3N6y/7UOsab/Jax0NZlN0bhZeAILBFilUsQO4BZ1Az598ZwcR t0D0y+/L93qxiItxCY+RBALtJGwAPqcISceXbPmKlX8QHVb/AGjguE+gq5dq7XN7h7FbBggdJkR4 bINnEIbxtRXK1j5gVcqJ9rVc5eiNVUiD2b9X07SeoMi6jMsfj27xIWIALmSJwuT2yQjY+ZwB3IFS T1v02+1HZqGyjL+FMkjADJCBJFJwO+AWGfkMk9gain8N/VNhTkncNyfVTRa0DRD679XLHcKGaZIs a2QwA3qnR7kHDM5yN69v29enc3rMHtQ6xpv8lrHQxMpujcLLwBBYIsUqliPMDLqBnz74zg4jXoHp l8NwXWqmIi3EJj5EEAu0kbAA+pwhJx5ds+Yp8SDVNhXknT9yZVTS60fRAa79XFHcWGGZHsbKQ8BX onRjlHMC5qO6d33dOva7o9l7WNN/ktfaGZlF0LhpeBIDFGiiUMB5kZRgceXbOMjLr5pl8dwWuqiI m3MIj5AEgOskjEE+hw4Iz598eRqVfw/dVv8AV+C5r7+rmVTtj3uZsVSGcB0Y8mG+DWRRn8bkRyNe +IZWqqfc1GuTqjkVYf8AaQ1fTtW6gxrp0yyeDbpE5UggOJJXK5HbIDrn5HIPcEVJXRDTb7Ttmub2 Mp4szyKGGCUKRqDg98EqcfMdx2IqrT1EaJt9Zz/yTWSdduFnbNyDaXWvRwV5ZBLuPYzzyopIiNav l7mGYnRnXo5HNXoqKiW66Z7g0W76caVdxXKeHBbQxyksAI2ijVHD5Pw4Kn6WMjB8iDVcN96Nqlvv fULeSB+cs8jxgKTzWRyylcD4sgjyz37eYq+3iaksda4r4z1y3Asa2oOP6aktIyuRyx5EWujAOzqn sva8bk6p/lmde8r+21Td+q6nZNyhmuZ5EPzV5XZT+8EGrqbZs59P23p9hdDEsUESMPkyxqpH7iDU LfWB6QJ3J043JvGQY67r8s0Wx64QrIg9oaFiMFIjlcqMbKaxrWK16o0jGN+5rm/1J16Kdarfaluu 1N1sfcMkxSgFjCWOSrAZJjJJIIBKEnsVPwxL1T6WzbhmO4dvAe94AkjJA8QAYDKT2DgYBBIDADuC PiqD2LUNr1GcSs2nW73XbAT1G+JdVR60/Xr09kI1OqL/AGVOqKnuirl1NM1rR9atxdaRdRzRn9KN 1cf8pOP2Hyqrl9pepaXMbfUrd4nHo6lT/qBWTeLfTtyzy7ZRYmr6nZAqzERsraLmKWr1qAxV+57p L29CK1PfxhR5F/s3++cpu7qZs3Zdq82rXimYDtChDysfkEB+HP6z8VHqa6HbexNz7ouFi062YRk9 5HBWNR8+RHf9i5b7Kvi4P4b13g7Q4Gl0L3TDIRbC+uzCQMq9nEa1pZDmoq9rURjGDH1XsYNqKrl7 nOzz3/vjU9/7ik13URxXHGOMHIjjBOFB9Tkks2BliTgDAFz9n7UsNnaKmk2XxH6TuRgu582PyHYB R6AAZJyTFf1rel265WbB5I4+itm7lS1yVlzQI9oTbFCG55AvjKqo1ZAVIROxyopGOREXuYxj5d6E dW7DZ5k2vuV+FjK3OOTzETkAMGx34Pgdx9BhkjDMyxv1c6c3e5Qmv6GvK7jXi6eRkQZIK+nNcnsf pDsDkAGnGy1rY6axfT29BdVdsMihfWWNWeFYNcnt2qF7Uf1/4dMu9a6ppl9ai9srmOSEjPNXVlx8 +QJH+tVUuNPv7S4NrdQOko7cWUhs/sIzU8/SP6Rtv2Pb6PkXkajm65puuTRXNZWXMZ0K12iUFyEj IkZ6I9kZr2sI8hERCI1GNRyOc5leOs3WjRdL0W42zti4We+nUxu6EMkKMMN8YyDIRlVVT8JyzEEA NNHTDpfql/qkOva9CYrSIh1VwQ0jA5X4T3CA4JJ+l2ABBJFjfqg4Zlc5cU2GpVcsUS/rrIOy64+S 9RwjzIwziQBnJ+TSikHGjvya57HKio1UWsPSbfMXT/eEes3aFrZ0aKXHdgjlTyX5lWVWx6gEDuan rqLtOTeO2pNLtmCzqwkjz5F1BGD9jKzDPoSD6VQLtugbtodsaj3DVrvXrQJVD8tZQCBadUXp3BJ0 7CsX/C8TnNcnuiqmaNaNuPQdw2a3+iXcc0RGcowOP7Q81I9QwBHqBVJdT0TV9FuTZ6rbPFIDjDKR n9h8mHyIJB9DUsvSl6Vdx5D3Oh3Db6KwoOO9fsA3Jz3ER8Eu0vA9CCiRBPRHPE97WoUyJ2IxHojl eqIkOdYOr+ibZ0O40XRbhZtTmVkARgwhDDDO5GQGAPwL9Itgkcc1JvTTptquu6tDquqQtHYRMHJc EGQg5CqDglSR8TeWMgHNXF8vUVltPE3KGs0wUk2+x8d3dFVR1eg0kSZlbJjgZ3L7J3PI1Oq+ydcz R33pl3rWx9Z0fT15Tz2lxEg8svJC6KM/axAqyPUvSL7cHTncGgaWnK5ubK7hjXOMySwSIgyewyzA ZrVwsqyxp50qrt4EyrsoJnR5tfYRnw5sQjV6OYQT0RzXIqKioqIuYxXdnd6fcvZX0TRzISGRwVZS PMFSAQR8iK/5+L6wvtMu5NP1KFop4yVdHUq6sPMMrAEEeoIzXDa1zlRrWq5yr0RrU6qv/LPwALHC jvXygFjxUZNZi499P/MfKMwEXTeP9inAM9GvuJcB9Vr8ZFX3cScZGBTonVe1HK5ei9rVX2zvdq9L t/7zuFh0DS5XU/8AqMpSIfaZX4p9uAST6AntUm7L6M9T+oF0lvtjRp5EY/0rIY4V+1ppOMY7d8Bi x/RBParrvSt6Qdf4Aiu2S9kxNm5NsYixpVwES/S9eC9E8kWtR6I9e78nyHo170TojRtVzXaIdFeg +l9L4Tq+pOtxrEi4aQD4IlPmkOQD38mkIDMOwCrkHVb2efZo0bo1bnXdXkW61+ReLSgHw4FP0o4O QB7+TysAzjsFRSwaT/IGj0XJOl7Jomyheal2erJWTfE5GyAd3RwjiVUVEIIjRlYqoqI8bVVF/LJk 3RtzTd3beu9tauube4Qo2PMZ7hl+TIwDKe+GA7Gp+3ltPSN9bWvtoa6pa1uozG+PpDPdXUnIDIwV 1JBAZQSD5Vr182ek3l3he2mtm69Y7PqTCudXbnrsAk+rOHqvYspjEc6KTp0RzDdE7kXseRPuXK/q J0P3309vpBcWj3FiCeFxEpZCvpzAyYmx5q+BnPFmHesWeqvs49Sulmoyi6snutNBPC6gRnjK+niB eRhbHmr4Gc8GcfEcD69p227dYCqtW1m+2KyMTxMg0tSeykq7qie7RtVUROvuq9ET+/TI00rQNd12 6FjotnLPMTgLHGzn/JQcfbnsPWof0TbG5NyXq6dt+wmuZycBIo3kbP7FBx9pPYetXT+ir0g2PEBS cm8khjs3+fAdBo6ERWS26jGMiId5itVWOlFb9i+NVaMbnt7nKRyM0K9nnoPd7Dc7w3coGqOpWOIE N4CN9IswyDK4+H4SQiEjJLELqh7K3s0X3TORt+76VRrMiFIYQQ3uyN9MswypmcfD8BIRCy8mLsFs Vy19XcpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMU pilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUp ilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpi lMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUqPO ncxXNrzbyvxjsdXWV9Fr+zRtd43vYXlbIvTh1TWtiuIM/ve5iSWJsLDR/EjPLHjyvs6xSEepXP4k 5Ul75rHAlre2VDXbJyrwQzlSx1WuoJy/Nm+X1YkyTAnOkPFGiwy37ArFkIU5/qEdzDNSKfyqV1db 6sOCrmsDcVG0X9nBm0ItnqVgcZ7TKl7FXka1z5VVGbXKaewHciSfk2FWIqOSQgVa5EUr67Pz9ruu bnxYD6lDsePeSeKtj5ArrqjpbHarm4fWzNNSsdWghNKQsckPYLGUZWAIqDisL3iGIquUr2JuQDm5 U441CofUWGq7xxVtHIC24FdJknfT2OlRa90U7SeJY5g7LMe/qxyvUcdWvYiPQildrqnKOkbtbWVJ rlrMlWNZHScrJuv2VJFtoqk8Xz1VJlRxBsYnf2t+bgPOBFexPJ97eqldtuO665oVQ272aZKjQzTh VcMFdUTdiuLSUdVQUaFXQxFlSTO7XuQUcT39o3u6drXKilYk425nZvWuaLsMm716vHvHNO6cfa6G Lr8+cPb4Wv2G6irRRSofpDkvga0KwNKko8L/AJSSFgRPkgUKle3reY+O7eBuNpX3U09dodzK1zZJ rtZtY8YNjDsplRIgRHvjIk2S2ZBNHQELzEc58fta5JEdSqVzIHKei2On2G9ht5MbXakxIlqttRWN HeVckb2DWFJqZIBzxSnOKFrIpAIYinCjBu8jO5Sscbl6lNI1zj+JyDTwtq2WCTk6i4xsaiJoexB2 eil21vXQJCT6hK51hFKCPO+ZECTHG6U98MAlUsyMhFKyLt/K+h6Ja1tLs9zJg2FmBJiNi0NjcxKm M4yAbNtZMYBA10VxFUaS57wAVzHohFVruilc03I2oh34XGDrCaTdiUUfZnVEahsJkeLAlvtBxpUi aMDooBkJTWA0UxWf1BDYvRxgNIpXz1vkzSNvNr0fXbv6kbadUJu1MJtbLjPNWhPHikOZCCb8u9DS hD8EjxmVzSog18JexSvpvnIuo8aVcC32+fNiAt7kOu00OpoLHar28nnYUoocGsgAPLklUceQVWAE 9WjjleqIxjnIpXXry1oS6XX8gR7ebY63bSHwqtafXLO62CykjIcJoQKaPHfYElBfFlNLFbHUwliH 7xt8RO1SuLbc0cb0uuajtc2+lEpt8tlodSfV65aXllcz2wrCwdCZAjRiSmSGhqrDuCQTXtJGcJWo VWjVSu2h8l6TYT6yrh3Xmsbfa7XSYEP6bLZIfZUjJRLMBGqJPEwLYZnIcvaEiOD4yP8AOHyKVxWc ha/ATk2bcbNWkrePtnBRWw4tBNhS9cIeko7MVeZznk+oyTfV45xEhDajm2UeK0TzhI8qlfmo5a0K 71S23SDbzR0lDPfU3QrPXLSj2Kqms8PSBIppMcdgyWT5mL4orgIY3zYPGx/lH3KVxScz8cA0K05K l3sqv1OklJXW5bPXLSrv6yY6QGKOAelLGbYsmFNJjDFDdHQ5XSgowbvIzuUr0Olb5q/IVXKttWmz ZMevsyUtpEtaOfrF5TTBDEV8WdWzQhlxjIM4CeM4mOVhxvRFa9qqpWNIfKV7deo6+4fq44oGvaLx tW7rs8200W9JJv5NzKso0WPW3K+KsCKO2CIjnL806W80oIUY+vnKJSvb6hyvoe+WljT6vcyZ86tE 6V/tVDY00O2jsMsd8yqlSQDDYxWl6DdKgPOFrnsRSIrmoqlc3j3kbUeVNZhblo1hNttZsxiPW2sq hsKANkM0YEoZo7JgAvKNRyBp5GNVqPQg1VCCIxilfOZyZpECws6qXd+Gyp9rqtJnwvpst8hlldji lrADaglUjDMmBcpxdwRo03kIzwG8alcaw5X0Or3KNoU65ki2SSWPFVo6Gxk0cKRLar4cOZbsA6BF lSWoigiyTjMZHs8Y397eqlcmZyZpED8Q/N3fi/Cu+U3Gd/8A/TZZPkLzYPoX0iF9ol7/AD/iWk/r D7gj+d/qEZ4zeNSvpUcjajfbjtOg1FhNm7PpRBg2mKyhsB19OQsKtsAhJYOAkRSEjW8ErBsK5z2v L2oqgOg1K/NtsdnH5B0zUILILIVzr15tFzJlAJIlKGqJTwxRoytI1o3kNdhKpXoRPHDIxGI4iEH0 FnpdpLtq/wBbuCxkilt4YwCAOUwncs+VJYKkDKFUqeTqxbClW8a5v7lNctNLhC8JI5pHJBJxGYkC rggAlpgxJDDihXGWDL8ovKOhTJNBDBsUf5naNbk7dSBNFkRnyq+H4klHf3jTwqPyt6iN2E+0n2f0 ydv9zbR3HBFczSWp4QSpBIQVOJXzwUYY8uWDhk5L3X4viXP8x7j0WWSCJJxymjaVAQwzGmOTHIHH Ge4bDdj2+FsJfJ2lQY9DLk2ktkXY66NbwZI6CxOCHEmIny0qxewCpAERVVqEneFvcx7evVjkRDtP XriW5hiiXnAzIwMkQLOn00iBceOy+ZWHxDgg4wwJ/wBl3DpEMcMskh4yqrKeEhAVvotIQp8JT6GX gMgjOQcdHZcpVuv8j3uobDJBBrIWm0Ow10kNbLmy2ksrDYYc0s0gkeMMMKVcBPmCtGMTpK+Qv9Qa N++12jdalti31rTFLzNPcRMC6KMRRWzoIwxVnlfxZPgUu7hBwT4WJ+K43Hb2OvzaXfMFjWKGRSFY nMjzo5crkLGvhp8bBVUt8TfEoHpJOxWETkem1MiQiVN/pNlsMNWRSDsIcmonVUaQhDKVWPGZl1G7 GINrhuiFVXkQjWj8yLTLaba8+sryE0NxFE3ccWWaOZlwvHIZDA/IlyGDqAqlSW9CS+ni16LTWwYp IZHHY8g0Txq2TnBDCZcDiCCrEk8gF4W/cp6TxmOudt1hZhPbMkmrq6h1a23O6lBhtG+ZJSBXRpEh I8dDBU0hRoIXmH3vb3t6+BXr10Oyc98VarD1CdZbHMmA3/V5W66W3WdVuN0lbJVwmVpZUyKCvinK 9gx20Aqp29yiK4iIrBFcxSu1u+YuN9fotV2WfsrD0m7w2WmrTqSrm7KlvCfGZMWxaOGEr2QhgIMx ZpGtjhGRrikYjkVVK/XDG5WfIvD3E/IN2CBFud741otyt4tUIgKyNKtKuLOkDjMI95GiaQ70Y173 uRqIiucvVVUr4arvzpmsbXuG1Hraymqt5v8AX65sOIdTx4lLcyqEaG+8jpMiTIgGKxAMYqpMAFon vYpC8bou52uNHvde1pkjt47m6iTirZCW9w9sOXdjJJJJEzqEVciRIlRmXk8f7e3i11oGo7m3C8cV rFd3kKcVfIjtbqSzXl8TmWWWWFnURouRLHCsbOpeThXfKsA2oRtn04jZrk5I1vRbOJfU0+ln1a22 yUtTNFJgSGglAkMjWimG0zG+7wvVj2ORHfNqO9bV9BTWNAPM+92ds6yxyxsnj3dvBIrxSCOVJFjm 5oHUdyjlWQ4b5NV6h2cm2o9f2w3M+/WFpIs0U0Txm5vrW2lWSGUQzRyrFcc4xIo7mNyrocN6mZyH qNfs4NQlWZx3hyBArWVE09TFNIaro0aTZNCsMEg6dFFHOVhSo9nYx3c3r7VxurQrXWF0GeYi5JUf 0chRWfuiPMEMUcjj6EburvkcVORnobreu2rPX02zcXBF2xVe0cpjVnGY45JwhgjlkHeOKSRZJAV4 K3Jc/eTveqQ/rXzFr4/w9t1Zolx/sMl/ydrc/SPpsX2Gvf5vrtV/VZ3DZ819729hOz9Jty6JB7x4 s+PAnhtpPhf4Z7jwPBTsvfn7zB8S5RefxMvF+P6z7v27be9ePcY92ubezl+CQ8bi6928CPsvxc/e 7f41zGvifGy8H4+I5G5ep9QmVuv1soMnapu6atrpoUmonSqyOG92CsrpAyTRtSOKX8lKlyQgIZCK gUJ4iDa5F5zdm+7DQZ4dLtHDXr3FlEVKSMgW5uoYmBkUCNZfBd5I0Zw5Ch+DICDym9+pembauYNF sZA+ovdafAUaOVo1W7vYIHVpUAiSfwJJJYo3kDkKJPDeMEH1dTsljI5D3XTpyQSRaXXqPaqc8WKS NIZHtiXEN8eS5xXtKRh6OQVCDaJEHLExWK4biE9ux1e7l3VqOgXPEpFFbTxlVIPGc3EZRyWYMwe2 dgyhBxkVSpKl26HTddvp966rti74GOCC0uIiqsrBLlrmIpIS7B2WS0dw6rGOEiIVLIXfo9+5t404 xnjrd0v5dbJ+msuproWs22wxKGCQz447C2kQ4xhV8RxBGYkqc4IVUBej/sf06Wuvr+bVzfxjpO1p pOy7FIgbIlRA2GTDFrlpZRayvspc6BEsJ0wEZ8aLFWRXShPkyCDEFyCQrx+YPkUptXN/GOk7Wmk7 LsUiBsiVEDYZMMWuWllFrK+ylzoESwnTARnxosVZFdKE+TIIMQXIJCvH5g+RSv5u/OHGXHV8DWtu 2CXX2xKZmxzGQ9Ytr6DQVpJD4o7G4mRIxY9bEeYRhtk2BACcsc3R6+N/apWWMUpilMUpilMUqPM3 h26mu5smstKuuvdw5Xr+VeL7oHlkm1idV6hqlHFJNYrGr0fKopwzhC5zTQZrhq9FMRjFK4HFnDez 6R/q2/Vp9DI/0O+mqfw3s306VIL89ZyvwD4zwO8DO+Kn4WsOry+In9aP0Evc/wAalfnivhjZNG/1 bfqkzXz/AOh302T+Htm+myDl+etZf4CVkiB3gZ3xv/tey7iF8RP68f8ApL3E8aleU1/hvlzRqv0z l1h/G9xecL+nedw7tEK/urKuq7WbNDo4kk18oUEpECJ2szCq4oWvI1RC8Y/M80dSsiaZw5O0m+4I WDaRbDXuHuAbjhyQeW4gbq1PKNonyMpgka4fYotWmqVXERzXnCjWvRXuYpXgvT/6ebjiO/rD2jIk uv0zjn/Rpq99K5b3PkS8uYzjVjzSEqbIzaqiEVKiG58CtEdO5g0HIEIXiIpWZuU9Q2LZE0K+1FaU 2zcb723dqmq2Seeqob3yVFxRSosmWEEgoOsa7lFGVoDdpgC6jVOqopWL9L4X3elqeGQ31jqZrXQv UJu/L+0vpiyxVsuJtAuR0ihr2PD3eVj9wrvIIqtYxoJCNMVWD8qlcidwXcWnCu08azrKKK1tOY7r lSvk01/Y6+MzT8lzN8q4j7SM0c2GR4nRIppURFLGe4rwuIoxucpXXUHBWwwuLNl18waSm3G85Tp+ XBx15E2nk6FIna9Y67Pro1nsl08ljJQzdahxinHHAwQXo0cRzhueZSvU7nqfMG+8YSIFzF41gb7E 5I1ne9foay+tCaiCPrWzUOwDrpl2+F8wUkhamQxZg68TR/NjakZ/icQqldRzBxBuu6W+/t1eRq6U fM3EcbhjepN9aS6621GFFPsL22dQEMUw5h3D2ae1Y5yRGo+NGd51TuZilZRq9MsoXMW9chmNXup9 m401TTK+OMhHWoJNFabnOmPMxWIxBPZsUFBq17nOcE3cxiNYr1KwR6W9ahpf82b9T3sHZtJvt8kU XFVvVvSTTmoWzJ+xSlgyEVWFClzs99FaUSqxw6wCNVzRs6KVl3nTj+fyRpkairtf1HZjxNhi3S1W 3bDb6WjkjtMiFrb+ra+bVzRuIxzJgRG+xDCUfQyvYpWKbPgzkS94d4s13adjfs/IPGm4SNxa6Pyl smjMt2libBVxKom5QBJcokODeiCtj4VNNdWopxIkkrUUr0mtcKXNFR+nuuYmvQn8Ycp3PJG2xY9/ ebEKQt1Q7vDO2JYWZJM6bI+f2kBSSJpR+VGSCtaH+nFRSux13hy4pvUFuXKR7atNpttQqbWtdG0n 1KqvLMNRC2CWRFYg0ESNrFF4VY9XeSTYqrWeRXFUrj3PDuxWMbmtwbCmZM3fm/V+Y9MYSRIbG7tW rNBSPCtHILuE2RO044yOAhu2PKY9Ec/uC1SubuOg8icrcUXur767VaHZZu1VWzU9boe03UOvrxUd vVXUOCTY2Cjz0Kc1Y9j7KHGikjsltUQXEAhCqV5Ok4Nu4nDXI+mWGuaJL2HkPY3bHZUGzb/uPKVB PVoaqGwVhs1mf6sWR8tVBYKfHFHbEeyM8cMjgOU6le/4E0fetA1C1pN5swSnm2qTY6tRx90teSB6 VUkDFYCq/ENmAM+w7TClyELJE1w2zWgb1GBjlUr0lVptnB5h3vkEp4DqbZ+NdT02BFGUi2gZVFab pOlkMxWINBPHscFBua9zlcI6OaxGsV6lYt4e4g3XS7Xj9u1SNX+jcM8TS+GdFk6/aS7Gz26BLPrz 1s7cBooWQ5DBaxAZ8uEktrnyZDvOidrMUrKPC+mWXHHDvFHHt0avk3Oi8a0WnW8mpIQ1XJlVlXFh SCRnkYN7hOIF7mOexjlaqKrWr1RFKwRa61D2n1i0ljSXsGdXaVoY73kyghPSU+mvoQ7CFqaTu1Va I0iBuF9JaInR7mVsQnTtaF2KV6bYeIN1st12YUGRq/8Ao+3rlnU+Zr+2lWksO5Us/U26wgqyHXti ujnjy3alWq6QSUFwklykQBerVxSvP7hw7yzZbfuYdfPx4uhb1zxoXN1nZW9tZRdur/wqbSRT6kME cMkd/lFpwpAZbpDf6khwHga1UksUrOOiaZZavtXNF7PNXljcjclRNxpWQyEJJjRY+n6pr7hy0cxq NL8zRzHo0avb4iiXuRznsYpXAtXBq+bNNlFMwLNq49u6BHSzorCy66bUTocaG1y9GFJHkXJitF0c Ydcxz+5IzFZ2dmHu9hX0SKSbe5t5PhHkksc0bu+PNVdYEQt2RpSFwZW5czclbfd1pIxwJoJk7nze N4nRUB8mKNKzBe7LGC2RGMYW2H05bTak20sHYKWGSftni1QvkkDLUa1YrereQ3q0a9sh34qukA0f Vn+yV/V7Oz+n3em9T9ItFskuLaRgkOZhhcPdRe7+7yDLd0HucHiE4b458KeXxclfbD1K4N00M6KW l/mj8Xw28njeMh7dmPvM3ADI+CLJGPh9zydw1N2+/kWNUGJJr7zUIOjW1bN5A2TSqmuhwpNkbyPr 6kg22jSMtTDWLKKBrUCnaVEIRM5/ae+YNF05bW8ZllinkuEdba1ndnkSJcCS5VzblTCreJGkhJY8 kJVa9fcO05dUvWntwDHJEkLKZ7iFVRGkOSkBUTAiQjg7IAB2Ycmrn77xxuGy7Jvhas2tN1rkfi+u 4yuCz5sqNfU7AydkdMnRWMA8ZFaG6YgwueNCE6q4gkEiG+bbu6NE0rS9OW7WX3uyu5btAqoY3LLa hI3JdWUF4CWcK3FcAK5clP31rQNU1C/vWtzH7vdW0du5YsHQBrgs6gKQcLMOKkryOSWUKA3fXhA2 XNnH9W0qPdrmi7Dtc0cUnZKhlkSaasrklK37vBIGW6VgX/0ylrUf2q+K1zPO09XtdhaldlcCe4to VJHZgqTyy8M9ucbCAFh8SJLxyFmIb7bwpcbusbcH+ihnlOD3BZoo4+WO/FwZsKfhZo+WC0YI6Hm7 SOUt0fq4dA2UFVTxmTwbTTv3G14+kWBJCRGwJzLStASY9sJBzu6AMkVJKzGKssKhaq8XXUV0nFvD WzaSvpsW3m0EleG/TXP4d2Ra+TIMs20lJoSDkQO8DO+KiatYo4hfET+vH6CXuJ41K6XXeGuRtL07 05D1+VpFjufEPCa8L7HGu504WrShTa/WxTrGEVkVxjOjytaivEAogfMBOZjixlcjkUrM3DGm2fHX D3E/H12eBKudE41otNt5VUUh6yTKq6uLBkEjPIxhHCcQD1Y57GOVqoqtavVEUrGmn64XY+JLHSqu bEHcaDytNBEBNlOIRhNa3RbqlDalajzd82HFqzHkPa8xWWPnchXE6viLQdJfVtjS7ds5FFxZX0gU MxJzaah7xbrOw5PymiSF5JGDSOsvjEOX+KCds6HJrfTebaunyqLrT9RlCh2JPKx1U3Vqtww5PyuI I7eSWVg0siz+Owdn+L293re/7lqEaBsjdPq7wXI+tbUKDST5s+pr66k2OluDx3TigGSTIeOulqwi Ro7FeYQ1a1GuM7otR0jdGv6Elrq4t47kXdnOFjaRkWK2u7edlMjIrSSFYn4t4USlmRCoAMh6vVdC 3lujbUdnrgtYrsX1hcBInleNILS+tbl0Mrxo0srJBJxbwIULMkZVQrSt0tzxttE7ab0cU1B+Ddt5 F13k+4sZFhJFs9XM11tCg4EaGkdwShkLrkFXGfIE4aSJCeIn2rnn6htHWbnWrlYGi/J9zd2l5I5d xMkloLbESRiMo6SG0jy5lQpzk+B+1eVqmxdwXe4btLdofyXeX1lqErs7i4jlshZ8YY4hEY3jlNjD mRpoygeUCN+xrptl405EnbJs4qY2mLqG28u6hyrPnWVjOj7HC/DxdVHMrhRGRnhf5B6yMwpCmb95 lE4SIvnb5+sbQ3Xc6veJp7W/uFzf2F6zO8gmX3U2QkiVBGyHktmHSQyD4mMbIAfEXzNe2Hva712/ j0trX8mXmpaZqLvI8qzp7k2nCWBY1haNuaWAkjlMo+JjE0YB8ZeTtvGG7WOwXX0GRqq61tHKeoco 3Mm4lyw3sEmuy9dbLgxQsA8bmmja+AozOK3oV5BuH2l84/113Z24rvVLj8mPB7ncXtheyGRnEim0 e0DxoqoykPHaqyuXGHLIVw/iJ++5Ng7rvtZuvyO9v7jd6jpmoStK0gmRrGSyEkUaLGyESRWSOjmR cSFo2TjJ4qelpyBtueN4kiM0w9Q41odfV0MvaIM2zn3U+bFmdq9HmFGjUhxML1cAdk9zEakt6v8A XsGjvupmpTI2Ra2drF8J7CSaW4lkSTH0nWNLZ0DZMaTFlwJ25e7pjxaj1f1aeNuS2dhZw/CewluJ rqaWOXHZpEijtJI1fLRJOWTiLhi+HPVFwtzLzHX7Rrmk7ZUwdU2bjKXqIqe03a50mJU2khtgw0+W KuiFfagkiPBjrFkmEECRSPUUtCvAvf1J9dRyZpu6chc385aHrf4WDQ736ZNN0jdbO8nSodzRQbS6 5OjEnVTBRyskHGJZTUjGfHY55Av87fEoyKU5M03dOQub+ctD1v8ACwaHe/TJpukbrZ3k6VDuaKDa XXJ0Yk6qYKOVkg4xLKakYz47HPIF/nb4lGRSvWc/8Nchb/s1NsvHCadQ7LW0Tain5HLuewaRu2kH +cWQ47o8ERod/BRqtc2msmgD5Gm7jubIcg1KljilMUpilMUpilMUpilMUpilMUpilMUpilMUpilM UpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMUpilMU pilMUpilMUpilMUpilMUpilMUr//2Q== --_004_CE8995AB5D178F44A2154F5C9A97CAF40252030AF3D6HE111541eme_-- From vladimir@nimbusds.com Mon Oct 8 23:19: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 CA50A21F85AC for ; Mon, 8 Oct 2012 23:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_84=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO2-3WeOj3jn for ; Mon, 8 Oct 2012 23:19:16 -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 87E2C21F8528 for ; Mon, 8 Oct 2012 23:19:15 -0700 (PDT) Received: (qmail 5157 invoked from network); 9 Oct 2012 06:19:13 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 9 Oct 2012 06:19:10 -0000 Received: (qmail 20244 invoked by uid 99); 9 Oct 2012 06:19:10 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 95.43.40.35 User-Agent: Workspace Webmail 5.6.25 Message-Id: <20121008231909.cc40c4f3d92d2001859047cd8cabb9ab.241bbd553e.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Mon, 08 Oct 2012 23:19:09 -0700 Mime-Version: 1.0 Subject: Re: [jose] =?utf-8?q?Example_DEFLATE_vectors_for_JWE=3F?= 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, 09 Oct 2012 06:19:16 -0000 Thanks for the pointers Axel.=0A=0AI had actually looked at Compress.java a= nd thought it was for the=0Apreviously specified zip=3DGZIP compression. = =0A=0AWhile GZIP uses the DEFLATE alg for compression, it appends a differe= nt=0Aset of headers to the stream. A good explanation of the difference I= =0Afound here:=0A=0Ahttp://stackoverflow.com/questions/388595/why-use-defla= te-instead-of-gzip-for-text-files-served-by-apache#answer-9856879=0A=0A=0AW= ith that difference taken into account, isn't=0Ajava.util.zip.Deflater{Inpu= t|Output}Stream the correct class to use=0Ahere?=0A=0ACheers,=0A=0AVladimir= =0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A= =0A=0A=0A=0A-------- Original Message --------=0ASubject: RE: [jose] Exampl= e DEFLATE vectors for JWE?=0AFrom: =0ADate: Mon, O= ctober 08, 2012 10:18 am=0ATo: , =0A= =0AA JUNIT test from jsoncrypto.org is here:=0Ahttps://code.google.com/p/js= oncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#1366=0A= Although that does not contain fixed =E2=80=9Cstrings=E2=80=9D.=0A =0ABewar= e that jsoncrypto uses the new 5-part jwe already (IV moved from=0Aheader t= o top level)=0A =0AThe JAVA implementation is here:=0Ahttps://code.google.c= om/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/util/Compress.java= =0A =0AThe code was borrowed from this post: (claims to be compatible with= =0A.net)=0Ahttp://stackoverflow.com/questions/6717165/how-can-i-zip-and-unz= ip-a-string-using-gzipoutputstream-that-is-compatible-with=0A =0Ahave fun= =0AAxel=0A =0A =0AFrom: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of=0AVladimir Dzhuvinov / NimbusDS=0ASent: Monday, October 08, = 2012 10:20 AM=0ATo: jose@ietf.org=0ASubject: [jose] Example DEFLATE vectors= for JWE?=0A=0A=0A =0AHi guys,=0A=0A =0A=0AThe new DEFLATE implementation i= n our Nimbus JOSE+JWT library seems to=0Abe incorrect and I want to find ou= t where the problem is. It would help=0Aa lot of we had some example test v= ectors for that in the JWE appendix.=0A=0A =0A=0AIf anyone has been able to= correctly implement DEFLATE in Java 6, please=0Aget in touch.=0A=0A =0A=0A= Thanks,=0A=0A =0A=0AVladimir=0A=0A =0A=0A--=0A=0AVladimir Dzhuvinov : www.N= imbusDS.com : vladimir@nimbusds.com From ietf@augustcellars.com Tue Oct 9 11:29: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 9BCC821F87F5 for ; Tue, 9 Oct 2012 11:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AdzTKW7547J for ; Tue, 9 Oct 2012 11:29:02 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 07E4121F87F3 for ; Tue, 9 Oct 2012 11:29:01 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (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 C2E4638F27 for ; Tue, 9 Oct 2012 11:29:01 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 9 Oct 2012 11:27:35 -0700 Message-ID: <01c301cda64b$c133ae00$439b0a00$@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: Ac2mSkiUp3n/JeZUSwGlqjzWpoRZfA== Content-Language: en-us Subject: [jose] Criticality of Headers - Possible Answers 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, 09 Oct 2012 18:29:02 -0000 I am looking to establish the possible answers that we have for criticality of header fields and then want to follow it up with a discussion hopefully leading to closure. Please respond if I am missing any of the different solutions or if you think that I have all of the solutions that were discussed for the options. Also please feel free to augment the wording I have below on the description of the solution. I want to deal with pros and cons after we have the descriptions agreed on. 1. Any headers not covered by the current document generate an error. This is the current state of the document and is the all headers are critical solution. 2. Any headers not covered by the current document are ignored. This is the no headers are critical solution. 3. Headers are to be decorated in some manner to say if they are critical. There are four possible decoration methods that I have seen proposed. a) Change the field name to indicate it is critical (ala "SignTime!") b) Change the field name to indicate it can be ignored (ala "SignTime?") c) Create a header that has a list of either critical (or ignorable) field names d) Separate the non-critical header fields into a sub header 4. The core specification should ignore all issues of criticality and just define a common set of headers. It is up to the application to define which headers are critical, which can be ignored, and it can define new headers to meet it's needs. Jim From ietf@augustcellars.com Tue Oct 9 11:35: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 ADDA721F88A1 for ; Tue, 9 Oct 2012 11:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw3YTO9b+AiA for ; Tue, 9 Oct 2012 11:35:11 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1FC21F88A3 for ; Tue, 9 Oct 2012 11:35:09 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1E6972CA12 for ; Tue, 9 Oct 2012 11:35:09 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 9 Oct 2012 11:33:42 -0700 Message-ID: <01c401cda64c$9c22e3f0$d468abd0$@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: Ac2mS8+HPTmw6GuJR1iSC/75b9GqqA== Content-Language: en-us Subject: [jose] Proposal - Create a SignTime Header 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, 09 Oct 2012 18:35:26 -0000 I propose that we create a header entry that is optional and contains a time that the signer claims that they signed at. There are two different types of times that can found in signed statements. The first is going to be a time field associated with the data. This is the current approach that is used for the JWT in that part of the claims about the token itself is the time that the claims in the token are created. The second time field is associated with the signing operation and is a claim not about the content but about the signature. This is a signing time. The claims may be attested to at a different time that the signature was created. Having a signing time is not an important issue for the JWT specification; however I believe that it will become an issue for cases where multiple people will be signing a single document. These signatures may be either made in parallel or serialized but as they occur at different times knowing a claimed signing time may be of interest. Side note - I believe that the nonce question should be dropped until somebody makes a case for it that is related to signatures and not to protocols which is where I generally see nonces being used. (That is for freshness checking or associating multiple documents in a single dialog.) Jim From Michael.Jones@microsoft.com Tue Oct 9 11:49: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 EE1521F0C8E for ; Tue, 9 Oct 2012 11:49:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3P3HAmkEsRt for ; Tue, 9 Oct 2012 11:49:50 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 322F61F0C3E for ; Tue, 9 Oct 2012 11:49:50 -0700 (PDT) Received: from mail152-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Oct 2012 18:49:49 +0000 Received: from mail152-ch1 (localhost [127.0.0.1]) by mail152-ch1-R.bigfish.com (Postfix) with ESMTP id 979CA60172; Tue, 9 Oct 2012 18:49:49 +0000 (UTC) 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 X-SpamScore: -23 X-BigFish: VS-23(zzbb2dI9371Ic85fh1454Izz1202h1d1ah1d2ahzz1033IL8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail152-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=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail152-ch1 (localhost.localdomain [127.0.0.1]) by mail152-ch1 (MessageSwitch) id 1349808587174377_11577; Tue, 9 Oct 2012 18:49:47 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail152-ch1.bigfish.com (Postfix) with ESMTP id 1EA0E3400CE; Tue, 9 Oct 2012 18:49:47 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Oct 2012 18:49:40 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.129]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Tue, 9 Oct 2012 18:49:35 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Criticality of Headers - Possible Answers Thread-Index: Ac2mSkiUp3n/JeZUSwGlqjzWpoRZfAABIrP0 Date: Tue, 9 Oct 2012 18:49:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436682B09E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <01c301cda64b$c133ae00$439b0a00$@augustcellars.com> In-Reply-To: <01c301cda64b$c133ae00$439b0a00$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436682B09ETK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Criticality of Headers - Possible Answers 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, 09 Oct 2012 18:49:51 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436682B09ETK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that the poll established that the working group affirmed the cur= rent semantics by a substantial margin, effectively closing this issue. Ka= ren, can you please make a consensus call based upon the poll results? Thank you, -- Mike ________________________________ From: Jim Schaad Sent: 10/9/2012 11:29 AM To: jose@ietf.org Subject: [jose] Criticality of Headers - Possible Answers I am looking to establish the possible answers that we have for criticality of header fields and then want to follow it up with a discussion hopefully leading to closure. Please respond if I am missing any of the different solutions or if you think that I have all of the solutions that were discussed for the options. Also please feel free to augment the wording I have below on the descriptio= n of the solution. I want to deal with pros and cons after we have the descriptions agreed on. 1. Any headers not covered by the current document generate an error. Thi= s is the current state of the document and is the all headers are critical solution. 2. Any headers not covered by the current document are ignored. This is the no headers are critical solution. 3. Headers are to be decorated in some manner to say if they are critical. There are four possible decoration methods that I have seen proposed. a) Change the field name to indicate it is critical (ala "SignTime!") b) Change the field name to indicate it can be ignored (ala "SignTime?") c) Create a header that has a list of either critical (or ignorable) fiel= d names d) Separate the non-critical header fields into a sub header 4. The core specification should ignore all issues of criticality and just define a common set of headers. It is up to the application to define whic= h headers are critical, which can be ignored, and it can define new headers t= o meet it's needs. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436682B09ETK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe tha= t the poll established that the working group affirmed the current semantic= s by a substantial margin, effectively closing this issue.  Karen, can= you please make a consensus call based upon the poll results?

Thank you,
-- Mike

From: Jim Sc= haad
Sent: 10/9/2= 012 11:29 AM
To: jose@i= etf.org
Subject: [jose]= Criticality of Headers - Possible Answers

I am looking to establish the possible answers tha= t we have for criticality
of header fields and then want to follow it up with a discussion hopefully<= br> leading to closure.

Please respond if I am missing any of the different solutions or if you
think that I have all of the solutions that were discussed for the options.=
Also please feel free to augment the wording I have below on the descriptio= n
of the solution.  I want to deal with pros and cons after we have the<= br> descriptions agreed on.

1.  Any headers not covered by the current document generate an error.=   This
is the current state of the document and is the all headers are critical solution.

2.  Any headers not covered by the current document are ignored. = This is
the no headers are critical solution.

3.  Headers are to be decorated in some manner to say if they are crit= ical.
There are four possible decoration methods that I have seen proposed.

a)  Change the field name to indicate it is critical (ala "SignTi= me!")
b)  Change the field name to indicate it can be ignored (ala "Sig= nTime?")
c)   Create a header that has a list of either critical (or ignor= able) field
names
d)  Separate the non-critical header fields into a sub header

4.  The core specification should ignore all issues of criticality and= just
define a common set of headers.  It is up to the application to define= which
headers are critical, which can be ignored, and it can define new headers t= o
meet it's needs.

Jim


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

 --_000_4E1F6AAD24975D4BA5B16804296739436682B09ETK5EX14MBXC284r_-- From bobwyman@gmail.com Tue Oct 9 12:19: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 8116621F869A for ; Tue, 9 Oct 2012 12:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmqekLNTVLaF for ; Tue, 9 Oct 2012 12:19:52 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91BAC21F86B8 for ; Tue, 9 Oct 2012 12:19:52 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so14081112iec.31 for ; Tue, 09 Oct 2012 12:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+IKH129w1F/VPrm5a69GMsxz+1PcBlucrbI5qXUjP1s=; b=lvR8hc/gVWC6ziC8t2hVbZBbdW3BM2rRfBhs3LqjFlNVF++UZZWgKTz4lwuCPLDNkD 785u/DyfxZBdUe4fMReOlV9oPs/Mx1qeL+Kyyy3f1Sm+njiGCxmAEAtvjtQtWH4ZngB1 4ZLWO9JoBkGqalK5iTwGtNGcYEUqLqBlFO7W15GgwCUWli4zV9Gc9iE8nb7KwMg+pEiV WZ5m6D0A2flCOpq/n0Sz56yywLuudUFBs6Hc87eBL7ueAHJdknVfSJuyFMazxCbvzw5X eHqL2CwSL+XcI2B7JCBw2phHyIuU5TddMBdC2ylMQjEZc4/K217A5vQHCT4dDR2HR1o4 QsNA== MIME-Version: 1.0 Received: by 10.50.190.162 with SMTP id gr2mr2846673igc.65.1349810392142; Tue, 09 Oct 2012 12:19:52 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.64.130.232 with HTTP; Tue, 9 Oct 2012 12:19:52 -0700 (PDT) In-Reply-To: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> References: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> Date: Tue, 9 Oct 2012 15:19:52 -0400 X-Google-Sender-Auth: MdjEisIVDU7nvY9Uwl0lkoBxDsI Message-ID: From: Bob Wyman To: Jim Schaad Content-Type: multipart/alternative; boundary=f46d0447a12df0150a04cba538df Cc: jose@ietf.org Subject: Re: [jose] Proposal - Create a SignTime Header 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, 09 Oct 2012 19:19:53 -0000 --f46d0447a12df0150a04cba538df Content-Type: text/plain; charset=ISO-8859-1 Time of signing would be valuable in many contexts. However, there are many other attributes that can be associated with the signature that would also be valuable -- depending on the specific context. Exhaustively listing all these attributes in advance is not going to work. So, I'd like to suggest again that the JWT format be extended to four parts rather than three. The added part would be "signature header" and would contain, in addition to those signature-specific elements now in JWS Header, arbitrary JSON content which is associated with the signature. Thus, instead of: .. we would have: ... Such a four-part structure, by isolating signature-specific data from payload-specific data also makes it very easy to support multiple signatures for the same payload (since all signatures would be applied to the same base . bytes.) Additionally, the ability to associate metadata with each signature allows a broad range of application requirements to be addressed. For instance, I might define a "signature purpose" attribute that allowed signers to distinguish between various intents such as "claiming authorship," "approving," "denying," "have read," etc. Other applications might want to support signatures that not only were created on a certain date but should be considered to "expire" after some time or upon some other event described in the signature header. There are all sorts of things that folk might want to do and each signer of any particular piece of payload is likely to have some different intent in mind when signing. The four-part structure is vastly more flexible than the existing three-part structure and introduces very little complexity or added bits to the protocol. Why not use it? bob wyman On Tue, Oct 9, 2012 at 2:33 PM, Jim Schaad wrote: > I propose that we create a header entry that is optional and contains a > time > that the signer claims that they signed at. > > There are two different types of times that can found in signed statements. > The first is going to be a time field associated with the data. This is > the > current approach that is used for the JWT in that part of the claims about > the token itself is the time that the claims in the token are created. The > second time field is associated with the signing operation and is a claim > not about the content but about the signature. This is a signing time. > The > claims may be attested to at a different time that the signature was > created. > > > Having a signing time is not an important issue for the JWT specification; > however I believe that it will become an issue for cases where multiple > people will be signing a single document. These signatures may be either > made in parallel or serialized but as they occur at different times knowing > a claimed signing time may be of interest. > > > > Side note - I believe that the nonce question should be dropped until > somebody makes a case for it that is related to signatures and not to > protocols which is where I generally see nonces being used. (That is for > freshness checking or associating multiple documents in a single dialog.) > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d0447a12df0150a04cba538df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Time of signing would be valuable in many contexts. However, there are many= other attributes that can be associated with the signature that would also= be valuable -- depending on the specific context. Exhaustively listing all= these attributes in advance is not going to work.

So, I'd like to suggest again that the JWT format be ext= ended to four parts rather than three. The added part would be "signat= ure header" and would contain, in addition to those signature-specific= elements now in JWS Header, arbitrary JSON content which is associated wit= h the signature.=A0

Thus, instead of:
<JWS Header>.<payload>.<sig= nature>
we would have:
<payload_header>.<payload>.<signature_header= >.<signature>

Such a four-part structure, by isolating signature-spec= ific data from payload-specific data also makes it very easy to support mul= tiple signatures for the same payload (since all signatures would be applie= d to the same base <payload_header>.<payload> bytes.) Additiona= lly, the ability to associate metadata with each signature allows a broad r= ange of application requirements to be addressed. For instance, I might def= ine a "signature purpose" attribute that allowed signers to disti= nguish between various intents such as "claiming authorship," &qu= ot;approving," "denying," "have read," etc. Other = applications might want to support signatures that not only were created on= a certain date but should be considered to "expire" after some t= ime or upon some other event described in the signature header. There are a= ll sorts of things that folk might want to do and each signer of any partic= ular piece of payload is likely to have some different intent in mind when = signing.

The four-part structure is vastly more flexible than th= e existing three-part structure and introduces very little complexity or ad= ded bits to the protocol. Why not use it?

bob wyma= n

On Tue, Oct 9, 2012 at 2:33 PM, Jim Schaad <= span dir=3D"ltr"><ietf@augustcellars.com> wrote:
I propose that we create a header entry that is optional and contains a tim= e
that the signer claims that they signed at.

There are two different types of times that can found in signed statements.=
The first is going to be a time field associated with the data. =A0This is = the
current approach that is used for the JWT in that part of the claims about<= br> the token itself is the time that the claims in the token are created. =A0T= he
second time field is associated with the signing operation and is a claim not about the content but about the signature. =A0This is a signing time. = =A0The
claims may be attested to at a different time that the signature was
created.


Having a signing time is not an important issue for the JWT specification;<= br> however I believe that it will become an issue for cases where multiple
people will be signing a single document. =A0These signatures may be either=
made in parallel or serialized but as they occur at different times knowing=
a claimed signing time may be of interest.



Side note - I believe that the nonce question should be dropped until
somebody makes a case for it that is related to signatures and not to
protocols which is where I generally see nonces being used. =A0(That is for=
freshness checking or associating multiple documents in a single dialog.)
Jim


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

--f46d0447a12df0150a04cba538df-- From tonynad@microsoft.com Tue Oct 9 18:40: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 C52A51F0C5C for ; Tue, 9 Oct 2012 18:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2VtR5caDzqI for ; Tue, 9 Oct 2012 18:40:02 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 124B11F0C4C for ; Tue, 9 Oct 2012 18:40:01 -0700 (PDT) Received: from BL2FFO11FD008.protection.gbl (10.173.161.202) by BL2FFO11HUB015.protection.gbl (10.173.160.27) with Microsoft SMTP Server (TLS) id 15.0.516.0; Wed, 10 Oct 2012 01:41:02 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 10 Oct 2012 01:41:02 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 10 Oct 2012 01:39:58 +0000 Received: from mail160-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 10 Oct 2012 01:39:57 +0000 Received: from mail160-va3 (localhost [127.0.0.1]) by mail160-va3-R.bigfish.com (Postfix) with ESMTP id 34BA8A0130 for ; Wed, 10 Oct 2012 01:39:57 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz9371I542Mzz1202h1d1ah1d2ah1082kzz1033IL8275dhz31h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: softfail (mail160-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ;.outlook.com ; Received: from mail160-va3 (localhost.localdomain [127.0.0.1]) by mail160-va3 (MessageSwitch) id 1349833194760564_23480; Wed, 10 Oct 2012 01:39:54 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.249]) by mail160-va3.bigfish.com (Postfix) with ESMTP id AC43B260045; Wed, 10 Oct 2012 01:39:54 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Oct 2012 01:39:54 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.98]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0207.009; Wed, 10 Oct 2012 01:39:53 +0000 From: Anthony Nadalin To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Proposal - Create a SignTime Header Thread-Index: Ac2mS8+HPTmw6GuJR1iSC/75b9GqqAAKIxWA Date: Wed, 10 Oct 2012 01:39:53 +0000 Message-ID: References: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> In-Reply-To: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.67.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464001)(42186003)(16616001)(33656001)(16696001)(8716001)(31966008)(49866001)(44976002)(5343655001)(47776002)(47446002)(3846001)(47736001)(51856001)(48376001)(306001)(47976001)(16676001)(6806001)(74662001)(4396001)(46102001)(876001)(1076001)(5836001)(4196001)(20776001)(50466001)(50986001)(74502001)(316001)(42262001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0630013541 Subject: Re: [jose] Proposal - Create a SignTime Header 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, 10 Oct 2012 01:40:02 -0000 What is the use case here? I really hate to bring in time requirements. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Tuesday, October 9, 2012 11:34 AM To: jose@ietf.org Subject: [jose] Proposal - Create a SignTime Header I propose that we create a header entry that is optional and contains a tim= e that the signer claims that they signed at. There are two different types of times that can found in signed statements. The first is going to be a time field associated with the data. This is th= e current approach that is used for the JWT in that part of the claims abou= t the token itself is the time that the claims in the token are created. T= he second time field is associated with the signing operation and is a clai= m not about the content but about the signature. This is a signing time. = The claims may be attested to at a different time that the signature was cr= eated. Having a signing time is not an important issue for the JWT specification; = however I believe that it will become an issue for cases where multiple peo= ple will be signing a single document. These signatures may be either made= in parallel or serialized but as they occur at different times knowing a c= laimed signing time may be of interest. Side note - I believe that the nonce question should be dropped until someb= ody makes a case for it that is related to signatures and not to protocols = which is where I generally see nonces being used. (That is for freshness c= hecking or associating multiple documents in a single dialog.) Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Wed Oct 10 10:19:22 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 4561221F860E for ; Wed, 10 Oct 2012 10:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+tenYeQ6KxO for ; Wed, 10 Oct 2012 10:19:21 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A92B021F8573 for ; Wed, 10 Oct 2012 10:19:21 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (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 59B8738F26; Wed, 10 Oct 2012 10:19:21 -0700 (PDT) From: "Jim Schaad" To: "'Anthony Nadalin'" , References: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> In-Reply-To: Date: Wed, 10 Oct 2012 10:17:46 -0700 Message-ID: <023b01cda70b$2ec56660$8c503320$@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: AQE8rDnmQzXhBeNgORN95rU+BI+sgQK+jWWBmL7JJbA= Content-Language: en-us Subject: Re: [jose] Proposal - Create a SignTime Header 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, 10 Oct 2012 17:19:22 -0000 I do not have a current use case in terms of a specific application. I just note that having a time that things are signed is common practice in many documents that are used today. As such I believe it will be a common attribute on signatures that will be needed in the future. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Anthony Nadalin > Sent: Tuesday, October 09, 2012 6:40 PM > To: Jim Schaad; jose@ietf.org > Subject: Re: [jose] Proposal - Create a SignTime Header > > What is the use case here? I really hate to bring in time requirements. > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Tuesday, October 9, 2012 11:34 AM > To: jose@ietf.org > Subject: [jose] Proposal - Create a SignTime Header > > I propose that we create a header entry that is optional and contains a time > that the signer claims that they signed at. > > There are two different types of times that can found in signed statements. > The first is going to be a time field associated with the data. This is the > current approach that is used for the JWT in that part of the claims about the > token itself is the time that the claims in the token are created. The second > time field is associated with the signing operation and is a claim not about the > content but about the signature. This is a signing time. The claims may be > attested to at a different time that the signature was created. > > > Having a signing time is not an important issue for the JWT specification; > however I believe that it will become an issue for cases where multiple > people will be signing a single document. These signatures may be either > made in parallel or serialized but as they occur at different times knowing a > claimed signing time may be of interest. > > > > Side note - I believe that the nonce question should be dropped until > somebody makes a case for it that is related to signatures and not to > protocols which is where I generally see nonces being used. (That is for > freshness checking or associating multiple documents in a single dialog.) > > Jim > > > _______________________________________________ > 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 tonynad@microsoft.com Wed Oct 10 10:40:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE56721F8724 for ; Wed, 10 Oct 2012 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czwy88AlYBUo for ; Wed, 10 Oct 2012 10:40:18 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id 21ED221F86DA for ; Wed, 10 Oct 2012 10:40:17 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.200) by BY2FFO11HUB007.protection.gbl (10.1.14.57) with Microsoft SMTP Server (TLS) id 15.0.516.0; Wed, 10 Oct 2012 17:41:12 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 10 Oct 2012 17:41:12 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 10 Oct 2012 17:39:44 +0000 Received: from mail226-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 10 Oct 2012 17:38:29 +0000 Received: from mail226-tx2 (localhost [127.0.0.1]) by mail226-tx2-R.bigfish.com (Postfix) with ESMTP id BE8BF2401D8 for ; Wed, 10 Oct 2012 17:38:29 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432Izz1202h1d1ah1d2ah1082kzz1033IL8275dhz31h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: softfail (mail226-tx2: transitioning domain of microsoft.com does not designate 157.56.236.5 as permitted sender) client-ip=157.56.236.5; envelope-from=tonynad@microsoft.com; helo=BY2PRD0310HT003.namprd03.prod.outlook.com ;.outlook.com ; Received: from mail226-tx2 (localhost.localdomain [127.0.0.1]) by mail226-tx2 (MessageSwitch) id 1349890707581808_4634; Wed, 10 Oct 2012 17:38:27 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.246]) by mail226-tx2.bigfish.com (Postfix) with ESMTP id 87106940064; Wed, 10 Oct 2012 17:38:27 +0000 (UTC) Received: from BY2PRD0310HT003.namprd03.prod.outlook.com (157.56.236.5) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Oct 2012 17:38:25 +0000 Received: from BY2PRD0310MB365.namprd03.prod.outlook.com ([169.254.4.133]) by BY2PRD0310HT003.namprd03.prod.outlook.com ([10.255.80.38]) with mapi id 14.16.0207.009; Wed, 10 Oct 2012 17:38:22 +0000 From: Anthony Nadalin To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Proposal - Create a SignTime Header Thread-Index: Ac2mS8+HPTmw6GuJR1iSC/75b9GqqAAKIxWAACWznQAAAK2pwA== Date: Wed, 10 Oct 2012 17:38:21 +0000 Message-ID: References: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> <023b01cda70b$2ec56660$8c503320$@augustcellars.com> In-Reply-To: <023b01cda70b$2ec56660$8c503320$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%CAMPBELLSOUP.COM$RO%1$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464001)(377454001)(51704002)(47976001)(16616001)(47736001)(16696001)(44976002)(4196001)(5343655001)(48376001)(16676001)(4396001)(42186003)(51856001)(74502001)(8716001)(306001)(47446002)(3846001)(46102001)(47776002)(50466001)(1076001)(31966008)(74662001)(5836001)(50986001)(49866001)(6806001)(20776001)(876001)(33656001)(316001)(42262001)(3746001)(37146003)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0630013541 Subject: Re: [jose] Proposal - Create a SignTime Header 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, 10 Oct 2012 17:40:18 -0000 Really think we should not be adding things w/o the proper use case, as we = have a ton of nice to have things but we also have no use cases so we have = not burdened the group with these -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Wednesday, October 10, 2012 10:18 AM To: Anthony Nadalin; jose@ietf.org Subject: Re: [jose] Proposal - Create a SignTime Header I do not have a current use case in terms of a specific application. I jus= t note that having a time that things are signed is common practice in many documents that are used today. As such I believe it will be a common attribute on signatures that will be needed in the future. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Anthony Nadalin > Sent: Tuesday, October 09, 2012 6:40 PM > To: Jim Schaad; jose@ietf.org > Subject: Re: [jose] Proposal - Create a SignTime Header >=20 > What is the use case here? I really hate to bring in time requirements. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Jim Schaad > Sent: Tuesday, October 9, 2012 11:34 AM > To: jose@ietf.org > Subject: [jose] Proposal - Create a SignTime Header >=20 > I propose that we create a header entry that is optional and contains=20 > a time > that the signer claims that they signed at. >=20 > There are two different types of times that can found in signed statements. > The first is going to be a time field associated with the data. This=20 > is the > current approach that is used for the JWT in that part of the claims=20 > about the > token itself is the time that the claims in the token are created. =20 > The second > time field is associated with the signing operation and is a claim not about the > content but about the signature. This is a signing time. The claims=20 > may be > attested to at a different time that the signature was created. >=20 >=20 > Having a signing time is not an important issue for the JWT=20 > specification; however I believe that it will become an issue for=20 > cases where multiple people will be signing a single document. These=20 > signatures may be either made in parallel or serialized but as they=20 > occur at different times knowing a > claimed signing time may be of interest. >=20 >=20 >=20 > Side note - I believe that the nonce question should be dropped until=20 > somebody makes a case for it that is related to signatures and not to=20 > protocols which is where I generally see nonces being used. (That is=20 > for freshness checking or associating multiple documents in a single=20 > dialog.) >=20 > Jim >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From dholth@gmail.com Wed Oct 10 10:43: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 373FC21F84EC for ; Wed, 10 Oct 2012 10:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S64bob1Oieon for ; Wed, 10 Oct 2012 10:43:52 -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 7E1E821F84C5 for ; Wed, 10 Oct 2012 10:43:52 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so492107bkc.31 for ; Wed, 10 Oct 2012 10:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sqD7n337g3WfhJn53fyQ/VfM6XYkn2vMETq559nS/Ds=; b=E85FWj62MuNygsGnAzDfB6EFeRsxz2DiJc5u2rnlY/yOlYqZ282HqHyS2ou+kRcR5t m1soyWzL0iAddmqXVLGeZRe7IuOx4ZloTOoxlIxrg+LYhFsO0juGJxb+gdbZgtHQwNZk qBRT4sfYzowx+l0SYCYVQ6vzB04PK0s3xBQPUpAs84GSCJKSnZGlmu1ulihb/5RGG6Iz 2o834QmhSBQ9iZ6B9p9it3CMlEmaN+pYCmTJr3EXZG4Iipn607DE9S1ZM2NKrw/s2Pzh ArFWpQM3SgbyR3+UB2jW9zKFMdEgSdfx+ftbZtztUGgwdo3TWccdDqoPMuVvp7lwxfOA 3myA== MIME-Version: 1.0 Received: by 10.204.151.9 with SMTP id a9mr8244067bkw.2.1349891030983; Wed, 10 Oct 2012 10:43:50 -0700 (PDT) Received: by 10.204.158.10 with HTTP; Wed, 10 Oct 2012 10:43:50 -0700 (PDT) In-Reply-To: <023b01cda70b$2ec56660$8c503320$@augustcellars.com> References: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> <023b01cda70b$2ec56660$8c503320$@augustcellars.com> Date: Wed, 10 Oct 2012 13:43:50 -0400 Message-ID: From: Daniel Holth To: Jim Schaad Content-Type: text/plain; charset=ISO-8859-1 Cc: Anthony Nadalin , jose@ietf.org Subject: Re: [jose] Proposal - Create a SignTime Header 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, 10 Oct 2012 17:43:53 -0000 I have a use case. I am using JSON-JWS derived signatures for code signing. The payload is just a hash of a manifest that in turn contains hashes of the rest of the files in the archive. I would use a "sat" header field with the same symantics as "iat". A signature from the publisher (with no timestamp) combined with a signature from the package index (that only means "this package is at least this old") would be used to make a trust decision. Header: { "sat":1349890320, "alg": "Ed25519", "key": { "alg": "Ed25519", "vk": "tmAYCrSfj8gtJ10v3VkvW7jOndKmQIYE12hgnFu3cvk" } } Payload: { "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" } (http://www.python.org/dev/peps/pep-0427/#signed-wheel-files) Apologies if this is double-posted. Daniel Holth From James.H.Manger@team.telstra.com Wed Oct 10 15:45: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 C1B2D21F859C for ; Wed, 10 Oct 2012 15:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4bHJyE+scM7 for ; Wed, 10 Oct 2012 15:45:16 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id F2A7D21F854F for ; Wed, 10 Oct 2012 15:45:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,567,1344175200"; d="scan'208";a="95354676" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 11 Oct 2012 09:45:07 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6861"; a="87496579" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdni.tcif.telstra.com.au with ESMTP; 11 Oct 2012 09:45:07 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 11 Oct 2012 09:45:07 +1100 From: "Manger, James H" To: Anthony Nadalin , Jim Schaad , "jose@ietf.org" Date: Thu, 11 Oct 2012 09:45:05 +1100 Thread-Topic: [jose] Proposal - Create a SignTime Header Thread-Index: Ac2mS8+HPTmw6GuJR1iSC/75b9GqqAAKIxWAACWznQAAAK2pwAAKJGwg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDB1D7A9@WSMSG3153V.srv.dir.telstra.com> References: <01c401cda64c$9c22e3f0$d468abd0$@augustcellars.com> <023b01cda70b$2ec56660$8c503320$@augustcellars.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Proposal - Create a SignTime Header 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, 10 Oct 2012 22:45:16 -0000 SmltIHNhaWQ6DQo+PiBJIGRvIG5vdCBoYXZlIGEgY3VycmVudCB1c2UgY2FzZSBpbiB0ZXJtcyBv ZiBhIHNwZWNpZmljIGFwcGxpY2F0aW9uLiAgSQ0KPj4ganVzdCBub3RlIHRoYXQgaGF2aW5nIGEg dGltZSB0aGF0IHRoaW5ncyBhcmUgc2lnbmVkIGlzIGNvbW1vbiBwcmFjdGljZQ0KPj4gaW4gbWFu eSBkb2N1bWVudHMgdGhhdCBhcmUgdXNlZCB0b2RheS4gICBBcyBzdWNoIEkgYmVsaWV2ZSBpdCB3 aWxsIGJlIGENCj4+IGNvbW1vbiBhdHRyaWJ1dGUgb24gc2lnbmF0dXJlcyB0aGF0IHdpbGwgYmUg bmVlZGVkIGluIHRoZSBmdXR1cmUuDQoNCkFudGhvbnkgcmVzcG9uZGVkOg0KPiBSZWFsbHkgdGhp bmsgd2Ugc2hvdWxkIG5vdCBiZSBhZGRpbmcgdGhpbmdzIHcvbyB0aGUgcHJvcGVyIHVzZSBjYXNl LCBhcw0KPiB3ZSBoYXZlIGEgdG9uIG9mIG5pY2UgdG8gaGF2ZSB0aGluZ3MgYnV0IHdlIGFsc28g aGF2ZSBubyB1c2UgY2FzZXMgc28NCj4gd2UgaGF2ZSBub3QgYnVyZGVuZWQgdGhlIGdyb3VwIHdp dGggdGhlc2UNCg0KDQpJdCB3aWxsIGJlIG11Y2ggbXVjaCBoYXJkZXIgdG8gZGVmaW5lICYgZGVw bG95IHNvbWV0aGluZyBsaWtlIHNpZ25pbmcgdGltZQ0KaW4gdGhlIGZ1dHVyZSBhcyBpdCB3aWxs IGJyZWFrIGFsbCBleGlzdGluZyBjbGllbnRzIChhcyB0aGV5IHdpbGwgc2VlIGENCmZpZWxkIHRo ZXkgZG9uJ3QgdW5kZXJzdGFuZCBhbmQgcmVqZWN0IHRoZSBtZXNzYWdlKS4NCg0KSWYgd2Ugd2Fu dCB0byBwb3N0cG9uZSBsb3RzIG9mIG5pY2UtdG8taGF2ZSBmZWF0dXJlcyB0byBsYXRlciwgdGhl bg0Kd2UgbmVlZCB0byBjaGFuZ2UgdGhlIE1VU1QtdW5kZXJzdGFuZC1ldmVyeXRoaW5nIHJ1bGUg c28gdGhlcmUgaXMgbm90DQpzdWNoIGEgaGlnaCBwZW5hbHR5IGZvciBwb3N0cG9uaW5nLg0KDQot LQ0KSmFtZXMgTWFuZ2VyDQoNCg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQo+PiBPZiBKaW0gU2NoYWFkDQo+PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDks IDIwMTIgMTE6MzQgQU0NCj4+IFRvOiBqb3NlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbam9zZV0g UHJvcG9zYWwgLSBDcmVhdGUgYSBTaWduVGltZSBIZWFkZXINCj4+DQo+PiBJIHByb3Bvc2UgdGhh dCB3ZSBjcmVhdGUgYSBoZWFkZXIgZW50cnkgdGhhdCBpcyBvcHRpb25hbCBhbmQgY29udGFpbnMN Cj4+IGEgdGltZSB0aGF0IHRoZSBzaWduZXIgY2xhaW1zIHRoYXQgdGhleSBzaWduZWQgYXQuDQou Li4NCg== From James.H.Manger@team.telstra.com Wed Oct 10 16:58: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 41C0911E808D for ; Wed, 10 Oct 2012 16:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_39=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k478d7munTfJ for ; Wed, 10 Oct 2012 16:58:44 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1087B21F8607 for ; Wed, 10 Oct 2012 16:58:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,568,1344175200"; d="scan'208";a="102367243" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 11 Oct 2012 10:58:40 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6861"; a="93516534" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbni.tcif.telstra.com.au with ESMTP; 11 Oct 2012 10:58:41 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Thu, 11 Oct 2012 10:58:40 +1100 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Thu, 11 Oct 2012 10:58:39 +1100 Thread-Topic: [jose] Criticality of Headers - Possible Answers Thread-Index: Ac2mSkiUp3n/JeZUSwGlqjzWpoRZfAAX/oGw Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDB1D9DB@WSMSG3153V.srv.dir.telstra.com> References: <01c301cda64b$c133ae00$439b0a00$@augustcellars.com> In-Reply-To: <01c301cda64b$c133ae00$439b0a00$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Criticality of Headers - Possible Answers 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, 10 Oct 2012 23:58:45 -0000 SmltLA0KDQpBbm90aGVyIHBvc3NpYmxlIHNvbHV0aW9uOg0KDQo1LiBPbmUgcHJpbWFyeSBmaWVs ZCBpcyBjcml0aWNhbCB0byB1bmRlcnN0YW5kLg0KICAgW0lkZWFsbHkgYSBmaWVsZCBpZGVudGlm eWluZyB0aGUgdHlwZSBvZiBwcm90ZWN0aW9uOg0KICAgTUFDZWQsIGRpZy5zaWcuLCBzeW0uZW5j cnlwdGVkLCBwbGFpbi4uLl0NCiAgIFRoZSBzcGVjaWZpY2F0aW9uIG9mIGVhY2ggdmFsdWUgb2Yg dGhlIHByaW1hcnkNCiAgIGZpZWxkIGluZGljYXRlcyB3aGljaCBvdGhlciBmaWVsZHMgYXJlIGNy aXRpY2FsDQogICB0byB1bmRlcnN0YW5kIHdoZW4gdGhhdCBwcmltYXJ5IHZhbHVlIGlzIHByZXNl bnQuDQoNCg0KDQpNb3JlIGltcG9ydGFudCB0aGFuIHRoZXNlIDUgc3ludGF4ZXMgZm9yIGluZGlj YXRpbmcgY3JpdGljYWxpdHksIGhvd2V2ZXIsIGlzIGFncmVlaW5nIG9uIHdoYXQgd2UgYXJlIHRy eWluZyB0byBhY2hpZXZlIHdpdGggY3JpdGljYWxpdHkuIEkgZG9u4oCZdCB0aGluayB0aGUgY3Vy cmVudCBkcmFmdHMgcHJvdmlkZSBhbnkgY2x1ZS4NCg0KUG9zc2libGUgcmVxdWlyZW1lbnRzIGZv ciBtYWtpbmcgdGhpbmdzIGNyaXRpY2FsOg0KDQpBLiBXYW50IHRvIGJlIGFibGUgdG8gZGVmaW5l IG1lc3NhZ2VzIHdpdGggbmV3IHNlbWFudGljcyBpbiBmdXR1cmUsIHdpdGhvdXQgYW55IHJpc2sg dGhhdCBvbGQgaW1wbGVtZW50YXRpb25zIHdpbGwgbWlzaW50ZXJwcmV0IHRoZW0gd2l0aCBvbGQg c2VtYW50aWNzLg0KDQpCLiBXYW50IHRvIGJlIGFibGUgdG8gKnJlZGVmaW5lKiAob3IgY29uc3Ry YWluKSB0aGUgc2VtYW50aWNzIG9mICpleGlzdGluZyogZmllbGRzIGluIGZ1dHVyZSwgd2l0aG91 dCBhbnkgcmlzayB0aGF0IG9sZCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBtaXNpbnRlcnByZXQgdGhl bSB3aXRoIG9sZCBzZW1hbnRpY3MgKG9yIHdpdGhvdXQgdGhlIGNvbnN0cmFpbnRzKS4NCg0KQy4g V2FudCB0byBwcmV2ZW50IGxhcmdlIGJsb2JzIG9mIGlnbm9yZWQgZGF0YSBhcHBlYXJpbmcgaW4g bWVzc2FnZXMsIGFzIHNpbWlsYXIgYmxvYnMgaGF2ZSBiZWVuIHVzZWQgdG8gY3JlYXRlIGhhc2gg Y29sbGlzaW9ucyBiZXR3ZWVuIGxlZ2l0aW1hdGUgJiBtYWxpY2lvdXMgY2VydGlmaWNhdGVzIHRo YXQgdXNlIHdlYWsgYWxnb3JpdGhtcyAoZWcgTUQ1KS4NCg0KRC4gV2FudCB0byBzdHJvbmdseSBk aXNjb3VyYWdlIGZ1dHVyZSBleHRlbnNpb25zIChmZWF0dXJlLWNyZWVwKSwgdW5kZXIgdGhlIHBo aWxvc29waHkgdGhhdCBldmVuIHdlbGwtaW50ZW50aW9uZWQgZXh0ZW5zaW9ucyB0ZW5kIHRvIGRv IG1vcmUgaGFybSAoYnkgYWRkaW5nIGNvbXBsZXhpdHkgdGhhdCBpcyBvbmx5IGRlcGxveWVkIHNw b3JhZGljYWxseSkgdGhhbiB0aGUgZ29vZCBvZiBhbnkgbmV3IGZ1bmN0aW9uYWxpdHkgdGhleSBi cmluZzsgS0lTUyBwcmluY2lwbGU7IHZlcnNpb24gMS4wIGlzIHZhc3RseSBtb3JlIGltcG9ydGFu dCB0aGF0IGFueSBzdWJzZXF1ZW50IHZlcnNpb24uDQoNCkUuIExvb3NlbHkgY291cGxpbmcgY2xp ZW50cyBhbmQgc2VydmVycyBpcyBnZW5lcmFsbHkgY29uc2lkZXJlZCBhIGdvb2QgdGhpbmc7IGJ1 dCBzdHJvbmdseSBjb3VwbGluZyB0aGVtIGlzIG1vcmUgYXBwcm9wcmlhdGUgZm9yIGEgc2VjdXJl IG1lc3NhZ2UgZm9ybWF0IGZvciBbaW5zZXJ0IGEgcmVhc29uIGhlcmVdLiBBIHBvc3NpYmxlIHJl YXNvbiBpcyB0aGF0IHBlb3BsZSBhcmUgdG9vIGxpa2VseSB0byBjaG9vc2UgdG8gbWFrZSBhbiBl eHRlbnNpb24gbm9uLWNyaXRpY2FsIGZvciBzaG9ydC10ZXJtIGVhc2Ugb2YgaW50ZXJvcGVyYWJp bGl0eSwgaW5zdGVhZCBvZiBtYWtpbmcgaXQgY3JpdGljYWwgZm9yIGJldHRlciBsb25nLXRlcm0g c2VjdXJpdHkuDQoNCkYuIC4uLg0KDQoNClRoZSBNVVNULXVuZGVyc3RhbmQtZXZlcnl0aGluZyBy dWxlIGZlZWxzIGFwcHJvcHJpYXRlIGZvciBFLCBtYXliZSBmb3IgRCwgZG9lc24ndCBhY2hpZXZl IEMsIGFuZCBpcyAoaGFybWZ1bGx5KSBmYXIgbW9yZSBkcmFjb25pYW4gdGhhbiBuZWNlc3Nhcnkg Zm9yIEIgb3IgQS4NCkkgdGhpbmsgSk9TRSBzaG91bGQgYWltIGZvciByZXF1aXJlbWVudCBBLg0K DQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KPiBKaW0gU2NoYWFkDQo+IFNlbnQ6IFdlZG5lc2RheSwgMTAgT2N0b2Jl ciAyMDEyIDU6MjggQU0NCj4gVG86IGpvc2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2pvc2VdIENy aXRpY2FsaXR5IG9mIEhlYWRlcnMgLSBQb3NzaWJsZSBBbnN3ZXJzDQo+IA0KPiBJIGFtIGxvb2tp bmcgdG8gZXN0YWJsaXNoIHRoZSBwb3NzaWJsZSBhbnN3ZXJzIHRoYXQgd2UgaGF2ZSBmb3INCj4g Y3JpdGljYWxpdHkNCj4gb2YgaGVhZGVyIGZpZWxkcyBhbmQgdGhlbiB3YW50IHRvIGZvbGxvdyBp dCB1cCB3aXRoIGEgZGlzY3Vzc2lvbg0KPiBob3BlZnVsbHkNCj4gbGVhZGluZyB0byBjbG9zdXJl Lg0KPiANCj4gUGxlYXNlIHJlc3BvbmQgaWYgSSBhbSBtaXNzaW5nIGFueSBvZiB0aGUgZGlmZmVy ZW50IHNvbHV0aW9ucyBvciBpZiB5b3UNCj4gdGhpbmsgdGhhdCBJIGhhdmUgYWxsIG9mIHRoZSBz b2x1dGlvbnMgdGhhdCB3ZXJlIGRpc2N1c3NlZCBmb3IgdGhlDQo+IG9wdGlvbnMuDQo+IEFsc28g cGxlYXNlIGZlZWwgZnJlZSB0byBhdWdtZW50IHRoZSB3b3JkaW5nIEkgaGF2ZSBiZWxvdyBvbiB0 aGUNCj4gZGVzY3JpcHRpb24NCj4gb2YgdGhlIHNvbHV0aW9uLiAgSSB3YW50IHRvIGRlYWwgd2l0 aCBwcm9zIGFuZCBjb25zIGFmdGVyIHdlIGhhdmUgdGhlDQo+IGRlc2NyaXB0aW9ucyBhZ3JlZWQg b24uDQo+IA0KPiAxLiAgQW55IGhlYWRlcnMgbm90IGNvdmVyZWQgYnkgdGhlIGN1cnJlbnQgZG9j dW1lbnQgZ2VuZXJhdGUgYW4gZXJyb3IuDQo+IFRoaXMNCj4gaXMgdGhlIGN1cnJlbnQgc3RhdGUg b2YgdGhlIGRvY3VtZW50IGFuZCBpcyB0aGUgYWxsIGhlYWRlcnMgYXJlDQo+IGNyaXRpY2FsDQo+ IHNvbHV0aW9uLg0KPiANCj4gMi4gIEFueSBoZWFkZXJzIG5vdCBjb3ZlcmVkIGJ5IHRoZSBjdXJy ZW50IGRvY3VtZW50IGFyZSBpZ25vcmVkLiAgVGhpcw0KPiBpcw0KPiB0aGUgbm8gaGVhZGVycyBh cmUgY3JpdGljYWwgc29sdXRpb24uDQo+IA0KPiAzLiAgSGVhZGVycyBhcmUgdG8gYmUgZGVjb3Jh dGVkIGluIHNvbWUgbWFubmVyIHRvIHNheSBpZiB0aGV5IGFyZQ0KPiBjcml0aWNhbC4NCj4gVGhl cmUgYXJlIGZvdXIgcG9zc2libGUgZGVjb3JhdGlvbiBtZXRob2RzIHRoYXQgSSBoYXZlIHNlZW4g cHJvcG9zZWQuDQo+IA0KPiBhKSAgQ2hhbmdlIHRoZSBmaWVsZCBuYW1lIHRvIGluZGljYXRlIGl0 IGlzIGNyaXRpY2FsIChhbGEgIlNpZ25UaW1lISIpDQo+IGIpICBDaGFuZ2UgdGhlIGZpZWxkIG5h bWUgdG8gaW5kaWNhdGUgaXQgY2FuIGJlIGlnbm9yZWQgKGFsYQ0KPiAiU2lnblRpbWU/IikNCj4g YykgICBDcmVhdGUgYSBoZWFkZXIgdGhhdCBoYXMgYSBsaXN0IG9mIGVpdGhlciBjcml0aWNhbCAo b3IgaWdub3JhYmxlKQ0KPiBmaWVsZA0KPiBuYW1lcw0KPiBkKSAgU2VwYXJhdGUgdGhlIG5vbi1j cml0aWNhbCBoZWFkZXIgZmllbGRzIGludG8gYSBzdWIgaGVhZGVyDQo+IA0KPiA0LiAgVGhlIGNv cmUgc3BlY2lmaWNhdGlvbiBzaG91bGQgaWdub3JlIGFsbCBpc3N1ZXMgb2YgY3JpdGljYWxpdHkg YW5kDQo+IGp1c3QNCj4gZGVmaW5lIGEgY29tbW9uIHNldCBvZiBoZWFkZXJzLiAgSXQgaXMgdXAg dG8gdGhlIGFwcGxpY2F0aW9uIHRvIGRlZmluZQ0KPiB3aGljaA0KPiBoZWFkZXJzIGFyZSBjcml0 aWNhbCwgd2hpY2ggY2FuIGJlIGlnbm9yZWQsIGFuZCBpdCBjYW4gZGVmaW5lIG5ldw0KPiBoZWFk ZXJzIHRvDQo+IG1lZXQgaXQncyBuZWVkcy4NCj4gDQo+IEppbQ0KPiANCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGpvc2UgbWFpbGluZyBs aXN0DQo+IGpvc2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9qb3NlDQo= From ietf@augustcellars.com Wed Oct 10 17:13: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 4D1F711E80A6 for ; Wed, 10 Oct 2012 17:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.028 X-Spam-Level: X-Spam-Status: No, score=-3.028 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irkuva6tMu3z for ; Wed, 10 Oct 2012 17:13:14 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 69F3611E808D for ; Wed, 10 Oct 2012 17:13:14 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (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 ECBED38F2F; Wed, 10 Oct 2012 17:13:13 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <01c301cda64b$c133ae00$439b0a00$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114FDB1D9DB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDB1D9DB@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 10 Oct 2012 17:11:46 -0700 Message-ID: <027501cda745$00bfe350$023fa9f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIefy0aWjoz2MksrHm3HEpeXxOBuQGL4uX4lwUr04A= Content-Language: en-us Subject: Re: [jose] Criticality of Headers - Possible Answers 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, 11 Oct 2012 00:13:15 -0000 James, I think that is an interesting set of reasons. I would add the = following to the list F. Application developers and specification writes are unable to = correct assess what is and is not important from the point of view of = security. It is therefore better that the signature header fields are = fully defined independent of any possible application specifications. While I disagree (in part) with the above statement for a number of = reasons, I believe that there are number of people who would believe = that it is a true statement. I agree that application developers and = specification writers don't understand all of the implications, but I = believe we can provide good guidance to them as part of this = specficiation. Jim > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Wednesday, October 10, 2012 4:59 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Criticality of Headers - Possible Answers >=20 > Jim, >=20 > Another possible solution: >=20 > 5. One primary field is critical to understand. > [Ideally a field identifying the type of protection: > MACed, dig.sig., sym.encrypted, plain...] > The specification of each value of the primary > field indicates which other fields are critical > to understand when that primary value is present. >=20 >=20 >=20 > More important than these 5 syntaxes for indicating criticality, = however, is > agreeing on what we are trying to achieve with criticality. I don t = think the > current drafts provide any clue. >=20 > Possible requirements for making things critical: >=20 > A. Want to be able to define messages with new semantics in future, = without > any risk that old implementations will misinterpret them with old = semantics. >=20 > B. Want to be able to *redefine* (or constrain) the semantics of = *existing* > fields in future, without any risk that old implementations will = misinterpret > them with old semantics (or without the constraints). >=20 > C. Want to prevent large blobs of ignored data appearing in messages, = as > similar blobs have been used to create hash collisions between = legitimate & > malicious certificates that use weak algorithms (eg MD5). >=20 > D. Want to strongly discourage future extensions (feature-creep), = under the > philosophy that even well-intentioned extensions tend to do more harm = (by > adding complexity that is only deployed sporadically) than the good of = any > new functionality they bring; KISS principle; version 1.0 is vastly = more > important that any subsequent version. >=20 > E. Loosely coupling clients and servers is generally considered a good = thing; > but strongly coupling them is more appropriate for a secure message = format > for [insert a reason here]. A possible reason is that people are too = likely to > choose to make an extension non-critical for short-term ease of > interoperability, instead of making it critical for better long-term = security. >=20 > F. ... >=20 >=20 > The MUST-understand-everything rule feels appropriate for E, maybe for = D, > doesn't achieve C, and is (harmfully) far more draconian than = necessary for B > or A. > I think JOSE should aim for requirement A. >=20 > -- > James Manger >=20 >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of Jim Schaad > > Sent: Wednesday, 10 October 2012 5:28 AM > > To: jose@ietf.org > > Subject: [jose] Criticality of Headers - Possible Answers > > > > I am looking to establish the possible answers that we have for > > criticality of header fields and then want to follow it up with a > > discussion hopefully leading to closure. > > > > Please respond if I am missing any of the different solutions or if > > you think that I have all of the solutions that were discussed for = the > > options. > > Also please feel free to augment the wording I have below on the > > description of the solution. I want to deal with pros and cons = after > > we have the descriptions agreed on. > > > > 1. Any headers not covered by the current document generate an = error. > > This > > is the current state of the document and is the all headers are > > critical solution. > > > > 2. Any headers not covered by the current document are ignored. = This > > is the no headers are critical solution. > > > > 3. Headers are to be decorated in some manner to say if they are > > critical. > > There are four possible decoration methods that I have seen = proposed. > > > > a) Change the field name to indicate it is critical (ala = "SignTime!") > > b) Change the field name to indicate it can be ignored (ala > > "SignTime?") > > c) Create a header that has a list of either critical (or = ignorable) > > field > > names > > d) Separate the non-critical header fields into a sub header > > > > 4. The core specification should ignore all issues of criticality = and > > just define a common set of headers. It is up to the application to > > define which headers are critical, which can be ignored, and it can > > define new headers to meet it's needs. > > > > Jim > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Oct 12 16:38: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 6369521F8559 for ; Fri, 12 Oct 2012 16:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+KiMS1OErJy for ; Fri, 12 Oct 2012 16:38:39 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7A21F8554 for ; Fri, 12 Oct 2012 16:38:39 -0700 (PDT) Received: from BL2FFO11FD009.protection.gbl (10.173.161.203) by BL2FFO11HUB031.protection.gbl (10.173.161.55) with Microsoft SMTP Server (TLS) id 15.0.516.0; Fri, 12 Oct 2012 23:39:39 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Fri, 12 Oct 2012 23:39:39 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Fri, 12 Oct 2012 23:38:35 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: OAuth 2.0 RFCs Completed Thread-Index: Ac2o0g5UnfkkfGxrQSWten+ni7nRywAAJKAA Date: Fri, 12 Oct 2012 23:38:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366848217@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943668481BD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668481BD@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366848217TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(54164002)(69234002)(51856001)(46102001)(42186003)(47446002)(44976002)(74662001)(31966008)(5343655001)(33656001)(74502001)(15202345001)(512954001)(15395725001)(8716001)(16826001)(47736001)(5343635001)(3846001)(5343665001)(4396001)(4196001)(47976001)(1076001)(16696001)(49866001)(50986001)(20776001)(16406001)(316001)(3746001)(3556001)(6606295001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0632519F33 Subject: [jose] FW: OAuth 2.0 RFCs Completed 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, 12 Oct 2012 23:38:40 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366848217TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, October 12, 2012 4:34 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.0 RFCs Completed The OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750. Thanks to all of you who brought us to this important mileston= e! I wrote about this at http://self-issued.info/?p=3D870 and Dick wrote about= it at http://dickhardt.org/2012/10/oauth-2-0/. Now, on to approving the next set of related standards! Thanks all! -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366848217TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

 

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, October 12, 2012 4:34 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2.0 RFCs Completed

 

Th= e OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750.  Thanks to all of you who brought us to this important m= ilestone!

 

I = wrote about this at http://self-issued.info/?p=3D8= 70 and Dick wrote about it at http://dickhardt.org/20= 12/10/oauth-2-0/.

 

No= w, on to approving the next set of related standards!

 

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         Thanks all!=

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         -- Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394366848217TK5EX14MBXC284r_-- From internet-drafts@ietf.org Mon Oct 15 23:18: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 CA1D721F8618; Mon, 15 Oct 2012 23:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfppk5xhBguq; Mon, 15 Oct 2012 23:18:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48ADA21F8621; Mon, 15 Oct 2012 23:18:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016061844.29941.22965.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 23:18:44 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-06.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, 16 Oct 2012 06:18:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-06.txt Pages : 40 Date : 2012-10-15 Abstract: JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 15 23:23: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 2D46421F897C; Mon, 15 Oct 2012 23:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuzdfgjQgBWl; Mon, 15 Oct 2012 23:22:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF4821F8984; Mon, 15 Oct 2012 23:22:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016062259.30865.48409.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 23:22:59 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-06.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, 16 Oct 2012 06:23:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-06.txt Pages : 50 Date : 2012-10-15 Abstract: JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 15 23: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 EF04721F87FF; Mon, 15 Oct 2012 23:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb-ONn7sXRYm; Mon, 15 Oct 2012 23:25:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6BB21F8875; Mon, 15 Oct 2012 23:25:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016062548.7674.42999.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 23:25:48 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-06.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, 16 Oct 2012 06:25:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-06.txt Pages : 12 Date : 2012-10-15 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a public key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 15 23:27:56 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 E462021F8888; Mon, 15 Oct 2012 23:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NNLxs9UZ78V; Mon, 15 Oct 2012 23:27:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8A121F89A2; Mon, 15 Oct 2012 23:27:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016062756.30865.44220.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 23:27:56 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-06.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, 16 Oct 2012 06:27:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-06.txt Pages : 40 Date : 2012-10-15 Abstract: The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Mon Oct 15 23:59: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 D862521F8758 for ; Mon, 15 Oct 2012 23:59:16 -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.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZwiWDNwzj0e for ; Mon, 15 Oct 2012 23:59:12 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4F13921F8750 for ; Mon, 15 Oct 2012 23:59:10 -0700 (PDT) Received: from mail31-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 06:59:09 +0000 Received: from mail31-am1 (localhost [127.0.0.1]) by mail31-am1-R.bigfish.com (Postfix) with ESMTP id B2451A02C9 for ; Tue, 16 Oct 2012 06:59:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail31-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1 (MessageSwitch) id 1350370746406674_25753; Tue, 16 Oct 2012 06:59:06 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.230]) by mail31-am1.bigfish.com (Postfix) with ESMTP id 60418400049 for ; Tue, 16 Oct 2012 06:59:06 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 06:59:06 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 06:59:02 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JOSE and JWT specs incorporating working group decisions since IETF 84 Thread-Index: Ac2ra69SDtelvfepRBCO1gAjjbxxsQ== Date: Tue, 16 Oct 2012 06:59:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] JOSE and JWT specs incorporating working group decisions since IETF 84 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, 16 Oct 2012 06:59:17 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (J= WS, JWE, JWK, JWA, JWT) specifications have been released. These versions = incorporate the decisions made by the JOSE working group during and since IETF 84. The primary change was revising the JWE format to always use AEAD encryptio= n algorithms. The companion change was defining two new composite AEAD alg= orithms "A128CBC+HS256" and "A256CBC+HS512" that use AES CBC to perform enc= ryption and matching HMAC SHA-2 algorithms to perform an integrity check on= the ciphertext and the parameters used to create it. Other than that, all changes were local in scope, with no changes to JWS - = other than changing the format of the "x5c" (X.509 Certificate Chain) from = a string containing a list of certificate values to an array of strings con= taining certificate values. Likewise, the only changes to JWT were to trac= k changes made in the specs that it uses. Having addressed all the open issues with resolutions with apparent working= group consensus, it's my hope that the working group will decide to send t= hese specifications to working group last call at IETF 85. The companion JWS JSON Serialization and JWE JSON Serialization specs were = also updated. The working group specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04 The individual submission specifications are available at: * http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization= -02 * http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization= -02 The document history entries (also in the specifications) are as follows: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06 * Changed x5c (X.509 Certificate Chain) representation from being a sin= gle string to being an array of strings, each containing a single base64 en= coded DER certificate value, representing elements of the certificate chain= . * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06 * Removed the int and kdf parameters and defined the new composite AEAD= algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of A= ES CBC, which required the use of separate integrity and key derivation fun= ctions. * Included additional values in the Concat KDF calculation -- the desir= ed output size and the algorithm value, and optionally PartyUInfo and Party= VInfo values. Added the optional header parameters apu (agreement PartyUInf= o), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encry= ption PartyVInfo). Updated the KDF examples accordingly. * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. * Changed x5c (X.509 Certificate Chain) representation from being a sin= gle string to being an array of strings, each containing a single base64 en= coded DER certificate value, representing elements of the certificate chain= . * Added an AES Key Wrap example. * Reordered the encryption steps so CMK creation is first, when require= d. * Correct statements in examples about which algorithms produce reprodu= cible results. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 * Changed the name of the JWK RSA exponent parameter from exp to xpo so= as to allow the potential use of the name exp for a future extension that = might define an expiration parameter for keys. (The exp name is already use= d for this purpose in the JWT specification.) * Clarify that the alg (algorithm family) member is REQUIRED. * Correct an instance of "JWK" that should have been "JWK Set". * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06 * Removed the int and kdf parameters and defined the new composite AEAD= algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of A= ES CBC, which required the use of separate integrity and key derivation fun= ctions. * Included additional values in the Concat KDF calculation -- the desir= ed output size and the algorithm value, and optionally PartyUInfo and Party= VInfo values. Added the optional header parameters apu (agreement PartyUInf= o), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encry= ption PartyVInfo). * Changed the name of the JWK RSA exponent parameter from exp to xpo so= as to allow the potential use of the name exp for a future extension that = might define an expiration parameter for keys. (The exp name is already use= d for this purpose in the JWT specification.) * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04 * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. * Reference RFC 6755 -- An IETF URN Sub-Namespace for OAuth. http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-02 * Changed to use an array of structures for per-recipient values, rathe= r than a set of parallel arrays. http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-02 * Changed to use an array of structures for per-recipient values, rathe= r than a set of parallel arrays. * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-06= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0= 6.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-06.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0= 6.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-04.ht= ml * http://self-issued.info/docs/draft-jones-jose-jws-json-serializati= on-02.html * http://self-issued.info/docs/draft-jones-jose-jwe-json-serializati= on-02.html -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New versions of the JSON WEB {Signature,Encryption,K= ey,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been rel= eased.  These versions incorporate the decisions made by the JOSE working group dur= ing and since IETF 84.

 

The primary change was revising the JWE format to al= ways use AEAD encryption algorithms.  The companion change was definin= g two new composite AEAD algorithms “A128CBC= 3;HS256” and “A256CBC+HS5= 12” that use AES CBC to perform encryption and matching HMAC SHA-2 algorithms = to perform an integrity check on the ciphertext and the parameters used to = create it.

 

Other than that, all changes were local in scope, wi= th no changes to JWS – other than changing the format of the “<= tt>x5c” (X.509 Certificate Chain) from = a string containing a list of certificate values to an array of strings containing certificate values.  Likewise, the only c= hanges to JWT were to track changes made in the specs that it uses.

 

Having addressed all the open issues with resolution= s with apparent working group consensus, it’s my hope that the workin= g group will decide to send these specifications to working group last call= at IETF 85.

 

The companion JWS JSON Serialization and JWE JSON Se= rialization specs were also updated.

 

The working group specifications are available at:

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

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

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

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

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-04

 

The individual submission specifications are availab= le at:

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

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

 

The document history entries (also in the specificat= ions) are as follows:

 

http://tools.ietf.org/html/draft-ietf-jose-json-we= b-signature-06

  • Changed x5c (X.509 Certificate Chain) representation from = being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the = certificate chain.
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.

 

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-encryption-06

  • Removed the int and kdf parameters and defined the new composite AEAD = algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AE= S CBC, which required the use of separate integrity and key derivation func= tions.
  • Included additional values in the Concat KDF calc= ulation -- the desired output size and the algorithm value, and optionally = PartyUInfo and PartyVInfo values. Added the optional header parameters apu<= /span> (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo). Updated the KDF examp= les accordingly.
  • Promoted Initialization Vector from being a heade= r parameter to being a top-level JWE element. This saves approximately 16 b= ytes in the compact serialization, which is a significant savings for some use cas= es. Promoting the Initialization Vector out of the header also avoids repea= ting this shared value in the JSON serialization.
  • Changed x5c (X.509 Certificate Chain) representation from = being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the = certificate chain.
  • Added an AES Key Wrap example.
  • Reordered the encryption steps so CMK creation is= first, when required.
  • Correct statements in examples about which algori= thms produce reproducible results.

 

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

  • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an ex= piration parameter for keys. (The exp name is already used for this purpose in the J= WT specification.)
  • Clarify that the alg (algorithm family) member is REQUIRED.
  • Correct an instance of "JWK" that shoul= d have been "JWK Set".
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.

 

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

  • Removed the int and kdf parameters and defined the new composite AEAD = algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AE= S CBC, which required the use of separate integrity and key derivation func= tions.
  • Included additional values in the Concat KDF calc= ulation -- the desired output size and the algorithm value, and optionally = PartyUInfo and PartyVInfo values. Added the optional header parameters apu<= /span> (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo).
  • Changed the name of the JWK RSA exponent paramete= r from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an ex= piration parameter for keys. (The exp name is already used for this purpose in the J= WT specification.)
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.

 

http://tools.ietf.org/html/draft-ietf-oauth-json-web-= token-04

  • Promoted Initialization Vector from being a header parameter to being a = top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cas= es. Promoting the Initialization Vector out of the header also avoids repea= ting this shared value in the JSON serialization.
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.
  • Reference RFC 6755 -- An IETF URN Sub-Namespace f= or OAuth.

 

http://tools.ietf.org/html/draft-jones-jose-j= ws-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather t= han a set of parallel arrays.

 

http://tools.ietf.org/html/draft-jones-jose-j= we-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather t= han a set of parallel arrays.
  • Promoted Initialization Vector from being a heade= r parameter to being a top-level JWE element. This saves approximately 16 b= ytes in the compact serialization, which is a significant savings for some use cas= es. Promoting the Initialization Vector out of the header also avoids repea= ting this shared value in the JSON serialization.

 

HTML formatted versions are available at:=

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

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

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

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

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-04.html

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

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

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_-- From vladimir@nimbusds.com Tue Oct 16 03:05:19 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 A8E8021F8892 for ; Tue, 16 Oct 2012 03:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.051 X-Spam-Level: X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH8I6XoYevFB for ; Tue, 16 Oct 2012 03:05:18 -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 224A321F8890 for ; Tue, 16 Oct 2012 03:05:17 -0700 (PDT) Received: (qmail 9749 invoked from network); 16 Oct 2012 09:33:25 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 16 Oct 2012 09:33:25 -0000 Received: (qmail 28416 invoked by uid 99); 16 Oct 2012 09:33:25 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.244.174 User-Agent: Workspace Webmail 5.6.26 Message-Id: <20121016023324.cc40c4f3d92d2001859047cd8cabb9ab.1b58107126.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Tue, 16 Oct 2012 02:33:24 -0700 Mime-Version: 1.0 Subject: [jose] JWE -06: Terminology - JWE IV and integrity value 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, 16 Oct 2012 10:05:20 -0000 Thank you guys for pushing the updates specs out.=0A=0ARegarding JWE -06 se= ction 2. Terminology:=0A=0AIt could be helpful to mention for "JWE Initiali= zation Vector" and "JWE=0AIntegrity Values" that these can also be empty, l= ike said for "JWE=0AEncrypted Key".=0A=0A=0AVladimir=0A=0A--=0AVladimir Dzh= uvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A =0A=0A From vladimir@nimbusds.com Tue Oct 16 04:25:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A063A21F8962 for ; Tue, 16 Oct 2012 04:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s--XcuFHkCrv for ; Tue, 16 Oct 2012 04:25:02 -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 1F0AC21F893D for ; Tue, 16 Oct 2012 04:25:01 -0700 (PDT) Received: (qmail 475 invoked from network); 16 Oct 2012 11:25:00 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 16 Oct 2012 11:24:56 -0000 Received: (qmail 11054 invoked by uid 99); 16 Oct 2012 11:24:56 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.244.174 User-Agent: Workspace Webmail 5.6.26 Message-Id: <20121016042455.cc40c4f3d92d2001859047cd8cabb9ab.6d065f381d.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "jose@ietf.org" Date: Tue, 16 Oct 2012 04:24:55 -0700 Mime-Version: 1.0 Subject: Re: [jose] JOSE and JWT specs incorporating working group decisions since IETF 84 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, 16 Oct 2012 11:25:03 -0000 I just incorporated the -06 spec changes into the Nimbus JOSE+JWT=0Alibrary= . Not only tokens are shorter now, but the core library code was=0Areduced = too! Excellent work!=0A=0ACheers,=0A=0AVladimir=0A=0APS: I'm looking for co= ntributors to port the missing JWE algs: =0Ahttps://bitbucket.org/nimbusds/= nimbus-jose-jwt=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@= nimbusds.com=0A =0A=0A=0A=0A=0A=0A=0A=0A-------- Original Message --------= =0ASubject: [jose] JOSE and JWT specs incorporating working group=0Adecisio= ns since IETF 84=0AFrom: Mike Jones =0ADate: T= ue, October 16, 2012 7:59 am=0ATo: "jose@ietf.org" =0A=0A N= ew versions of the JSON WEB=0A{Signature,Encryption,Key,Algorithms,Token} (= JWS, JWE, JWK, JWA, JWT)=0Aspecifications have been released. These versio= ns incorporate the=0Adecisions made by the JOSE working group during and si= nce IETF 84.=0A =0A The primary change was revising the JWE format to alwa= ys use AEAD=0Aencryption algorithms. The companion change was defining two= new=0Acomposite AEAD algorithms =E2=80=9CA128CBC+HS256=E2=80=9D and =E2=80= =9CA256CBC+HS512=E2=80=9D=0Athat use AES CBC to perform encryption and matc= hing HMAC SHA-2=0Aalgorithms to perform an integrity check on the ciphertex= t and the=0Aparameters used to create it.=0A =0A Other than that, all chan= ges were local in scope, with no changes to=0AJWS =E2=80=93 other than chan= ging the format of the =E2=80=9Cx5c=E2=80=9D (X.509=0ACertificate Chain) fr= om a string containing a list of certificate values=0Ato an array of string= s containing certificate values. Likewise, the=0Aonly changes to JWT were = to track changes made in the specs that it=0Auses.=0A =0A Having addressed= all the open issues with resolutions with apparent=0Aworking group consens= us, it=E2=80=99s my hope that the working group will=0Adecide to send these= specifications to working group last call at IETF=0A85.=0A =0A The compan= ion JWS JSON Serialization and JWE JSON Serialization specs=0Awere also upd= ated.=0A =0A The working group specifications are available at:=0A =C2=B7 = =0Ahttp://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06= =0A =C2=B7 =0Ahttp://tools.ietf.org/html/draft-ietf-jose-json-web-enc= ryption-06=0A =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json= -web-key-06=0A =C2=B7 =0Ahttp://tools.ietf.org/html/draft-ietf-jose-j= son-web-algorithms-06=0A =C2=B7 http://tools.ietf.org/html/draft-iet= f-oauth-json-web-token-04=0A =0A The individual submission specifications = are available at:=0A =C2=B7 =0Ahttp://tools.ietf.org/html/draft-jones= -jose-jws-json-serialization-02=0A =C2=B7 =0Ahttp://tools.ietf.org/ht= ml/draft-jones-jose-jwe-json-serialization-02=0A =0A The document history = entries (also in the specifications) are as=0Afollows:=0A =0A http://tools= .ietf.org/html/draft-ietf-jose-json-web-signature-06=0A Changed x5c (X.509= Certificate Chain) representation from being a=0Asingle string to being an= array of strings, each containing a single=0Abase64 encoded DER certificat= e value, representing elements of the=0Acertificate chain. Applied changes = made by the RFC Editor to RFC 6749's=0Aregistry language to this specificat= ion. =0A=0A =0A http://tools.ietf.org/html/draft-ietf-jose-json-web-encryp= tion-06=0A Removed the int and kdf parameters and defined the new composit= e AEAD=0Aalgorithms A128CBC+HS256 and A256CBC+HS512 to replace the former u= ses of=0AAES CBC, which required the use of separate integrity and key deri= vation=0Afunctions. Included additional values in the Concat KDF calculatio= n --=0Athe desired output size and the algorithm value, and optionally=0APa= rtyUInfo and PartyVInfo values. Added the optional header parameters=0Aapu = (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption=0AParty= UInfo), and epv (encryption PartyVInfo). Updated the KDF examples=0Aaccordi= ngly. Promoted Initialization Vector from being a header=0Aparameter to bei= ng a top-level JWE element. This saves approximately 16=0Abytes in the comp= act serialization, which is a significant savings for=0Asome use cases. Pro= moting the Initialization Vector out of the header=0Aalso avoids repeating = this shared value in the JSON serialization.=0AChanged x5c (X.509 Certifica= te Chain) representation from being a single=0Astring to being an array of = strings, each containing a single base64=0Aencoded DER certificate value, r= epresenting elements of the certificate=0Achain. Added an AES Key Wrap exam= ple. Reordered the encryption steps so=0ACMK creation is first, when requir= ed. Correct statements in examples=0Aabout which algorithms produce reprodu= cible results. =0A=0A =0A http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-06=0A Changed the name of the JWK RSA exponent parameter from exp = to xpo so=0Aas to allow the potential use of the name exp for a future exte= nsion=0Athat might define an expiration parameter for keys. (The exp name i= s=0Aalready used for this purpose in the JWT specification.) Clarify that= =0Athe alg (algorithm family) member is REQUIRED. Correct an instance of=0A= "JWK" that should have been "JWK Set". Applied changes made by the RFC=0AEd= itor to RFC 6749's registry language to this specification. =0A=0A =0A htt= p://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06=0A Removed = the int and kdf parameters and defined the new composite AEAD=0Aalgorithms = A128CBC+HS256 and A256CBC+HS512 to replace the former uses of=0AAES CBC, wh= ich required the use of separate integrity and key derivation=0Afunctions. = Included additional values in the Concat KDF calculation --=0Athe desired o= utput size and the algorithm value, and optionally=0APartyUInfo and PartyVI= nfo values. Added the optional header parameters=0Aapu (agreement PartyUInf= o), apv (agreement PartyVInfo), epu (encryption=0APartyUInfo), and epv (enc= ryption PartyVInfo). Changed the name of the=0AJWK RSA exponent parameter f= rom exp to xpo so as to allow the potential=0Ause of the name exp for a fut= ure extension that might define an=0Aexpiration parameter for keys. (The ex= p name is already used for this=0Apurpose in the JWT specification.) Applie= d changes made by the RFC=0AEditor to RFC 6749's registry language to this = specification. =0A=0A =0A http://tools.ietf.org/html/draft-ietf-oauth-json= -web-token-04=0A Promoted Initialization Vector from being a header parame= ter to being=0Aa top-level JWE element. This saves approximately 16 bytes i= n the=0Acompact serialization, which is a significant savings for some use= =0Acases. Promoting the Initialization Vector out of the header also avoids= =0Arepeating this shared value in the JSON serialization. Applied changes= =0Amade by the RFC Editor to RFC 6749's registry language to this=0Aspecifi= cation. Reference RFC 6755 -- An IETF URN Sub-Namespace for=0AOAuth. =0A=0A= =0A http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-02= =0A Changed to use an array of structures for per-recipient values, rather= =0Athan a set of parallel arrays. =0A=0A =0A http://tools.ietf.org/html/dr= aft-jones-jose-jwe-json-serialization-02=0A Changed to use an array of str= uctures for per-recipient values, rather=0Athan a set of parallel arrays. P= romoted Initialization Vector from being=0Aa header parameter to being a to= p-level JWE element. This saves=0Aapproximately 16 bytes in the compact ser= ialization, which is a=0Asignificant savings for some use cases. Promoting = the Initialization=0AVector out of the header also avoids repeating this sh= ared value in the=0AJSON serialization. =0A=0A =0A HTML formatted versions= are available at:=0A =C2=B7 =0Ahttp://self-issued.info/docs/draft-ie= tf-jose-json-web-signature-06.html=0A =C2=B7 =0Ahttp://self-issued.in= fo/docs/draft-ietf-jose-json-web-encryption-06.html=0A =C2=B7 =0Ahttp= ://self-issued.info/docs/draft-ietf-jose-json-web-key-06.html=0A =C2=B7 = =0Ahttp://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-06.h= tml=0A =C2=B7 =0Ahttp://self-issued.info/docs/draft-ietf-oauth-json-w= eb-token-04.html=0A =C2=B7 =0Ahttp://self-issued.info/docs/draft-jone= s-jose-jws-json-serialization-02.html=0A =C2=B7 =0Ahttp://self-issued= .info/docs/draft-jones-jose-jwe-json-serialization-02.html=0A =0A = -- Mike=0A =0A =0A____= ___________________________________________=0Ajose mailing list=0Ajose@ietf= .org=0Ahttps://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Tue Oct 16 09:10: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 E891721F89E3 for ; Tue, 16 Oct 2012 09:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhAp12-immdF for ; Tue, 16 Oct 2012 09:10:35 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2779321F8A0B for ; Tue, 16 Oct 2012 09:10:34 -0700 (PDT) Received: from mail94-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 16:10:33 +0000 Received: from mail94-ch1 (localhost [127.0.0.1]) by mail94-ch1-R.bigfish.com (Postfix) with ESMTP id D1A16201EE; Tue, 16 Oct 2012 16:10:33 +0000 (UTC) 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 X-SpamScore: -25 X-BigFish: VS-25(zz9371Ic89bh542Mzz1202h1d1ah1d2ahzz1033IL17326ah8275eh8275bh8275dha1495iz2fh2a8h668h839h93fhd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail94-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 mail94-ch1 (localhost.localdomain [127.0.0.1]) by mail94-ch1 (MessageSwitch) id 1350403831985813_21552; Tue, 16 Oct 2012 16:10:31 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail94-ch1.bigfish.com (Postfix) with ESMTP id EC21640094; Tue, 16 Oct 2012 16:10:31 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 16:10:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 16:10:18 +0000 From: Mike Jones To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" Thread-Topic: [jose] JOSE and JWT specs incorporating working group decisions since IETF 84 Thread-Index: AQHNq5DdDtelvfepRBCO1gAjjbxxsZe8GkdA Date: Tue, 16 Oct 2012 16:10:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366854172@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20121016042455.cc40c4f3d92d2001859047cd8cabb9ab.6d065f381d.wbe@email07.europe.secureserver.net> In-Reply-To: <20121016042455.cc40c4f3d92d2001859047cd8cabb9ab.6d065f381d.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.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] JOSE and JWT specs incorporating working group decisions since IETF 84 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, 16 Oct 2012 16:10:40 -0000 VGhhbmtzIC0gZ29vZCBmZWVkYmFjayENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTDQpTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDE2LCAyMDEyIDQ6MjUgQU0NClRvOiBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW2pvc2VdIEpPU0UgYW5kIEpXVCBzcGVjcyBpbmNvcnBvcmF0aW5nIHdvcmtpbmcgZ3JvdXAg ZGVjaXNpb25zIHNpbmNlIElFVEYgODQNCg0KSSBqdXN0IGluY29ycG9yYXRlZCB0aGUgLTA2IHNw ZWMgY2hhbmdlcyBpbnRvIHRoZSBOaW1idXMgSk9TRStKV1QgbGlicmFyeS4gTm90IG9ubHkgdG9r ZW5zIGFyZSBzaG9ydGVyIG5vdywgYnV0IHRoZSBjb3JlIGxpYnJhcnkgY29kZSB3YXMgcmVkdWNl ZCB0b28hIEV4Y2VsbGVudCB3b3JrIQ0KDQpDaGVlcnMsDQoNClZsYWRpbWlyDQoNClBTOiBJJ20g bG9va2luZyBmb3IgY29udHJpYnV0b3JzIHRvIHBvcnQgdGhlIG1pc3NpbmcgSldFIGFsZ3M6IA0K aHR0cHM6Ly9iaXRidWNrZXQub3JnL25pbWJ1c2RzL25pbWJ1cy1qb3NlLWp3dA0KDQotLQ0KVmxh ZGltaXIgRHpodXZpbm92IDogd3d3Lk5pbWJ1c0RTLmNvbSA6IHZsYWRpbWlyQG5pbWJ1c2RzLmNv bQ0KIA0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpT dWJqZWN0OiBbam9zZV0gSk9TRSBhbmQgSldUIHNwZWNzIGluY29ycG9yYXRpbmcgd29ya2luZyBn cm91cCBkZWNpc2lvbnMgc2luY2UgSUVURiA4NA0KRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPg0KRGF0ZTogVHVlLCBPY3RvYmVyIDE2LCAyMDEyIDc6NTkgYW0N ClRvOiAiam9zZUBpZXRmLm9yZyIgPGpvc2VAaWV0Zi5vcmc+DQoNCiAgTmV3IHZlcnNpb25zIG9m IHRoZSBKU09OIFdFQg0Ke1NpZ25hdHVyZSxFbmNyeXB0aW9uLEtleSxBbGdvcml0aG1zLFRva2Vu fSAoSldTLCBKV0UsIEpXSywgSldBLCBKV1QpIHNwZWNpZmljYXRpb25zIGhhdmUgYmVlbiByZWxl YXNlZC4gIFRoZXNlIHZlcnNpb25zIGluY29ycG9yYXRlIHRoZSBkZWNpc2lvbnMgbWFkZSBieSB0 aGUgSk9TRSB3b3JraW5nIGdyb3VwIGR1cmluZyBhbmQgc2luY2UgSUVURiA4NC4NCiAgDQogVGhl IHByaW1hcnkgY2hhbmdlIHdhcyByZXZpc2luZyB0aGUgSldFIGZvcm1hdCB0byBhbHdheXMgdXNl IEFFQUQgZW5jcnlwdGlvbiBhbGdvcml0aG1zLiAgVGhlIGNvbXBhbmlvbiBjaGFuZ2Ugd2FzIGRl ZmluaW5nIHR3byBuZXcgY29tcG9zaXRlIEFFQUQgYWxnb3JpdGhtcyDigJxBMTI4Q0JDK0hTMjU2 4oCdIGFuZCDigJxBMjU2Q0JDK0hTNTEy4oCdDQp0aGF0IHVzZSBBRVMgQ0JDIHRvIHBlcmZvcm0g ZW5jcnlwdGlvbiBhbmQgbWF0Y2hpbmcgSE1BQyBTSEEtMiBhbGdvcml0aG1zIHRvIHBlcmZvcm0g YW4gaW50ZWdyaXR5IGNoZWNrIG9uIHRoZSBjaXBoZXJ0ZXh0IGFuZCB0aGUgcGFyYW1ldGVycyB1 c2VkIHRvIGNyZWF0ZSBpdC4NCiAgDQogT3RoZXIgdGhhbiB0aGF0LCBhbGwgY2hhbmdlcyB3ZXJl IGxvY2FsIGluIHNjb3BlLCB3aXRoIG5vIGNoYW5nZXMgdG8gSldTIOKAkyBvdGhlciB0aGFuIGNo YW5naW5nIHRoZSBmb3JtYXQgb2YgdGhlIOKAnHg1Y+KAnSAoWC41MDkgQ2VydGlmaWNhdGUgQ2hh aW4pIGZyb20gYSBzdHJpbmcgY29udGFpbmluZyBhIGxpc3Qgb2YgY2VydGlmaWNhdGUgdmFsdWVz IHRvIGFuIGFycmF5IG9mIHN0cmluZ3MgY29udGFpbmluZyBjZXJ0aWZpY2F0ZSB2YWx1ZXMuICBM aWtld2lzZSwgdGhlIG9ubHkgY2hhbmdlcyB0byBKV1Qgd2VyZSB0byB0cmFjayBjaGFuZ2VzIG1h ZGUgaW4gdGhlIHNwZWNzIHRoYXQgaXQgdXNlcy4NCiAgDQogSGF2aW5nIGFkZHJlc3NlZCBhbGwg dGhlIG9wZW4gaXNzdWVzIHdpdGggcmVzb2x1dGlvbnMgd2l0aCBhcHBhcmVudCB3b3JraW5nIGdy b3VwIGNvbnNlbnN1cywgaXTigJlzIG15IGhvcGUgdGhhdCB0aGUgd29ya2luZyBncm91cCB3aWxs IGRlY2lkZSB0byBzZW5kIHRoZXNlIHNwZWNpZmljYXRpb25zIHRvIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIGF0IElFVEYgODUuDQogIA0KIFRoZSBjb21wYW5pb24gSldTIEpTT04gU2VyaWFsaXph dGlvbiBhbmQgSldFIEpTT04gU2VyaWFsaXphdGlvbiBzcGVjcyB3ZXJlIGFsc28gdXBkYXRlZC4N CiAgDQogVGhlIHdvcmtpbmcgZ3JvdXAgc3BlY2lmaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhdDoN CiDCtyAgICAgICANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1zaWduYXR1cmUtMDYNCiDCtyAgICAgICANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA2DQogwrcgICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMDYN CiDCtyAgICAgICANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1hbGdvcml0aG1zLTA2DQogwrcgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDQNCiAgDQogVGhlIGluZGl2aWR1 YWwgc3VibWlzc2lvbiBzcGVjaWZpY2F0aW9ucyBhcmUgYXZhaWxhYmxlIGF0Og0KIMK3ICAgICAg IA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtam9zZS1qd3MtanNvbi1z ZXJpYWxpemF0aW9uLTAyDQogwrcgICAgICAgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1qb25lcy1qb3NlLWp3ZS1qc29uLXNlcmlhbGl6YXRpb24tMDINCiAgDQogVGhlIGRvY3Vt ZW50IGhpc3RvcnkgZW50cmllcyAoYWxzbyBpbiB0aGUgc3BlY2lmaWNhdGlvbnMpIGFyZSBhcw0K Zm9sbG93czoNCiAgDQogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3Nl LWpzb24td2ViLXNpZ25hdHVyZS0wNg0KICBDaGFuZ2VkIHg1YyAoWC41MDkgQ2VydGlmaWNhdGUg Q2hhaW4pIHJlcHJlc2VudGF0aW9uIGZyb20gYmVpbmcgYSBzaW5nbGUgc3RyaW5nIHRvIGJlaW5n IGFuIGFycmF5IG9mIHN0cmluZ3MsIGVhY2ggY29udGFpbmluZyBhIHNpbmdsZQ0KYmFzZTY0IGVu Y29kZWQgREVSIGNlcnRpZmljYXRlIHZhbHVlLCByZXByZXNlbnRpbmcgZWxlbWVudHMgb2YgdGhl IGNlcnRpZmljYXRlIGNoYWluLiBBcHBsaWVkIGNoYW5nZXMgbWFkZSBieSB0aGUgUkZDIEVkaXRv ciB0byBSRkMgNjc0OSdzIHJlZ2lzdHJ5IGxhbmd1YWdlIHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4g DQoNCiAgDQogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24t d2ViLWVuY3J5cHRpb24tMDYNCiAgUmVtb3ZlZCB0aGUgaW50IGFuZCBrZGYgcGFyYW1ldGVycyBh bmQgZGVmaW5lZCB0aGUgbmV3IGNvbXBvc2l0ZSBBRUFEIGFsZ29yaXRobXMgQTEyOENCQytIUzI1 NiBhbmQgQTI1NkNCQytIUzUxMiB0byByZXBsYWNlIHRoZSBmb3JtZXIgdXNlcyBvZiBBRVMgQ0JD LCB3aGljaCByZXF1aXJlZCB0aGUgdXNlIG9mIHNlcGFyYXRlIGludGVncml0eSBhbmQga2V5IGRl cml2YXRpb24gZnVuY3Rpb25zLiBJbmNsdWRlZCBhZGRpdGlvbmFsIHZhbHVlcyBpbiB0aGUgQ29u Y2F0IEtERiBjYWxjdWxhdGlvbiAtLSB0aGUgZGVzaXJlZCBvdXRwdXQgc2l6ZSBhbmQgdGhlIGFs Z29yaXRobSB2YWx1ZSwgYW5kIG9wdGlvbmFsbHkgUGFydHlVSW5mbyBhbmQgUGFydHlWSW5mbyB2 YWx1ZXMuIEFkZGVkIHRoZSBvcHRpb25hbCBoZWFkZXIgcGFyYW1ldGVycyBhcHUgKGFncmVlbWVu dCBQYXJ0eVVJbmZvKSwgYXB2IChhZ3JlZW1lbnQgUGFydHlWSW5mbyksIGVwdSAoZW5jcnlwdGlv biBQYXJ0eVVJbmZvKSwgYW5kIGVwdiAoZW5jcnlwdGlvbiBQYXJ0eVZJbmZvKS4gVXBkYXRlZCB0 aGUgS0RGIGV4YW1wbGVzIGFjY29yZGluZ2x5LiBQcm9tb3RlZCBJbml0aWFsaXphdGlvbiBWZWN0 b3IgZnJvbSBiZWluZyBhIGhlYWRlciBwYXJhbWV0ZXIgdG8gYmVpbmcgYSB0b3AtbGV2ZWwgSldF IGVsZW1lbnQuIFRoaXMgc2F2ZXMgYXBwcm94aW1hdGVseSAxNiBieXRlcyBpbiB0aGUgY29tcGFj dCBzZXJpYWxpemF0aW9uLCB3aGljaCBpcyBhIHNpZ25pZmljYW50IHNhdmluZ3MgZm9yIHNvbWUg dXNlIGNhc2VzLiBQcm9tb3RpbmcgdGhlIEluaXRpYWxpemF0aW9uIFZlY3RvciBvdXQgb2YgdGhl IGhlYWRlciBhbHNvIGF2b2lkcyByZXBlYXRpbmcgdGhpcyBzaGFyZWQgdmFsdWUgaW4gdGhlIEpT T04gc2VyaWFsaXphdGlvbi4NCkNoYW5nZWQgeDVjIChYLjUwOSBDZXJ0aWZpY2F0ZSBDaGFpbikg cmVwcmVzZW50YXRpb24gZnJvbSBiZWluZyBhIHNpbmdsZSBzdHJpbmcgdG8gYmVpbmcgYW4gYXJy YXkgb2Ygc3RyaW5ncywgZWFjaCBjb250YWluaW5nIGEgc2luZ2xlIGJhc2U2NCBlbmNvZGVkIERF UiBjZXJ0aWZpY2F0ZSB2YWx1ZSwgcmVwcmVzZW50aW5nIGVsZW1lbnRzIG9mIHRoZSBjZXJ0aWZp Y2F0ZSBjaGFpbi4gQWRkZWQgYW4gQUVTIEtleSBXcmFwIGV4YW1wbGUuIFJlb3JkZXJlZCB0aGUg ZW5jcnlwdGlvbiBzdGVwcyBzbyBDTUsgY3JlYXRpb24gaXMgZmlyc3QsIHdoZW4gcmVxdWlyZWQu IENvcnJlY3Qgc3RhdGVtZW50cyBpbiBleGFtcGxlcyBhYm91dCB3aGljaCBhbGdvcml0aG1zIHBy b2R1Y2UgcmVwcm9kdWNpYmxlIHJlc3VsdHMuIA0KDQogIA0KIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMDYNCiAgQ2hhbmdlZCB0aGUgbmFt ZSBvZiB0aGUgSldLIFJTQSBleHBvbmVudCBwYXJhbWV0ZXIgZnJvbSBleHAgdG8geHBvIHNvIGFz IHRvIGFsbG93IHRoZSBwb3RlbnRpYWwgdXNlIG9mIHRoZSBuYW1lIGV4cCBmb3IgYSBmdXR1cmUg ZXh0ZW5zaW9uIHRoYXQgbWlnaHQgZGVmaW5lIGFuIGV4cGlyYXRpb24gcGFyYW1ldGVyIGZvciBr ZXlzLiAoVGhlIGV4cCBuYW1lIGlzIGFscmVhZHkgdXNlZCBmb3IgdGhpcyBwdXJwb3NlIGluIHRo ZSBKV1Qgc3BlY2lmaWNhdGlvbi4pIENsYXJpZnkgdGhhdCB0aGUgYWxnIChhbGdvcml0aG0gZmFt aWx5KSBtZW1iZXIgaXMgUkVRVUlSRUQuIENvcnJlY3QgYW4gaW5zdGFuY2Ugb2YgIkpXSyIgdGhh dCBzaG91bGQgaGF2ZSBiZWVuICJKV0sgU2V0Ii4gQXBwbGllZCBjaGFuZ2VzIG1hZGUgYnkgdGhl IFJGQyBFZGl0b3IgdG8gUkZDIDY3NDkncyByZWdpc3RyeSBsYW5ndWFnZSB0byB0aGlzIHNwZWNp ZmljYXRpb24uIA0KDQogIA0KIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt am9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTA2DQogIFJlbW92ZWQgdGhlIGludCBhbmQga2RmIHBh cmFtZXRlcnMgYW5kIGRlZmluZWQgdGhlIG5ldyBjb21wb3NpdGUgQUVBRCBhbGdvcml0aG1zIEEx MjhDQkMrSFMyNTYgYW5kIEEyNTZDQkMrSFM1MTIgdG8gcmVwbGFjZSB0aGUgZm9ybWVyIHVzZXMg b2YgQUVTIENCQywgd2hpY2ggcmVxdWlyZWQgdGhlIHVzZSBvZiBzZXBhcmF0ZSBpbnRlZ3JpdHkg YW5kIGtleSBkZXJpdmF0aW9uIGZ1bmN0aW9ucy4gSW5jbHVkZWQgYWRkaXRpb25hbCB2YWx1ZXMg aW4gdGhlIENvbmNhdCBLREYgY2FsY3VsYXRpb24gLS0gdGhlIGRlc2lyZWQgb3V0cHV0IHNpemUg YW5kIHRoZSBhbGdvcml0aG0gdmFsdWUsIGFuZCBvcHRpb25hbGx5IFBhcnR5VUluZm8gYW5kIFBh cnR5VkluZm8gdmFsdWVzLiBBZGRlZCB0aGUgb3B0aW9uYWwgaGVhZGVyIHBhcmFtZXRlcnMgYXB1 IChhZ3JlZW1lbnQgUGFydHlVSW5mbyksIGFwdiAoYWdyZWVtZW50IFBhcnR5VkluZm8pLCBlcHUg KGVuY3J5cHRpb24gUGFydHlVSW5mbyksIGFuZCBlcHYgKGVuY3J5cHRpb24gUGFydHlWSW5mbyku IENoYW5nZWQgdGhlIG5hbWUgb2YgdGhlIEpXSyBSU0EgZXhwb25lbnQgcGFyYW1ldGVyIGZyb20g ZXhwIHRvIHhwbyBzbyBhcyB0byBhbGxvdyB0aGUgcG90ZW50aWFsIHVzZSBvZiB0aGUgbmFtZSBl eHAgZm9yIGEgZnV0dXJlIGV4dGVuc2lvbiB0aGF0IG1pZ2h0IGRlZmluZSBhbiBleHBpcmF0aW9u IHBhcmFtZXRlciBmb3Iga2V5cy4gKFRoZSBleHAgbmFtZSBpcyBhbHJlYWR5IHVzZWQgZm9yIHRo aXMgcHVycG9zZSBpbiB0aGUgSldUIHNwZWNpZmljYXRpb24uKSBBcHBsaWVkIGNoYW5nZXMgbWFk ZSBieSB0aGUgUkZDIEVkaXRvciB0byBSRkMgNjc0OSdzIHJlZ2lzdHJ5IGxhbmd1YWdlIHRvIHRo aXMgc3BlY2lmaWNhdGlvbi4gDQoNCiAgDQogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNA0KICBQcm9tb3RlZCBJbml0aWFsaXphdGlv biBWZWN0b3IgZnJvbSBiZWluZyBhIGhlYWRlciBwYXJhbWV0ZXIgdG8gYmVpbmcgYSB0b3AtbGV2 ZWwgSldFIGVsZW1lbnQuIFRoaXMgc2F2ZXMgYXBwcm94aW1hdGVseSAxNiBieXRlcyBpbiB0aGUg Y29tcGFjdCBzZXJpYWxpemF0aW9uLCB3aGljaCBpcyBhIHNpZ25pZmljYW50IHNhdmluZ3MgZm9y IHNvbWUgdXNlIGNhc2VzLiBQcm9tb3RpbmcgdGhlIEluaXRpYWxpemF0aW9uIFZlY3RvciBvdXQg b2YgdGhlIGhlYWRlciBhbHNvIGF2b2lkcyByZXBlYXRpbmcgdGhpcyBzaGFyZWQgdmFsdWUgaW4g dGhlIEpTT04gc2VyaWFsaXphdGlvbi4gQXBwbGllZCBjaGFuZ2VzIG1hZGUgYnkgdGhlIFJGQyBF ZGl0b3IgdG8gUkZDIDY3NDkncyByZWdpc3RyeSBsYW5ndWFnZSB0byB0aGlzIHNwZWNpZmljYXRp b24uIFJlZmVyZW5jZSBSRkMgNjc1NSAtLSBBbiBJRVRGIFVSTiBTdWItTmFtZXNwYWNlIGZvciBP QXV0aC4gDQoNCiAgDQogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtam9z ZS1qd3MtanNvbi1zZXJpYWxpemF0aW9uLTAyDQogIENoYW5nZWQgdG8gdXNlIGFuIGFycmF5IG9m IHN0cnVjdHVyZXMgZm9yIHBlci1yZWNpcGllbnQgdmFsdWVzLCByYXRoZXIgdGhhbiBhIHNldCBv ZiBwYXJhbGxlbCBhcnJheXMuIA0KDQogIA0KIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWpvbmVzLWpvc2UtandlLWpzb24tc2VyaWFsaXphdGlvbi0wMg0KICBDaGFuZ2VkIHRvIHVz ZSBhbiBhcnJheSBvZiBzdHJ1Y3R1cmVzIGZvciBwZXItcmVjaXBpZW50IHZhbHVlcywgcmF0aGVy IHRoYW4gYSBzZXQgb2YgcGFyYWxsZWwgYXJyYXlzLiBQcm9tb3RlZCBJbml0aWFsaXphdGlvbiBW ZWN0b3IgZnJvbSBiZWluZyBhIGhlYWRlciBwYXJhbWV0ZXIgdG8gYmVpbmcgYSB0b3AtbGV2ZWwg SldFIGVsZW1lbnQuIFRoaXMgc2F2ZXMgYXBwcm94aW1hdGVseSAxNiBieXRlcyBpbiB0aGUgY29t cGFjdCBzZXJpYWxpemF0aW9uLCB3aGljaCBpcyBhIHNpZ25pZmljYW50IHNhdmluZ3MgZm9yIHNv bWUgdXNlIGNhc2VzLiBQcm9tb3RpbmcgdGhlIEluaXRpYWxpemF0aW9uIFZlY3RvciBvdXQgb2Yg dGhlIGhlYWRlciBhbHNvIGF2b2lkcyByZXBlYXRpbmcgdGhpcyBzaGFyZWQgdmFsdWUgaW4gdGhl IEpTT04gc2VyaWFsaXphdGlvbi4gDQoNCiAgDQogSFRNTCBmb3JtYXR0ZWQgdmVyc2lvbnMgYXJl IGF2YWlsYWJsZSBhdDoNCiDCtyAgICAgICANCmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3Mv ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wNi5odG1sDQogwrcgICAgICAgDQpo dHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNy eXB0aW9uLTA2Lmh0bWwNCiDCtyAgICAgICANCmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3Mv ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNi5odG1sDQogwrcgICAgICAgDQpodHRwOi8v c2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1z LTA2Lmh0bWwNCiDCtyAgICAgICANCmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQt aWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNC5odG1sDQogwrcgICAgICAgDQpodHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLWpvc2UtandzLWpzb24tc2VyaWFsaXphdGlv bi0wMi5odG1sDQogwrcgICAgICAgDQpodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0 LWpvbmVzLWpvc2UtandlLWpzb24tc2VyaWFsaXphdGlvbi0wMi5odG1sDQogIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCiAgDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vam9zZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg== From Michael.Jones@microsoft.com Tue Oct 16 09:14: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 E8A1F21F87D3 for ; Tue, 16 Oct 2012 09:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slIFUAhNgL3V for ; Tue, 16 Oct 2012 09:13:56 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 474FF21F8775 for ; Tue, 16 Oct 2012 09:13:56 -0700 (PDT) Received: from mail245-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 16:13:53 +0000 Received: from mail245-va3 (localhost [127.0.0.1]) by mail245-va3-R.bigfish.com (Postfix) with ESMTP id 1A7A110006A; Tue, 16 Oct 2012 16:13:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail245-va3: 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=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail245-va3 (localhost.localdomain [127.0.0.1]) by mail245-va3 (MessageSwitch) id 1350404030711779_14013; Tue, 16 Oct 2012 16:13:50 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.240]) by mail245-va3.bigfish.com (Postfix) with ESMTP id AA47280064; Tue, 16 Oct 2012 16:13:50 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 16:13:48 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 16:13:31 +0000 From: Mike Jones To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" Thread-Topic: [jose] JWE -06: Terminology - JWE IV and integrity value Thread-Index: AQHNq4XJpAwmobtNL0KqTPWdvmazT5e8Gnxw Date: Tue, 16 Oct 2012 16:13:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366854197@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20121016023324.cc40c4f3d92d2001859047cd8cabb9ab.1b58107126.wbe@email07.europe.secureserver.net> In-Reply-To: <20121016023324.cc40c4f3d92d2001859047cd8cabb9ab.1b58107126.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.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] JWE -06: Terminology - JWE IV and integrity value 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, 16 Oct 2012 16:14:01 -0000 There's currently no actual case where the JWE Initialization Vector or JWE= Integrity Value can be empty, because an Initialization Vector is used for= all the defined "enc" algorithms - (CBC, GCM) and all of them have an inte= grity value. However, this could be true for future algorithms. Is that what you're thi= nking? -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Vla= dimir Dzhuvinov / NimbusDS Sent: Tuesday, October 16, 2012 2:33 AM To: jose@ietf.org Subject: [jose] JWE -06: Terminology - JWE IV and integrity value Thank you guys for pushing the updates specs out. Regarding JWE -06 section 2. Terminology: It could be helpful to mention for "JWE Initialization Vector" and "JWE Int= egrity Values" that these can also be empty, like said for "JWE Encrypted K= ey". Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com =20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Tue Oct 16 15:55: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 267FD1F0CB8 for ; Tue, 16 Oct 2012 15:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRmOF6LCwt-a for ; Tue, 16 Oct 2012 15:55:14 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA1C1F0CB4 for ; Tue, 16 Oct 2012 15:55:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,596,1344175200"; d="scan'208";a="99875813" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 17 Oct 2012 09:55:12 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6867"; a="93488430" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 17 Oct 2012 09:55:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 17 Oct 2012 09:55:11 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 17 Oct 2012 09:55:10 +1100 Thread-Topic: [jose] xpo Thread-Index: Ac2ra69SDtelvfepRBCO1gAjjbxxsQAhPaSw Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDD5151B@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] xpo 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, 16 Oct 2012 22:55:15 -0000 PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5 LTA2DQo+IOKAoiBDaGFuZ2VkIHRoZSBuYW1lIG9mIHRoZSBKV0sgUlNBIGV4cG9uZW50IHBhcmFt ZXRlciBmcm9tIGV4cCB0byB4cG8gc28gYXMgdG8gYWxsb3cgdGhlIHBvdGVudGlhbCB1c2Ugb2Yg dGhlIG5hbWUgZXhwIGZvciBhIGZ1dHVyZSBleHRlbnNpb24gdGhhdCBtaWdodCBkZWZpbmUgYW4g ZXhwaXJhdGlvbiBwYXJhbWV0ZXIgZm9yIGtleXMuIChUaGUgZXhwIG5hbWUgaXMgYWxyZWFkeSB1 c2VkIGZvciB0aGlzIHB1cnBvc2UgaW4gdGhlIEpXVCBzcGVjaWZpY2F0aW9uLikNCg0KIm4iIGFu ZCAiZSIgd291bGQgYmUgYmV0dGVyIHRoYW4gIm1vZCIgYW5kICJ4cG8iLg0KIm4iIGFuZCAiZSIg YXJlIHZlcnkgd2lkZWx5IHVzZWQgZm9yIHRoZSBSU0EgbW9kdWx1cyBhbmQgcHVibGljIGV4cG9u ZW50Lg0KDQpzXmUgPSBtIG1vZCBuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From rbarnes@bbn.com Tue Oct 16 16:16:42 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 1DCA521F869C for ; Tue, 16 Oct 2012 16:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn6-aQxNCdXT for ; Tue, 16 Oct 2012 16:16:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7E51221F869A for ; Tue, 16 Oct 2012 16:16:41 -0700 (PDT) Received: from [128.89.253.178] (port=55407) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TOGMe-000Hb8-PD; Tue, 16 Oct 2012 19:15:57 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Richard Barnes In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDD5151B@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 16 Oct 2012 19:15:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8AC56264-8B09-48BA-802F-6B30577419E9@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FDD5151B@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1283) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] xpo 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, 16 Oct 2012 23:16:42 -0000 +1=20 On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >> =95 Changed the name of the JWK RSA exponent parameter from exp to = xpo so as to allow the potential use of the name exp for a future = extension that might define an expiration parameter for keys. (The exp = name is already used for this purpose in the JWT specification.) >=20 > "n" and "e" would be better than "mod" and "xpo". > "n" and "e" are very widely used for the RSA modulus and public = exponent. >=20 > s^e =3D m mod n >=20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Tue Oct 16 22:32: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 9CEAC21F87A8 for ; Tue, 16 Oct 2012 22:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9unBKn28hxj for ; Tue, 16 Oct 2012 22:32:44 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id C557121F877C for ; Tue, 16 Oct 2012 22:32:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,598,1344175200"; d="scan'208";a="98533648" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 17 Oct 2012 16:32:40 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6867"; a="94368374" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 17 Oct 2012 16:32:39 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 17 Oct 2012 16:32:39 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 17 Oct 2012 16:32:38 +1100 Thread-Topic: [jose] AEAD-only Thread-Index: Ac2ra69SDtelvfepRBCO1gAjjbxxsQAs/NCA Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDDCC27D@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] AEAD-only 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, 17 Oct 2012 05:32:44 -0000 SXQgaXMgZ3JlYXQgdG8gc2VlICJBMTI4Q0JDK0hTMjU2IiBhcyBhIG5hbWUgZm9yIGFuIEFFQUQg YWxnb3JpdGhtIChpbnN0ZWFkIG9mIDMgbmFtZXMgZm9yIGVuYy9pbnQva2RmIGNvbXBvbmVudHMp Lg0KDQpUaGUgcmVzdCBvZiB0aGUgSldFIHNwZWMgbmVlZHMgZnVydGhlciBlZGl0cyB0byBwcm9w ZXJseSByZWZsZWN0IHRoZSBBRUFELW9ubHkgbW9kZWwg4oCUIGFzIGRvZXMgdGhlIEpXQSBzcGVj Lg0KDQoxLiBEcm9wIHNlY3Rpb24gMy4yLiAiRXhhbXBsZSBKV0Ugd2l0aCBhIFNlcGFyYXRlIElu dGVncml0eSBDaGVjayI7IHJlbmFtZSBzZWN0aW9uIDMuMSB0byBiZSAiRXhhbXBsZSIuIFRoZSBk aWZmZXJlbmNlIGJldHdlZW4gYW4gImludGVncmF0ZWQiIEFFQUQgYWxnb3JpdGhtIChlZyBBMjU2 R0NNKSBhbmQgYSAiY29uc3RydWN0ZWQiIEFFQUQgYWxnb3JpdGhtIChlZyBBMTI4Q0JDK0hTMjU2 KSBzaG91bGRuJ3QgYmUgdmlzaWJsZSBhdCB0aGlzIGxldmVsIChpZSBpbiB0aGlzIHNwZWMpLg0K DQoyLiBTZWN0aW9uIDUgIk1lc3NhZ2UgRW5jcnlwdGlvbiIgc3RlcCAxOiB0aGUgc2l6ZSBvZiB0 aGUgQ01LIGlzIGRldGVybWluZWQgYnkgdGhlIEFFQUQgYWxnb3JpdGhtIChlbmMgcGFyYW1ldGVy IHZhbHVlKSwgbm90IHRoZSBzaXplIHJlcXVpcmVkIGZvciB0aGUgYmxvY2sgZW5jcnlwdGlvbiBh bGdvcml0aG0uDQoNCjMuIFNlY3Rpb24gNSAiTWVzc2FnZSBFbmNyeXB0aW9uIi4gVGhlcmUgaXMg bm8gbWVudGlvbiBvZiB3aGF0IHRoZSBBZGRpdGlvbmFsIERhdGEgaXMgZm9yIHRoZSBBRUFEIGFs Z29yaXRobS4gQWRkIGEgc3RlcCAxMWIgdGhhdCBkZWZpbmVzIHdoYXQgdGhlIEFkZGl0aW9uYWwg RGF0YSBpcy4gQWRqdXN0IHN0ZXAgMTIgdG8gc2F5IHRoZSAoY29tcHJlc3NlZCkgcGxhaW50ZXh0 IGFuZCBBZGRpdGlvbmFsIERhdGEgYXJlIHBhc3NlZCB0byB0aGUgQUVBRCBhbGdvcml0aG0uDQoN CjQuIFNlY3Rpb24gNiAiTWVzc2FnZSBEZWNyeXB0aW9uIi4gQXMgYWJvdmUsIGEgc3RlcCBuZWVk cyB0byBzcGVjaWZ5aW5nIHdoYXQgdGhlIEFkZGl0aW9uYWwgRGF0YSBpcy4NCg0KNS4gU2VjdGlv biAxICJJbnRyb2R1Y3Rpb24iLiBJdCB3b3VsZCBiZSB3b3J0aCBtZW50aW9uaW5nIHRoYXQgYW4g QUVBRCBhbGdvcml0aG0gaXMgdXNlZCB0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50 ZWdyaXR5LCBhbG9uZyB3aXRoIHRoZSBtb2RlbCBvZiBhbiBBRUFEIGFsZ29yaXRobSAoZml4ZWQg bGVuZ3RoIHN5bW1ldHJpYyBrZXk7IHBsYWludGV4dCBhbmQgQWRkaXRpb25hbCBEYXRhIGlucHV0 czsgaXY/OyBjaXBoZXJ0ZXh0IGFuZCBpbnRlZ3JpdHkgdGFnIG91dHB1dHMpLg0KDQo2LiBTZWN0 aW9uIDQuMS4yLiAiImVuYyIgKEVuY3J5cHRpb24gTWV0aG9kKSBIZWFkZXIgUGFyYW1ldGVyIi4g U2F5IGl0IGlzIGFuIEFFQUQgYWxnb3JpdGhtLiBFeHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlICJl bmMiIHZhbHVlIG11c3QgaW1wbHkgYSBzcGVjaWZpYyBrZXkgbGVuZ3RoLiBBIHNwZWNpZmljIGtl eSBsZW5ndGggaXMgcmVxdWlyZWQgZm9yIGtleSBhZ3JlZW1lbnQgb3IgZm9yIGdlbmVyYXRpbmcg YSByYW5kb20gQ01LLg0KDQoNCkluIEpXQToNCg0KNy4gU2VjdGlvbiA0LjguMyAiSW50ZWdyaXR5 IENhbGN1bGF0aW9uIGZvciAiQTEyOENCQytIUzI1NiIgYW5kICJBMjU2Q0JDK0hTNTEyIiIgc2hv dWxkIHJlZmVyIHRvIHRoZSBBdXRoZW50aWNhdGVkIERhdGEgcGFzc2VkIHRvIHRoZSBhbGdvcml0 aG0uIEl0IHNob3VsZCBub3QgcmVkZWZpbmUgaG93IHRoZSBBdXRoZW50aWNhdGVkIERhdGEgaXMg YnVpbHQgZnJvbSBkb3RzIGFuZCBiYXNlNjR1cmwtZW5jb2RpbmdzLg0KDQo4LiBTZWN0aW9uIDQu OSAiUGxhaW50ZXh0IEVuY3J5cHRpb24gd2l0aCBBRVMgR0NNIiBzaW1pbGFybHkgc2hvdWxkIG5v dCByZWRlZmluZSBob3cgdGhlIEF1dGhlbnRpY2F0ZWQgRGF0YSBpcyBidWlsdC4NCg0KDQpDaG9v c2luZyB0byBvbmx5IHN1cHBvcnQgQUVBRCBhbGdvcml0aG1zIHdhcyBhIGdvb2QgY2hvaWNlLiBJ dCBzaG91bGQgbWFrZSBpdCBlYXNpZXIgdG8gdW5kZXJzdGFuZCB0aGUgc2VjdXJpdHkgcHJvcGVy dGllcy4gSG93ZXZlciwgYXQgdGhlIG1vbWVudCBkaWZmZXJlbnQgQUVBRCBhbGdvcml0aG0gdXNl IGRpZmZlcmVudCBpbnB1dHMgZm9yIHRoZSBBdXRoZW50aWNhdGVkIERhdGEgcG9ydGlvbiwgd2hp Y2ggcmVhbGx5IHVuZGVybWluZXMgYW55IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNlY3VyaXR5Lg0K DQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From vladimir@nimbusds.com Wed Oct 17 01:24: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 6683521F877C for ; Wed, 17 Oct 2012 01:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcwnCH687v55 for ; Wed, 17 Oct 2012 01:24:40 -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 37C9B21F857D for ; Wed, 17 Oct 2012 01:24:39 -0700 (PDT) Received: (qmail 22242 invoked from network); 17 Oct 2012 08:24:38 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 17 Oct 2012 08:24:30 -0000 Received: (qmail 13064 invoked by uid 99); 17 Oct 2012 08:24:30 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.137.102 User-Agent: Workspace Webmail 5.6.26 Message-Id: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Wed, 17 Oct 2012 01:24:29 -0700 Mime-Version: 1.0 Subject: Re: [jose] xpo 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, 17 Oct 2012 08:24:43 -0000 +1=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com= =0A=0A=0A-------- Original Message --------=0ASubject: Re: [jose] xpo=0AFro= m: Richard Barnes =0ADate: Wed, October 17, 2012 12:15 am= =0ATo: "Manger, James H" =0ACc: Mike Jones= , "jose@ietf.org"=0A=0A=0A=0A+= 1 =0A=0AOn Oct 16, 2012, at 6:55 PM, Manger, James H wrote:=0A=0A>> http://= tools.ietf.org/html/draft-ietf-jose-json-web-key-06=0A>> =E2=80=A2 Changed = the name of the JWK RSA exponent parameter from exp to xpo so as to allow t= he potential use of the name exp for a future extension that might define a= n expiration parameter for keys. (The exp name is already used for this pur= pose in the JWT specification.)=0A> =0A> "n" and "e" would be better than "= mod" and "xpo".=0A> "n" and "e" are very widely used for the RSA modulus an= d public exponent.=0A> =0A> s^e =3D m mod n=0A> =0A> --=0A> James Manger=0A= > _______________________________________________=0A> jose mailing list=0A>= jose@ietf.org=0A> https://www.ietf.org/mailman/listinfo/jose=0A=0A________= _______________________________________=0Ajose mailing list=0Ajose@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/jose From vladimir@nimbusds.com Wed Oct 17 01:39:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA8C21F85EF for ; Wed, 17 Oct 2012 01:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZvufLIrkbzR for ; Wed, 17 Oct 2012 01:39: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 D177121F853A for ; Wed, 17 Oct 2012 01:39:27 -0700 (PDT) Received: (qmail 13876 invoked from network); 17 Oct 2012 08:39:23 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 17 Oct 2012 08:39:22 -0000 Received: (qmail 25482 invoked by uid 99); 17 Oct 2012 08:39:22 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.137.102 User-Agent: Workspace Webmail 5.6.26 Message-Id: <20121017013921.cc40c4f3d92d2001859047cd8cabb9ab.e652796d65.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "jose@ietf.org" Date: Wed, 17 Oct 2012 01:39:21 -0700 Mime-Version: 1.0 Subject: Re: [jose] JWE -06: Terminology - JWE IV and integrity value 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, 17 Oct 2012 08:39:29 -0000 Yes, Mike, and the JWE spec does mention further down that the IV part=0Ama= y be empty:=0A=0A=0A'''=0A5. Message Encryption=0A=0A6. Generate a random= JWE Initialization Vector of the correct size=0A for the block encr= yption algorithm (if required for the=0A algorithm); otherwise, let = the JWE Initialization Vector be the=0A empty byte string.=0A'''=0A= =0AMy original reaction was - if it's mentioned for JWE Encrypted Key, then= =0Ait should be mentioned for the other possibly empty parts as well.=0A=0A= I used this hint in the library development: It has a JOSE core that=0Avali= dates the messages, and only then passes them on to the matching JWA=0Acryp= to handlers for decryption. Part of this initial validation includes=0Achec= king for empty parts. For example, it makes sure the header=0ABase64URL par= t is not empty. My strategy is to have as much of this=0Avalidation perform= ed by the core and only what is truly algorithm=0Arelated have it validated= by the handler. Having a clear definition of=0Awhich parts may be empty an= d which not helps that.=0A=0ACheers,=0A=0AVladimir=0A--=0AVladimir Dzhuvino= v : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A=0A=0A=0A-------- Origina= l Message --------=0ASubject: Re: [jose] JWE -06: Terminology - JWE IV and = integrity value=0AFrom: Mike Jones =0ADate: Tu= e, October 16, 2012 5:13 pm=0ATo: Vladimir Dzhuvinov / NimbusDS ,=0A"jose@ietf.org" =0A=0A=0AThere's currently n= o actual case where the JWE Initialization Vector or=0AJWE Integrity Value = can be empty, because an Initialization Vector is=0Aused for all the define= d "enc" algorithms - (CBC, GCM) and all of them=0Ahave an integrity value.= =0A=0AHowever, this could be true for future algorithms. Is that what you'r= e=0Athinking?=0A=0A -- Mike=0A=0A-----Original Message-----=0AFrom: jose-bo= unces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of=0AVladimir Dzhuv= inov / NimbusDS=0ASent: Tuesday, October 16, 2012 2:33 AM=0ATo: jose@ietf.o= rg=0ASubject: [jose] JWE -06: Terminology - JWE IV and integrity value=0A= =0AThank you guys for pushing the updates specs out.=0A=0ARegarding JWE -06= section 2. Terminology:=0A=0AIt could be helpful to mention for "JWE Initi= alization Vector" and "JWE=0AIntegrity Values" that these can also be empty= , like said for "JWE=0AEncrypted Key".=0A=0A=0AVladimir=0A=0A--=0AVladimir = Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A =0A=0A=0A__________= _____________________________________=0Ajose mailing list=0Ajose@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/jose=0A=0A=0A_____________________= __________________________=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://ww= w.ietf.org/mailman/listinfo/jose From bcampbell@pingidentity.com Wed Oct 17 06:09:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E8121F8658 for ; Wed, 17 Oct 2012 06:09:20 -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.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhHAnlb4QTDh for ; Wed, 17 Oct 2012 06:09:19 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1582F21F859C for ; Wed, 17 Oct 2012 06:09:18 -0700 (PDT) Received: from mail-vc0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKUH6t/lt0waiciXhnESj/I2ysDhNwnRTM@postini.com; Wed, 17 Oct 2012 06:09:19 PDT Received: by mail-vc0-f172.google.com with SMTP id fl11so8767811vcb.31 for ; Wed, 17 Oct 2012 06:09:17 -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=Ddp0I1I7AM41WsOuaiYmH4TkndcLNoy9IY3F7eWzzPs=; b=EoifNxioZjQUOP3MYYH+4ki1sRSJQKRFaewYk4Neeo5kOFizmQ4MMAXfp6s1gDxb0L PeSvGLf/YSVf5ZxjOAb9jnh6ahY1H8r1pa9CkaqWEX5gqReRjmYE23gFxpxOStG/qsNR 5FbD3Et+2337hVXzfu1EF/sxLJHD9pqdLjnG70xbjZPrT7VKl9TvtHM8bCrz0MNXW1rZ HM4wIVwrpHHl3+zL4iQP+dgdUFlwXVwT5bALpLz33ZN6/VQxXAaHfT1RpxAMYskPIyaH MZ4CBfWlEwHno/LsOjbodFjvd9tLr232LhPPSpg5ajy0K9qliQ65Jo71OWRTYoxzfQBF mmTw== Received: by 10.220.150.82 with SMTP id x18mr603824vcv.73.1350479357684; Wed, 17 Oct 2012 06:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.44 with HTTP; Wed, 17 Oct 2012 06:08:47 -0700 (PDT) In-Reply-To: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> From: Brian Campbell Date: Wed, 17 Oct 2012 07:08:47 -0600 Message-ID: To: "Vladimir Dzhuvinov / NimbusDS" Content-Type: multipart/alternative; boundary=f46d043c7c1e642b6204cc40fa44 X-Gm-Message-State: ALoCoQmIwtCVz6MbtF59iYYUDw7N+W3DJMy1PUoei9lsHfHHHNnnl5O+NM/zs4e9bUU9rFAeXRhu Cc: jose@ietf.org Subject: Re: [jose] xpo 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, 17 Oct 2012 13:09:20 -0000 --f46d043c7c1e642b6204cc40fa44 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 (if a parameter name change is going to happen anyway) On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS < vladimir@nimbusds.com> wrote: > +1 > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > -------- Original Message -------- > Subject: Re: [jose] xpo > From: Richard Barnes > Date: Wed, October 17, 2012 12:15 am > To: "Manger, James H" > Cc: Mike Jones , "jose@ietf.org" > > > > +1 > > On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: > > >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 > >> =95 Changed the name of the JWK RSA exponent parameter from exp to xpo= so > as to allow the potential use of the name exp for a future extension that > might define an expiration parameter for keys. (The exp name is already > used for this purpose in the JWT specification.) > > > > "n" and "e" would be better than "mod" and "xpo". > > "n" and "e" are very widely used for the RSA modulus and public exponen= t. > > > > s^e =3D m mod n > > > > -- > > James Manger > > _______________________________________________ > > 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 > --f46d043c7c1e642b6204cc40fa44 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 (if a parameter name change is going to happen anyway)

On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / Nimb= usDS <vladimir@nimbusds.com> wrote:
+1

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


-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <rbarnes@bbn.com= >
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Cc: Mike Jones <Michael.J= ones@microsoft.com>, "jose@iet= f.org"
<jose@ietf.org>


+1

On Oct 16, 2012, at 6:55 PM, Manger, James H wrote:

>> http://tools.ietf.org/html/draft-ietf-jose-json-web-= key-06
>> =95 Changed the name of the JWK RSA exponent parameter from exp to= xpo so as to allow the potential use of the name exp for a future extensio= n that might define an expiration parameter for keys. (The exp name is alre= ady used for this purpose in the JWT specification.)
>
> "n" and "e" would be better than "mod" a= nd "xpo".
> "n" and "e" are very widely used for the RSA modul= us and public exponent.
>
> s^e =3D m mod n
>
> --
> James Manger
> _______________________________________________
> 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
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d043c7c1e642b6204cc40fa44-- From barryleiba@gmail.com Thu Oct 18 04:16:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A149821F8685 for ; Thu, 18 Oct 2012 04:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVtRLGdj75os for ; Thu, 18 Oct 2012 04:16:58 -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 DFEF021F8652 for ; Thu, 18 Oct 2012 04:16:57 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9556882vbb.31 for ; Thu, 18 Oct 2012 04:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=oFrRE07D66kT8hMfVttyOBMjevTpsQOg24+lCv8wNQY=; b=f7OpdtU8b13pWnlBh4LCs60rSmyl3eKJ0LkWbqK3l01fra2A0101J2FKNVlA2NoeSj h+lti76dkzNnjozGMVRO2Ic3YBkKymgLmAmvruFepe6WNibPTaDg/BU+TQimEtjmkBnH s98yoalCkxjPdTqd0qw9BvcJMXRKZOON6ZFBuNSDOpUM0BRUeaLqDfi2uSbKnNDfgTjY 87AtzDYmO/iZGoWRzRfDDaabM70G6xhh7SNTsgR8BdtUa37RO+SeyN1Kjcxjq8naGkox w0pnlngK0mzjZsob+pPq+IEhS2LMyBFi5OkqOvPqRCDUPGHNL1uZxE8vqC3NxADKSgeZ 2Vxw== MIME-Version: 1.0 Received: by 10.52.65.51 with SMTP id u19mr11554530vds.3.1350559017396; Thu, 18 Oct 2012 04:16:57 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Thu, 18 Oct 2012 04:16:57 -0700 (PDT) Date: Thu, 18 Oct 2012 07:16:57 -0400 X-Google-Sender-Auth: URJ7qKcQb7Ao8S1OIbuYrEzMhlA Message-ID: From: Barry Leiba To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [jose] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: saag@ietf.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 11:16:58 -0000 A document titled "Secure Cookie Sessions for HTTP" has been submitted to the Independent Stream Editor (ISE): http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ The IESG has been asked to review the document, as specified in RFC 5742, Section 3. The Security and Applications Area Directors are looking for input for that review. Please post any relevant comments to the Security Area list, , as soon as possible, and at least by 1 November 2012. Note: Please do NOT post responses to the jose mailing list. Respond only to (using the subject line of this message). Please read RFC 5742, Section 3, and be aware that we are not looking for detailed comments on the document itself (see below). We specifically need input on whether this document is in conflict with work that's being done in the IETF. Look at the five possible responses specified in that section, and help us determine whether any of 2 through 5 applies. Please be specific in your response. In addition to this, we're sure that the authors and the ISE would appreciate comments about the document. If you have those, you may send them directly to the authors at and to the ISE at . General discussion of the document on these lists or the saag list will likely not get to the authors or the ISE. Barry Leiba, Applications AD From Axel.Nennker@telekom.de Thu Oct 18 23:49: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 E08E721F8639 for ; Thu, 18 Oct 2012 23:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg3mopO4MtTF for ; Thu, 18 Oct 2012 23:49:52 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4515221F861C for ; Thu, 18 Oct 2012 23:49:50 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 19 Oct 2012 08:49:47 +0200 Received: from HE113558.emea1.cds.t-internal.com (10.125.65.100) by HE111528.EMEA1.CDS.T-INTERNAL.COM (10.125.90.87) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 19 Oct 2012 08:49:47 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE113558.emea1.cds.t-internal.com ([2002:7cd:4164::7cd:4164]) with mapi; Fri, 19 Oct 2012 08:49:44 +0200 From: To: Date: Fri, 19 Oct 2012 08:49:40 +0200 Thread-Topic: [jose] xpo Thread-Index: Ac2saK8mHKFHzhbaT3KrDB3AfYKSXwBWuvgQ Message-ID: References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402520665ECC5HE111541eme_" MIME-Version: 1.0 Cc: bcampbell@pingidentity.com, sakimura@gmail.com, vladimir@nimbusds.com Subject: Re: [jose] xpo 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, 19 Oct 2012 06:49:54 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402520665ECC5HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know why the exp in jwk needs to be changed. From a developer POW t= here is no need. You always know which "exp" is the right one. I would reverse the change from exp to xpo. Developers don't need it and ma= ny did not update their implementation to incorporate the exp->xpo transiti= on. Actually I don't care (much) how the parameters are named. Although I would= like to stick to the 3-letter scheme I am OK with the n,e proposal. But please stop making breaking changes (especially renaming parameters whi= ch leads only to more work and no gain). Case1: harm is already done -> stick with xpo and don't change AGAIN. Case2: Most implementation haven't changed yet -> revert to exp Case3: xpo is just stupid -> n,e is better -> another change -> Oh no -> re= vert to exp Again: I suggest to revert to exp and make the implementers happy. Axel Cc'ing Nat because I don't want to give away his developer's emails without= asking. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bri= an Campbell Sent: Wednesday, October 17, 2012 3:09 PM To: Vladimir Dzhuvinov / NimbusDS Cc: jose@ietf.org Subject: Re: [jose] xpo +1 (if a parameter name change is going to happen anyway) On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS > wrote: +1 -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@n= imbusds.com -------- Original Message -------- Subject: Re: [jose] xpo From: Richard Barnes > Date: Wed, October 17, 2012 12:15 am To: "Manger, James H" > Cc: Mike Jones >, "jose@ietf.org" > +1 On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >> * Changed the name of the JWK RSA exponent parameter from exp to xpo so = as to allow the potential use of the name exp for a future extension that m= ight define an expiration parameter for keys. (The exp name is already used= for this purpose in the JWT specification.) > > "n" and "e" would be better than "mod" and "xpo". > "n" and "e" are very widely used for the RSA modulus and public exponent. > > s^e =3D m mod n > > -- > James Manger > _______________________________________________ > 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 --_000_CE8995AB5D178F44A2154F5C9A97CAF402520665ECC5HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I donR= 17;t know why the exp in jwk needs to be changed. From a developer POW ther= e is no need. You always know which “exp” is the right one.

I would reverse the change fr= om exp to xpo. Developers don’t need it and many did not update their= implementation to incorporate the exp->xpo transition.

 

Actually I don’t care (much) how the parameters are nam= ed. Although I would like to stick to the 3-letter scheme I am OK with the = n,e proposal.

But please s= top making breaking changes (especially renaming parameters which leads onl= y to more work and no gain).

 

Case1: harm is a= lready done -> stick with xpo and don’t change AGAIN.

Case2: Most implementation haven’= ;t changed yet -> revert to exp

Case3: xpo is just stupid -> n,e is better -> another change= -> Oh no -> revert to exp

=  

Again: I sug= gest to revert to exp and make the implementers happy.

 

Axel

 =

Cc’ing Nat because I don= ’t want to give away his developer’s emails without asking.

 

<= p class=3DMsoNormal> 

From= : jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of <= /b>Brian Campbell
Sent: Wednesday, October 17, 2012 3:09 PM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Su= bject: Re: [jose] xpo

&n= bsp;

+1 (if a = parameter name change is going to happen anyway)

On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusD= S <vladimir@n= imbusds.com> wrote:

+1

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



----= ---- Original Message --------
Subject: Re: [jose] xpo
From: Richard = Barnes <rbarnes@bbn.com>
Da= te: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <<= a href=3D"mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telst= ra.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org"
<j= ose@ietf.org>


+1

On Oct 16, 2012, at 6:55 PM, Mang= er, James H wrote:

>> http://tools.ietf.org/html= /draft-ietf-jose-json-web-key-06
>> • Changed the name o= f the JWK RSA exponent parameter from exp to xpo so as to allow the potenti= al use of the name exp for a future extension that might define an expirati= on parameter for keys. (The exp name is already used for this purpose in th= e JWT specification.)
>
> "n" and "e" would= be better than "mod" and "xpo".
> "n" = and "e" are very widely used for the RSA modulus and public expon= ent.
>
> s^e =3D m mod n
>
> --
> James Mange= r
> _______________________________________________
> jose mail= ing list
> jose@ietf.org
>= h= ttps://www.ietf.org/mailman/listinfo/jose

______________________= _________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose_______________________________________________
jose mailing list
<= a href=3D"mailto:jose@ietf.org">jose@ietf.org
https://www.ietf.org/mai= lman/listinfo/jose

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402520665ECC5HE111541eme_-- From James.H.Manger@team.telstra.com Fri Oct 19 00:18: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 8934921F8620 for ; Fri, 19 Oct 2012 00:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stJ8j41JmLq4 for ; Fri, 19 Oct 2012 00:18:29 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6159121F855B for ; Fri, 19 Oct 2012 00:18:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,612,1344175200"; d="scan'208,217";a="97226598" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 19 Oct 2012 18:18:26 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6869"; a="95488886" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccni.tcif.telstra.com.au with ESMTP; 19 Oct 2012 18:18:26 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 19 Oct 2012 18:18:25 +1100 From: "Manger, James H" To: "Axel.Nennker@telekom.de" , "jose@ietf.org" Date: Fri, 19 Oct 2012 18:18:24 +1100 Thread-Topic: [jose] xpo Thread-Index: Ac2saK8mHKFHzhbaT3KrDB3AfYKSXwBWuvgQAAFgZsA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FDEC39C2WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "bcampbell@pingidentity.com" , "sakimura@gmail.com" , "vladimir@nimbusds.com" Subject: Re: [jose] xpo 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, 19 Oct 2012 07:18:30 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FDEC39C2WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcZXhw4oCdIHdvdWxkbuKAmXQgY2xhc2ggaWYgd2UgdXNlZCBzb21lIEpTT04gc3RydWN0dXJl IGluIGEgSldLLiBGb3IgaW5zdGFuY2UsIHNlcGFyYXRlIHRoZSBtYXRocyBmaWVsZHMgb2YgdGhl IHB1YmxpYyBrZXkgKG4sIGUsIOKApikgZnJvbSB0aGUgYWRtaW5pc3RyYXRpdmUgcGFydHMgKGtl eS1pZCwgY2VydGlmaWNhdGUsIHVzYWdl4oCmKS4gSW5zdGVhZCwgSldLIGdvZXMgZm9yIGEgZmxh dCBidWNrZXQgZm9yIGFsbCBhIGtleeKAmXMgaW5mby4gSGVuY2UsIHdlIGhhdmUgcG90ZW50aWFs IHByb2JsZW1zIHdpdGggY2xhc2hlcyBvZiBuYW1lcyBmcm9tIHF1aXRlIHNlcGFyYXRlIGRvbWFp bnMuIFdlIHNob3VsZCBmaXggdGhlIHN0cnVjdHVyZSwgaW5zdGVhZCBvZiB0aW5rZXJpbmcgd2l0 aCB0aGUgbmFtZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBeGVsLk5l bm5rZXJAdGVsZWtvbS5kZQ0KU2VudDogRnJpZGF5LCAxOSBPY3RvYmVyIDIwMTIgNTo1MCBQTQ0K VG86IGpvc2VAaWV0Zi5vcmcNCkNjOiBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTsgc2FraW11 cmFAZ21haWwuY29tOyB2bGFkaW1pckBuaW1idXNkcy5jb20NClN1YmplY3Q6IFJlOiBbam9zZV0g eHBvDQoNCkkgZG9u4oCZdCBrbm93IHdoeSB0aGUgZXhwIGluIGp3ayBuZWVkcyB0byBiZSBjaGFu Z2VkLiBGcm9tIGEgZGV2ZWxvcGVyIFBPVyB0aGVyZSBpcyBubyBuZWVkLiBZb3UgYWx3YXlzIGtu b3cgd2hpY2gg4oCcZXhw4oCdIGlzIHRoZSByaWdodCBvbmUuDQpJIHdvdWxkIHJldmVyc2UgdGhl IGNoYW5nZSBmcm9tIGV4cCB0byB4cG8uIERldmVsb3BlcnMgZG9u4oCZdCBuZWVkIGl0IGFuZCBt YW55IGRpZCBub3QgdXBkYXRlIHRoZWlyIGltcGxlbWVudGF0aW9uIHRvIGluY29ycG9yYXRlIHRo ZSBleHAtPnhwbyB0cmFuc2l0aW9uLg0KDQpBY3R1YWxseSBJIGRvbuKAmXQgY2FyZSAobXVjaCkg aG93IHRoZSBwYXJhbWV0ZXJzIGFyZSBuYW1lZC4gQWx0aG91Z2ggSSB3b3VsZCBsaWtlIHRvIHN0 aWNrIHRvIHRoZSAzLWxldHRlciBzY2hlbWUgSSBhbSBPSyB3aXRoIHRoZSBuLGUgcHJvcG9zYWwu DQpCdXQgcGxlYXNlIHN0b3AgbWFraW5nIGJyZWFraW5nIGNoYW5nZXMgKGVzcGVjaWFsbHkgcmVu YW1pbmcgcGFyYW1ldGVycyB3aGljaCBsZWFkcyBvbmx5IHRvIG1vcmUgd29yayBhbmQgbm8gZ2Fp bikuDQoNCkNhc2UxOiBoYXJtIGlzIGFscmVhZHkgZG9uZSAtPiBzdGljayB3aXRoIHhwbyBhbmQg ZG9u4oCZdCBjaGFuZ2UgQUdBSU4uDQpDYXNlMjogTW9zdCBpbXBsZW1lbnRhdGlvbiBoYXZlbuKA mXQgY2hhbmdlZCB5ZXQgLT4gcmV2ZXJ0IHRvIGV4cA0KQ2FzZTM6IHhwbyBpcyBqdXN0IHN0dXBp ZCAtPiBuLGUgaXMgYmV0dGVyIC0+IGFub3RoZXIgY2hhbmdlIC0+IE9oIG5vIC0+IHJldmVydCB0 byBleHANCg0KQWdhaW46IEkgc3VnZ2VzdCB0byByZXZlcnQgdG8gZXhwIGFuZCBtYWtlIHRoZSBp bXBsZW1lbnRlcnMgaGFwcHkuDQoNCkF4ZWwNCg0KQ2PigJlpbmcgTmF0IGJlY2F1c2UgSSBkb27i gJl0IHdhbnQgdG8gZ2l2ZSBhd2F5IGhpcyBkZXZlbG9wZXLigJlzIGVtYWlscyB3aXRob3V0IGFz a2luZy4NCg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC cmlhbiBDYW1wYmVsbA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE3LCAyMDEyIDM6MDkgUE0N ClRvOiBWbGFkaW1pciBEemh1dmlub3YgLyBOaW1idXNEUw0KQ2M6IGpvc2VAaWV0Zi5vcmc8bWFp bHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2pvc2VdIHhwbw0KDQorMSAoaWYgYSBw YXJhbWV0ZXIgbmFtZSBjaGFuZ2UgaXMgZ29pbmcgdG8gaGFwcGVuIGFueXdheSkNCk9uIFdlZCwg T2N0IDE3LCAyMDEyIGF0IDI6MjQgQU0sIFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTIDx2 bGFkaW1pckBuaW1idXNkcy5jb208bWFpbHRvOnZsYWRpbWlyQG5pbWJ1c2RzLmNvbT4+IHdyb3Rl Og0KKzENCg0KLS0NClZsYWRpbWlyIER6aHV2aW5vdiA6IHd3dy5OaW1idXNEUy5jb208aHR0cDov L3d3dy5OaW1idXNEUy5jb20+IDogdmxhZGltaXJAbmltYnVzZHMuY29tPG1haWx0bzp2bGFkaW1p ckBuaW1idXNkcy5jb20+DQoNCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0K U3ViamVjdDogUmU6IFtqb3NlXSB4cG8NCkZyb206IFJpY2hhcmQgQmFybmVzIDxyYmFybmVzQGJi bi5jb208bWFpbHRvOnJiYXJuZXNAYmJuLmNvbT4+DQpEYXRlOiBXZWQsIE9jdG9iZXIgMTcsIDIw MTIgMTI6MTUgYW0NClRvOiAiTWFuZ2VyLCBKYW1lcyBIIiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50 ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4+DQpDYzog TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+PiwgImpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+ Ig0KPGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+Pg0KDQoNCisxDQoNCk9uIE9j dCAxNiwgMjAxMiwgYXQgNjo1NSBQTSwgTWFuZ2VyLCBKYW1lcyBIIHdyb3RlOg0KDQo+PiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTA2DQo+ PiDigKIgQ2hhbmdlZCB0aGUgbmFtZSBvZiB0aGUgSldLIFJTQSBleHBvbmVudCBwYXJhbWV0ZXIg ZnJvbSBleHAgdG8geHBvIHNvIGFzIHRvIGFsbG93IHRoZSBwb3RlbnRpYWwgdXNlIG9mIHRoZSBu YW1lIGV4cCBmb3IgYSBmdXR1cmUgZXh0ZW5zaW9uIHRoYXQgbWlnaHQgZGVmaW5lIGFuIGV4cGly YXRpb24gcGFyYW1ldGVyIGZvciBrZXlzLiAoVGhlIGV4cCBuYW1lIGlzIGFscmVhZHkgdXNlZCBm b3IgdGhpcyBwdXJwb3NlIGluIHRoZSBKV1Qgc3BlY2lmaWNhdGlvbi4pDQo+DQo+ICJuIiBhbmQg ImUiIHdvdWxkIGJlIGJldHRlciB0aGFuICJtb2QiIGFuZCAieHBvIi4NCj4gIm4iIGFuZCAiZSIg YXJlIHZlcnkgd2lkZWx5IHVzZWQgZm9yIHRoZSBSU0EgbW9kdWx1cyBhbmQgcHVibGljIGV4cG9u ZW50Lg0KPg0KPiBzXmUgPSBtIG1vZCBuDQo+DQo+IC0tDQo+IEphbWVzIE1hbmdlcg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBqb3NlIG1haWxp bmcgbGlzdA0KPiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGll dGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9qb3NlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0K --_000_255B9BB34FB7D647A506DC292726F6E114FDEC39C2WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgs IGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4t dG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdp bi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFu Zz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnGV4cOKAnSB3b3VsZG7i gJl0IGNsYXNoIGlmIHdlIHVzZWQgc29tZSBKU09OIHN0cnVjdHVyZSBpbiBhIEpXSy4gRm9yIGlu c3RhbmNlLCBzZXBhcmF0ZSB0aGUgbWF0aHMgZmllbGRzIG9mIHRoZSBwdWJsaWMga2V5IChuLCBl LCDigKYpIGZyb20gdGhlIGFkbWluaXN0cmF0aXZlIHBhcnRzIChrZXktaWQsIGNlcnRpZmljYXRl LCB1c2FnZeKApikuIEluc3RlYWQsIEpXSyBnb2VzIGZvciBhIGZsYXQgYnVja2V0IGZvciBhbGwg YSBrZXnigJlzIGluZm8uIEhlbmNlLCB3ZSBoYXZlIHBvdGVudGlhbCBwcm9ibGVtcyB3aXRoIGNs YXNoZXMgb2YgbmFtZXMgZnJvbSBxdWl0ZSBzZXBhcmF0ZSBkb21haW5zLiBXZSBzaG91bGQgZml4 IHRoZSBzdHJ1Y3R1cmUsIGluc3RlYWQgb2YgdGlua2VyaW5nIHdpdGggdGhlIG5hbWUuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGpvc2UtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5B eGVsLk5lbm5rZXJAdGVsZWtvbS5kZTxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCAxOSBPY3RvYmVy IDIwMTIgNTo1MCBQTTxicj48Yj5Ubzo8L2I+IGpvc2VAaWV0Zi5vcmc8YnI+PGI+Q2M6PC9iPiBi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTsgc2FraW11cmFAZ21haWwuY29tOyB2bGFkaW1pckBu aW1idXNkcy5jb208YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0geHBvPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PkkgZG9u4oCZdCBrbm93IHdoeSB0aGUgZXhwIGluIGp3ayBuZWVkcyB0byBiZSBjaGFuZ2VkLiBG cm9tIGEgZGV2ZWxvcGVyIFBPVyB0aGVyZSBpcyBubyBuZWVkLiBZb3UgYWx3YXlzIGtub3cgd2hp Y2gg4oCcZXhw4oCdIGlzIHRoZSByaWdodCBvbmUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB3b3VsZCBy ZXZlcnNlIHRoZSBjaGFuZ2UgZnJvbSBleHAgdG8geHBvLiBEZXZlbG9wZXJzIGRvbuKAmXQgbmVl ZCBpdCBhbmQgbWFueSBkaWQgbm90IHVwZGF0ZSB0aGVpciBpbXBsZW1lbnRhdGlvbiB0byBpbmNv cnBvcmF0ZSB0aGUgZXhwLSZndDt4cG8gdHJhbnNpdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5BY3R1YWxseSBJIGRvbuKAmXQgY2FyZSAobXVjaCkgaG93IHRo ZSBwYXJhbWV0ZXJzIGFyZSBuYW1lZC4gQWx0aG91Z2ggSSB3b3VsZCBsaWtlIHRvIHN0aWNrIHRv IHRoZSAzLWxldHRlciBzY2hlbWUgSSBhbSBPSyB3aXRoIHRoZSBuLGUgcHJvcG9zYWwuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+QnV0IHBsZWFzZSBzdG9wIG1ha2luZyBicmVha2luZyBjaGFuZ2VzIChlc3Bl Y2lhbGx5IHJlbmFtaW5nIHBhcmFtZXRlcnMgd2hpY2ggbGVhZHMgb25seSB0byBtb3JlIHdvcmsg YW5kIG5vIGdhaW4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNh c2UxOiBoYXJtIGlzIGFscmVhZHkgZG9uZSAtJmd0OyBzdGljayB3aXRoIHhwbyBhbmQgZG9u4oCZ dCBjaGFuZ2UgQUdBSU4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2FzZTI6IE1vc3QgaW1wbGVtZW50YXRp b24gaGF2ZW7igJl0IGNoYW5nZWQgeWV0IC0mZ3Q7IHJldmVydCB0byBleHA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5DYXNlMzogeHBvIGlzIGp1c3Qgc3R1cGlkIC0mZ3Q7IG4sZSBpcyBiZXR0ZXIgLSZndDsg YW5vdGhlciBjaGFuZ2UgLSZndDsgT2ggbm8gLSZndDsgcmV2ZXJ0IHRvIGV4cDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFnYWluOiBJIHN1Z2dlc3QgdG8gcmV2ZXJ0 IHRvIGV4cCBhbmQgbWFrZSB0aGUgaW1wbGVtZW50ZXJzIGhhcHB5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkF4ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5DY+KAmWluZyBOYXQgYmVjYXVzZSBJIGRvbuKAmXQgd2FudCB0byBnaXZl IGF3YXkgaGlzIGRldmVsb3BlcuKAmXMgZW1haWxzIHdpdGhvdXQgYXNraW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhh bGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9i ZXIgMTcsIDIwMTIgMzowOSBQTTxicj48Yj5Ubzo8L2I+IFZsYWRpbWlyIER6aHV2aW5vdiAvIE5p bWJ1c0RTPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VA aWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIHhwbzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1VUz4rMSAoaWYgYSBwYXJhbWV0ZXIgbmFtZSBjaGFuZ2Ug aXMgZ29pbmcgdG8gaGFwcGVuIGFueXdheSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5PbiBXZWQsIE9jdCAxNywgMjAxMiBhdCAy OjI0IEFNLCBWbGFkaW1pciBEemh1dmlub3YgLyBOaW1idXNEUyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnZsYWRpbWlyQG5pbWJ1c2RzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZsYWRpbWlyQG5pbWJ1c2Rz LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz4rMTxicj48YnI+LS08YnI+VmxhZGltaXIgRHpodXZpbm92IDog PGEgaHJlZj0iaHR0cDovL3d3dy5OaW1idXNEUy5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuTmlt YnVzRFMuY29tPC9hPiA6IDxhIGhyZWY9Im1haWx0bzp2bGFkaW1pckBuaW1idXNkcy5jb20iPnZs YWRpbWlyQG5pbWJ1c2RzLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxicj48YnI+LS0tLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0tLTxicj5TdWJqZWN0OiBSZTogW2pvc2VdIHhwbzxicj5Gcm9tOiBS aWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJiYXJuZXNAYmJuLmNvbSI+cmJhcm5l c0BiYm4uY29tPC9hPiZndDs8YnI+RGF0ZTogV2VkLCBPY3RvYmVyIDE3LCAyMDEyIDEyOjE1IGFt PGJyPlRvOiAmcXVvdDtNYW5nZXIsIEphbWVzIEgmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpK YW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIj5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0 cmEuY29tPC9hPiZndDs8YnI+Q2M6IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwv YT4mcXVvdDs8YnI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYu b3JnPC9hPiZndDs8YnI+PGJyPjxicj4rMTxicj48YnI+T24gT2N0IDE2LCAyMDEyLCBhdCA2OjU1 IFBNLCBNYW5nZXIsIEphbWVzIEggd3JvdGU6PGJyPjxicj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTA2IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3Nl LWpzb24td2ViLWtleS0wNjwvYT48YnI+Jmd0OyZndDsg4oCiIENoYW5nZWQgdGhlIG5hbWUgb2Yg dGhlIEpXSyBSU0EgZXhwb25lbnQgcGFyYW1ldGVyIGZyb20gZXhwIHRvIHhwbyBzbyBhcyB0byBh bGxvdyB0aGUgcG90ZW50aWFsIHVzZSBvZiB0aGUgbmFtZSBleHAgZm9yIGEgZnV0dXJlIGV4dGVu c2lvbiB0aGF0IG1pZ2h0IGRlZmluZSBhbiBleHBpcmF0aW9uIHBhcmFtZXRlciBmb3Iga2V5cy4g KFRoZSBleHAgbmFtZSBpcyBhbHJlYWR5IHVzZWQgZm9yIHRoaXMgcHVycG9zZSBpbiB0aGUgSldU IHNwZWNpZmljYXRpb24uKTxicj4mZ3Q7PGJyPiZndDsgJnF1b3Q7biZxdW90OyBhbmQgJnF1b3Q7 ZSZxdW90OyB3b3VsZCBiZSBiZXR0ZXIgdGhhbiAmcXVvdDttb2QmcXVvdDsgYW5kICZxdW90O3hw byZxdW90Oy48YnI+Jmd0OyAmcXVvdDtuJnF1b3Q7IGFuZCAmcXVvdDtlJnF1b3Q7IGFyZSB2ZXJ5 IHdpZGVseSB1c2VkIGZvciB0aGUgUlNBIG1vZHVsdXMgYW5kIHB1YmxpYyBleHBvbmVudC48YnI+ Jmd0Ozxicj4mZ3Q7IHNeZSA9IG0gbW9kIG48YnI+Jmd0Ozxicj4mZ3Q7IC0tPGJyPiZndDsgSmFt ZXMgTWFuZ2VyPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Jmd0OyBqb3NlIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0 bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48YnI+PGJyPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPmpvc2UgbWFpbGlu ZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9h Pjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2Ui IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pv c2U8L2E+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPmpvc2UgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5q b3NlQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114FDEC39C2WSMSG3153Vsrv_-- From Axel.Nennker@telekom.de Fri Oct 19 02:46:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7056221F8562 for ; Fri, 19 Oct 2012 02:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Okkq4nyyeo+u for ; Fri, 19 Oct 2012 02:46:57 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8621F855B for ; Fri, 19 Oct 2012 02:46:56 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 19 Oct 2012 11:46:54 +0200 Received: from HE113558.emea1.cds.t-internal.com (10.125.65.100) by HE101251.emea1.cds.t-internal.com (10.125.92.154) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 19 Oct 2012 11:46:53 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE113558.emea1.cds.t-internal.com ([2002:7cd:4164::7cd:4164]) with mapi; Fri, 19 Oct 2012 11:46:53 +0200 From: To: Date: Fri, 19 Oct 2012 11:46:52 +0200 Thread-Topic: [jose] xpo Thread-Index: Ac2saK8mHKFHzhbaT3KrDB3AfYKSXwBWuvgQAAFgZsAABFsCEA== Message-ID: References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402520665EF89HE111541eme_" MIME-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] xpo 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, 19 Oct 2012 09:46:59 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402520665EF89HE111541eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3RydWN0dXJlIG1lYW5zIOKAnG1vcmUgYnl0ZXPigJ0uIEkgZ3Vlc3MgdGhhdCB3YXMgdGhlIHJl YXNvbiB0byBnbyBmb3IgeHBvLiAoSSBjYW5ub3QgZmluZCB0aGUgYXJndW1lbnRzIG9uIHRoZSBt YWlsaW5nIGxpc3QpDQoNCkkgY2hhbmdlZCBteSBtaW5kOiBBbHRob3VnaCBJIGRvbuKAmXQgbGlr ZSB4cG8gSSB0aGluayB0aGF0IGluc3RlYWQgb2YgZ29pbmcgYmFjayB3ZSBzaG91bGQgbm93IGxp dmUgd2l0aCB4cG8uIENoYW5naW5nIGFueSBpbXBsZW1lbnRhdGlvbiB0byB1bmRlcnN0YW5kIHhw byBpcyBub3QgdGhhdCBtdWNoIHdvcmsuDQpBbmQgaXQgaXMgYmV0dGVyIHRvIG1pbmltaXplIGJy ZWFraW5nIGNoYW5nZXMuDQoNCkF4ZWwNCg0KRnJvbTogTWFuZ2VyLCBKYW1lcyBIIFttYWlsdG86 SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAx OSwgMjAxMiA5OjE4IEFNDQpUbzogTmVubmtlciwgQXhlbDsgam9zZUBpZXRmLm9yZw0KQ2M6IGJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tOyBzYWtpbXVyYUBnbWFpbC5jb207IHZsYWRpbWlyQG5p bWJ1c2RzLmNvbQ0KU3ViamVjdDogUkU6IFtqb3NlXSB4cG8NCg0K4oCcZXhw4oCdIHdvdWxkbuKA mXQgY2xhc2ggaWYgd2UgdXNlZCBzb21lIEpTT04gc3RydWN0dXJlIGluIGEgSldLLiBGb3IgaW5z dGFuY2UsIHNlcGFyYXRlIHRoZSBtYXRocyBmaWVsZHMgb2YgdGhlIHB1YmxpYyBrZXkgKG4sIGUs IOKApikgZnJvbSB0aGUgYWRtaW5pc3RyYXRpdmUgcGFydHMgKGtleS1pZCwgY2VydGlmaWNhdGUs IHVzYWdl4oCmKS4gSW5zdGVhZCwgSldLIGdvZXMgZm9yIGEgZmxhdCBidWNrZXQgZm9yIGFsbCBh IGtleeKAmXMgaW5mby4gSGVuY2UsIHdlIGhhdmUgcG90ZW50aWFsIHByb2JsZW1zIHdpdGggY2xh c2hlcyBvZiBuYW1lcyBmcm9tIHF1aXRlIHNlcGFyYXRlIGRvbWFpbnMuIFdlIHNob3VsZCBmaXgg dGhlIHN0cnVjdHVyZSwgaW5zdGVhZCBvZiB0aW5rZXJpbmcgd2l0aCB0aGUgbmFtZS4NCg0KLS0N CkphbWVzIE1hbmdlcg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3Nl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBeGVsLk5lbm5rZXJAdGVsZWtvbS5kZQ0K U2VudDogRnJpZGF5LCAxOSBPY3RvYmVyIDIwMTIgNTo1MCBQTQ0KVG86IGpvc2VAaWV0Zi5vcmcN CkNjOiBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTsgc2FraW11cmFAZ21haWwuY29tOyB2bGFk aW1pckBuaW1idXNkcy5jb20NClN1YmplY3Q6IFJlOiBbam9zZV0geHBvDQoNCkkgZG9u4oCZdCBr bm93IHdoeSB0aGUgZXhwIGluIGp3ayBuZWVkcyB0byBiZSBjaGFuZ2VkLiBGcm9tIGEgZGV2ZWxv cGVyIFBPVyB0aGVyZSBpcyBubyBuZWVkLiBZb3UgYWx3YXlzIGtub3cgd2hpY2gg4oCcZXhw4oCd IGlzIHRoZSByaWdodCBvbmUuDQpJIHdvdWxkIHJldmVyc2UgdGhlIGNoYW5nZSBmcm9tIGV4cCB0 byB4cG8uIERldmVsb3BlcnMgZG9u4oCZdCBuZWVkIGl0IGFuZCBtYW55IGRpZCBub3QgdXBkYXRl IHRoZWlyIGltcGxlbWVudGF0aW9uIHRvIGluY29ycG9yYXRlIHRoZSBleHAtPnhwbyB0cmFuc2l0 aW9uLg0KDQpBY3R1YWxseSBJIGRvbuKAmXQgY2FyZSAobXVjaCkgaG93IHRoZSBwYXJhbWV0ZXJz IGFyZSBuYW1lZC4gQWx0aG91Z2ggSSB3b3VsZCBsaWtlIHRvIHN0aWNrIHRvIHRoZSAzLWxldHRl ciBzY2hlbWUgSSBhbSBPSyB3aXRoIHRoZSBuLGUgcHJvcG9zYWwuDQpCdXQgcGxlYXNlIHN0b3Ag bWFraW5nIGJyZWFraW5nIGNoYW5nZXMgKGVzcGVjaWFsbHkgcmVuYW1pbmcgcGFyYW1ldGVycyB3 aGljaCBsZWFkcyBvbmx5IHRvIG1vcmUgd29yayBhbmQgbm8gZ2FpbikuDQoNCkNhc2UxOiBoYXJt IGlzIGFscmVhZHkgZG9uZSAtPiBzdGljayB3aXRoIHhwbyBhbmQgZG9u4oCZdCBjaGFuZ2UgQUdB SU4uDQpDYXNlMjogTW9zdCBpbXBsZW1lbnRhdGlvbiBoYXZlbuKAmXQgY2hhbmdlZCB5ZXQgLT4g cmV2ZXJ0IHRvIGV4cA0KQ2FzZTM6IHhwbyBpcyBqdXN0IHN0dXBpZCAtPiBuLGUgaXMgYmV0dGVy IC0+IGFub3RoZXIgY2hhbmdlIC0+IE9oIG5vIC0+IHJldmVydCB0byBleHANCg0KQWdhaW46IEkg c3VnZ2VzdCB0byByZXZlcnQgdG8gZXhwIGFuZCBtYWtlIHRoZSBpbXBsZW1lbnRlcnMgaGFwcHku DQoNCkF4ZWwNCg0KQ2PigJlpbmcgTmF0IGJlY2F1c2UgSSBkb27igJl0IHdhbnQgdG8gZ2l2ZSBh d2F5IGhpcyBkZXZlbG9wZXLigJlzIGVtYWlscyB3aXRob3V0IGFza2luZy4NCg0KDQpGcm9tOiBq b3NlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2Vu dDogV2VkbmVzZGF5LCBPY3RvYmVyIDE3LCAyMDEyIDM6MDkgUE0NClRvOiBWbGFkaW1pciBEemh1 dmlub3YgLyBOaW1idXNEUw0KQ2M6IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW2pvc2VdIHhwbw0KDQorMSAoaWYgYSBwYXJhbWV0ZXIgbmFtZSBjaGFu Z2UgaXMgZ29pbmcgdG8gaGFwcGVuIGFueXdheSkNCk9uIFdlZCwgT2N0IDE3LCAyMDEyIGF0IDI6 MjQgQU0sIFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTIDx2bGFkaW1pckBuaW1idXNkcy5j b208bWFpbHRvOnZsYWRpbWlyQG5pbWJ1c2RzLmNvbT4+IHdyb3RlOg0KKzENCg0KLS0NClZsYWRp bWlyIER6aHV2aW5vdiA6IHd3dy5OaW1idXNEUy5jb208aHR0cDovL3d3dy5OaW1idXNEUy5jb20+ IDogdmxhZGltaXJAbmltYnVzZHMuY29tPG1haWx0bzp2bGFkaW1pckBuaW1idXNkcy5jb20+DQoN Cg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogUmU6IFtqb3Nl XSB4cG8NCkZyb206IFJpY2hhcmQgQmFybmVzIDxyYmFybmVzQGJibi5jb208bWFpbHRvOnJiYXJu ZXNAYmJuLmNvbT4+DQpEYXRlOiBXZWQsIE9jdG9iZXIgMTcsIDIwMTIgMTI6MTUgYW0NClRvOiAi TWFuZ2VyLCBKYW1lcyBIIiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86 SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4+DQpDYzogTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ PiwgImpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+Ig0KPGpvc2VAaWV0Zi5vcmc8 bWFpbHRvOmpvc2VAaWV0Zi5vcmc+Pg0KDQoNCisxDQoNCk9uIE9jdCAxNiwgMjAxMiwgYXQgNjo1 NSBQTSwgTWFuZ2VyLCBKYW1lcyBIIHdyb3RlOg0KDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTA2DQo+PiDigKIgQ2hhbmdlZCB0aGUg bmFtZSBvZiB0aGUgSldLIFJTQSBleHBvbmVudCBwYXJhbWV0ZXIgZnJvbSBleHAgdG8geHBvIHNv IGFzIHRvIGFsbG93IHRoZSBwb3RlbnRpYWwgdXNlIG9mIHRoZSBuYW1lIGV4cCBmb3IgYSBmdXR1 cmUgZXh0ZW5zaW9uIHRoYXQgbWlnaHQgZGVmaW5lIGFuIGV4cGlyYXRpb24gcGFyYW1ldGVyIGZv ciBrZXlzLiAoVGhlIGV4cCBuYW1lIGlzIGFscmVhZHkgdXNlZCBmb3IgdGhpcyBwdXJwb3NlIGlu IHRoZSBKV1Qgc3BlY2lmaWNhdGlvbi4pDQo+DQo+ICJuIiBhbmQgImUiIHdvdWxkIGJlIGJldHRl ciB0aGFuICJtb2QiIGFuZCAieHBvIi4NCj4gIm4iIGFuZCAiZSIgYXJlIHZlcnkgd2lkZWx5IHVz ZWQgZm9yIHRoZSBSU0EgbW9kdWx1cyBhbmQgcHVibGljIGV4cG9uZW50Lg0KPg0KPiBzXmUgPSBt IG1vZCBuDQo+DQo+IC0tDQo+IEphbWVzIE1hbmdlcg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBqb3NlIG1haWxpbmcgbGlzdA0KPiBqb3NlQGll dGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2pvc2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3Nl QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWls aW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0K --_000_CE8995AB5D178F44A2154F5C9A97CAF402520665EF89HE111541eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1y aWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxl PjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlN0cnVjdHVyZSBtZWFucyDigJxtb3JlIGJ5dGVz4oCdLiBJIGd1ZXNzIHRoYXQg d2FzIHRoZSByZWFzb24gdG8gZ28gZm9yIHhwby4gKEkgY2Fubm90IGZpbmQgdGhlIGFyZ3VtZW50 cyBvbiB0aGUgbWFpbGluZyBsaXN0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBjaGFuZ2VkIG15IG1p bmQ6IEFsdGhvdWdoIEkgZG9u4oCZdCBsaWtlIHhwbyBJIHRoaW5rIHRoYXQgaW5zdGVhZCBvZiBn b2luZyBiYWNrIHdlIHNob3VsZCBub3cgbGl2ZSB3aXRoIHhwby4gQ2hhbmdpbmcgYW55IGltcGxl bWVudGF0aW9uIHRvIHVuZGVyc3RhbmQgeHBvIGlzIG5vdCB0aGF0IG11Y2ggd29yay48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ QW5kIGl0IGlzIGJldHRlciB0byBtaW5pbWl6ZSBicmVha2luZyBjaGFuZ2VzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+QXhlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2Vy QHRlYW0udGVsc3RyYS5jb21dIDxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDE5LCAy MDEyIDk6MTggQU08YnI+PGI+VG86PC9iPiBOZW5ua2VyLCBBeGVsOyBqb3NlQGlldGYub3JnPGJy PjxiPkNjOjwvYj4gYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb207IHNha2ltdXJhQGdtYWlsLmNv bTsgdmxhZGltaXJAbmltYnVzZHMuY29tPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW2pvc2VdIHhw bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz7igJxleHDigJ0gd291bGRu4oCZdCBjbGFzaCBpZiB3ZSB1c2VkIHNvbWUg SlNPTiBzdHJ1Y3R1cmUgaW4gYSBKV0suIEZvciBpbnN0YW5jZSwgc2VwYXJhdGUgdGhlIG1hdGhz IGZpZWxkcyBvZiB0aGUgcHVibGljIGtleSAobiwgZSwg4oCmKSBmcm9tIHRoZSBhZG1pbmlzdHJh dGl2ZSBwYXJ0cyAoa2V5LWlkLCBjZXJ0aWZpY2F0ZSwgdXNhZ2XigKYpLiBJbnN0ZWFkLCBKV0sg Z29lcyBmb3IgYSBmbGF0IGJ1Y2tldCBmb3IgYWxsIGEga2V54oCZcyBpbmZvLiBIZW5jZSwgd2Ug aGF2ZSBwb3RlbnRpYWwgcHJvYmxlbXMgd2l0aCBjbGFzaGVzIG9mIG5hbWVzIGZyb20gcXVpdGUg c2VwYXJhdGUgZG9tYWlucy4gV2Ugc2hvdWxkIGZpeCB0aGUgc3RydWN0dXJlLCBpbnN0ZWFkIG9m IHRpbmtlcmluZyB3aXRoIHRoZSBuYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkF4ZWwu TmVubmtlckB0ZWxla29tLmRlPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIDE5IE9jdG9iZXIgMjAx MiA1OjUwIFBNPGJyPjxiPlRvOjwvYj4gam9zZUBpZXRmLm9yZzxicj48Yj5DYzo8L2I+IGJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tOyBzYWtpbXVyYUBnbWFpbC5jb207IHZsYWRpbWlyQG5pbWJ1 c2RzLmNvbTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3NlXSB4cG88bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkkgZG9u4oCZdCBrbm93IHdoeSB0aGUgZXhwIGluIGp3ayBuZWVkcyB0byBiZSBj aGFuZ2VkLiBGcm9tIGEgZGV2ZWxvcGVyIFBPVyB0aGVyZSBpcyBubyBuZWVkLiBZb3UgYWx3YXlz IGtub3cgd2hpY2gg4oCcZXhw4oCdIGlzIHRoZSByaWdodCBvbmUuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgd291bGQgcmV2 ZXJzZSB0aGUgY2hhbmdlIGZyb20gZXhwIHRvIHhwby4gRGV2ZWxvcGVycyBkb27igJl0IG5lZWQg aXQgYW5kIG1hbnkgZGlkIG5vdCB1cGRhdGUgdGhlaXIgaW1wbGVtZW50YXRpb24gdG8gaW5jb3Jw b3JhdGUgdGhlIGV4cC0mZ3Q7eHBvIHRyYW5zaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BY3R1 YWxseSBJIGRvbuKAmXQgY2FyZSAobXVjaCkgaG93IHRoZSBwYXJhbWV0ZXJzIGFyZSBuYW1lZC4g QWx0aG91Z2ggSSB3b3VsZCBsaWtlIHRvIHN0aWNrIHRvIHRoZSAzLWxldHRlciBzY2hlbWUgSSBh bSBPSyB3aXRoIHRoZSBuLGUgcHJvcG9zYWwuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJ1dCBwbGVhc2Ugc3RvcCBtYWtpbmcg YnJlYWtpbmcgY2hhbmdlcyAoZXNwZWNpYWxseSByZW5hbWluZyBwYXJhbWV0ZXJzIHdoaWNoIGxl YWRzIG9ubHkgdG8gbW9yZSB3b3JrIGFuZCBubyBnYWluKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNh c2UxOiBoYXJtIGlzIGFscmVhZHkgZG9uZSAtJmd0OyBzdGljayB3aXRoIHhwbyBhbmQgZG9u4oCZ dCBjaGFuZ2UgQUdBSU4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNhc2UyOiBNb3N0IGltcGxlbWVudGF0aW9uIGhhdmVu4oCZ dCBjaGFuZ2VkIHlldCAtJmd0OyByZXZlcnQgdG8gZXhwPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNhc2UzOiB4cG8gaXMganVz dCBzdHVwaWQgLSZndDsgbixlIGlzIGJldHRlciAtJmd0OyBhbm90aGVyIGNoYW5nZSAtJmd0OyBP aCBubyAtJmd0OyByZXZlcnQgdG8gZXhwPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BZ2FpbjogSSBzdWdn ZXN0IHRvIHJldmVydCB0byBleHAgYW5kIG1ha2UgdGhlIGltcGxlbWVudGVycyBoYXBweS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkF4ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNj4oCZaW5nIE5hdCBiZWNh dXNlIEkgZG9u4oCZdCB3YW50IHRvIGdpdmUgYXdheSBoaXMgZGV2ZWxvcGVy4oCZcyBlbWFpbHMg d2l0aG91dCBhc2tpbmcuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+IDxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPmpvc2UtYm91bmNlc0Bp ZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENh bXBiZWxsPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTIgMzowOSBQ TTxicj48Yj5Ubzo8L2I+IFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTPGJyPjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPjxi PlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIHhwbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+KzEgKGlmIGEgcGFyYW1ldGVyIG5hbWUgY2hhbmdlIGlz IGdvaW5nIHRvIGhhcHBlbiBhbnl3YXkpPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+T24gV2VkLCBPY3QgMTcsIDIwMTIgYXQgMjoyNCBBTSwgVmxhZGltaXIgRHpodXZpbm92 IC8gTmltYnVzRFMgJmx0OzxhIGhyZWY9Im1haWx0bzp2bGFkaW1pckBuaW1idXNkcy5jb20iIHRh cmdldD0iX2JsYW5rIj52bGFkaW1pckBuaW1idXNkcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+KzE8YnI+PGJyPi0tPGJyPlZsYWRpbWlyIER6aHV2 aW5vdiA6IDxhIGhyZWY9Imh0dHA6Ly93d3cuTmltYnVzRFMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ d3d3Lk5pbWJ1c0RTLmNvbTwvYT4gOiA8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAbmltYnVzZHMu Y29tIj52bGFkaW1pckBuaW1idXNkcy5jb208L2E+PG86cD48L286cD48L3A+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0t LS08YnI+U3ViamVjdDogUmU6IFtqb3NlXSB4cG88YnI+RnJvbTogUmljaGFyZCBCYXJuZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpyYmFybmVzQGJibi5jb20iPnJiYXJuZXNAYmJuLmNvbTwvYT4mZ3Q7 PGJyPkRhdGU6IFdlZCwgT2N0b2JlciAxNywgMjAxMiAxMjoxNSBhbTxicj5UbzogJnF1b3Q7TWFu Z2VyLCBKYW1lcyBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbSI+SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTwvYT4mZ3Q7PGJy PkNjOiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+JnF1b3Q7PGJyPiZsdDs8 YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxi cj48YnI+KzE8YnI+PGJyPk9uIE9jdCAxNiwgMjAxMiwgYXQgNjo1NSBQTSwgTWFuZ2VyLCBKYW1l cyBIIHdyb3RlOjxicj48YnI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMDY8 L2E+PGJyPiZndDsmZ3Q7IOKAoiBDaGFuZ2VkIHRoZSBuYW1lIG9mIHRoZSBKV0sgUlNBIGV4cG9u ZW50IHBhcmFtZXRlciBmcm9tIGV4cCB0byB4cG8gc28gYXMgdG8gYWxsb3cgdGhlIHBvdGVudGlh bCB1c2Ugb2YgdGhlIG5hbWUgZXhwIGZvciBhIGZ1dHVyZSBleHRlbnNpb24gdGhhdCBtaWdodCBk ZWZpbmUgYW4gZXhwaXJhdGlvbiBwYXJhbWV0ZXIgZm9yIGtleXMuIChUaGUgZXhwIG5hbWUgaXMg YWxyZWFkeSB1c2VkIGZvciB0aGlzIHB1cnBvc2UgaW4gdGhlIEpXVCBzcGVjaWZpY2F0aW9uLik8 YnI+Jmd0Ozxicj4mZ3Q7ICZxdW90O24mcXVvdDsgYW5kICZxdW90O2UmcXVvdDsgd291bGQgYmUg YmV0dGVyIHRoYW4gJnF1b3Q7bW9kJnF1b3Q7IGFuZCAmcXVvdDt4cG8mcXVvdDsuPGJyPiZndDsg JnF1b3Q7biZxdW90OyBhbmQgJnF1b3Q7ZSZxdW90OyBhcmUgdmVyeSB3aWRlbHkgdXNlZCBmb3Ig dGhlIFJTQSBtb2R1bHVzIGFuZCBwdWJsaWMgZXhwb25lbnQuPGJyPiZndDs8YnI+Jmd0OyBzXmUg PSBtIG1vZCBuPGJyPiZndDs8YnI+Jmd0OyAtLTxicj4mZ3Q7IEphbWVzIE1hbmdlcjxicj4mZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsg am9zZSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+ am9zZUBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2pvc2U8L2E+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5qb3NlIG1haWxpbmcgbGlzdDxicj48YSBocmVm PSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxicj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5qb3NlIG1haWxpbmcg bGlzdDxicj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48 YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3Nl PC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_CE8995AB5D178F44A2154F5C9A97CAF402520665EF89HE111541eme_-- From djc.ochtman@gmail.com Sat Oct 20 09:47: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 3F3B921F86E1 for ; Sat, 20 Oct 2012 09:47:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lygRdZHAR+rK for ; Sat, 20 Oct 2012 09:47:45 -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 A23A821F8630 for ; Sat, 20 Oct 2012 09:47:45 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so998739qcg.31 for ; Sat, 20 Oct 2012 09:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=eDQGqaa4eU5cGVrVHMITLMnGVivhw0rPKMdp7UIxJVs=; b=XtfmPKG0KU3k+Q3nmdzW1/aD2afKfw7/0xsorDS5ln7us4c58zGGLKdffiPsmcF68h s+j7k5vJWCp855EQ4Jzgk2TlFx3nC1rPYUPdKXDQSEjiGVQT9gbjBP4XccYOonXu9E1C SpVfLaJHvflW9Yi59OWn0duyvsu2mrko1wLNfKmhf8tPjOXs6Ikh8CnHhSLXYivCpQ2q OhI47Tz8rVVrk8ziK7banwybUlB27FrrKmKPhBr3PgU39qA0Cqy3exrnzE2kAmisyP9k bFKPoCSHSgcv6N65TtzMlYHlbPAS+ByNEcCtNyBdUlhNYUAdbWtV2z+2KQ3/z3lgbJ+W QuyQ== Received: by 10.224.181.138 with SMTP id by10mr2170231qab.4.1350751665184; Sat, 20 Oct 2012 09:47:45 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.49.97.195 with HTTP; Sat, 20 Oct 2012 09:47:24 -0700 (PDT) From: Dirkjan Ochtman Date: Sat, 20 Oct 2012 18:47:24 +0200 X-Google-Sender-Auth: mPy5Z4jLvcIitrpgwte353i_vpQ Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [jose] Feedback on JWS draft-06 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, 20 Oct 2012 16:47:46 -0000 Hi there, I spent some time this week becoming familiar with the JOSE familiar of specifications, in the context of implementing a Mozilla Persona identity provider. This took quite a bit longer than I expected, partially due to a misunderstanding on my side about JWS. In particular, I spent a few hours figuring out why my signatures were being rejected by a Persona server, with the error message given "bad signature in chain". It turns out that the signature I provided was incorrect, because I had used basic RSA signing rather than PKCS1 v1.5 as the JWS spec seems to require. Unfortunately I spent much more time looking at the JWS draft-06 appendices with examples than I spent time looking at JWA, where the algorithms are properly called out. In fact, while JWS seems to refer to the algorithms allowed quite often, the term PKCS is not to be found in the current draft. I haven't read the entire spec, but it seems an oversight not to include a reference to PKCS, particularly in the example sections. Finally, while I appear to be quite late to the party, I was wondering if something like HTTP's Transfer-Encoding has been considered for inclusion. The JOSE family of specs looks very useful, but one use case I had developed earlier (for which I built my own serialization format for encrypted and signed messages) included some form of compression. It seems like a "te" field in the header part could, through a value like "zlib" or "gzip", simply confer to the receiver that the payload must first be decompressed after being decoded. This would neatly encapsulate handling of larger payloads. On the other hands, perhaps compression could easily be done with the encoded header/payload/signature, without much of a loss in compression efficiency due to the order of the compress and encode operations. Cheers, and thanks for the useful specs, Dirkjan From James.H.Manger@team.telstra.com Sun Oct 21 20:25: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 41ADB21F8AE2 for ; Sun, 21 Oct 2012 20:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5mFL+oanMNC for ; Sun, 21 Oct 2012 20:25:50 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 673C621F8A2F for ; Sun, 21 Oct 2012 20:25:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,628,1344175200"; d="scan'208";a="99461868" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 22 Oct 2012 14:25:45 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6872"; a="139206092" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcavi.tcif.telstra.com.au with ESMTP; 22 Oct 2012 14:25:45 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 22 Oct 2012 14:25:44 +1100 From: "Manger, James H" To: "jose@ietf.org" Date: Mon, 22 Oct 2012 14:25:43 +1100 Thread-Topic: draft-secure-cookie-session-protocol Thread-Index: Ac2tIhoVx0YXq/qZQrC5EPQyLO1WoAC3yLEw Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDEC4523@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] draft-secure-cookie-session-protocol 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, 22 Oct 2012 03:25:51 -0000 ZHJhZnQtc2VjdXJlLWNvb2tpZS1zZXNzaW9uLXByb3RvY29sIGRlZmluZXMgYW4gZW5jcnlwdGVk LWFuZC1NQUNlZCBtZXNzYWdlIHN5bnRheCB0aGF0IGlzIGZhaXJseSBjbG9zZSB0byAoYSBzdWJz ZXQgb2YpIEpXRS4NCg0KMS4gSXQgdXNlcyAifCIgdG8gc2VwYXJhdGUgYmFzZTY0dXJsLWVuY29k ZWQgcGFydHM7IGluc3RlYWQgb2YgSldF4oCZcyAiLiIuDQoyLiBJdCBhbHdheXMgaW5jbHVkZXMg dGhlIGNyZWF0aW9uIHRpbWU7IGFuIG9wdGlvbmFsIHNpZ25pbmctdGltZSBoYXMgYmVlbiBwcm9w b3NlZCBmb3IgSldFL0pXUy4NCjMuIEl0IGhhcyBvbmUgKG9wYXF1ZSkgaWQgdG8gaW5kaWNhdGUg dGhlICJzZWN1cml0eSBjb250ZXh0IiwgaWUgdGhlIGFsZ29yaXRobXMgYW5kIGtleXMgdXNlZC4g SldFDQogbWFuZGF0ZXMgYWxnIGlkcyBiZSBwcmVzZW50IGFuZCwgb3B0aW9uYWxseSwgYWxsb3dz IHNlcGFyYXRlIGtleSBpZHMuDQogIA0KVGhlIDNyZCBwb2ludCBpcyB0aGUgaW50ZXJlc3Rpbmcg aXNzdWUuIGRyYWZ0LXNlY3VyZS1jb29raWUtc2Vzc2lvbi1wcm90b2NvbCBoYXMgYSBiZXR0ZXIg YXBwcm9hY2ggdGhhbiBKT1NFIGZvciB0aGlzIGFzcGVjdCAoYW5kIG1vcmUgY29tcGFjdCkuIElk ZW50aWZ5aW5nIHRoZSBrZXkgbmVlZHMgdG8gYmUgbWFuZGF0b3J5LiBXaGV0aGVyIHRoZSBrZXkt aWQgYWxzbyBpZGVudGlmaWVzIHRoZSBhbGdvcml0aG1zLCBvciB3aGV0aGVyIHRoZSBhbGdvcml0 aG1zIGFyZSBpZGVudGlmaWVkIHNlcGFyYXRlbHksIGlzIGEgbWF0dGVyIG9mIHRhc3RlLg0KDQpJ IG1lbnRpb25lZCB0aGlzIGlzc3VlIGEgbW9udGggYWdvICgia2lkIjoiQ3VycmVudCIgaXMgYnJv a2VuKSBbaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9t c2cwMTE1MC5odG1sXS4gZHJhZnQtc2VjdXJlLWNvb2tpZS1zZXNzaW9uLXByb3RvY29sIGlsbHVz dHJhdGVzIGFub3RoZXIgYXBwcm9hY2ggdG8gdGhpcyBpc3N1ZS4NCg0KLS0NCkphbWVzIE1hbmdl cg0K From rbarnes@bbn.com Mon Oct 22 09:08: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 5BA5121F8A57 for ; Mon, 22 Oct 2012 09:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx-JCn8NTrav for ; Mon, 22 Oct 2012 09:08:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD8521F8A21 for ; Mon, 22 Oct 2012 09:08:32 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:56434) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TQKYJ-000G3u-OR for jose@ietf.org; Mon, 22 Oct 2012 12:08:31 -0400 From: Richard Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2012 12:08:31 -0400 References: <20121022160135.6385.43310.idtracker@ietfa.amsl.com> To: jose@ietf.org Message-Id: <109F453E-86EC-478A-98AF-AC7AC8E53A9B@bbn.com> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-use-cases-01.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: Mon, 22 Oct 2012 16:08:33 -0000 FYI, I have updated the use cases document. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-barnes-jose-use-cases-01.txt > Date: October 22, 2012 12:01:35 PM EDT > To: rbarnes@bbn.com >=20 >=20 > A new version of I-D, draft-barnes-jose-use-cases-01.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. >=20 > Filename: draft-barnes-jose-use-cases > Revision: 01 > Title: Use Cases and Requirements for JSON Object = Signing and Encryption (JOSE) > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-use-cases-01.txt > Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-use-cases > Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-use-cases-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-jose-use-cases-01 >=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 >=20 From michael_b_jones@hotmail.com Mon Oct 22 13:23:19 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 98CAF21F894D for ; Mon, 22 Oct 2012 13:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwSyd8slLI0p for ; Mon, 22 Oct 2012 13:23:18 -0700 (PDT) Received: from bay0-omc1-s24.bay0.hotmail.com (bay0-omc1-s24.bay0.hotmail.com [65.54.190.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7826721F8949 for ; Mon, 22 Oct 2012 13:23:18 -0700 (PDT) Received: from BAY171-W108 ([65.54.190.59]) by bay0-omc1-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 13:23:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_44306239-aabd-4fcb-943f-f51dd98a1c99_" X-Originating-IP: [216.239.55.198] From: Michael Jones To: Date: Mon, 22 Oct 2012 13:23:17 -0700 Importance: Normal In-Reply-To: References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net>, , , <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 22 Oct 2012 20:23:17.0899 (UTC) FILETIME=[126655B0:01CDB093] Subject: Re: [jose] xpo 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, 22 Oct 2012 20:23:19 -0000 --_44306239-aabd-4fcb-943f-f51dd98a1c99_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It seems the choice is between (mod=2C xpo) and (n=2C e). A number of peop= le have already expressed a preference for the latter. What do others thin= k? -- Mike P.S. I'm sending this message from this address because it bounced when I = tried to send it from my regular e-mail address. Please continue interacti= ng with me at my regular e-mail address Michael.Jones@microsoft.com.From: A= xel.Nennker@telekom.de To: James.H.Manger@team.telstra.com Date: Fri=2C 19 Oct 2012 11:46:52 +0200 CC: jose@ietf.org Subject: Re: [jose] xpo Structure means =93more bytes=94. I guess that was the reason to go for xpo= . (I cannot find the arguments on the mailing list) I changed my mind: Alth= ough I don=92t like xpo I think that instead of going back we should now li= ve with xpo. Changing any implementation to understand xpo is not that much= work.And it is better to minimize breaking changes. Axel From: Manger=2C J= ames H [mailto:James.H.Manger@team.telstra.com]=20 Sent: Friday=2C October 19=2C 2012 9:18 AM To: Nennker=2C Axel=3B jose@ietf.org Cc: bcampbell@pingidentity.com=3B sakimura@gmail.com=3B vladimir@nimbusds.c= om Subject: RE: [jose] xpo =93exp=94 wouldn=92t clash if we used some JSON str= ucture in a JWK. For instance=2C separate the maths fields of the public ke= y (n=2C e=2C =85) from the administrative parts (key-id=2C certificate=2C u= sage=85). Instead=2C JWK goes for a flat bucket for all a key=92s info. Hen= ce=2C we have potential problems with clashes of names from quite separate = domains. We should fix the structure=2C instead of tinkering with the name.= --James Manger From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Axel.Nennker@telekom.de Sent: Friday=2C 19 October 2012 5:50 PM To: jose@ietf.org Cc: bcampbell@pingidentity.com=3B sakimura@gmail.com=3B vladimir@nimbusds.c= om Subject: Re: [jose] xpo I don=92t know why the exp in jwk needs to be chang= ed. From a developer POW there is no need. You always know which =93exp=94 = is the right one.I would reverse the change from exp to xpo. Developers don= =92t need it and many did not update their implementation to incorporate th= e exp->xpo transition. Actually I don=92t care (much) how the parameters ar= e named. Although I would like to stick to the 3-letter scheme I am OK with= the n=2Ce proposal.But please stop making breaking changes (especially ren= aming parameters which leads only to more work and no gain). Case1: harm is= already done -> stick with xpo and don=92t change AGAIN.Case2: Most implem= entation haven=92t changed yet -> revert to expCase3: xpo is just stupid ->= n=2Ce is better -> another change -> Oh no -> revert to exp Again: I sugge= st to revert to exp and make the implementers happy. Axel Cc=92ing Nat beca= use I don=92t want to give away his developer=92s emails without asking. F= rom: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bria= n Campbell Sent: Wednesday=2C October 17=2C 2012 3:09 PM To: Vladimir Dzhuvinov / NimbusDS Cc: jose@ietf.org Subject: Re: [jose] xpo +1 (if a parameter name change is going to happen a= nyway)On Wed=2C Oct 17=2C 2012 at 2:24 AM=2C Vladimir Dzhuvinov / NimbusDS = wrote:+1 -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com -------- Original Message -------- Subject: Re: [jose] xpo From: Richard Barnes Date: Wed=2C October 17=2C 2012 12:15 am To: "Manger=2C James H" Cc: Mike Jones =2C "jose@ietf.org" +1 On Oct 16=2C 2012=2C at 6:55 PM=2C Manger=2C James H wrote: >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >> =95 Changed the name of the JWK RSA exponent parameter from exp to xpo s= o as to allow the potential use of the name exp for a future extension that= might define an expiration parameter for keys. (The exp name is already us= ed for this purpose in the JWT specification.) > > "n" and "e" would be better than "mod" and "xpo". > "n" and "e" are very widely used for the RSA modulus and public exponent. > > s^e =3D m mod n > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose = --_44306239-aabd-4fcb-943f-f51dd98a1c99_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
It seems the choice is between (mod=2C xpo) and (n=2C e). =3B A number = of people have already expressed a preference for the latter. =3B What = do others think?
 =3B
-- Mike

P.S. =3B I'm sending thi= s message from this address because it bounced when I tried to send it from= my regular e-mail address. =3B Please continue interacting with me at = my regular e-mail address Mi= chael.Jones@microsoft.com.
From: Axel.Nennker@telekom.de
To: James.H.Mang= er@team.telstra.com
Date: Fri=2C 19 Oct 2012 11:46:52 +0200
CC: jose@= ietf.org
Subject: Re: [jose] xpo

Structure means =93more bytes=94. I guess that was= the reason to go for xpo. (I cannot find the arguments on the mailing list= )

 = =3B

I = changed my mind: Although I don=92t like xpo I think that instead of going = back we should now live with xpo. Changing any implementation to understand= xpo is not that much work.

And it is better to minimize breaking changes.<= /p>

 =3B

Axel

 =3B

From: Manger=2C James H [mailto:James.H.Manger@team.telstra.com]
S= ent: Friday=2C October 19=2C 2012 9:18 AM
To: Nennker=2C Axel= =3B jose@ietf.org
Cc: bcampbell@pingidentity.com=3B sakimura@gmai= l.com=3B vladimir@nimbusds.com
Subject: RE: [jose] xpo

=

 =3B

=93exp=94 wouldn=92t clash = if we used some JSON structure in a JWK. For instance=2C separate the maths= fields of the public key (n=2C e=2C =85) from the administrative parts (ke= y-id=2C certificate=2C usage=85). Instead=2C JWK goes for a flat bucket for= all a key=92s info. Hence=2C we have potential problems with clashes of na= mes from quite separate domains. We should fix the structure=2C instead of = tinkering with the name.

 =3B

--

James Man= ger

 =3B

=

From:<= span style=3D'font-family: "Tahoma"=2C"sans-serif"=3B font-size: 10pt=3B'> = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ax= el.Nennker@telekom.de
Sent: Friday=2C 19 October 2012 5:50 PM
= To: jose@ietf.org
Cc: bcampbell@pingidentity.com=3B sakimu= ra@gmail.com=3B vladimir@nimbusds.com
Subject: Re: [jose] xpo

 =3B<= /span>

I don= =92t know why the exp in jwk needs to be changed. From a developer POW ther= e is no need. You always know which =93exp=94 is the right one.

<= p class=3D"ecxMsoNormal">I would reverse th= e change from exp to xpo. Developers don=92t need it and many did not updat= e their implementation to incorporate the exp->=3Bxpo transition.<= /p>

 =3B

Actually I= don=92t care (much) how the parameters are named. Although I would like to= stick to the 3-letter scheme I am OK with the n=2Ce proposal.

But please stop mak= ing breaking changes (especially renaming parameters which leads only to mo= re work and no gain).

 =3B

Case1: harm is already done ->=3B stick with xpo and don= =92t change AGAIN.

Case2: Most implementation haven=92t changed yet ->=3B revert= to exp

Case3: xpo is just stupid ->=3B n=2Ce is better ->=3B another change -= >=3B Oh no ->=3B revert to exp

 =3B

Again: I suggest to revert to exp and make th= e implementers happy.

 =3B

Axel

 =3B

Cc=92ing Nat because I don=92t want to give away his devel= oper=92s emails without asking.

 =3B

 =3B

= = From: jose-bounces@ietf= .org [mailto:jose-bounces@ietf= .org] On Behalf Of Brian Campbell
Sent: Wednesday=2C O= ctober 17=2C 2012 3:09 PM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject:<= /b> Re: [jose] xpo

 =3B

+1 (if a parameter name = change is going to happen anyway)

On Wed= =2C Oct 17=2C 2012 at 2:24 AM=2C Vladimir Dzhuvinov / NimbusDS <=3Bvladimir@nimbusds.com>=3B wrote:

+1

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



-------- Original Message --------
Subje= ct: Re: [jose] xpo
From: Richard Barnes <=3Brbarnes@bbn.com>=3B
Date: Wed=2C October 17=2C 2012 12:15= am
To: "Manger=2C James H" <=3BJames.H.Manger@team.telstra.com>=3B
Cc: Mike Jones &l= t=3BMichael.Jones@microsoft.= com>=3B=2C "jose@ietf.org"
&l= t=3Bjose@ietf.org>=3B


+1<= br>
On Oct 16=2C 2012=2C at 6:55 PM=2C Manger=2C James H wrote:

&= gt=3B>=3B http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-key-06
>=3B>=3B =95 Changed the name of the JWK RSA exponent = parameter from exp to xpo so as to allow the potential use of the name exp = for a future extension that might define an expiration parameter for keys. = (The exp name is already used for this purpose in the JWT specification.)>=3B
>=3B "n" and "e" would be better than "mod" and "xpo".
>= =3B "n" and "e" are very widely used for the RSA modulus and public exponen= t.
>=3B
>=3B s^e =3D m mod n
>=3B
>=3B --
>=3B Jam= es Manger
>=3B _______________________________________________
>= =3B jose mailing list
>=3B jose@ietf.= org
>=3B https://www.ietf.org/mailman/listinfo/jose

_____= __________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/l= istinfo/jose
_______________________________________________
jose= mailing list
jose@ietf.org
https:= //www.ietf.org/mailman/listinfo/jose

 =3B


__________________________________= _____________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
= --_44306239-aabd-4fcb-943f-f51dd98a1c99_-- From rbarnes@bbn.com Mon Oct 22 13:40: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 43A5421F8569 for ; Mon, 22 Oct 2012 13:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.592 X-Spam-Level: X-Spam-Status: No, score=-107.592 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkEM-jP1BozQ for ; Mon, 22 Oct 2012 13:40:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABB421F8530 for ; Mon, 22 Oct 2012 13:40:26 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:58362) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TQOnQ-000MMR-4f; Mon, 22 Oct 2012 16:40:24 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Richard Barnes In-Reply-To: Date: Mon, 22 Oct 2012 16:40:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3EA6E4F1-0E55-4975-9E0A-831CD6B69B25@bbn.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net>, , , <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com>, To: Michael Jones X-Mailer: Apple Mail (2.1283) Cc: Mike Jones , jose@ietf.org Subject: Re: [jose] xpo 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, 22 Oct 2012 20:40:27 -0000 +1 for (n,e), with scoping to avoid conflict with other uses of those = letters. On Oct 22, 2012, at 4:23 PM, Michael Jones wrote: > It seems the choice is between (mod, xpo) and (n, e). A number of = people have already expressed a preference for the latter. What do = others think? > =20 > -- Mike >=20 > P.S. I'm sending this message from this address because it bounced = when I tried to send it from my regular e-mail address. Please continue = interacting with me at my regular e-mail = addressMichael.Jones@microsoft.com. > From: Axel.Nennker@telekom.de > To: James.H.Manger@team.telstra.com > Date: Fri, 19 Oct 2012 11:46:52 +0200 > CC: jose@ietf.org > Subject: Re: [jose] xpo >=20 > Structure means =93more bytes=94. I guess that was the reason to go = for xpo. (I cannot find the arguments on the mailing list) > =20 > I changed my mind: Although I don=92t like xpo I think that instead of = going back we should now live with xpo. Changing any implementation to = understand xpo is not that much work. > And it is better to minimize breaking changes. > =20 > Axel > =20 > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 > Sent: Friday, October 19, 2012 9:18 AM > To: Nennker, Axel; jose@ietf.org > Cc: bcampbell@pingidentity.com; sakimura@gmail.com; = vladimir@nimbusds.com > Subject: RE: [jose] xpo > =20 > =93exp=94 wouldn=92t clash if we used some JSON structure in a JWK. = For instance, separate the maths fields of the public key (n, e, =85) = from the administrative parts (key-id, certificate, usage=85). Instead, = JWK goes for a flat bucket for all a key=92s info. Hence, we have = potential problems with clashes of names from quite separate domains. We = should fix the structure, instead of tinkering with the name. > =20 > -- > James Manger > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Axel.Nennker@telekom.de > Sent: Friday, 19 October 2012 5:50 PM > To: jose@ietf.org > Cc: bcampbell@pingidentity.com; sakimura@gmail.com; = vladimir@nimbusds.com > Subject: Re: [jose] xpo > =20 > I don=92t know why the exp in jwk needs to be changed. =46rom a = developer POW there is no need. You always know which =93exp=94 is the = right one. > I would reverse the change from exp to xpo. Developers don=92t need it = and many did not update their implementation to incorporate the exp->xpo = transition. > =20 > Actually I don=92t care (much) how the parameters are named. Although = I would like to stick to the 3-letter scheme I am OK with the n,e = proposal. > But please stop making breaking changes (especially renaming = parameters which leads only to more work and no gain). > =20 > Case1: harm is already done -> stick with xpo and don=92t change = AGAIN. > Case2: Most implementation haven=92t changed yet -> revert to exp > Case3: xpo is just stupid -> n,e is better -> another change -> Oh no = -> revert to exp > =20 > Again: I suggest to revert to exp and make the implementers happy. > =20 > Axel > =20 > Cc=92ing Nat because I don=92t want to give away his developer=92s = emails without asking. > =20 > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Brian Campbell > Sent: Wednesday, October 17, 2012 3:09 PM > To: Vladimir Dzhuvinov / NimbusDS > Cc: jose@ietf.org > Subject: Re: [jose] xpo > =20 > +1 (if a parameter name change is going to happen anyway) >=20 > On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS = wrote: > +1 >=20 > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >=20 >=20 > -------- Original Message -------- > Subject: Re: [jose] xpo > From: Richard Barnes > Date: Wed, October 17, 2012 12:15 am > To: "Manger, James H" > Cc: Mike Jones , "jose@ietf.org" > >=20 >=20 > +1 >=20 > On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >=20 > >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 > >> =95 Changed the name of the JWK RSA exponent parameter from exp to = xpo so as to allow the potential use of the name exp for a future = extension that might define an expiration parameter for keys. (The exp = name is already used for this purpose in the JWT specification.) > > > > "n" and "e" would be better than "mod" and "xpo". > > "n" and "e" are very widely used for the RSA modulus and public = exponent. > > > > s^e =3D m mod n > > > > -- > > James Manger > > _______________________________________________ > > 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 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 >=20 > _______________________________________________ jose mailing list = jose@ietf.org https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Oct 22 13:49: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 2E5731F041C for ; Mon, 22 Oct 2012 13:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.069 X-Spam-Level: X-Spam-Status: No, score=-4.069 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN8lczQFC9xG for ; Mon, 22 Oct 2012 13:49:26 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 76CA81F042B for ; Mon, 22 Oct 2012 13:49:24 -0700 (PDT) Received: from BL2FFO11FD002.protection.gbl (10.173.161.204) by BL2FFO11HUB001.protection.gbl (10.173.161.19) with Microsoft SMTP Server (TLS) id 15.0.545.8; Sun, 21 Oct 2012 04:58:31 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD002.mail.protection.outlook.com (10.173.160.102) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Sun, 21 Oct 2012 04:58:31 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Sun, 21 Oct 2012 04:57:27 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: [jose] xpo Thread-Index: AQHNrEDfucS89Z7uH0uzJAfKNczTGZe9eJOAgAK6vgCAAAgHAIAAKXsAgALTmnA= Date: Sun, 21 Oct 2012 04:57:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436687298E@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.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.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436687298ETK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(24454001)(13464001)(51444002)(512874001)(31966008)(42186003)(51856001)(15202345001)(47446002)(8716001)(1076001)(33656001)(44976002)(5343655001)(20776001)(46102001)(53806001)(3846001)(2666001)(5343635001)(74662001)(47976001)(16406001)(50986001)(47736001)(16826001)(16696001)(4196001)(74502001)(4396001)(49866001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0641678E68 Subject: Re: [jose] xpo 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, 22 Oct 2012 20:49:28 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436687298ETK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdGhlIGNob2ljZSBpcyBiZXR3ZWVuIChtb2QsIHhwbykgYW5kIChuLCBlKS4gIEEg bnVtYmVyIG9mIHBlb3BsZSBoYXZlIGFscmVhZHkgZXhwcmVzc2VkIGEgcHJlZmVyZW5jZSBmb3Ig dGhlIGxhdHRlci4gIFdoYXQgZG8gb3RoZXJzIHRoaW5rPw0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEF4ZWwuTmVubmtlckB0ZWxla29tLmRlDQpTZW50OiBGcmlkYXksIE9jdG9iZXIg MTksIDIwMTIgMjo0NyBBTQ0KVG86IEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20NCkNj OiBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2pvc2VdIHhwbw0KDQpTdHJ1Y3R1cmUgbWVh bnMg4oCcbW9yZSBieXRlc+KAnS4gSSBndWVzcyB0aGF0IHdhcyB0aGUgcmVhc29uIHRvIGdvIGZv ciB4cG8uIChJIGNhbm5vdCBmaW5kIHRoZSBhcmd1bWVudHMgb24gdGhlIG1haWxpbmcgbGlzdCkN Cg0KSSBjaGFuZ2VkIG15IG1pbmQ6IEFsdGhvdWdoIEkgZG9u4oCZdCBsaWtlIHhwbyBJIHRoaW5r IHRoYXQgaW5zdGVhZCBvZiBnb2luZyBiYWNrIHdlIHNob3VsZCBub3cgbGl2ZSB3aXRoIHhwby4g Q2hhbmdpbmcgYW55IGltcGxlbWVudGF0aW9uIHRvIHVuZGVyc3RhbmQgeHBvIGlzIG5vdCB0aGF0 IG11Y2ggd29yay4NCkFuZCBpdCBpcyBiZXR0ZXIgdG8gbWluaW1pemUgYnJlYWtpbmcgY2hhbmdl cy4NCg0KQXhlbA0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tXQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDE5LCAyMDEyIDk6MTgg QU0NClRvOiBOZW5ua2VyLCBBeGVsOyBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3Jn Pg0KQ2M6IGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbT47IHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29t PjsgdmxhZGltaXJAbmltYnVzZHMuY29tPG1haWx0bzp2bGFkaW1pckBuaW1idXNkcy5jb20+DQpT dWJqZWN0OiBSRTogW2pvc2VdIHhwbw0KDQrigJxleHDigJ0gd291bGRu4oCZdCBjbGFzaCBpZiB3 ZSB1c2VkIHNvbWUgSlNPTiBzdHJ1Y3R1cmUgaW4gYSBKV0suIEZvciBpbnN0YW5jZSwgc2VwYXJh dGUgdGhlIG1hdGhzIGZpZWxkcyBvZiB0aGUgcHVibGljIGtleSAobiwgZSwg4oCmKSBmcm9tIHRo ZSBhZG1pbmlzdHJhdGl2ZSBwYXJ0cyAoa2V5LWlkLCBjZXJ0aWZpY2F0ZSwgdXNhZ2XigKYpLiBJ bnN0ZWFkLCBKV0sgZ29lcyBmb3IgYSBmbGF0IGJ1Y2tldCBmb3IgYWxsIGEga2V54oCZcyBpbmZv LiBIZW5jZSwgd2UgaGF2ZSBwb3RlbnRpYWwgcHJvYmxlbXMgd2l0aCBjbGFzaGVzIG9mIG5hbWVz IGZyb20gcXVpdGUgc2VwYXJhdGUgZG9tYWlucy4gV2Ugc2hvdWxkIGZpeCB0aGUgc3RydWN0dXJl LCBpbnN0ZWFkIG9mIHRpbmtlcmluZyB3aXRoIHRoZSBuYW1lLg0KDQotLQ0KSmFtZXMgTWFuZ2Vy DQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYu b3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEF4ZWwuTmVu bmtlckB0ZWxla29tLmRlPG1haWx0bzpBeGVsLk5lbm5rZXJAdGVsZWtvbS5kZT4NClNlbnQ6IEZy aWRheSwgMTkgT2N0b2JlciAyMDEyIDU6NTAgUE0NClRvOiBqb3NlQGlldGYub3JnPG1haWx0bzpq b3NlQGlldGYub3JnPg0KQ2M6IGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11 cmFAZ21haWwuY29tPjsgdmxhZGltaXJAbmltYnVzZHMuY29tPG1haWx0bzp2bGFkaW1pckBuaW1i dXNkcy5jb20+DQpTdWJqZWN0OiBSZTogW2pvc2VdIHhwbw0KDQpJIGRvbuKAmXQga25vdyB3aHkg dGhlIGV4cCBpbiBqd2sgbmVlZHMgdG8gYmUgY2hhbmdlZC4gRnJvbSBhIGRldmVsb3BlciBQT1cg dGhlcmUgaXMgbm8gbmVlZC4gWW91IGFsd2F5cyBrbm93IHdoaWNoIOKAnGV4cOKAnSBpcyB0aGUg cmlnaHQgb25lLg0KSSB3b3VsZCByZXZlcnNlIHRoZSBjaGFuZ2UgZnJvbSBleHAgdG8geHBvLiBE ZXZlbG9wZXJzIGRvbuKAmXQgbmVlZCBpdCBhbmQgbWFueSBkaWQgbm90IHVwZGF0ZSB0aGVpciBp bXBsZW1lbnRhdGlvbiB0byBpbmNvcnBvcmF0ZSB0aGUgZXhwLT54cG8gdHJhbnNpdGlvbi4NCg0K QWN0dWFsbHkgSSBkb27igJl0IGNhcmUgKG11Y2gpIGhvdyB0aGUgcGFyYW1ldGVycyBhcmUgbmFt ZWQuIEFsdGhvdWdoIEkgd291bGQgbGlrZSB0byBzdGljayB0byB0aGUgMy1sZXR0ZXIgc2NoZW1l IEkgYW0gT0sgd2l0aCB0aGUgbixlIHByb3Bvc2FsLg0KQnV0IHBsZWFzZSBzdG9wIG1ha2luZyBi cmVha2luZyBjaGFuZ2VzIChlc3BlY2lhbGx5IHJlbmFtaW5nIHBhcmFtZXRlcnMgd2hpY2ggbGVh ZHMgb25seSB0byBtb3JlIHdvcmsgYW5kIG5vIGdhaW4pLg0KDQpDYXNlMTogaGFybSBpcyBhbHJl YWR5IGRvbmUgLT4gc3RpY2sgd2l0aCB4cG8gYW5kIGRvbuKAmXQgY2hhbmdlIEFHQUlOLg0KQ2Fz ZTI6IE1vc3QgaW1wbGVtZW50YXRpb24gaGF2ZW7igJl0IGNoYW5nZWQgeWV0IC0+IHJldmVydCB0 byBleHANCkNhc2UzOiB4cG8gaXMganVzdCBzdHVwaWQgLT4gbixlIGlzIGJldHRlciAtPiBhbm90 aGVyIGNoYW5nZSAtPiBPaCBubyAtPiByZXZlcnQgdG8gZXhwDQoNCkFnYWluOiBJIHN1Z2dlc3Qg dG8gcmV2ZXJ0IHRvIGV4cCBhbmQgbWFrZSB0aGUgaW1wbGVtZW50ZXJzIGhhcHB5Lg0KDQpBeGVs DQoNCkNj4oCZaW5nIE5hdCBiZWNhdXNlIEkgZG9u4oCZdCB3YW50IHRvIGdpdmUgYXdheSBoaXMg ZGV2ZWxvcGVy4oCZcyBlbWFpbHMgd2l0aG91dCBhc2tpbmcuDQoNCg0KRnJvbTogam9zZS1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86am9zZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFdlZG5l c2RheSwgT2N0b2JlciAxNywgMjAxMiAzOjA5IFBNDQpUbzogVmxhZGltaXIgRHpodXZpbm92IC8g TmltYnVzRFMNCkNjOiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtqb3NlXSB4cG8NCg0KKzEgKGlmIGEgcGFyYW1ldGVyIG5hbWUgY2hhbmdlIGlzIGdv aW5nIHRvIGhhcHBlbiBhbnl3YXkpDQpPbiBXZWQsIE9jdCAxNywgMjAxMiBhdCAyOjI0IEFNLCBW bGFkaW1pciBEemh1dmlub3YgLyBOaW1idXNEUyA8dmxhZGltaXJAbmltYnVzZHMuY29tPG1haWx0 bzp2bGFkaW1pckBuaW1idXNkcy5jb20+PiB3cm90ZToNCisxDQoNCi0tDQpWbGFkaW1pciBEemh1 dmlub3YgOiB3d3cuTmltYnVzRFMuY29tPGh0dHA6Ly93d3cuTmltYnVzRFMuY29tPiA6IHZsYWRp bWlyQG5pbWJ1c2RzLmNvbTxtYWlsdG86dmxhZGltaXJAbmltYnVzZHMuY29tPg0KDQoNCi0tLS0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IFJlOiBbam9zZV0geHBvDQpG cm9tOiBSaWNoYXJkIEJhcm5lcyA8cmJhcm5lc0BiYm4uY29tPG1haWx0bzpyYmFybmVzQGJibi5j b20+Pg0KRGF0ZTogV2VkLCBPY3RvYmVyIDE3LCAyMDEyIDEyOjE1IGFtDQpUbzogIk1hbmdlciwg SmFtZXMgSCIgPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkphbWVzLkgu TWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4sICJqb3Nl QGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPiINCjxqb3NlQGlldGYub3JnPG1haWx0bzpq b3NlQGlldGYub3JnPj4NCg0KDQorMQ0KDQpPbiBPY3QgMTYsIDIwMTIsIGF0IDY6NTUgUE0sIE1h bmdlciwgSmFtZXMgSCB3cm90ZToNCg0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNg0KPj4g4oCiIENoYW5nZWQgdGhlIG5hbWUgb2Yg dGhlIEpXSyBSU0EgZXhwb25lbnQgcGFyYW1ldGVyIGZyb20gZXhwIHRvIHhwbyBzbyBhcyB0byBh bGxvdyB0aGUgcG90ZW50aWFsIHVzZSBvZiB0aGUgbmFtZSBleHAgZm9yIGEgZnV0dXJlIGV4dGVu c2lvbiB0aGF0IG1pZ2h0IGRlZmluZSBhbiBleHBpcmF0aW9uIHBhcmFtZXRlciBmb3Iga2V5cy4g KFRoZSBleHAgbmFtZSBpcyBhbHJlYWR5IHVzZWQgZm9yIHRoaXMgcHVycG9zZSBpbiB0aGUgSldU IHNwZWNpZmljYXRpb24uKQ0KPg0KPiAibiIgYW5kICJlIiB3b3VsZCBiZSBiZXR0ZXIgdGhhbiAi bW9kIiBhbmQgInhwbyIuDQo+ICJuIiBhbmQgImUiIGFyZSB2ZXJ5IHdpZGVseSB1c2VkIGZvciB0 aGUgUlNBIG1vZHVsdXMgYW5kIHB1YmxpYyBleHBvbmVudC4NCj4NCj4gc15lID0gbSBtb2Qgbg0K Pg0KPiAtLQ0KPiBKYW1lcyBNYW5nZXINCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gam9zZSBtYWlsaW5nIGxpc3QNCj4gam9zZUBpZXRmLm9yZzxt YWlsdG86am9zZUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9qb3NlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0 DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739436687298ETK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA1Ni43cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgc2VlbXMgdGhl IGNob2ljZSBpcyBiZXR3ZWVuIChtb2QsIHhwbykgYW5kIChuLCBlKS4mbmJzcDsgQSBudW1iZXIg b2YgcGVvcGxlIGhhdmUgYWxyZWFkeSBleHByZXNzZWQgYSBwcmVmZXJlbmNlIGZvciB0aGUgbGF0 dGVyLiZuYnNwOyBXaGF0IGRvIG90aGVycyB0aGluaz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 am9zZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BeGVsLk5lbm5rZXJA dGVsZWtvbS5kZTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMTksIDIwMTIgMjo0 NyBBTTxicj4NCjxiPlRvOjwvYj4gSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxicj4N CjxiPkNjOjwvYj4gam9zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2Vd IHhwbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdHJ1Y3R1cmUgbWVhbnMg4oCc bW9yZSBieXRlc+KAnS4gSSBndWVzcyB0aGF0IHdhcyB0aGUgcmVhc29uIHRvIGdvIGZvciB4cG8u IChJIGNhbm5vdCBmaW5kIHRoZSBhcmd1bWVudHMgb24gdGhlIG1haWxpbmcgbGlzdCk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgY2hhbmdlZCBteSBtaW5kOiBBbHRob3VnaCBJIGRvbuKAmXQgbGlrZSB4cG8gSSB0aGlu ayB0aGF0IGluc3RlYWQgb2YgZ29pbmcgYmFjayB3ZSBzaG91bGQgbm93IGxpdmUgd2l0aCB4cG8u IENoYW5naW5nIGFueSBpbXBsZW1lbnRhdGlvbiB0byB1bmRlcnN0YW5kIHhwbyBpcw0KIG5vdCB0 aGF0IG11Y2ggd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGl0IGlzIGJl dHRlciB0byBtaW5pbWl6ZSBicmVha2luZyBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXhlbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IE1hbmdlciwgSmFtZXMgSCBbPGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFu Z2VyQHRlYW0udGVsc3RyYS5jb20iPm1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEu Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMTksIDIwMTIgOTox OCBBTTxicj4NCjxiPlRvOjwvYj4gTmVubmtlciwgQXhlbDsgPGEgaHJlZj0ibWFpbHRvOmpvc2VA aWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWls LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzp2bGFkaW1pckBuaW1idXNkcy5jb20iPg0KdmxhZGlt aXJAbmltYnVzZHMuY29tPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2pvc2VdIHhwbzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcZXhw4oCdIHdv dWxkbuKAmXQgY2xhc2ggaWYgd2UgdXNlZCBzb21lIEpTT04gc3RydWN0dXJlIGluIGEgSldLLiBG b3IgaW5zdGFuY2UsIHNlcGFyYXRlIHRoZSBtYXRocyBmaWVsZHMgb2YgdGhlIHB1YmxpYyBrZXkg KG4sIGUsIOKApikgZnJvbSB0aGUgYWRtaW5pc3RyYXRpdmUNCiBwYXJ0cyAoa2V5LWlkLCBjZXJ0 aWZpY2F0ZSwgdXNhZ2XigKYpLiBJbnN0ZWFkLCBKV0sgZ29lcyBmb3IgYSBmbGF0IGJ1Y2tldCBm b3IgYWxsIGEga2V54oCZcyBpbmZvLiBIZW5jZSwgd2UgaGF2ZSBwb3RlbnRpYWwgcHJvYmxlbXMg d2l0aCBjbGFzaGVzIG9mIG5hbWVzIGZyb20gcXVpdGUgc2VwYXJhdGUgZG9tYWlucy4gV2Ugc2hv dWxkIGZpeCB0aGUgc3RydWN0dXJlLCBpbnN0ZWFkIG9mIHRpbmtlcmluZyB3aXRoIHRoZSBuYW1l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t QVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0K PGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYu b3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmpv c2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1h aWx0bzpBeGVsLk5lbm5rZXJAdGVsZWtvbS5kZSI+QXhlbC5OZW5ua2VyQHRlbGVrb20uZGU8L2E+ PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgMTkgT2N0b2JlciAyMDEyIDU6NTAgUE08YnI+DQo8 Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9h Pjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2Fr aW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86 dmxhZGltaXJAbmltYnVzZHMuY29tIj4NCnZsYWRpbWlyQG5pbWJ1c2RzLmNvbTwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3NlXSB4cG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQga25vdyB3aHkgdGhlIGV4 cCBpbiBqd2sgbmVlZHMgdG8gYmUgY2hhbmdlZC4gRnJvbSBhIGRldmVsb3BlciBQT1cgdGhlcmUg aXMgbm8gbmVlZC4gWW91IGFsd2F5cyBrbm93IHdoaWNoIOKAnGV4cOKAnSBpcyB0aGUgcmlnaHQg b25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIHJldmVyc2UgdGhlIGNo YW5nZSBmcm9tIGV4cCB0byB4cG8uIERldmVsb3BlcnMgZG9u4oCZdCBuZWVkIGl0IGFuZCBtYW55 IGRpZCBub3QgdXBkYXRlIHRoZWlyIGltcGxlbWVudGF0aW9uIHRvIGluY29ycG9yYXRlIHRoZSBl eHAtJmd0O3hwbyB0cmFuc2l0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWN0dWFsbHkgSSBkb27igJl0IGNhcmUg KG11Y2gpIGhvdyB0aGUgcGFyYW1ldGVycyBhcmUgbmFtZWQuIEFsdGhvdWdoIEkgd291bGQgbGlr ZSB0byBzdGljayB0byB0aGUgMy1sZXR0ZXIgc2NoZW1lIEkgYW0gT0sgd2l0aCB0aGUgbixlIHBy b3Bvc2FsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgcGxlYXNlIHN0b3AgbWFr aW5nIGJyZWFraW5nIGNoYW5nZXMgKGVzcGVjaWFsbHkgcmVuYW1pbmcgcGFyYW1ldGVycyB3aGlj aCBsZWFkcyBvbmx5IHRvIG1vcmUgd29yayBhbmQgbm8gZ2FpbikuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DYXNlMTog aGFybSBpcyBhbHJlYWR5IGRvbmUgLSZndDsgc3RpY2sgd2l0aCB4cG8gYW5kIGRvbuKAmXQgY2hh bmdlIEFHQUlOLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DYXNlMjogTW9zdCBpbXBs ZW1lbnRhdGlvbiBoYXZlbuKAmXQgY2hhbmdlZCB5ZXQgLSZndDsgcmV2ZXJ0IHRvIGV4cDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DYXNlMzogeHBvIGlzIGp1c3Qgc3R1cGlkIC0mZ3Q7 IG4sZSBpcyBiZXR0ZXIgLSZndDsgYW5vdGhlciBjaGFuZ2UgLSZndDsgT2ggbm8gLSZndDsgcmV2 ZXJ0IHRvIGV4cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdhaW46IEkgc3VnZ2VzdCB0byByZXZlcnQgdG8gZXhwIGFu ZCBtYWtlIHRoZSBpbXBsZW1lbnRlcnMgaGFwcHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BeGVsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5D Y+KAmWluZyBOYXQgYmVjYXVzZSBJIGRvbuKAmXQgd2FudCB0byBnaXZlIGF3YXkgaGlzIGRldmVs b3BlcuKAmXMgZW1haWxzIHdpdGhvdXQgYXNraW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8 YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5v cmc8L2E+IFs8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86am9z ZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJl bGw8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDE3LCAyMDEyIDM6MDkgUE08 YnI+DQo8Yj5Ubzo8L2I+IFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTPGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3NlXSB4cG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+JiM0MzsxIChpZiBhIHBhcmFtZXRl ciBuYW1lIGNoYW5nZSBpcyBnb2luZyB0byBoYXBwZW4gYW55d2F5KTxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDE3LCAyMDEyIGF0IDI6MjQg QU0sIFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTICZsdDs8YSBocmVmPSJtYWlsdG86dmxh ZGltaXJAbmltYnVzZHMuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmxhZGltaXJAbmltYnVzZHMuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz OzE8YnI+DQo8YnI+DQotLTxicj4NClZsYWRpbWlyIER6aHV2aW5vdiA6IDxhIGhyZWY9Imh0dHA6 Ly93d3cuTmltYnVzRFMuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3Lk5pbWJ1c0RTLmNvbTwvYT4g Og0KPGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQG5pbWJ1c2RzLmNvbSI+dmxhZGltaXJAbmltYnVz ZHMuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPg0K U3ViamVjdDogUmU6IFtqb3NlXSB4cG88YnI+DQpGcm9tOiBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJiYXJuZXNAYmJuLmNvbSI+cmJhcm5lc0BiYm4uY29tPC9hPiZndDs8YnI+ DQpEYXRlOiBXZWQsIE9jdG9iZXIgMTcsIDIwMTIgMTI6MTUgYW08YnI+DQpUbzogJnF1b3Q7TWFu Z2VyLCBKYW1lcyBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbSI+SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTwvYT4mZ3Q7PGJy Pg0KQ2M6IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBo cmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT4mcXVvdDs8YnI+DQom bHQ7PGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxicj4NCjxicj4NCiYjNDM7MTxicj4NCjxicj4NCk9uIE9jdCAxNiwgMjAxMiwgYXQgNjo1 NSBQTSwgTWFuZ2VyLCBKYW1lcyBIIHdyb3RlOjxicj4NCjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXkt MDYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1rZXktMDY8L2E+PGJyPg0KJmd0OyZndDsg4oCiIENoYW5nZWQgdGhl IG5hbWUgb2YgdGhlIEpXSyBSU0EgZXhwb25lbnQgcGFyYW1ldGVyIGZyb20gZXhwIHRvIHhwbyBz byBhcyB0byBhbGxvdyB0aGUgcG90ZW50aWFsIHVzZSBvZiB0aGUgbmFtZSBleHAgZm9yIGEgZnV0 dXJlIGV4dGVuc2lvbiB0aGF0IG1pZ2h0IGRlZmluZSBhbiBleHBpcmF0aW9uIHBhcmFtZXRlciBm b3Iga2V5cy4gKFRoZSBleHAgbmFtZSBpcyBhbHJlYWR5IHVzZWQgZm9yIHRoaXMgcHVycG9zZSBp biB0aGUgSldUIHNwZWNpZmljYXRpb24uKTxicj4NCiZndDs8YnI+DQomZ3Q7ICZxdW90O24mcXVv dDsgYW5kICZxdW90O2UmcXVvdDsgd291bGQgYmUgYmV0dGVyIHRoYW4gJnF1b3Q7bW9kJnF1b3Q7 IGFuZCAmcXVvdDt4cG8mcXVvdDsuPGJyPg0KJmd0OyAmcXVvdDtuJnF1b3Q7IGFuZCAmcXVvdDtl JnF1b3Q7IGFyZSB2ZXJ5IHdpZGVseSB1c2VkIGZvciB0aGUgUlNBIG1vZHVsdXMgYW5kIHB1Ymxp YyBleHBvbmVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBzXmUgPSBtIG1vZCBuPGJyPg0KJmd0Ozxi cj4NCiZndDsgLS08YnI+DQomZ3Q7IEphbWVzIE1hbmdlcjxicj4NCiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGpvc2UgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vam9zZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kam9zZSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739436687298ETK5EX14MBXC285r_-- From rbarnes@bbn.com Mon Oct 22 13:51: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 3A93F21F879B for ; Mon, 22 Oct 2012 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.631 X-Spam-Level: X-Spam-Status: No, score=-107.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3OAnwwyNM9G for ; Mon, 22 Oct 2012 13:51:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A43A21F041C for ; Mon, 22 Oct 2012 13:51:45 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:58395) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TQOyE-000Lt6-9g; Mon, 22 Oct 2012 16:51:34 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Richard Barnes In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 22 Oct 2012 16:51:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6BA7F1B5-5F4D-4626-B18E-9D31E68FCE21@bbn.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1283) Cc: "bcampbell@pingidentity.com" , "sakimura@gmail.com" , "jose@ietf.org" , "Axel.Nennker@telekom.de" , "vladimir@nimbusds.com" Subject: Re: [jose] xpo 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, 22 Oct 2012 20:51:53 -0000 On Oct 19, 2012, at 3:18 AM, Manger, James H wrote: > =93exp=94 wouldn=92t clash if we used some JSON structure in a JWK. = For instance, separate the maths fields of the public key (n, e, =85) = from the administrative parts (key-id, certificate, usage=85). Instead, = JWK goes for a flat bucket for all a key=92s info. Hence, we have = potential problems with clashes of names from quite separate domains. We = should fix the structure, instead of tinkering with the name. Yes. This. =20 Most of this WG's problems arise from using flat buckets. Flat buckets = don't hold water :) --Richard > =20 > -- > James Manger > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Axel.Nennker@telekom.de > Sent: Friday, 19 October 2012 5:50 PM > To: jose@ietf.org > Cc: bcampbell@pingidentity.com; sakimura@gmail.com; = vladimir@nimbusds.com > Subject: Re: [jose] xpo > =20 > I don=92t know why the exp in jwk needs to be changed. =46rom a = developer POW there is no need. You always know which =93exp=94 is the = right one. > I would reverse the change from exp to xpo. Developers don=92t need it = and many did not update their implementation to incorporate the exp->xpo = transition. > =20 > Actually I don=92t care (much) how the parameters are named. Although = I would like to stick to the 3-letter scheme I am OK with the n,e = proposal. > But please stop making breaking changes (especially renaming = parameters which leads only to more work and no gain). > =20 > Case1: harm is already done -> stick with xpo and don=92t change = AGAIN. > Case2: Most implementation haven=92t changed yet -> revert to exp > Case3: xpo is just stupid -> n,e is better -> another change -> Oh no = -> revert to exp > =20 > Again: I suggest to revert to exp and make the implementers happy. > =20 > Axel > =20 > Cc=92ing Nat because I don=92t want to give away his developer=92s = emails without asking. > =20 > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Brian Campbell > Sent: Wednesday, October 17, 2012 3:09 PM > To: Vladimir Dzhuvinov / NimbusDS > Cc: jose@ietf.org > Subject: Re: [jose] xpo > =20 > +1 (if a parameter name change is going to happen anyway) >=20 > On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS = wrote: > +1 >=20 > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >=20 >=20 > -------- Original Message -------- > Subject: Re: [jose] xpo > From: Richard Barnes > Date: Wed, October 17, 2012 12:15 am > To: "Manger, James H" > Cc: Mike Jones , "jose@ietf.org" > >=20 >=20 > +1 >=20 > On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >=20 > >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 > >> =95 Changed the name of the JWK RSA exponent parameter from exp to = xpo so as to allow the potential use of the name exp for a future = extension that might define an expiration parameter for keys. (The exp = name is already used for this purpose in the JWT specification.) > > > > "n" and "e" would be better than "mod" and "xpo". > > "n" and "e" are very widely used for the RSA modulus and public = exponent. > > > > s^e =3D m mod n > > > > -- > > James Manger > > _______________________________________________ > > 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 > _______________________________________________ > 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 Axel.Nennker@telekom.de Mon Oct 22 14:37:06 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 8902521F897F for ; Mon, 22 Oct 2012 14:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo7TL6A2-l1r for ; Mon, 22 Oct 2012 14:36:50 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2D46D21F897C for ; Mon, 22 Oct 2012 14:36:48 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 22 Oct 2012 23:36:47 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Mon, 22 Oct 2012 23:36:46 +0200 From: To: , , Date: Mon, 22 Oct 2012 23:36:45 +0200 Thread-Topic: [jose] xpo Thread-Index: Ac2wkycWqhNt4bVrTt2LvpPY4fmk4wABihzA Message-ID: References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net>, , , <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com>, In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40252192EAE0EHE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] xpo 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, 22 Oct 2012 21:37:06 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF40252192EAE0EHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are talking about two specs here, right? https://tools.ietf.org/html/draft-ietf-jose-json-web-key https://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms There are "general" jwk parameters alg, use, kid, and algorithm specific parameters. x,y,n,e If two parties use a new (or old but non standard) alg with new parameter a= bc and cde then we would break that implementation if we later define abc o= r cde as top level fields. Do we care about this or do we discourage this use case by potentially brea= king them? (breaking is a feature from a security and standards pow?) From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mic= hael Jones Sent: Monday, October 22, 2012 10:23 PM To: jose@ietf.org Subject: Re: [jose] xpo It seems the choice is between (mod, xpo) and (n, e). A number of people h= ave already expressed a preference for the latter. What do others think? -- Mike P.S. I'm sending this message from this address because it bounced when I = tried to send it from my regular e-mail address. Please continue interacti= ng with me at my regular e-mail address Michael.Jones@microsoft.com. ________________________________ From: Axel.Nennker@telekom.de To: James.H.Manger@team.telstra.com Date: Fri, 19 Oct 2012 11:46:52 +0200 CC: jose@ietf.org Subject: Re: [jose] xpo Structure means "more bytes". I guess that was the reason to go for xpo. (I= cannot find the arguments on the mailing list) I changed my mind: Although I don't like xpo I think that instead of going = back we should now live with xpo. Changing any implementation to understand= xpo is not that much work. And it is better to minimize breaking changes. Axel From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Friday, October 19, 2012 9:18 AM To: Nennker, Axel; jose@ietf.org Cc: bcampbell@pingidentity.com; sakimura@gmail.com; vladimir@nimbusds.com Subject: RE: [jose] xpo "exp" wouldn't clash if we used some JSON structure in a JWK. For instance,= separate the maths fields of the public key (n, e, ...) from the administr= ative parts (key-id, certificate, usage...). Instead, JWK goes for a flat b= ucket for all a key's info. Hence, we have potential problems with clashes = of names from quite separate domains. We should fix the structure, instead = of tinkering with the name. -- James Manger From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l.Nennker@telekom.de Sent: Friday, 19 October 2012 5:50 PM To: jose@ietf.org Cc: bcampbell@pingidentity.com; sakimura@gmail.com; vladimir@nimbusds.com Subject: Re: [jose] xpo I don't know why the exp in jwk needs to be changed. From a developer POW t= here is no need. You always know which "exp" is the right one. I would reverse the change from exp to xpo. Developers don't need it and ma= ny did not update their implementation to incorporate the exp->xpo transiti= on. Actually I don't care (much) how the parameters are named. Although I would= like to stick to the 3-letter scheme I am OK with the n,e proposal. But please stop making breaking changes (especially renaming parameters whi= ch leads only to more work and no gain). Case1: harm is already done -> stick with xpo and don't change AGAIN. Case2: Most implementation haven't changed yet -> revert to exp Case3: xpo is just stupid -> n,e is better -> another change -> Oh no -> re= vert to exp Again: I suggest to revert to exp and make the implementers happy. Axel Cc'ing Nat because I don't want to give away his developer's emails without= asking. From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Brian Campbell Sent: Wednesday, October 17, 2012 3:09 PM To: Vladimir Dzhuvinov / NimbusDS Cc: jose@ietf.org Subject: Re: [jose] xpo +1 (if a parameter name change is going to happen anyway) On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS > wrote: +1 -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@n= imbusds.com -------- Original Message -------- Subject: Re: [jose] xpo From: Richard Barnes > Date: Wed, October 17, 2012 12:15 am To: "Manger, James H" > Cc: Mike Jones >, "jose@ietf.org" > +1 On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >> * Changed the name of the JWK RSA exponent parameter from exp to xpo so = as to allow the potential use of the name exp for a future extension that m= ight define an expiration parameter for keys. (The exp name is already used= for this purpose in the JWT specification.) > > "n" and "e" would be better than "mod" and "xpo". > "n" and "e" are very widely used for the RSA modulus and public exponent. > > s^e =3D m mod n > > -- > James Manger > _______________________________________________ > 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 --_000_CE8995AB5D178F44A2154F5C9A97CAF40252192EAE0EHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are ta= lking about two specs here, right?

https://tools.ietf.org/html/draft-ietf-jose-json-web-key<= /span>

https://tools.ietf.org/id/draft-ietf-j= ose-json-web-algorithms

 

There are “= general” jwk parameters

alg, use, kid,

and = algorithm specific parameters.

x,y,n,e

 

If two parties use a new (or old= but non standard) alg with new parameter abc and cde then we would break t= hat implementation if we later define abc or cde as top level fields.<= /o:p>

Do we care about this or do we = discourage this use case by potentially breaking them? (breaking is a featu= re from a security and standards pow?)

 

 

From: jose-bounc= es@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Michael Jone= s
Sent: Monday, October 22, 2012 10:23 PM
To: jose@ietf= .org
Subject: Re: [jose] xpo

 

It seems the choic= e is between (mod, xpo) and (n, e).  A number of people have already e= xpressed a preference for the latter.  What do others think?
 =
-- Mike

P.S.  I'm sending this message from this address be= cause it bounced when I tried to send it from my regular e-mail address.&nb= sp; Please continue interacting with me at my regular e-mail address Michael.Jones@microsoft.com.

From: Axel.Nennker@telek= om.de
To: James.H.Manger@team.telstra.com
Date: Fri, 19 Oct 2012 11:4= 6:52 +0200
CC: jose@ietf.org
Subject: Re: [jose] xpo

Structure means “more bytesR= 21;. I guess that was the reason to go for xpo. (I cannot find the argument= s on the mailing list)

&nbs= p;

I changed my mind: Altho= ugh I don’t like xpo I think that instead of going back we should now= live with xpo. Changing any implementation to understand xpo is not that m= uch work.

And it is better = to minimize breaking changes.

 

Axel

 

From: Manger= , James H [mailto:James.H.Manger@team.telstra.com]
Sent: Friday,= October 19, 2012 9:18 AM
To: Nennker, Axel; jose@ietf.org
= Cc: bcampbell@pingidentity.com; sakimura@gmail.com; vladimir@nimbusds.c= om
Subject: RE: [jose] xpo

 

“exp” wouldn’t clash if we used some JSON structure in = a JWK. For instance, separate the maths fields of the public key (n, e, = 230;) from the administrative parts (key-id, certificate, usage…). In= stead, JWK goes for a flat bucket for all a key’s info. Hence, we hav= e potential problems with clashes of names from quite separate domains. We = should fix the structure, instead of tinkering with the name.

 

=

--

James Manger

<= p class=3DMsoNormal> 

From:= jose-bo= unces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel.Nenn= ker@telekom.de
Sent: Friday, 19 October 2012 5:50 PM
To: jose@ietf.org
Cc: bcampbell@pingidentity.com; sakimura@gmail.co= m; vladimir@nimbusds.com
Subject: Re: [jose] xpo

 

I don’t know why the exp in jwk needs to be ch= anged. From a developer POW there is no need. You always know which “= exp” is the right one.

I would reverse the change from exp to xpo. Developers don’t need i= t and many did not update their implementation to incorporate the exp->x= po transition.

 

Actually I don’t care (muc= h) how the parameters are named. Although I would like to stick to the 3-le= tter scheme I am OK with the n,e proposal.

But please stop making breaking changes (especially renamin= g parameters which leads only to more work and no gain).<= /p>

 

Case1: harm is already done -> stick with xpo and don’t= change AGAIN.

Case2: Most = implementation haven’t changed yet -> revert to exp

Case3: xpo is just stupid -> n,e is be= tter -> another change -> Oh no -> revert to exp<= /p>

 

Again: I suggest to revert to exp and make the implementers happ= y.

 <= /p>

Axel

 

Cc’in= g Nat because I don’t want to give away his developer’s emails = without asking.

 <= /o:p>

 

From: jose-bounces@= ietf.org [mailto:jose-bounces@= ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday,= October 17, 2012 3:09 PM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject:<= /b> Re: [jose] xpo

 

+1 (if a parameter name c= hange is going to happen anyway)

On = Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com> wrote:

+1

--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com<= /p>



-------- Original Message --------
Sub= ject: Re: [jose] xpo
From: Richard Barnes <rbarnes@bbn.com>
Date: Wed, October 17, 2012 12:15 amTo: "Manger, James H" <James.H.Manger@team.telstra.com>
Cc: Mike Jones <= Michael.Jones@microsoft.com<= /a>>, "jose@ietf.org"
= <jose@ietf.org>


+1
On Oct 16, 2012, at 6:55 PM, Manger, James H wrote:

>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06<= br>>> • Changed the name of the JWK RSA exponent parameter from= exp to xpo so as to allow the potential use of the name exp for a future e= xtension that might define an expiration parameter for keys. (The exp name = is already used for this purpose in the JWT specification.)
>
>= "n" and "e" would be better than "mod" and &= quot;xpo".
> "n" and "e" are very widely use= d for the RSA modulus and public exponent.
>
> s^e =3D m mod n<= br>>
> --
> James Manger
> ___________________________= ____________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/= jose

_______________________________________________
jose mai= ling list
jose@ietf.org
https://w= ww.ietf.org/mailman/listinfo/jose
__________________________________= _____________
jose mailing list
jose= @ietf.org
https://www.ietf.org/mailman/listinfo/jose

 


_______________________________________________ jose m= ailing list jose@ietf.org https://www.ietf.org/mailman/lis= tinfo/jose

= --_000_CE8995AB5D178F44A2154F5C9A97CAF40252192EAE0EHE111541eme_-- From Michael.Jones@microsoft.com Tue Oct 23 01:34:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EB421F866E for ; Tue, 23 Oct 2012 01:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUBVQsRxCOjD for ; Tue, 23 Oct 2012 01:34:31 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id C241921F865D for ; Tue, 23 Oct 2012 01:34:30 -0700 (PDT) Received: from BY2FFO11FD006.protection.gbl (10.1.15.202) by BY2FFO11HUB002.protection.gbl (10.1.14.144) with Microsoft SMTP Server (TLS) id 15.0.545.8; Tue, 23 Oct 2012 08:34:17 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Tue, 23 Oct 2012 08:34:16 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Tue, 23 Oct 2012 08:32:40 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: [jose] xpo Thread-Index: AQHNrEDfucS89Z7uH0uzJAfKNczTGZe9eJOAgAK6vgCAAAgHAIAFmi+AgADAq+A= Date: Tue, 23 Oct 2012 08:32:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366877D28@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> <6BA7F1B5-5F4D-4626-B18E-9D31E68FCE21@bbn.com> In-Reply-To: <6BA7F1B5-5F4D-4626-B18E-9D31E68FCE21@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464001)(24454001)(51704002)(377454001)(31966008)(47736001)(550184003)(47976001)(47776002)(48376001)(16826001)(16696001)(5343635001)(20776001)(5343655001)(33656001)(53806001)(51856001)(46102001)(16406001)(2666001)(42186003)(8716001)(44976002)(74662001)(50986001)(4396001)(47446002)(50466001)(3846001)(49866001)(1076001)(4196001)(74502001)(15202345001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0643BDA83C Subject: Re: [jose] xpo 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, 23 Oct 2012 08:34:32 -0000 Scoping would make sense if we anticipated there being many many key parame= ters in the future, such that future naming conflicts were likely. In prac= tice, there are all of eight key parameters defined at present ("alg", "crv= ", "x", "y", "mod", "xpo", "use", and "kid"). I've heard discussions of ma= ybe one or two more that people might anticipate adding in the future (expi= ration time is the only one I can remember off the top of my head). So at = least within the next few years, the number might reach a dozen or so. And= we already have a registry defined that would avoid parameter conflicts. Adding structure to avoid potential conflicts among at most a dozen or so p= arameter names seems like significant overkill. In the spirit of keeping s= imple things simple, in practice, I'm sure that a flat structure will conti= nue to work out just fine. Cheers, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Monday, October 22, 2012 1:52 PM To: Manger, James H Cc: bcampbell@pingidentity.com; sakimura@gmail.com; jose@ietf.org; Axel.Nen= nker@telekom.de; vladimir@nimbusds.com Subject: Re: [jose] xpo On Oct 19, 2012, at 3:18 AM, Manger, James H wrote: > "exp" wouldn't clash if we used some JSON structure in a JWK. For instanc= e, separate the maths fields of the public key (n, e, ...) from the adminis= trative parts (key-id, certificate, usage...). Instead, JWK goes for a flat= bucket for all a key's info. Hence, we have potential problems with clashe= s of names from quite separate domains. We should fix the structure, instea= d of tinkering with the name. Yes. This. =20 Most of this WG's problems arise from using flat buckets. Flat buckets don= 't hold water :) --Richard > =20 > -- > James Manger > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of A= xel.Nennker@telekom.de > Sent: Friday, 19 October 2012 5:50 PM > To: jose@ietf.org > Cc: bcampbell@pingidentity.com; sakimura@gmail.com; vladimir@nimbusds.com > Subject: Re: [jose] xpo > =20 > I don't know why the exp in jwk needs to be changed. From a developer POW= there is no need. You always know which "exp" is the right one. > I would reverse the change from exp to xpo. Developers don't need it and = many did not update their implementation to incorporate the exp->xpo transi= tion. > =20 > Actually I don't care (much) how the parameters are named. Although I wou= ld like to stick to the 3-letter scheme I am OK with the n,e proposal. > But please stop making breaking changes (especially renaming parameters w= hich leads only to more work and no gain). > =20 > Case1: harm is already done -> stick with xpo and don't change AGAIN. > Case2: Most implementation haven't changed yet -> revert to exp > Case3: xpo is just stupid -> n,e is better -> another change -> Oh no -> = revert to exp > =20 > Again: I suggest to revert to exp and make the implementers happy. > =20 > Axel > =20 > Cc'ing Nat because I don't want to give away his developer's emails witho= ut asking. > =20 > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of B= rian Campbell > Sent: Wednesday, October 17, 2012 3:09 PM > To: Vladimir Dzhuvinov / NimbusDS > Cc: jose@ietf.org > Subject: Re: [jose] xpo > =20 > +1 (if a parameter name change is going to happen anyway) >=20 > On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS wrote: > +1 >=20 > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >=20 >=20 > -------- Original Message -------- > Subject: Re: [jose] xpo > From: Richard Barnes > Date: Wed, October 17, 2012 12:15 am > To: "Manger, James H" > Cc: Mike Jones , "jose@ietf.org" > >=20 >=20 > +1 >=20 > On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >=20 > >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 > >> * Changed the name of the JWK RSA exponent parameter from exp to xpo s= o as to allow the potential use of the name exp for a future extension that= might define an expiration parameter for keys. (The exp name is already us= ed for this purpose in the JWT specification.) > > > > "n" and "e" would be better than "mod" and "xpo". > > "n" and "e" are very widely used for the RSA modulus and public exponen= t. > > > > s^e =3D m mod n > > > > -- > > James Manger > > _______________________________________________ > > 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 > _______________________________________________ > 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 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From djc.ochtman@gmail.com Tue Oct 23 01:42:22 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 5BDCB21F86B5 for ; Tue, 23 Oct 2012 01:42:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgwM9VpzNiWT for ; Tue, 23 Oct 2012 01:42:21 -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 C54E221F86BE for ; Tue, 23 Oct 2012 01:42:21 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2405969qcg.31 for ; Tue, 23 Oct 2012 01:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=AGVUw7XAdgiahTjATRPc6voACg14hr7wz7gLHAJLoJg=; b=CdSHSD9VV+DenjzhfFytVkjVwd5KZyjBvQ5Dw/yo1bpAwOj7HULOQsQEApfiwe1SMV djLlUlDZgkjkjb66AA0lhZqUiA00HpM0iYwBJjnfaEwB0zHpLYlOKnMD0iJtCcj7a0TE uWCzgvWXTLWtQ5Yo2Kly/OXd/0V3PjaEFPhgR74AFXOirqGw1IfLoC9lMOG1kf8kbaxp p2ADvxhkkxAQ9HuytbuCDQv8RMscR46z4hUQdtoD2OOomMTJBBmZneQK2Dyx2njNCdIs 5IVimQAAt8LVsLMsfqS/mLKvCI5VGYJm58SAjVx1xJER8Ur9YpmgNMgcBvQO87/Q1vNM JgfA== Received: by 10.224.72.206 with SMTP id n14mr3335621qaj.38.1350981738462; Tue, 23 Oct 2012 01:42:18 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.49.97.195 with HTTP; Tue, 23 Oct 2012 01:41:58 -0700 (PDT) In-Reply-To: References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> From: Dirkjan Ochtman Date: Tue, 23 Oct 2012 10:41:58 +0200 X-Google-Sender-Auth: tDEPz5z1OjwDU9jhufECs9LMbZg Message-ID: To: Michael Jones Content-Type: text/plain; charset=UTF-8 Cc: jose@ietf.org Subject: Re: [jose] xpo 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, 23 Oct 2012 08:42:22 -0000 On Mon, Oct 22, 2012 at 10:23 PM, Michael Jones wrote: > It seems the choice is between (mod, xpo) and (n, e). A number of people > have already expressed a preference for the latter. What do others think? I recently implemented partial support for JWS/JWA/JWK in order to write an identity provider for Mozilla Persona, and the usage of (n, e) in their preliminary spec (based on an older draft of the JOSE specs, IIUC) made it very easy to correlate those parameters to the documentation for my cryptographic library. So +1 from me for (n, e). Cheers, Dirkjan From James.H.Manger@team.telstra.com Tue Oct 23 16:47: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 4B50D1F0CB7 for ; Tue, 23 Oct 2012 16:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_23=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvDJ2-cCz9z1 for ; Tue, 23 Oct 2012 16:47:52 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5B11F0CB8 for ; Tue, 23 Oct 2012 16:47:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,638,1344175200"; d="scan'208";a="99466114" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 24 Oct 2012 10:47:48 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6874"; a="139471543" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcavi.tcif.telstra.com.au with ESMTP; 24 Oct 2012 10:47:47 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 24 Oct 2012 10:47:47 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 24 Oct 2012 10:47:44 +1100 Thread-Topic: [jose] xpo Thread-Index: AQHNrEDfucS89Z7uH0uzJAfKNczTGZe9eJOAgAK6vgCAAAgHAIAFmi+AgADAq+CAAOwFIA== Message-ID: <255B9BB34FB7D647A506DC292726F6E114FE01A44B@WSMSG3153V.srv.dir.telstra.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> <6BA7F1B5-5F4D-4626-B18E-9D31E68FCE21@bbn.com> <4E1F6AAD24975D4BA5B168042967394366877D28@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877D28@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] xpo 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, 23 Oct 2012 23:47:53 -0000 TWlrZSBpcyByaWdodCB0aGF0IHdpdGggb25seSBhIGhhbmRmdWwgb3Igc28gcGFyYW1ldGVycyB3 ZSBjb3VsZCBtdWRkbGUgdGhyb3VnaCB3aXRoIGEgZmxhdCBzdHJ1Y3R1cmUuIFRoZSBmYWN0IHRo YXQgd2UgaGF2ZSBhbHJlYWR5IGhhZCBhIGNsYXNoICgiZXhwIikgaXMgYW5ub3lpbmcsIGFuZCBu b3QgYSBnb29kIHNpZ24gYWJvdXQgdGhlIGZsYXQgc3RydWN0dXJlLCBidXQgd2UgY291bGQgbXVk ZGxlIHRocm91Z2ggYW55d2F5LiBBIHBhcmFtZXRlciByZWdpc3RyeSBpcyBzdXBwb3NlZCB0byBo ZWxwLg0KDQpCdXQgdGhlcmUgYXJlIGFscmVhZHkgb3RoZXIgcHJvYmxlbXMuLi4NCkpXSyBbc2Vj dGlvbiA0LiAiSlNPTiBXZWIgS2V5IChKV0spIEZvcm1hdCI7IHNlY3Rpb24gNi4xLjEuICJSZWdp c3RyYXRpb24gVGVtcGxhdGUiXSBzYXlzIHBhcmFtZXRlcnMgc2hvdWxkIGJlIHJlZ2lzdGVyZWQ7 IHNheXMgZGlmZmVyZW50IGtpbmRzIG9mIGtleSBjYW4gdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBu YW1lIGZvciBraW5kLXNwZWNpZmljIHBhcmFtZXRlcnM7IGFuZCBlc3RhYmxpc2hlcyBhIHJlZ2lz dHJ5IHRoYXQgYXNzdW1lcyBwYXJhbWV0ZXIgbmFtZXMgYXJlIHVuYW1iaWd1b3VzLiBUaG9zZSB0 aHJlZSBwb2ludHMgY2Fubm90IGFsbCB3b3JrIHRvZ2V0aGVyLg0KDQpGb3IgaW5zdGFuY2UsIGFu IGVsbGlwdGljIGN1cnZlIGtleSBjYW4gdXNlICJ5IiBmb3IgdGhlIHgtY29vcmRpbmF0ZSBvZiBh IHBvaW50OyB3aGlsZSBhIA0KRFNBIGtleSBjb3VsZCB1c2UgInkiIGZvciB0aGUgcHVibGljIGtl eSAoYW4gaW50ZWdlcikuIFdoYXQgZ29lcyBpbiB0aGUgcmVnaXN0cnk/DQoNClRoZSAiZXhwIiBj bGFzaCB0aGVvcmV0aWNhbGx5IGlzbuKAmXQgYSBjbGFzaCBhbnl3YXksIHNpbmNlIHRoZSBKV0sg cGFyYW1ldGVyIHJlZ2lzdHJ5IGlzICpzZXBhcmF0ZSogZnJvbSB0aGUgSldFL0pXUyBoZWFkZXIg cGFyYW1ldGVyIHJlZ2lzdHJ5LiBPZiBjb3Vyc2Ugd2UgZG9uJ3Qgd2FudCBkaWZmZXJlbnQgbmFt ZXMgZm9yIHRoZSBzYW1lIHNvcnQgb2YgbWV0YWRhdGEgaW4gSldTICYgSldLIC0tIHRoYXQgd291 bGQgYmUgYW5ub3lpbmcuIFRoaXMgc3VnZ2VzdHMgd2UgaGF2ZSBhcnJhbmdlZCB0aGUgcmVnaXN0 cmllcyBpbmNvcnJlY3RseS4NCg0KWW91IGNhbiBhbHNvIHNlZSB0aGlzIGlzc3VlIGluIEpXRSAm IEpXUy4gVGhleSBzaGFyZSBhIGNvbW1vbiByZWdpc3RyeTogIkpTT04gV2ViIFNpZ25hdHVyZSBh bmQgRW5jcnlwdGlvbiBoZWFkZXIgUGFyYW1ldGVycyBSZWdpc3RyeSIgW0pXUyBzZWN0aW9uIDcu MV0uIEpXUyBwdXRzICJraWQiIGluIHRoaXMgcmVnaXN0cnksIHBvaW50aW5nIHRvIEpXUyBzZWN0 aW9uIDQuMS43LiB3aGVyZSBpdCBpcyBkZWZpbmVkIGFzIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBv cmlnaW5hdG9yJ3Mga2V5LiBKV0UgcHV0cyB0aGUgc2FtZSBuYW1lICJraWQiIGluIHRoZSBzYW1l IHJlZ2lzdHJ5LCBidXQgcG9pbnRzIGl0IHRvIEpXRSBzZWN0aW9uIDQuMS4xMC4gd2hlcmUgaXQg aXMgZGVmaW5lZCBhcyBhbiBpZGVudGlmaWVyIGZvciB0aGUgcmVjaXBpZW50J3Mga2V5LiBVZ2g/ IFdoYXQgd2lsbCBnbyBpbiB0aGUgcmVnaXN0cnk/IFdoYXQgaGFwcGVucyB3aGVuIGFuIG9yaWdp bmF0b3IgYW5kIHJlY2lwaWVudCBrZXkgYXJlIGJvdGggaW52b2x2ZWQ/DQoNCg0KUGVyaGFwcyB0 aGlzIG1lc3MgY2FuIGJlIHNvcnRlZCBvdXQgYnkgcHV0dGluZyBtb3JlIGNhcmUgaW50byB3aGlj aCByZWdpc3RyaWVzIGFyZSBkZWZpbmVkIGFuZCB3aGF0IGRldGFpbHMgZ28gaW50byB0aGVtLiBQ ZXJoYXBzIGEgcGFyYW1ldGVyIHJlZ2lzdHJ5IHRoYXQgaXMgY29tbW9uIGZvciBKV0UvSldTL0pX SywgYnV0IGFsbG93cyBuYW1lcyB0byBiZSByZWdpc3RlcmVkIHRoYXQgKGluc3RlYWQgb2YgcG9p bnRpbmcgdG8gb25lIGRlZmluaXRpb24gZm9yIHRoZSBwYXJhbWV0ZXIpIG1hcmsgdGhhdCBwYXJh bWV0ZXIgYXMgZGVwZW5kYW50IG9uIHRoZSB2YWx1ZSBvZiwgc2F5LCB0aGUgImFsZyIgdmFsdWUg aW4gdGhlIHNhbWUgY29udGV4dD8NCg0KQWN0dWFsbHksIHRoaXMgc291bmRzIG1vcmUgY29tcGxl eCB0aGFuIGp1c3QgdXNpbmcgc29tZSBzdHJ1Y3R1cmUgaW4gdGhlIG1lc3NhZ2VzLg0KDQotLQ0K SmFtZXMgTWFuZ2VyDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQo+IE1pa2UgSm9uZXMNCj4gU2VudDogVHVlc2RheSwgMjMgT2N0b2JlciAyMDEy IDc6MzMgUE0NCj4gVG86IGpvc2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtqb3NlXSB4cG8N Cj4gDQo+IFNjb3Bpbmcgd291bGQgbWFrZSBzZW5zZSBpZiB3ZSBhbnRpY2lwYXRlZCB0aGVyZSBi ZWluZyBtYW55IG1hbnkga2V5DQo+IHBhcmFtZXRlcnMgaW4gdGhlIGZ1dHVyZSwgc3VjaCB0aGF0 IGZ1dHVyZSBuYW1pbmcgY29uZmxpY3RzIHdlcmUNCj4gbGlrZWx5LiAgSW4gcHJhY3RpY2UsIHRo ZXJlIGFyZSBhbGwgb2YgZWlnaHQga2V5IHBhcmFtZXRlcnMgZGVmaW5lZCBhdA0KPiBwcmVzZW50 ICgiYWxnIiwgImNydiIsICJ4IiwgInkiLCAibW9kIiwgInhwbyIsICJ1c2UiLCBhbmQgImtpZCIp LiAgSSd2ZQ0KPiBoZWFyZCBkaXNjdXNzaW9ucyBvZiBtYXliZSBvbmUgb3IgdHdvIG1vcmUgdGhh dCBwZW9wbGUgbWlnaHQgYW50aWNpcGF0ZQ0KPiBhZGRpbmcgaW4gdGhlIGZ1dHVyZSAoZXhwaXJh dGlvbiB0aW1lIGlzIHRoZSBvbmx5IG9uZSBJIGNhbiByZW1lbWJlcg0KPiBvZmYgdGhlIHRvcCBv ZiBteSBoZWFkKS4gIFNvIGF0IGxlYXN0IHdpdGhpbiB0aGUgbmV4dCBmZXcgeWVhcnMsIHRoZQ0K PiBudW1iZXIgbWlnaHQgcmVhY2ggYSBkb3plbiBvciBzby4gIEFuZCB3ZSBhbHJlYWR5IGhhdmUg YSByZWdpc3RyeQ0KPiBkZWZpbmVkIHRoYXQgd291bGQgYXZvaWQgcGFyYW1ldGVyIGNvbmZsaWN0 cy4NCj4gDQo+IEFkZGluZyBzdHJ1Y3R1cmUgdG8gYXZvaWQgcG90ZW50aWFsIGNvbmZsaWN0cyBh bW9uZyBhdCBtb3N0IGEgZG96ZW4gb3INCj4gc28gcGFyYW1ldGVyIG5hbWVzIHNlZW1zIGxpa2Ug c2lnbmlmaWNhbnQgb3ZlcmtpbGwuICBJbiB0aGUgc3Bpcml0IG9mDQo+IGtlZXBpbmcgc2ltcGxl IHRoaW5ncyBzaW1wbGUsIGluIHByYWN0aWNlLCBJJ20gc3VyZSB0aGF0IGEgZmxhdA0KPiBzdHJ1 Y3R1cmUgd2lsbCBjb250aW51ZSB0byB3b3JrIG91dCBqdXN0IGZpbmUuDQo+IA0KPiAJCQkJQ2hl ZXJzLA0KPiAJCQkJLS0gTWlrZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4gUmljaGFyZCBCYXJuZXMNCj4gU2VudDogTW9uZGF5LCBPY3RvYmVy IDIyLCAyMDEyIDE6NTIgUE0NCj4gVG86IE1hbmdlciwgSmFtZXMgSA0KPiBDYzogYmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb207IHNha2ltdXJhQGdtYWlsLmNvbTsgam9zZUBpZXRmLm9yZzsNCj4g QXhlbC5OZW5ua2VyQHRlbGVrb20uZGU7IHZsYWRpbWlyQG5pbWJ1c2RzLmNvbQ0KPiBTdWJqZWN0 OiBSZTogW2pvc2VdIHhwbw0KPiANCj4gDQo+IE9uIE9jdCAxOSwgMjAxMiwgYXQgMzoxOCBBTSwg TWFuZ2VyLCBKYW1lcyBIIHdyb3RlOg0KPiANCj4gPiAiZXhwIiB3b3VsZG4ndCBjbGFzaCBpZiB3 ZSB1c2VkIHNvbWUgSlNPTiBzdHJ1Y3R1cmUgaW4gYSBKV0suIEZvcg0KPiBpbnN0YW5jZSwgc2Vw YXJhdGUgdGhlIG1hdGhzIGZpZWxkcyBvZiB0aGUgcHVibGljIGtleSAobiwgZSwgLi4uKSBmcm9t DQo+IHRoZSBhZG1pbmlzdHJhdGl2ZSBwYXJ0cyAoa2V5LWlkLCBjZXJ0aWZpY2F0ZSwgdXNhZ2Uu Li4pLiBJbnN0ZWFkLCBKV0sNCj4gZ29lcyBmb3IgYSBmbGF0IGJ1Y2tldCBmb3IgYWxsIGEga2V5 J3MgaW5mby4gSGVuY2UsIHdlIGhhdmUgcG90ZW50aWFsDQo+IHByb2JsZW1zIHdpdGggY2xhc2hl cyBvZiBuYW1lcyBmcm9tIHF1aXRlIHNlcGFyYXRlIGRvbWFpbnMuIFdlIHNob3VsZA0KPiBmaXgg dGhlIHN0cnVjdHVyZSwgaW5zdGVhZCBvZiB0aW5rZXJpbmcgd2l0aCB0aGUgbmFtZS4NCj4gDQo+ IFllcy4gIFRoaXMuDQo+IA0KPiBNb3N0IG9mIHRoaXMgV0cncyBwcm9ibGVtcyBhcmlzZSBmcm9t IHVzaW5nIGZsYXQgYnVja2V0cy4gIEZsYXQgYnVja2V0cw0KPiBkb24ndCBob2xkIHdhdGVyIDop DQo+IA0KPiAtLVJpY2hhcmQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiA+DQo+ID4gLS0NCj4gPiBK YW1lcyBNYW5nZXINCj4gPg0KPiA+IEZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Ompvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIEF4ZWwuTmVubmtlckB0ZWxl a29tLmRlDQo+ID4gU2VudDogRnJpZGF5LCAxOSBPY3RvYmVyIDIwMTIgNTo1MCBQTQ0KPiA+IFRv OiBqb3NlQGlldGYub3JnDQo+ID4gQ2M6IGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tOyBzYWtp bXVyYUBnbWFpbC5jb207DQo+IHZsYWRpbWlyQG5pbWJ1c2RzLmNvbQ0KPiA+IFN1YmplY3Q6IFJl OiBbam9zZV0geHBvDQo+ID4NCj4gPiBJIGRvbid0IGtub3cgd2h5IHRoZSBleHAgaW4gandrIG5l ZWRzIHRvIGJlIGNoYW5nZWQuIEZyb20gYSBkZXZlbG9wZXINCj4gUE9XIHRoZXJlIGlzIG5vIG5l ZWQuIFlvdSBhbHdheXMga25vdyB3aGljaCAiZXhwIiBpcyB0aGUgcmlnaHQgb25lLg0KPiA+IEkg d291bGQgcmV2ZXJzZSB0aGUgY2hhbmdlIGZyb20gZXhwIHRvIHhwby4gRGV2ZWxvcGVycyBkb24n dCBuZWVkIGl0DQo+IGFuZCBtYW55IGRpZCBub3QgdXBkYXRlIHRoZWlyIGltcGxlbWVudGF0aW9u IHRvIGluY29ycG9yYXRlIHRoZSBleHAtDQo+ID54cG8gdHJhbnNpdGlvbi4NCj4gPg0KPiA+IEFj dHVhbGx5IEkgZG9uJ3QgY2FyZSAobXVjaCkgaG93IHRoZSBwYXJhbWV0ZXJzIGFyZSBuYW1lZC4g QWx0aG91Z2ggSQ0KPiB3b3VsZCBsaWtlIHRvIHN0aWNrIHRvIHRoZSAzLWxldHRlciBzY2hlbWUg SSBhbSBPSyB3aXRoIHRoZSBuLGUNCj4gcHJvcG9zYWwuDQo+ID4gQnV0IHBsZWFzZSBzdG9wIG1h a2luZyBicmVha2luZyBjaGFuZ2VzIChlc3BlY2lhbGx5IHJlbmFtaW5nDQo+IHBhcmFtZXRlcnMg d2hpY2ggbGVhZHMgb25seSB0byBtb3JlIHdvcmsgYW5kIG5vIGdhaW4pLg0KPiA+DQo+ID4gQ2Fz ZTE6IGhhcm0gaXMgYWxyZWFkeSBkb25lIC0+IHN0aWNrIHdpdGggeHBvIGFuZCBkb24ndCBjaGFu Z2UgQUdBSU4uDQo+ID4gQ2FzZTI6IE1vc3QgaW1wbGVtZW50YXRpb24gaGF2ZW4ndCBjaGFuZ2Vk IHlldCAtPiByZXZlcnQgdG8gZXhwDQo+ID4gQ2FzZTM6IHhwbyBpcyBqdXN0IHN0dXBpZCAtPiBu LGUgaXMgYmV0dGVyIC0+IGFub3RoZXIgY2hhbmdlIC0+IE9oIG5vDQo+IC0+IHJldmVydCB0byBl eHANCj4gPg0KPiA+IEFnYWluOiBJIHN1Z2dlc3QgdG8gcmV2ZXJ0IHRvIGV4cCBhbmQgbWFrZSB0 aGUgaW1wbGVtZW50ZXJzIGhhcHB5Lg0KPiA+DQo+ID4gQXhlbA0KPiA+DQo+ID4gQ2MnaW5nIE5h dCBiZWNhdXNlIEkgZG9uJ3Qgd2FudCB0byBnaXZlIGF3YXkgaGlzIGRldmVsb3BlcidzIGVtYWls cw0KPiB3aXRob3V0IGFza2luZy4NCj4gPg0KPiA+DQo+ID4gRnJvbTogam9zZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgQnJp YW4gQ2FtcGJlbGwNCj4gPg0KPiA+ICsxIChpZiBhIHBhcmFtZXRlciBuYW1lIGNoYW5nZSBpcyBn b2luZyB0byBoYXBwZW4gYW55d2F5KQ0KPiA+DQo+ID4gT24gV2VkLCBPY3QgMTcsIDIwMTIgYXQg MjoyNCBBTSwgVmxhZGltaXIgRHpodXZpbm92IC8gTmltYnVzRFMNCj4gPHZsYWRpbWlyQG5pbWJ1 c2RzLmNvbT4gd3JvdGU6DQo+ID4gKzENCj4gPg0KPiA+IC0tLS0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0tLS0NCj4gPiBGcm9tOiBSaWNoYXJkIEJhcm5lcyA8cmJhcm5lc0BiYm4uY29tPg0K PiA+DQo+ID4gKzENCj4gPg0KPiA+IE9uIE9jdCAxNiwgMjAxMiwgYXQgNjo1NSBQTSwgTWFuZ2Vy LCBKYW1lcyBIIHdyb3RlOg0KPiA+DQo+ID4gPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNg0KPiA+ID4+ICogQ2hhbmdlZCB0aGUgbmFt ZSBvZiB0aGUgSldLIFJTQSBleHBvbmVudCBwYXJhbWV0ZXIgZnJvbSBleHAgdG8NCj4geHBvIHNv IGFzIHRvIGFsbG93IHRoZSBwb3RlbnRpYWwgdXNlIG9mIHRoZSBuYW1lIGV4cCBmb3IgYSBmdXR1 cmUNCj4gZXh0ZW5zaW9uIHRoYXQgbWlnaHQgZGVmaW5lIGFuIGV4cGlyYXRpb24gcGFyYW1ldGVy IGZvciBrZXlzLiAoVGhlIGV4cA0KPiBuYW1lIGlzIGFscmVhZHkgdXNlZCBmb3IgdGhpcyBwdXJw b3NlIGluIHRoZSBKV1Qgc3BlY2lmaWNhdGlvbi4pDQo+ID4gPg0KPiA+ID4gIm4iIGFuZCAiZSIg d291bGQgYmUgYmV0dGVyIHRoYW4gIm1vZCIgYW5kICJ4cG8iLg0KPiA+ID4gIm4iIGFuZCAiZSIg YXJlIHZlcnkgd2lkZWx5IHVzZWQgZm9yIHRoZSBSU0EgbW9kdWx1cyBhbmQgcHVibGljDQo+IGV4 cG9uZW50Lg0KPiA+ID4NCj4gPiA+IHNeZSA9IG0gbW9kIG4NCj4gPiA+DQo+ID4gPiAtLQ0KPiA+ ID4gSmFtZXMgTWFuZ2VyDQo= From Michael.Jones@microsoft.com Tue Oct 23 23:42:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D7621F8D3C for ; Tue, 23 Oct 2012 23:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA2IPKkSftpS for ; Tue, 23 Oct 2012 23:42:20 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 886B721F8D28 for ; Tue, 23 Oct 2012 23:42:19 -0700 (PDT) Received: from BY2FFO11FD015.protection.gbl (10.1.15.203) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 24 Oct 2012 06:42:10 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 24 Oct 2012 06:42:10 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 24 Oct 2012 06:41:59 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] xpo Thread-Index: AQHNrEDfucS89Z7uH0uzJAfKNczTGZe9eJOAgAK6vgCAAAgHAIAFmi+AgADAq+CAAOwFIIAAiCAw Date: Wed, 24 Oct 2012 06:41:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366879A5B@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> <6BA7F1B5-5F4D-4626-B18E-9D31E68FCE21@bbn.com> <4E1F6AAD24975D4BA5B168042967394366877D28@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FE01A44B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FE01A44B@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(377454001)(52314002)(51704002)(13464001)(47976001)(16406001)(31966008)(47776002)(16696001)(53806001)(20776001)(54316001)(16826001)(54356001)(8716001)(1076001)(3846001)(15202345001)(2666001)(4396001)(4196001)(51856001)(50466001)(49866001)(50986001)(5343635001)(5343655001)(74502001)(46102001)(48376001)(47446002)(44976002)(74662001)(47736001)(33656001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0644578634 Subject: Re: [jose] xpo 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, 24 Oct 2012 06:42:21 -0000 SGkgSmFtZXMsDQoNCkluIHRoZSBKV0sgY2FzZSB5b3UgY2l0ZSBiZWxvdywgYm90aCB1c2VzIG9m IHRoZSBuYW1lICJ5IiB3b3VsZCBnbyBpbnRvIHRoZSByZWdpc3RyeS4gIFRoaXMgd291bGQgbm90 IGJlIGEgY29uZmxpY3QsIGFzIHRoZWlyIHVzZSBpcyBkaWZmZXJlbnRpYXRlZCBieSB0aGUgImFs ZyIgcGFyYW1ldGVyIHZhbHVlLiAgVGhpcyBpcyBhbHJlYWR5IHRoZSBpbnRlbnQgb2YgdGhlIHNw ZWMsIGJ1dCBJJ2xsIGJlIHN1cmUgdG8gcmUtcmVhZCBhbmQgcmV2aWV3IHRoaXMgbGFuZ3VhZ2Ug aW4gdGhlIG5leHQgcm91bmQgb2YgcmV2aXNpb25zIHRvIG1ha2Ugc3VyZSB0aGF0IHRoaXMgdXNl IG9mIHRoZSByZWdpc3RyeSBpcyBjbGVhcmx5IGNhbGxlZCBvdXQgYXMgbGVnYWwgYW5kIGludGVu ZGVkLg0KDQpMaWtld2lzZSwgaW4gdGhlIHNlY29uZCBjYXNlIHlvdSBjaXRlLCB0aGUgSlNPTiBX ZWIgU2lnbmF0dXJlIGFuZCBFbmNyeXB0aW9uIEhlYWRlciBQYXJhbWV0ZXJzIHJlZ2lzdHJ5IGFs cmVhZHkgbWFrZXMgaXQgY2xlYXIgdGhhdCAiVGhlIHNhbWUgSGVhZGVyIFBhcmFtZXRlciBOYW1l IG1heSBiZSByZWdpc3RlcmVkIG11bHRpcGxlIHRpbWVzLCBwcm92aWRlZCB0aGF0IHRoZSBwYXJh bWV0ZXIgdXNhZ2UgaXMgY29tcGF0aWJsZSBiZXR3ZWVuIHRoZSBzcGVjaWZpY2F0aW9ucy4iICBU aGVyZSBpcyBubyBjb25mbGljdC4NCg0KV2UgaGF2ZSBubyBzZXRzIG9mIGFsZ29yaXRobSBjb21i aW5hdGlvbnMgdGhhdCB0YWtlIG11bHRpcGxlIGluZGVwZW5kZW50IGtleXMgYXMgaW5wdXRzLCBz byB0aGVyZSBpcyBubyBuZWVkIGZvciB0d28gImtpZCIgcGFyYW1ldGVycyBpbiBhbnkgaGVhZGVy Lg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogam9z ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTWFuZ2VyLCBKYW1lcyBIDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIzLCAyMDEyIDQ6 NDggUE0NClRvOiBNaWtlIEpvbmVzOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2pvc2Vd IHhwbw0KDQpNaWtlIGlzIHJpZ2h0IHRoYXQgd2l0aCBvbmx5IGEgaGFuZGZ1bCBvciBzbyBwYXJh bWV0ZXJzIHdlIGNvdWxkIG11ZGRsZSB0aHJvdWdoIHdpdGggYSBmbGF0IHN0cnVjdHVyZS4gVGhl IGZhY3QgdGhhdCB3ZSBoYXZlIGFscmVhZHkgaGFkIGEgY2xhc2ggKCJleHAiKSBpcyBhbm5veWlu ZywgYW5kIG5vdCBhIGdvb2Qgc2lnbiBhYm91dCB0aGUgZmxhdCBzdHJ1Y3R1cmUsIGJ1dCB3ZSBj b3VsZCBtdWRkbGUgdGhyb3VnaCBhbnl3YXkuIEEgcGFyYW1ldGVyIHJlZ2lzdHJ5IGlzIHN1cHBv c2VkIHRvIGhlbHAuDQoNCkJ1dCB0aGVyZSBhcmUgYWxyZWFkeSBvdGhlciBwcm9ibGVtcy4uLg0K SldLIFtzZWN0aW9uIDQuICJKU09OIFdlYiBLZXkgKEpXSykgRm9ybWF0Ijsgc2VjdGlvbiA2LjEu MS4gIlJlZ2lzdHJhdGlvbiBUZW1wbGF0ZSJdIHNheXMgcGFyYW1ldGVycyBzaG91bGQgYmUgcmVn aXN0ZXJlZDsgc2F5cyBkaWZmZXJlbnQga2luZHMgb2Yga2V5IGNhbiB1c2UgdGhlIHNhbWUgcGFy YW1ldGVyIG5hbWUgZm9yIGtpbmQtc3BlY2lmaWMgcGFyYW1ldGVyczsgYW5kIGVzdGFibGlzaGVz IGEgcmVnaXN0cnkgdGhhdCBhc3N1bWVzIHBhcmFtZXRlciBuYW1lcyBhcmUgdW5hbWJpZ3VvdXMu IFRob3NlIHRocmVlIHBvaW50cyBjYW5ub3QgYWxsIHdvcmsgdG9nZXRoZXIuDQoNCkZvciBpbnN0 YW5jZSwgYW4gZWxsaXB0aWMgY3VydmUga2V5IGNhbiB1c2UgInkiIGZvciB0aGUgeC1jb29yZGlu YXRlIG9mIGEgcG9pbnQ7IHdoaWxlIGEgRFNBIGtleSBjb3VsZCB1c2UgInkiIGZvciB0aGUgcHVi bGljIGtleSAoYW4gaW50ZWdlcikuIFdoYXQgZ29lcyBpbiB0aGUgcmVnaXN0cnk/DQoNClRoZSAi ZXhwIiBjbGFzaCB0aGVvcmV0aWNhbGx5IGlzbuKAmXQgYSBjbGFzaCBhbnl3YXksIHNpbmNlIHRo ZSBKV0sgcGFyYW1ldGVyIHJlZ2lzdHJ5IGlzICpzZXBhcmF0ZSogZnJvbSB0aGUgSldFL0pXUyBo ZWFkZXIgcGFyYW1ldGVyIHJlZ2lzdHJ5LiBPZiBjb3Vyc2Ugd2UgZG9uJ3Qgd2FudCBkaWZmZXJl bnQgbmFtZXMgZm9yIHRoZSBzYW1lIHNvcnQgb2YgbWV0YWRhdGEgaW4gSldTICYgSldLIC0tIHRo YXQgd291bGQgYmUgYW5ub3lpbmcuIFRoaXMgc3VnZ2VzdHMgd2UgaGF2ZSBhcnJhbmdlZCB0aGUg cmVnaXN0cmllcyBpbmNvcnJlY3RseS4NCg0KWW91IGNhbiBhbHNvIHNlZSB0aGlzIGlzc3VlIGlu IEpXRSAmIEpXUy4gVGhleSBzaGFyZSBhIGNvbW1vbiByZWdpc3RyeTogIkpTT04gV2ViIFNpZ25h dHVyZSBhbmQgRW5jcnlwdGlvbiBoZWFkZXIgUGFyYW1ldGVycyBSZWdpc3RyeSIgW0pXUyBzZWN0 aW9uIDcuMV0uIEpXUyBwdXRzICJraWQiIGluIHRoaXMgcmVnaXN0cnksIHBvaW50aW5nIHRvIEpX UyBzZWN0aW9uIDQuMS43LiB3aGVyZSBpdCBpcyBkZWZpbmVkIGFzIGFuIGlkZW50aWZpZXIgZm9y IHRoZSBvcmlnaW5hdG9yJ3Mga2V5LiBKV0UgcHV0cyB0aGUgc2FtZSBuYW1lICJraWQiIGluIHRo ZSBzYW1lIHJlZ2lzdHJ5LCBidXQgcG9pbnRzIGl0IHRvIEpXRSBzZWN0aW9uIDQuMS4xMC4gd2hl cmUgaXQgaXMgZGVmaW5lZCBhcyBhbiBpZGVudGlmaWVyIGZvciB0aGUgcmVjaXBpZW50J3Mga2V5 LiBVZ2g/IFdoYXQgd2lsbCBnbyBpbiB0aGUgcmVnaXN0cnk/IFdoYXQgaGFwcGVucyB3aGVuIGFu IG9yaWdpbmF0b3IgYW5kIHJlY2lwaWVudCBrZXkgYXJlIGJvdGggaW52b2x2ZWQ/DQoNCg0KUGVy aGFwcyB0aGlzIG1lc3MgY2FuIGJlIHNvcnRlZCBvdXQgYnkgcHV0dGluZyBtb3JlIGNhcmUgaW50 byB3aGljaCByZWdpc3RyaWVzIGFyZSBkZWZpbmVkIGFuZCB3aGF0IGRldGFpbHMgZ28gaW50byB0 aGVtLiBQZXJoYXBzIGEgcGFyYW1ldGVyIHJlZ2lzdHJ5IHRoYXQgaXMgY29tbW9uIGZvciBKV0Uv SldTL0pXSywgYnV0IGFsbG93cyBuYW1lcyB0byBiZSByZWdpc3RlcmVkIHRoYXQgKGluc3RlYWQg b2YgcG9pbnRpbmcgdG8gb25lIGRlZmluaXRpb24gZm9yIHRoZSBwYXJhbWV0ZXIpIG1hcmsgdGhh dCBwYXJhbWV0ZXIgYXMgZGVwZW5kYW50IG9uIHRoZSB2YWx1ZSBvZiwgc2F5LCB0aGUgImFsZyIg dmFsdWUgaW4gdGhlIHNhbWUgY29udGV4dD8NCg0KQWN0dWFsbHksIHRoaXMgc291bmRzIG1vcmUg Y29tcGxleCB0aGFuIGp1c3QgdXNpbmcgc29tZSBzdHJ1Y3R1cmUgaW4gdGhlIG1lc3NhZ2VzLg0K DQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIA0KPiBPZiBNaWtlIEpvbmVzDQo+IFNlbnQ6IFR1ZXNkYXksIDIzIE9jdG9i ZXIgMjAxMiA3OjMzIFBNDQo+IFRvOiBqb3NlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbam9z ZV0geHBvDQo+IA0KPiBTY29waW5nIHdvdWxkIG1ha2Ugc2Vuc2UgaWYgd2UgYW50aWNpcGF0ZWQg dGhlcmUgYmVpbmcgbWFueSBtYW55IGtleSANCj4gcGFyYW1ldGVycyBpbiB0aGUgZnV0dXJlLCBz dWNoIHRoYXQgZnV0dXJlIG5hbWluZyBjb25mbGljdHMgd2VyZSANCj4gbGlrZWx5LiAgSW4gcHJh Y3RpY2UsIHRoZXJlIGFyZSBhbGwgb2YgZWlnaHQga2V5IHBhcmFtZXRlcnMgZGVmaW5lZCBhdCAN Cj4gcHJlc2VudCAoImFsZyIsICJjcnYiLCAieCIsICJ5IiwgIm1vZCIsICJ4cG8iLCAidXNlIiwg YW5kICJraWQiKS4gIA0KPiBJJ3ZlIGhlYXJkIGRpc2N1c3Npb25zIG9mIG1heWJlIG9uZSBvciB0 d28gbW9yZSB0aGF0IHBlb3BsZSBtaWdodCANCj4gYW50aWNpcGF0ZSBhZGRpbmcgaW4gdGhlIGZ1 dHVyZSAoZXhwaXJhdGlvbiB0aW1lIGlzIHRoZSBvbmx5IG9uZSBJIGNhbiANCj4gcmVtZW1iZXIg b2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCkuICBTbyBhdCBsZWFzdCB3aXRoaW4gdGhlIG5leHQgZmV3 IA0KPiB5ZWFycywgdGhlIG51bWJlciBtaWdodCByZWFjaCBhIGRvemVuIG9yIHNvLiAgQW5kIHdl IGFscmVhZHkgaGF2ZSBhIA0KPiByZWdpc3RyeSBkZWZpbmVkIHRoYXQgd291bGQgYXZvaWQgcGFy YW1ldGVyIGNvbmZsaWN0cy4NCj4gDQo+IEFkZGluZyBzdHJ1Y3R1cmUgdG8gYXZvaWQgcG90ZW50 aWFsIGNvbmZsaWN0cyBhbW9uZyBhdCBtb3N0IGEgZG96ZW4gb3IgDQo+IHNvIHBhcmFtZXRlciBu YW1lcyBzZWVtcyBsaWtlIHNpZ25pZmljYW50IG92ZXJraWxsLiAgSW4gdGhlIHNwaXJpdCBvZiAN Cj4ga2VlcGluZyBzaW1wbGUgdGhpbmdzIHNpbXBsZSwgaW4gcHJhY3RpY2UsIEknbSBzdXJlIHRo YXQgYSBmbGF0IA0KPiBzdHJ1Y3R1cmUgd2lsbCBjb250aW51ZSB0byB3b3JrIG91dCBqdXN0IGZp bmUuDQo+IA0KPiAJCQkJQ2hlZXJzLA0KPiAJCQkJLS0gTWlrZQ0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9z ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+IE9mIFJpY2hhcmQgQmFybmVzDQo+IFNl bnQ6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiAxOjUyIFBNDQo+IFRvOiBNYW5nZXIsIEphbWVz IEgNCj4gQ2M6IGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tOyBzYWtpbXVyYUBnbWFpbC5jb207 IGpvc2VAaWV0Zi5vcmc7IA0KPiBBeGVsLk5lbm5rZXJAdGVsZWtvbS5kZTsgdmxhZGltaXJAbmlt YnVzZHMuY29tDQo+IFN1YmplY3Q6IFJlOiBbam9zZV0geHBvDQo+IA0KPiANCj4gT24gT2N0IDE5 LCAyMDEyLCBhdCAzOjE4IEFNLCBNYW5nZXIsIEphbWVzIEggd3JvdGU6DQo+IA0KPiA+ICJleHAi IHdvdWxkbid0IGNsYXNoIGlmIHdlIHVzZWQgc29tZSBKU09OIHN0cnVjdHVyZSBpbiBhIEpXSy4g Rm9yDQo+IGluc3RhbmNlLCBzZXBhcmF0ZSB0aGUgbWF0aHMgZmllbGRzIG9mIHRoZSBwdWJsaWMg a2V5IChuLCBlLCAuLi4pIGZyb20gDQo+IHRoZSBhZG1pbmlzdHJhdGl2ZSBwYXJ0cyAoa2V5LWlk LCBjZXJ0aWZpY2F0ZSwgdXNhZ2UuLi4pLiBJbnN0ZWFkLCBKV0sgDQo+IGdvZXMgZm9yIGEgZmxh dCBidWNrZXQgZm9yIGFsbCBhIGtleSdzIGluZm8uIEhlbmNlLCB3ZSBoYXZlIHBvdGVudGlhbCAN Cj4gcHJvYmxlbXMgd2l0aCBjbGFzaGVzIG9mIG5hbWVzIGZyb20gcXVpdGUgc2VwYXJhdGUgZG9t YWlucy4gV2Ugc2hvdWxkIA0KPiBmaXggdGhlIHN0cnVjdHVyZSwgaW5zdGVhZCBvZiB0aW5rZXJp bmcgd2l0aCB0aGUgbmFtZS4NCj4gDQo+IFllcy4gIFRoaXMuDQo+IA0KPiBNb3N0IG9mIHRoaXMg V0cncyBwcm9ibGVtcyBhcmlzZSBmcm9tIHVzaW5nIGZsYXQgYnVja2V0cy4gIEZsYXQgDQo+IGJ1 Y2tldHMgZG9uJ3QgaG9sZCB3YXRlciA6KQ0KPiANCj4gLS1SaWNoYXJkDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gPg0KPiA+IC0tDQo+ID4gSmFtZXMgTWFuZ2VyDQo+ID4NCj4gPiBGcm9tOiBqb3Nl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPiBPZiBBeGVsLk5lbm5rZXJAdGVsZWtvbS5kZQ0KPiA+IFNlbnQ6IEZyaWRheSwgMTkgT2N0 b2JlciAyMDEyIDU6NTAgUE0NCj4gPiBUbzogam9zZUBpZXRmLm9yZw0KPiA+IENjOiBiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbTsgc2FraW11cmFAZ21haWwuY29tOw0KPiB2bGFkaW1pckBuaW1i dXNkcy5jb20NCj4gPiBTdWJqZWN0OiBSZTogW2pvc2VdIHhwbw0KPiA+DQo+ID4gSSBkb24ndCBr bm93IHdoeSB0aGUgZXhwIGluIGp3ayBuZWVkcyB0byBiZSBjaGFuZ2VkLiBGcm9tIGEgDQo+ID4g ZGV2ZWxvcGVyDQo+IFBPVyB0aGVyZSBpcyBubyBuZWVkLiBZb3UgYWx3YXlzIGtub3cgd2hpY2gg ImV4cCIgaXMgdGhlIHJpZ2h0IG9uZS4NCj4gPiBJIHdvdWxkIHJldmVyc2UgdGhlIGNoYW5nZSBm cm9tIGV4cCB0byB4cG8uIERldmVsb3BlcnMgZG9uJ3QgbmVlZCBpdA0KPiBhbmQgbWFueSBkaWQg bm90IHVwZGF0ZSB0aGVpciBpbXBsZW1lbnRhdGlvbiB0byBpbmNvcnBvcmF0ZSB0aGUgZXhwLQ0K PiA+eHBvIHRyYW5zaXRpb24uDQo+ID4NCj4gPiBBY3R1YWxseSBJIGRvbid0IGNhcmUgKG11Y2gp IGhvdyB0aGUgcGFyYW1ldGVycyBhcmUgbmFtZWQuIEFsdGhvdWdoIA0KPiA+IEkNCj4gd291bGQg bGlrZSB0byBzdGljayB0byB0aGUgMy1sZXR0ZXIgc2NoZW1lIEkgYW0gT0sgd2l0aCB0aGUgbixl IA0KPiBwcm9wb3NhbC4NCj4gPiBCdXQgcGxlYXNlIHN0b3AgbWFraW5nIGJyZWFraW5nIGNoYW5n ZXMgKGVzcGVjaWFsbHkgcmVuYW1pbmcNCj4gcGFyYW1ldGVycyB3aGljaCBsZWFkcyBvbmx5IHRv IG1vcmUgd29yayBhbmQgbm8gZ2FpbikuDQo+ID4NCj4gPiBDYXNlMTogaGFybSBpcyBhbHJlYWR5 IGRvbmUgLT4gc3RpY2sgd2l0aCB4cG8gYW5kIGRvbid0IGNoYW5nZSBBR0FJTi4NCj4gPiBDYXNl MjogTW9zdCBpbXBsZW1lbnRhdGlvbiBoYXZlbid0IGNoYW5nZWQgeWV0IC0+IHJldmVydCB0byBl eHANCj4gPiBDYXNlMzogeHBvIGlzIGp1c3Qgc3R1cGlkIC0+IG4sZSBpcyBiZXR0ZXIgLT4gYW5v dGhlciBjaGFuZ2UgLT4gT2ggDQo+ID4gbm8NCj4gLT4gcmV2ZXJ0IHRvIGV4cA0KPiA+DQo+ID4g QWdhaW46IEkgc3VnZ2VzdCB0byByZXZlcnQgdG8gZXhwIGFuZCBtYWtlIHRoZSBpbXBsZW1lbnRl cnMgaGFwcHkuDQo+ID4NCj4gPiBBeGVsDQo+ID4NCj4gPiBDYydpbmcgTmF0IGJlY2F1c2UgSSBk b24ndCB3YW50IHRvIGdpdmUgYXdheSBoaXMgZGV2ZWxvcGVyJ3MgZW1haWxzDQo+IHdpdGhvdXQg YXNraW5nLg0KPiA+DQo+ID4NCj4gPiBGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBCcmlhbiBDYW1wYmVsbA0K PiA+DQo+ID4gKzEgKGlmIGEgcGFyYW1ldGVyIG5hbWUgY2hhbmdlIGlzIGdvaW5nIHRvIGhhcHBl biBhbnl3YXkpDQo+ID4NCj4gPiBPbiBXZWQsIE9jdCAxNywgMjAxMiBhdCAyOjI0IEFNLCBWbGFk aW1pciBEemh1dmlub3YgLyBOaW1idXNEUw0KPiA8dmxhZGltaXJAbmltYnVzZHMuY29tPiB3cm90 ZToNCj4gPiArMQ0KPiA+DQo+ID4gLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0K PiA+IEZyb206IFJpY2hhcmQgQmFybmVzIDxyYmFybmVzQGJibi5jb20+DQo+ID4NCj4gPiArMQ0K PiA+DQo+ID4gT24gT2N0IDE2LCAyMDEyLCBhdCA2OjU1IFBNLCBNYW5nZXIsIEphbWVzIEggd3Jv dGU6DQo+ID4NCj4gPiA+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpv c2UtanNvbi13ZWIta2V5LTA2DQo+ID4gPj4gKiBDaGFuZ2VkIHRoZSBuYW1lIG9mIHRoZSBKV0sg UlNBIGV4cG9uZW50IHBhcmFtZXRlciBmcm9tIGV4cCB0bw0KPiB4cG8gc28gYXMgdG8gYWxsb3cg dGhlIHBvdGVudGlhbCB1c2Ugb2YgdGhlIG5hbWUgZXhwIGZvciBhIGZ1dHVyZSANCj4gZXh0ZW5z aW9uIHRoYXQgbWlnaHQgZGVmaW5lIGFuIGV4cGlyYXRpb24gcGFyYW1ldGVyIGZvciBrZXlzLiAo VGhlIGV4cCANCj4gbmFtZSBpcyBhbHJlYWR5IHVzZWQgZm9yIHRoaXMgcHVycG9zZSBpbiB0aGUg SldUIHNwZWNpZmljYXRpb24uKQ0KPiA+ID4NCj4gPiA+ICJuIiBhbmQgImUiIHdvdWxkIGJlIGJl dHRlciB0aGFuICJtb2QiIGFuZCAieHBvIi4NCj4gPiA+ICJuIiBhbmQgImUiIGFyZSB2ZXJ5IHdp ZGVseSB1c2VkIGZvciB0aGUgUlNBIG1vZHVsdXMgYW5kIHB1YmxpYw0KPiBleHBvbmVudC4NCj4g PiA+DQo+ID4gPiBzXmUgPSBtIG1vZCBuDQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+IEphbWVzIE1h bmdlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpv c2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2pvc2UNCg== From James.H.Manger@team.telstra.com Wed Oct 24 00:06: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 83D3221F8CF5 for ; Wed, 24 Oct 2012 00:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT+k4KiTVC25 for ; Wed, 24 Oct 2012 00:06:43 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0FB21F8CF3 for ; Wed, 24 Oct 2012 00:06:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,639,1344175200"; d="scan'208";a="98093841" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 24 Oct 2012 18:06:24 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6874"; a="95563982" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbni.tcif.telstra.com.au with ESMTP; 24 Oct 2012 18:06:24 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 24 Oct 2012 18:06:23 +1100 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 24 Oct 2012 18:06:23 +1100 Thread-Topic: [jose] xpo Thread-Index: AQHNrEDfucS89Z7uH0uzJAfKNczTGZe9eJOAgAK6vgCAAAgHAIAFmi+AgADAq+CAAOwFIIAAiCAwgAADzrA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FE0A3E16@WSMSG3153V.srv.dir.telstra.com> References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> <6BA7F1B5-5F4D-4626-B18E-9D31E68FCE21@bbn.com> <4E1F6AAD24975D4BA5B168042967394366877D28@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FE01A44B@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366879A5B@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366879A5B@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] xpo 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, 24 Oct 2012 07:06:51 -0000 PiBJbiB0aGUgSldLIGNhc2UgeW91IGNpdGUgYmVsb3csIGJvdGggdXNlcyBvZiB0aGUgbmFtZSAi eSIgd291bGQgZ28gaW50bw0KPiB0aGUgcmVnaXN0cnkuICBUaGlzIHdvdWxkIG5vdCBiZSBhIGNv bmZsaWN0LCBhcyB0aGVpciB1c2UgaXMNCj4gZGlmZmVyZW50aWF0ZWQgYnkgdGhlICJhbGciIHBh cmFtZXRlciB2YWx1ZS4gIFRoaXMgaXMgYWxyZWFkeSB0aGUNCj4gaW50ZW50IG9mIHRoZSBzcGVj LCBidXQgSSdsbCBiZSBzdXJlIHRvIHJlLXJlYWQgYW5kIHJldmlldyB0aGlzDQo+IGxhbmd1YWdl IGluIHRoZSBuZXh0IHJvdW5kIG9mIHJldmlzaW9ucyB0byBtYWtlIHN1cmUgdGhhdCB0aGlzIHVz ZSBvZg0KPiB0aGUgcmVnaXN0cnkgaXMgY2xlYXJseSBjYWxsZWQgb3V0IGFzIGxlZ2FsIGFuZCBp bnRlbmRlZC4NCg0KV293LCBzdHJhbmdlIHJlZ2lzdHJ5Lg0KUC5TLiBUaGUgc3BlYyBzYXlzICJu YW1lcyB0aGF0IG1hdGNoIG90aGVyIHJlZ2lzdGVyZWQgbmFtZXMgaW4gYSBjYXNlIGluc2Vuc2l0 aXZlIG1hbm5lciBTSE9VTEQgTk9UIGJlIGFjY2VwdGVkIi4gSSBoYWQgYmVlbiB3b25kZXJpbmcg d2h5IGl0IHdhc24ndCAiTVVTVCBOT1QiLCBub3cgeW91IGFyZSBzdWdnZXN0aW5nIGl0IGlzIGV2 ZW4gbG9vc2VyIHRoYW4gIk1BWSIuDQoNCj4gTGlrZXdpc2UsIGluIHRoZSBzZWNvbmQgY2FzZSB5 b3UgY2l0ZSwgdGhlIEpTT04gV2ViIFNpZ25hdHVyZSBhbmQNCj4gRW5jcnlwdGlvbiBIZWFkZXIg UGFyYW1ldGVycyByZWdpc3RyeSBhbHJlYWR5IG1ha2VzIGl0IGNsZWFyIHRoYXQgIlRoZQ0KPiBz YW1lIEhlYWRlciBQYXJhbWV0ZXIgTmFtZSBtYXkgYmUgcmVnaXN0ZXJlZCBtdWx0aXBsZSB0aW1l cywgcHJvdmlkZWQNCj4gdGhhdCB0aGUgcGFyYW1ldGVyIHVzYWdlIGlzIGNvbXBhdGlibGUgYmV0 d2VlbiB0aGUgc3BlY2lmaWNhdGlvbnMuIg0KPiBUaGVyZSBpcyBubyBjb25mbGljdC4NCg0KSWRl bnRpZnlpbmcgdGhlIG9yaWdpbmF0b3IncyBrZXkgYW5kIGlkZW50aWZ5aW5nIHRoZSByZWNpcGll bnQncyBrZXkgYXJlIGhhcmRseSAiY29tcGF0aWJsZSIgc2VtYW50aWNzLg0KQWdhaW4sIHN0cmFu Z2UgcmVnaXN0cnkuDQoNCj4gV2UgaGF2ZSBubyBzZXRzIG9mIGFsZ29yaXRobSBjb21iaW5hdGlv bnMgdGhhdCB0YWtlIG11bHRpcGxlDQo+IGluZGVwZW5kZW50IGtleXMgYXMgaW5wdXRzLCBzbyB0 aGVyZSBpcyBubyBuZWVkIGZvciB0d28gImtpZCINCj4gcGFyYW1ldGVycyBpbiBhbnkgaGVhZGVy Lg0KDQpUaGUgQ3J5cHRvIE1lc3NhZ2UgU3ludGF4IChDTVMpIGhhcyBrZXkgYWdyZWVtZW50IG1v ZGVzIHRoYXQgaW52b2x2ZSBpZGVudGlmaWVkIG9yaWdpbmF0b3IgYW5kIHJlY2lwaWVudCBrZXlz IHNvIGl0IGlzIGhhcmRseSBpbXBvc3NpYmxlIHRoYXQgSk9TRSBtaWdodCBzdXBwb3J0IHNvbWV0 aGluZyBzaW1pbGFyIGF0IHNvbWUgcG9pbnQuDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0K From odonoghue@isoc.org Wed Oct 24 03:34: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 9D34121F8B86 for ; Wed, 24 Oct 2012 03:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7s+jyGpLisV for ; Wed, 24 Oct 2012 03:34:41 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 01CFB21F8A6A for ; Wed, 24 Oct 2012 03:34:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 856AD270856 for ; Wed, 24 Oct 2012 06:34:40 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id DC4AD270855 for ; Wed, 24 Oct 2012 06:34:39 -0400 (EDT) Message-ID: <5087C43E.2010806@isoc.org> Date: Wed, 24 Oct 2012 06:34:38 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org Content-Type: multipart/alternative; boundary="------------080206000400050100000709" Subject: [jose] IETF84 consensus poll results and a last minute opportunity for objections X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:34:41 -0000 This is a multi-part message in MIME format. --------------080206000400050100000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, The following polls were conducted at the IETF84 meeting and followed up on the jose mailing list. 1. Non AEAD algorithm as a single name (CLOSED) 2. Add new ECB key wrap functionality (CLOSED) 3. Add key wrap functionality for EC (CLOSED) 4. Remove no key wrap for Key agree algorithms (CLOSED) 5. Add other than pre-shared MAC key (CLOSED) 6. Add Key Usage "both" (CLOSED) 7. Support multiple types for algorithms (string and object) (CLOSED) 8. RSA-OAEP/RSA-PSS default parameters (OPEN) 9. Add a nonce/timestamp Parameter (OPEN) 10. What criticality level should be used for header fields (OPEN) 11. Is KID sufficiently defined (CLOSED) I am preparing to send out the results of those polls (summarized above). If you have any serious concerns with my consensus calls, you have between now and the IETF in Atlanta to clearly and concisely articulate your concerns on the mailing list. I realize this will leave a few issues potentially open that folks would like to have closed, but given that I'm new as one of the co-chairs of the working group, I would prefer to err on the side of caution. I would, however, like to have all these issues closed in Atlanta. (and my apologies especially to Jim and Mike who worked so hard to close all the issues!) Thanks for your patience! Karen --------------080206000400050100000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Folks,

The following polls were conducted at the IETF84 meeting and followed up on the jose mailing list. 

1.  Non AEAD algorithm as a single name (CLOSED)
2.  Add new ECB key wrap functionality (CLOSED)
3.  Add key wrap functionality for EC (CLOSED)
4.  Remove no key wrap for Key agree algorithms (CLOSED)
5.  Add other than pre-shared MAC key (CLOSED)
6.  Add Key Usage "both" (CLOSED)
7.  Support multiple types for algorithms (string and object) (CLOSED)
8.  RSA-OAEP/RSA-PSS default parameters (OPEN)
9.  Add a nonce/timestamp Parameter (OPEN)
10. What criticality level should be used for header fields (OPEN)
11. Is KID sufficiently defined (CLOSED) 
I am preparing to send out the results of those polls (summarized above). If you have any serious 
concerns with my consensus calls, you have between now and the IETF in Atlanta to clearly and 
concisely articulate your concerns on the mailing list. I realize this will leave a few issues 
potentially open that folks would like to have closed, but given that I'm new as one of the 
co-chairs of the working group, I would prefer to err on the side of caution. I would, however, 
like to have all these issues closed in Atlanta. (and my apologies especially to Jim and Mike 
who worked so hard to close all the issues!)

Thanks for your patience!
Karen
--------------080206000400050100000709-- From odonoghue@isoc.org Wed Oct 24 03:35: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 6987621F8A6A for ; Wed, 24 Oct 2012 03:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggwCytPWXecB for ; Wed, 24 Oct 2012 03:35:01 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id E813121F8BB2 for ; Wed, 24 Oct 2012 03:35:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 99577270837 for ; Wed, 24 Oct 2012 06:35:00 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 19B3E27085A for ; Wed, 24 Oct 2012 06:34:59 -0400 (EDT) Message-ID: <5087C453.7080203@isoc.org> Date: Wed, 24 Oct 2012 06:34:59 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877A5A@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877A5A@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877A5A@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Add new ECB Key wrap function X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:35:01 -0000 Folks, The results of this poll were: 2 YES - We should add a new ECB key wrap function to the algorithm specification 10 NO - We should not add a new ECB key wrap function to the algorithm specification 0 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that we should not add a new ECB key wrap function to the algorithm specification. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:08 AM To: jose@ietf.org Subject: [jose] POLL: Add new ECB Key wrap function If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we add a new ECB key wrap function to the algorithm specification? This action would define a second key wrap function the current AES key wrap would not go away Room vote: 2 yes, 10 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:35:06 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 D9AA021F8BB7 for ; Wed, 24 Oct 2012 03:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbI02HPIniXc for ; Wed, 24 Oct 2012 03:35:06 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6059921F8BB1 for ; Wed, 24 Oct 2012 03:35:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 19B23270867 for ; Wed, 24 Oct 2012 06:35:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id A459B27085A for ; Wed, 24 Oct 2012 06:35:05 -0400 (EDT) Message-ID: <5087C458.2090106@isoc.org> Date: Wed, 24 Oct 2012 06:35:04 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877A40@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877A40@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877A40@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Add key wrap functionality for EC X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:35:07 -0000 Folks, The results of this poll were: 12 YES - We need to require the ability for doing a key agreement followed by a key wrap to get the CMK 1 NO - We do not need to require the ability for doing a key agreement followed by a key wrap to get the CMK 1 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that we do need to require the ability for doing a key agreement followed by a key wrap to get the CMK. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:08 AM To: jose@ietf.org Subject: [jose] POLL: Add key wrap functionality for EC If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Do we need to require the ability for doing a key agree followed by a key wrap to get the CMK? Current process uses the output of the key agree as the CMK, saying yes would allow for both methods to operate. Room vote: 12 yes, 1 no, 1 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:35:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561AE21F8BC1 for ; Wed, 24 Oct 2012 03:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1uzFxMdB50a for ; Wed, 24 Oct 2012 03:35:10 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id CEADB21F8A6A for ; Wed, 24 Oct 2012 03:35:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 84BC327085A for ; Wed, 24 Oct 2012 06:35:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 123AD2706CB for ; Wed, 24 Oct 2012 06:35:09 -0400 (EDT) Message-ID: <5087C45C.5050600@isoc.org> Date: Wed, 24 Oct 2012 06:35:08 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877A4D@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877A4D@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877A4D@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Remove no key wrap for key agreement algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:35:11 -0000 Folks, The results of this poll were: 1 YES - We should remove the ability to go directly from a Key Agreement algorithm to the CMK without having a key wrap step 9 NO - We should not remove the ability to go directly from a Key Agreement algorithm to the CMK without having a key wrap step 0 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that we should not remove the ability to go directly from a Key Agreement algorithm to the CMK without having a key wrap step. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:08 AM To: jose@ietf.org Subject: [jose] POLL: Remove no key wrap for key agreement algorithms If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we remove the ability to go directly from a Key Agreement algorithm to the CMK without having a key wrap step? This would remove the ability to go directly and would require an intervening key wrap step. Room vote: 1 yes, 6 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:35: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 9C23721F8BC6 for ; Wed, 24 Oct 2012 03:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHvz3mR-CGDO for ; Wed, 24 Oct 2012 03:35:17 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 35F4921F8BC5 for ; Wed, 24 Oct 2012 03:35:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id AC17327085A for ; Wed, 24 Oct 2012 06:35:16 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 3D85B2706CB for ; Wed, 24 Oct 2012 06:35:16 -0400 (EDT) Message-ID: <5087C463.1060006@isoc.org> Date: Wed, 24 Oct 2012 06:35:15 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877A2D@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877A2D@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877A2D@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Add Key Usage "both" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:35:17 -0000 Folks, The results of this poll were: 1 YES - We need to add the string "both" as a key usage 11 NO - We do not need to add the string "both" as a key usage 0 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that we do not need to add the string "both" as a key usage. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:08 AM To: jose@ietf.org Subject: [jose] POLL: Add Key Usage "both" If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Do we need to add the string "both" as a key usage? Room vote: 1 yes, 11 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:35: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 4446621F8BB4 for ; Wed, 24 Oct 2012 03:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aey-HNVp2is7 for ; Wed, 24 Oct 2012 03:35:47 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id CB08421F8BB2 for ; Wed, 24 Oct 2012 03:35:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 8B4A4270871 for ; Wed, 24 Oct 2012 06:35:47 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 847BE27087A for ; Wed, 24 Oct 2012 06:35:46 -0400 (EDT) Message-ID: <5087C481.90208@isoc.org> Date: Wed, 24 Oct 2012 06:35:45 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B16804296739436687790B@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436687790B@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B16804296739436687790B@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] OPEN: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:35:48 -0000 Folks, The results of this poll were: 7 YES - We need to define a nonce/timestamp parameter in the base specification 1 NO - We do not need to define a nonce/timestamp parameter in the base specification 14 DISCUSS - More discussion is needed Many people discussing this issue commented that the question was underspecified. Based upon these results, I do not believe that a reasonable consensus call is possible on the question as stated. This issue remains open. Please comment on the mailing list and be prepared to resolve in Atlanta. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:05 AM To: jose@ietf.org Subject: [jose] POLL: Nonce/Timestamp parameter If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Do we need to define a nonce/timestamp parameter in the base specification? Room vote: 6 yes, 0 no, 1 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:35: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 67C6F21F8BB2 for ; Wed, 24 Oct 2012 03:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pECAhR97A-0T for ; Wed, 24 Oct 2012 03:35:53 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B621F8A6A for ; Wed, 24 Oct 2012 03:35:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 84C0A270882 for ; Wed, 24 Oct 2012 06:35:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 0351A27087E for ; Wed, 24 Oct 2012 06:35:52 -0400 (EDT) Message-ID: <5087C488.5060509@isoc.org> Date: Wed, 24 Oct 2012 06:35:52 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B1680429673943668778DC@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668778DC@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B1680429673943668778DC@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] OPEN: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:35:54 -0000 Folks, The results of this poll were: 9 YES - all header fields are critical 1 NO - all header fields are non-critical 4 MAYBE - header fields are marked critical or criticality should be defined by the application 3 DISCUSS - need to talk more Based upon these results, I do not believe that a reasonable consensus call is possible yet. This issue remains open. Please comment on the mailing list and be prepared to resolve in (or prior to) Atlanta. Thanks to all who participated in this poll. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:05 AM To: jose@ietf.org Subject: [jose] POLL: Criticality of understanding header fields If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. What should be the criticality of header fields as defined by the core specification? YES - all headers fields are critical NO - all header fields are non-critical MAYBE - header fields are marked critical or criticality should be defined by the application DISCUSS - need to talk more Room vote: 2 yes, 0 no, 4 maybe, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:36: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 AF06621F8B86 for ; Wed, 24 Oct 2012 03:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4P6etkGsTNz for ; Wed, 24 Oct 2012 03:36:02 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 37CFF21F8A6A for ; Wed, 24 Oct 2012 03:36:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id C7D92270871 for ; Wed, 24 Oct 2012 06:36:01 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 3EFAB27087A for ; Wed, 24 Oct 2012 06:36:01 -0400 (EDT) Message-ID: <5087C490.1000706@isoc.org> Date: Wed, 24 Oct 2012 06:36:00 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877956@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877956@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877956@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] OPEN: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:36:02 -0000 Folks, The results of this poll were: 7 YES - SHA1 (and mgf1SHA1) should be the default parameters for these algorithms 2 NO - SHA1 (and mgf1SHA1) should not be the default parameters for these algorithms 4 DISCUSS - More discussion is needed Based upon these results, I do not believe that a reasonable consensus call is possible yet. This issue remains open. Please comment on the mailing list and be prepared to finalize resolution in Atlanta. Thanks to all who participated in this poll. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue Sent: Wednesday, August 29, 2012 2:30 PM To: jose@ietf.org Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Folks, Given the confusion around the original version of this poll, I'd like to try again. The basic question is unchanged, the room count from Vancouver has been corrected, and a clarification regarding the status of SHA1 in the OAEP specification has been added. For those of you who voted and feel you may have misunderstood the question or voted incorrectly, please feel free to update your answer. Question: Should SHA1 (and mgf1SHA1) be the default parameters for these algorithms? Note: These are the default parameters specified in RFC 3447, Section A.2.1, and are widely deployed. Room vote: 5 yes, 0 no, 3 discuss Thanks, Karen _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:41: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 6CC9821F8BCB for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT7U5IpXxOwS for ; Wed, 24 Oct 2012 03:41:47 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id D066B21F8BB2 for ; Wed, 24 Oct 2012 03:41:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6DDA7270867 for ; Wed, 24 Oct 2012 06:35:21 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id BE4F727085A for ; Wed, 24 Oct 2012 06:35:20 -0400 (EDT) Message-ID: <5087C467.1080205@isoc.org> Date: Wed, 24 Oct 2012 06:35:19 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B1680429673943668778F3@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668778F3@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B1680429673943668778F3@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:41:48 -0000 Folks, The results of this poll were: 10 YES - KID is sufficiently defined and understood 2 NO - KID is not sufficiently defined and understood 0 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that KID is sufficiently defined and understood. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:05 AM To: jose@ietf.org Subject: [jose] POLL: Is KID sufficently defined If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Is the current text for KID sufficiently defined and understood? Room vote: 2 yes, 0 no, 1 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:41: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 763DE21F8BCC for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPk84xmfEeD9 for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id ED87F21F8BB4 for ; Wed, 24 Oct 2012 03:41:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 86E4B270877 for ; Wed, 24 Oct 2012 06:35:26 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 0D81D270868 for ; Wed, 24 Oct 2012 06:35:25 -0400 (EDT) Message-ID: <5087C46D.8090905@isoc.org> Date: Wed, 24 Oct 2012 06:35:25 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877975@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877975@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877975@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:41:48 -0000 Folks, The results of this poll were: 1 YES - Support should be mandated to allow an algorithm to be both a string and an object 14 NO - Support should not be mandated to allow an algorithm to be both a string and an object 4 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that support should not be mandated to allow an algorithm to be both a string and an object. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:05 AM To: jose@ietf.org Subject: [jose] POLL: Support Multiple types for algorithms If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should support be mandated to allow an algorithm to be both a string and an object Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"} Room vote: 1 yes, 5 no, 4 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:41: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 DD67421F8BB2 for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvbWJXvBlwG8 for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 47A9221F8BC9 for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id D4DB6270875 for ; Wed, 24 Oct 2012 06:35:38 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 675282707F9 for ; Wed, 24 Oct 2012 06:35:38 -0400 (EDT) Message-ID: <5087C479.6050403@isoc.org> Date: Wed, 24 Oct 2012 06:35:37 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877989@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877989@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877989@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:41:49 -0000 Folks, The results of this poll were: 4 YES - We should add the ability to have a randomly generated MAC key protected by a different key 13 NO - We should not add the ability to have a randomly generated MAC key protected by a different key 4 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that we should not add the ability to have a randomly generated MAC key protected by a different key. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:07 AM To: jose@ietf.org Subject: [jose] POLL: Add other than pre-shared MAC key If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we add the ability to have a randomly generated MAC key protected by a different key? The other key could be either a pre-shared symmetric key or a public key. Room vote: 3 yes, 5 no, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:41: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 0ED4D21F8BB4 for ; Wed, 24 Oct 2012 03:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeA6vXiD8TYg for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5C821F8BCA for ; Wed, 24 Oct 2012 03:41:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 25A352706CB for ; Wed, 24 Oct 2012 06:35:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id A06BD270860 for ; Wed, 24 Oct 2012 06:35:31 -0400 (EDT) Message-ID: <5087C472.30905@isoc.org> Date: Wed, 24 Oct 2012 06:35:30 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366877A1B@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366877A1B@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Forwarded-Message-Id: <4E1F6AAD24975D4BA5B168042967394366877A1B@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] CLOSED: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:41:49 -0000 Folks, The results of this poll were: 18 YES - We should change the current treatment of AES-CBC + HMAC to use a single content encryption name 5 NO - We should not change the current treatment of AES-CBC + HMAC to use a single content encryption name 0 DISCUSS - More discussion is needed Based upon these results, I am making a consensus call that we should change the current treatment of AES-CBC + HMAC to use a single content encryption name. This issue is now closed. Thanks to all who participated in this poll. Karen O'Donoghue (writing as working group co-chair) -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 12:08 AM To: jose@ietf.org Subject: [jose] POLL: Non AEAD algorithms as a single name If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we change the current treatment of AES-CBC + HMAC to use a single content encryption name. Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: {"enc":"AES128CBC+HS256+CS256"} Exact name is still to be determined Room vote: 12 yes, 2 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Wed Oct 24 03:48: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 D9D0121F8BCC for ; Wed, 24 Oct 2012 03:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZnFOyHrjN8K for ; Wed, 24 Oct 2012 03:48:16 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 7088B21F8BCB for ; Wed, 24 Oct 2012 03:48:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 134372708AA for ; Wed, 24 Oct 2012 06:48:16 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 164FA2706BA for ; Wed, 24 Oct 2012 06:48:14 -0400 (EDT) Message-ID: <5087C76D.3040709@isoc.org> Date: Wed, 24 Oct 2012 06:48:13 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] call for agenda items X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:48:17 -0000 Folks, We'll be putting together a draft agenda later today. Here are the documents I've identified as having been updated since Atlanta. These will be on the agenda. Additionally, I would expect some agenda time to resolve the last of the polls from IETF84. Any other agenda time requests? http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-algorithms/ http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-encryption/ http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-key/ http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-signature/ http://tools.ietf.org/id/draft-barnes-jose-use-cases-01.txt http://tools.ietf.org/id/draft-jones-jose-json-private-key-00.txt http://tools.ietf.org/id/draft-jones-jose-jwe-json-serialization-02.txt http://tools.ietf.org/id/draft-jones-jose-jws-json-serialization-02.txt Regards, Karen From Michael.Jones@microsoft.com Wed Oct 24 11:39: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 28D0B21F8783 for ; Wed, 24 Oct 2012 11:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqmwustXO8ed for ; Wed, 24 Oct 2012 11:39:00 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 87FB621F8782 for ; Wed, 24 Oct 2012 11:39:00 -0700 (PDT) Received: from BL2FFO11FD012.protection.gbl (10.173.161.200) by BL2FFO11HUB031.protection.gbl (10.173.161.55) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 24 Oct 2012 18:38:57 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 24 Oct 2012 18:38:57 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 24 Oct 2012 18:38:37 +0000 From: Mike Jones To: "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] call for agenda items Thread-Index: AQHNsdUeaBYzHioP/EOJi2PMT1UcxpfIxZNw Date: Wed, 24 Oct 2012 18:38:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436687B9B6@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <5087C76D.3040709@isoc.org> In-Reply-To: <5087C76D.3040709@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464001)(164054002)(377454001)(47736001)(8716001)(74662001)(44976002)(5343655001)(4396001)(2666001)(47776002)(31966008)(54316001)(54356001)(3846001)(48376001)(53806001)(4196001)(33656001)(20776001)(47976001)(16406001)(16826001)(51856001)(16696001)(50466001)(47446002)(74502001)(1076001)(46102001)(50986001)(49866001)(15202345001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0644578634 Subject: Re: [jose] call for agenda items 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, 24 Oct 2012 18:39:01 -0000 I'll plan to give a brief overview of the changes made to the specs since I= ETF 84. I'd like us to reserve time on the agenda to discuss these topics as well: - Bringing JWS, JWE, JWK, and JWA to working group last call - Adopting the JSON serialization documents as working group documents - Input from the W3C WebCrypto WG on the need for a JSON private key form= at, and whether we want to meet that need Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Wednesday, October 24, 2012 3:48 AM To: jose@ietf.org Subject: [jose] call for agenda items Folks, We'll be putting together a draft agenda later today. Here are the document= s I've identified as having been updated since Atlanta. These will be on th= e agenda. Additionally, I would expect some agenda time to resolve the last= of the polls from IETF84. Any other agenda time requests? http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-algorithms/ http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-encryption/ http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-key/ http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-signature/ http://tools.ietf.org/id/draft-barnes-jose-use-cases-01.txt http://tools.ietf.org/id/draft-jones-jose-json-private-key-00.txt http://tools.ietf.org/id/draft-jones-jose-jwe-json-serialization-02.txt http://tools.ietf.org/id/draft-jones-jose-jws-json-serialization-02.txt Regards, Karen _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ignisvulpis@gmail.com Wed Oct 24 12:55:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C364F21F8964 for ; Wed, 24 Oct 2012 12:55:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DBP8GGeYpSF for ; Wed, 24 Oct 2012 12:55:17 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95321F88C8 for ; Wed, 24 Oct 2012 12:55:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so524108wey.31 for ; Wed, 24 Oct 2012 12:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=GH5a8CeCFUcsVIL1Lqp69JArIJprqMPPCxYIl1GYfi4=; b=hIeifGfC5nN5zD4OyCQFQKv5lH+rWhIU5emI3arPxMZhCbiihHBg8Ydv5EkbHdlR/W dpxTs1rgKkSDDgZ9m5PGWibHlVj3y6SYiaZs4gqvcya0CNKPb3Ft9ogZGOHD2EL+Rbmf +mCsGiPsCD/6nz8LHGdLC6zJmh1mD0XJASKgnAE8g6pXAFoGN/hcOcvviFVN/CYnvwU4 9WFn5/qSnp/dT32e+DaLDjd37cPFv/wwWQXPQ68ViQLPxkcDoRWOFt4ZXTlP9kGoQmjz /YWaNqout4f+MamolD19ODl/F4akyVyynE0Bwp/LhPcodk6Mft7uz9KiTAq57cJT9vjo bIQQ== MIME-Version: 1.0 Received: by 10.180.80.100 with SMTP id q4mr8236434wix.20.1351108516276; Wed, 24 Oct 2012 12:55:16 -0700 (PDT) Received: by 10.216.54.130 with HTTP; Wed, 24 Oct 2012 12:55:16 -0700 (PDT) Date: Wed, 24 Oct 2012 21:55:16 +0200 Message-ID: From: Axel Nennker To: jose@ietf.org Content-Type: multipart/alternative; boundary=f46d044283542a688404ccd3770c Cc: "Michael B. Jones" Subject: [jose] jwk 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, 24 Oct 2012 19:55:18 -0000 --f46d044283542a688404ccd3770c Content-Type: text/plain; charset=ISO-8859-1 I think that having more choices other than (xpo, mod) is useful. I believe that it is easier for me to implement keys in Firefox if I have PEM encoded keys. So the format could be: user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } // PEM encoded public key without linebreaks A more general format would be: jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } This general format could be used for private keys too. What do you think? Axel ps: Don't know whether I can post from this email address.... Mike, would you lease post it if it does appear in your inbox but not on the list. Thanks. --f46d044283542a688404ccd3770c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that having more choices other than (xpo, mod) is useful.
I = believe that it is easier for me to implement keys in Firefox if I have PEM= encoded keys.

So the format could be:

user_jwk : {"pub&= quot;: "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzj= QI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45= Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbK= UXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" }
// PEM encoded public key without linebreaks

A = more general format would be:

jwk: { "-----BEGIN PUBLIC KEY----= -": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtD= zjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45= Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbK= UXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB"
}

This general format could be used for private ke= ys too.

What do you think?

Axel

ps: Don't know whe= ther I can post from this email address.... Mike, would you lease post it i= f it does appear in your inbox but not on the list. Thanks.
--f46d044283542a688404ccd3770c-- From djc.ochtman@gmail.com Wed Oct 24 13:00:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32C121F8A2D for ; Wed, 24 Oct 2012 13:00:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDbAia0KBuWb for ; Wed, 24 Oct 2012 13:00:03 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECA621F8A2A for ; Wed, 24 Oct 2012 13:00:03 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so2943430qao.10 for ; Wed, 24 Oct 2012 13:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9M1E1nesHaMhjkHg06EknGkxTG/M8oV0V3xBHhu4h8o=; b=ZZQfJWJThsb1UMe91q2yecxotQb/FIXgVBatfmFOiSOUo1e8MtjxSw39Qk65+143il r/WoAOtryngCPsa3ug4lXVa+K4jtzfAfajWEbegfNSRxfOq04Qmn/dYZzKir6Ffo/ZcD 7NZD1uhZavARG6fAdQKe8dN/Yc681garTj+bbaIjhVicTrB3Fp8aT4APQ7MT9nXsFgn4 yofmGFmoY0/Hc1udvyX3UrWISmbHFfNozEURMACjg/dlgM5bii5TtawsbqfHD3DsoWxn ClOveKcJqGxbbyvOYRQyzP+YpbI0GCZewR1ScbrxclS9fdhGgoU3NG3tby+nFpwxGGWf zPNw== Received: by 10.224.27.3 with SMTP id g3mr7712136qac.44.1351108802759; Wed, 24 Oct 2012 13:00:02 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.49.97.195 with HTTP; Wed, 24 Oct 2012 12:59:42 -0700 (PDT) In-Reply-To: References: From: Dirkjan Ochtman Date: Wed, 24 Oct 2012 21:59:42 +0200 X-Google-Sender-Auth: tRLrJQJshid8U_0_NI7ER-n5bgk Message-ID: To: Axel Nennker Content-Type: text/plain; charset=UTF-8 Cc: "Michael B. Jones" , jose@ietf.org Subject: Re: [jose] jwk 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, 24 Oct 2012 20:00:03 -0000 On Wed, Oct 24, 2012 at 9:55 PM, Axel Nennker wrote: > I think that having more choices other than (xpo, mod) is useful. > I believe that it is easier for me to implement keys in Firefox if I have > PEM encoded keys. This sounds like the kind of thing discussed in the "Support Multiple types for algorithms" poll, where it was apparently voted out. Cheers, Dirkjan From Michael.Jones@microsoft.com Wed Oct 24 13:15: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 C49D821F88E7 for ; Wed, 24 Oct 2012 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJiUvdEZ94ie for ; Wed, 24 Oct 2012 13:15:31 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id D92A521F86D8 for ; Wed, 24 Oct 2012 13:15:30 -0700 (PDT) Received: from BL2FFO11FD012.protection.gbl (10.173.161.201) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 24 Oct 2012 20:15:22 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 24 Oct 2012 20:15:21 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Wed, 24 Oct 2012 20:14:58 +0000 From: Mike Jones To: Axel Nennker , "jose@ietf.org" Thread-Topic: jwk Thread-Index: AQHNsiF/w0zq/rO+/0GqJ4iKlhRQdpfI5BAg Date: Wed, 24 Oct 2012 20:14:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436687BCEB@TK5EX14MBXC285.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436687BCEBTK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51444002)(47446002)(15202345001)(31966008)(74502001)(74662001)(16826001)(20776001)(16696001)(46102001)(44976002)(8716001)(512954001)(54316001)(54356001)(53806001)(3846001)(47736001)(51856001)(50986001)(1076001)(4396001)(47976001)(4196001)(49866001)(2666001)(16406001)(5343635001)(33656001)(5343655001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0644578634 Subject: Re: [jose] jwk 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, 24 Oct 2012 20:15:31 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436687BCEBTK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To be clear, JWS and JWE already support the use of PEM encoded keys throug= h the "x5c" and "x5u" parameters. Therefore, I don't see any need to also = add X.509-based key formats to JWK itself. -- Mike From: Axel Nennker [mailto:ignisvulpis@gmail.com] Sent: Wednesday, October 24, 2012 12:55 PM To: jose@ietf.org Cc: Mike Jones Subject: jwk I think that having more choices other than (xpo, mod) is useful. I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys. So the format could be: user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgE= oOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGl= NtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4= DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr= 22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREz= Q/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } // PEM encoded public key without linebreaks A more general format would be: jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC= gKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355um= CThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qRE= EIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dl= YKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOa= Jxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } This general format could be used for private keys too. What do you think? Axel ps: Don't know whether I can post from this email address.... Mike, would y= ou lease post it if it does appear in your inbox but not on the list. Thank= s. --_000_4E1F6AAD24975D4BA5B16804296739436687BCEBTK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To be clear, JWS and JWE already support the use = of PEM encoded keys through the "x5c" and "x5u" paramet= ers.  Therefore, I don't see any need to also add X.509-based key form= ats to JWK itself.

 

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

 <= /p>

From: Axel Nen= nker [mailto:ignisvulpis@gmail.com]
Sent: Wednesday, October 24, 2012 12:55 PM
To: jose@ietf.org
Cc: Mike Jones
Subject: jwk

 


I think that having more choices other than (xpo, mod) is useful.
I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys.

So the format could be:

user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC= AQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCTh= N/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qR= EEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk K= X9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB&qu= ot; }
// PEM encoded public key without linebreaks

A more general format would be:

jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQ= EFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ= 3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+= Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeiv= wASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk K= X9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB&qu= ot;
}

This general format could be used for private keys too.

What do you think?

Axel

ps: Don't know whether I can post from this email address.... Mike, would y= ou lease post it if it does appear in your inbox but not on the list. Thank= s.

--_000_4E1F6AAD24975D4BA5B16804296739436687BCEBTK5EX14MBXC285r_-- From mamille2@cisco.com Wed Oct 24 14:13:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A070F21F8BB8 for ; Wed, 24 Oct 2012 14:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.667 X-Spam-Level: X-Spam-Status: No, score=-10.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAM5d9zTzNYH for ; Wed, 24 Oct 2012 14:13:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D7A8F21F8BBE for ; Wed, 24 Oct 2012 14:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4392; q=dns/txt; s=iport; t=1351113217; x=1352322817; h=from:to:subject:date:message-id:mime-version; bh=F84goLlTFhjUUQ08v4uxXs7h9CDA37dKs7mxUhe2cwE=; b=Lq8E0tfC7FOIlRxqffsmcy8vhIEqh7PnmOp7FZlsGoTez+D+2tWRekaI rpWwWY+jHP5MDLA1uolJH6wX50DV3QRUWswlMKU6j+4bm1pOY8SXs9EIE dqSe4fUK4TCSWRodHq3eUVSCZ40fu4HXduYC5Pj1iJjyfzCFazTdt60Z+ Y=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAE9ZiFCtJXG+/2dsb2JhbABEhU28MIEIgiABBBIBeAEqJjAnBBMIBhSHYptCgSugEZFtYQOOdIEglC2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,642,1344211200"; d="p7s'?scan'208";a="135046534" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2012 21:13:36 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9OLDauh024012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Oct 2012 21:13:36 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 16:13:35 -0500 From: "Matt Miller (mamille2)" To: "" Thread-Topic: Support for Wrapped Keys? Thread-Index: AQHNsixtFQh89Wn5MUGS4dRC2YkxtQ== Date: Wed, 24 Oct 2012 21:13:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.62] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--25.746600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_EB5D5783-1CF0-4FFD-A319-1E40E92DA7EB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [jose] Support for Wrapped Keys? 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, 24 Oct 2012 21:13:37 -0000 --Apple-Mail=_EB5D5783-1CF0-4FFD-A319-1E40E92DA7EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a topic that has been discussed some off-list between myself, = Mike Jones, John Bradley, and Nat Sakimura. For XMPP E2E, there is a need to disseminate a "session" master = (symmetric) key between the sender and recipients as a wrapped key. To = date, this is done in a very custom manner by encrypting the session key = with the recipient's public key, and packaging as a partial (read: = broken) JWE value. Ideally, I would like a nice way of handling wrapped keys in JWE. The = more standardized alternatives I can see are: * Follow JWE, using the session key for both the content key and the = content plaintext (feels very awkward) * Follow JWE, generating yet-another-CMK and using the session key as = the content plaintext (feels very wasteful) Does anyone else think this is worth supporting? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. PS: JSMS supports wrapped keys, as does CMS.= --Apple-Mail=_EB5D5783-1CF0-4FFD-A319-1E40E92DA7EB 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyNDIxMTQy MFowIwYJKoZIhvcNAQkEMRYEFAe4uyHgTw1OTR386pMQECYD/CXQMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAhsp7z7ZARYYlQu4JQdOhKR/wljTh2OPUjizrZ6wsesDEn+rhwvxzPvXjY /IMYvYcGHm01KIpMElnxeIDqhDBfvuPYcG8snjxIdfSgYqlHWaOwN1kNdRi9O2VWqmEYZSKiiuwa 2pHdvrv9glRuIKYT9WwKee+HoobJ7wcbf5X5DmvsPpHOAtUZiNDcRMCoRBnUkUflTnVyA5A78094 FhpGOaYMVPCMkLnLRFJk9P8kRimuZTWXOhvn5JNJuTDLYXt5zIwze8wBqzCE+M0A4tKL/CO94kOJ TjJsF5Qwi+wiDAvOpIc+3XIYr+H+rncvIsKMQWa09q2I5BSfk7MZG1oTAAAAAAAA --Apple-Mail=_EB5D5783-1CF0-4FFD-A319-1E40E92DA7EB-- From ignisvulpis@gmail.com Wed Oct 24 14:14: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 6D98C21F85AE for ; Wed, 24 Oct 2012 14:14:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYLF7Y-07cYg for ; Wed, 24 Oct 2012 14:14:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3095A21F8620 for ; Wed, 24 Oct 2012 14:14:22 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so539953wgb.13 for ; Wed, 24 Oct 2012 14:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=35y6uZLHCjPtARwqsmneNWE4ozPYRKjv6UX29z7JMkA=; b=ddMTrYy3OETh+NCiOpDPSjgfF1lpCr9rIEqshDze8EzEHzpGFdqHNJeybfu/3JdDa7 eYRjli36XyvDdywpFWZSzNO01bTpIbQhdkOzWyLnGleQJsMzDFkm3Jw3CMtvKg16ykak 042LD1jpluxe/2buG4bhHS+93LrX7Gxyq2ptfuo/d1VkEPE5GZgZNK/2Q7NwUM7VEBOk Ygwce58+KUXN0cLF5ihidAKfRrkQgKfS1cjdDSU+TRraoYlU/YzOon7zcyCEHC/mdvH1 cnqazMJAALGRlLZ8lnhJ7rlxSF/Wh5nf6uCx9cCcFQSd3oN+WO0ecwPpCNrVJRIgsB8L KgfA== MIME-Version: 1.0 Received: by 10.180.99.133 with SMTP id eq5mr5218447wib.21.1351113261054; Wed, 24 Oct 2012 14:14:21 -0700 (PDT) Received: by 10.216.54.130 with HTTP; Wed, 24 Oct 2012 14:14:20 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436687BCEB@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436687BCEB@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 24 Oct 2012 23:14:20 +0200 Message-ID: From: Axel Nennker To: Mike Jones Content-Type: multipart/alternative; boundary=f46d04428c96f9f95d04ccd491d4 Cc: jose@ietf.org Subject: Re: [jose] jwk 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, 24 Oct 2012 21:14:23 -0000 --f46d04428c96f9f95d04ccd491d4 Content-Type: text/plain; charset=ISO-8859-1 In the case where I generate the keypair on the fly I do not have an URL to put in x5u. And a cert in not a public key. I want bare keys. I don't know how x5u and x5c help here. I have the problem that I don't know how to convert (exp,mod) into a pubkey on one platform (Firefox). I think that PEM is easier. I think the same might be true an other platforms too. Another reason I think that PEM is better is that there are command line tools to produce PEM-encoded keys while I don't know any tool to produce (exp, mod). --Axel 2012/10/24 Mike Jones > To be clear, JWS and JWE already support the use of PEM encoded keys > through the "x5c" and "x5u" parameters. Therefore, I don't see any need to > also add X.509-based key formats to JWK itself.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Axel Nennker [mailto:ignisvulpis@gmail.com] > *Sent:* Wednesday, October 24, 2012 12:55 PM > *To:* jose@ietf.org > *Cc:* Mike Jones > *Subject:* jwk**** > > ** ** > > > I think that having more choices other than (xpo, mod) is useful. > I believe that it is easier for me to implement keys in Firefox if I have > PEM encoded keys. > > So the format could be: > > user_jwk : {"pub": > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI > yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc > n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk > KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" > } > // PEM encoded public key without linebreaks > > A more general format would be: > > jwk: { "-----BEGIN PUBLIC KEY-----": > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI > yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc > n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk > KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" > } > > This general format could be used for private keys too. > > What do you think? > > Axel > > ps: Don't know whether I can post from this email address.... Mike, would > you lease post it if it does appear in your inbox but not on the list. > Thanks.**** > --f46d04428c96f9f95d04ccd491d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the case where I generate the keypair on the fly I do not have an URL to= put in x5u. And a cert in not a public key. I want bare keys.
I don'= ;t know how x5u and x5c help here.

I have the problem that I don'= ;t know how to convert (exp,mod) into a pubkey on one platform (Firefox). I= think that PEM is easier.
I think the same might be true an other platforms too.

Another reaso= n I think that PEM is better is that there are command line tools to produc= e PEM-encoded keys while I don't know any tool to produce (exp, mod).
--Axel

2012/10/24 Mike Jones <Michael.Jones@microsoft.com>

To be clear, JWS and JWE already support the use of PEM encoded keys thr= ough the "x5c" and "x5u" parameters.=A0 Therefore, I do= n't see any need to also add X.509-based key formats to JWK itself.<= /u>

=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=

=A0<= /p>

From: Axel Nen= nker [mailto:ign= isvulpis@gmail.com]
Sent: Wednesday, October 24, 2012 12:55 PM
To: jose@ietf.org=
Cc: Mike Jones
Subject: jwk

=A0


I think that having more choices other than (xpo, mod) is useful.
I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys.

So the format could be:

user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC= AQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCTh= N/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp= 4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zD= zelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" }
// PEM encoded public key without linebreaks

A more general format would be:

jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQ= EFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ= 3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9K= IlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASi= gL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zD= zelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB"
}

This general format could be used for private keys too.

What do you think?

Axel

ps: Don't know whether I can post from this email address.... Mike, wou= ld you lease post it if it does appear in your inbox but not on the list. T= hanks.


--f46d04428c96f9f95d04ccd491d4-- From Michael.Jones@microsoft.com Wed Oct 24 15:04: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 3A37221F8653 for ; Wed, 24 Oct 2012 15:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP9J7Tb6v5mu for ; Wed, 24 Oct 2012 15:04:08 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id 65CBF21F85A6 for ; Wed, 24 Oct 2012 15:04:08 -0700 (PDT) Received: from BL2FFO11FD005.protection.gbl (10.173.161.200) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 24 Oct 2012 22:04:06 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 24 Oct 2012 22:04:05 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 24 Oct 2012 22:03:42 +0000 From: Mike Jones To: "Matt Miller (mamille2)" , "" Thread-Topic: Support for Wrapped Keys? Thread-Index: AQHNsixtFQh89Wn5MUGS4dRC2YkxtZfI+/JA Date: Wed, 24 Oct 2012 22:03:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436687BED7@TK5EX14MBXC285.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(52314002)(13464001)(74662001)(50986001)(2666001)(47736001)(74502001)(49866001)(48376001)(44976002)(4396001)(47976001)(4196001)(1076001)(47446002)(16826001)(3846001)(47776002)(16696001)(31966008)(20776001)(46102001)(16406001)(54356001)(53806001)(51856001)(5343635001)(5343655001)(54316001)(8716001)(33656001)(50466001)(316001)(491001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0644578634 Subject: Re: [jose] Support for Wrapped Keys? 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, 24 Oct 2012 22:04:09 -0000 Per our discussions, there's an approach we could discuss that's very close= to what you're already doing. JWE already has a way to encrypt a key. Th= is key is then currently always used to encrypt the plaintext. One obvious solution then appears to be to have no plaintext and only perfo= rm the first of the two steps - create a JWE Encrypted Key value, leaving t= he JWE Initialization Vector, JWE Ciphertext, and JWE Integrity value field= s empty. The objection that I'm sure people would raise to this obvious solution is = that then the contents of the header and encrypted key are not integrity pr= otected. One potential solution to this would be to use an "enc" algorithm= that only provides integrity but performs no encryption. The most simple such solution would be to use a cryptographic hash function= such as SHA-256 to compute an integrity value over the other fields. You = could look at this as a degenerate AEAD algorithm, accepting an "additional= authenticated data" input and producing an "authentication tag" output, bu= t with no plaintext input or ciphertext output. That would give you an integrity-protected encrypted key, doing the key enc= ryption in the same way that the JWE "alg" values already do. Anyway, hopefully the above will at least seed a productive discussion of t= he possibilities. I do completely understand the value of Matt's use case = and want us to think about how to best solve it. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mat= t Miller (mamille2) Sent: Wednesday, October 24, 2012 2:14 PM To: Subject: [jose] Support for Wrapped Keys? This is a topic that has been discussed some off-list between myself, Mike = Jones, John Bradley, and Nat Sakimura. For XMPP E2E, there is a need to disseminate a "session" master (symmetric)= key between the sender and recipients as a wrapped key. To date, this is = done in a very custom manner by encrypting the session key with the recipie= nt's public key, and packaging as a partial (read: broken) JWE value. Ideally, I would like a nice way of handling wrapped keys in JWE. The more= standardized alternatives I can see are: * Follow JWE, using the session key for both the content key and the conten= t plaintext (feels very awkward) * Follow JWE, generating yet-another-CMK and using the session key as the c= ontent plaintext (feels very wasteful) Does anyone else think this is worth supporting? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. PS: JSMS supports wrapped keys, as does CMS. From Michael.Jones@microsoft.com Sun Oct 28 23:28: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 E01E921F85A5 for ; Sun, 28 Oct 2012 23:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW-jIg+dGVie for ; Sun, 28 Oct 2012 23:28:41 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 165EC21F85B2 for ; Sun, 28 Oct 2012 23:28:40 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.202) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.545.8; Mon, 29 Oct 2012 06:28:38 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Mon, 29 Oct 2012 06:28:38 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Mon, 29 Oct 2012 06:28:16 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObw== Date: Mon, 29 Oct 2012 06:28:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366880D09TK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(69234002)(16826001)(16696001)(1076001)(8716001)(20776001)(54356001)(3846001)(47976001)(51856001)(4196001)(4396001)(46102001)(47736001)(31966008)(44976002)(33656001)(15202345001)(50986001)(5343635001)(47446002)(5343665001)(53806001)(512954001)(49866001)(16406001)(74662001)(54316001)(5343655001)(74502001)(316001)(3556001)(3746001)(6606295001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 064903DDDC Subject: [jose] Platform Support for JWA Crypto Algorithms 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, 29 Oct 2012 06:28:42 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366880D09TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I posted the table describing support for the JWA algorithms in common= Web development platforms that we discussed at IETF 84. See http://self-i= ssued.info/?p=3D884. -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366880D09TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, I posted the table describing support for the <= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS","s= ans-serif";color:#555555"> JWA algorithms in common Web development platforms that we discussed at IET= F 84.  See http://self-issued.info/?p=3D8= 84.

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366880D09TK5EX14MBXC285r_-- From Axel.Nennker@telekom.de Mon Oct 29 06:03:22 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 BF53721F866D for ; Mon, 29 Oct 2012 06:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91FM3EppfoQ6 for ; Mon, 29 Oct 2012 06:03:21 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7398421F866C for ; Mon, 29 Oct 2012 06:03:17 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2012 14:03:09 +0100 Received: from HE113558.emea1.cds.t-internal.com (10.125.65.100) by HE101251.emea1.cds.t-internal.com (10.125.92.154) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 29 Oct 2012 14:03:09 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE113558.emea1.cds.t-internal.com ([2002:7cd:4164::7cd:4164]) with mapi; Mon, 29 Oct 2012 14:03:09 +0100 From: To: , Date: Mon, 29 Oct 2012 14:03:08 +0100 Thread-Topic: Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQ Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40252198DCF55HE111541eme_" MIME-Version: 1.0 Cc: public-webcrypto@w3.org Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 29 Oct 2012 13:03:22 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF40252198DCF55HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As one can see from this table the KDF is unsupported on all platforms (exc= ept one). http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_Al= gorithms.xlsx JWE kdf CS256 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO Isn't this an indication that we should look at alternatives? e.g.: we could generate the integrity protection key randomly instead of de= riving it from the content encryption key. This would add some more bytes (e.g. about 32) to the jwt but is very easy = to implement on all platforms. One way to do it would be to generate enough bytes "Bytes" in "JWE Encrypte= d Key" for encryption and integrity. The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength .. c= ekLength+cikLength-1]" Axel [On some platforms (Firefox/NSS) it might even be nearly impossible to impl= ement (without extending the platform's functions) because the build-in dig= est function is always reset when finalize (doFinal) is called. The spec of= the Concat-KDF says that bytes are generated in a loop but the digest is N= OT reset in the loop.] From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Monday, October 29, 2012 7:28 AM To: jose@ietf.org Subject: [jose] Platform Support for JWA Crypto Algorithms FYI, I posted the table describing support for the JWA algorithms in common= Web development platforms that we discussed at IETF 84. See http://self-i= ssued.info/?p=3D884. -- Mike --_000_CE8995AB5D178F44A2154F5C9A97CAF40252198DCF55HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As one can see from this table the KDF is unsuppo= rted on all platforms (except one).

http= ://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_Algori= thms.xlsx

 

<= td width=3D59 nowrap style=3D'width:44.0pt;border:solid windowtext 1.0pt;bo= rder-left:none;background:#FFC7CE;padding:0cm 5.4pt 0cm 5.4pt;height:15.6pt= '>

NO

<= td width=3D56 nowrap style=3D'width:42.0pt;border:solid windowtext 1.0pt;bo= rder-left:none;background:#FFC7CE;padding:0cm 5.4pt 0cm 5.4pt;height:15.6pt= '>

NO

NO

= <= td width=3D60 nowrap style=3D'width:45.0pt;border-top:none;border-left:none= ;border-bottom:solid black 1.0pt;border-right:solid windowtext 1.0pt;backgr= ound:#D9D9D9;padding:0cm 5.4pt 0cm 5.4pt;height:15.6pt'>

kdf

= Win7

= <= td width=3D60 nowrap style=3D'width:45.0pt;border-top:none;border-left:none= ;border-bottom:solid black 1.0pt;border-right:solid windowtext 1.0pt;backgr= ound:#FFC7CE;padding:0cm 5.4pt 0cm 5.4pt;height:15.6pt'>

NO

= JWE

kdf

CS256<= /span>

Concat Key Derivation Function (KDF)<= o:p>

NO

Win7

 

 

NO

NO<= /span>

NO

NO

NO

NO

NO

 

NO

NO

= JWE

kdf

CS384

Concat Key Derivation Function (KDF)

<= span style=3D'color:#006100'>Win7

 

 

NO

NO

NO

NO

NO

NO

= NO

NO<= /o:p>

 

NO

NO

NO

JWE

CS512

Concat Key Derivation Function (KDF)<= /p>

NO

 

 

NO<= o:p>

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

 

Isn’t this an indicati= on that we should look at alternatives?

 

e.g.: we c= ould generate the integrity protection key randomly instead of deriving it = from the content encryption key.

= This would add some more bytes (e= .g. about 32) to the jwt but is very easy to implement on all platforms.

 

On=
e way to do it would be to generate enough bytes “Bytes” in =
220;JWE Encrypted Key” for encryption and integrity.
The CEK is th=
en “Bytes[0 .. cekLength-1]” and the CIK “Bytes[cekLength=
 .. cekLength+cikLength-1]”

 

 

 

[On some platforms (Firefox/NSS) it might e= ven be nearly impossible to implement (without extending the platform’= ;s functions) because the build-in digest function is always reset when fin= alize (doFinal) is called. The spec of the Concat-KDF says that bytes are g= enerated in a loop but the digest is NOT reset in the loop.]

=  

<= o:p> 

From: jose-boun= ces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones<= br>Sent: Monday, October 29, 2012 7:28 AM
To: jose@ietf.or= g
Subject: [jose] Platform Support for JWA Crypto Algorithms=

 

FYI, I posted the table describing support for the JWA algorithms in common Web development platforms that we discussed a= t IETF 84.  See http://se= lf-issued.info/?p=3D884.

 

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

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF40252198DCF55HE111541eme_-- From dick.hardt@gmail.com Mon Oct 29 08:57:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB1821F8745 for ; Mon, 29 Oct 2012 08:57:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7XfEBIxdgOC for ; Mon, 29 Oct 2012 08:57:20 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC321F8738 for ; Mon, 29 Oct 2012 08:57:19 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2419969dan.31 for ; Mon, 29 Oct 2012 08:57:19 -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:message-id:date :to:mime-version:x-mailer; bh=L5THid73l+7zHEzehEcfZ3wlB+rMXUk2/iU+k+6EhmY=; b=Ff3emHVBdifkuSVgBGONTMxX8pEpHQSJ5WjOLoatOQm7S9ZcNE+GD7hgku1p+i3I/v vu+cYhG4cUfOkNsqmb+pFynwoGfbxZCuR+4XwAv6Jzx2LweFG4MUOPYcHrDpNe0/tihn aJ+OY1KkbFNSD9zcKpg3xlCj0TMtNpqFJqWS9hruiJeJvV8nGyRRlagTCH0BaaqVPiRe /Jt9R0h22z2Xh877f+t9rhNb5R2fd+CrrKqPnGpCjIyxbfQ8TFjkj3O4Gr2UlQRt6eoh jh1PQt0iqinEmq+4SET3v91TTlC1+vwOhmMiwUcZyc+XNjCCj146Fc7axGcXiWQK77jk 5fmA== Received: by 10.66.88.197 with SMTP id bi5mr83964113pab.58.1351526239756; Mon, 29 Oct 2012 08:57:19 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id a4sm5789604pax.12.2012.10.29.08.57.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 08:57:14 -0700 (PDT) From: Dick Hardt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 29 Oct 2012 08:57:11 -0700 To: jose@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [jose] signing an existing JWT 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, 29 Oct 2012 15:57:20 -0000 Let's say we have created a JWE as such: =09 = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne This is now the payload to a JWS. Rather than increasing the token size = by 4/3 by URL safe base 64 encoding the payload (since it is already URL = safe), it would be useful to have a JWS header parameter that indicates = the payload was not re-encoded and does not need to be URL safe base 64 = decoded. As there are more periods than expected in a JWS, decoding would ignore = all periods except the first and last one for separating out the header, = payload and signature. The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate. -- Dick From Michael.Jones@microsoft.com Mon Oct 29 09:25: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 31D1C21F8718 for ; Mon, 29 Oct 2012 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUpfp5Qo8erm for ; Mon, 29 Oct 2012 09:25:42 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id DE86821F86C3 for ; Mon, 29 Oct 2012 09:25:41 -0700 (PDT) Received: from BY2FFO11FD006.protection.gbl (10.1.15.201) by BY2FFO11HUB013.protection.gbl (10.1.14.85) with Microsoft SMTP Server (TLS) id 15.0.545.8; Mon, 29 Oct 2012 16:25:39 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Mon, 29 Oct 2012 16:25:38 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 29 Oct 2012 16:25:13 +0000 From: Mike Jones To: "Axel.Nennker@telekom.de" , "jose@ietf.org" Thread-Topic: Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsA= Date: Mon, 29 Oct 2012 16:25:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436688123ATK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(69234002)(377454001)(4196001)(16406001)(49866001)(5343665001)(8716001)(5343655001)(53806001)(4396001)(51856001)(512954001)(3846001)(47446002)(5343635001)(74502001)(15202345001)(74662001)(31966008)(54316001)(20776001)(1076001)(33656001)(50986001)(47736001)(16696001)(16826001)(46102001)(54356001)(44976002)(47976001)(316001)(6606295001)(3556001)(550254004)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 064903DDDC Cc: "public-webcrypto@w3.org" Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 29 Oct 2012 16:25:44 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436688123ATK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, Concat often isn't natively supported, but it's very easy to implement = given implementations of SHA-256 and SHA-512, as shown in http://tools.ietf= .org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://to= ols.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5. When the table was discussed at the WebCrypto F2F, it was pointed out that = a shortcoming of the current table is that it doesn't indicate which of the= "NO" values are effectively show-stoppers and which are easy to build impl= ementations of, and so not a problem in practice. As shown in the appendic= es, I believe that Concat is in the latter category. Given the ease of imp= lementation, it's certainly not worth adding space to the JWEs to work arou= nd. -- Mike From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] Sent: Monday, October 29, 2012 6:03 AM To: Mike Jones; jose@ietf.org Cc: public-webcrypto@w3.org Subject: RE: Platform Support for JWA Crypto Algorithms As one can see from this table the KDF is unsupported on all platforms (exc= ept one). http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_Al= gorithms.xlsx JWE kdf CS256 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO Isn't this an indication that we should look at alternatives? e.g.: we could generate the integrity protection key randomly instead of de= riving it from the content encryption key. This would add some more bytes (e.g. about 32) to the jwt but is very easy = to implement on all platforms. One way to do it would be to generate enough bytes "Bytes" in "JWE Encrypte= d Key" for encryption and integrity. The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength .. c= ekLength+cikLength-1]" Axel [On some platforms (Firefox/NSS) it might even be nearly impossible to impl= ement (without extending the platform's functions) because the build-in dig= est function is always reset when finalize (doFinal) is called. The spec of= the Concat-KDF says that bytes are generated in a loop but the digest is N= OT reset in the loop.] From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Monday, October 29, 2012 7:28 AM To: jose@ietf.org Subject: [jose] Platform Support for JWA Crypto Algorithms FYI, I posted the table describing support for the JWA algorithms in common= Web development platforms that we discussed at IETF 84. See http://self-i= ssued.info/?p=3D884. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436688123ATK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, Concat often isn&#= 8217;t natively supported, but it’s very easy to implement given impl= ementations of SHA-256 and SHA-512, as shown in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-= A.4 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-= A.5.

 

When the table was dis= cussed at the WebCrypto F2F, it was pointed out that a shortcoming of the c= urrent table is that it doesn’t indicate which of the “NO”= ; values are effectively show-stoppers and which are easy to build implementations of, and so not a problem in practice.  As sh= own in the appendices, I believe that Concat is in the latter category.&nbs= p; Given the ease of implementation, it’s certainly not worth adding = space to the JWEs to work around.

 

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

 

From: Axel.Nen= nker@telekom.de [mailto:Axel.Nennker@telekom.de]
Sent: Monday, October 29, 2012 6:03 AM
To: Mike Jones; jose@ietf.org
Cc: public-webcrypto@w3.org
Subject: RE: Platform Support for JWA Crypto Algorithms

 

= As one can see from this table the KDF is unsupported on all platforms (exc= ept one).

= http://self-issued.info/presentations/Platform_Su= pport_for_JWA-04_Crypto_Algorithms.xlsx

=  

JWE

kdf

CS256

Concat Key Derivation Function (KDF= )

NO

Win7=

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

NO

JWE

kdf

CS384

Concat Key Derivation Function (KDF= )

NO

Win7=

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

NO

JWE

kdf

CS512

Concat Key Derivation Function (KDF= )

NO

Win7=

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

NO

=  

= Isn’t this an indication that we should look at alternatives?

=  

= e.g.: we could generate the integrity protection key randomly instead of de= riving it from the content encryption key.

= This would add some more bytes (e.g. about 32) to the jwt but is very easy = to implement on all platforms.

=  

One way to do it would be to generate=
 enough bytes “Bytes” in “JWE Encrypted Key” for en=
cryption and integrity.
The CEK is then “Bytes[0 .. cekLength-1]&#=
8221; and the CIK “Bytes[cekLength .. cekLength+cikLength-1]̶=
1;

=  

=  

= Axel

=  

= [On some platforms (Firefox/NSS) it might even be nearly impossible to impl= ement (without extending the platform’s functions) because the build-= in digest function is always reset when finalize (doFinal) is called. The spec of the Concat-KDF says that bytes are generated in a l= oop but the digest is NOT reset in the loop.]

=  

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, October 29, 2012 7:28 AM
To: jose@ietf.org
Subject: [jose] Platform Support for JWA Crypto Algorithms

 

FYI, I posted the table describing support for the <= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS","s= ans-serif";color:#555555"> JWA algorithms in common Web development platforms that we discussed at IET= F 84.  See http://self-issued.info/?p=3D8= 84.

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436688123ATK5EX14MBXC285r_-- From Axel.Nennker@telekom.de Mon Oct 29 13:46: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 D759521F8735 for ; Mon, 29 Oct 2012 13:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WigCQYPCSz93 for ; Mon, 29 Oct 2012 13:46:32 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 57F3621F8737 for ; Mon, 29 Oct 2012 13:46:30 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2012 21:46:28 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Mon, 29 Oct 2012 21:46:27 +0100 From: To: , Date: Mon, 29 Oct 2012 21:46:26 +0100 Thread-Topic: Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsAACDLiIA== Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40252199B9114HE111541eme_" MIME-Version: 1.0 Cc: public-webcrypto@w3.org Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 29 Oct 2012 20:46:36 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF40252199B9114HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ease of implementation is relative. Maybe tomorrow I will discover that the= needed concat-KDF is supported "natively" by Mozilla's NSS library. Then i= t is very easy. Currently it looks difficult on that platform because the documentation say= s that the digest function "finish" resets the digest, which would probably= lead to different results than in the examples in the appendices A4 and A5= . " http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330= d1ac9e69aafc30f71ba35da74e NOTE: This method may be called any time after |init| is called. This call = resets the object to its pre-init state. " I still think that some thirty bytes is not much and that generating the CI= K randomly is much easier. I implemented the concat-kdf in java https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto= /crypto/KDFConcatGenerator.java and I know that implementing my proposal be= low is easier. Anyway: One could ask why the concat-KDF is not implemented in Bouncycastle= while three other KDFs are implemented there. Mozilla implements KDFs too: https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/pk= 11skey.c#1437 Although there is no indication in the code which KDF this implements. Mayb= e a Mozillian on these lists can clarify. If it is a KDF that is implemented in Bouncycastle too then I suggest to ch= ange the default KDF in JWE to that one. The implementation of KDF can lead to buffer overflows is no secret: https://bugzilla.mozilla.org/show_bug.cgi?id=3D617565 Which means that KeyDerivationFunction implementation is not as easy as it = could be. Why do you think that the list of NIST's crypto implementations lists all a= lgs except KDF? http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.html NIST defines other KDFs too. Why is JWE using one that is implemented nowhe= re? Any other choice that is implemented on two platforms is a better choic= e than concat-kdf I think. Axel http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1= ac9e69aafc30f71ba35da74e NOTE: This method may be called any time after |init| is called. This call = resets the object to its pre-init state. From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, October 29, 2012 5:25 PM To: Nennker, Axel; jose@ietf.org Cc: public-webcrypto@w3.org Subject: RE: Platform Support for JWA Crypto Algorithms No, Concat often isn't natively supported, but it's very easy to implement = given implementations of SHA-256 and SHA-512, as shown in http://tools.ietf= .org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://to= ols.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5. When the table was discussed at the WebCrypto F2F, it was pointed out that = a shortcoming of the current table is that it doesn't indicate which of the= "NO" values are effectively show-stoppers and which are easy to build impl= ementations of, and so not a problem in practice. As shown in the appendic= es, I believe that Concat is in the latter category. Given the ease of imp= lementation, it's certainly not worth adding space to the JWEs to work arou= nd. -- Mike From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] Sent: Monday, October 29, 2012 6:03 AM To: Mike Jones; jose@ietf.org Cc: public-webcrypto@w3.org Subject: RE: Platform Support for JWA Crypto Algorithms As one can see from this table the KDF is unsupported on all platforms (exc= ept one). http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_Al= gorithms.xlsx JWE kdf CS256 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO Isn't this an indication that we should look at alternatives? e.g.: we could generate the integrity protection key randomly instead of de= riving it from the content encryption key. This would add some more bytes (e.g. about 32) to the jwt but is very easy = to implement on all platforms. One way to do it would be to generate enough bytes "Bytes" in "JWE Encrypte= d Key" for encryption and integrity. The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength .. c= ekLength+cikLength-1]" Axel [On some platforms (Firefox/NSS) it might even be nearly impossible to impl= ement (without extending the platform's functions) because the build-in dig= est function is always reset when finalize (doFinal) is called. The spec of= the Concat-KDF says that bytes are generated in a loop but the digest is N= OT reset in the loop.] From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Monday, October 29, 2012 7:28 AM To: jose@ietf.org Subject: [jose] Platform Support for JWA Crypto Algorithms FYI, I posted the table describing support for the JWA algorithms in common= Web development platforms that we discussed at IETF 84. See http://self-i= ssued.info/?p=3D884. -- Mike --_000_CE8995AB5D178F44A2154F5C9A97CAF40252199B9114HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ease of implementation is relative. Maybe tomorrow I will dis= cover that the needed concat-KDF is supported “natively” by Moz= illa’s NSS library. Then it is very easy.

Currently it looks difficult o= n that platform because the documentation says that the digest function = 220;finish” resets the digest, which would probably lead to different= results than in the examples in the appendices A4 and A5.

“ http://doxygen.db48x.net/mozilla/html/interfacens= ICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e

NOTE: This method may be called any time after |init|= is called. This call resets the object to its pre-init state.

”

I still think that some thirty bytes is not much an= d that generating the CIK randomly is much easier. I implemented the concat= -kdf in java

https://code.google.= com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/crypto/KDFConcatGen= erator.java and I know that implementing my proposal below is easier.

Anyw= ay: One could ask why the concat-KDF is not implemented in Bouncycastle whi= le three other KDFs are implemented there.

Mozilla implements KDFs too:

https://mxr.mozilla.org/mozilla-central/source/security/= nss/lib/pk11wrap/pk11skey.c#1437

Although there is no indication in the co= de which KDF this implements. Maybe a Mozillian on these lists can clarify.=

If= it is a KDF that is implemented in Bouncycastle too then I suggest to chan= ge the default KDF in JWE to that one.

 

The implementation of KDF can lead = to buffer overflows is no secret:

https://bugzilla.mozilla.org/show_bug.cgi?id=3D617565=

Which means that KeyDerivationFunction implementation is not as easy as = it could be.

 

Why do you think that the list of NIST’s crypto impleme= ntations lists all algs except KDF?

http://csrc.nist.gov/groups/S= TM/cavp/documents/components/componentval.html

 

NIST defines other KDFs= too. Why is JWE using one that is implemented nowhere? Any other choice th= at is implemented on two platforms is a better choice than concat-kdf I thi= nk.

 

Axel

 

http://doxygen.db48x.net/mo= zilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e

NOTE: This method may be called= any time after |init| is called. This call resets the object to its pre-in= it state.

 

 

No, Concat often isn’t natively supported, b= ut it’s very easy to implement given implementations of SHA-256 and S= HA-512, as shown in http://tools.ietf.org/html/draft-ietf-j= ose-json-web-encryption-06#appendix-A.4 and http://tool= s.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5.

=  

W= hen the table was discussed at the WebCrypto F2F, it was pointed out that a= shortcoming of the current table is that it doesn’t indicate which o= f the “NO” values are effectively show-stoppers and which are e= asy to build implementations of, and so not a problem in practice.  As= shown in the appendices, I believe that Concat is in the latter category.&= nbsp; Given the ease of implementation, it’s certainly not worth addi= ng space to the JWEs to work around.

 

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

 

From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] <= br>Sent: Monday, October 29, 2012 6:03 AM
To: Mike Jones; = jose@ietf.org
Cc: public-webcrypto@w3.org
Subject: RE: = Platform Support for JWA Crypto Algorithms

 

As one can see from this table the KDF is un= supported on all platforms (except one).

http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_A= lgorithms.xlsx

 

<= td width=3D61 nowrap style=3D'width:46.0pt;border-top:none;border-left:none= ;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;b= ackground:#FFC7CE;padding:0cm 5.4pt 0cm 5.4pt;height:15.6pt'>

NO

= <= td width=3D60 nowrap style=3D'width:45.0pt;border-top:none;border-left:none= ;border-bottom:solid black 1.0pt;border-right:solid windowtext 1.0pt;backgr= ound:#D9D9D9;padding:0cm 5.4pt 0cm 5.4pt;height:15.6pt'>

kdf

= Win7

= <= td width=3D60 nowrap style=3D'width:45.0pt;border-top:none;border-left:none= ;border-bottom:solid black 1.0pt;border-right:solid windowtext 1.0pt;backgr= ound:#FFC7CE;padding:0cm 5.4pt 0cm 5.4pt;height:15.6pt'>

NO

JWE

kdf

CS256

Concat Key Derivation Function (= KDF)

NO

Win7

<= span style=3D'color:black'> 

 

NO

NO

NO

NO=

NO

NO

NO

= NO

 

NO

NO

NO<= /span>

JWE

kdf

=

CS384

Concat Key Derivation Function (KDF)

<= span style=3D'color:#006100'>Win7

 

 

NO

NO

NO

NO

NO

NO

= NO

NO<= /o:p>

 

NO

NO

NO

JWE

CS512

Concat Key Derivation Function (KDF)<= /p>

NO

 

 

NO<= o:p>

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

 

Isn’t this an indicati= on that we should look at alternatives?

 

e.g.: we c= ould generate the integrity protection key randomly instead of deriving it = from the content encryption key.

= This would add some more bytes (e= .g. about 32) to the jwt but is very easy to implement on all platforms.

 

On=
e way to do it would be to generate enough bytes “Bytes” in =
220;JWE Encrypted Key” for encryption and integrity.
The CEK is th=
en “Bytes[0 .. cekLength-1]” and the CIK “Bytes[cekLength=
 .. cekLength+cikLength-1]”

 

 

 

[On some platforms (Firefox/NSS) it might e= ven be nearly impossible to implement (without extending the platform’= ;s functions) because the build-in digest function is always reset when fin= alize (doFinal) is called. The spec of the Concat-KDF says that bytes are g= enerated in a loop but the digest is NOT reset in the loop.]

=  

<= o:p> 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf O= f Mike Jones
Sent: Monday, October 29, 2012 7:28 AM
To:= jose@ietf.org
Subject: = [jose] Platform Support for JWA Crypto Algorithms

 

FYI,= I posted the table describing support for the JWA algorithms i= n common Web development platforms that we discussed at IETF 84.  See = http://self-issued.info/?p=3D8= 84.

 

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

 

<= /html>= --_000_CE8995AB5D178F44A2154F5C9A97CAF40252199B9114HE111541eme_-- From Michael.Jones@microsoft.com Mon Oct 29 15:05: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 0A04821F8654 for ; Mon, 29 Oct 2012 15:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-I6xJ6dV6iK for ; Mon, 29 Oct 2012 15:05:49 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 24FD521F8647 for ; Mon, 29 Oct 2012 15:05:48 -0700 (PDT) Received: from BY2FFO11FD006.protection.gbl (10.1.15.204) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.545.8; Mon, 29 Oct 2012 22:05:43 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Mon, 29 Oct 2012 22:05:43 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 29 Oct 2012 22:05:06 +0000 From: Mike Jones To: Axel Nennker Thread-Topic: jwk Thread-Index: AQHNsiF/w0zq/rO+/0GqJ4iKlhRQdpfI5BAggAAQvQCAB5mvgA== Date: Mon, 29 Oct 2012 22:05:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668828D9@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436687BCEB@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668828D9TK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51444002)(479174001)(5343655001)(15202345001)(74662001)(8716001)(512954001)(51856001)(44976002)(16696001)(54356001)(33656001)(31966008)(54316001)(74502001)(550184003)(53806001)(47446002)(16826001)(2666001)(1411001)(1076001)(49866001)(4396001)(16406001)(20776001)(50986001)(46102001)(5343635001)(4196001)(47736001)(47976001)(3846001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 064903DDDC Cc: "jose@ietf.org" Subject: Re: [jose] jwk 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, 29 Oct 2012 22:05:51 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668828D9TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "x5c" helps because you can represent a bare key as a self-signed cert in P= EM format in the "x5c" parameter. The JOSE specs already support PEM-encod= ed keys. -- Mike From: Axel Nennker [mailto:ignisvulpis@gmail.com] Sent: Wednesday, October 24, 2012 2:14 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: jwk In the case where I generate the keypair on the fly I do not have an URL to= put in x5u. And a cert in not a public key. I want bare keys. I don't know how x5u and x5c help here. I have the problem that I don't know how to convert (exp,mod) into a pubkey= on one platform (Firefox). I think that PEM is easier. I think the same might be true an other platforms too. Another reason I think that PEM is better is that there are command line to= ols to produce PEM-encoded keys while I don't know any tool to produce (exp= , mod). --Axel 2012/10/24 Mike Jones > To be clear, JWS and JWE already support the use of PEM encoded keys throug= h the "x5c" and "x5u" parameters. Therefore, I don't see any need to also = add X.509-based key formats to JWK itself. -- Mike From: Axel Nennker [mailto:ignisvulpis@gmail.com] Sent: Wednesday, October 24, 2012 12:55 PM To: jose@ietf.org Cc: Mike Jones Subject: jwk I think that having more choices other than (xpo, mod) is useful. I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys. So the format could be: user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgE= oOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGl= NtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4= DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr= 22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREz= Q/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } // PEM encoded public key without linebreaks A more general format would be: jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC= gKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355um= CThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qRE= EIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dl= YKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOa= Jxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } This general format could be used for private keys too. What do you think? Axel ps: Don't know whether I can post from this email address.... Mike, would y= ou lease post it if it does appear in your inbox but not on the list. Thank= s. --_000_4E1F6AAD24975D4BA5B1680429673943668828D9TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“x5c” helps b= ecause you can represent a bare key as a self-signed cert in PEM format in = the “x5c” parameter.  The JOSE specs already support PEM-e= ncoded keys.

 <= /p>

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

 <= /p>

From: Axel Nen= nker [mailto:ignisvulpis@gmail.com]
Sent: Wednesday, October 24, 2012 2:14 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: jwk

 

In the case where I g= enerate the keypair on the fly I do not have an URL to put in x5u. And a ce= rt in not a public key. I want bare keys.
I don't know how x5u and x5c help here.

I have the problem that I don't know how to convert (exp,mod) into a pubkey= on one platform (Firefox). I think that PEM is easier.
I think the same might be true an other platforms too.

Another reason I think that PEM is better is that there are command line to= ols to produce PEM-encoded keys while I don't know any tool to produce (exp= , mod).

--Axel

2012/10/24 Mike Jones <Michael.Jones@microsoft.com><= o:p>

To be clear, JWS and JWE already support the use of PEM encoded keys thr= ough the "x5c" and "x5u" parameters.  Therefore, I= don't see any need to also add X.509-based key formats to JWK itself.=

 

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

 

From: Axel Nennker [mailto:<= a href=3D"mailto:ignisvulpis@gmail.com" target=3D"_blank">ignisvulpis@gmail= .com]
Sent: Wednesday, October 24, 2012 12:55 PM
To: jose@ietf.org=
Cc: Mike Jones
Subject: jwk

 


I think that having more choices other than (xpo, mod) is useful.
I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys.

So the format could be:

user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC= AQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCTh= N/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qR= EEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk K= X9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB&qu= ot; }
// PEM encoded public key without linebreaks

A more general format would be:

jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQ= EFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ= 3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+= Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeiv= wASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk K= X9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB&qu= ot;
}

This general format could be used for private keys too.

What do you think?

Axel

ps: Don't know whether I can post from this email address.... Mike, would y= ou lease post it if it does appear in your inbox but not on the list. Thank= s.

 

--_000_4E1F6AAD24975D4BA5B1680429673943668828D9TK5EX14MBXC285r_-- From mamille2@cisco.com Mon Oct 29 15:16: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 24D2C21F86EB for ; Mon, 29 Oct 2012 15:16:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKASZrGTpCI1 for ; Mon, 29 Oct 2012 15:16:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B338021F84FB for ; Mon, 29 Oct 2012 15:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10147; q=dns/txt; s=iport; t=1351548971; x=1352758571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dKATCy+nt9tPghxqRaErfw6vEPqVuzd6nAtYLwFoWFc=; b=UNyQiv5ILQUFcLc3KVoErHApMVGj2i6/1LIOc355O8bQ/o5Zy3DcrmFw YEq1nyddbbPNXfNN8z1CjAEsrigDD24C4wTUYrZb5pp5FLw+8WPE/XHDu IywW+jfkWfBPt0UKTZDQHx/Swik98wKO+cqMiRCelSwV3DnzbOgcQcrte w=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOv+jlCtJV2Z/2dsb2JhbABEwwmBCIIeAQEBAwEBAQEPAVsLBQsCAQgRBAEBCx0HAiULFAkIAQEEDgUIBhSHXgYLnAiff4t1hAOBeWEDjnSBIYZ5jT2Ba4JiDYIZ X-IronPort-AV: E=Sophos;i="4.80,675,1344211200"; d="p7s'?scan'208";a="136640493" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2012 22:16:11 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9TMGBP7021964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 22:16:11 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 17:16:10 -0500 From: "Matt Miller (mamille2)" To: " " Thread-Topic: [jose] Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsAACDLiIAAO0JKA Date: Mon, 29 Oct 2012 22:16:10 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.62] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004 x-tm-as-result: No--37.865600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_EC4A02AA-8B30-4776-9E1B-7BB60503AAAF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 29 Oct 2012 22:16:13 -0000 --Apple-Mail=_EC4A02AA-8B30-4776-9E1B-7BB60503AAAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 29, 2012, at 2:46 PM, wrote: > Ease of implementation is relative. Maybe tomorrow I will discover = that the needed concat-KDF is supported "natively" by Mozilla's NSS = library. Then it is very easy. > Currently it looks difficult on that platform because the = documentation says that the digest function "finish" resets the digest, = which would probably lead to different results than in the examples in = the appendices A4 and A5. > " = http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d= 1ac9e69aafc30f71ba35da74e > NOTE: This method may be called any time after |init| is called. This = call resets the object to its pre-init state. > " > I still think that some thirty bytes is not much and that generating = the CIK randomly is much easier. I implemented the concat-kdf in java > = https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypt= o/crypto/KDFConcatGenerator.java and I know that implementing my = proposal below is easier. > Anyway: One could ask why the concat-KDF is not implemented in = Bouncycastle while three other KDFs are implemented there. > Mozilla implements KDFs too: > = https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/p= k11skey.c#1437 > Although there is no indication in the code which KDF this implements. = Maybe a Mozillian on these lists can clarify. > If it is a KDF that is implemented in Bouncycastle too then I suggest = to change the default KDF in JWE to that one. >=20 > The implementation of KDF can lead to buffer overflows is no secret: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D617565 > Which means that KeyDerivationFunction implementation is not as easy = as it could be. >=20 > Why do you think that the list of NIST's crypto implementations lists = all algs except KDF? > = http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.htm= l >=20 > NIST defines other KDFs too. Why is JWE using one that is implemented = nowhere? Any other choice that is implemented on two platforms is a = better choice than concat-kdf I think. >=20 To add more fuel to the fire: I've seen PBKDF2 is implemented in a few = places, and I think it's only slightly harder to implement as concatKDF. However, I still think just requiring a larger key is the easiest, least = error-prone approach. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > Axel >=20 > = http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d= 1ac9e69aafc30f71ba35da74e > NOTE: This method may be called any time after |init| is called. This = call resets the object to its pre-init state. >=20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, October 29, 2012 5:25 PM > To: Nennker, Axel; jose@ietf.org > Cc: public-webcrypto@w3.org > Subject: RE: Platform Support for JWA Crypto Algorithms >=20 > No, Concat often isn't natively supported, but it's very easy to = implement given implementations of SHA-256 and SHA-512, as shown in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix= -A.4 and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix= -A.5. >=20 > When the table was discussed at the WebCrypto F2F, it was pointed out = that a shortcoming of the current table is that it doesn't indicate = which of the "NO" values are effectively show-stoppers and which are = easy to build implementations of, and so not a problem in practice. As = shown in the appendices, I believe that Concat is in the latter = category. Given the ease of implementation, it's certainly not worth = adding space to the JWEs to work around. >=20 > -- Mike >=20 > From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] > Sent: Monday, October 29, 2012 6:03 AM > To: Mike Jones; jose@ietf.org > Cc: public-webcrypto@w3.org > Subject: RE: Platform Support for JWA Crypto Algorithms >=20 > As one can see from this table the KDF is unsupported on all platforms = (except one). > = http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_A= lgorithms.xlsx >=20 > JWE >=20 > kdf >=20 > CS256 >=20 > Concat Key Derivation Function (KDF) >=20 > NO >=20 > Win7 >=20 >=20 >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > JWE >=20 > kdf >=20 > CS384 >=20 > Concat Key Derivation Function (KDF) >=20 > NO >=20 > Win7 >=20 >=20 >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > JWE >=20 > kdf >=20 > CS512 >=20 > Concat Key Derivation Function (KDF) >=20 > NO >=20 > Win7 >=20 >=20 >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 >=20 > Isn't this an indication that we should look at alternatives? >=20 > e.g.: we could generate the integrity protection key randomly instead = of deriving it from the content encryption key. > This would add some more bytes (e.g. about 32) to the jwt but is very = easy to implement on all platforms. >=20 >=20 > One way to do it would be to generate enough bytes "Bytes" in "JWE = Encrypted Key" for encryption and integrity. > The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength = .. cekLength+cikLength-1]" >=20 >=20 > Axel >=20 > [On some platforms (Firefox/NSS) it might even be nearly impossible to = implement (without extending the platform's functions) because the = build-in digest function is always reset when finalize (doFinal) is = called. The spec of the Concat-KDF says that bytes are generated in a = loop but the digest is NOT reset in the loop.] >=20 >=20 > From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Monday, October 29, 2012 7:28 AM > To: jose@ietf.org > Subject: [jose] Platform Support for JWA Crypto Algorithms >=20 > FYI, I posted the table describing support for the JWA algorithms in = common Web development platforms that we discussed at IETF 84. See = http://self-issued.info/?p=3D884. >=20 > -- Mike >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_EC4A02AA-8B30-4776-9E1B-7BB60503AAAF 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyOTIyMTYy MFowIwYJKoZIhvcNAQkEMRYEFGX+drBEtUsRp21kgKJxrDF71PJlMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAjILm2DHVh2sda6JcBkMzmCaG5dbSbz4K+b6Pk+V9o3tEEBBCYLqgtjMIN w6TCazBv1bDcVJ5MDvUZLDONW5kSK8Tnt9zg0JvrwGKAokMdLnH/KhM6UYeQ+YwwiHe7MmZISUw1 zL2JHW8UZkE43IO6IUnJv0qfdpaPL/lzlM9IIAS40ghvsqIwV4v16oAybLprJltWfBvBj6Y5lvYi 4R+gDwXawFwOvyHDm5y1BuxELKPgzBe/J7Yk1g8shNAEZQRL4j0CzmSAJeH8JokHsnfrmufzdos9 ur5TeSma84Df65LgfNMLHD9uvGpsaoA55NedJVVdB6s2lvwfJen0D2b7AAAAAAAA --Apple-Mail=_EC4A02AA-8B30-4776-9E1B-7BB60503AAAF-- From Michael.Jones@microsoft.com Mon Oct 29 15:24: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 9799121F8647 for ; Mon, 29 Oct 2012 15:24:50 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UmvLad8PuDu for ; Mon, 29 Oct 2012 15:24:49 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id 307AF21F8646 for ; Mon, 29 Oct 2012 15:24:48 -0700 (PDT) Received: from BY2FFO11FD001.protection.gbl (10.1.15.200) by BY2FFO11HUB009.protection.gbl (10.1.14.167) with Microsoft SMTP Server (TLS) id 15.0.545.8; Mon, 29 Oct 2012 22:24:39 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Mon, 29 Oct 2012 22:24:39 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Mon, 29 Oct 2012 22:24:26 +0000 From: Mike Jones To: "Matt Miller (mamille2)" , " " Thread-Topic: [jose] Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsAACDLiIAAO0JKAAApuFWA= Date: Mon, 29 Oct 2012 22:24:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(69234002)(377454001)(51704002)(13464001)(54316001)(48376001)(8716001)(47736001)(3846001)(20776001)(47976001)(46102001)(16826001)(51856001)(54356001)(5343665001)(15202345001)(551544001)(47776002)(4196001)(47446002)(74502001)(44976002)(53806001)(16406001)(1076001)(4396001)(50466001)(74662001)(50986001)(16696001)(5343645001)(33656001)(31966008)(5343635001)(5343655001)(49866001)(6606295001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 064903DDDC Cc: "" , "" Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 29 Oct 2012 22:24:50 -0000 The "PB" in PBKDF2 is "Password Based". This and related KDFs generate key= s from passwords rather than other keys, and so are not applicable for this= use case. For lack of a commonly implemented key-based KDF, we chose a very simple on= e that only requires support for SHA-256 and SHA-512 to build for our use c= ases. (Heck, for our use cases, implementations don't even require a loop = - just a single hash calculation over the input.) I already know of 5 inte= roperable implementations at this point. It's just not that hard. See the example calculations in http://tools.ietf.org/html/draft-ietf-jose-= json-web-encryption-06#appendix-A.4 and http://tools.ietf.org/html/draft-ie= tf-jose-json-web-encryption-06#appendix-A.5 to see how simple it actually i= s. -- Mike -----Original Message----- From: Matt Miller (mamille2) [mailto:mamille2@cisco.com]=20 Sent: Monday, October 29, 2012 3:16 PM To: =20 Cc: Mike Jones; ; Subject: Re: [jose] Platform Support for JWA Crypto Algorithms On Oct 29, 2012, at 2:46 PM, wrote: > Ease of implementation is relative. Maybe tomorrow I will discover that t= he needed concat-KDF is supported "natively" by Mozilla's NSS library. Then= it is very easy. > Currently it looks difficult on that platform because the documentation s= ays that the digest function "finish" resets the digest, which would probab= ly lead to different results than in the examples in the appendices A4 and = A5. > " http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa73= 30d1ac9e69aafc30f71ba35da74e > NOTE: This method may be called any time after |init| is called. This cal= l resets the object to its pre-init state. > " > I still think that some thirty bytes is not much and that generating the = CIK randomly is much easier. I implemented the concat-kdf in java > https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncryp= to/crypto/KDFConcatGenerator.java and I know that implementing my proposal = below is easier. > Anyway: One could ask why the concat-KDF is not implemented in Bouncycast= le while three other KDFs are implemented there. > Mozilla implements KDFs too: > https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/= pk11skey.c#1437 > Although there is no indication in the code which KDF this implements. Ma= ybe a Mozillian on these lists can clarify. > If it is a KDF that is implemented in Bouncycastle too then I suggest to = change the default KDF in JWE to that one. >=20 > The implementation of KDF can lead to buffer overflows is no secret: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D617565 > Which means that KeyDerivationFunction implementation is not as easy as i= t could be. >=20 > Why do you think that the list of NIST's crypto implementations lists all= algs except KDF? > http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.ht= ml >=20 > NIST defines other KDFs too. Why is JWE using one that is implemented now= here? Any other choice that is implemented on two platforms is a better cho= ice than concat-kdf I think. >=20 To add more fuel to the fire: I've seen PBKDF2 is implemented in a few plac= es, and I think it's only slightly harder to implement as concatKDF. However, I still think just requiring a larger key is the easiest, least er= ror-prone approach. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > Axel >=20 > http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330= d1ac9e69aafc30f71ba35da74e > NOTE: This method may be called any time after |init| is called. This cal= l resets the object to its pre-init state. >=20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, October 29, 2012 5:25 PM > To: Nennker, Axel; jose@ietf.org > Cc: public-webcrypto@w3.org > Subject: RE: Platform Support for JWA Crypto Algorithms >=20 > No, Concat often isn't natively supported, but it's very easy to implemen= t given implementations of SHA-256 and SHA-512, as shown in http://tools.ie= tf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://= tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5. >=20 > When the table was discussed at the WebCrypto F2F, it was pointed out tha= t a shortcoming of the current table is that it doesn't indicate which of t= he "NO" values are effectively show-stoppers and which are easy to build im= plementations of, and so not a problem in practice. As shown in the append= ices, I believe that Concat is in the latter category. Given the ease of i= mplementation, it's certainly not worth adding space to the JWEs to work ar= ound. >=20 > -- Mike >=20 > From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] > Sent: Monday, October 29, 2012 6:03 AM > To: Mike Jones; jose@ietf.org > Cc: public-webcrypto@w3.org > Subject: RE: Platform Support for JWA Crypto Algorithms >=20 > As one can see from this table the KDF is unsupported on all platforms (e= xcept one). > http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_= Algorithms.xlsx >=20 > JWE >=20 > kdf >=20 > CS256 >=20 > Concat Key Derivation Function (KDF) >=20 > NO >=20 > Win7 >=20 >=20 >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > JWE >=20 > kdf >=20 > CS384 >=20 > Concat Key Derivation Function (KDF) >=20 > NO >=20 > Win7 >=20 >=20 >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > JWE >=20 > kdf >=20 > CS512 >=20 > Concat Key Derivation Function (KDF) >=20 > NO >=20 > Win7 >=20 >=20 >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 > NO >=20 >=20 >=20 > NO >=20 > NO >=20 > NO >=20 >=20 > Isn't this an indication that we should look at alternatives? >=20 > e.g.: we could generate the integrity protection key randomly instead of = deriving it from the content encryption key. > This would add some more bytes (e.g. about 32) to the jwt but is very eas= y to implement on all platforms. >=20 >=20 > One way to do it would be to generate enough bytes "Bytes" in "JWE Encryp= ted Key" for encryption and integrity. > The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength ..= cekLength+cikLength-1]" >=20 >=20 > Axel >=20 > [On some platforms (Firefox/NSS) it might even be nearly impossible to im= plement (without extending the platform's functions) because the build-in d= igest function is always reset when finalize (doFinal) is called. The spec = of the Concat-KDF says that bytes are generated in a loop but the digest is= NOT reset in the loop.] >=20 >=20 > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf Of Mike Jones > Sent: Monday, October 29, 2012 7:28 AM > To: jose@ietf.org > Subject: [jose] Platform Support for JWA Crypto Algorithms >=20 > FYI, I posted the table describing support for the JWA algorithms in comm= on Web development platforms that we discussed at IETF 84. See http://self= -issued.info/?p=3D884. >=20 > -- Mike >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ignisvulpis@gmail.com Mon Oct 29 16:41: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 C23ED21F8673 for ; Mon, 29 Oct 2012 16:41:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk3JT5nC0VT8 for ; Mon, 29 Oct 2012 16:41:14 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id CC4B921F863F for ; Mon, 29 Oct 2012 16:41:13 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id fm10so1732210wgb.1 for ; Mon, 29 Oct 2012 16:41:12 -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 :content-type; bh=HSw4AhBH8HnEnfu5qQIGgN947RyFL65GAOTtBPIhjr8=; b=Y7okV0Qkzv+NwpOwYxsTsrgebJomBxSMO5bGROsseqO8R+4CSKGKV0bDVw50+G1RU7 t+UmPNjdhd0/bgcAsfQiJLRBQ1YyQT0LO3U/PLHPOOgkG7qXYad6dnbMxypLZwBwMvF5 aqayc+kE9hLgWkAiajmO8MH7Iq2wCuXL/2RIAkyoIzVIy+u5NDorb0jZEO+s0zL119V0 uUr+g5LxBQjIWc0K3urhg50KiF1PbB3EmvHnOVODa58cVDosde9Ch8ok5XlWEE7pqQ28 HgGDIXgSNOkMusybyVGp5YP7KJ+8USRY8GiiI/iu8NlCqDIf2gY3DKZmJlFlNt2NZSEa 44zw== MIME-Version: 1.0 Received: by 10.216.207.170 with SMTP id n42mr16812340weo.173.1351554072793; Mon, 29 Oct 2012 16:41:12 -0700 (PDT) Received: by 10.216.54.130 with HTTP; Mon, 29 Oct 2012 16:41:12 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Tue, 30 Oct 2012 00:41:12 +0100 Message-ID: From: Axel Nennker To: Mike Jones , jose@ietf.org Content-Type: multipart/alternative; boundary=0016e6dd8bd967536904cd3b34b1 Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 29 Oct 2012 23:41:14 -0000 --0016e6dd8bd967536904cd3b34b1 Content-Type: text/plain; charset=ISO-8859-1 Maybe that is the way to go then: In http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms simply state there that the CIK is CIK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43, 72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255] CEK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255] Similar for SHA512. General rule: use a digest that produces enough or more bits as needed for the cik or cek. NOTE (non normative) that this happens to be the same as the concat KDF as defined in NIST.800-56A for the given bit lengths Axel 2012/10/29 Mike Jones > > The "PB" in PBKDF2 is "Password Based". This and related KDFs generate keys from passwords rather than other keys, and so are not applicable for this use case. > > For lack of a commonly implemented key-based KDF, we chose a very simple one that only requires support for SHA-256 and SHA-512 to build for our use cases. (Heck, for our use cases, implementations don't even require a loop - just a single hash calculation over the input.) I already know of 5 interoperable implementations at this point. It's just not that hard. > > See the example calculations in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5to see how simple it actually is. > > -- Mike --0016e6dd8bd967536904cd3b34b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maybe that is the way to go then:

In
=A0 http://tools.ietf.org/id/d= raft-ietf-jose-json-web-algorithms
simply state there that the CIK i= s

=A0 CIK =3D SHA256(0,= 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43, 72, 83, 50, 53, = 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255]
=A0 CEK =3D SHA25= 6(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 50, = 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255]
Similar for SHA512. General rule: use a digest that produces enough = or more bits as needed for the cik or cek.

NOTE (non normative) that= this happens to be the same as the concat KDF as defined in NIST.800-56A f= or the given bit lengths

Axel


2012/10/29 Mike Jones <Michael.Jones@microsoft.com>
>
> The &= quot;PB" in PBKDF2 is "Password Based". =A0This and related = KDFs generate keys from passwords rather than other keys, and so are not ap= plicable for this use case.
>
> For lack of a commonly implemented key-based KDF, we chose a v= ery simple one that only requires support for SHA-256 and SHA-512 to build = for our use cases. =A0(Heck, for our use cases, implementations don't e= ven require a loop - just a single hash calculation over the input.) =A0I a= lready know of 5 interoperable implementations at this point. =A0It's j= ust not that hard.
>
> See the example calculations in http://tools.i= etf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryptio= n-06#appendix-A.5 to see how simple it actually is.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 -- Mike --0016e6dd8bd967536904cd3b34b1-- From ignisvulpis@gmail.com Mon Oct 29 16:56:06 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 D8AF721F86A1 for ; Mon, 29 Oct 2012 16:56:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN7gXHh5EHJf for ; Mon, 29 Oct 2012 16:56:06 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 976F121F8650 for ; Mon, 29 Oct 2012 16:56:01 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2278334wib.13 for ; Mon, 29 Oct 2012 16:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vbYAlBK5IkCifQ0tH/ib9CzPvrQ5DQJjpgkDkNEja/s=; b=Ta2k3HhFb1wBrH7i7rr1maQ51RtHp5fJMW6jtKAYcNngV600PS1U7HccqIPrlOF/UA F7y9FSUPDjVKglKntz5NoEli8AZftUykW1fzhiVh56tcpzBsa1yO31Hf+6duOVnIFBRI IcrtE7qpuZ3wpNz+tUon9PAXSRHiLfiKAPZxgpnhzC9ePd9XeJve8XS/9UbfYb6KzJrU oAmZFOPEVqYpn54sMLEfGmJ9N9u5rHeiuu+7y8IR9gkRic2euqSt5TdZWmSjYBjCaTlP dkXQsp8KMiZeQjW89YXxPNofq1G/luaWPQiHs8CMz2RI4LjkV4a8zQB+51Fd1SK4Dzwf 95cQ== MIME-Version: 1.0 Received: by 10.216.207.170 with SMTP id n42mr16823042weo.173.1351554960645; Mon, 29 Oct 2012 16:56:00 -0700 (PDT) Received: by 10.216.54.130 with HTTP; Mon, 29 Oct 2012 16:56:00 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668828D9@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436687BCEB@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943668828D9@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Tue, 30 Oct 2012 00:56:00 +0100 Message-ID: From: Axel Nennker To: Mike Jones Content-Type: multipart/alternative; boundary=0016e6dd8bd952de8604cd3b699a Cc: "jose@ietf.org" Subject: Re: [jose] jwk 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, 29 Oct 2012 23:56:07 -0000 --0016e6dd8bd952de8604cd3b699a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Encoding public keys as self-signed certs: That is a hack. Not that I am opposed to hacks but this is too much. 2012/10/29 Mike Jones > =93x5c=94 helps because you can represent a bare key as a self-signed ce= rt > in PEM format in the =93x5c=94 parameter. The JOSE specs already support > PEM-encoded keys.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Axel Nennker [mailto:ignisvulpis@gmail.com] > *Sent:* Wednesday, October 24, 2012 2:14 PM > *To:* Mike Jones > *Cc:* jose@ietf.org > *Subject:* Re: jwk**** > > ** ** > > In the case where I generate the keypair on the fly I do not have an URL > to put in x5u. And a cert in not a public key. I want bare keys. > I don't know how x5u and x5c help here. > > I have the problem that I don't know how to convert (exp,mod) into a > pubkey on one platform (Firefox). I think that PEM is easier. > I think the same might be true an other platforms too. > > Another reason I think that PEM is better is that there are command line > tools to produce PEM-encoded keys while I don't know any tool to produce > (exp, mod). > > --Axel**** > > 2012/10/24 Mike Jones **** > > To be clear, JWS and JWE already support the use of PEM encoded keys > through the "x5c" and "x5u" parameters. Therefore, I don't see any need = to > also add X.509-based key formats to JWK itself.**** > > **** > > -- Mike**** > > **** > > *From:* Axel Nennker [mailto:ignisvulpis@gmail.com] > *Sent:* Wednesday, October 24, 2012 12:55 PM > *To:* jose@ietf.org > *Cc:* Mike Jones > *Subject:* jwk**** > > **** > > > I think that having more choices other than (xpo, mod) is useful. > I believe that it is easier for me to implement keys in Firefox if I have > PEM encoded keys. > > So the format could be: > > user_jwk : {"pub": > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI > yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh= 45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTT= bKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc > n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk > KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB= " > } > // PEM encoded public key without linebreaks > > A more general format would be: > > jwk: { "-----BEGIN PUBLIC KEY-----": > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI > yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh= 45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTT= bKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc > n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk > KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB= " > } > > This general format could be used for private keys too. > > What do you think? > > Axel > > ps: Don't know whether I can post from this email address.... Mike, would > you lease post it if it does appear in your inbox but not on the list. > Thanks.**** > > ** ** > --0016e6dd8bd952de8604cd3b699a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Encoding public keys as self-signed certs: That is a hack. Not that I am op= posed to hacks but this is too much.


--0016e6dd8bd952de8604cd3b699a-- From ignisvulpis@gmail.com Mon Oct 29 17:10: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 C1E4721F86BA for ; Mon, 29 Oct 2012 17:10:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkTH55Hb1uEW for ; Mon, 29 Oct 2012 17:10:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 478D021F86A1 for ; Mon, 29 Oct 2012 17:10:12 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so2233704wib.13 for ; Mon, 29 Oct 2012 17:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zEJMTb+/PaSOHk0U2/C+oSqBTtJ7zmQdglAtva1TB2I=; b=s5DxmqYKD85whZwszaO9cv4oPQKvIQqDdyBl1ljWIb4/iZuwHLF9oQvBtut0kbz8TR DUEwya6nUKvv/aiNpDe7OX0P/Y8hMD3Q6ewhs278vrpC3uzsHr5Wot685A2G6ws7vGgK +oR2O8trbEyqiUbGxKlmICkUYgmiXanX8ZS/+Pn+eHQE633ybfbBxqSM9XlvBOmIgxDY 9io7APZ42GUt0x4W39xGxy+ykfgFalQgwKunsftOBnRSo+Jd8b5QlxqOucScCHaPBtQX Wbzryw7JOuWYJ8yh7z81KjK6uBheWmeZPPm5hZxoZCiFKRKgPRZoKFsFxS9DgyTnDEXf rZRA== MIME-Version: 1.0 Received: by 10.216.131.85 with SMTP id l63mr14887336wei.110.1351555808432; Mon, 29 Oct 2012 17:10:08 -0700 (PDT) Received: by 10.216.54.130 with HTTP; Mon, 29 Oct 2012 17:10:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Oct 2012 01:10:08 +0100 Message-ID: From: Axel Nennker To: Dick Hardt Content-Type: multipart/alternative; boundary=0016e6d99ee1db13a304cd3b9bde Cc: jose@ietf.org Subject: Re: [jose] signing an existing JWT 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, 30 Oct 2012 00:10:13 -0000 --0016e6d99ee1db13a304cd3b9bde Content-Type: text/plain; charset=ISO-8859-1 An answer not related to the size issue which might be relevant regardless: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html --Axel 2012/10/29 Dick Hardt > > Let's say we have created a JWE as such: > > > headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritityVectorOne > > This is now the payload to a JWS. Rather than increasing the token size by > 4/3 by URL safe base 64 encoding the payload (since it is already URL > safe), it would be useful to have a JWS header parameter that indicates the > payload was not re-encoded and does not need to be URL safe base 64 decoded. > > As there are more periods than expected in a JWS, decoding would ignore > all periods except the first and last one for separating out the header, > payload and signature. > > The indicating parameter would seem to be either "tip" or "cty". I'm still > confused about the difference between the two parameters, so not sure which > one is appropriate. > > -- Dick > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --0016e6d99ee1db13a304cd3b9bde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable An answer not related to the size issue which might be relevant regardless:= http= ://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

--Axel
2012/10/29 Dick Hardt <= dick.hardt@gmail.= com>

Let's say we have created a JWE as such:

=A0 =A0 =A0 =A0 headerOne.encryptedKeyOne.initializationVectorOne.ciphertex= tOne.integritityVectorOne

This is now the payload to a JWS. Rather than increasing the token size by = 4/3 by URL safe base 64 encoding the payload (since it is already URL safe)= , it would be useful to have a JWS header parameter that indicates the payl= oad was not re-encoded and does not need to be URL safe base 64 decoded.
As there are more periods than expected in a JWS, decoding would ignore all= periods except the first and last one for separating out the header, paylo= ad and signature.

The indicating parameter would seem to be either "tip" or "c= ty". I'm still confused about the difference between the two param= eters, so not sure which one is appropriate.

-- Dick


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

--0016e6d99ee1db13a304cd3b9bde-- From dick.hardt@gmail.com Mon Oct 29 19:15: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 EE13021F85D4 for ; Mon, 29 Oct 2012 19:15:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvWNY1gTaSr7 for ; Mon, 29 Oct 2012 19:15:03 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6DCC21F852A for ; Mon, 29 Oct 2012 19:15:03 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3759436pad.31 for ; Mon, 29 Oct 2012 19:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Se31L6HYjoujdpOxha0FV6a6ANlVA5FRsFhuZa+0IzU=; b=QPLbEqsSyOyQeRP5ZKwaUkODOf/hSBViALHAbeQUsKzk5VFyuV4fYpBrC5DBS0QbcS Vs2iWfvzEhPVd5PKrEG6mcNkHWwCkxkQrmFh56RZIl/mzG46qat89u+WGz/I8UnhlNx7 O3kurC+ZZnsRuQP15NM6a0QYaQ+U+U07gf1CFlX7cd1ucbh398A3EcFFW0lKoUh3I5uL lHCiqhPcmQpwZJWBqnZ2h9cg0vHEkfmU8shUDFESiPaQMcRNsyQsgZjfuscaTmT8O4/b +0YPXmKvefSc4ZszElaJ5v1Iy1II243KpTtWHpwDlGe+uOkD8LB0STHACg7Ywnncowgt Ghpw== Received: by 10.68.223.66 with SMTP id qs2mr32932698pbc.139.1351563303487; Mon, 29 Oct 2012 19:15:03 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id s1sm997477paz.0.2012.10.29.19.14.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 19:14:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AB158D5C-D8FB-456C-9FE3-AD74FF5900CF" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Mon, 29 Oct 2012 19:14:46 -0700 Message-Id: <347420ED-3223-4403-A592-51EBAAB2E2A3@gmail.com> References: To: Axel Nennker X-Mailer: Apple Mail (2.1499) Cc: jose@ietf.org, Dick Hardt Subject: Re: [jose] signing an existing JWT 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, 30 Oct 2012 02:15:05 -0000 --Apple-Mail=_AB158D5C-D8FB-456C-9FE3-AD74FF5900CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks Axel. I'm familiar with naive sign and encrypt issues = (hopefully!) As I reflected on my implementation, I have to include other parameters = in my payload besides the JWT, so an optimization does not look simple. = I can use POST here as well, so size is not as much of an issue as it is = with a redirect over GET. -- Dick On Oct 29, 2012, at 5:10 PM, Axel Nennker wrote: > An answer not related to the size issue which might be relevant = regardless: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html=20 >=20 > --Axel >=20 > 2012/10/29 Dick Hardt >=20 > Let's say we have created a JWE as such: >=20 > = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne >=20 > This is now the payload to a JWS. Rather than increasing the token = size by 4/3 by URL safe base 64 encoding the payload (since it is = already URL safe), it would be useful to have a JWS header parameter = that indicates the payload was not re-encoded and does not need to be = URL safe base 64 decoded. >=20 > As there are more periods than expected in a JWS, decoding would = ignore all periods except the first and last one for separating out the = header, payload and signature. >=20 > The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate. >=20 > -- Dick >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_AB158D5C-D8FB-456C-9FE3-AD74FF5900CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ignisvulpis@gmail.com> = wrote:
2012= /10/29 Mike Jones <Michael.Jones@microsoft.com>

=93x5c=94 helps because y= ou can represent a bare key as a self-signed cert in PEM format in the =93x= 5c=94 parameter.=A0 The JOSE specs already support PEM-encoded keys.=

=A0<= /p>

=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

=A0<= /p>

From: Axel Nen= nker [mailto:ign= isvulpis@gmail.com]
Sent: Wednesday, October 24, 2012 2:14 PM
To: Mike Jones
Cc: jose@ietf.org=
Subject: Re: jwk

=A0

In the case where I g= enerate the keypair on the fly I do not have an URL to put in x5u. And a ce= rt in not a public key. I want bare keys.
I don't know how x5u and x5c help here.

I have the problem that I don't know how to convert (exp,mod) into a pu= bkey on one platform (Firefox). I think that PEM is easier.
I think the same might be true an other platforms too.

Another reason I think that PEM is better is that there are command line to= ols to produce PEM-encoded keys while I don't know any tool to produce = (exp, mod).

--Axel

2012/10/24 Mike Jones <Michael.Jones@microsoft.com><= u>

To be clear, JWS and JWE already support the use of PEM encoded keys thr= ough the "x5c" and "x5u" parameters.=A0 Therefore, I do= n't see any need to also add X.509-based key formats to JWK itself.<= /u>

=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

=A0<= /p>

From: Axel Nen= nker [mailto:ign= isvulpis@gmail.com]
Sent: Wednesday, October 24, 2012 12:55 PM
To: jose@ietf.org=
Cc: Mike Jones
Subject: jwk

=A0


I think that having more choices other than (xpo, mod) is useful.
I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys.

So the format could be:

user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC= AQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCTh= N/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp= 4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zD= zelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" }
// PEM encoded public key without linebreaks

A more general format would be:

jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQ= EFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ= 3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9K= IlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASi= gL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zD= zelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB"
}

This general format could be used for private keys too.

What do you think?

Axel

ps: Don't know whether I can post from this email address.... Mike, wou= ld you lease post it if it does appear in your inbox but not on the list. T= hanks.

=A0


An answer not related to the size issue which might be = relevant regardless: http://= world.std.com/~dtd/sign_encrypt/sign_encrypt7.html =

--Axel

2012/10/29 Dick Hardt <dick.hardt@gmail.com>

Let's say we have created a JWE as such:

        = headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritit= yVectorOne

This is now the payload to a JWS. Rather than increasing the token size = by 4/3 by URL safe base 64 encoding the payload (since it is already URL = safe), it would be useful to have a JWS header parameter that indicates = the payload was not re-encoded and does not need to be URL safe base 64 = decoded.

As there are more periods than expected in a JWS, decoding would ignore = all periods except the first and last one for separating out the header, = payload and signature.

The indicating parameter would seem to be either "tip" or "cty". I'm = still confused about the difference between the two parameters, so not = sure which one is appropriate.

-- Dick


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


= --Apple-Mail=_AB158D5C-D8FB-456C-9FE3-AD74FF5900CF-- From djc.ochtman@gmail.com Tue Oct 30 00:47:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42A221F84A1 for ; Tue, 30 Oct 2012 00:47:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOLf8NbdRr8f for ; Tue, 30 Oct 2012 00:47:58 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 282B521F849F for ; Tue, 30 Oct 2012 00:47:57 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so1982179qab.10 for ; Tue, 30 Oct 2012 00:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=1enFzJPT8yO7aldWSdY5k5yIvZIcZ55Mo2yHyETIiD4=; b=FjL0yRPWdNQ6j5KVED11O0p5Tnp2MNXBRpUp6uFQoFXMgdZCoPUAmF0d1u2phXA0Dn F96I8PrxAkVZEtslXwC9g8x/GAotLCtqksp0E1RpEsmlJWyWTcnl4BGIXOWdpJ6ppLCK De/cbOBHtDqt6owedar4OWFDWh/J8Kk+XliM3QnlEp6umrErJz+mVgh1tz19sDnMgyPO OcvuXLUlQSCAImSzM2dABb8haQ0Img3CcZb78zdCbcoOkvtDEyY7olxQ6LNVfdrpQYUG cSG2OLGmK+7GOUI+xREh+xzs7IbIkmCJsUYDjT/NhLCLGuGaPFFyVNQlw1umCINbQkjY vt4A== Received: by 10.49.63.97 with SMTP id f1mr25146476qes.4.1351583277310; Tue, 30 Oct 2012 00:47:57 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.49.97.195 with HTTP; Tue, 30 Oct 2012 00:47:35 -0700 (PDT) In-Reply-To: References: From: Dirkjan Ochtman Date: Tue, 30 Oct 2012 08:47:35 +0100 X-Google-Sender-Auth: V20r1TSBBeP9VGsmDR19eaDcu8M Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [jose] Feedback on JWS draft-06 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, 30 Oct 2012 07:47:58 -0000 Any feedback on this? I can understand how no one is interested in discussing a new header option at this stage (particularly if there are out-of-band methods to solve the problem), but the lack of mentions of PKCS seems like a significant usability bug. I will add to the paragraph from below that the appendix also doesn't explicitly refer to relevant sections of the JWA spec. Cheers, Dirkjan On Sat, Oct 20, 2012 at 6:47 PM, Dirkjan Ochtman wrote: > I spent some time this week becoming familiar with the JOSE familiar > of specifications, in the context of implementing a Mozilla Persona > identity provider. This took quite a bit longer than I expected, > partially due to a misunderstanding on my side about JWS. > > In particular, I spent a few hours figuring out why my signatures were > being rejected by a Persona server, with the error message given "bad > signature in chain". It turns out that the signature I provided was > incorrect, because I had used basic RSA signing rather than PKCS1 v1.5 > as the JWS spec seems to require. Unfortunately I spent much more time > looking at the JWS draft-06 appendices with examples than I spent time > looking at JWA, where the algorithms are properly called out. In fact, > while JWS seems to refer to the algorithms allowed quite often, the > term PKCS is not to be found in the current draft. I haven't read the > entire spec, but it seems an oversight not to include a reference to > PKCS, particularly in the example sections. > > Finally, while I appear to be quite late to the party, I was wondering > if something like HTTP's Transfer-Encoding has been considered for > inclusion. The JOSE family of specs looks very useful, but one use > case I had developed earlier (for which I built my own serialization > format for encrypted and signed messages) included some form of > compression. It seems like a "te" field in the header part could, > through a value like "zlib" or "gzip", simply confer to the receiver > that the payload must first be decompressed after being decoded. This > would neatly encapsulate handling of larger payloads. > > On the other hands, perhaps compression could easily be done with the > encoded header/payload/signature, without much of a loss in > compression efficiency due to the order of the compress and encode > operations. > > Cheers, and thanks for the useful specs, > > Dirkjan From James.H.Manger@team.telstra.com Tue Oct 30 06:13: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 0080721F84B5 for ; Tue, 30 Oct 2012 06:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.959 X-Spam-Level: X-Spam-Status: No, score=0.959 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo-DGLgYDXTd for ; Tue, 30 Oct 2012 06:13:22 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id EB07021F84D6 for ; Tue, 30 Oct 2012 06:13:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,680,1344175200"; d="scan'208,217";a="100516302" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 31 Oct 2012 00:13:19 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6880"; a="95337613" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 31 Oct 2012 00:13:16 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 31 Oct 2012 00:13:18 +1100 From: "Manger, James H" To: "jose@ietf.org" Date: Wed, 31 Oct 2012 00:13:16 +1100 Thread-Topic: NIST Concat KDF Thread-Index: Ac22LuWgSDJoAVpDQL23HP4i5KxmTwACPfUA Message-ID: <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FFB9FC5DWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [jose] NIST Concat KDF 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, 30 Oct 2012 13:13:29 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FFB9FC5DWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sk9TRSBzdGlsbCBkb2VzbuKAmXQgdXNlIHRoZSBOSVNUIDgwMC01NkEgQ29uY2F0IEtleSBERiBh cyB0aGF0IHNwZWNpZmljYXRpb24gcmVxdWlyZXMuDQoNCkpXQSBhbGxvd3MgUGFydHlVSW5mbyBh bmQvb3IgUGFydHlWSW5mbyB0byBiZSBlbXB0eSAoaWYgYXB1L2Fwdi9lcHUvZXB2IGFyZSBhYnNl bnQpLiBUaGF0IGRvZXNu4oCZdCBjb21wbHkgd2l0aCA4MDAtNTZBIHRoYXQgc2F5cyDigJxhdCBh IG1pbmltdW0sIFBhcnR5VUluZm8gc2hhbGwgaW5jbHVkZSBJRHUsIHRoZSBpZGVudGl0eSBvZiBw YXJ0eSBV4oCdLiA4MDAtNTZBIGFsc28gc2F5cyDigJxpdCBpcyByZXF1aXJlZCB0aGF0IGlkZW50 aWZpZXIgZm9yIGJvdGggcGFydGllcyB0byBhIGtleSBhZ3JlZW1lbnQgdHJhbnNhY3Rpb24gYmUg aW5jbHVkZWQgaW4gdGhlIE90aGVySW5mbyB0aGF0IGlzIGlucHV0IHRvIHRoZSBrZXkgZGVyaXZh dGlvbiBmdW5jdGlvbuKAnS4NCg0KODAwLTU2QSByZXF1aXJlcyB0aGF0IHRoZSBjb25jYXRlbmF0 aW9uIEFsZ29yaXRobUlEIHx8IFBhcnR5VUluZm8gfHwgUGFydHlWSW5mbyBiZSB1bmFtYmlndW91 cy4gSXQgYWxsb3dzIHR3byB3YXlzIHRvIGFjaGlldmUgdGhpczogcHJlLWRlZmluZSBmaXhlZCBz aXplcyBmb3IgY29tcG9uZW50czsgb3IgcHJlZml4IGVhY2ggY29tcG9uZW50IHdpdGggaXRzIGxl bmd0aC4gSldBIGRvZXMgbmVpdGhlciBvZiB0aGVzZS4NCg0KQ29uc2lkZXIgdHdvIEpPU0UgbWVz c2FnZXMgKGlnbm9yaW5nIHNvbWUgaXJyZWxldmFudCBiYXNlNjR1cmwgZW5jb2RpbmcpOg0KICB7 IC4uLiwgImFwdSI6IkpvQmV0aCIsICJhcHYiOiJBbm5lIiB9IGFuZA0KICB7IC4uLiwgImFwdSI6 IkpvIiwgImFwdiI6IkJldGhBbm5lIiB9DQpKV0EgaW1wbGllcyBib3RoIHVzZSB0aGUgc3RyaW5n ICJKb0JldGhBbm5lIiBpbiB0aGUgS0RGIGRlc3BpdGUgdGhlIG1lc3NhZ2VzIGJlaW5nIGJldHdl ZW4gZGlmZmVyZW50IHBhcnRpZXMsIHdoaWNoIGRlZmVhdHMgdGhpcyBwYXJ0IG9mIHRoZSBDb25j YXQgS0RGIGRlc2lnbi4NCg0KSldBIGV4cGxpY2l0bHkgcHV0cyB0aGUga2V5IGxlbmd0aCBhbmQg ImFsZyIgdmFsdWUgaW50byB0aGUgQWxnb3JpdGhtSUQgZmllbGQgdGhhdCB0aGUgS0RGIHVzZXMu IEhvd2V2ZXIsIHRoZSAiYWxnIiB2YWx1ZSBhbG9uZSBtdXN0IGltcGx5IG9uZSBzcGVjaWZpYyBr ZXkgbGVuZ3RoIGZvciB0aGUgcmVzdCBvZiB0aGUgSk9TRSBwcm9jZXNzaW5nIHRvIHdvcmsgc28g aW5jbHVkaW5nIHRoZSBrZXkgbGVuZ3RoIGV4cGxpY2l0bHkgaXMgcmVkdW5kYW50Lg0KDQo4MDAt NTZBIGlzIGRlc2lnbmVkIHRvIGRlcml2ZSBpbnRlZ3JpdHkgYW5kIGVuY3J5cHRpb24ga2V5cyB0 b2dldGhlci4gRm9yIGluc3RhbmNlLCBpdCBzYXlzIOKAnEFsZ29yaXRobUlEIG1pZ2h0IGluZGlj YXRlIHRoYXQgYml0cyAxLTgwIGFyZSB0byBiZSB1c2VkIGFzIGFuIDgwLWJpdCBITUFDIGtleSBh bmQgdGhhdCBiaXRzIDgxLTIwOCBhcmUgdG8gYmUgdXNlZCBhcyBhIDEyOC1iaXQgQUVTIGtleeKA nS4gSldBIGRvZXMgbm90IGRvIHRoaXMuIEpXQSBydW5zIHRoZSBLREYgdHdpY2UgdG8gZGVyaXZl IGludGVncml0eSBhbmQgZW5jcnlwdGlvbiBrZXlzIHNlcGFyYXRlbHkuDQoNCklmIHdlIHdhbnQg dG8gdXNlIE5JU1QgODAwLTU2QSBDb25jYXQgS0RGIHRoZW4gSldBL0pXRSBuZWVkcyBsb3RzIG9m IGZpeGVzLg0KSWYgd2Ugd2FudCBhIHNpbXBsZXIgS0RGIHRoZW4gSldBIHNob3VsZG7igJl0IHBy ZXRlbmQgaXQgaXMgdGhlIE5JU1QgODAwLTU2QSBDb25jYXQgS0RGLg0KDQotLQ0KSmFtZXMgTWFu Z2VyDQo= --_000_255B9BB34FB7D647A506DC292726F6E114FFB9FC5DWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Sk9TRSBzdGlsbCBk b2VzbuKAmXQgdXNlIHRoZSBOSVNUIDgwMC01NkEgQ29uY2F0IEtleSBERiBhcyB0aGF0IHNwZWNp ZmljYXRpb24gcmVxdWlyZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KV0EgYWxsb3dzIFBhcnR5VUlu Zm8gYW5kL29yIFBhcnR5VkluZm8gdG8gYmUgZW1wdHkgKGlmIGFwdS9hcHYvZXB1L2VwdiBhcmUg YWJzZW50KS4gVGhhdCBkb2VzbuKAmXQgY29tcGx5IHdpdGggODAwLTU2QSB0aGF0IHNheXMg4oCc YXQgYSBtaW5pbXVtLCBQYXJ0eVVJbmZvIHNoYWxsIGluY2x1ZGUgSUR1LCB0aGUgaWRlbnRpdHkg b2YgcGFydHkgVeKAnS4gODAwLTU2QSBhbHNvIHNheXMg4oCcaXQgaXMgcmVxdWlyZWQgdGhhdCBp ZGVudGlmaWVyIGZvciBib3RoIHBhcnRpZXMgdG8gYSBrZXkgYWdyZWVtZW50IHRyYW5zYWN0aW9u IGJlIGluY2x1ZGVkIGluIHRoZSBPdGhlckluZm8gdGhhdCBpcyBpbnB1dCB0byB0aGUga2V5IGRl cml2YXRpb24gZnVuY3Rpb27igJ0uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz44MDAtNTZBIHJlcXVpcmVz IHRoYXQgdGhlIGNvbmNhdGVuYXRpb24gQWxnb3JpdGhtSUQgfHwgUGFydHlVSW5mbyB8fCBQYXJ0 eVZJbmZvIGJlIHVuYW1iaWd1b3VzLiBJdCBhbGxvd3MgdHdvIHdheXMgdG8gYWNoaWV2ZSB0aGlz OiBwcmUtZGVmaW5lIGZpeGVkIHNpemVzIGZvciBjb21wb25lbnRzOyBvciBwcmVmaXggZWFjaCBj b21wb25lbnQgd2l0aCBpdHMgbGVuZ3RoLiBKV0EgZG9lcyBuZWl0aGVyIG9mIHRoZXNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Q29uc2lkZXIgdHdvIEpPU0UgbWVzc2FnZXMgKGlnbm9yaW5nIHNvbWUg aXJyZWxldmFudCBiYXNlNjR1cmwgZW5jb2RpbmcpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoCB7IC4uLiwgJnF1b3Q7YXB1 JnF1b3Q7OiZxdW90O0pvQmV0aCZxdW90OywgJnF1b3Q7YXB2JnF1b3Q7OiZxdW90O0FubmUmcXVv dDsgfSBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+wqAgeyAuLi4sICZxdW90O2FwdSZxdW90OzomcXVvdDtKbyZxdW90Oywg JnF1b3Q7YXB2JnF1b3Q7OiZxdW90O0JldGhBbm5lJnF1b3Q7IH08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SldBIGltcGxpZXMg Ym90aCB1c2UgdGhlIHN0cmluZyAmcXVvdDtKb0JldGhBbm5lJnF1b3Q7IGluIHRoZSBLREYgZGVz cGl0ZSB0aGUgbWVzc2FnZXMgYmVpbmcgYmV0d2VlbiBkaWZmZXJlbnQgcGFydGllcywgd2hpY2gg ZGVmZWF0cyB0aGlzIHBhcnQgb2YgdGhlIENvbmNhdCBLREYgZGVzaWduLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+SldBIGV4cGxpY2l0bHkgcHV0cyB0aGUga2V5IGxlbmd0aCBhbmQgJnF1b3Q7YWxnJnF1 b3Q7IHZhbHVlIGludG8gdGhlIEFsZ29yaXRobUlEIGZpZWxkIHRoYXQgdGhlIEtERiB1c2VzLiBI b3dldmVyLCB0aGUgJnF1b3Q7YWxnJnF1b3Q7IHZhbHVlIGFsb25lIG11c3QgaW1wbHkgb25lIHNw ZWNpZmljIGtleSBsZW5ndGggZm9yIHRoZSByZXN0IG9mIHRoZSBKT1NFIHByb2Nlc3NpbmcgdG8g d29yayBzbyBpbmNsdWRpbmcgdGhlIGtleSBsZW5ndGggZXhwbGljaXRseSBpcyByZWR1bmRhbnQu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz44MDAtNTZBIGlzIGRlc2lnbmVkIHRvIGRlcml2ZSBpbnRlZ3Jp dHkgYW5kIGVuY3J5cHRpb24ga2V5cyB0b2dldGhlci4gRm9yIGluc3RhbmNlLCBpdCBzYXlzIOKA nEFsZ29yaXRobUlEIG1pZ2h0IGluZGljYXRlIHRoYXQgYml0cyAxLTgwIGFyZSB0byBiZSB1c2Vk IGFzIGFuIDgwLWJpdCBITUFDIGtleSBhbmQgdGhhdCBiaXRzIDgxLTIwOCBhcmUgdG8gYmUgdXNl ZCBhcyBhIDEyOC1iaXQgQUVTIGtleeKAnS4gSldBIGRvZXMgbm90IGRvIHRoaXMuIEpXQSBydW5z IHRoZSBLREYgdHdpY2UgdG8gZGVyaXZlIGludGVncml0eSBhbmQgZW5jcnlwdGlvbiBrZXlzIHNl cGFyYXRlbHkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JZiB3ZSB3YW50IHRvIHVzZSBOSVNUIDgwMC01 NkEgQ29uY2F0IEtERiB0aGVuIEpXQS9KV0UgbmVlZHMgbG90cyBvZiBmaXhlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYg d2Ugd2FudCBhIHNpbXBsZXIgS0RGIHRoZW4gSldBIHNob3VsZG7igJl0IHByZXRlbmQgaXQgaXMg dGhlIE5JU1QgODAwLTU2QSBDb25jYXQgS0RGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E114FFB9FC5DWSMSG3153Vsrv_-- From mamille2@cisco.com Tue Oct 30 06:46: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 72F0321F84DB for ; Tue, 30 Oct 2012 06:46:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlIBwPu+gaOD for ; Tue, 30 Oct 2012 06:46:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AB96A21F84EF for ; Tue, 30 Oct 2012 06:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11898; q=dns/txt; s=iport; t=1351604805; x=1352814405; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/dE3RKeBaHMQvji+V3r63KqSjcm9uB4ubMNDtI5/dPk=; b=A6RIdE/4MHqDofE6eQLvR2HZrpNMrkqSzHHGsWK2Mh4PqRutVoPWTqDj Pi7mU45NFjfJlkPuOdZwohy2oGoZu9ZV9AWzrRS3nuYBPsnXUypseWWpj IZSVwt8KGJlDB69Lt8COop06t7zVjduD1HR0VRsBSyswfxZxfk6S3U5oR Q=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD3Zj1CtJV2d/2dsb2JhbABEw0iBCIIeAQEBAwEBAQEPAVsLBQcEAgEIDgMEAQEBCg4PBwIlCxQJCAIEDgUIBhSHXgYLnGSPZ5A5i3eDO4JBYQOOdYEhhnmNPYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="p7s'?scan'208";a="136890977" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 30 Oct 2012 13:46:45 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9UDkidA022897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 13:46:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 08:46:44 -0500 From: "Matt Miller (mamille2)" To: Mike Jones Thread-Topic: [jose] Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsAACDLiIAAO0JKAAApuFWAAFhIhgA== Date: Tue, 30 Oct 2012 13:46:44 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.62] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--38.711600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_19330349-12BD-42E3-908D-8917BDF90077"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 30 Oct 2012 13:46:47 -0000 --Apple-Mail=_19330349-12BD-42E3-908D-8917BDF90077 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 29, 2012, at 4:24 PM, Mike Jones = wrote: > The "PB" in PBKDF2 is "Password Based". This and related KDFs = generate keys from passwords rather than other keys, and so are not = applicable for this use case. >=20 Maybe this is too hacky for people, but: PBKDF2(H, base64url(key), salt, = iters) > For lack of a commonly implemented key-based KDF, we chose a very = simple one that only requires support for SHA-256 and SHA-512 to build = for our use cases. (Heck, for our use cases, implementations don't even = require a loop - just a single hash calculation over the input.) I = already know of 5 interoperable implementations at this point. It's = just not that hard. >=20 > See the example calculations in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix= -A.4 and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix= -A.5 to see how simple it actually is. >=20 If we're going for least difficulty, then why not just use key that's = (cipher-len + hash-len) in the first place? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > -- Mike >=20 > -----Original Message----- > From: Matt Miller (mamille2) [mailto:mamille2@cisco.com]=20 > Sent: Monday, October 29, 2012 3:16 PM > To: =20 > Cc: Mike Jones; ; > Subject: Re: [jose] Platform Support for JWA Crypto Algorithms >=20 >=20 > On Oct 29, 2012, at 2:46 PM, > wrote: >=20 >> Ease of implementation is relative. Maybe tomorrow I will discover = that the needed concat-KDF is supported "natively" by Mozilla's NSS = library. Then it is very easy. >> Currently it looks difficult on that platform because the = documentation says that the digest function "finish" resets the digest, = which would probably lead to different results than in the examples in = the appendices A4 and A5. >> " = http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d= 1ac9e69aafc30f71ba35da74e >> NOTE: This method may be called any time after |init| is called. This = call resets the object to its pre-init state. >> " >> I still think that some thirty bytes is not much and that generating = the CIK randomly is much easier. I implemented the concat-kdf in java >> = https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypt= o/crypto/KDFConcatGenerator.java and I know that implementing my = proposal below is easier. >> Anyway: One could ask why the concat-KDF is not implemented in = Bouncycastle while three other KDFs are implemented there. >> Mozilla implements KDFs too: >> = https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/p= k11skey.c#1437 >> Although there is no indication in the code which KDF this = implements. Maybe a Mozillian on these lists can clarify. >> If it is a KDF that is implemented in Bouncycastle too then I suggest = to change the default KDF in JWE to that one. >>=20 >> The implementation of KDF can lead to buffer overflows is no secret: >> https://bugzilla.mozilla.org/show_bug.cgi?id=3D617565 >> Which means that KeyDerivationFunction implementation is not as easy = as it could be. >>=20 >> Why do you think that the list of NIST's crypto implementations lists = all algs except KDF? >> = http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.htm= l >>=20 >> NIST defines other KDFs too. Why is JWE using one that is implemented = nowhere? Any other choice that is implemented on two platforms is a = better choice than concat-kdf I think. >>=20 >=20 > To add more fuel to the fire: I've seen PBKDF2 is implemented in a few = places, and I think it's only slightly harder to implement as concatKDF. >=20 > However, I still think just requiring a larger key is the easiest, = least error-prone approach. >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 >> Axel >>=20 >> = http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d= 1ac9e69aafc30f71ba35da74e >> NOTE: This method may be called any time after |init| is called. This = call resets the object to its pre-init state. >>=20 >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Monday, October 29, 2012 5:25 PM >> To: Nennker, Axel; jose@ietf.org >> Cc: public-webcrypto@w3.org >> Subject: RE: Platform Support for JWA Crypto Algorithms >>=20 >> No, Concat often isn't natively supported, but it's very easy to = implement given implementations of SHA-256 and SHA-512, as shown in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix= -A.4 and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix= -A.5. >>=20 >> When the table was discussed at the WebCrypto F2F, it was pointed out = that a shortcoming of the current table is that it doesn't indicate = which of the "NO" values are effectively show-stoppers and which are = easy to build implementations of, and so not a problem in practice. As = shown in the appendices, I believe that Concat is in the latter = category. Given the ease of implementation, it's certainly not worth = adding space to the JWEs to work around. >>=20 >> -- Mike >>=20 >> From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] >> Sent: Monday, October 29, 2012 6:03 AM >> To: Mike Jones; jose@ietf.org >> Cc: public-webcrypto@w3.org >> Subject: RE: Platform Support for JWA Crypto Algorithms >>=20 >> As one can see from this table the KDF is unsupported on all = platforms (except one). >> = http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_A= lgorithms.xlsx >>=20 >> JWE >>=20 >> kdf >>=20 >> CS256 >>=20 >> Concat Key Derivation Function (KDF) >>=20 >> NO >>=20 >> Win7 >>=20 >>=20 >>=20 >>=20 >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >>=20 >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> JWE >>=20 >> kdf >>=20 >> CS384 >>=20 >> Concat Key Derivation Function (KDF) >>=20 >> NO >>=20 >> Win7 >>=20 >>=20 >>=20 >>=20 >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >>=20 >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> JWE >>=20 >> kdf >>=20 >> CS512 >>=20 >> Concat Key Derivation Function (KDF) >>=20 >> NO >>=20 >> Win7 >>=20 >>=20 >>=20 >>=20 >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >>=20 >>=20 >> NO >>=20 >> NO >>=20 >> NO >>=20 >>=20 >> Isn't this an indication that we should look at alternatives? >>=20 >> e.g.: we could generate the integrity protection key randomly instead = of deriving it from the content encryption key. >> This would add some more bytes (e.g. about 32) to the jwt but is very = easy to implement on all platforms. >>=20 >>=20 >> One way to do it would be to generate enough bytes "Bytes" in "JWE = Encrypted Key" for encryption and integrity. >> The CEK is then "Bytes[0 .. cekLength-1]" and the CIK = "Bytes[cekLength .. cekLength+cikLength-1]" >>=20 >>=20 >> Axel >>=20 >> [On some platforms (Firefox/NSS) it might even be nearly impossible = to implement (without extending the platform's functions) because the = build-in digest function is always reset when finalize (doFinal) is = called. The spec of the Concat-KDF says that bytes are generated in a = loop but the digest is NOT reset in the loop.] >>=20 >>=20 >> From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones >> Sent: Monday, October 29, 2012 7:28 AM >> To: jose@ietf.org >> Subject: [jose] Platform Support for JWA Crypto Algorithms >>=20 >> FYI, I posted the table describing support for the JWA algorithms in = common Web development platforms that we discussed at IETF 84. See = http://self-issued.info/?p=3D884. >>=20 >> -- Mike >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_19330349-12BD-42E3-908D-8917BDF90077 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAzMDEzNDY1 NlowIwYJKoZIhvcNAQkEMRYEFPg5pvQm71Whrs59O8aLO7kVJPk8MIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBUGfY193t//QMoDHaEkS9x7voCMfdUxJ7bd1aYvUQEJZYvluxmKMtSoeEY I5RH6tM/Vl4uaWLeXgA3AGURA4t1Ks6sBOGgfoYSsr7VEtQIqfJKdq3ARc9YbUW0an4Tjc4i/qQA NxZ37pGfktsrcRUzausN0oGO1IRPcKQctCmngctQXLNJtSitr9U5M+S/JB+B2NGhJZVqfYkC9LyI DOVgWGSGJumCnKmbdun4HjW9j1SSkka72IqWHJZVJUqZ3Iba9XSvQ2k6VUhmG6a3nvI/47ohjK+T UnlBGrpa+a7sjBI/eP+7qPyCMlBN3uy1bETGpIDl7lyxD775/fTIgOnyAAAAAAAA --Apple-Mail=_19330349-12BD-42E3-908D-8917BDF90077-- From mamille2@cisco.com Tue Oct 30 07:53:42 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 96E8521F8489 for ; Tue, 30 Oct 2012 07:53:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXJjFQiyoZrn for ; Tue, 30 Oct 2012 07:53:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2ED21F8481 for ; Tue, 30 Oct 2012 07:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7905; q=dns/txt; s=iport; t=1351608821; x=1352818421; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zehiK6ANTukAt/BoplSS4gM9jZ88nrBvzB7Yh5LukIA=; b=KWTbceAG2jQjqWjJw3Qzl7IbUGQffEziDBJ8/Xj2GVfhUOEdhWocMbDJ q3ukfpCQW0MASoc5bGLbuJmx+MrzAzZrenED21f/JSzqPntAiSlNmag+x FFbeNhxb4oLrqzBY5KBINtL3zxZGoDxwrBL/fVl9Tj4L8yd46fHxR8qJL Q=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALXpj1CtJV2c/2dsb2JhbABEw0iBCIIeAQEBAwEBAQEPAVsLBQcEAgEIDgMEAQELHQcCJQsUCQgCBA4FCAYNB4deBgucfI9nkDcEi3eFfGEDjnWBIZQ2gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="p7s'?scan'208";a="136913712" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 30 Oct 2012 14:53:41 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9UEreY7018314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 14:53:40 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 09:53:40 -0500 From: "Matt Miller (mamille2)" To: Mike Jones Thread-Topic: [jose] Support for Wrapped Keys? Thread-Index: AQHNsixtFQh89Wn5MUGS4dRC2YkxtZfI+/JAgAlQRoA= Date: Tue, 30 Oct 2012 14:53:40 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436687BED7@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436687BED7@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.62] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--48.550300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_937516A1-B76A-433F-A826-3E309654259E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [jose] Support for Wrapped Keys? 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, 30 Oct 2012 14:53:42 -0000 --Apple-Mail=_937516A1-B76A-433F-A826-3E309654259E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2012, at 4:03 PM, Mike Jones = wrote: > Per our discussions, there's an approach we could discuss that's very = close to what you're already doing. JWE already has a way to encrypt a = key. This key is then currently always used to encrypt the plaintext. >=20 > One obvious solution then appears to be to have no plaintext and only = perform the first of the two steps - create a JWE Encrypted Key value, = leaving the JWE Initialization Vector, JWE Ciphertext, and JWE Integrity = value fields empty. >=20 That would work, but I wonder if this complicates implementation = interfaces too much. Here's what I mean: As far as I can tell, there's no real need for a = user of a JWE implementation to actually know about the CMK. For = encryption, the implementation could generate it using a suitable RNG = based on the (header) parameters, and encode it with the one key = provided by the user. For decryption, it uses parameters from the = header and some determination of the "alg" key (passed in, from a = keystore, etc etc), decrypts the CMK with that key, then decrypts the = ciphertext with the CMK. In this instance, decryption requires at a bare minimum multiple = outputs: plaintext plus the CMK. It might be nice for an implementation = to provide the rest (header, integrity), but these are easily obtained = from the input data in the first place. Personally, I think it would be ideal if there were a way to say "use = this asymmetric key to encrypt the plaintext, but don't worry about a = CMK." I think what we had talked about in Vancouver was effectively to use an = "alg" of "dir" and an "enc" of "RSA-OAEP", which I'm sure has its own = set of objections (aside from currently being disallowed). > The objection that I'm sure people would raise to this obvious = solution is that then the contents of the header and encrypted key are = not integrity protected. One potential solution to this would be to use = an "enc" algorithm that only provides integrity but performs no = encryption. >=20 > The most simple such solution would be to use a cryptographic hash = function such as SHA-256 to compute an integrity value over the other = fields. You could look at this as a degenerate AEAD algorithm, = accepting an "additional authenticated data" input and producing an = "authentication tag" output, but with no plaintext input or ciphertext = output. >=20 > That would give you an integrity-protected encrypted key, doing the = key encryption in the same way that the JWE "alg" values already do. >=20 Personally, I don't really care if there is integrity protection here. = I'm probably alone (with Richard) on this one, though. > Anyway, hopefully the above will at least seed a productive discussion = of the possibilities. I do completely understand the value of Matt's = use case and want us to think about how to best solve it. >=20 - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Matt Miller (mamille2) > Sent: Wednesday, October 24, 2012 2:14 PM > To: > Subject: [jose] Support for Wrapped Keys? >=20 > This is a topic that has been discussed some off-list between myself, = Mike Jones, John Bradley, and Nat Sakimura. >=20 > For XMPP E2E, there is a need to disseminate a "session" master = (symmetric) key between the sender and recipients as a wrapped key. To = date, this is done in a very custom manner by encrypting the session key = with the recipient's public key, and packaging as a partial (read: = broken) JWE value. >=20 > Ideally, I would like a nice way of handling wrapped keys in JWE. The = more standardized alternatives I can see are: >=20 > * Follow JWE, using the session key for both the content key and the = content plaintext (feels very awkward) > * Follow JWE, generating yet-another-CMK and using the session key as = the content plaintext (feels very wasteful) >=20 > Does anyone else think this is worth supporting? >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > PS: JSMS supports wrapped keys, as does CMS. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_937516A1-B76A-433F-A826-3E309654259E 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAzMDE0NTM1 MlowIwYJKoZIhvcNAQkEMRYEFDNaXXa4rdga3GhoWvIlVqDvfAFeMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAElfBH6e8OztmgqypI4PqTeUyqR8rmwxMzX/WPGg1TcvVO+dvOGb/w+qf/ L2/jv5oZsQnV7Wq4X0sm/DDIQPXXRM1jDRiMGTk/3iv7FihJaUmzX4HAoHSO9cm284cpT7ARhjtr ioECboAouaId67khk67c0c/RS6xbVhQguDIdZ20qZu/Re7U+2/US9niTelgxGXjECuSXjCrk9BSt ZJfO/tRZG9ku3Estma0tE538kZzfhUMzwoB+h0zWUnhcfoux7I4NF2al6uV1/MV2vL0+zP3Ajjcf sVK1yMDWWbsH+JEbQc4pkJ7/t4vhUbFDbmfeFRFQRB8zPEWmhlBVyYsxAAAAAAAA --Apple-Mail=_937516A1-B76A-433F-A826-3E309654259E-- From ignisvulpis@gmail.com Wed Oct 31 01:32:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0C21F870B for ; Wed, 31 Oct 2012 01:32:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhdapZIMVSYK for ; Wed, 31 Oct 2012 01:32:20 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4F321F8735 for ; Wed, 31 Oct 2012 01:32:19 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so549925wgb.13 for ; Wed, 31 Oct 2012 01:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pSr7ISRjRU1eg3U40U3ke7hRbWQX59VzMPCPwIdWzz4=; b=u1AioFIXOwGnWIVXJB0CQgp2kk5c79Yl3GfbVmMyULEtU4GcqtdiIQQfjVwnKkORS+ NpDwx7GNrRP5HGPZd0LkZZ1RGpvhP8XlYaByzoH0kUhF6p+fHTRqMSkQ9S5QX35EZbnK 67KEdWEYVygt0fZcSvEhxYFJwserJXCjRSThDqiGai9IyaPyHnibusUCH65s12KxuJQ+ 5lktS6BUT6saWxjEJkUqsMus5V++FCdJZMRjHub3QvKtQZ59KhFkGNk6Amnmw3IGO8e7 zk6EIpFuH11xUpzrUBCti8cYazh5OtaQ546hbkN/FFdOmeGTTc7vtVDitftMbyd3aNj8 zi9A== MIME-Version: 1.0 Received: by 10.180.82.34 with SMTP id f2mr1051736wiy.17.1351672337615; Wed, 31 Oct 2012 01:32:17 -0700 (PDT) Received: by 10.216.54.130 with HTTP; Wed, 31 Oct 2012 01:32:17 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 31 Oct 2012 09:32:17 +0100 Message-ID: From: Axel Nennker To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=f46d044289f689495404cd56bdd8 Cc: Mike Jones , "" , "" , "" Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 31 Oct 2012 08:32:21 -0000 --f46d044289f689495404cd56bdd8 Content-Type: text/plain; charset=ISO-8859-1 I think that https://tools.ietf.org/html/rfc2898 ( https://en.wikipedia.org/wiki/PBKDF2) is a better choice than the concat-kdf from NIST. PBKDF2 does not care whether the password consists of printable characters or whether it is a randomly generated byte strink like our CMK. There is no need to base64url the key/cmk. In the wikipedia article is a list of implementations which sounds much better than our current rows in our crypto-algs compat-table. I suggest we use PBKDF2(HMACSHA1, cmk, iv||"Integrity", 1000) to generate cik and PBKDF2(SHA256, cmk, iv||"Encryption", 1000) to generate the cek. "||" is concatenation. HMACSHA1 as default (MTI) and HMACSHA256 as recommended?! Or we could use my earlier proposal to define the first interation of the concat-kdf as the default for our currently defined encryption algorithms. CIK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43, 72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255] CEK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255] or something along those lines... Axel 2012/10/30 Matt Miller (mamille2) > > On Oct 29, 2012, at 4:24 PM, Mike Jones > wrote: > > > The "PB" in PBKDF2 is "Password Based". This and related KDFs generate > keys from passwords rather than other keys, and so are not applicable for > this use case. > > > > Maybe this is too hacky for people, but: PBKDF2(H, base64url(key), salt, > iters) > > > For lack of a commonly implemented key-based KDF, we chose a very simple > one that only requires support for SHA-256 and SHA-512 to build for our use > cases. (Heck, for our use cases, implementations don't even require a loop > - just a single hash calculation over the input.) I already know of 5 > interoperable implementations at this point. It's just not that hard. > > > > See the example calculations in > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4and > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5to see how simple it actually is. > > > > If we're going for least difficulty, then why not just use key that's > (cipher-len + hash-len) in the first place? > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > -- Mike > > > > -----Original Message----- > > From: Matt Miller (mamille2) [mailto:mamille2@cisco.com] > > Sent: Monday, October 29, 2012 3:16 PM > > To: > > Cc: Mike Jones; ; > > Subject: Re: [jose] Platform Support for JWA Crypto Algorithms > > > > > > On Oct 29, 2012, at 2:46 PM, > > wrote: > > > >> Ease of implementation is relative. Maybe tomorrow I will discover that > the needed concat-KDF is supported "natively" by Mozilla's NSS library. > Then it is very easy. > >> Currently it looks difficult on that platform because the documentation > says that the digest function "finish" resets the digest, which would > probably lead to different results than in the examples in the appendices > A4 and A5. > >> " > http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e > >> NOTE: This method may be called any time after |init| is called. This > call resets the object to its pre-init state. > >> " > >> I still think that some thirty bytes is not much and that generating > the CIK randomly is much easier. I implemented the concat-kdf in java > >> > https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/crypto/KDFConcatGenerator.javaand I know that implementing my proposal below is easier. > >> Anyway: One could ask why the concat-KDF is not implemented in > Bouncycastle while three other KDFs are implemented there. > >> Mozilla implements KDFs too: > >> > https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11skey.c#1437 > >> Although there is no indication in the code which KDF this implements. > Maybe a Mozillian on these lists can clarify. > >> If it is a KDF that is implemented in Bouncycastle too then I suggest > to change the default KDF in JWE to that one. > >> > >> The implementation of KDF can lead to buffer overflows is no secret: > >> https://bugzilla.mozilla.org/show_bug.cgi?id=617565 > >> Which means that KeyDerivationFunction implementation is not as easy as > it could be. > >> > >> Why do you think that the list of NIST's crypto implementations lists > all algs except KDF? > >> > http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.html > >> > >> NIST defines other KDFs too. Why is JWE using one that is implemented > nowhere? Any other choice that is implemented on two platforms is a better > choice than concat-kdf I think. > >> > > > > To add more fuel to the fire: I've seen PBKDF2 is implemented in a few > places, and I think it's only slightly harder to implement as concatKDF. > > > > However, I still think just requiring a larger key is the easiest, least > error-prone approach. > > > > > > - m&m > > > > Matt Miller < mamille2@cisco.com > > > Cisco Systems, Inc. > > > >> Axel > >> > >> > http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e > >> NOTE: This method may be called any time after |init| is called. This > call resets the object to its pre-init state. > >> > >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] > >> Sent: Monday, October 29, 2012 5:25 PM > >> To: Nennker, Axel; jose@ietf.org > >> Cc: public-webcrypto@w3.org > >> Subject: RE: Platform Support for JWA Crypto Algorithms > >> > >> No, Concat often isn't natively supported, but it's very easy to > implement given implementations of SHA-256 and SHA-512, as shown in > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4and > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5 > . > >> > >> When the table was discussed at the WebCrypto F2F, it was pointed out > that a shortcoming of the current table is that it doesn't indicate which > of the "NO" values are effectively show-stoppers and which are easy to > build implementations of, and so not a problem in practice. As shown in > the appendices, I believe that Concat is in the latter category. Given the > ease of implementation, it's certainly not worth adding space to the JWEs > to work around. > >> > >> -- Mike > >> > >> From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] > >> Sent: Monday, October 29, 2012 6:03 AM > >> To: Mike Jones; jose@ietf.org > >> Cc: public-webcrypto@w3.org > >> Subject: RE: Platform Support for JWA Crypto Algorithms > >> > >> As one can see from this table the KDF is unsupported on all platforms > (except one). > >> > http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx > >> > >> JWE > >> > >> kdf > >> > >> CS256 > >> > >> Concat Key Derivation Function (KDF) > >> > >> NO > >> > >> Win7 > >> > >> > >> > >> > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> JWE > >> > >> kdf > >> > >> CS384 > >> > >> Concat Key Derivation Function (KDF) > >> > >> NO > >> > >> Win7 > >> > >> > >> > >> > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> JWE > >> > >> kdf > >> > >> CS512 > >> > >> Concat Key Derivation Function (KDF) > >> > >> NO > >> > >> Win7 > >> > >> > >> > >> > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> > >> > >> NO > >> > >> NO > >> > >> NO > >> > >> > >> Isn't this an indication that we should look at alternatives? > >> > >> e.g.: we could generate the integrity protection key randomly instead > of deriving it from the content encryption key. > >> This would add some more bytes (e.g. about 32) to the jwt but is very > easy to implement on all platforms. > >> > >> > >> One way to do it would be to generate enough bytes "Bytes" in "JWE > Encrypted Key" for encryption and integrity. > >> The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength > .. cekLength+cikLength-1]" > >> > >> > >> Axel > >> > >> [On some platforms (Firefox/NSS) it might even be nearly impossible to > implement (without extending the platform's functions) because the build-in > digest function is always reset when finalize (doFinal) is called. The spec > of the Concat-KDF says that bytes are generated in a loop but the digest is > NOT reset in the loop.] > >> > >> > >> From: jose-bounces@ietf.org [mailto: > jose-bounces@ietf.org] On Behalf Of Mike Jones > >> Sent: Monday, October 29, 2012 7:28 AM > >> To: jose@ietf.org > >> Subject: [jose] Platform Support for JWA Crypto Algorithms > >> > >> FYI, I posted the table describing support for the JWA algorithms in > common Web development platforms that we discussed at IETF 84. See > http://self-issued.info/?p=884. > >> > >> -- 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 > > --f46d044289f689495404cd56bdd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that https://tools.ietf.org/html/rfc2898 (https://en.wikipedia.org/wiki/PBKDF2) is a better choice than the concat-kdf from NIST.
PBKDF2 does not care whether the password consists of printable characters = or whether it is a randomly generated byte strink like our CMK.
There is= no need to base64url the key/cmk.

In the wikipedia article is a lis= t of implementations which sounds much better than our current rows in our = crypto-algs compat-table.

I suggest we use PBKDF2(HMACSHA1, cmk, iv||"Integrity", 1000)= to generate cik and PBKDF2(SHA256, cmk, iv||"Encryption", 1000) = to generate the cek. "||" is concatenation. HMACSHA1 as default (= MTI) and HMACSHA256 as recommended?!

Or we could use my earlier proposal to define the first interation of t= he concat-kdf as the default for our currently defined encryption algorithm= s.
=A0 CIK =3D SHA256(= 0, 0, 0,=20 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43, 72, 83, 50, 53, 54,=20 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255]
=A0 CEK =3D SHA256(0,= =20 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 50,=20 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255]
or something along those = lines...

Axel

2012/10/30 Ma= tt Miller (mamille2) <mamille2@cisco.com>

On Oct 29, 2012, at 4:24 PM, Mike Jones <Michael.Jones@microsoft.com> wrote= :

> The "PB" in PBKDF2 is "Password Based". =A0This an= d related KDFs generate keys from passwords rather than other keys, and so = are not applicable for this use case.
>

Maybe this is too hacky for people, but: PBKDF2(H, base64url(key), sa= lt, iters)

> For lack of a commonly implemented key-based KDF, we chose a very simp= le one that only requires support for SHA-256 and SHA-512 to build for our = use cases. =A0(Heck, for our use cases, implementations don't even requ= ire a loop - just a single hash calculation over the input.) =A0I already k= now of 5 interoperable implementations at this point. =A0It's just not = that hard.
>
> See the example calculations in http= ://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4<= /a> and http://tools.ietf.org/html/draft-= ietf-jose-json-web-encryption-06#appendix-A.5 to see how simple it actu= ally is.
>

If we're going for least difficulty, then why not just use key th= at's (cipher-len + hash-len) in the first place?


- m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: Matt Miller (mamille2) [mailto:mamille2@cisco.com]
> Sent: Monday, October 29, 2012 3:16 PM
> To: <A= xel.Nennker@telekom.de>
> Cc: Mike Jones; <jose@ietf.org>; <public-webcrypto@w3.org>
> Subject: Re: [jose] Platform Support for JWA Crypto Algorithms
>
>
> On Oct 29, 2012, at 2:46 PM, <Axel.Nennker@telekom.de>
> wrote:
>
>> Ease of implementation is relative. Maybe tomorrow I will discover= that the needed concat-KDF is supported "natively" by Mozilla= 9;s NSS library. Then it is very easy.
>> Currently it looks difficult on that platform because the document= ation says that the digest function "finish" resets the digest, w= hich would probably lead to different results than in the examples in the a= ppendices A4 and A5.
>> " http= ://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e= 69aafc30f71ba35da74e
>> NOTE: This method may be called any time after |init| is called. T= his call resets the object to its pre-init state.
>> "
>> I still think that some thirty bytes is not much and that generati= ng the CIK randomly is much easier. I implemented the concat-kdf in java >> http= s://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/cry= pto/KDFConcatGenerator.java and I know that implementing my proposal be= low is easier.
>> Anyway: One could ask why the concat-KDF is not implemented in Bou= ncycastle while three other KDFs are implemented there.
>> Mozilla implements KDFs too:
>> https://mxr.mozilla.or= g/mozilla-central/source/security/nss/lib/pk11wrap/pk11skey.c#1437
>> Although there is no indication in the code which KDF this impleme= nts. Maybe a Mozillian on these lists can clarify.
>> If it is a KDF that is implemented in Bouncycastle too then I sugg= est to change the default KDF in JWE to that one.
>>
>> The implementation of KDF can lead to buffer overflows is no secre= t:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=3D617565=
>> Which means that KeyDerivationFunction implementation is not as ea= sy as it could be.
>>
>> Why do you think that the list of NIST's crypto implementation= s lists all algs except KDF?
>> http://csrc.nist.gov/groups/STM/cav= p/documents/components/componentval.html
>>
>> NIST defines other KDFs too. Why is JWE using one that is implemen= ted nowhere? Any other choice that is implemented on two platforms is a bet= ter choice than concat-kdf I think.
>>
>
> To add more fuel to the fire: I've seen PBKDF2 is implemented in a= few places, and I think it's only slightly harder to implement as conc= atKDF.
>
> However, I still think just requiring a larger key is the easiest, lea= st error-prone approach.
>
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
>
>> Axel
>>
>> http://doxy= gen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc3= 0f71ba35da74e
>> NOTE: This method may be called any time after |init| is called. T= his call resets the object to its pre-init state.
>>
>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
>> Sent: Monday, October 29, 2012 5:25 PM
>> To: Nennker, Axel; jose@ietf.org
>> Cc: p= ublic-webcrypto@w3.org
>> Subject: RE: Platform Support for JWA Crypto Algorithms
>>
>> No, Concat often isn't natively supported, but it's very e= asy to implement given implementations of SHA-256 and SHA-512, as shown in = http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-06#appendix-A.4 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appe= ndix-A.5.
>>
>> When the table was discussed at the WebCrypto F2F, it was pointed = out that a shortcoming of the current table is that it doesn't indicate= which of the "NO" values are effectively show-stoppers and which= are easy to build implementations of, and so not a problem in practice. = =A0As shown in the appendices, I believe that Concat is in the latter categ= ory. =A0Given the ease of implementation, it's certainly not worth addi= ng space to the JWEs to work around.
>>
>> =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: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de]
>> Sent: Monday, October 29, 2012 6:03 AM
>> To: Mike Jones; jose@ietf.org
>> Cc: p= ublic-webcrypto@w3.org
>> Subject: RE: Platform Support for JWA Crypto Algorithms
>>
>> As one can see from this table the KDF is unsupported on all platf= orms (except one).
>> http://self-issued.inf= o/presentations/Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx
>>
>> JWE
>>
>> kdf
>>
>> CS256
>>
>> Concat Key Derivation Function (KDF)
>>
>> NO
>>
>> Win7
>>
>>
>>
>>
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>>
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> JWE
>>
>> kdf
>>
>> CS384
>>
>> Concat Key Derivation Function (KDF)
>>
>> NO
>>
>> Win7
>>
>>
>>
>>
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>>
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> JWE
>>
>> kdf
>>
>> CS512
>>
>> Concat Key Derivation Function (KDF)
>>
>> NO
>>
>> Win7
>>
>>
>>
>>
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>> NO
>>
>>
>>
>> NO
>>
>> NO
>>
>> NO
>>
>>
>> Isn't this an indication that we should look at alternatives?<= br> >>
>> e.g.: we could generate the integrity protection key randomly inst= ead of deriving it from the content encryption key.
>> This would add some more bytes (e.g. about 32) to the jwt but is v= ery easy to implement on all platforms.
>>
>>
>> One way to do it would be to generate enough bytes "Bytes&quo= t; in "JWE Encrypted Key" for encryption and integrity.
>> The CEK is then "Bytes[0 .. cekLength-1]" and the CIK &q= uot;Bytes[cekLength .. cekLength+cikLength-1]"
>>
>>
>> Axel
>>
>> [On some platforms (Firefox/NSS) it might even be nearly impossibl= e to implement (without extending the platform's functions) because the= build-in digest function is always reset when finalize (doFinal) is called= . The spec of the Concat-KDF says that bytes are generated in a loop but th= e digest is NOT reset in the loop.]
>>
>>
>> From: j= ose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org] On Beha= lf Of Mike Jones
>> Sent: Monday, October 29, 2012 7:28 AM
>> To: jose@ietf.o= rg<mailto:jose@ie= tf.org>
>> Subject: [jose] Platform Support for JWA Crypto Algorithms
>>
>> FYI, I posted the table describing support for the JWA algorithms = in common Web development platforms that we discussed at IETF 84. =A0See http://self-is= sued.info/?p=3D884.
>>
>> =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
ht= tps://www.ietf.org/mailman/listinfo/jose


--f46d044289f689495404cd56bdd8-- From mamille2@cisco.com Wed Oct 31 07: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 8530C21F8810 for ; Wed, 31 Oct 2012 07:41:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QoRXeEnMqxN for ; Wed, 31 Oct 2012 07:41:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8058F21F8847 for ; Wed, 31 Oct 2012 07:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4732; q=dns/txt; s=iport; t=1351694503; x=1352904103; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5NLmvu9jMsbMcncYNk+SM1cgz+l13zSRfXDpqjT+UZE=; b=Ax/e+j6ves7R3hoEai+0DPzOFfAxxEH5KByNf+5vfDpAFCpcUniqm7lz S3iIM5sWPIVUr18n+l+e+k3ijpE40OczSbsG5aC0tfAHWvt4zkfJGKTqC 7efXisEgVTKEMItLmRmiWgkjlUhTjfNw3O3OncxR6xu+b9GKhFKE10PDJ k=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHc4kVCtJXHA/2dsb2JhbABEw2yBCIIeAQEBAwESAWYFCwIBCA4UDhYCHxElAgQOBQgGFIdSAwkGC5wUljQNiVAEixFngxmCQWEDjnaBIYQKjQaDJoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="p7s'?scan'208";a="137352383" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 31 Oct 2012 14:41:32 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9VEfXg2024672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 14:41:33 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 09:41:32 -0500 From: "Matt Miller (mamille2)" To: Axel Nennker Thread-Topic: [jose] Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsAACDLiIAAO0JKAAApuFWAAFhIhgAAnTZCAAAznJAA= Date: Wed, 31 Oct 2012 14:41:31 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.62] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--33.907300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_5A6EC4C8-D3DD-4898-ABF1-568A607466BB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Mike Jones , "" , "" , "" Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 31 Oct 2012 14:41:57 -0000 --Apple-Mail=_5A6EC4C8-D3DD-4898-ABF1-568A607466BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 31, 2012, at 2:32 AM, Axel Nennker wrote: > I think that https://tools.ietf.org/html/rfc2898 ( > https://en.wikipedia.org/wiki/PBKDF2) is a better choice than the > concat-kdf from NIST. > PBKDF2 does not care whether the password consists of printable = characters > or whether it is a randomly generated byte strink like our CMK. > There is no need to base64url the key/cmk. >=20 > In the wikipedia article is a list of implementations which sounds = much > better than our current rows in our crypto-algs compat-table. I only suggested base64 encoding the key as a way to get past the = perceptions around the word "password". While RFC 2898 does say: Throughout this document, a password is considered to be an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of UTF-8.) All of the implementations I've used or looked at have interpreted = "password" to simply be an octet string (as per the rest of RFC 2898). - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_5A6EC4C8-D3DD-4898-ABF1-568A607466BB 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAzMTE0NDE0 NVowIwYJKoZIhvcNAQkEMRYEFBdOT1tJ0866pPj2HspYGW+gu0GvMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQASd3m7Q2bIB3tMeWfdLStt/bn+HoAt1niglLszyjJcyCwR6iiuWNJZaYH6 2ZXU1ZGY+3GNxsce7D2jCg7rqws8snK2BvVVCbus2z2Ib2wmhr83dJ7sS4HQwfKURErkVQMsgU0Z 6wx9dOznOOCrXyUFxr6EiC6Xxo+rBpIBYSbFH3JYaqs+GVMscTOUC+GCBqU34ppR6AnoqAq4Woex 3UrNo9JtKy0SczsaAWrP4JY95JRVbuBssUn580a/vg6YT7Sb4kVgcEp6JXJhj8Kwl9y4tFj9D/wM SYweflwyajTW8IOmdYmDo9BZgFlR28+HW+dESAaeqlNvW9Dfkd663Px4AAAAAAAA --Apple-Mail=_5A6EC4C8-D3DD-4898-ABF1-568A607466BB-- From Michael.Jones@microsoft.com Wed Oct 31 08:17:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F77D21F8857 for ; Wed, 31 Oct 2012 08:17:03 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kVFZo01pvdS for ; Wed, 31 Oct 2012 08:17:02 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 76DF121F8829 for ; Wed, 31 Oct 2012 08:17:02 -0700 (PDT) Received: from BL2FFO11FD010.protection.gbl (10.173.161.202) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 31 Oct 2012 15:16:59 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 31 Oct 2012 15:16:58 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Wed, 31 Oct 2012 15:16:39 +0000 From: Mike Jones To: "Matt Miller (mamille2)" Thread-Topic: [jose] Support for Wrapped Keys? Thread-Index: AQHNsixtFQh89Wn5MUGS4dRC2YkxtZfI+/JAgAlQRoCAAUQEoA== Date: Wed, 31 Oct 2012 15:16:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366884C37@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436687BED7@TK5EX14MBXC285.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.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464001)(54094002)(377454001)(52314002)(24454001)(51704002)(47976001)(50986001)(53806001)(47736001)(50466001)(47776002)(44976002)(74502001)(54356001)(49866001)(5343635001)(16406001)(48376001)(5343655001)(4396001)(54316001)(51856001)(33656001)(74662001)(46102001)(550184003)(31966008)(47446002); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06515DA04B Cc: "" Subject: Re: [jose] Support for Wrapped Keys? 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, 31 Oct 2012 15:17:03 -0000 I believe that this is an important discussion. I'd be interested to hear = other's opinions about direct key encryption. For instance, while the work= ing group decided that all plaintext encryption algorithms we used would al= so provide integrity, does the working group believe that integrity is nece= ssary in Matt's case as well? -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mat= t Miller (mamille2) Sent: Tuesday, October 30, 2012 7:54 AM To: Mike Jones Cc: Subject: Re: [jose] Support for Wrapped Keys? On Oct 24, 2012, at 4:03 PM, Mike Jones wrote= : > Per our discussions, there's an approach we could discuss that's very clo= se to what you're already doing. JWE already has a way to encrypt a key. = This key is then currently always used to encrypt the plaintext. >=20 > One obvious solution then appears to be to have no plaintext and only per= form the first of the two steps - create a JWE Encrypted Key value, leaving= the JWE Initialization Vector, JWE Ciphertext, and JWE Integrity value fie= lds empty. >=20 That would work, but I wonder if this complicates implementation interfaces= too much. Here's what I mean: As far as I can tell, there's no real need for a user = of a JWE implementation to actually know about the CMK. For encryption, th= e implementation could generate it using a suitable RNG based on the (heade= r) parameters, and encode it with the one key provided by the user. For de= cryption, it uses parameters from the header and some determination of the = "alg" key (passed in, from a keystore, etc etc), decrypts the CMK with that= key, then decrypts the ciphertext with the CMK. In this instance, decryption requires at a bare minimum multiple outputs: p= laintext plus the CMK. It might be nice for an implementation to provide t= he rest (header, integrity), but these are easily obtained from the input d= ata in the first place. Personally, I think it would be ideal if there were a way to say "use this = asymmetric key to encrypt the plaintext, but don't worry about a CMK." I think what we had talked about in Vancouver was effectively to use an "al= g" of "dir" and an "enc" of "RSA-OAEP", which I'm sure has its own set of o= bjections (aside from currently being disallowed). > The objection that I'm sure people would raise to this obvious solution i= s that then the contents of the header and encrypted key are not integrity = protected. One potential solution to this would be to use an "enc" algorit= hm that only provides integrity but performs no encryption. >=20 > The most simple such solution would be to use a cryptographic hash functi= on such as SHA-256 to compute an integrity value over the other fields. Yo= u could look at this as a degenerate AEAD algorithm, accepting an "addition= al authenticated data" input and producing an "authentication tag" output, = but with no plaintext input or ciphertext output. >=20 > That would give you an integrity-protected encrypted key, doing the key e= ncryption in the same way that the JWE "alg" values already do. >=20 Personally, I don't really care if there is integrity protection here. I'm= probably alone (with Richard) on this one, though. > Anyway, hopefully the above will at least seed a productive discussion of= the possibilities. I do completely understand the value of Matt's use cas= e and want us to think about how to best solve it. >=20 - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of M= att Miller (mamille2) > Sent: Wednesday, October 24, 2012 2:14 PM > To: > Subject: [jose] Support for Wrapped Keys? >=20 > This is a topic that has been discussed some off-list between myself, Mik= e Jones, John Bradley, and Nat Sakimura. >=20 > For XMPP E2E, there is a need to disseminate a "session" master (symmetri= c) key between the sender and recipients as a wrapped key. To date, this i= s done in a very custom manner by encrypting the session key with the recip= ient's public key, and packaging as a partial (read: broken) JWE value. >=20 > Ideally, I would like a nice way of handling wrapped keys in JWE. The mo= re standardized alternatives I can see are: >=20 > * Follow JWE, using the session key for both the content key and the cont= ent plaintext (feels very awkward) > * Follow JWE, generating yet-another-CMK and using the session key as the= content plaintext (feels very wasteful) >=20 > Does anyone else think this is worth supporting? >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > PS: JSMS supports wrapped keys, as does CMS. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From wtc@google.com Wed Oct 31 10:00:52 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 DF89221F877B for ; Wed, 31 Oct 2012 10:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkFPlUazkgic for ; Wed, 31 Oct 2012 10:00:52 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 382D321F872C for ; Wed, 31 Oct 2012 10:00:46 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2738299iec.31 for ; Wed, 31 Oct 2012 10:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=6pvfWbocKoggoVdY0lYe6dzSK/YV395euScaw3bmjZc=; b=YsjkYA9zAhoP3y80kTaqOn+Ln1G+vQo+mdZDJqQ0NDJ2jUgWIT4lW9jGZbIoK7oV9z XwsbILIk+OTKM+SWsxbAeIgBO7N/CkvcU2rpA9iMqeN4eNFfV7sqgVmrf75SRpyDIrEy dJREPyJ7CC/nfpo80gtPMl9727UJwaBSX8jcFdhq8etOWQfijVXh7Yfqi6ATowLfMnyn z98cMt57Y+pkde3+Hgn+EnLLUSzal2l9mPy6SqWeT4QFLFyuywB8RW1pLdBnO6gvBP7f kC9mTFZoPjs+U2mwodsSv4u5gRjyk+pvbCuNr/G7sIjTwcxokqG6mFfisIavv7L951+u d6LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=6pvfWbocKoggoVdY0lYe6dzSK/YV395euScaw3bmjZc=; b=lnm1j1UOU3DsfAIC042DNvvIbAkuasAYduot2CtHyu/P/21JPqCbVromYIiSfMOewt P8nzkPkFMzTBd5TckL+HzpbX2+c8Jrx8WCaXv+xGvSDS2+lY3Pmog5q1AZRzlo3L4iwD EDbN6kvBQp920dzg2XbdEdL/AZX4LOzCv42HHz7xNBtmJ1dNlPuv1Z4lC4C3gQee5FSl m+6a/tplwr/btU2SYSpz2Xp6Y1HggEG4UVw12tCnHahoDx9BnACJop+O23MHpmO7XYiD I6FpbcTX80G1tQnAD0RTAMqRCe3Q/mccYQgohjYmvgJEPsCoCIXmdILIegOx0UkYBzIc bK2g== MIME-Version: 1.0 Received: by 10.50.5.239 with SMTP id v15mr2272657igv.41.1351702845763; Wed, 31 Oct 2012 10:00:45 -0700 (PDT) Received: by 10.231.6.83 with HTTP; Wed, 31 Oct 2012 10:00:45 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 31 Oct 2012 10:00:45 -0700 Message-ID: From: Wan-Teh Chang To: Ryan Sleevi Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlXf218TWz5n/1ueUOclgJk3ItvtkSAkrcERSeu54GsCHhosd6zBKQ0lap818xL9kKRTPeBoapuHLR/ieil9j7t+ARu/MU7vAjjSrnXdbIz0kX7A6IQfv0+gexqCdHpDc2cQgSjr5k1keEIC++rYKBZydx8SehxTZY09U/YeLiE6QProISzSlQl2jwrS39Mtxi+TNLP X-Mailman-Approved-At: Wed, 31 Oct 2012 13:34:29 -0700 Cc: Michael.Jones@microsoft.com, jose@ietf.org, Axel.Nennker@telekom.de, public-webcrypto@w3.org Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 31 Oct 2012 17:00:53 -0000 On Mon, Oct 29, 2012 at 4:23 PM, Ryan Sleevi wrote: > > However, as an NSS developer, I do not see your presented argument as a > reason not to use Concat-KDF, and Concat-KDF would be more preferable, as a > NIST-blessed KDF, since NSS cares especially for NIST-blessed algorithms. I think HKDF (hash-based key derivation function) is also worth considering. It is specified in RFC 5869 and is also blessed by NIST in SP 800-56C. Wan-Teh From ignisvulpis@gmail.com Wed Oct 31 14:15: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 594F421F868B for ; Wed, 31 Oct 2012 14:15:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfBmQ8UyYzo8 for ; Wed, 31 Oct 2012 14:15:53 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA1A821F8675 for ; Wed, 31 Oct 2012 14:15:52 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so951745wey.31 for ; Wed, 31 Oct 2012 14:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0swRI+urtpBuw+FwktKhhhT3e9pO1c9wMng0DL/gvgI=; b=EP544N6C7Bwi+wMh0Uzsvz7FPB3tXoxH4fCTrl478aiVTC7gPNL7agDMZPWNS2z0OA bDP7aam7xy3qEoJwJ/1AQMweBRc0XS935vVfd0Tdyoft31xKcfxZXCp4dEEd2tSO7hth zJZYv6rGcw2pCIuMBQVl20AtxQ6EccKGatJp7c8Nwr1hcgiU5Ag6UNUs59+NSqtqzAOS KV+zZNlKyLaaNXpZq8n3Wq+gnpo+ar1vddxAO7CnuZtl2HyLTywljCL9LxRKw9NwwzZN /Wy/wfyNWSSfWDd5H+4LiYVKMOdN0q6CGGMzKvI9NMXlrEDsAPQ/OlO7JmVqKlSJ1K2Q PykQ== MIME-Version: 1.0 Received: by 10.180.94.102 with SMTP id db6mr4744551wib.20.1351718152085; Wed, 31 Oct 2012 14:15:52 -0700 (PDT) Received: by 10.216.54.130 with HTTP; Wed, 31 Oct 2012 14:15:51 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 31 Oct 2012 22:15:51 +0100 Message-ID: From: Axel Nennker To: Wan-Teh Chang Content-Type: multipart/alternative; boundary=f46d0442720a4aa0b104cd616898 Cc: Michael.Jones@microsoft.com, public-webcrypto@w3.org, Ryan Sleevi , jose@ietf.org, Axel.Nennker@telekom.de Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 31 Oct 2012 21:15:54 -0000 --f46d0442720a4aa0b104cd616898 Content-Type: text/plain; charset=ISO-8859-1 I think we need a table with the same platform as in Mike's table that started this discussion with KDFs that actually have implementations. Specification in RFCs or blessing by NIST does not count. Implementations rule. Usage Param Name Param Val Description .NET Windows native OS X iOS Java JCA BouncyCastle Android PHP PHPSecLib Python M2Crypto PyCrypto Ruby OpenSSL node.js NSS JWE kdf CS256 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO Axel 2012/10/31 Wan-Teh Chang > On Mon, Oct 29, 2012 at 4:23 PM, Ryan Sleevi wrote: > > > > However, as an NSS developer, I do not see your presented argument as a > > reason not to use Concat-KDF, and Concat-KDF would be more preferable, > as a > > NIST-blessed KDF, since NSS cares especially for NIST-blessed algorithms. > > I think HKDF (hash-based key derivation function) is also worth > considering. > It is specified in RFC 5869 and is also blessed by NIST in SP 800-56C. > > Wan-Teh > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d0442720a4aa0b104cd616898 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we need a table with the same platform as in Mike's table that = started this discussion with KDFs that actually have implementations.
Sp= ecification in RFCs or blessing by NIST does not count. Implementations rul= e.

= <= /colgroup>
Usage Param Name Param Val Description .NET Windows native OS X iOS Java JCA BouncyCastle Android PHP PHPSecLib Python M2Crypto PyCrypto Ruby OpenSSL node.js NSS
JWE kdf CS256 C= oncat Key Derivation Function (KDF) NO Win7 =A0= =A0= NO NO NO NO NO NO NO NO =A0= NO NO NO
JWE kdf CS384 Concat Key = Derivation Function (KDF) NO Win7 =A0 =A0 NO NO NO NO NO NO NO NO =A0 NO NO NO
JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7 =A0 =A0 NO NO NO NO NO NO NO NO =A0 NO NO NO


Axel


2012/10/= 31 Wan-Teh Chang <wtc@google.com>
On Mon, Oct 29, 2012 at 4:23 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
> However, as an NSS developer, I do not see your presented argument as = a
> reason not to use Concat-KDF, and Concat-KDF would be more preferable,= as a
> NIST-blessed KDF, since NSS cares especially for NIST-blessed algorith= ms.

I think HKDF (hash-based key derivation function) is also worth considering= .
It is specified in RFC 5869 and is also blessed by NIST in SP 800-56C.

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

--f46d0442720a4aa0b104cd616898-- From Michael.Jones@microsoft.com Wed Oct 31 14:22: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 AE1E621F84F2 for ; Wed, 31 Oct 2012 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph3UOkKQ07UQ for ; Wed, 31 Oct 2012 14:22:49 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5A021F845E for ; Wed, 31 Oct 2012 14:22:48 -0700 (PDT) Received: from BY2FFO11FD004.protection.gbl (10.1.15.200) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 31 Oct 2012 21:22:45 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 31 Oct 2012 21:22:44 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 31 Oct 2012 21:22:08 +0000 From: Mike Jones To: Axel Nennker , Wan-Teh Chang Thread-Topic: [jose] Platform Support for JWA Crypto Algorithms Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsAACDLiIAAGrwcAAFc3J4AACOjGgAAAFHHQ Date: Wed, 31 Oct 2012 21:22:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366885038@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366885038TK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(479174001)(377454001)(51704002)(46102001)(50986001)(16406001)(33656001)(5343655001)(47736001)(47976001)(51856001)(49866001)(53806001)(31966008)(54316001)(44976002)(15202345001)(47446002)(5343635001)(74502001)(512954001)(74662001)(4396001)(54356001)(550254004); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06515DA04B Cc: "public-webcrypto@w3.org" , Ryan Sleevi , "jose@ietf.org" , "Axel.Nennker@telekom.de" Subject: Re: [jose] Platform Support for JWA Crypto Algorithms 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, 31 Oct 2012 21:22:50 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366885038TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that this would be useful, but the other factor that's critical is = ability to implement when your developer platform doesn't have native suppo= rt. As demonstrated in the appendices, it's trivial to implement Concat wi= th only SHA-256 and SHA-512. So direct platform support for Concat is actu= ally a non-issue for interoperability, as anyone can build it themselves wi= th a few string concat operations and a single hash. If other KDFs aren't built-in to all platforms, the key criteria for consid= ering them is that the primitives needed to build them must be (just as the= y already are for Concat). = -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l Nennker Sent: Wednesday, October 31, 2012 2:16 PM To: Wan-Teh Chang Cc: Mike Jones; public-webcrypto@w3.org; Ryan Sleevi; jose@ietf.org; Axel.N= ennker@telekom.de Subject: Re: [jose] Platform Support for JWA Crypto Algorithms I think we need a table with the same platform as in Mike's table that star= ted this discussion with KDFs that actually have implementations. Specification in RFCs or blessing by NIST does not count. Implementations r= ule. Usage Param Name Param Val Description .NET Windows native OS X iOS Java JCA BouncyCastle Android PHP PHPSecLib Python M2Crypto PyCrypto Ruby OpenSSL node.js NSS JWE kdf CS256 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO Axel 2012/10/31 Wan-Teh Chang > On Mon, Oct 29, 2012 at 4:23 PM, Ryan Sleevi > wrote: > > However, as an NSS developer, I do not see your presented argument as a > reason not to use Concat-KDF, and Concat-KDF would be more preferable, as= a > NIST-blessed KDF, since NSS cares especially for NIST-blessed algorithms. I think HKDF (hash-based key derivation function) is also worth considering= . It is specified in RFC 5869 and is also blessed by NIST in SP 800-56C. Wan-Teh _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366885038TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that this would b= e useful, but the other factor that’s critical is ability to implement when your developer platform doesn’= ;t have native support.  As demonstrated in the appendices, it’s= trivial to implement Concat with only SHA-256 and SHA-512.  So direct= platform support for Concat is actually a non-issue for interoperability, as anyone can build it themselves with a few string conc= at operations and a single hash.

 <= /p>

If other KDFs aren’= t built-in to all platforms, the key criteria for considering them is that = the primitives needed to build them must be (just as they already are for Concat).

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel Nennker
Sent: Wednesday, October 31, 2012 2:16 PM
To: Wan-Teh Chang
Cc: Mike Jones; public-webcrypto@w3.org; Ryan Sleevi; jose@ietf.org;= Axel.Nennker@telekom.de
Subject: Re: [jose] Platform Support for JWA Crypto Algorithms<= /o:p>

 

I think we need a tab= le with the same platform as in Mike's table that started this discussion w= ith KDFs that actually have implementations.
Specification in RFCs or blessing by NIST does not count. Implementations r= ule.

Usage<= /b>

Param Name

Param Val

Description

.NET

Windows native

OS X

iOS

Java JCA

BouncyCastle<= /span>

Android

PHP

PHPSecLib

Python=

M2Crypto

PyCrypto

Ruby

OpenSSL

node.js

NSS

 

JWE

kdf

CS256

Concat Key Derivation Function (KDF)

NO

Win7

 

 

NO

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

NO

JWE

kdf

CS384

Concat Key Derivation Function (KDF)

NO

Win7

 

 

NO

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

NO

JWE

kdf

CS512

Concat Key Derivat= ion Function (KDF)

NO

Win7

 

 

NO

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

NO



Axel

2012/10/31 Wan-Teh Chang <wtc@google.com>

On Mon, Oct 29, 2012 at 4:23 PM, Ryan Sleevi <sleevi@google.com&g= t; wrote:
>
> However, as an NSS developer, I do not see your presented argument as = a
> reason not to use Concat-KDF, and Concat-KDF would be more preferable,= as a
> NIST-blessed KDF, since NSS cares especially for NIST-blessed algorith= ms.

I think HKDF (hash-based key derivation function) is also worth considering= .
It is specified in RFC 5869 and is also blessed by NIST in SP 800-56C.

Wan-Teh

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366885038TK5EX14MBXC285r_--