From vladimir@nimbusds.com Fri Jun 1 04:45: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 CE63821F8659 for ; Fri, 1 Jun 2012 04:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehp2GnA1wORi for ; Fri, 1 Jun 2012 04:45:33 -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 853B421F8501 for ; Fri, 1 Jun 2012 04:45:32 -0700 (PDT) Received: (qmail 26427 invoked from network); 1 Jun 2012 11:45:29 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 1 Jun 2012 11:45:29 -0000 Received: (qmail 25212 invoked by uid 99); 1 Jun 2012 11:45:28 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.79.251 User-Agent: Workspace Webmail 5.6.18 Message-Id: <20120601044527.cc40c4f3d92d2001859047cd8cabb9ab.306925200a.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Fri, 01 Jun 2012 04:45:27 -0700 Mime-Version: 1.0 Subject: Re: [jose] Suggestion for new term: JSON Web Object (JWO) or JSON Web Message (JWM) 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, 01 Jun 2012 11:45:34 -0000 =0A> > After a bit of brain storming two favourites emerged:=0A> > =0A> > J= SON Web Object (JWO)=0A> > =0A> > and=0A> > =0A> > JSON Web Message (JWM).= =0A> =0A> =0A> JWO and JWM are both missing the security angle, which is th= e primary reason for JOSE.=0A> =0A> How about "JWsec", and I would call the= spec "JSON Web Message Security Format".=0A=0ASounds good. I need to diges= t it a bit though :)=0A=0ATo me an ideal name is one that is meaningful, co= ncise and can result in=0Aa reasonably short acronym or abbreviation.=0A=0A= =0A> I don't think we will need separate acronyms for specific modes once w= e have a nickname for the top-level structure. For instance, say "signed JW= sec" and "encrypted JWsec", instead of JWS and JWE.=0A=0AYes, once we have = a common name/acronym for these messages, there would=0Abe less of a need t= o have the current set of acronyms (JWS, JWE, JWA,=0AJWK).=0A=0AHowever, wh= en we put "signed" etc in front of "JWsec" the phrase becomes=0Aa bit awkwa= rd. An acronym that still makes sense when unrolled with an=0Aadjective in = front of it would fit better.=0A=0ATo illustrate - "signed JWsec" -> "signe= d JSON Web Message Security=0AFormat".=0A=0AHow about having JWsec refer to= the format and JWM refer to the=0Aresulting messages?=0A=0AWe would then h= ave:=0A=0A* JSON Web Message (JWM) - A message that follows the JSON Web Me= ssage=0ASecurity Format (JWsec).=0A=0A* signed JWM - signed JSON Web Messag= e=0A=0A* encrypted JWM - encrypted JSON Web Message=0A=0A* plain/unprotecte= d JWM - ...=0A=0A* JWM key - ...=0A=0A* JWM algorithm - ...=0A=0A=0AWhat do= you guys think?=0A=0A=0AVladimir=0A=0A=0A=0A From vladimir@nimbusds.com Fri Jun 1 04:52: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 9635921F8619 for ; Fri, 1 Jun 2012 04:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtb4n-GKHMoM for ; Fri, 1 Jun 2012 04:52:05 -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 06EA021F85C9 for ; Fri, 1 Jun 2012 04:51:58 -0700 (PDT) Received: (qmail 13699 invoked from network); 1 Jun 2012 11:51:58 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 1 Jun 2012 11:51:58 -0000 Received: (qmail 18101 invoked by uid 99); 1 Jun 2012 11:51:58 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.79.251 User-Agent: Workspace Webmail 5.6.18 Message-Id: <20120601045157.cc40c4f3d92d2001859047cd8cabb9ab.03891e2067.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "jose@ietf.org" Date: Fri, 01 Jun 2012 04:51:57 -0700 Mime-Version: 1.0 Subject: Re: [jose] =?utf-8?q?Allow_compression_of_plain_and_JWS_too=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: Fri, 01 Jun 2012 11:52:07 -0000 Thanks for the figures James. This looks like a good case to make=0ADEFLATE= a standard option for all messages types.=0A=0AVladimir=0A=0A--=0AVladimir= Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A=0A-------- Orig= inal Message --------=0ASubject: RE: [jose] Allow compression of plain and = JWS too?=0AFrom: "Manger, James H" =0ADate= : Thu, May 31, 2012 3:01 pm=0ATo: Vladimir Dzhuvinov / NimbusDS ,=0A"jose@ietf.org" =0A=0A> Is there a reason to= have compression only with JWE?=0A=0ACompression should be available in si= gned and unprotected messages as=0Awell. Specifying the "zip" header elemen= t for signed JWsec messages (aka=0AJWS) and unprotected JWsec messages (aka= "alg":"none") would be a good=0Aapproach.=0A=0A=0AThe DEFLATE algorithm do= es a really good job of almost eliminating the=0A33% overhead introduced by= a base64url encoding.=0A* DEFLATE(B64(random)) is only 1% longer than rand= om=0A* DEFLATE(B64(DEFLATE(text))) is less than 1% longer than DEFLATE(text= )=0A* DEFLATE(B64(text)) however is significantly longer than DEFLATE(text)= =0A=0A--=0AJames Manger=0A From vladimir@nimbusds.com Fri Jun 1 05:16: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 0FD0621F869D for ; Fri, 1 Jun 2012 05:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-tIYikKHYx4 for ; Fri, 1 Jun 2012 05:16:01 -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 9654F21F8951 for ; Fri, 1 Jun 2012 05:15:43 -0700 (PDT) Received: (qmail 26210 invoked from network); 1 Jun 2012 12:15:36 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 1 Jun 2012 12:15:36 -0000 Received: (qmail 9791 invoked by uid 99); 1 Jun 2012 12:15:36 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.79.251 User-Agent: Workspace Webmail 5.6.18 Message-Id: <20120601051535.cc40c4f3d92d2001859047cd8cabb9ab.4028586602.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "jose@ietf.org" Date: Fri, 01 Jun 2012 05:15:35 -0700 Mime-Version: 1.0 Subject: Re: [jose] JOSE top-level syntax proposal 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, 01 Jun 2012 12:16:02 -0000 > I think the (nice looking) Nimbus code, for instance, =0A> splits on dots= , base64url-decodes, interprets as UTF-8, =0A> parses as JSON, extracts the= "alg" element, looks up =0A> the alg value to learn its type... then sees = it is an =0A> encrypted message and passes the original string to the =0A> = encryption code (where splitting/decoding/interpreting/=0A> parsing happens= all over again).=0A=0AYes, it is indeed so.=0A=0AAn alternative would be t= o pass both the decoded header =0AJSON and the entire raw message (because = the raw header is=0Arequired for signature verification). I didn't do it=0A= because that would make the subclass APIs more complicated =0Aand a bit awk= ward too. =0A=0AI don't know how much performance is lost there, however.= =0A=0A=0A> For instance, a web app firewall might perform some =0A> sanity = checks on the content.=0A=0AI understand. I think that was your initial con= cern when=0Ayou first brought up the issue.=0A=0A=0A> Or (if your app accep= ts unprotected and signed =0A> messages), you can convert a signed message = to an =0A> unprotected one when the signing algorithm is =0A> unrecognized.= At least that doesn't punish the sender =0A> for trying to offer some secu= rity (by signing), even =0A> if you don't support that algorithm yet.=0A=0A= The current format doesn't make this impossible.=0A=0A=0A> As a bonus, a me= ssage's mode is instantly obvious to =0A> developers (without cut 'n pastin= g a header into a =0A> base64url decoding tool).=0A=0AYes, this can be hand= y.=0A=0A=0AI'm still neutral on this proposal and would like to see=0Awhat = the others think. In terms of coding to update our=0Aexisting library it do= esn't seem like much work.=0A=0A=0AVladimir=0A From vladimir@nimbusds.com Fri Jun 1 05:25: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 7CDC311E81B0 for ; Fri, 1 Jun 2012 05:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UNRG4beOuQV for ; Fri, 1 Jun 2012 05:25:58 -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 4DE0411E829B for ; Fri, 1 Jun 2012 05:25:58 -0700 (PDT) Received: (qmail 32594 invoked from network); 1 Jun 2012 12:25:57 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 1 Jun 2012 12:25:55 -0000 Received: (qmail 19892 invoked by uid 99); 1 Jun 2012 12:25:55 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.79.251 User-Agent: Workspace Webmail 5.6.18 Message-Id: <20120601052554.cc40c4f3d92d2001859047cd8cabb9ab.10afebca6a.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: Axel.Nennker@telekom.de, jose@ietf.org Date: Fri, 01 Jun 2012 05:25:54 -0700 Mime-Version: 1.0 Subject: Re: [jose] ECDH-ES in Java 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: Fri, 01 Jun 2012 12:25:59 -0000 Thank you Axel. I had a quick look at the code to see what it would take=0A= to incorporate it into Nimbus-JWT and looks OK.=0A=0AI suppose we don't hav= e any normative test vectors for ECDH-ES yet?=0A=0AVladimir=0A=0A--=0AVladi= mir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A=0A-------- O= riginal Message --------=0ASubject: ECDH-ES in Java for JWE=0AFrom: =0ADate: Thu, May 31, 2012 4:06 pm=0ATo: , =0A=0A=0AI whipped something up that I think is not= completely bogus.=0A=0AEncryption:=0Ahttps://code.google.com/p/openinfocar= d/source/browse/trunk/src/org/xmldap/json/WebToken.java#699=0A=0ADecryption= :=0Ahttps://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmld= ap/json/WebToken.java#644=0A=0AKDFConcatGenerator:=0Ahttps://code.google.co= m/p/openinfocard/source/browse/trunk/src/org/xmldap/crypto/KDFConcatGenerat= or.java=0A=0AJUNIT test cases:=0Ahttps://code.google.com/p/openinfocard/sou= rce/browse/trunk/testsrc/org/xmldap/json/WebTokenTest.java#723=0A=0AI know = the code needs more work to make it adhere to the spec. Currently=0AI am no= t using the epk field but x and y but the semantic should be the=0Asame I h= ope.=0A=0AHave fun=0AAxel=0A From Axel.Nennker@telekom.de Fri Jun 1 06:50: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 59B5111E81F4 for ; Fri, 1 Jun 2012 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GD-gOnPhXh3 for ; Fri, 1 Jun 2012 06:50:20 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE8811E817D for ; Fri, 1 Jun 2012 06:50:18 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 01 Jun 2012 15:50:02 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.88]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Fri, 1 Jun 2012 15:49:46 +0200 From: To: , Date: Fri, 1 Jun 2012 15:49:57 +0200 Thread-Topic: ECDH-ES in Java for JWE Thread-Index: Ac0/8bKc1mP1LxhuQXKsb60iFgZArAAC1+UA Message-ID: References: <20120601052554.cc40c4f3d92d2001859047cd8cabb9ab.10afebca6a.wbe@email07.europe.secureserver.net> In-Reply-To: <20120601052554.cc40c4f3d92d2001859047cd8cabb9ab.10afebca6a.wbe@email07.europe.secureserver.net> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] ECDH-ES in Java 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: Fri, 01 Jun 2012 13:50:21 -0000 SnVzdCBwb3N0ZWQgdGhpcyBodHRwOi8vaWduaXN2dWxwaXMuYmxvZ3Nwb3QuZGUvMjAxMi8wNi9l Y2RoLWVzLWZvci1qc29uLXdlYi1lbmNyeXB0aW9uLmh0bWwgd2hpY2ggY29udGFpbnMgbW9yZSBk ZXRhaWxzIGFuZCBzb21lIHRlc3QgdmFsdWVzLg0KQWx0aG91Z2ggSSB3b3VsZCBub3QgY2FsbCB0 aGVtIG5vcm1hdGl2ZS4NCldvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhbm90aGVyIGltcGxlbWVudGF0 aW9uIHRvIHZlcmlmeSBteSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc3BlYy4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTIFtt YWlsdG86dmxhZGltaXJAbmltYnVzZHMuY29tXSANClNlbnQ6IEZyaWRheSwgSnVuZSAwMSwgMjAx MiAyOjI2IFBNDQpUbzogTmVubmtlciwgQXhlbDsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IEVDREgtRVMgaW4gSmF2YSBmb3IgSldFDQoNClRoYW5rIHlvdSBBeGVsLiBJIGhhZCBhIHF1aWNr IGxvb2sgYXQgdGhlIGNvZGUgdG8gc2VlIHdoYXQgaXQgd291bGQgdGFrZSB0byBpbmNvcnBvcmF0 ZSBpdCBpbnRvIE5pbWJ1cy1KV1QgYW5kIGxvb2tzIE9LLg0KDQpJIHN1cHBvc2Ugd2UgZG9uJ3Qg aGF2ZSBhbnkgbm9ybWF0aXZlIHRlc3QgdmVjdG9ycyBmb3IgRUNESC1FUyB5ZXQ/DQoNClZsYWRp bWlyDQoNCi0tDQpWbGFkaW1pciBEemh1dmlub3YgOiB3d3cuTmltYnVzRFMuY29tIDogdmxhZGlt aXJAbmltYnVzZHMuY29tDQoNCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0K U3ViamVjdDogRUNESC1FUyBpbiBKYXZhIGZvciBKV0UNCkZyb206IDxBeGVsLk5lbm5rZXJAdGVs ZWtvbS5kZT4NCkRhdGU6IFRodSwgTWF5IDMxLCAyMDEyIDQ6MDYgcG0NClRvOiA8dmxhZGltaXJA bmltYnVzZHMuY29tPiwgPGpvc2VAaWV0Zi5vcmc+DQoNCg0KSSB3aGlwcGVkIHNvbWV0aGluZyB1 cCB0aGF0IEkgdGhpbmsgaXMgbm90IGNvbXBsZXRlbHkgYm9ndXMuDQoNCkVuY3J5cHRpb246DQpo dHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL29wZW5pbmZvY2FyZC9zb3VyY2UvYnJvd3NlL3RydW5r L3NyYy9vcmcveG1sZGFwL2pzb24vV2ViVG9rZW4uamF2YSM2OTkNCg0KRGVjcnlwdGlvbjoNCmh0 dHBzOi8vY29kZS5nb29nbGUuY29tL3Avb3BlbmluZm9jYXJkL3NvdXJjZS9icm93c2UvdHJ1bmsv c3JjL29yZy94bWxkYXAvanNvbi9XZWJUb2tlbi5qYXZhIzY0NA0KDQpLREZDb25jYXRHZW5lcmF0 b3I6DQpodHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL29wZW5pbmZvY2FyZC9zb3VyY2UvYnJvd3Nl L3RydW5rL3NyYy9vcmcveG1sZGFwL2NyeXB0by9LREZDb25jYXRHZW5lcmF0b3IuamF2YQ0KDQpK VU5JVCB0ZXN0IGNhc2VzOg0KaHR0cHM6Ly9jb2RlLmdvb2dsZS5jb20vcC9vcGVuaW5mb2NhcmQv c291cmNlL2Jyb3dzZS90cnVuay90ZXN0c3JjL29yZy94bWxkYXAvanNvbi9XZWJUb2tlblRlc3Qu amF2YSM3MjMNCg0KSSBrbm93IHRoZSBjb2RlIG5lZWRzIG1vcmUgd29yayB0byBtYWtlIGl0IGFk aGVyZSB0byB0aGUgc3BlYy4gQ3VycmVudGx5IEkgYW0gbm90IHVzaW5nIHRoZSBlcGsgZmllbGQg YnV0IHggYW5kIHkgYnV0IHRoZSBzZW1hbnRpYyBzaG91bGQgYmUgdGhlIHNhbWUgSSBob3BlLg0K DQpIYXZlIGZ1bg0KQXhlbA0KDQo= From ietf@augustcellars.com Sun Jun 3 11:10:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC9B21F845C for ; Sun, 3 Jun 2012 11:10:10 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJNAWB7UwPgZ for ; Sun, 3 Jun 2012 11:10:09 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B821F8454 for ; Sun, 3 Jun 2012 11:10:09 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (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 CDC9538F16; Sun, 3 Jun 2012 11:10:08 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <255B9BB34FB7D647A506DC292726F6E114F4FC08C1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4FC08C1@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 3 Jun 2012 11:08:56 -0700 Message-ID: <066701cd41b3$f1754bc0$d45fe340$@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: AQIP3/RsifqcjyR58+ljXztrAdTAJpZjp9ZA Content-Language: en-us Subject: Re: [jose] JOSE top-level syntax proposal X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 18:10:10 -0000 How would you extend this to deal with the alternative encoding format? This only addresses the issue for the dot form of encoding. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Wednesday, May 30, 2012 5:56 PM > To: jose@ietf.org > Subject: [jose] JOSE top-level syntax proposal > > Here is a concrete proposal for the syntax of JOSE messages that explicitly > indicates the mode of protection, independently of specific algorithm values. > > jwsec = ("Z" "." header64 "." compressed64) / > ("S" "." header64 "." data64 "." signature64) / > ("I" "." header64 "." data64 "." checksum64) / > ("E" "." header64 "." enckey64 "." ciphertext64 "." mac64) / > (ext "." header64 *("." component64)) > > ext = 1*b64url ; future modes > > header64 = 1*b64url ; base64url-encoded UTF-8-encoded JSON object > > ; the following 8 items hold base64url-encoded byte arrays > compressed64 = *b64url > data64 = *b64url > signature64 = *b64url > checksum64 = *b64url > enckey64 = *b64url > ciphertext64 = *b64url > mac64 = *b64url > component64 = *b64url > > b64url = %x41-5A / %x61-7A / %x30-39 / %x2D / %x5F > ; A-Z a-z 0-9 - _ > > Mode "Z" carries unsecured data that is optionally compressed. > Mode "I" carries unsecured data with a checksum to detect accidental errors. > Mode "S" provide data origin authentication. > Mode "E" provides confidentiality. > > -- > James Manger > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Sun Jun 3 11:24: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 A7B8421F854C for ; Sun, 3 Jun 2012 11:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIVGUGPPo7Rn for ; Sun, 3 Jun 2012 11:24:09 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4774221F853B for ; Sun, 3 Jun 2012 11:24:09 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1DF1138EF8 for ; Sun, 3 Jun 2012 11:24:09 -0700 (PDT) From: "Jim Schaad" To: Date: Sun, 3 Jun 2012 11:22:56 -0700 Message-ID: <066801cd41b5$e63fcf80$b2bf6e80$@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: Ac1BtFQuWxXrJ2JcQdivhiunPGbSqw== Content-Language: en-us Subject: [jose] Discussion Topic - Lets kill all non AEAD 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: Sun, 03 Jun 2012 18:24:09 -0000 The message title is deliberately provocative, but does indicate the path that I think we should follow for the document. Specifically what I would like to do is to remove the non AEAD algorithms and replace them with AEAD algorithms that are, more or less, equivalent. This means that I would like define three new algorithms AES128-HS256, AES256-HS256 and AES512-HS512 that are AEAD algorithms. Advantages: 1. The header is smaller as we can eliminate the "int:" field 2. We make it clear that non-AEAD algorithms are not permitted and put it on the algorithm definer and not on the implementer to fix the problem if the proposed algorithm is not an AEAD algorithm. 3. It makes the encryption document simpler as there is now only one encryption/decrypt set of steps to follow. 4. The KDF moves from JWE to JWA where it more properly belongs 5. The KDF now becomes an implicit parameter of the algorithm and it is easy to change it for an updated one later as necessary for specific algorithms. As it currently stands there is no easy way to change this on an algorithm by algorithm basis. This means that we can use SHA-256 for the first two algorithms and SHA-512 for the last one - this means that we don't "lose bits" in the process of doing the KDF. 6. The test matrix becomes smaller for implementers as there is a list rather than a matrix of possible functions to look at. From James.H.Manger@team.telstra.com Sun Jun 3 17:13: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 AAB5D21F8796 for ; Sun, 3 Jun 2012 17:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.738 X-Spam-Level: X-Spam-Status: No, score=-0.738 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwT36pH8G3Mq for ; Sun, 3 Jun 2012 17:13:33 -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 D12D721F8794 for ; Sun, 3 Jun 2012 17:13:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,710,1330866000"; d="scan'208";a="75540290" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 04 Jun 2012 10:13:29 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6731"; a="15297750" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcani.tcif.telstra.com.au with ESMTP; 04 Jun 2012 10:13:29 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 4 Jun 2012 10:13:28 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Mon, 4 Jun 2012 10:13:27 +1000 Thread-Topic: [jose] Discussion Topic - Lets kill all non AEAD algorithms Thread-Index: Ac1BtFQuWxXrJ2JcQdivhiunPGbSqwALZbzA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F50B41C8@WSMSG3153V.srv.dir.telstra.com> References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> In-Reply-To: <066801cd41b5$e63fcf80$b2bf6e80$@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] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 00:13:33 -0000 SmltIFNjaGFhZCBzYWlkOg0KPiBUaGUgbWVzc2FnZSB0aXRsZSBpcyBkZWxpYmVyYXRlbHkgcHJv dm9jYXRpdmUsIGJ1dCBkb2VzIGluZGljYXRlIHRoZQ0KPiBwYXRoIHRoYXQgSSB0aGluayB3ZSBz aG91bGQgZm9sbG93IGZvciB0aGUgZG9jdW1lbnQuICBTcGVjaWZpY2FsbHkgd2hhdA0KPiB3aGF0 IEkgd291bGQgbGlrZSB0byBkbyBpcyB0byByZW1vdmUgdGhlIG5vbiBBRUFEIGFsZ29yaXRobXMg YW5kIHJlcGxhY2UNCj4gdGhlbSB3aXRoIEFFQUQgYWxnb3JpdGhtcyB0aGF0IGFyZSwgbW9yZSBv ciBsZXNzLCBlcXVpdmFsZW50LiAgVGhpcw0KPiBtZWFucyB0aGF0IEkgd291bGQgbGlrZSBkZWZp bmUgdGhyZWUgbmV3IGFsZ29yaXRobXMgQUVTMTI4LUhTMjU2LA0KPiBBRVMyNTYtSFMyNTYgYW5k IEFFUzUxMi1IUzUxMiB0aGF0IGFyZSBBRUFEIGFsZ29yaXRobXMuDQo+IA0KPiBBZHZhbnRhZ2Vz Og0KPiANCj4gMS4gIFRoZSBoZWFkZXIgaXMgc21hbGxlciBhcyB3ZSBjYW4gZWxpbWluYXRlIHRo ZSAiaW50OiIgZmllbGQNCj4gMi4gIFdlIG1ha2UgaXQgY2xlYXIgdGhhdCBub24tQUVBRCBhbGdv cml0aG1zIGFyZSBub3QgcGVybWl0dGVkIGFuZCBwdXQNCj4gaXQgb24gdGhlIGFsZ29yaXRobSBk ZWZpbmVyIGFuZCBub3Qgb24gdGhlIGltcGxlbWVudGVyIHRvIGZpeCB0aGUNCj4gcHJvYmxlbSBp ZiB0aGUgcHJvcG9zZWQgYWxnb3JpdGhtIGlzIG5vdCBhbiBBRUFEIGFsZ29yaXRobS4NCj4gMy4g IEl0IG1ha2VzIHRoZSBlbmNyeXB0aW9uIGRvY3VtZW50IHNpbXBsZXIgYXMgdGhlcmUgaXMgbm93 IG9ubHkgb25lDQo+IGVuY3J5cHRpb24vZGVjcnlwdCBzZXQgb2Ygc3RlcHMgdG8gZm9sbG93Lg0K PiA0LiAgVGhlIEtERiBtb3ZlcyBmcm9tIEpXRSB0byBKV0Egd2hlcmUgaXQgbW9yZSBwcm9wZXJs eSBiZWxvbmdzDQo+IDUuICBUaGUgS0RGIG5vdyBiZWNvbWVzIGFuIGltcGxpY2l0IHBhcmFtZXRl ciBvZiB0aGUgYWxnb3JpdGhtIGFuZCBpdA0KPiBpcyBlYXN5IHRvIGNoYW5nZSBpdCBmb3IgYW4g dXBkYXRlZCBvbmUgbGF0ZXIgYXMgbmVjZXNzYXJ5IGZvciBzcGVjaWZpYw0KPiBhbGdvcml0aG1z LiAgQXMgaXQgY3VycmVudGx5IHN0YW5kcyB0aGVyZSBpcyBubyBlYXN5IHdheSB0byBjaGFuZ2Ug dGhpcw0KPiBvbiBhbiBhbGdvcml0aG0gYnkgYWxnb3JpdGhtIGJhc2lzLiAgVGhpcyBtZWFucyB0 aGF0IHdlIGNhbiB1c2UgU0hBLTI1Ng0KPiBmb3IgdGhlIGZpcnN0IHR3byBhbGdvcml0aG1zIGFu ZCBTSEEtNTEyIGZvciB0aGUgbGFzdCBvbmUgLSB0aGlzIG1lYW5zDQo+IHRoYXQgd2UgZG9uJ3Qg Imxvc2UgYml0cyIgaW4gdGhlIHByb2Nlc3Mgb2YgZG9pbmcgdGhlIEtERi4NCj4gNi4gIFRoZSB0 ZXN0IG1hdHJpeCBiZWNvbWVzIHNtYWxsZXIgZm9yIGltcGxlbWVudGVycyBhcyB0aGVyZSBpcyBh IGxpc3QNCj4gcmF0aGVyIHRoYW4gYSBtYXRyaXggb2YgcG9zc2libGUgZnVuY3Rpb25zIHRvIGxv b2sgYXQuDQoNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgYXBwcm9hY2guDQpIYXJkd2lyaW5nIHRoZSBL REYgdG8gdXNlIFNIQS0yNTYgaXMgYSBzaG93c3RvcHBlciBpbiB0aGUgY3VycmVudCBhcHByb2Fj aCBbSldFLTAyXSwgcGFydGljdWxhcmx5IHdpdGggU0hBLTMgb24gdGhlIGhvcml6b24uDQoNCg0K SSBndWVzcyAiQUVTNTEyLUhTNTEyIiBzaG91bGQgYWN0dWFsbHkgYmUgIkFFUzI1Ni1IUzUxMiIs IG9yIGJldHRlciBzdGlsbCAiQTI1NkNCQy1IUzUxMiIgdG8gYmUgYSBiaXQgbW9yZSBjb25zaXN0 ZW50IHdpdGggb3RoZXIgbmFtZXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From ve7jtb@ve7jtb.com Sun Jun 3 18:16: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 322B421F87D3 for ; Sun, 3 Jun 2012 18:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zDYe490hnil for ; Sun, 3 Jun 2012 18:16:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4150121F87D1 for ; Sun, 3 Jun 2012 18:16:22 -0700 (PDT) Received: by yhq56 with SMTP id 56so2870013yhq.31 for ; Sun, 03 Jun 2012 18:16:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=03lVlgVp9T25SpZQl/DWn6qkZJaTCzFAOlHcRyLUUiw=; b=dlLZnBOhlLafNhHBDSFRFjD0ElbGJH24HH2Fprg+D5M0dhGOJAx6gEbR2h2VH75sho Ynj3RNA9c3U5CM4JHheHyGF7MjANQ1rA5y/85D44D0w7+bZOqgQK0TRTUvra1egVkyny 7P/VMNehrXMTgcTZHlxwM0U2VQZhXGLlygnDrDxW2jRwyAHmub+6NlW63lh2eyHHiY6D XuZhnk5/f7G2aUIfjoeuds731tyfyRmYGYT1mUs5Q8MCaiITt8c48UfsD5iOiCig17nr moO5vjl5ej/c/TpncwIJ74t8bYx8F+pqcClcLKP5Gh1mfvPzQY6MLC1XGivHsSRp2uHK 6VSA== Received: by 10.236.78.1 with SMTP id f1mr3242314yhe.109.1338772581559; Sun, 03 Jun 2012 18:16:21 -0700 (PDT) Received: from 201-188-162-56.bam.movistar.cl ([201.188.162.56]) by mx.google.com with ESMTPS id q32sm12767738anh.21.2012.06.03.18.16.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jun 2012 18:16:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_D30BBCB1-BBA1-4054-9991-E466E18D3C02"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net> Date: Sun, 3 Jun 2012 21:16:05 -0400 Message-Id: References: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net> To: "Vladimir Dzhuvinov / NimbusDS" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk/1nOM7L0zkWsLWbuEgv1g0kTk8smih17j8IZ57O5q9dvxj9k+PLETi2/5oDRxBjfW76oh Cc: jose@ietf.org Subject: Re: [jose] Allow compression of plain and JWS too? 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, 04 Jun 2012 01:16:23 -0000 --Apple-Mail=_D30BBCB1-BBA1-4054-9991-E466E18D3C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This has come up before in the working group. Compression is required before encryption as your can't encrypt after = (if your encryption is any good). With signing you can always leave it to transport or some other process = to compress it if required. We did note that the http layer supports compression as well. We previously came to the conclusion that compression for signing is = unnecessary and only adds extra code to be tested. I actually had to argue quite strongly at the time to get compression as = a option with encryption due to the additional complexity. So on the basis that the more mandatory to implement things we add, the = less likely we are to get adoption, and previous discussions around some = of the input documents,=20 I am opposed to adding compression for signing. John B. On 2012-05-31, at 8:01 AM, Vladimir Dzhuvinov / NimbusDS wrote: > Is there a reason to have compression only with JWE? >=20 >=20 > Vladimir >=20 > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_D30BBCB1-BBA1-4054-9991-E466E18D3C02 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw NDAxMTYwNlowIwYJKoZIhvcNAQkEMRYEFF4i+hwmlTeb7yvS6rWuQjochUjpMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABJHFpV/XMW9USM7DIPdxqwjjBbxs+dUh0n0mFCJngu5E8vAEBhmQbRDDPZmXHi5TPVt5qpnS58a ch0xeVG3fAHMQVq4SvJDGWeGO+UguCUz6KZqTgT+ss1idWb2EG80CmWTc1ShUGnSscHOc70AXfGG swrNw42Q132+OyL+o4v7PSbyEOcE65NPlOnVCp7el1t7TzdTpeokOIdvbwT+/BU8T3qkGdZQCa+T su2dbfc9S2WKS/f0Cy8lgYli51Qf0MbniZT8zNsOYdwPnY8CWIt70wOSqaG4dFvzF7jVQTUa7v3x dKTi8g+4t7QXg//0o8gi8uxxodfkWC42QyEQ3VkAAAAAAAA= --Apple-Mail=_D30BBCB1-BBA1-4054-9991-E466E18D3C02-- From ve7jtb@ve7jtb.com Sun Jun 3 18:27: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 29B9321F87E6 for ; Sun, 3 Jun 2012 18:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRFYiZ50jGhc for ; Sun, 3 Jun 2012 18:27:42 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7399E21F87E5 for ; Sun, 3 Jun 2012 18:27:42 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3331561ghb.31 for ; Sun, 03 Jun 2012 18:27:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ffKXp8Dgjphn4lUlfKOCj6PEhNGbCRBWpSLHVqShRr0=; b=N3ci6mgh9RRHZOV/UE1onPGYBouORB3FNKmqzGu19Ys+iKG/xDGint2IdbZFetuhOG /yj4VUWjvYgQz9xmzys+7txy4bXG4aw0YTPfB8F3ZtgtwUjzu6Jd55TAaKOcfh/9um7k DTESU29tbl5VfrI3kecG6s1dgbZwXW2mtDPMw1ekHe6Dq7BhQRJmFkzxq19ZVFsHabRZ Mnd31NkxV7TkPtseu8NlxtgxORvAIpNs4gDniIKALIDIx/kh54h0Pchvegw4tNW7dnrd rcOrtR+/SpPKyYeTrBsSNV9xsbplau7cXHirPvWpHmvyEEN/G/9E8VPkLNN6fb302Z0F 8S9Q== Received: by 10.100.238.14 with SMTP id l14mr3142065anh.0.1338773261643; Sun, 03 Jun 2012 18:27:41 -0700 (PDT) Received: from 201-188-162-56.bam.movistar.cl ([201.188.162.56]) by mx.google.com with ESMTPS id p14sm12806877ani.8.2012.06.03.18.27.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jun 2012 18:27:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_26C93D2A-1557-4903-9883-215E0BD67E08"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net> Date: Sun, 3 Jun 2012 21:27:36 -0400 Message-Id: References: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net> To: "Vladimir Dzhuvinov / NimbusDS" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk54jxrOkxEDABU51wfIRYnhSPcY7k2CfdV+X7v1kTKdNHdDRFMYp8GMxVc8+ZrJvZ2Jx7D Cc: jose@ietf.org Subject: Re: [jose] Allow compression of plain and JWS too? 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, 04 Jun 2012 01:27:43 -0000 --Apple-Mail=_26C93D2A-1557-4903-9883-215E0BD67E08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Done, On 2012-05-31, at 8:01 AM, Vladimir Dzhuvinov / NimbusDS wrote: > Is there a reason to have compression only with JWE? > > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_26C93D2A-1557-4903-9883-215E0BD67E08 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw NDAxMjczN1owIwYJKoZIhvcNAQkEMRYEFMRkLmyLPwWo7/WkPBdRJGTg9GFTMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ADLnBkrFi4aAXa1lzEpFcCZkOD1EkHULEFCH1oMvGYJSrOmyop8qXXuhML9oN/+V86kwB4oSVnOE mzGr51XDCkgvhwVzjALGSosSd1GNdevdRyKBgyQhY6Na24zL39rDWJT3OQt+/6NQJgMM6NgiH+s2 Zs2GoZRv4OxsKPsrx2O06tInv/bcG7a+OI6QdOzZ5fLqJrFPFQ0aMGYIyOXSb214CFazS9cVPcRk k/IwlPn4WK6HLEDpds9of2RD85rCbFZiOzaZj7AmpymPiyRW3OHtmlF1vjVEUFVgUavYqcoD1zBt P6IKmDZG5dQMeAa9mgU+kXLpbATv2/G3hZ0OIswAAAAAAAA= --Apple-Mail=_26C93D2A-1557-4903-9883-215E0BD67E08-- From James.H.Manger@team.telstra.com Sun Jun 3 18:38: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 733D221F87FA for ; Sun, 3 Jun 2012 18:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=1.157, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN-Y3eCesBZF for ; Sun, 3 Jun 2012 18:38:51 -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 BB1F321F87FB for ; Sun, 3 Jun 2012 18:38:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,710,1330866000"; d="scan'208";a="78617092" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 04 Jun 2012 11:38:48 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6731"; a="66740534" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccvi.tcif.telstra.com.au with ESMTP; 04 Jun 2012 11:38:47 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Mon, 4 Jun 2012 11:38:47 +1000 From: "Manger, James H" To: John Bradley , Vladimir Dzhuvinov / NimbusDS Date: Mon, 4 Jun 2012 11:38:46 +1000 Thread-Topic: [jose] Allow compression of plain and JWS too? Thread-Index: Ac1B76uKXUIODGf9Qf6GHGw9RYRsSAAACWdw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F51D2712@WSMSG3153V.srv.dir.telstra.com> References: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Allow compression of plain and JWS too? 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, 04 Jun 2012 01:38:52 -0000 PiBDb21wcmVzc2lvbiBpcyByZXF1aXJlZCBiZWZvcmUgZW5jcnlwdGlvbiBhcyB5b3VyIGNhbid0 IGVuY3J5cHQgYWZ0ZXINCj4gKGlmIHlvdXIgZW5jcnlwdGlvbiBpcyBhbnkgZ29vZCkuDQo+IA0K PiBXaXRoIHNpZ25pbmcgeW91IGNhbiBhbHdheXMgbGVhdmUgaXQgdG8gdHJhbnNwb3J0IG9yIHNv bWUgb3RoZXIgcHJvY2Vzcw0KPiB0byBjb21wcmVzcyBpdCBpZiByZXF1aXJlZC4NCg0KQ29tcHJl c3NpbmcgdGV4dCBhZnRlciBiYXNlNjR1cmwtZW5jb2RpbmcgKGVnIGJ5IHRoZSB0cmFuc3BvcnQp IGlzIG5vdCBuZWFybHkgYXMgZWZmZWN0aXZlIGFzIGNvbXByZXNzaW5nIHRoZSBhY3R1YWwgdGV4 dC4NCg0KPiBXZSBkaWQgbm90ZSB0aGF0IHRoZSBodHRwIGxheWVyIHN1cHBvcnRzIGNvbXByZXNz aW9uIGFzIHdlbGwuDQo+IA0KPiBXZSBwcmV2aW91c2x5IGNhbWUgdG8gdGhlIGNvbmNsdXNpb24g dGhhdCBjb21wcmVzc2lvbiBmb3Igc2lnbmluZyBpcw0KPiB1bm5lY2Vzc2FyeSBhbmQgb25seSBh ZGRzIGV4dHJhIGNvZGUgdG8gYmUgdGVzdGVkLg0KPiANCj4gSSBhY3R1YWxseSBoYWQgdG8gYXJn dWUgcXVpdGUgc3Ryb25nbHkgYXQgdGhlIHRpbWUgdG8gZ2V0IGNvbXByZXNzaW9uDQo+IGFzIGEg b3B0aW9uIHdpdGggZW5jcnlwdGlvbiBkdWUgdG8gdGhlIGFkZGl0aW9uYWwgY29tcGxleGl0eS4N Cg0KSWYgeW91IHN1cHBvcnQgY29tcHJlc3Npb24gd2l0aCBlbmNyeXB0aW9uLCB0aGVyZSBpcyBu byBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgdG8gc3VwcG9ydCBjb21wcmVzc2lvbiB3aXRoIHNpZ25p bmcuDQpPbmx5IHNjZW5hcmlvcyB0aGF0IHdpbGwgb25seSBldmVyIGRvIHNpZ25pbmcgLS0gd2l0 aCBubyBwb3NzaWJpbGl0eSBvZiBldmVyIG5lZWRpbmcgZW5jcnlwdGlvbiAtLSBjYW4gcG90ZW50 aWFsbHkgc2F2ZSBzb21lIGNvbXBsZXhpdHkuIEkgZG91YnQgdGhvc2Ugc2NlbmFyaW9zIHdpbGwg YmUgY29tbW9uLg0KDQo+IFNvIG9uIHRoZSBiYXNpcyB0aGF0IHRoZSBtb3JlIG1hbmRhdG9yeSB0 byBpbXBsZW1lbnQgdGhpbmdzIHdlIGFkZCwgdGhlDQo+IGxlc3MgbGlrZWx5IHdlIGFyZSB0byBn ZXQgYWRvcHRpb24sIGFuZCBwcmV2aW91cyBkaXNjdXNzaW9ucyBhcm91bmQNCj4gc29tZSBvZiB0 aGUgaW5wdXQgZG9jdW1lbnRzLCBJIGFtIG9wcG9zZWQgdG8gYWRkaW5nIGNvbXByZXNzaW9uIGZv cg0KPiBzaWduaW5nLg0KDQpUaGUgSldTIHNwZWMgc3RhcnRzIGJ5IHNheWluZyBpdCBpcyBhIGNv bXBhY3QgZm9ybWF0IGludGVuZGVkIGZvciBzcGFjZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMu IEl0IGNob29zZXMgdGVyc2UgMy1sZXR0ZXIgaGVhZGVyIGVsZW1lbnQgbmFtZXMuIEl0IGRlZmlu ZXMgaXQgb3duIGFsZyBuYW1lcywgcGFydGx5IGJlY2F1c2UgdGhleSBhcmUgc2hvcnRlciB0aGFu IGV4aXN0aW5nIG5hbWVzLg0KSSBhbSBzdHJvbmdseSBpbiBmYXZvdXIgb2YgaW5jbHVkaW5nIGNv bXByZXNzaW9uIGNvbnNpc3RlbnRseSBhY3Jvc3MgYWxsIHRoZSBtb2RlcyB0aGF0IGEgSk9TRSBt ZXNzYWdlIHN1cHBvcnRzIChlbmNyeXB0ZWQsIHNpZ25lZCwgdW5wcm90ZWN0ZWQuLi4pLg0KDQot LQ0KSmFtZXMgTWFuZ2VyDQo= From ve7jtb@ve7jtb.com Sun Jun 3 18: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 DF95821F8771 for ; Sun, 3 Jun 2012 18:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy8oZZzhQXgE for ; Sun, 3 Jun 2012 18:47:46 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC9721F8750 for ; Sun, 3 Jun 2012 18:47:45 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3337441ghb.31 for ; Sun, 03 Jun 2012 18:47:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=J60Qx4dWewMs6Kr8TcooOzz2sMzsSu3mNt1bf3L8nAM=; b=VwoSfzB+BQyYMNOw20KB9qsNQ9KlLokvGR1ek7RPqtUzEX57PhWMZTFxS+ubN6HxOe nTWWmjhSTTg/nB993ZtFJ+AWmBYPler04b4egkZTCjXXB50sTXBtESW9ctJo7PvLOs8d nU2HfSpj6J3J93kB+wqBx0GStzWsq2EPsFCkrKVL/om7rhnHq9jc6VFf4QQC2yFvpOY3 bb0MdSmDQQYUSLV0vuU/GtL/7CgtoPmeqrY/jfdTnTW6wr0br7ZkMayJqVsOwDRI0jaI Qry0Zs84JfGN/K9mzj6yuSg/HpxmXxQahQsPI5+heunidbfZETDkZLJpmg4sgZiEM5z6 8MHQ== Received: by 10.236.177.1 with SMTP id c1mr5323928yhm.41.1338774465635; Sun, 03 Jun 2012 18:47:45 -0700 (PDT) Received: from 201-188-162-56.bam.movistar.cl ([201.188.162.56]) by mx.google.com with ESMTPS id t11sm2379418anm.5.2012.06.03.18.47.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jun 2012 18:47:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_6BE59AD7-21D3-44EB-B5F0-40C112DA3E55"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F51D2712@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 3 Jun 2012 21:47:40 -0400 Message-Id: References: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114F51D2712@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn15DWUEjN2WmafYW+hBeyOh7fLLZVihcL1mvHZ3LQlz2DZfar8AaqllEMNVJTOCPoM6Cip Cc: "jose@ietf.org" , Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] Allow compression of plain and JWS too? 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, 04 Jun 2012 01:47:47 -0000 --Apple-Mail=_6BE59AD7-21D3-44EB-B5F0-40C112DA3E55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-06-03, at 9:38 PM, Manger, James H wrote: >> Compression is required before encryption as your can't encrypt after >> (if your encryption is any good). >>=20 >> With signing you can always leave it to transport or some other = process >> to compress it if required. >=20 > Compressing text after base64url-encoding (eg by the transport) is not = nearly as effective as compressing the actual text. I can't argue that, but it is much better than compressing after = encryption. >=20 >> We did note that the http layer supports compression as well. >>=20 >> We previously came to the conclusion that compression for signing is >> unnecessary and only adds extra code to be tested. >>=20 >> I actually had to argue quite strongly at the time to get compression >> as a option with encryption due to the additional complexity. >=20 > If you support compression with encryption, there is no additional = complexity to support compression with signing. > Only scenarios that will only ever do signing -- with no possibility = of ever needing encryption -- can potentially save some complexity. I = doubt those scenarios will be common. Again compression with encryption was a hard sell to many of the = original participants like Facebook. =20 Many libraries and use cases will be signing only, and they will balk at = compression as a MTI. =20 Making it optional will cause more interop problems than it is worth. I honestly originally wanted compression available for both. I have = been convinced subsequently that for adoption it is better to leave it = out of signing. John B. >=20 >> So on the basis that the more mandatory to implement things we add, = the >> less likely we are to get adoption, and previous discussions around >> some of the input documents, I am opposed to adding compression for >> signing. >=20 > The JWS spec starts by saying it is a compact format intended for = space constrained environments. It chooses terse 3-letter header element = names. It defines it own alg names, partly because they are shorter than = existing names. > I am strongly in favour of including compression consistently across = all the modes that a JOSE message supports (encrypted, signed, = unprotected...). >=20 > -- > James Manger --Apple-Mail=_6BE59AD7-21D3-44EB-B5F0-40C112DA3E55 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw NDAxNDc0MVowIwYJKoZIhvcNAQkEMRYEFOR84vJJ97WjUQJMfc5mMMkIlIdcMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AGLbg4xcnyuWue7pmWXqojJ6ifMz2fzEkrk7u4QQTB320yWEfiHbFHOAU3MZdSR48sFqRsb5U28r f2bIgTaYP4hjizvtvtZLIBIUfToG2wGAw8SEw3UzA9xXaVy3jUpAnfbGmZjX/v6ZZlZ6PgBJlZUc e3suDP2qsF4ZSzhLYmhME2pva+v3897xUz6KYujYqjTX/0Jo4RS45UY3Ek4I9Hrz2uLRicf/pebr s1fOJ5xXGe5sLoi3V7b29pf71FQ02xadGFBx72nG5PYuqvVm2f60oIWQZKxSni/I7AmcVHRj7qyM yY3X3XP4AP5JLkZE5dlB+Euh3nfwrQwkF73yFyIAAAAAAAA= --Apple-Mail=_6BE59AD7-21D3-44EB-B5F0-40C112DA3E55-- From James.H.Manger@team.telstra.com Sun Jun 3 18:49: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 B888C21F87AD for ; Sun, 3 Jun 2012 18:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C-5UqV6HNs0 for ; Sun, 3 Jun 2012 18:49:45 -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 E790F21F8771 for ; Sun, 3 Jun 2012 18:49:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,710,1330866000"; d="scan'208";a="81448560" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 04 Jun 2012 11:49:43 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6731"; a="67791835" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccni.tcif.telstra.com.au with ESMTP; 04 Jun 2012 11:49:43 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 4 Jun 2012 11:49:43 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Mon, 4 Jun 2012 11:49:42 +1000 Thread-Topic: [jose] JOSE top-level syntax proposal Thread-Index: AQIP3/RsifqcjyR58+ljXztrAdTAJpZjp9ZAgABstxA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F51D277A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F4FC08C1@WSMSG3153V.srv.dir.telstra.com> <066701cd41b3$f1754bc0$d45fe340$@augustcellars.com> In-Reply-To: <066701cd41b3$f1754bc0$d45fe340$@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] JOSE top-level syntax proposal 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, 04 Jun 2012 01:49:45 -0000 PiA+IEhlcmUgaXMgYSBjb25jcmV0ZSBwcm9wb3NhbCBmb3IgdGhlIHN5bnRheCBvZiBKT1NFIG1l c3NhZ2VzIHRoYXQNCj4gPiBleHBsaWNpdGx5IGluZGljYXRlcyB0aGUgbW9kZSBvZiBwcm90ZWN0 aW9uLCBpbmRlcGVuZGVudGx5IG9mDQo+ID4gc3BlY2lmaWMgYWxnb3JpdGhtIHZhbHVlcy4NCj4g Pg0KPiA+IGp3c2VjICA9ICgiWiIgIi4iIGhlYWRlcjY0ICIuIiBjb21wcmVzc2VkNjQpIC8NCj4g PiAgICAgICAgICAoIlMiICIuIiBoZWFkZXI2NCAiLiIgZGF0YTY0ICIuIiBzaWduYXR1cmU2NCkg Lw0KPiA+ICAgICAgICAgICgiSSIgIi4iIGhlYWRlcjY0ICIuIiBkYXRhNjQgIi4iIGNoZWNrc3Vt NjQpIC8NCj4gPiAgICAgICAgICAoIkUiICIuIiBoZWFkZXI2NCAiLiIgZW5ja2V5NjQgIi4iIGNp cGhlcnRleHQ2NCAiLiIgbWFjNjQpIC8NCj4gPiAgICAgICAgICAoZXh0ICIuIiBoZWFkZXI2NCAq KCIuIiBjb21wb25lbnQ2NCkpDQoNCg0KPiBIb3cgd291bGQgeW91IGV4dGVuZCB0aGlzIHRvIGRl YWwgd2l0aCB0aGUgYWx0ZXJuYXRpdmUgZW5jb2RpbmcgZm9ybWF0Pw0KPiBUaGlzIG9ubHkgYWRk cmVzc2VzIHRoZSBpc3N1ZSBmb3IgdGhlIGRvdCBmb3JtIG9mIGVuY29kaW5nLg0KDQoNClRoZSBj dXJyZW50IEpXUy1KUyBhbmQgSldFLUpTIGFsdGVybmF0aXZlIHNlcmlhbGl6YXRpb25zIHN0aWxs IHdvcmsuIFdoZXJlIHRoZXkgdGFsayBhYm91dCA8aGVhZGVyIE4gY29udGVudHM+IHlvdSBjb3Vs ZCBzaW1wbHkgaW5jbHVkZSB0aGUgZXh0cmEgbGVhZGluZyBsZXR0ZXIgYW5kIGRvdC4gVGhlIEpX RS1KUyBleGFtcGxlIGJlY29tZXM6DQp7ImhlYWRlcnMiOlsNCiAgICAgIkUuZXlKaGJH4oCmSW4w IiwNCiAgICAgIkUuZXlKaGJH4oCmeUo5Il0sDQogImVuY3J5cHRlZF9rZXlzIjpbDQogICAgICJU QkRfZW5jcnlwdGVkX2tleV8xX3ZhbHVlX1RCRCIsDQogICAgICJUQkRfZW5jcnlwdGVkX2tleV8y X3ZhbHVlX1RCRCJdLA0KICJjaXBoZXJ0ZXh0IjoiVEJEX2NpcGhlcnRleHRfdmFsdWVfVEJEIiwN CiAiaW50ZWdyaXR5X3ZhbHVlcyI6Ww0KICAgICAiVEJEX2ludGVncml0eV8xX3ZhbHVlX1RCRCIs DQogICAgICJUQkRfaW50ZWdyaXR5XzJfdmFsdWVfVEJEIl0NCn0NCg0KQW5vdGhlciBhbHRlcm5h dGl2ZSB3b3VsZCBiZSB0byBrZWVwIHRoZSAiaGVhZGVycyIsICJlbmNyeXB0ZWRfa2V5cyIsICJj aXBoZXJ0ZXh0IiwgYW5kICJpbnRlZ3JpdHlfdmFsdWVzIiBmaWVsZCBhcyBub3csIGJ1dCBhZGQg b25lIG5ldyBmaWVsZCAibW9kZSIuDQp7DQogICJtb2RlIjoiRSIsDQogICJoZWFkZXJzIjpbImV5 SmhiR+KApkluMCIsICJFLmV5SmhiR+KApnlKOSJdLA0KICAiY2lwaGVydGV4dCI6IuKApiIsDQog ICJpbnRlZ3JpdHlfdmFsdWVzIjpbIuKApiIsICLigKYiXQ0KfQ0KDQotLQ0KSmFtZXMgTWFuZ2Vy DQo= From mamille2@cisco.com Mon Jun 4 08:37: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 3FE7B21F88B7 for ; Mon, 4 Jun 2012 08:37: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE6mUpOvtALA for ; Mon, 4 Jun 2012 08:37:12 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6A21F8898 for ; Mon, 4 Jun 2012 08:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6164; q=dns/txt; s=iport; t=1338824232; x=1340033832; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=81Jrkm3LlInbghhnH1W2xK4PR3HxVWCes8x2BUw/uNY=; b=PLfjz/Y5jGe7OGXhfR5kVZyM344jcSy3JsA1yytC+cSDq2BDCvJ+Mj12 1srclSckAaLDSKr/Q7RgSfUPJLG+Z8fYTksR0AMuCl4cJQzR4FwhywFP2 u+HvHacLbeX2gJWFgNbmWMYulhlVaaJuB3TyfXDLsN577Iz7VPZT3DL3H U=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA/VzE+rRDoI/2dsb2JhbABEtC2BB4IZAQEEEgFmEAsOOAJVBhMih2gBlxifMosRhTBgA4hAhXeGZIVQiECBZoJ/ X-IronPort-AV: E=Sophos;i="4.75,713,1330905600"; d="sig'?p7s'?scan'208";a="47500480" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 04 Jun 2012 15:37:06 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q54Fb6ux009463; Mon, 4 Jun 2012 15:37:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8--260214511" From: Matt Miller In-Reply-To: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> Date: Mon, 4 Jun 2012 09:37:18 -0600 Message-Id: References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> To: Jim Schaad Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 15:37:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8--260214511 Content-Type: multipart/signed; boundary=Apple-Mail-7--260214513; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-7--260214513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 3, 2012, at 12:22, Jim Schaad wrote: > >=20 > The message title is deliberately provocative, but does indicate the = path > that I think we should follow for the document. Specifically what I = would > like to do is to remove the non AEAD algorithms and replace them with = AEAD > algorithms that are, more or less, equivalent. This means that I = would like > define three new algorithms AES128-HS256, AES256-HS256 and = AES512-HS512 that > are AEAD algorithms. >=20 > Advantages: >=20 > 1. The header is smaller as we can eliminate the "int:" field > 2. We make it clear that non-AEAD algorithms are not permitted and = put it > on the algorithm definer and not on the implementer to fix the problem = if > the proposed algorithm is not an AEAD algorithm. > 3. It makes the encryption document simpler as there is now only one > encryption/decrypt set of steps to follow. > 4. The KDF moves from JWE to JWA where it more properly belongs > 5. The KDF now becomes an implicit parameter of the algorithm and it = is > easy to change it for an updated one later as necessary for specific > algorithms. As it currently stands there is no easy way to change = this on > an algorithm by algorithm basis. This means that we can use SHA-256 = for the > first two algorithms and SHA-512 for the last one - this means that we = don't > "lose bits" in the process of doing the KDF. > 6. The test matrix becomes smaller for implementers as there is a = list > rather than a matrix of possible functions to look at. +1 In fact, David McGrew is working on a draft that defines AEAD algorithms = that re-use AES-CBC + HMAC-SHA2. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-7--260214513 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwNDE1Mzcx OFowIwYJKoZIhvcNAQkEMRYEFHVpya37RZRsfoLJZoHEPZ77NtN3MIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQC6zDeUP/XHo5CsRbz2hWzMLard0cGXtYsE3D5QGBfzrxU+qpKBMnz/sp5t Q6to+JbewhRBw7Pm4sui0/w3GiB6IlJr6xyjjXK1Vnf5z1qtoTyy6pmiKtGBIDXO7VMn5L8aEySp HcLriME3lrgtS6cL9Bo3i7XryVPppG/UvkNnqJaRs+h/CnQbGUsOHt+ZYuQCUIf6S6MUBPF4KXmh Q+zVC3GGhX5WW3tg32aCqvHgD973BAQ6BWv+0WKXPPZhhb8tPoxd6wkqDKpAJRiP6h0thYpTNlaX 6KKKVXRiiRlDa5vDtvYG4+UZHehhstbNwk5ktMRQeS87ETThI3qP9k7LAAAAAAAA --Apple-Mail-7--260214513-- --Apple-Mail-8--260214511 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPzNYuAAoJEJq6Ou0cgrSPAdIIALJ1ojpEOF+u2NXDUNdT8ISC 0CmcGretGtCnfkekW9XMbB0kw1rC/O6VLwOvkLzSch556Hx0DJInSKB532LUSwf/ vwSGSTwbpFgBjPgsOlYpIbemg2BbjytBNw1N55Inz46CVi83Z6lyB0Nns5UFta+B N9elPoRmHNz3X7gqQkZo7l+TUmsQf/P62wsBhJYx7UbDNkE9We+1iUbu8L/bfDtP mEgaq2zSla6EZoS9uriuPXKkynCu5DyAR8Cc4gGlT9hvZ5JJe23g+6x7jrXo0APk ohRT7bNA/gXAqeznTaq2BxKIBtrZlBLPci3yGoXxqFVXE5R1KI1Lqj0ieC/kVpk= =MCFw -----END PGP SIGNATURE----- --Apple-Mail-8--260214511-- From ietf@augustcellars.com Mon Jun 4 09:17:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F02F21F87C9 for ; Mon, 4 Jun 2012 09:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgr4doErl7m4 for ; Mon, 4 Jun 2012 09:17:23 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id C6CCD21F879B for ; Mon, 4 Jun 2012 09:17:23 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 5F3AC2CA24; Mon, 4 Jun 2012 09:17:23 -0700 (PDT) From: "Jim Schaad" To: "'Matt Miller'" References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> In-Reply-To: Date: Mon, 4 Jun 2012 09:16:08 -0700 Message-ID: <06a501cd426d$5a54fc80$0efef580$@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: AQN7lRnf1JPyv6QP4WEDAazkDoLz4AHErbPTk3+K9ZA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 16:17:24 -0000 > -----Original Message----- > From: Matt Miller [mailto:mamille2@cisco.com] > Sent: Monday, June 04, 2012 8:37 AM > To: Jim Schaad > Cc: jose@ietf.org > Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms > > On Jun 3, 2012, at 12:22, Jim Schaad wrote: > > > > > > > The message title is deliberately provocative, but does indicate the > > path that I think we should follow for the document. Specifically > > what I would like to do is to remove the non AEAD algorithms and > > replace them with AEAD algorithms that are, more or less, equivalent. > > This means that I would like define three new algorithms AES128-HS256, > > AES256-HS256 and AES512-HS512 that are AEAD algorithms. > > > > Advantages: > > > > 1. The header is smaller as we can eliminate the "int:" field 2. We > > make it clear that non-AEAD algorithms are not permitted and put it on > > the algorithm definer and not on the implementer to fix the problem if > > the proposed algorithm is not an AEAD algorithm. > > 3. It makes the encryption document simpler as there is now only one > > encryption/decrypt set of steps to follow. > > 4. The KDF moves from JWE to JWA where it more properly belongs 5. > > The KDF now becomes an implicit parameter of the algorithm and it is > > easy to change it for an updated one later as necessary for specific > > algorithms. As it currently stands there is no easy way to change > > this on an algorithm by algorithm basis. This means that we can use > > SHA-256 for the first two algorithms and SHA-512 for the last one - > > this means that we don't "lose bits" in the process of doing the KDF. > > 6. The test matrix becomes smaller for implementers as there is a > > list rather than a matrix of possible functions to look at. > > +1 > > In fact, David McGrew is working on a draft that defines AEAD algorithms that > re-use AES-CBC + HMAC-SHA2. There is also RFC6576 by Peter Gutmann which does the same thing in a CMS context. Jim > > > - m&m > > Matt Miller - > Cisco Systems, Inc. From mamille2@cisco.com Mon Jun 4 09:31: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 0432F21F8691 for ; Mon, 4 Jun 2012 09:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keLKBdjgFnsB for ; Mon, 4 Jun 2012 09:31:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD6521F866D for ; Mon, 4 Jun 2012 09:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6853; q=dns/txt; s=iport; t=1338827467; x=1340037067; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Hef1PozguhU2DBGcLI286VVGbYq18YiNdHsLe0mrmT8=; b=hl/4n98nUKptpAFHTjksTn5N9R4NHWrhirbDe0TGR97QndG/z5EbBzJz 79AUc+Ez/TbW1vOhxZdzb1ns3lrOyYLvA08DfE4MgeHQzNPKDIiUEd4dC L+dEhenZJQEMmTBTWaoeMyYb+jvmxx2W1VCtam3hH5svZXDLo/Eqmd6TR I=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKTizE+rRDoI/2dsb2JhbABEtC2BB4IYAQEBBBIBZgwECw4DBAEBAScHAkQJCAYTIodoAZc2nzeLEYUwYAOIQIV3hmSFUIhAgWaCfw X-IronPort-AV: E=Sophos;i="4.75,713,1330905600"; d="sig'?p7s'?scan'208";a="45018480" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 04 Jun 2012 16:30:46 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q54GUjXV014774; Mon, 4 Jun 2012 16:30:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--256994960" From: Matt Miller In-Reply-To: <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> Date: Mon, 4 Jun 2012 10:30:57 -0600 Message-Id: References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> To: Jim Schaad Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 16:31:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--256994960 Content-Type: multipart/signed; boundary=Apple-Mail-9--256994972; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-9--256994972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 4, 2012, at 10:16, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Matt Miller [mailto:mamille2@cisco.com] >> Sent: Monday, June 04, 2012 8:37 AM >> To: Jim Schaad >> Cc: jose@ietf.org >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD = algorithms >>=20 >> On Jun 3, 2012, at 12:22, Jim Schaad wrote: >>=20 >>> >>>=20 >>> The message title is deliberately provocative, but does indicate the >>> path that I think we should follow for the document. Specifically >>> what I would like to do is to remove the non AEAD algorithms and >>> replace them with AEAD algorithms that are, more or less, = equivalent. >>> This means that I would like define three new algorithms = AES128-HS256, >>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. >>>=20 >>> Advantages: >>>=20 >>> 1. The header is smaller as we can eliminate the "int:" field 2. = We >>> make it clear that non-AEAD algorithms are not permitted and put it = on >>> the algorithm definer and not on the implementer to fix the problem = if >>> the proposed algorithm is not an AEAD algorithm. >>> 3. It makes the encryption document simpler as there is now only = one >>> encryption/decrypt set of steps to follow. >>> 4. The KDF moves from JWE to JWA where it more properly belongs 5. >>> The KDF now becomes an implicit parameter of the algorithm and it is >>> easy to change it for an updated one later as necessary for specific >>> algorithms. As it currently stands there is no easy way to change >>> this on an algorithm by algorithm basis. This means that we can use >>> SHA-256 for the first two algorithms and SHA-512 for the last one - >>> this means that we don't "lose bits" in the process of doing the = KDF. >>> 6. The test matrix becomes smaller for implementers as there is a >>> list rather than a matrix of possible functions to look at. >>=20 >> +1 >>=20 >> In fact, David McGrew is working on a draft that defines AEAD = algorithms > that >> re-use AES-CBC + HMAC-SHA2. >=20 > There is also RFC6576 by Peter Gutmann which does the same thing in a = CMS > context. >=20 > Jim Did you mean RFC6476 "Using Message Authentication Code (MAC) Encryption = in the Cryptographic Message Syntax (CMS)"? In any case, thank you for the reference; I could not find that earlier! - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-9--256994972 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwNDE2MzA1 OFowIwYJKoZIhvcNAQkEMRYEFF6A4+1OvCPx3tBQgmfJ02qb3gtIMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQARACzix1HXXn9dfx2yPl2gOP/mpIDiyaMUTtkVRGgXp26iAjnckF9K6A0N fShowz61kfDSHlW87HWnFhXqYDD9F9cRGZ0tEc8bkR2G1mAYqEpcNAWErhzJD4UswMm4F74A7rNr ZTqsp4XArdGcWZhe/u68aTIBA2PMDC0E2ktTVWSpn8OQn4xZtuMhv6JsavB/JwunFekqNEXfJ5MN rnTCuIXqQxKe1aa0JIL+0zOSL0c6iLJi3B6dXrcujv8aLuKsZnnEEPQ74iVtKQxHYLDKNhwI4dfl 00B6cd0FbBqx7O+34mUsDxSqv6bw4OGDM9yNRA4Uru89B7elyAU+/qOqAAAAAAAA --Apple-Mail-9--256994972-- --Apple-Mail-10--256994960 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPzOLCAAoJEJq6Ou0cgrSPMP8H/iTl38ql9EOPZe4bjexcaft4 bNr5BSCq8AjsYjB9PdZoR6o3L5ZULpQem4HqCHVKHMgKK4ibnJvhrniGpI9tL/Wn 1T7IT0LbX18EU9ldDCNK9zPpmK5RHAMZ1tCufnZazJOt6d1c5swAlpLrGhgFMzjK eUyE/igZ/ICcuOeTYuhy7LgqrJfmsHRVcPO/9F4rrz8puHC07cD8AtPQL4nqHNoe 7GS43vmpqpmwgwHH3RgO7XWNdGt4s2CgxeXcNEqfPhYOotGxeRTGgXjZzwOnTXH7 bRFzjv5BvtJUO73mlOqLEZ+a/AdTfgr4fO7fWfbjdCu03bYfOJwOO+m0MjktoUA= =hqbf -----END PGP SIGNATURE----- --Apple-Mail-10--256994960-- From ietf@augustcellars.com Mon Jun 4 09:38: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 BDE0611E8089 for ; Mon, 4 Jun 2012 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yNMrIbPDt9q for ; Mon, 4 Jun 2012 09:38:29 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3423611E8086 for ; Mon, 4 Jun 2012 09:38:29 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 03F172CA27; Mon, 4 Jun 2012 09:38:28 -0700 (PDT) From: "Jim Schaad" To: "'Matt Miller'" References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> In-Reply-To: Date: Mon, 4 Jun 2012 09:37:14 -0700 Message-ID: <06b901cd4270$4cafea60$e60fbf20$@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: AQN7lRnf1JPyv6QP4WEDAazkDoLz4AHErbPTAr7d3QgBTDeYaJNfODsA Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 16:38:29 -0000 > -----Original Message----- > From: Matt Miller [mailto:mamille2@cisco.com] > Sent: Monday, June 04, 2012 9:31 AM > To: Jim Schaad > Cc: jose@ietf.org > Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms > > > On Jun 4, 2012, at 10:16, Jim Schaad wrote: > > > > > > >> -----Original Message----- > >> From: Matt Miller [mailto:mamille2@cisco.com] > >> Sent: Monday, June 04, 2012 8:37 AM > >> To: Jim Schaad > >> Cc: jose@ietf.org > >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD > >> algorithms > >> > >> On Jun 3, 2012, at 12:22, Jim Schaad wrote: > >> > >>> > >>> > >>> The message title is deliberately provocative, but does indicate the > >>> path that I think we should follow for the document. Specifically > >>> what I would like to do is to remove the non AEAD algorithms and > >>> replace them with AEAD algorithms that are, more or less, equivalent. > >>> This means that I would like define three new algorithms > >>> AES128-HS256, > >>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. > >>> > >>> Advantages: > >>> > >>> 1. The header is smaller as we can eliminate the "int:" field 2. > >>> We make it clear that non-AEAD algorithms are not permitted and put > >>> it on the algorithm definer and not on the implementer to fix the > >>> problem if the proposed algorithm is not an AEAD algorithm. > >>> 3. It makes the encryption document simpler as there is now only > >>> one encryption/decrypt set of steps to follow. > >>> 4. The KDF moves from JWE to JWA where it more properly belongs 5. > >>> The KDF now becomes an implicit parameter of the algorithm and it is > >>> easy to change it for an updated one later as necessary for specific > >>> algorithms. As it currently stands there is no easy way to change > >>> this on an algorithm by algorithm basis. This means that we can use > >>> SHA-256 for the first two algorithms and SHA-512 for the last one - > >>> this means that we don't "lose bits" in the process of doing the KDF. > >>> 6. The test matrix becomes smaller for implementers as there is a > >>> list rather than a matrix of possible functions to look at. > >> > >> +1 > >> > >> In fact, David McGrew is working on a draft that defines AEAD > >> algorithms > > that > >> re-use AES-CBC + HMAC-SHA2. > > > > There is also RFC6576 by Peter Gutmann which does the same thing in a > > CMS context. > > > > Jim > > Did you mean RFC6476 "Using Message Authentication Code (MAC) > Encryption in the Cryptographic Message Syntax (CMS)"? > > In any case, thank you for the reference; I could not find that earlier! Yes - typo on my part. > > > - m&m > > Matt Miller - > Cisco Systems, Inc. From ve7jtb@ve7jtb.com Mon Jun 4 09:59: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 48D2221F87E9 for ; Mon, 4 Jun 2012 09:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BPddxWJkYIH for ; Mon, 4 Jun 2012 09:59:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 794A621F87DF for ; Mon, 4 Jun 2012 09:59:25 -0700 (PDT) Received: by yenq13 with SMTP id q13so3562137yen.31 for ; Mon, 04 Jun 2012 09:59:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=zmJz2AjK6DCb1COy+gq9MqTSBbrf/RZLU71Z5FbdRcc=; b=mZGV6tnqdy1P3spxIdvBizTQmic2cRLuhOPUMfLPGC44IAXnZdorGWG54eHrvSDMc3 U45eG01MV2iSp6kAzHUYfVUJJU0Typa58wwajZyeDKNHG5p87Taz23ZeYC5d5EvnUKCh nJ878/jBXxKT1xR+G3DwYcrGDAZHFlfUgqrXnw+s+nJcFXyLWROsdTIPrjk+3DqUB8Fq Dov9dgBjteQZxf0JWJeUdXBmmEf5cj0p6QTvn0erqU1HCadlG/cpa2RidqMAxLwChKCk O/gbZFZL3sqIT21yKtZkQfsUxI+X6H6vKq1+cB2XkGGTC38lNwJT+Cb+XP+xgXy8ErFF e0Mw== Received: by 10.236.77.164 with SMTP id d24mr8030567yhe.129.1338829164000; Mon, 04 Jun 2012 09:59:24 -0700 (PDT) Received: from 201-188-222-222.bam.movistar.cl ([201.188.222.222]) by mx.google.com with ESMTPS id m16sm15444014anl.9.2012.06.04.09.59.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 09:59:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8092EBC5-CEE4-4E19-8473-8A5A055CDAD3"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <06b901cd4270$4cafea60$e60fbf20$@augustcellars.com> Date: Mon, 4 Jun 2012 12:59:18 -0400 Message-Id: <1200CAC4-5320-47D3-871C-942D8F239092@ve7jtb.com> References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <06b901cd4270$4cafea60$e60fbf20$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk9VVrV4UsazTUHKfHxMPgD3VbcSfOzZ5l4boXku1YarQEbzgEZO3ZK/3HRElOgV//jqz0R Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 16:59:26 -0000 --Apple-Mail=_8092EBC5-CEE4-4E19-8473-8A5A055CDAD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think there is some merit in having: AES128CBC + HMAC-SHA256 + SHA256KDF =3D A128CBC AES256CBC + HMAC-SHA256 + SHA256KDF =3D A256CBC AES512CNC + HMAC-SHA512 + SHA512KDF =3D A512CBC defined as composite algorithms, while keeping the HMAC as a separate = element from the encrypted CMK, as we have it now. Using the other RFC lags can be done as later extensions. The current = CBC + HMAC may not be sexy but it works, and is easy to implement. John B. On 2012-06-04, at 12:37 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Matt Miller [mailto:mamille2@cisco.com] >> Sent: Monday, June 04, 2012 9:31 AM >> To: Jim Schaad >> Cc: jose@ietf.org >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD = algorithms >>=20 >>=20 >> On Jun 4, 2012, at 10:16, Jim Schaad wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Matt Miller [mailto:mamille2@cisco.com] >>>> Sent: Monday, June 04, 2012 8:37 AM >>>> To: Jim Schaad >>>> Cc: jose@ietf.org >>>> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD >>>> algorithms >>>>=20 >>>> On Jun 3, 2012, at 12:22, Jim Schaad wrote: >>>>=20 >>>>> >>>>>=20 >>>>> The message title is deliberately provocative, but does indicate = the >>>>> path that I think we should follow for the document. Specifically >>>>> what I would like to do is to remove the non AEAD algorithms and >>>>> replace them with AEAD algorithms that are, more or less, = equivalent. >>>>> This means that I would like define three new algorithms >>>>> AES128-HS256, >>>>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. >>>>>=20 >>>>> Advantages: >>>>>=20 >>>>> 1. The header is smaller as we can eliminate the "int:" field 2. >>>>> We make it clear that non-AEAD algorithms are not permitted and = put >>>>> it on the algorithm definer and not on the implementer to fix the >>>>> problem if the proposed algorithm is not an AEAD algorithm. >>>>> 3. It makes the encryption document simpler as there is now only >>>>> one encryption/decrypt set of steps to follow. >>>>> 4. The KDF moves from JWE to JWA where it more properly belongs = 5. >>>>> The KDF now becomes an implicit parameter of the algorithm and it = is >>>>> easy to change it for an updated one later as necessary for = specific >>>>> algorithms. As it currently stands there is no easy way to change >>>>> this on an algorithm by algorithm basis. This means that we can = use >>>>> SHA-256 for the first two algorithms and SHA-512 for the last one = - >>>>> this means that we don't "lose bits" in the process of doing the = KDF. >>>>> 6. The test matrix becomes smaller for implementers as there is a >>>>> list rather than a matrix of possible functions to look at. >>>>=20 >>>> +1 >>>>=20 >>>> In fact, David McGrew is working on a draft that defines AEAD >>>> algorithms >>> that >>>> re-use AES-CBC + HMAC-SHA2. >>>=20 >>> There is also RFC6576 by Peter Gutmann which does the same thing in = a >>> CMS context. >>>=20 >>> Jim >>=20 >> Did you mean RFC6476 "Using Message Authentication Code (MAC) >> Encryption in the Cryptographic Message Syntax (CMS)"? >>=20 >> In any case, thank you for the reference; I could not find that = earlier! >=20 > Yes - typo on my part. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller - >> Cisco Systems, Inc. >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_8092EBC5-CEE4-4E19-8473-8A5A055CDAD3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw NDE2NTkxOFowIwYJKoZIhvcNAQkEMRYEFBKbqm4BKdSct9S9Bkr1+Ps2vM4GMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFJ1SQuHSuQSPfDXvw1vuEOJtLq5PdlZlQQRZPEGa7d3wWbMDBuc1YOGWuqtOAvWNltDZM+hg1z5 D7/tMgz3q/bcA/jVeuLDdac6WPCkA7dGY84qi7g+8FLkFyy48uNkSi7W56uj4014WKrUfszifc9g ludTlmNCDJcuRRXfXcu+pg80AoapAKi2un7dziQztUbmRUdrVskXEIZN23ktGCOjbWZ0XJU5k3w2 sNVbfgq3OldSrrcQh5neoHqTS2Iobt1Lwk3xDx8ML9/Wxvg/90kmyvHUyjTGJDR3Zvbn8JNG4Fp+ k1o9sB43pgk0gDPxj4G8eTaUdGkzTyXdHvsU0yIAAAAAAAA= --Apple-Mail=_8092EBC5-CEE4-4E19-8473-8A5A055CDAD3-- From ietf@augustcellars.com Mon Jun 4 12:14: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 B61D011E80D1 for ; Mon, 4 Jun 2012 12:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9YAtg7WU97M for ; Mon, 4 Jun 2012 12:14:16 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1811E80C0 for ; Mon, 4 Jun 2012 12:14:15 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (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 839FB2C9F1; Mon, 4 Jun 2012 12:14:15 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <06b901cd4270$4cafea60$e60fbf20$@augustcellars.com> <1200CAC4-5320-47D3-871C-942D8F239092@ve7jtb.com> In-Reply-To: <1200CAC4-5320-47D3-871C-942D8F239092@ve7jtb.com> Date: Mon, 4 Jun 2012 12:13:00 -0700 Message-ID: <06cd01cd4286$0f7d4050$2e77c0f0$@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: AQN7lRnf1JPyv6QP4WEDAazkDoLz4AHErbPTAr7d3QgBTDeYaAGD0X9KAmAdCWaTQERBAA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 19:14:16 -0000 I am afraid I don't understand your position. Are you saying keep things the way they are or not? Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Monday, June 04, 2012 9:59 AM > To: Jim Schaad > Cc: jose@ietf.org > Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms > > I think there is some merit in having: > AES128CBC + HMAC-SHA256 + SHA256KDF = A128CBC > AES256CBC + HMAC-SHA256 + SHA256KDF = A256CBC > AES512CNC + HMAC-SHA512 + SHA512KDF = A512CBC > > defined as composite algorithms, while keeping the HMAC as a separate > element from the encrypted CMK, as we have it now. > > Using the other RFC lags can be done as later extensions. The current CBC + > HMAC may not be sexy but it works, and is easy to implement. > > John B. > > On 2012-06-04, at 12:37 PM, Jim Schaad wrote: > > > > > > >> -----Original Message----- > >> From: Matt Miller [mailto:mamille2@cisco.com] > >> Sent: Monday, June 04, 2012 9:31 AM > >> To: Jim Schaad > >> Cc: jose@ietf.org > >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms > >> > >> > >> On Jun 4, 2012, at 10:16, Jim Schaad wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Matt Miller [mailto:mamille2@cisco.com] > >>>> Sent: Monday, June 04, 2012 8:37 AM > >>>> To: Jim Schaad > >>>> Cc: jose@ietf.org > >>>> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD > >>>> algorithms > >>>> > >>>> On Jun 3, 2012, at 12:22, Jim Schaad wrote: > >>>> > >>>>> > >>>>> > >>>>> The message title is deliberately provocative, but does indicate the > >>>>> path that I think we should follow for the document. Specifically > >>>>> what I would like to do is to remove the non AEAD algorithms and > >>>>> replace them with AEAD algorithms that are, more or less, equivalent. > >>>>> This means that I would like define three new algorithms > >>>>> AES128-HS256, > >>>>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. > >>>>> > >>>>> Advantages: > >>>>> > >>>>> 1. The header is smaller as we can eliminate the "int:" field 2. > >>>>> We make it clear that non-AEAD algorithms are not permitted and put > >>>>> it on the algorithm definer and not on the implementer to fix the > >>>>> problem if the proposed algorithm is not an AEAD algorithm. > >>>>> 3. It makes the encryption document simpler as there is now only > >>>>> one encryption/decrypt set of steps to follow. > >>>>> 4. The KDF moves from JWE to JWA where it more properly belongs > 5. > >>>>> The KDF now becomes an implicit parameter of the algorithm and it is > >>>>> easy to change it for an updated one later as necessary for specific > >>>>> algorithms. As it currently stands there is no easy way to change > >>>>> this on an algorithm by algorithm basis. This means that we can use > >>>>> SHA-256 for the first two algorithms and SHA-512 for the last one - > >>>>> this means that we don't "lose bits" in the process of doing the KDF. > >>>>> 6. The test matrix becomes smaller for implementers as there is a > >>>>> list rather than a matrix of possible functions to look at. > >>>> > >>>> +1 > >>>> > >>>> In fact, David McGrew is working on a draft that defines AEAD > >>>> algorithms > >>> that > >>>> re-use AES-CBC + HMAC-SHA2. > >>> > >>> There is also RFC6576 by Peter Gutmann which does the same thing in a > >>> CMS context. > >>> > >>> Jim > >> > >> Did you mean RFC6476 "Using Message Authentication Code (MAC) > >> Encryption in the Cryptographic Message Syntax (CMS)"? > >> > >> In any case, thank you for the reference; I could not find that earlier! > > > > Yes - typo on my part. > >> > >> > >> - m&m > >> > >> Matt Miller - > >> Cisco Systems, Inc. > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Jun 4 12:35: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 5FA7811E80F6 for ; Mon, 4 Jun 2012 12:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCNyp5W9NQTV for ; Mon, 4 Jun 2012 12:35:12 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6D011E80E8 for ; Mon, 4 Jun 2012 12:35:11 -0700 (PDT) Received: from mail78-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Jun 2012 19:34:30 +0000 Received: from mail78-db3 (localhost [127.0.0.1]) by mail78-db3-R.bigfish.com (Postfix) with ESMTP id E8336806D6; Mon, 4 Jun 2012 19:34:29 +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: -36 X-BigFish: VS-36(zz9371I936eI542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail78-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail78-db3 (localhost.localdomain [127.0.0.1]) by mail78-db3 (MessageSwitch) id 1338838468671137_11548; Mon, 4 Jun 2012 19:34:28 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.225]) by mail78-db3.bigfish.com (Postfix) with ESMTP id 97F1B20047; Mon, 4 Jun 2012 19:34:28 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Jun 2012 19:34:22 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Mon, 4 Jun 2012 19:26:21 +0000 From: Mike Jones To: Jim Schaad , 'John Bradley' Thread-Topic: [jose] Discussion Topic - Lets kill all non AEAD algorithms Thread-Index: Ac1BtFQuWxXrJ2JcQdivhiunPGbSqwAs5hIAAAFbMwAAAIR4gAAAOC4AAADFSgAABKtfAAAAFl6Q Date: Mon, 4 Jun 2012 19:26:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665289F6@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <06b901cd4270$4cafea60$e60fbf20$@augustcellars.com> <1200CAC4-5320-47D3-871C-942D8F239092@ve7jtb.com> <06cd01cd4286$0f7d4050$2e77c0f0$@augustcellars.com> In-Reply-To: <06cd01cd4286$0f7d4050$2e77c0f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 19:35:13 -0000 I won't claim to be able to your question to John, but I will make a relat= ed observation. Both you and John suggested that SHA-512 should be used wi= th the KDF when the block encryption algorithm is AES CBC with 512 bit keys= . To my knowledge, the supported key sizes for AES do not include 512 bits - = they are 128, 192, or 256 bits. For those key sizes, I believe that HMAC S= HA-256 is sufficient, as no bits will be "lost". Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Monday, June 04, 2012 12:13 PM To: 'John Bradley' Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms I am afraid I don't understand your position. Are you saying keep things t= he way they are or not? Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Monday, June 04, 2012 9:59 AM > To: Jim Schaad > Cc: jose@ietf.org > Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD=20 > algorithms >=20 > I think there is some merit in having: > AES128CBC + HMAC-SHA256 + SHA256KDF =3D A128CBC > AES256CBC + HMAC-SHA256 + SHA256KDF =3D A256CBC > AES512CNC + HMAC-SHA512 + SHA512KDF =3D A512CBC >=20 > defined as composite algorithms, while keeping the HMAC as a separate=20 > element from the encrypted CMK, as we have it now. >=20 > Using the other RFC lags can be done as later extensions. The current=20 > CBC + > HMAC may not be sexy but it works, and is easy to implement. >=20 > John B. >=20 > On 2012-06-04, at 12:37 PM, Jim Schaad wrote: >=20 > > > > > >> -----Original Message----- > >> From: Matt Miller [mailto:mamille2@cisco.com] > >> Sent: Monday, June 04, 2012 9:31 AM > >> To: Jim Schaad > >> Cc: jose@ietf.org > >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms > >> > >> > >> On Jun 4, 2012, at 10:16, Jim Schaad wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Matt Miller [mailto:mamille2@cisco.com] > >>>> Sent: Monday, June 04, 2012 8:37 AM > >>>> To: Jim Schaad > >>>> Cc: jose@ietf.org > >>>> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD=20 > >>>> algorithms > >>>> > >>>> On Jun 3, 2012, at 12:22, Jim Schaad wrote: > >>>> > >>>>> > >>>>> > >>>>> The message title is deliberately provocative, but does indicate=20 > >>>>> the path that I think we should follow for the document. =20 > >>>>> Specifically what I would like to do is to remove the non AEAD=20 > >>>>> algorithms and replace them with AEAD algorithms that are, more=20 > >>>>> or less, equivalent. > >>>>> This means that I would like define three new algorithms=20 > >>>>> AES128-HS256, > >>>>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. > >>>>> > >>>>> Advantages: > >>>>> > >>>>> 1. The header is smaller as we can eliminate the "int:" field 2. > >>>>> We make it clear that non-AEAD algorithms are not permitted and=20 > >>>>> put it on the algorithm definer and not on the implementer to=20 > >>>>> fix the problem if the proposed algorithm is not an AEAD algorithm. > >>>>> 3. It makes the encryption document simpler as there is now=20 > >>>>> only one encryption/decrypt set of steps to follow. > >>>>> 4. The KDF moves from JWE to JWA where it more properly belongs > 5. > >>>>> The KDF now becomes an implicit parameter of the algorithm and=20 > >>>>> it is easy to change it for an updated one later as necessary=20 > >>>>> for specific algorithms. As it currently stands there is no=20 > >>>>> easy way to change this on an algorithm by algorithm basis. =20 > >>>>> This means that we can use > >>>>> SHA-256 for the first two algorithms and SHA-512 for the last=20 > >>>>> one - this means that we don't "lose bits" in the process of=20 > >>>>> doing the KDF. > >>>>> 6. The test matrix becomes smaller for implementers as there is=20 > >>>>> a list rather than a matrix of possible functions to look at. > >>>> > >>>> +1 > >>>> > >>>> In fact, David McGrew is working on a draft that defines AEAD=20 > >>>> algorithms > >>> that > >>>> re-use AES-CBC + HMAC-SHA2. > >>> > >>> There is also RFC6576 by Peter Gutmann which does the same thing=20 > >>> in a CMS context. > >>> > >>> Jim > >> > >> Did you mean RFC6476 "Using Message Authentication Code (MAC)=20 > >> Encryption in the Cryptographic Message Syntax (CMS)"? > >> > >> In any case, thank you for the reference; I could not find that earlier! > > > > Yes - typo on my part. > >> > >> > >> - m&m > >> > >> Matt Miller - > >> Cisco Systems, Inc. > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Mon Jun 4 13:34: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 A680311E80FC for ; Mon, 4 Jun 2012 13:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkec39I4laby for ; Mon, 4 Jun 2012 13:34:05 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id D632B11E80C5 for ; Mon, 4 Jun 2012 13:34:05 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 7BE002CA45; Mon, 4 Jun 2012 13:34:05 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'John Bradley'" References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <06b901cd4270$4cafea60$e60fbf20$@augustcellars.com> <1200CAC4-5320-47D3-871C-942D8F239092@ve7jtb.com> <06cd01cd4286$0f7d4050$2e77c0f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943665289F6@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665289F6@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Mon, 4 Jun 2012 13:32:50 -0700 Message-ID: <06e301cd4291$368b91a0$a3a2b4e0$@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: AQN7lRnf1JPyv6QP4WEDAazkDoLz4AHErbPTAr7d3QgBTDeYaAGD0X9KAmAdCWYCVCZ2MwG1NBXkkyAN/oA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 04 Jun 2012 20:34:06 -0000 You are correct about the key sizes of AES and I was wrong. I was not paying full attention to that when I wrote the email and was thinking in terms of matching the hash sizes rather than the AES sizes. I believe that this means we could limit to one HMAC algorithm w/ the three AES algorithms for the initially defined algorithms. However in terms of the number of bits "lost" that would depend on the number of bits that were specified as the input to the KDF algorithm. One could say that AES256-HS512 takes a CEK of 512 bits that is then processed to get a 256 bit AES key and a 512 bit HMAC key. If this was then case then one could claim that bits are lost. I would actually recommend this approach if we really wanted to have a 512 bit integrity value with 256 bit AES. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, June 04, 2012 12:26 PM > To: Jim Schaad; 'John Bradley' > Cc: jose@ietf.org > Subject: RE: [jose] Discussion Topic - Lets kill all non AEAD algorithms > > I won't claim to be able to your question to John, but I will make a related > observation. Both you and John suggested that SHA-512 should be used with > the KDF when the block encryption algorithm is AES CBC with 512 bit keys. > > To my knowledge, the supported key sizes for AES do not include 512 bits - > they are 128, 192, or 256 bits. For those key sizes, I believe that HMAC SHA- > 256 is sufficient, as no bits will be "lost". > > Best wishes, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Monday, June 04, 2012 12:13 PM > To: 'John Bradley' > Cc: jose@ietf.org > Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms > > I am afraid I don't understand your position. Are you saying keep things the > way they are or not? > > Jim > > > > -----Original Message----- > > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > > Sent: Monday, June 04, 2012 9:59 AM > > To: Jim Schaad > > Cc: jose@ietf.org > > Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD > > algorithms > > > > I think there is some merit in having: > > AES128CBC + HMAC-SHA256 + SHA256KDF = A128CBC > > AES256CBC + HMAC-SHA256 + SHA256KDF = A256CBC > > AES512CNC + HMAC-SHA512 + SHA512KDF = A512CBC > > > > defined as composite algorithms, while keeping the HMAC as a separate > > element from the encrypted CMK, as we have it now. > > > > Using the other RFC lags can be done as later extensions. The current > > CBC > + > > HMAC may not be sexy but it works, and is easy to implement. > > > > John B. > > > > On 2012-06-04, at 12:37 PM, Jim Schaad wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: Matt Miller [mailto:mamille2@cisco.com] > > >> Sent: Monday, June 04, 2012 9:31 AM > > >> To: Jim Schaad > > >> Cc: jose@ietf.org > > >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD > algorithms > > >> > > >> > > >> On Jun 4, 2012, at 10:16, Jim Schaad wrote: > > >> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Matt Miller [mailto:mamille2@cisco.com] > > >>>> Sent: Monday, June 04, 2012 8:37 AM > > >>>> To: Jim Schaad > > >>>> Cc: jose@ietf.org > > >>>> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD > > >>>> algorithms > > >>>> > > >>>> On Jun 3, 2012, at 12:22, Jim Schaad wrote: > > >>>> > > >>>>> > > >>>>> > > >>>>> The message title is deliberately provocative, but does indicate > > >>>>> the path that I think we should follow for the document. > > >>>>> Specifically what I would like to do is to remove the non AEAD > > >>>>> algorithms and replace them with AEAD algorithms that are, more > > >>>>> or less, > equivalent. > > >>>>> This means that I would like define three new algorithms > > >>>>> AES128-HS256, > > >>>>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. > > >>>>> > > >>>>> Advantages: > > >>>>> > > >>>>> 1. The header is smaller as we can eliminate the "int:" field 2. > > >>>>> We make it clear that non-AEAD algorithms are not permitted and > > >>>>> put it on the algorithm definer and not on the implementer to > > >>>>> fix the problem if the proposed algorithm is not an AEAD algorithm. > > >>>>> 3. It makes the encryption document simpler as there is now > > >>>>> only one encryption/decrypt set of steps to follow. > > >>>>> 4. The KDF moves from JWE to JWA where it more properly belongs > > 5. > > >>>>> The KDF now becomes an implicit parameter of the algorithm and > > >>>>> it is easy to change it for an updated one later as necessary > > >>>>> for specific algorithms. As it currently stands there is no > > >>>>> easy way to change this on an algorithm by algorithm basis. > > >>>>> This means that we can use > > >>>>> SHA-256 for the first two algorithms and SHA-512 for the last > > >>>>> one - this means that we don't "lose bits" in the process of > > >>>>> doing the > KDF. > > >>>>> 6. The test matrix becomes smaller for implementers as there is > > >>>>> a list rather than a matrix of possible functions to look at. > > >>>> > > >>>> +1 > > >>>> > > >>>> In fact, David McGrew is working on a draft that defines AEAD > > >>>> algorithms > > >>> that > > >>>> re-use AES-CBC + HMAC-SHA2. > > >>> > > >>> There is also RFC6576 by Peter Gutmann which does the same thing > > >>> in a CMS context. > > >>> > > >>> Jim > > >> > > >> Did you mean RFC6476 "Using Message Authentication Code (MAC) > > >> Encryption in the Cryptographic Message Syntax (CMS)"? > > >> > > >> In any case, thank you for the reference; I could not find that > earlier! > > > > > > Yes - typo on my part. > > >> > > >> > > >> - m&m > > >> > > >> Matt Miller - > > >> Cisco Systems, Inc. > > > > > > > > > _______________________________________________ > > > 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 ve7jtb@ve7jtb.com Mon Jun 4 17:38: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 4DCA311E8112 for ; Mon, 4 Jun 2012 17:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHHmHQ5K8ytk for ; Mon, 4 Jun 2012 17:38:16 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51D9911E80C2 for ; Mon, 4 Jun 2012 17:38:16 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3933155ggn.31 for ; Mon, 04 Jun 2012 17:38:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=H+CSiAzT1F2mvssSSTZ7F8ZWHkEbV1R69LkfQGMqYyc=; b=K24k5ZezDbUqmPcnoSB6dLlLxGgxVwguQ/0JSJ87IiS5G36nr3O6QB/vRoPs64lCEH DuRfH/tbk1v8TYkj6hPldnsUEYFpGuJgKf8Kdt2uZpvF8lDDnLSBOrMTZpdGAiUbEd76 niSMByv2CyL6wxr9aGhOerXEuoTKuQ51a/okPFcwBWFrG382TWSUnXd1jBe/6onzAtV4 oDp+dVMIgFifRp1u6C2Tlaz56n91/jnVFGoocV6x0Uh+kEu3H/K1dgczXriMRzq32xpe yinLMDuo9croRJXEBTqI3lMcwuDxgvZBCTaXD4qVx81a7C05HnQsaqll6jlfHa/fqxMM 636Q== Received: by 10.236.77.134 with SMTP id d6mr9136854yhe.79.1338856695673; Mon, 04 Jun 2012 17:38:15 -0700 (PDT) Received: from 201-188-222-222.bam.movistar.cl ([201.188.222.222]) by mx.google.com with ESMTPS id e19sm16657ann.10.2012.06.04.17.38.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 17:38:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_17CFD870-02CA-44F6-BB37-FBC500EE3F79"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <06e301cd4291$368b91a0$a3a2b4e0$@augustcellars.com> Date: Mon, 4 Jun 2012 20:38:08 -0400 Message-Id: <95823280-5182-4199-B39C-510BB816CE48@ve7jtb.com> References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <06b901cd4270$4cafea60$e60fbf20$@augustcellars.com> <1200CAC4-5320-47D3-871C-942D8F239092@ve7jtb.com> <06cd01cd4286$0f7d4050$2e77c0f0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943665289F6@TK5EX14MBXC284.redmond.corp.microsoft.com> <06e301cd4291$368b91a0$a3a2b4e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn5ebWCMNQLBWHhbvROwSBo6l95UPBeKsZpuEp2gZJI11hrrujmHePUHMywOSgFCoP5xxfi Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 05 Jun 2012 00:38:17 -0000 --Apple-Mail=_17CFD870-02CA-44F6-BB37-FBC500EE3F79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes while there is rijndael with 512 bit keys it is not NIST approved as = AES. If we are going to allow mixing integrity length and encryption key = length then we are probably better off specifying them separately as = they are now. AES 256 has 256 bits of security as has HMAC-SHA256. (SHA256 for = signatures is only 128 bits of security, confusing isn't it) For our AES-CBC MTI I would keep the HMAC SHA256, the KDF hash SHA256, = and specify it as a single lag dropping the int parameter. Thus giving us: A128CBC =3D AES128CBC + HMAC-SHA2256 + KDF SHA256 A256CBC =3D AES256CBC + HMAC-SHA2256 + KDF SHA256 So it would only drop the now unnecessary int parameter and allow moving = the KDF to algs. Later we could add A256CBC3 when we have SHA 3 if we need to. John On 2012-06-04, at 4:32 PM, Jim Schaad wrote: > You are correct about the key sizes of AES and I was wrong. I was not > paying full attention to that when I wrote the email and was thinking = in > terms of matching the hash sizes rather than the AES sizes. I believe = that > this means we could limit to one HMAC algorithm w/ the three AES = algorithms > for the initially defined algorithms. >=20 > However in terms of the number of bits "lost" that would depend on the > number of bits that were specified as the input to the KDF algorithm. = One > could say that AES256-HS512 takes a CEK of 512 bits that is then = processed > to get a 256 bit AES key and a 512 bit HMAC key. If this was then = case then > one could claim that bits are lost. I would actually recommend this > approach if we really wanted to have a 512 bit integrity value with = 256 bit > AES. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Monday, June 04, 2012 12:26 PM >> To: Jim Schaad; 'John Bradley' >> Cc: jose@ietf.org >> Subject: RE: [jose] Discussion Topic - Lets kill all non AEAD = algorithms >>=20 >> I won't claim to be able to your question to John, but I will make a > related >> observation. Both you and John suggested that SHA-512 should be used = with >> the KDF when the block encryption algorithm is AES CBC with 512 bit = keys. >>=20 >> To my knowledge, the supported key sizes for AES do not include 512 = bits - >> they are 128, 192, or 256 bits. For those key sizes, I believe that = HMAC > SHA- >> 256 is sufficient, as no bits will be "lost". >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Jim Schaad >> Sent: Monday, June 04, 2012 12:13 PM >> To: 'John Bradley' >> Cc: jose@ietf.org >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD = algorithms >>=20 >> I am afraid I don't understand your position. Are you saying keep = things > the >> way they are or not? >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Monday, June 04, 2012 9:59 AM >>> To: Jim Schaad >>> Cc: jose@ietf.org >>> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD >>> algorithms >>>=20 >>> I think there is some merit in having: >>> AES128CBC + HMAC-SHA256 + SHA256KDF =3D A128CBC >>> AES256CBC + HMAC-SHA256 + SHA256KDF =3D A256CBC >>> AES512CNC + HMAC-SHA512 + SHA512KDF =3D A512CBC >>>=20 >>> defined as composite algorithms, while keeping the HMAC as a = separate >>> element from the encrypted CMK, as we have it now. >>>=20 >>> Using the other RFC lags can be done as later extensions. The = current >>> CBC >> + >>> HMAC may not be sexy but it works, and is easy to implement. >>>=20 >>> John B. >>>=20 >>> On 2012-06-04, at 12:37 PM, Jim Schaad wrote: >>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Matt Miller [mailto:mamille2@cisco.com] >>>>> Sent: Monday, June 04, 2012 9:31 AM >>>>> To: Jim Schaad >>>>> Cc: jose@ietf.org >>>>> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD >> algorithms >>>>>=20 >>>>>=20 >>>>> On Jun 4, 2012, at 10:16, Jim Schaad wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Matt Miller [mailto:mamille2@cisco.com] >>>>>>> Sent: Monday, June 04, 2012 8:37 AM >>>>>>> To: Jim Schaad >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD >>>>>>> algorithms >>>>>>>=20 >>>>>>> On Jun 3, 2012, at 12:22, Jim Schaad wrote: >>>>>>>=20 >>>>>>>> >>>>>>>>=20 >>>>>>>> The message title is deliberately provocative, but does = indicate >>>>>>>> the path that I think we should follow for the document. >>>>>>>> Specifically what I would like to do is to remove the non AEAD >>>>>>>> algorithms and replace them with AEAD algorithms that are, more >>>>>>>> or less, >> equivalent. >>>>>>>> This means that I would like define three new algorithms >>>>>>>> AES128-HS256, >>>>>>>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. >>>>>>>>=20 >>>>>>>> Advantages: >>>>>>>>=20 >>>>>>>> 1. The header is smaller as we can eliminate the "int:" field = 2. >>>>>>>> We make it clear that non-AEAD algorithms are not permitted and >>>>>>>> put it on the algorithm definer and not on the implementer to >>>>>>>> fix the problem if the proposed algorithm is not an AEAD > algorithm. >>>>>>>> 3. It makes the encryption document simpler as there is now >>>>>>>> only one encryption/decrypt set of steps to follow. >>>>>>>> 4. The KDF moves from JWE to JWA where it more properly = belongs >>> 5. >>>>>>>> The KDF now becomes an implicit parameter of the algorithm and >>>>>>>> it is easy to change it for an updated one later as necessary >>>>>>>> for specific algorithms. As it currently stands there is no >>>>>>>> easy way to change this on an algorithm by algorithm basis. >>>>>>>> This means that we can use >>>>>>>> SHA-256 for the first two algorithms and SHA-512 for the last >>>>>>>> one - this means that we don't "lose bits" in the process of >>>>>>>> doing the >> KDF. >>>>>>>> 6. The test matrix becomes smaller for implementers as there = is >>>>>>>> a list rather than a matrix of possible functions to look at. >>>>>>>=20 >>>>>>> +1 >>>>>>>=20 >>>>>>> In fact, David McGrew is working on a draft that defines AEAD >>>>>>> algorithms >>>>>> that >>>>>>> re-use AES-CBC + HMAC-SHA2. >>>>>>=20 >>>>>> There is also RFC6576 by Peter Gutmann which does the same thing >>>>>> in a CMS context. >>>>>>=20 >>>>>> Jim >>>>>=20 >>>>> Did you mean RFC6476 "Using Message Authentication Code (MAC) >>>>> Encryption in the Cryptographic Message Syntax (CMS)"? >>>>>=20 >>>>> In any case, thank you for the reference; I could not find that >> earlier! >>>>=20 >>>> Yes - typo on my part. >>>>>=20 >>>>>=20 >>>>> - m&m >>>>>=20 >>>>> Matt Miller - >>>>> Cisco Systems, Inc. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 --Apple-Mail=_17CFD870-02CA-44F6-BB37-FBC500EE3F79 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw NTAwMzgwOVowIwYJKoZIhvcNAQkEMRYEFOpLP2Xbkq72cruFOXOwt5P8HOxRMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AAjl0vtduObeaChC9ov/tihSX90ctGS1tdjP23BVIK9/Q25KIoJdSqWu6Rq3sv3V7A8h+J4Mi8qQ xMCPe8DIPfh18l0XhYZvcE1gDxucUxn6+k73x9No7Bx6oJFWu4ik0J5EkS8/LQMrU1DXPhCqT2Aj 6WEPYvdTXZVZgyU7d8nMMv7xFfGiGtwU6/5AjC73fBAWil1d9YE+UYSMZbqfMkIS+p8OnVZSptVr Bo4sM1Pxdrg7yAMFBovkge+HbynHKukPtfxN3gx226kNDDMoWLPM6Wupw7UVULu4wOAvMsxaOLl9 UBwb2y6j/SyUd4aNcK7iFu9m8oYbk2m0eIeABooAAAAAAAA= --Apple-Mail=_17CFD870-02CA-44F6-BB37-FBC500EE3F79-- From rbarnes@bbn.com Tue Jun 5 05:56: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 0DEAE21F866C for ; Tue, 5 Jun 2012 05:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-+8A6huVHwu for ; Tue, 5 Jun 2012 05:56:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5A421F866E for ; Tue, 5 Jun 2012 05:56:55 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:62549) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SbtJ5-00065N-N4; Tue, 05 Jun 2012 08:56:19 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> Date: Tue, 5 Jun 2012 08:56:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org, 'Matt Miller' Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 05 Jun 2012 12:56:56 -0000 The McGrew reference is: I find Dave's document slightly nicer because=20 (1) It doesn't require a KDF (it just specifies each key separately); = and (2) It appends the MAC to the ciphertext, rather than requiring a = separate field On Jun 4, 2012, at 12:16 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Matt Miller [mailto:mamille2@cisco.com] >> Sent: Monday, June 04, 2012 8:37 AM >> To: Jim Schaad >> Cc: jose@ietf.org >> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD = algorithms >>=20 >> On Jun 3, 2012, at 12:22, Jim Schaad wrote: >>=20 >>> >>>=20 >>> The message title is deliberately provocative, but does indicate the >>> path that I think we should follow for the document. Specifically >>> what I would like to do is to remove the non AEAD algorithms and >>> replace them with AEAD algorithms that are, more or less, = equivalent. >>> This means that I would like define three new algorithms = AES128-HS256, >>> AES256-HS256 and AES512-HS512 that are AEAD algorithms. >>>=20 >>> Advantages: >>>=20 >>> 1. The header is smaller as we can eliminate the "int:" field 2. = We >>> make it clear that non-AEAD algorithms are not permitted and put it = on >>> the algorithm definer and not on the implementer to fix the problem = if >>> the proposed algorithm is not an AEAD algorithm. >>> 3. It makes the encryption document simpler as there is now only = one >>> encryption/decrypt set of steps to follow. >>> 4. The KDF moves from JWE to JWA where it more properly belongs 5. >>> The KDF now becomes an implicit parameter of the algorithm and it is >>> easy to change it for an updated one later as necessary for specific >>> algorithms. As it currently stands there is no easy way to change >>> this on an algorithm by algorithm basis. This means that we can use >>> SHA-256 for the first two algorithms and SHA-512 for the last one - >>> this means that we don't "lose bits" in the process of doing the = KDF. >>> 6. The test matrix becomes smaller for implementers as there is a >>> list rather than a matrix of possible functions to look at. >>=20 >> +1 >>=20 >> In fact, David McGrew is working on a draft that defines AEAD = algorithms > that >> re-use AES-CBC + HMAC-SHA2. >=20 > There is also RFC6576 by Peter Gutmann which does the same thing in a = CMS > context. >=20 > Jim >=20 >>=20 >>=20 >> - m&m >>=20 >> Matt Miller - >> Cisco Systems, Inc. >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Tue Jun 5 19:07: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 6595321F87D8 for ; Tue, 5 Jun 2012 19:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdda09aT8U-2 for ; Tue, 5 Jun 2012 19:07:22 -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 BE84121F87D7 for ; Tue, 5 Jun 2012 19:07:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,721,1330866000"; d="scan'208";a="75890265" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 06 Jun 2012 12:07:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6733"; a="15809261" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcani.tcif.telstra.com.au with ESMTP; 06 Jun 2012 12:07:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 6 Jun 2012 12:07:18 +1000 From: "Manger, James H" To: "Richard L. Barnes" , Jim Schaad Date: Wed, 6 Jun 2012 12:07:17 +1000 Thread-Topic: [jose] Discussion Topic - Lets kill all non AEAD algorithms Thread-Index: Ac1DGrK8PzSz2hnWT02vxJMVS52ilAAa8JdA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F5348F9B@WSMSG3153V.srv.dir.telstra.com> References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@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 Cc: "jose@ietf.org" , 'Matt Miller' Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 06 Jun 2012 02:07:23 -0000 Pj4+IEluIGZhY3QsIERhdmlkIE1jR3JldyBpcyB3b3JraW5nIG9uIGEgZHJhZnQgdGhhdCBkZWZp bmVzIEFFQUQNCj4+PiBhbGdvcml0aG1zIHRoYXQgcmUtdXNlIEFFUy1DQkMgKyBITUFDLVNIQTIu DQo+Pj4NCj4+PiBUaGVyZSBpcyBhbHNvIFJGQzY1NzYgYnkgUGV0ZXIgR3V0bWFubiB3aGljaCBk b2VzIHRoZSBzYW1lIHRoaW5nIGluIGENCj4+PiBDTVMgY29udGV4dC4NCg0KPiBUaGUgTWNHcmV3 IHJlZmVyZW5jZSBpczoNCj4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1jZ3Jl dy1hZWFkLWFlcy1jYmMtaG1hYy1zaGExLTAxPg0KPiANCj4gSSBmaW5kIERhdmUncyBkb2N1bWVu dCBzbGlnaHRseSBuaWNlciBiZWNhdXNlDQo+ICgxKSBJdCBkb2Vzbid0IHJlcXVpcmUgYSBLREYg KGl0IGp1c3Qgc3BlY2lmaWVzIGVhY2gga2V5IHNlcGFyYXRlbHkpOw0KPiBhbmQNCj4gKDIpIEl0 IGFwcGVuZHMgdGhlIE1BQyB0byB0aGUgY2lwaGVydGV4dCwgcmF0aGVyIHRoYW4gcmVxdWlyaW5n IGENCj4gc2VwYXJhdGUgZmllbGQNCg0KSSBsaWtlIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMt aG1hYy1zaGExIGFzIHdlbGwuDQpUaGUgZHJhZnQgaXMgb3ZlciAzIHllYXJzIG9sZC4gSGFzIGl0 IGJlZW4gYWJhbmRvbmVkPw0KSXMgdGhlcmUgYW4gSUVURiBsaXN0IGRpc2N1c3NpbmcgaXQ/DQoN ClRoZSBzaW1wbGljaXR5IG9mIGp1c3Qgc3BsaXR0aW5nIGEgbWFzdGVyIGtleSBpbnRvIGVuY3J5 cHRpb24gJiBNQUMga2V5cyBpcyBhcHBlYWxpbmcuIFRoYXQgc2ltcGxpY2l0eSBhbG1vc3Qgb3Zl cmNvbWVzIG15IGNvbmNlcm4gdGhhdCBzb21lIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdCBiZSBj YXJlZnVsIGVub3VnaCBpbiBvbmx5IHVzaW5nIGEgZ2l2ZW4gc2VjcmV0IHdpdGggYSBzaW5nbGUg YWxnb3JpdGhtLiBJdCB3b3VsZCBiZSBpbnNlY3VyZSBpZiB0aGUgc2FtZSBzZWNyZXQgd2FzIHNw bGl0IGRpZmZlcmVudGx5IGJhc2VkIG9uIHRoZSBhbGcgaWQgaW4gYSByZWNlaXZlZCBtZXNzYWdl IC0tIGFuZCBJJ20gbm90IHRoYXQgY29uZmlkZW50IHRoYXQgYSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyB3YXJuaW5nIHdvdWxkIGJlIHN1ZmZpY2llbnQgdG8gYXZvaWQgdGhpcy4NCg0KTm93IEkg anVzdCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIG5vbmNlIGFu ZCBhbiBJVi4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From rbarnes@bbn.com Tue Jun 5 19:48: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 1F62711E8097 for ; Tue, 5 Jun 2012 19:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANMMtunbX9uy for ; Tue, 5 Jun 2012 19:48:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 979B511E808C for ; Tue, 5 Jun 2012 19:48:06 -0700 (PDT) Received: from [128.89.255.82] (port=53943) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sc6HM-0000i4-Pb; Tue, 05 Jun 2012 22:47:24 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5348F9B@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 5 Jun 2012 22:47:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F5348F9B@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Jim Schaad , "jose@ietf.org" , 'Matt Miller' Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 06 Jun 2012 02:48:07 -0000 On Jun 5, 2012, at 10:07 PM, Manger, James H wrote: >>>> In fact, David McGrew is working on a draft that defines AEAD >>>> algorithms that re-use AES-CBC + HMAC-SHA2. >>>>=20 >>>> There is also RFC6576 by Peter Gutmann which does the same thing in = a >>>> CMS context. >=20 >> The McGrew reference is: >> >>=20 >> I find Dave's document slightly nicer because >> (1) It doesn't require a KDF (it just specifies each key separately); >> and >> (2) It appends the MAC to the ciphertext, rather than requiring a >> separate field >=20 > I like draft-mcgrew-aead-aes-cbc-hmac-sha1 as well. > The draft is over 3 years old. Has it been abandoned? > Is there an IETF list discussing it? >=20 > The simplicity of just splitting a master key into encryption & MAC = keys is appealing. That simplicity almost overcomes my concern that some = implementations will not be careful enough in only using a given secret = with a single algorithm. It would be insecure if the same secret was = split differently based on the alg id in a received message -- and I'm = not that confident that a Security Considerations warning would be = sufficient to avoid this. >=20 > Now I just need to understand the difference between a nonce and an = IV. Dave tells me he's working on reviving it. But obviously, it's not an = RFC yet, so standard caveats apply. --Richard= From ve7jtb@ve7jtb.com Wed Jun 6 08: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 8FC4221F8869 for ; Wed, 6 Jun 2012 08:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukSYBpXn9lTH for ; Wed, 6 Jun 2012 08:59:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C25CE21F85C9 for ; Wed, 6 Jun 2012 08:59:15 -0700 (PDT) Received: by yenq13 with SMTP id q13so5675068yen.31 for ; Wed, 06 Jun 2012 08:59:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ZEF18NLdPSZ2nj4pXURcOd/U2GxfG4mjYKkYAr2WFG0=; b=WOpWs0gXfapbfOKtv/D7KnhqrAoRvBf9Qy1qx1o4wIQz7SRjgN8++60Hf0qPHtgcgt CQoqxV2flGM+45cVT4NHXj028W4JvIyo8bbj7KJh3cwk+aSLtGhpdvovHRXEKcK/7kYz cJi7NyWr66hMArtG4FmptkV0QN3r0eNfzpQsx1Y4XsgFMNYBtKZPtVcm/5QIrcv57Fit prBM2x3DzS+B0BRHszkVh/zN63YKjRvDjHKZqJ4IHWuQAr0qjTCpMHTW0xx/Pr6aMlt/ 8qcTXdLBZEhgW552CQR2cO1lDSRAymw9KJVVmM7dYpZ1CUueHrxazK5LGsoNecsaRmJV j4UA== Received: by 10.236.78.39 with SMTP id f27mr16439224yhe.121.1338998355263; Wed, 06 Jun 2012 08:59:15 -0700 (PDT) Received: from [192.168.1.213] (190-20-5-57.baf.movistar.cl. [190.20.5.57]) by mx.google.com with ESMTPS id p29sm613612yhl.19.2012.06.06.08.59.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jun 2012 08:59:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_E9C0F148-E0C8-4FE4-8669-84D93F3DA6C1"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5348F9B@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 6 Jun 2012 11:59:04 -0400 Message-Id: <49C132AD-2591-4997-84E0-60DE00F4D32E@ve7jtb.com> References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F5348F9B@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn/y40sZbOE8pkqnVMq/t3sEoRoDRrtz05D6Jzp5Cey1JS2PxgYPH/qhzmU8aePWWD4C5je Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 06 Jun 2012 15:59:16 -0000 --Apple-Mail=_E9C0F148-E0C8-4FE4-8669-84D93F3DA6C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Using a KDF to create separate encryption and integrity values is a = perfectly fine way to do it. We can add other algorithms later. We have people and products waiting = for this. If we wait for David or others, people will have to go forward without = JOSE.=20 Combining the symmetric encryption & integrity algorithm into a single = value is fine, and not a significant code change in most cases. Waiting for additional algorithms is not. =20 The lag from David's RFC can be added later if there is traction for it. John B. On 2012-06-05, at 10:07 PM, Manger, James H wrote: >>>> In fact, David McGrew is working on a draft that defines AEAD >>>> algorithms that re-use AES-CBC + HMAC-SHA2. >>>>=20 >>>> There is also RFC6576 by Peter Gutmann which does the same thing in = a >>>> CMS context. >=20 >> The McGrew reference is: >> >>=20 >> I find Dave's document slightly nicer because >> (1) It doesn't require a KDF (it just specifies each key separately); >> and >> (2) It appends the MAC to the ciphertext, rather than requiring a >> separate field >=20 > I like draft-mcgrew-aead-aes-cbc-hmac-sha1 as well. > The draft is over 3 years old. Has it been abandoned? > Is there an IETF list discussing it? >=20 > The simplicity of just splitting a master key into encryption & MAC = keys is appealing. That simplicity almost overcomes my concern that some = implementations will not be careful enough in only using a given secret = with a single algorithm. It would be insecure if the same secret was = split differently based on the alg id in a received message -- and I'm = not that confident that a Security Considerations warning would be = sufficient to avoid this. >=20 > Now I just need to understand the difference between a nonce and an = IV. >=20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_E9C0F148-E0C8-4FE4-8669-84D93F3DA6C1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw NjE1NTkwNVowIwYJKoZIhvcNAQkEMRYEFNnSXDfi5TXIUmj3eujVH9V0tPmuMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABOxJtZWgfSQJgrHtejuAfjh4fQQjt5fRin3DrexmTY2DXXi08T7fuSdN3CMqo2BtFnRo3GOqhFS P6eoAAfjEr6Yw/S7BsYmEyr3TPDb8EMFmW8i2I6NwoaJvrvweR7ArPl30wkVHa7I8iYYKbN5xP8K mtHdfjtQbRPMJdY859fltWM9AEEDd3CDJjbbFhWYrtzQ5yaLDu+JEGYoXHNYHqsnpD/LzRC0sN8D u1+MscNMWDzBKl5uSXaGIwNnNx/BYzHygtrstOMprU+yjB66fvE5P+fwHOgBK4VftPvmT3d9llZQ dYckPR/eTlCKq0XuByizuFfR7rdUtnJ8qPUQndUAAAAAAAA= --Apple-Mail=_E9C0F148-E0C8-4FE4-8669-84D93F3DA6C1-- From tonynad@microsoft.com Wed Jun 6 09:32:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A73721F8678 for ; Wed, 6 Jun 2012 09:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MImZmvsyG6bJ for ; Wed, 6 Jun 2012 09:32:38 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7711721F8598 for ; Wed, 6 Jun 2012 09:32:38 -0700 (PDT) Received: from mail60-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Jun 2012 16:31:52 +0000 Received: from mail60-am1 (localhost [127.0.0.1]) by mail60-am1-R.bigfish.com (Postfix) with ESMTP id 172552008A for ; Wed, 6 Jun 2012 16:31:52 +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: -33 X-BigFish: VS-33(zz9371I936eI542M1432N98dKzz1202h1082kzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail60-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1 (MessageSwitch) id 1339000310262666_13361; Wed, 6 Jun 2012 16:31:50 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.236]) by mail60-am1.bigfish.com (Postfix) with ESMTP id 34184A0046 for ; Wed, 6 Jun 2012 16:31:50 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Jun 2012 16:31:47 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 6 Jun 2012 16:32:00 +0000 Received: from mail109-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Jun 2012 16:28:52 +0000 Received: from mail109-db3 (localhost [127.0.0.1]) by mail109-db3-R.bigfish.com (Postfix) with ESMTP id E14A7607A7 for ; Wed, 6 Jun 2012 16:04:19 +0000 (UTC) Received: from mail109-db3 (localhost.localdomain [127.0.0.1]) by mail109-db3 (MessageSwitch) id 1338998657858303_2128; Wed, 6 Jun 2012 16:04:17 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.237]) by mail109-db3.bigfish.com (Postfix) with ESMTP id CE08E320042; Wed, 6 Jun 2012 16:04:17 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Jun 2012 16:04:15 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.180]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0152.000; Wed, 6 Jun 2012 16:04:57 +0000 From: Anthony Nadalin To: John Bradley , "Manger, James H" Thread-Topic: [jose] Discussion Topic - Lets kill all non AEAD algorithms Thread-Index: Ac1BtFQuWxXrJ2JcQdivhiunPGbSqwAs5hIAAAFbMwAAK1UFAAAbmuCAAB0MuQAAACQiEA== Date: Wed, 6 Jun 2012 16:04:55 +0000 Message-ID: References: <066801cd41b5$e63fcf80$b2bf6e80$@augustcellars.com> <06a501cd426d$5a54fc80$0efef580$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F5348F9B@WSMSG3153V.srv.dir.telstra.com> <49C132AD-2591-4997-84E0-60DE00F4D32E@ve7jtb.com> In-Reply-To: <49C132AD-2591-4997-84E0-60DE00F4D32E@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.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: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD 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, 06 Jun 2012 16:32:39 -0000 This can be a big code change and puts the burden on the developer until th= e libraries can catch up, also there are cases where I'm signing encrypted = content and would not like to be forced into KDF -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Joh= n Bradley Sent: Wednesday, June 06, 2012 8:59 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms Using a KDF to create separate encryption and integrity values is a perfect= ly fine way to do it. We can add other algorithms later. We have people and products waiting fo= r this. If we wait for David or others, people will have to go forward without JOS= E.=20 Combining the symmetric encryption & integrity algorithm into a single valu= e is fine, and not a significant code change in most cases. Waiting for additional algorithms is not. =20 The lag from David's RFC can be added later if there is traction for it. John B. On 2012-06-05, at 10:07 PM, Manger, James H wrote: >>>> In fact, David McGrew is working on a draft that defines AEAD=20 >>>> algorithms that re-use AES-CBC + HMAC-SHA2. >>>>=20 >>>> There is also RFC6576 by Peter Gutmann which does the same thing in=20 >>>> a CMS context. >=20 >> The McGrew reference is: >> >>=20 >> I find Dave's document slightly nicer because >> (1) It doesn't require a KDF (it just specifies each key separately);=20 >> and >> (2) It appends the MAC to the ciphertext, rather than requiring a=20 >> separate field >=20 > I like draft-mcgrew-aead-aes-cbc-hmac-sha1 as well. > The draft is over 3 years old. Has it been abandoned? > Is there an IETF list discussing it? >=20 > The simplicity of just splitting a master key into encryption & MAC keys = is appealing. That simplicity almost overcomes my concern that some impleme= ntations will not be careful enough in only using a given secret with a sin= gle algorithm. It would be insecure if the same secret was split differentl= y based on the alg id in a received message -- and I'm not that confident t= hat a Security Considerations warning would be sufficient to avoid this. >=20 > Now I just need to understand the difference between a nonce and an IV. >=20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Thu Jun 7 11:57: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 4878821F86B0 for ; Thu, 7 Jun 2012 11:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTqssaM+RnY7 for ; Thu, 7 Jun 2012 11:57:17 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0621F85BE for ; Thu, 7 Jun 2012 11:57:01 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9529738F20; Thu, 7 Jun 2012 11:57:01 -0700 (PDT) From: "Jim Schaad" To: , Date: Thu, 7 Jun 2012 11:55:50 -0700 Message-ID: <007d01cd44df$28c901b0$7a5b0510$@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: Ac1EcmBIQ3mOBeSpSjW7y6QusPnZLQ== Content-Language: en-us Subject: [jose] json-web-encryption -02 comments 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, 07 Jun 2012 18:57:18 -0000 Introduction 1. I would separate the introduction into two paragraphs. One to address the general encryption issue and one to address the compact serialization issues. This will allow for an easier addition/removal to deal with other serialization issues. 2. I find sentence #2 confusing since this document is defining how to do the encryption process so we are not really dealing with pre-encrypted content which is what this appears to me to say. 3. What do you mean by the type of content being encrypted? This could either mean the format of the content (i.e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON signature object). 4. I think a new paragraph should start with "Cryptographic algorithms..." this is a new topic. (What is not in this document.) Section 3 1. Simple clarity s/confidentiality of the contents of the Plaintext/confidentiality of the Plaintext/ Section 4 - JWE Header 1. Do we think parsers can enforce the uniqueness requirement? 2. What does it mean to reject a JWE? Should it decrypt and say it is a bad decrypt or should it fail to decrypt? Section 4.1.1 1. You should be constant about what you call the encryption key, master key or JWE Encrypted key. A search and replace should be done to make them constant. 2. Refer to the registry not to the document for the list of algorithms. Section 4.1.2 1. See comment 2 above 2. the encryption algorithm is not used to secure the cipher text. It is used to produce the cipher text 3. Why does the enc algorithm not require the existence of a key for it's use? Section 4.1.4 1. (Curiosity question) Other than "size" is there a reason that an iv must be base64url encoded? 2. The presence of this parameter MUST be specified for all content encryption algorithms. Section 4.1.5 1. See comment 2 above - alternate language would be say MUST be absent unless otherwise specified by the algorithm. 2. epk should talk about key agreement algorithms not a specific algorithm. 3. Content of the key should be specified by the algorithm and not by this document. Section 4.1.6 1. Should specify the use the "alg" registry for the zip parameter (in case a new one comes into existence) and this algorithm should be registered as the only algorithm. Section 4.1.7 1. Should make clear that this is the way of identifying what private key is needed to decrypt the content. 2. Should this be used? It implies that the decryptor needs to do the following: a) Get the keys b) For each key - i) Do I have the private key for this? ii) Does it match the algorithm? iii) Does it work? c) if no function keys found then ---??? Section 4.1.8 1. See comment 1 above. Section 4.1.9 1. I would eliminate the (implicit) requirement that the certificate be validated before decryption. There is no reason that a client should not be able to decrypt a message to themselves if their certificate has been revoked or is expired. This is just a requirement at send time. Section 4.1.11 1. I don't understand the format used here. The data could be either encoded as a string or an array of strings or something else that is a concatenated string form. 2. Why is this not base64url encoded given that all other locations are? 3. See comment 1 above Section 4.1.12 1. This is so underspecified that I would know how to go about using it. Any code that I wrote would therefore ignore it. Section 4.1.13 1. The list of possible typ values should apparently include the mime registry as well. This is neither in the value registry (which should probably be setup to avoid collisions with mime types) or a URI. Section 4.2 1. Should re-iterate the "if you don't know it then reject it" sentence here - it has been a long time since we have seen it. (Ditto for section 4.3) Section 5 1. I disagree with the concept of using a key agree algorithm to create the CMK. Look at CMS to see how they handle key agree algorithms to create a key wrap key 2. In step 8 - when did you create the encoded JWE header? 3. Separate the serialization format from the encryption algorithm. This may just affect step 14. 4. Note previous discussion on only documenting AEAD algorithms Section 6 1. Separate serialization from message decryption. If alternate serializations are used then step 1 fails. 2. Note that you have imposed some additional restrictions on the JSE header in step three - specifically that no duplicate fields exist. This is not in the decryption process. Section 7 1. If you are using the NIST KDF function, then the length of the output key should really be included in the OtherInfo Section 8.1 1. Refer to the registry not to the document (ditto for section 8.2) Section 11.1 1. Should there be an optional parameter which describes which serialization method is being used? 2. Check with IANA if you or the IESG should be listed under the contact section. From dick.hardt@gmail.com Sun Jun 10 20:18: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 2200421F84D0 for ; Sun, 10 Jun 2012 20:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osw6Fy3DRPdn for ; Sun, 10 Jun 2012 20:18:56 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F13E21F84CE for ; Sun, 10 Jun 2012 20:18:56 -0700 (PDT) Received: by dacx6 with SMTP id x6so4732027dac.31 for ; Sun, 10 Jun 2012 20:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6JQkG0dOMETTpltjdgaDhhVMZicWIcLHLfdTdT7kEQo=; b=vk9J5iZeIPjyPCxUzC2aqE5eyMy/yMJiv/Faf+LLPv9PldnNqH8CBqcYPKpBfGSUrY AB0W3Vy00Qni8QnVLhEYPHsl1PuT/uD4R3qvYycrBcalcz5JfT8JRFopRogcNJU5G7Lg mwwmN4zIKnKS9IVqwh7KooQgeWGAXdtL3jLiR1vsIfdl9Uog4TwqvfjM98CR2CvPhoZa 7l2UXzFaMvrfp5laM1MNfaCfEkLP4S9xrWiWmnqcqMCNcvEhz2wwmG/dGo+txqtd35lM hTc7CnoCAE1nAG5SyiU6Sbja0MnxtoR+ING8YCCvtaOa/sBXGg+MrDYgAU4SVe01sY6u ukIw== Received: by 10.68.200.165 with SMTP id jt5mr21398716pbc.90.1339384736388; Sun, 10 Jun 2012 20:18:56 -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 kg4sm16853456pbb.67.2012.06.10.20.18.54 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Jun 2012 20:18:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sun, 10 Jun 2012 20:18:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42847B02-494E-40E1-BCA7-8032882B35CA@gmail.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Draft -02 of 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, 11 Jun 2012 03:18:57 -0000 Hi Mike I was confused for a while reading the spec until I realized that IV = stood for Initialization Vector and not Integrity Value. I was trying to = figure out why it was in both the header and a 4th parameter before I = realizing there were two different parameters. Perhaps change the name = of one of those?=20 BTW: I'm looking forward to more examples. I'm writing a spec that uses = symmetric key encryption of a JWE and the spec is confusing on what to = do! -- Dick=20= From James.H.Manger@team.telstra.com Mon Jun 11 08:04: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 C120221F8656 for ; Mon, 11 Jun 2012 08:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpucErNnDS4L for ; Mon, 11 Jun 2012 08:04:22 -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 49CAD21F8653 for ; Mon, 11 Jun 2012 08:04:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,389,1336312800"; d="scan'208";a="82388594" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 12 Jun 2012 01:04:20 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6738"; a="69238665" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccni.tcif.telstra.com.au with ESMTP; 12 Jun 2012 01:04:20 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 12 Jun 2012 01:04:19 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Tue, 12 Jun 2012 01:04:17 +1000 Thread-Topic: draft-manger-jose-jwsec Thread-Index: Ac1H43jaczmQ35m0T9GUeedFjwFKgg== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.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] draft-manger-jose-jwsec 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, 11 Jun 2012 15:04:23 -0000 SSBoYXZlIHByb3Bvc2VkIHZhcmlvdXMgY2hhbmdlcyB0byBKV1MvSldFL0pXVCByZWNlbnRseSwg YnV0IG5vdCBhbHdheXMgd2l0aCBzcGVjaWZpYyB0ZXh0IGNoYW5nZXMgdG8gdGhlIGV4aXN0aW5n IGRvY3VtZW50cy4gU28gSSBoYXZlIGhhZCBhIGdvIHB1dHRpbmcgdGhlIGNoYW5nZXMgdG9nZXRo ZXIgYXMgYSB2YWd1ZWx5IGNvbXBsZXRlIGRyYWZ0IHNwZWMuIFRoZSByZXN1bHQgaXM6DQoNCiAg SlNPTiBXZWIgU2VjdXJpdHkgTWVzc2FnZSBGb3JtYXQgKEpXc2VjKQ0KICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1tYW5nZXItam9zZS1qd3NlYy0wMA0KDQogIEFic3RyYWN0Og0K ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjcnlwdG9ncmFwaGljIG1lc3NhZ2UgZm9ybWF0 IGJhc2VkIG9uDQogICBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTikgYW5kIGJhc2Ut NjQgZW5jb2RpbmdzIHRvIGJlIGVhc3kNCiAgIGZvciB3ZWIgYXBwbGljYXRpb25zIHRvIGdlbmVy YXRlIGFuZCBwcm9jZXNzLiAgU2lnbmVkLCBlbmNyeXB0ZWQsDQogICBzaWduZWQtdGhlbi1lbmNy eXB0ZWQsIGFuZCB1bnByb3RlY3RlZCBtZXNzYWdlcyBhcmUgc3VwcG9ydGVkIHVzaW5nDQogICBz eW1tZXRyaWMgYW5kL29yIGFzeW1tZXRyaWMga2V5cy4NCg0KQ2hhbmdlcyBmcm9tIEpXUy9KV0Uv SldBL0pXVDoNCg0KMS4gVGhlIG5pY2tuYW1lIEpXc2VjIGlzIHVzZWQgZm9yIGEgbWVzc2FnZSB0 aGF0IGNhbiBiZSBzaWduZWQsIGVuY3J5cHRlZCwgb3IgdW5wcm90ZWN0ZWQuIEFsbCB0aHJlZSBt b2RlcyBhcmUgY292ZXJlZCBieSBvbmUgQUJORiBzeW50YXguIEFsbCB0aHJlZSBhcmUgaW5jbHVk ZWQgaW4gdGhlIG9uZSBzcGVjLg0KDQoyLiBBIHByZWZpeCAoIlUuIiwgIlMuIiwgb3IgIkUuIikg aW5kaWNhdGVzIGlmIGEgbWVzc2FnZSBpcyB1bnByb3RlY3RlZCAoYy5mLiAiYWxnIjoibm9uZSIp LCBzaWduZWQsIG9yIGVuY3J5cHRlZC4gVGhlIHJlc3QgKGFzIGluIEpXUy9KV0UpIGlzIGRvdC1z ZXBhcmF0ZWQgYmFzZTY0dXJsLWVuY29kZWQgY29tcG9uZW50cywgaW5jbHVkaW5nIGEgSlNPTiBv YmplY3QgaGVhZGVyLg0KDQozLiBFYWNoIG1vZGUgY2FuIGNvbXByZXNzIHRoZSBpbnB1dCBkYXRh Lg0KDQo0LiBPbmx5IHVzZXMgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIHdpdGggYWRkaXRpb25h bCBkYXRhIChBRUFEKS4NCg0KNS4gVW5yZWNvZ25pemVkIGhlYWRlciBlbGVtZW50cyBNVVNUIGJl IGlnbm9yZWQgdG8gYWxsb3cgbmV3IGVsZW1lbnRzIHRvIGJlIGRlcGxveWVkIHdpdGhvdXQgYnJl YWtpbmcgaW50ZXJvcGVyYWJpbGl0eS4gSWYgbmV3IGVsZW1lbnRzIHRoYXQgTVVTVCBOT1QgYmUg aWdub3JlZCBhcmUgcmVxdWlyZWQsIHRoZW4gYSBuZXcgbW9kZSBjYW4gZWFzaWx5IGJlIGRlZmlu ZWQuDQoNCjYuIFRoZSBpbml0aWFsaXphdGlvbiB2ZWN0b3IgKElWKSBhbmQgYXV0aGVudGljYXRp b24gdGFnIGFzc29jaWF0ZWQgd2l0aCBhbiBBRUFEIGFsZ29yaXRobSBhcmUgcHJlcGVuZGVkLCBh bmQgYXBwZW5kZWQgdG8gdGhlIGNpcGhlcnRleHQgcmVzcGVjdGl2ZWx5IChpbnN0ZWFkIG9mIHVz aW5nIGEgaGVhZGVyIGVsZW1lbnQgYW5kIGFub3RoZXIgZG90LXNlcGFyYXRlZCBjb21wb25lbnQp LiBJIHRoaW5rIHRoaXMgZm9ybSBpcyBhIHNsaWdodGx5IG5pY2VyLiBJdCBlbmNvdXJhZ2VzIHRo ZSBJViBhbmQgYXV0aGVudGljYXRpb24gdGFnIGxlbmd0aHMgdG8gYmUgZml4ZWQgZm9yIGFuIGFs Z29yaXRobSAoYSBzbGlnaHRseSBsYXp5IHJlY2lwaWVudCB3aWxsIG5vdCBhY2NlcHQgd2hhdGV2 ZXIgbGVuZ3RoIHRoZSBsYXN0IGRvdC1zZXBhcmF0ZWQgbWFjIGZpZWxkIGhhcykuIE9uZSBzaWRl LWVmZmVjdCBpcyB0aGF0IHRoZSBoZWFkZXIgd2lsbCBvZnRlbiByZW1haW4gdGhlIHNhbWUgZm9y IG1lc3NhZ2VzIGJldHdlZW4gdHdvIHBhcnRpZXMgKG5vIHZhcnlpbmctcGVyLW1lc3NhZ2UgZWxl bWVudHMpLCB3aGljaCBtaWdodCBhaWQgcGVyZm9ybWFuY2UgaW4gc29tZSBzaXR1YXRpb25zLg0K DQo3LiBUaGUgb3V0cHV0IG9mIGEga2V5IGFncmVlbWVudCBhbGdvcml0aG0gaXMgdXNlZCB0byBl bmNyeXB0IGEgcmFuZG9tIHBlci1tZXNzYWdlIEFFQUQga2V5LiBJdCBpcyBub3QgdXNlZCBhcyB0 aGUgQUVBRCBrZXkgZGlyZWN0bHkuDQoNCjguIERlZmluZXMgb25lIG1lZGlhIHR5cGUgImFwcGxp Y2F0aW9uL2p3c2VjIiwgbm90IHNlcGFyYXRlIG9uZXMgZm9yIHNpZ25lZCBhbmQgZW5jcnlwdGVk IG1lc3NhZ2VzLg0KDQo5LiBIYXMgdHdvIGhlYWRlciBlbGVtZW50cyBmb3Iga2V5IGlkZW50aWZp ZXJzOiAia2lkIiwgYW5kICJva2lkIi4gIm9raWQiIGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlIG9y aWdpbmF0b3JzIGtleS4gWW91IG5lZWQgYm90aCB3aGVuIHVzaW5nIGEga2V5IGFncmVlbWVudCBh bGdvcml0aG0uDQoNCjEwLiBObyAidHlwIiBoZWFkZXIgZWxlbWVudC4gVGhlcmUgaXMgYSBzZXBh cmF0ZSBpbmRpY2F0b3IgZm9yIHdoZW4gb25lIEpXc2VjIG1lc3NhZ2UgZW52ZWxvcGVzIGFub3Ro ZXIgKGVnIHNpZ25lZC10aGVuLWVuY3J5cHRlZCBtZXNzYWdlKS4NCg0KDQpJIGhvcGUgdGhpcyBp cyBhIHVzZWZ1bCBjb250cmlidXRpb24gdG8gbWFraW5nIGEgZ3JlYXQgSk9TRSBzdWl0ZSBvZiBz cGVjcy4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= From ietf@augustcellars.com Mon Jun 11 12:37: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 C5A9E11E80A4 for ; Mon, 11 Jun 2012 12:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qlRlm2xc3Ly for ; Mon, 11 Jun 2012 12:37:56 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id E951C11E80A2 for ; Mon, 11 Jun 2012 12:37:55 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id E576038F00; Mon, 11 Jun 2012 12:37:49 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Jun 2012 12:36:31 -0700 Message-ID: <01cf01cd4809$85845440$908cfcc0$@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: AQHq+q566jI6ZzOAh78ZgLwPesBMaZa6HJsQ Content-Language: en-us Subject: Re: [jose] draft-manger-jose-jwsec 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, 11 Jun 2012 19:37:57 -0000 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Monday, June 11, 2012 8:04 AM > To: jose@ietf.org > Subject: [jose] draft-manger-jose-jwsec > > I have proposed various changes to JWS/JWE/JWT recently, but not always > with specific text changes to the existing documents. So I have had a go > putting the changes together as a vaguely complete draft spec. The result is: > > JSON Web Security Message Format (JWsec) > http://tools.ietf.org/html/draft-manger-jose-jwsec-00 > > Abstract: > This document describes a cryptographic message format based on > JavaScript Object Notation (JSON) and base-64 encodings to be easy > for web applications to generate and process. Signed, encrypted, > signed-then-encrypted, and unprotected messages are supported using > symmetric and/or asymmetric keys. > > Changes from JWS/JWE/JWA/JWT: > > 1. The nickname JWsec is used for a message that can be signed, encrypted, > or unprotected. All three modes are covered by one ABNF syntax. All three > are included in the one spec. > > 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. > "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- > separated base64url-encoded components, including a JSON object header. > > 3. Each mode can compress the input data. > > 4. Only uses authenticated encryption with additional data (AEAD). > > 5. Unrecognized header elements MUST be ignored to allow new elements > to be deployed without breaking interoperability. If new elements that > MUST NOT be ignored are required, then a new mode can easily be defined. > > 6. The initialization vector (IV) and authentication tag associated with an > AEAD algorithm are prepended, and appended to the ciphertext respectively > (instead of using a header element and another dot-separated component). > I think this form is a slightly nicer. It encourages the IV and authentication tag > lengths to be fixed for an algorithm (a slightly lazy recipient will not accept > whatever length the last dot-separated mac field has). One side-effect is that > the header will often remain the same for messages between two parties > (no varying-per-message elements), which might aid performance in some > situations. I am not sure that there will be a side-effect of a constant header as it would still need to identify the key that is needed to decrypt the message. If you encrypt for multiple people with a single CEK then the IV is normally fixed for all of them anyway. > > 7. The output of a key agreement algorithm is used to encrypt a random per- > message AEAD key. It is not used as the AEAD key directly. (YEAH) > > 8. Defines one media type "application/jwsec", not separate ones for signed > and encrypted messages. > > 9. Has two header elements for key identifiers: "kid", and "okid". "okid" is > used to identify the originators key. You need both when using a key > agreement algorithm. > > 10. No "typ" header element. There is a separate indicator for when one > JWsec message envelopes another (eg signed-then-encrypted message). But what about using the typ header for identifying the content -- i.e. a web token vs an XMPP or ALTO message? Jim > > > I hope this is a useful contribution to making a great JOSE suite of specs. > > -- > James Manger > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Mon Jun 11 12:52: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 3C77F21F8645 for ; Mon, 11 Jun 2012 12:52:03 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFdckKEBcQWN for ; Mon, 11 Jun 2012 12:52:02 -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 3694721F864A for ; Mon, 11 Jun 2012 12:52:01 -0700 (PDT) Received: by werb13 with SMTP id b13so3547540wer.31 for ; Mon, 11 Jun 2012 12:52:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=vVE7VDO6G8yD2aHRXa+tLLMdiY+ln4F8HLZnI4TYLeo=; b=afntiQyoya8SXaJLe3HKv0ryv4Bl6B8QIHo/NXeQHgJGAsK/1irjGMNMZ/J3n3c6Js o/bEEV2VikVAUmF/Rf61OLHC3/avrISkTbuJrPW0yEjfD/YCHAfszunays5KSUi4EhW0 g8vRmi/Mw2LcpbP8ayahh1XPdF+rSDlpJmstP2ZbBeGc4NWYbGTddHGS8x/yKn+PKuYF LlJJHBCx7amSjUFLkn0SseBPgfA2RUkkw5DK7224mwy5Qz2J9Ls7NaOxMx8qLeMrwE2J gJ4LJlxnJn6EkqIk0NLkqJgqndz/j23HF4bId5/x47rixWaYuDCIPq3IdU0GI2kxulue 3ujA== Received: by 10.180.103.4 with SMTP id fs4mr23361738wib.18.1339444316808; Mon, 11 Jun 2012 12:51:56 -0700 (PDT) Received: from [10.0.0.90] (host-92-27-146-217.static.as13285.net. [92.27.146.217]) by mx.google.com with ESMTPS id ch9sm824775wib.8.2012.06.11.12.51.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 12:51:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Jun 2012 20:51:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk7x7qf2vw0fARdOrXqMpbXMBd45RKziCiMSzjORRpLtlrHLMyG0oxcwY/CcuHw0zLp2VSW Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 11 Jun 2012 19:52:03 -0000 I am against adding the prefix that winds up outside the integrity = protection. It is an un necessary and breaking change to many existing JWS = deployments. Taking the IV out of the header removes the integrity check over it and = complicates parsing by JSON. It is not using Authenticated encryption, AEAD only adds integrity not = sender authentication. I agree that for simplicity the output of key agreement should be used = to encrypt a CMK, that adds some more processing for key agreement, = but is overall more consistent. We didn't do a okid because the WG was against my proposal to add static = static key agreement in Paris. If feelings have changed then it should = be in. Sorry for the short response I am traveling. John B. On 2012-06-11, at 4:04 PM, Manger, James H wrote: > I have proposed various changes to JWS/JWE/JWT recently, but not = always with specific text changes to the existing documents. So I have = had a go putting the changes together as a vaguely complete draft spec. = The result is: >=20 > JSON Web Security Message Format (JWsec) > http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >=20 > Abstract: > This document describes a cryptographic message format based on > JavaScript Object Notation (JSON) and base-64 encodings to be easy > for web applications to generate and process. Signed, encrypted, > signed-then-encrypted, and unprotected messages are supported using > symmetric and/or asymmetric keys. >=20 > Changes from JWS/JWE/JWA/JWT: >=20 > 1. The nickname JWsec is used for a message that can be signed, = encrypted, or unprotected. All three modes are covered by one ABNF = syntax. All three are included in the one spec. >=20 > 2. A prefix ("U.", "S.", or "E.") indicates if a message is = unprotected (c.f. "alg":"none"), signed, or encrypted. The rest (as in = JWS/JWE) is dot-separated base64url-encoded components, including a JSON = object header. >=20 > 3. Each mode can compress the input data. >=20 > 4. Only uses authenticated encryption with additional data (AEAD). >=20 > 5. Unrecognized header elements MUST be ignored to allow new elements = to be deployed without breaking interoperability. If new elements that = MUST NOT be ignored are required, then a new mode can easily be defined. >=20 > 6. The initialization vector (IV) and authentication tag associated = with an AEAD algorithm are prepended, and appended to the ciphertext = respectively (instead of using a header element and another = dot-separated component). I think this form is a slightly nicer. It = encourages the IV and authentication tag lengths to be fixed for an = algorithm (a slightly lazy recipient will not accept whatever length the = last dot-separated mac field has). One side-effect is that the header = will often remain the same for messages between two parties (no = varying-per-message elements), which might aid performance in some = situations. >=20 > 7. The output of a key agreement algorithm is used to encrypt a random = per-message AEAD key. It is not used as the AEAD key directly. >=20 > 8. Defines one media type "application/jwsec", not separate ones for = signed and encrypted messages. >=20 > 9. Has two header elements for key identifiers: "kid", and "okid". = "okid" is used to identify the originators key. You need both when using = a key agreement algorithm. >=20 > 10. No "typ" header element. There is a separate indicator for when = one JWsec message envelopes another (eg signed-then-encrypted message). >=20 >=20 > I hope this is a useful contribution to making a great JOSE suite of = specs. >=20 > -- > James Manger >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Mon Jun 11 12:58: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 A56DB11E809B for ; Mon, 11 Jun 2012 12:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBOR6DV3x2HF for ; Mon, 11 Jun 2012 12:58:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5FC11E808C for ; Mon, 11 Jun 2012 12:58:44 -0700 (PDT) Received: by dacx6 with SMTP id x6so5831379dac.31 for ; Mon, 11 Jun 2012 12:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=giiqq8we4TbdrNGgGbDcxuQgma7AcgyEIkI4fYo7fOM=; b=PeOOqSkZcrhKhtj/cOoZoJn7wJXjnN+NjtmfAJlCT394uZ+7LIFSJbdeb3WfPBVzq/ 8EyA3GcofQGA0ecBym6aWjSIETHKF2ovkPsipnIsjSyJ9+i5OvX7Yjw2Rk9Z9NZLwWf4 6Y4HjveHvN5i/AE+IDUfEFcchzmDBCcpVoya/LquHwG0MPw3y4qyUgz34LLJxxIV3nUe h7XrPTVd3GNHcHEHtaUkVO5xuBp/WOxjPsd1WyLEfFNCpC6ukZa5+4k61LiJ9rc4s9cn zD8uxv4zqmUny4QUkcJx7j4pr+NIjiN0M3Kg9B85jaPF2qd68mmc9lJg5VCewdVY+EN1 FDVA== Received: by 10.68.211.131 with SMTP id nc3mr31212398pbc.4.1339444723790; Mon, 11 Jun 2012 12:58:43 -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 or8sm19489179pbb.12.2012.06.11.12.58.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 12:58:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Jun 2012 12:58:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 11 Jun 2012 19:58:44 -0000 On Jun 11, 2012, at 8:04 AM, Manger, James H wrote: > I have proposed various changes to JWS/JWE/JWT recently, but not = always with specific text changes to the existing documents. So I have = had a go putting the changes together as a vaguely complete draft spec. = The result is: >=20 > JSON Web Security Message Format (JWsec) > http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >=20 > Abstract: > This document describes a cryptographic message format based on > JavaScript Object Notation (JSON) and base-64 encodings to be easy > for web applications to generate and process. Signed, encrypted, > signed-then-encrypted, and unprotected messages are supported using > symmetric and/or asymmetric keys. >=20 > Changes from JWS/JWE/JWA/JWT: >=20 > 1. The nickname JWsec is used for a message that can be signed, = encrypted, or unprotected. All three modes are covered by one ABNF = syntax. All three are included in the one spec. >=20 > 2. A prefix ("U.", "S.", or "E.") indicates if a message is = unprotected (c.f. "alg":"none"), signed, or encrypted. The rest (as in = JWS/JWE) is dot-separated base64url-encoded components, including a JSON = object header. yuck -- I don't see the advantage of this over it being in the header -- = I have to parse the header anyway. >=20 > 3. Each mode can compress the input data. good >=20 > 4. Only uses authenticated encryption with additional data (AEAD). I'll defer to crypto heads on this one. >=20 > 5. Unrecognized header elements MUST be ignored to allow new elements = to be deployed without breaking interoperability. If new elements that = MUST NOT be ignored are required, then a new mode can easily be defined. good >=20 > 6. The initialization vector (IV) and authentication tag associated = with an AEAD algorithm are prepended, and appended to the ciphertext = respectively (instead of using a header element and another = dot-separated component). I think this form is a slightly nicer. It = encourages the IV and authentication tag lengths to be fixed for an = algorithm (a slightly lazy recipient will not accept whatever length the = last dot-separated mac field has). One side-effect is that the header = will often remain the same for messages between two parties (no = varying-per-message elements), which might aid performance in some = situations. yuck -- I prefer having each item being dot separated. Simple to get all = items parsed with one line of code. I don't like different parsing = rules. We currently have dot parsing, base64URL parsing and JSON = parsing. >=20 > 7. The output of a key agreement algorithm is used to encrypt a random = per-message AEAD key. It is not used as the AEAD key directly. >=20 > 8. Defines one media type "application/jwsec", not separate ones for = signed and encrypted messages. I'm indifferent -- but if one type, then "application/jwt" >=20 > 9. Has two header elements for key identifiers: "kid", and "okid". = "okid" is used to identify the originators key. You need both when using = a key agreement algorithm. I'll defer to crypto heads on this one. -- Dick= From ietf@augustcellars.com Mon Jun 11 13:15: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 D918421F848F for ; Mon, 11 Jun 2012 13:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc1CTdTyauXF for ; Mon, 11 Jun 2012 13:15:11 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E358411E808E for ; Mon, 11 Jun 2012 13:15:10 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (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 82BF62C9F8; Mon, 11 Jun 2012 13:15:10 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" , "'Manger, James H'" References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> In-Reply-To: <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> Date: Mon, 11 Jun 2012 13:13:49 -0700 Message-ID: <01d301cd480e$bcfbc110$36f34330$@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: AQHq+q566jI6ZzOAh78ZgLwPesBMaQJ82Fb3lqZAj2A= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 11 Jun 2012 20:15:12 -0000 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > John Bradley > Sent: Monday, June 11, 2012 12:52 PM > To: Manger, James H > Cc: jose@ietf.org > Subject: Re: [jose] draft-manger-jose-jwsec > > I am against adding the prefix that winds up outside the integrity protection. > > It is an un necessary and breaking change to many existing JWS deployments. > > Taking the IV out of the header removes the integrity check over it and > complicates parsing by JSON. It does not necessarily remove it from the integrity check. This depends on how the AEAD algorithm is defined. The stream authenticated could be the header || the iv || the message body so that it is still authenticated. > > It is not using Authenticated encryption, AEAD only adds integrity not sender > authentication. The AEAD algorithm class is called Authenticated encryption with additional data. This is the term for the art. Note that this does not imply sender origination which is the additional service one wants signatures for. There is a debate if you get sender origination even with static-static key agreement. > > I agree that for simplicity the output of key agreement should be used to > encrypt a CMK, that adds some more processing for key agreement, but is > overall more consistent. > > We didn't do a okid because the WG was against my proposal to add static > static key agreement in Paris. If feelings have changed then it should be in. > > Sorry for the short response I am traveling. > > John B. > > On 2012-06-11, at 4:04 PM, Manger, James H wrote: > > > I have proposed various changes to JWS/JWE/JWT recently, but not always > with specific text changes to the existing documents. So I have had a go > putting the changes together as a vaguely complete draft spec. The result is: > > > > JSON Web Security Message Format (JWsec) > > http://tools.ietf.org/html/draft-manger-jose-jwsec-00 > > > > Abstract: > > This document describes a cryptographic message format based on > > JavaScript Object Notation (JSON) and base-64 encodings to be easy > > for web applications to generate and process. Signed, encrypted, > > signed-then-encrypted, and unprotected messages are supported using > > symmetric and/or asymmetric keys. > > > > Changes from JWS/JWE/JWA/JWT: > > > > 1. The nickname JWsec is used for a message that can be signed, > encrypted, or unprotected. All three modes are covered by one ABNF > syntax. All three are included in the one spec. > > > > 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. > "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- > separated base64url-encoded components, including a JSON object header. > > > > 3. Each mode can compress the input data. > > > > 4. Only uses authenticated encryption with additional data (AEAD). > > > > 5. Unrecognized header elements MUST be ignored to allow new elements > to be deployed without breaking interoperability. If new elements that > MUST NOT be ignored are required, then a new mode can easily be defined. > > > > 6. The initialization vector (IV) and authentication tag associated with an > AEAD algorithm are prepended, and appended to the ciphertext respectively > (instead of using a header element and another dot-separated component). > I think this form is a slightly nicer. It encourages the IV and authentication tag > lengths to be fixed for an algorithm (a slightly lazy recipient will not accept > whatever length the last dot-separated mac field has). One side-effect is that > the header will often remain the same for messages between two parties > (no varying-per-message elements), which might aid performance in some > situations. > > > > 7. The output of a key agreement algorithm is used to encrypt a random > per-message AEAD key. It is not used as the AEAD key directly. > > > > 8. Defines one media type "application/jwsec", not separate ones for > signed and encrypted messages. > > > > 9. Has two header elements for key identifiers: "kid", and "okid". "okid" is > used to identify the originators key. You need both when using a key > agreement algorithm. > > > > 10. No "typ" header element. There is a separate indicator for when one > JWsec message envelopes another (eg signed-then-encrypted message). > > > > > > I hope this is a useful contribution to making a great JOSE suite of specs. > > > > -- > > 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 From ve7jtb@ve7jtb.com Mon Jun 11 13:34: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 CFD4921F850D for ; Mon, 11 Jun 2012 13:34:52 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulX2YCvwqwTn for ; Mon, 11 Jun 2012 13:34:52 -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 A56EE21F84FC for ; Mon, 11 Jun 2012 13:34:51 -0700 (PDT) Received: by werb13 with SMTP id b13so3581258wer.31 for ; Mon, 11 Jun 2012 13:34:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Cw7y6s1UaaoTJOxkUOEIA18FsyHeXoUMXptIo/QYiQ0=; b=BQQvfT92O+YxfUm68BO7GH4XBuJ9Qb/HtMSx/uF21kBL4zpqFUaS49mirWYX8OLOi9 ht6R9k81sOyPQ/AjFJf+luI2h5WiIXpayryY4DnvMdJvJeG1+T1rWeeYh7KCXu8TPAqb P8IWADL7wwB0jOm0BbIHAgABQSiyHiP47IzL2oLAiG9AbTUfZw/RnpQaS5CwHy6j3J5E Iz9g1SIuXHZFQKBU+OUbl8ajphcTQfVq1gtuneM0dkbSalnyg+aCIHnPywSGKuG44O3J psCvAeJldHNl1CGaxFMA3MaJ9AgvTo8r0Z8WRxwLrLq8u1fBZcjKwFrCFF8kqxqiRQS+ zT2w== Received: by 10.180.85.129 with SMTP id h1mr23586459wiz.2.1339446890513; Mon, 11 Jun 2012 13:34:50 -0700 (PDT) Received: from [10.0.0.90] (host-92-27-146-217.static.as13285.net. [92.27.146.217]) by mx.google.com with ESMTPS id z8sm1215369wiy.1.2012.06.11.13.34.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 13:34:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> Date: Mon, 11 Jun 2012 21:34:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkdXX/aGAKfbQ0SskxZMVrwNg0veuUlh3FUq6/tcnLSwrKisTQx5sADHfEDN0OqS0rpUQmI Cc: "'Manger, James H'" , jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 11 Jun 2012 20:34:52 -0000 inline On 2012-06-11, at 9:13 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> John Bradley >> Sent: Monday, June 11, 2012 12:52 PM >> To: Manger, James H >> Cc: jose@ietf.org >> Subject: Re: [jose] draft-manger-jose-jwsec >>=20 >> I am against adding the prefix that winds up outside the integrity > protection. >>=20 >> It is an un necessary and breaking change to many existing JWS > deployments. >>=20 >> Taking the IV out of the header removes the integrity check over it = and >> complicates parsing by JSON. >=20 > It does not necessarily remove it from the integrity check. This = depends on > how the AEAD algorithm is defined. The stream authenticated could be = the > header || the iv || the message body so that it is still = authenticated. Yes if the iv is prepended or appended to the cyphertext that would = happen however the additional parsing and potential for interop problems = is not worth it. =20 >=20 >>=20 >> It is not using Authenticated encryption, AEAD only adds integrity = not > sender >> authentication. >=20 > The AEAD algorithm class is called Authenticated encryption with = additional > data. This is the term for the art. Note that this does not imply = sender > origination which is the additional service one wants signatures for. = There > is a debate if you get sender origination even with static-static key > agreement. >=20 OK if it is used as a term of art, rather than implying sender = verification.=20 I expect that some people are going to object to being forced to do = integrity if they intend to do signing in some other way. I personally = don't see it as the end of the world.=20 John B. >>=20 >> I agree that for simplicity the output of key agreement should be = used to >> encrypt a CMK, that adds some more processing for key agreement, = but is >> overall more consistent. >>=20 >> We didn't do a okid because the WG was against my proposal to add = static >> static key agreement in Paris. If feelings have changed then it = should > be in. >>=20 >> Sorry for the short response I am traveling. >>=20 >> John B. >>=20 >> On 2012-06-11, at 4:04 PM, Manger, James H wrote: >>=20 >>> I have proposed various changes to JWS/JWE/JWT recently, but not = always >> with specific text changes to the existing documents. So I have had a = go >> putting the changes together as a vaguely complete draft spec. The = result > is: >>>=20 >>> JSON Web Security Message Format (JWsec) >>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >>>=20 >>> Abstract: >>> This document describes a cryptographic message format based on >>> JavaScript Object Notation (JSON) and base-64 encodings to be easy >>> for web applications to generate and process. Signed, encrypted, >>> signed-then-encrypted, and unprotected messages are supported using >>> symmetric and/or asymmetric keys. >>>=20 >>> Changes from JWS/JWE/JWA/JWT: >>>=20 >>> 1. The nickname JWsec is used for a message that can be signed, >> encrypted, or unprotected. All three modes are covered by one ABNF >> syntax. All three are included in the one spec. >>>=20 >>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is = unprotected > (c.f. >> "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- >> separated base64url-encoded components, including a JSON object = header. >>>=20 >>> 3. Each mode can compress the input data. >>>=20 >>> 4. Only uses authenticated encryption with additional data (AEAD). >>>=20 >>> 5. Unrecognized header elements MUST be ignored to allow new = elements >> to be deployed without breaking interoperability. If new elements = that >> MUST NOT be ignored are required, then a new mode can easily be = defined. >>>=20 >>> 6. The initialization vector (IV) and authentication tag associated = with > an >> AEAD algorithm are prepended, and appended to the ciphertext = respectively >> (instead of using a header element and another dot-separated = component). >> I think this form is a slightly nicer. It encourages the IV and > authentication tag >> lengths to be fixed for an algorithm (a slightly lazy recipient will = not > accept >> whatever length the last dot-separated mac field has). One = side-effect is > that >> the header will often remain the same for messages between two = parties >> (no varying-per-message elements), which might aid performance in = some >> situations. >>>=20 >>> 7. The output of a key agreement algorithm is used to encrypt a = random >> per-message AEAD key. It is not used as the AEAD key directly. >>>=20 >>> 8. Defines one media type "application/jwsec", not separate ones for >> signed and encrypted messages. >>>=20 >>> 9. Has two header elements for key identifiers: "kid", and "okid". > "okid" is >> used to identify the originators key. You need both when using a key >> agreement algorithm. >>>=20 >>> 10. No "typ" header element. There is a separate indicator for when = one >> JWsec message envelopes another (eg signed-then-encrypted message). >>>=20 >>>=20 >>> I hope this is a useful contribution to making a great JOSE suite of > specs. >>>=20 >>> -- >>> James Manger >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From cmortimore@salesforce.com Mon Jun 11 15:49: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 D6CD711E80C9 for ; Mon, 11 Jun 2012 15:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+r-YIHhaMsZ for ; Mon, 11 Jun 2012 15:49:42 -0700 (PDT) Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by ietfa.amsl.com (Postfix) with SMTP id 452EF11E808A for ; Mon, 11 Jun 2012 15:49:41 -0700 (PDT) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKT9Z2BA5PlLv7GZPs6K4p/Cysw6USIOt5@postini.com; Mon, 11 Jun 2012 15:49:41 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Mon, 11 Jun 2012 15:48:38 -0700 From: Chuck Mortimore To: John Bradley Date: Mon, 11 Jun 2012 15:48:39 -0700 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1IJFc5rZGsifvURKWQNHyM/tSXTQ== Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> In-Reply-To: <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 11 Jun 2012 22:49:43 -0000 +1=20 - would be concerned if this was outside the integrity check - in abstract the proposal looks fine, but I'm not sure there is enough inc= remental value vs cost of breaking existing deployments -cmort On Jun 11, 2012, at 12:51 PM, John Bradley wrote: > I am against adding the prefix that winds up outside the integrity protec= tion. >=20 > It is an un necessary and breaking change to many existing JWS deployment= s. >=20 > Taking the IV out of the header removes the integrity check over it and c= omplicates parsing by JSON. >=20 > It is not using Authenticated encryption, AEAD only adds integrity not s= ender authentication. >=20 > I agree that for simplicity the output of key agreement should be used to= encrypt a CMK, that adds some more processing for key agreement, but is= overall more consistent. >=20 > We didn't do a okid because the WG was against my proposal to add static = static key agreement in Paris. If feelings have changed then it should be= in. >=20 > Sorry for the short response I am traveling. >=20 > John B. >=20 > On 2012-06-11, at 4:04 PM, Manger, James H wrote: >=20 >> I have proposed various changes to JWS/JWE/JWT recently, but not always = with specific text changes to the existing documents. So I have had a go pu= tting the changes together as a vaguely complete draft spec. The result is: >>=20 >> JSON Web Security Message Format (JWsec) >> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >>=20 >> Abstract: >> This document describes a cryptographic message format based on >> JavaScript Object Notation (JSON) and base-64 encodings to be easy >> for web applications to generate and process. Signed, encrypted, >> signed-then-encrypted, and unprotected messages are supported using >> symmetric and/or asymmetric keys. >>=20 >> Changes from JWS/JWE/JWA/JWT: >>=20 >> 1. The nickname JWsec is used for a message that can be signed, encrypte= d, or unprotected. All three modes are covered by one ABNF syntax. All thre= e are included in the one spec. >>=20 >> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected = (c.f. "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot-= separated base64url-encoded components, including a JSON object header. >>=20 >> 3. Each mode can compress the input data. >>=20 >> 4. Only uses authenticated encryption with additional data (AEAD). >>=20 >> 5. Unrecognized header elements MUST be ignored to allow new elements to= be deployed without breaking interoperability. If new elements that MUST N= OT be ignored are required, then a new mode can easily be defined. >>=20 >> 6. The initialization vector (IV) and authentication tag associated with= an AEAD algorithm are prepended, and appended to the ciphertext respective= ly (instead of using a header element and another dot-separated component).= I think this form is a slightly nicer. It encourages the IV and authentica= tion tag lengths to be fixed for an algorithm (a slightly lazy recipient wi= ll not accept whatever length the last dot-separated mac field has). One si= de-effect is that the header will often remain the same for messages betwee= n two parties (no varying-per-message elements), which might aid performanc= e in some situations. >>=20 >> 7. The output of a key agreement algorithm is used to encrypt a random p= er-message AEAD key. It is not used as the AEAD key directly. >>=20 >> 8. Defines one media type "application/jwsec", not separate ones for sig= ned and encrypted messages. >>=20 >> 9. Has two header elements for key identifiers: "kid", and "okid". "okid= " is used to identify the originators key. You need both when using a key a= greement algorithm. >>=20 >> 10. No "typ" header element. There is a separate indicator for when one = JWsec message envelopes another (eg signed-then-encrypted message). >>=20 >>=20 >> I hope this is a useful contribution to making a great JOSE suite of spe= cs. >>=20 >> -- >> James Manger >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From bcampbell@pingidentity.com Mon Jun 11 16:04:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2858121F8476 for ; Mon, 11 Jun 2012 16:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo+Mrju2zQyy for ; Mon, 11 Jun 2012 16:04:54 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id CFDFB21F8474 for ; Mon, 11 Jun 2012 16:04:53 -0700 (PDT) Received: from mail-vc0-f182.google.com ([209.85.220.182]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKT9Z5k1HaV20q+r9wZOZLp4TgmRi8DW3b@postini.com; Mon, 11 Jun 2012 16:04:53 PDT Received: by vcbfy7 with SMTP id fy7so2721125vcb.41 for ; Mon, 11 Jun 2012 16:04:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=/oBoBn1KXIYJddH/p+NFFsCIKuDvr0Afdq6Vc2oC6Sw=; b=ZtLYs6s3xkOpNGxwqpza/dam1JVdTF0oXXtuxtBw2mvKXdrQWTOvTodGHRVW0nzzpb kY2dyHFAZGee67xO9BgMT72YAI2zBJQr8l0A6mNjrBoJbvbeTkSyQOTgxfe2jv71qVNo lsZWpejxclAPlTtd/dOqWt5rp9ko6eb/M4wf0jO/BCfyKhoIqFfDuXhu7vlSpOBHwqC6 rD3qHy25yY2fAXB2za2pu/bl6nr/iGQwQC8JWEyRudjVDZAtoX/Vuv/3dpQYtE4ibTvp K44r9lXEAHCSu2I56Zo9VV8UATxP6y5+R3LewiI+TQlk202UOQ4dW99sty1n5//jImUo XxJg== Received: by 10.220.157.14 with SMTP id z14mr13500498vcw.73.1339455890775; Mon, 11 Jun 2012 16:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.109.170 with HTTP; Mon, 11 Jun 2012 16:04:20 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> From: Brian Campbell Date: Mon, 11 Jun 2012 17:04:20 -0600 Message-ID: To: Chuck Mortimore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn1SfdMbsjFG5innVtFpiiWiUFfx7ogiIdAZAeUgr2uNLoiSLLsIylXciupymsNgGocVmEs Cc: John Bradley , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 11 Jun 2012 23:04:55 -0000 I'd like to avoid introducing breaking changes unless there's a very good reason to do so. And I don't think the potential value in the prefixing, for example, is sufficient to warrant a breaking change (which it would be). On Mon, Jun 11, 2012 at 4:48 PM, Chuck Mortimore wrote: > +1 > > - would be concerned if this was outside the integrity check > - in abstract the proposal looks fine, but I'm not sure there is enough i= ncremental value vs cost of breaking existing deployments > > -cmort > > On Jun 11, 2012, at 12:51 PM, John Bradley wrote: > >> I am against adding the prefix that winds up outside the integrity prote= ction. >> >> It is an un necessary and breaking change to many existing JWS deploymen= ts. >> >> Taking the IV out of the header removes the integrity check over it and = complicates parsing by JSON. >> >> It is not using Authenticated encryption, =A0AEAD only adds integrity no= t sender authentication. >> >> I agree that for simplicity the output of key agreement should be used t= o encrypt a CMK, =A0that adds some =A0more processing for key agreement, = =A0but is overall more consistent. >> >> We didn't do a okid because the WG was against my proposal to add static= static key agreement in Paris. =A0 If feelings have changed then it should= be in. >> >> Sorry for the short response I am traveling. >> >> John B. >> >> On 2012-06-11, at 4:04 PM, Manger, James H wrote: >> >>> I have proposed various changes to JWS/JWE/JWT recently, but not always= with specific text changes to the existing documents. So I have had a go p= utting the changes together as a vaguely complete draft spec. The result is= : >>> >>> JSON Web Security Message Format (JWsec) >>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >>> >>> Abstract: >>> =A0This document describes a cryptographic message format based on >>> =A0JavaScript Object Notation (JSON) and base-64 encodings to be easy >>> =A0for web applications to generate and process. =A0Signed, encrypted, >>> =A0signed-then-encrypted, and unprotected messages are supported using >>> =A0symmetric and/or asymmetric keys. >>> >>> Changes from JWS/JWE/JWA/JWT: >>> >>> 1. The nickname JWsec is used for a message that can be signed, encrypt= ed, or unprotected. All three modes are covered by one ABNF syntax. All thr= ee are included in the one spec. >>> >>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected= (c.f. "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot= -separated base64url-encoded components, including a JSON object header. >>> >>> 3. Each mode can compress the input data. >>> >>> 4. Only uses authenticated encryption with additional data (AEAD). >>> >>> 5. Unrecognized header elements MUST be ignored to allow new elements t= o be deployed without breaking interoperability. If new elements that MUST = NOT be ignored are required, then a new mode can easily be defined. >>> >>> 6. The initialization vector (IV) and authentication tag associated wit= h an AEAD algorithm are prepended, and appended to the ciphertext respectiv= ely (instead of using a header element and another dot-separated component)= . I think this form is a slightly nicer. It encourages the IV and authentic= ation tag lengths to be fixed for an algorithm (a slightly lazy recipient w= ill not accept whatever length the last dot-separated mac field has). One s= ide-effect is that the header will often remain the same for messages betwe= en two parties (no varying-per-message elements), which might aid performan= ce in some situations. >>> >>> 7. The output of a key agreement algorithm is used to encrypt a random = per-message AEAD key. It is not used as the AEAD key directly. >>> >>> 8. Defines one media type "application/jwsec", not separate ones for si= gned and encrypted messages. >>> >>> 9. Has two header elements for key identifiers: "kid", and "okid". "oki= d" is used to identify the originators key. You need both when using a key = agreement algorithm. >>> >>> 10. No "typ" header element. There is a separate indicator for when one= JWsec message envelopes another (eg signed-then-encrypted message). >>> >>> >>> I hope this is a useful contribution to making a great JOSE suite of sp= ecs. >>> >>> -- >>> 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 From ejay@mgi1.com Mon Jun 11 17:32: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 1428C11E8087 for ; Mon, 11 Jun 2012 17:32: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcoEhu6ivmvy for ; Mon, 11 Jun 2012 17:32:40 -0700 (PDT) Received: from nm21-vm1.access.bullet.mail.sp2.yahoo.com (nm21-vm1.access.bullet.mail.sp2.yahoo.com [98.139.44.177]) by ietfa.amsl.com (Postfix) with SMTP id 12D5611E8083 for ; Mon, 11 Jun 2012 17:32:39 -0700 (PDT) Received: from [98.139.44.101] by nm21.access.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 00:32:37 -0000 Received: from [98.139.44.83] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 00:32:37 -0000 Received: from [127.0.0.1] by omp1020.access.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 00:32:37 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 189312.95067.bm@omp1020.access.mail.sp2.yahoo.com Received: (qmail 34639 invoked by uid 60001); 12 Jun 2012 00:32:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339461156; bh=satJal3OuXTkzTyLbf5QKzgbZaVCaWEX+n9Idqo85A0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VMhqg2UW+WhqOJomvOpgFWRjnYiAe0yk4hJnlERQRDroImuUTWzC1j9HyC06gJ502J92w9+wtnN5uWEYFmkXKi4OkCSvhzL+gh4T6AtdfSyPzKP/dBpn4MZbfepDqtIqIAC/s3EvL4jS0ZR43ad/mrX7zcnmPZJRP3NbGhwKHKk= X-YMail-OSG: _7fdxAQVM1l04hBESKASfPbXf0tHF7ovPKuyMxavy_oT7fk S_zuXsYsvmDJrnYd98mG47.3.it17M0o7PuO_Z8yJykb5xyLNf8d8TiXqeV4 9bp9pFrHEls0AZIvbItkfWK1lA0IE9Wro1SWEdwuuJyTpLRCBntCCQDNo_UD 9_1lmbPovWcoGJDxC_3QXj6CAT_QMQJWvmvtRM14p_Cp0q5IjRb.nm7KLywB qAU.R05dwlYs9CRK9aBwyh4_9RzvJcwW_fuHxqvCRN3dLoyT9OZziz_KcUzI 2lD9gsnpEa1x24WExn0SBuXO0CiKMaCLMsDnEAlQrEWokfD9l61uC9dLZ2oi 2V_s75Q_TaYHvJr2hrFqBg8cmFBGd7InqJyl.5y_eUkyEQAFJlHQlkOCbL0. 9mi7_pqWztpdcsl2BXnMxdKTYGBZhPXWogzl1hSScQmnmgxG6zeIMmXzrRSd sPE2GRiiYDTUML0X9K7tl Received: from [64.140.94.67] by web181308.mail.ne1.yahoo.com via HTTP; Mon, 11 Jun 2012 17:32:36 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.118.349524 References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> Message-ID: <1339461156.31774.YahooMailRC@web181308.mail.ne1.yahoo.com> Date: Mon, 11 Jun 2012 17:32:36 -0700 (PDT) From: Edmund Jay To: Brian Campbell , Chuck Mortimore In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1791919606-1560635163-1339461156=:31774" Cc: John Bradley , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 00:32:41 -0000 --1791919606-1560635163-1339461156=:31774 Content-Type: text/plain; charset=us-ascii +1 to avoid breaking changes to the parsing. Whether parameters are in the header or outside, they still need to be parsed. I prefer them packaged in the JSON header so that one call to the JSON library will return the JSON key/value pairs without some more processing on non-JSON elements. -- Edmund ________________________________ From: Brian Campbell To: Chuck Mortimore Cc: John Bradley ; "Manger, James H" ; "jose@ietf.org" Sent: Mon, June 11, 2012 4:04:57 PM Subject: Re: [jose] draft-manger-jose-jwsec I'd like to avoid introducing breaking changes unless there's a very good reason to do so. And I don't think the potential value in the prefixing, for example, is sufficient to warrant a breaking change (which it would be). On Mon, Jun 11, 2012 at 4:48 PM, Chuck Mortimore wrote: > +1 > > - would be concerned if this was outside the integrity check > - in abstract the proposal looks fine, but I'm not sure there is enough >incremental value vs cost of breaking existing deployments > > -cmort > > On Jun 11, 2012, at 12:51 PM, John Bradley wrote: > >> I am against adding the prefix that winds up outside the integrity protection. >> >> It is an un necessary and breaking change to many existing JWS deployments. >> >> Taking the IV out of the header removes the integrity check over it and >>complicates parsing by JSON. >> >> It is not using Authenticated encryption, AEAD only adds integrity not sender >>authentication. >> >> I agree that for simplicity the output of key agreement should be used to >>encrypt a CMK, that adds some more processing for key agreement, but is >>overall more consistent. >> >> We didn't do a okid because the WG was against my proposal to add static static >>key agreement in Paris. If feelings have changed then it should be in. >> >> Sorry for the short response I am traveling. >> >> John B. >> >> On 2012-06-11, at 4:04 PM, Manger, James H wrote: >> >>> I have proposed various changes to JWS/JWE/JWT recently, but not always with >>>specific text changes to the existing documents. So I have had a go putting the >>>changes together as a vaguely complete draft spec. The result is: >>> >>> JSON Web Security Message Format (JWsec) >>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >>> >>> Abstract: >>> This document describes a cryptographic message format based on >>> JavaScript Object Notation (JSON) and base-64 encodings to be easy >>> for web applications to generate and process. Signed, encrypted, >>> signed-then-encrypted, and unprotected messages are supported using >>> symmetric and/or asymmetric keys. >>> >>> Changes from JWS/JWE/JWA/JWT: >>> >>> 1. The nickname JWsec is used for a message that can be signed, encrypted, or >>>unprotected. All three modes are covered by one ABNF syntax. All three are >>>included in the one spec. >>> >>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. >>>"alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot-separated >>>base64url-encoded components, including a JSON object header. >>> >>> 3. Each mode can compress the input data. >>> >>> 4. Only uses authenticated encryption with additional data (AEAD). >>> >>> 5. Unrecognized header elements MUST be ignored to allow new elements to be >>>deployed without breaking interoperability. If new elements that MUST NOT be >>>ignored are required, then a new mode can easily be defined. >>> >>> 6. The initialization vector (IV) and authentication tag associated with an >>>AEAD algorithm are prepended, and appended to the ciphertext respectively >>>(instead of using a header element and another dot-separated component). I think >>>this form is a slightly nicer. It encourages the IV and authentication tag >>>lengths to be fixed for an algorithm (a slightly lazy recipient will not accept >>>whatever length the last dot-separated mac field has). One side-effect is that >>>the header will often remain the same for messages between two parties (no >>>varying-per-message elements), which might aid performance in some situations. >>> >>> 7. The output of a key agreement algorithm is used to encrypt a random >>>per-message AEAD key. It is not used as the AEAD key directly. >>> >>> 8. Defines one media type "application/jwsec", not separate ones for signed and >>>encrypted messages. >>> >>> 9. Has two header elements for key identifiers: "kid", and "okid". "okid" is >>>used to identify the originators key. You need both when using a key agreement >>>algorithm. >>> >>> 10. No "typ" header element. There is a separate indicator for when one JWsec >>>message envelopes another (eg signed-then-encrypted message). >>> >>> >>> I hope this is a useful contribution to making a great JOSE suite of specs. >>> >>> -- >>> 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 --1791919606-1560635163-1339461156=:31774 Content-Type: text/html; charset=us-ascii
+1 to avoid breaking changes to the parsing.
Whether parameters are in the header or outside, they still need to be parsed.
I prefer them packaged in the JSON header so that one call to the JSON library will return the JSON key/value pairs without some more processing on  non-JSON elements.

-- Edmund

From: Brian Campbell <bcampbell@pingidentity.com>
To: Chuck Mortimore <cmortimore@salesforce.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; "Manger, James H" <James.H.Manger@team.telstra.com>; "jose@ietf.org" <jose@ietf.org>
Sent: Mon, June 11, 2012 4:04:57 PM
Subject: Re: [jose] draft-manger-jose-jwsec

I'd like to avoid introducing breaking changes unless there's a very
good reason to do so. And I don't think the potential value in the
prefixing, for example, is sufficient to warrant a breaking change
(which it would be).


On Mon, Jun 11, 2012 at 4:48 PM, Chuck Mortimore
<cmortimore@salesforce.com> wrote:
> +1
>
> - would be concerned if this was outside the integrity check
> - in abstract the proposal looks fine, but I'm not sure there is enough incremental value vs cost of breaking existing deployments
>
> -cmort
>
> On Jun 11, 2012, at 12:51 PM, John Bradley wrote:
>
>> I am against adding the prefix that winds up outside the integrity protection.
>>
>> It is an un necessary and breaking change to many existing JWS deployments.
>>
>> Taking the IV out of the header removes the integrity check over it and complicates parsing by JSON.
>>
>> It is not using Authenticated encryption,  AEAD only adds integrity not sender authentication.
>>
>> I agree that for simplicity the output of key agreement should be used to encrypt a CMK,  that adds some  more processing for key agreement,  but is overall more consistent.
>>
>> We didn't do a okid because the WG was against my proposal to add static static key agreement in Paris.   If feelings have changed then it should be in.
>>
>> Sorry for the short response I am traveling.
>>
>> John B.
>>
>> On 2012-06-11, at 4:04 PM, Manger, James H wrote:
>>
>>> I have proposed various changes to JWS/JWE/JWT recently, but not always with specific text changes to the existing documents. So I have had a go putting the changes together as a vaguely complete draft spec. The result is:
>>>
>>> JSON Web Security Message Format (JWsec)
>>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00
>>>
>>> Abstract:
>>>  This document describes a cryptographic message format based on
>>>  JavaScript Object Notation (JSON) and base-64 encodings to be easy
>>>  for web applications to generate and process.  Signed, encrypted,
>>>  signed-then-encrypted, and unprotected messages are supported using
>>>  symmetric and/or asymmetric keys.
>>>
>>> Changes from JWS/JWE/JWA/JWT:
>>>
>>> 1. The nickname JWsec is used for a message that can be signed, encrypted, or unprotected. All three modes are covered by one ABNF syntax. All three are included in the one spec.
>>>
>>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot-separated base64url-encoded components, including a JSON object header.
>>>
>>> 3. Each mode can compress the input data.
>>>
>>> 4. Only uses authenticated encryption with additional data (AEAD).
>>>
>>> 5. Unrecognized header elements MUST be ignored to allow new elements to be deployed without breaking interoperability. If new elements that MUST NOT be ignored are required, then a new mode can easily be defined.
>>>
>>> 6. The initialization vector (IV) and authentication tag associated with an AEAD algorithm are prepended, and appended to the ciphertext respectively (instead of using a header element and another dot-separated component). I think this form is a slightly nicer. It encourages the IV and authentication tag lengths to be fixed for an algorithm (a slightly lazy recipient will not accept whatever length the last dot-separated mac field has). One side-effect is that the header will often remain the same for messages between two parties (no varying-per-message elements), which might aid performance in some situations.
>>>
>>> 7. The output of a key agreement algorithm is used to encrypt a random per-message AEAD key. It is not used as the AEAD key directly.
>>>
>>> 8. Defines one media type "application/jwsec", not separate ones for signed and encrypted messages.
>>>
>>> 9. Has two header elements for key identifiers: "kid", and "okid". "okid" is used to identify the originators key. You need both when using a key agreement algorithm.
>>>
>>> 10. No "typ" header element. There is a separate indicator for when one JWsec message envelopes another (eg signed-then-encrypted message).
>>>
>>>
>>> I hope this is a useful contribution to making a great JOSE suite of specs.
>>>
>>> --
>>> 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
--1791919606-1560635163-1339461156=:31774-- From James.H.Manger@team.telstra.com Mon Jun 11 17:56: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 8E1B921F8449 for ; Mon, 11 Jun 2012 17:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84ev2-rxlpED for ; Mon, 11 Jun 2012 17:56:41 -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 D9BD921F8445 for ; Mon, 11 Jun 2012 17:56:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,392,1336312800"; d="scan'208";a="77691360" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 Jun 2012 10:56:39 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6739"; a="68305781" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdvi.tcif.telstra.com.au with ESMTP; 12 Jun 2012 10:56:39 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 12 Jun 2012 10:56:39 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Tue, 12 Jun 2012 10:56:37 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1IDJ3egY74UN3oSsav3iDzgBTODgAHVmHQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 00:56:42 -0000 UmVzcG9uZGluZyB0byBzb21lIGNvbW1lbnRzIGZyb20gRGljaywgSm9obiwgSmltIGFuZCBFZG11 bmQgdG9nZXRoZXI6DQoNCj4+IDIuIEEgcHJlZml4ICgiVS4iLCAiUy4iLCBvciAiRS4iKSBpbmRp Y2F0ZXMgaWYgYSBtZXNzYWdlIGlzDQo+PiB1bnByb3RlY3RlZCAoYy5mLiAiYWxnIjoibm9uZSIp LCBzaWduZWQsIG9yIGVuY3J5cHRlZC4NCiANCj4geXVjayAtLSBJIGRvbid0IHNlZSB0aGUgYWR2 YW50YWdlIG9mIHRoaXMgb3ZlciBpdCBiZWluZyBpbiB0aGUgaGVhZGVyIC0NCj4gLSBJIGhhdmUg dG8gcGFyc2UgdGhlIGhlYWRlciBhbnl3YXkuDQoNCldpdGggSldFL0pXUyB0aGVyZSBpcyBubyBl eHBsaWNpdCBpbmRpY2F0aW9uIG9mIHRoZSBtb2RlICh1bnByb3RlY3RlZC9zaWduZWQvZW5jcnlw dGVkLy4uLj8pIGluIHRoZSBoZWFkZXIuIFlvdSBvbmx5IGtub3cgdGhlIG1vZGUgaWYgeW91IHJl Y29nbml6ZSBhbiBhbGdvcml0aG0gaWRlbnRpZmllciB2YWx1ZS4gTG9va2luZyBmb3IgdGhlIHBy ZXNlbmNlL2Fic2VuY2Ugb2YgYW4gImVuYyIgZmllbGQgYWxtb3N0IHdvcmtzIGFzIGEgaGFjayAt LSBidXQgb25seSB3aGlsZSB0aGVyZSBhcmUgb25seSB0d28gbW9kZXMgKHNpZ25lZCAmIGVuY3J5 cHRlZCkuIEFuIGV4cGxpY2l0ICJtb2RlIjoiZW5jcnlwdGVkIiBoZWFkZXIgZWxlbWVudCBjb3Vs ZCBkbyB0aGUgam9iLCBieSBhIHNpbmdsZSBsZXR0ZXIgdmlzaWJsZSBpbiB0aGUgb3V0ZXIgbWVz c2FnZSBpcyBuaWNlci4NClNvbWUgYWR2YW50YWdlcyBvZiBhIGV4cGxpY2l0IG1vZGUgaW5kaWNh dGlvbjoNCmEpIFRvcC1sZXZlbCBjb2RlIHRoYXQgc3dpdGNoZXMgdG8gZGVjcnlwdGlvbiBvciBz aWduYXR1cmUgdmVyaWZpY2F0aW9uIG1vZHVsZSBkb2Vzbid0IG5lZWQgdG8ga25vdyBhbGcgaWQg dmFsdWVzLg0KYikgQ2FuIGRvIHNvbWUgaW5wdXQgdmFsaWRhdGlvbiBvbiBkYXRhIHdpdGhvdXQg a25vd2luZyBhbnkgc2lnbmF0dXJlIGFsZ29yaXRobXMuIFJlY29nbml6aW5nIHRoZSAiUyIgb3Ig IlUiIHByZWZpeCBpcyBzdWZmaWNpZW50IHRvIGtub3cgdGhlIDNyZCBkb3Qtc2VwYXJhdGVkIGNv bXBvbmVudCBpcyB0aGUgY29udGVudC4NCmMpIEF2b2lkcyBhIGhhY2sgbGlrZSAiYWxnIjoibm9u ZSIgdGhhdCBjYXVzZXMgYSAiZmFrZSIgc2lnbmluZyBhbGdvcml0aG0gdG8gYmUgaW1wbGVtZW50 LCB3aGljaCBpcyBwb3RlbnRpYWxseSBkYW5nZXJvdXMgaWYgcmVjaXBpZW50cyBsb29rIGF0IGEg cmVzdWx0aW5nICJzaWduZWQiIGZsYWcgd2l0aG91dCBjaGVja2luZyB0aGUgYWxnIHZhbHVlLg0K ZCkgQ2FuIGRlZmluZSBuZXcgbW9kZXMgd2l0aG91dCBoYXZpbmcgdG8gd29ycnkgYWJvdXQgaG93 IGV4aXN0aW5nIGNvZGUgbWlnaHQgbWlzaW50ZXJwcmV0IG1lc3NhZ2VzLCBwYXJ0aWN1bGFybHkg aWYgdGhlIG5ldyBtb2RlIHVzZXMgc29tZSBvZiB0aGUgc2FtZSBwcmltaXRpdmVzIHNvIHRoZSBz YW1lIGFsZyBpZHMgYXJlIHVzZWQuDQplKSBEZXZlbG9wZXJzIGNhbiBzZWUgYXQgYSBnbGFuY2Ug aWYgYSBtZXNzYWdlIGlzIHNpZ25lZCwgZW5jcnlwdGVkLCBvciB1bnByb3RlY3RlZC4NCg0KPiBJ IHByZWZlciB0aGVtIHBhY2thZ2VkIGluIHRoZSBKU09OIGhlYWRlciBzbyB0aGF0IG9uZSBjYWxs DQo+IHRvIHRoZSBKU09OIGxpYnJhcnkgd2lsbCByZXR1cm4gdGhlIEpTT04ga2V5L3ZhbHVlIHBh aXJzIHdpdGhvdXQNCj4gc29tZSBtb3JlIHByb2Nlc3Npbmcgb24gIG5vbi1KU09OIGVsZW1lbnRz Lg0KDQpPdGhlciBpdGVtcyBhcmUgYWxyZWFkeSBvdXRzaWRlIHRoZSBKU09OIGhlYWRlcjogdGhl IGVuY3J5cHRlZCBrZXksIHRoZSBzaWduYXR1cmUsIHRoZSBjb250ZW50Lg0KDQoNCj4gSSBhbSBh Z2FpbnN0IGFkZGluZyB0aGUgcHJlZml4IHRoYXQgd2luZHMgdXAgb3V0c2lkZSB0aGUgaW50ZWdy aXR5DQo+IHByb3RlY3Rpb24uDQoNClRoZSBwcmVmaXggaXMgV0lUSElOIHRoZSBpbnRlZ3JpdHkg cHJvdGVjdGlvbi4gVGhlIGRhdGEgdGhhdCBpcyBzaWduZWQsIE1BQ2VkLCBvciB0cmVhdGVkIGFz ICJhZGRpdGlvbmFsIGRhdGEiIGlzIHRoZSBwcmVmaXggb2YgdGhlIEpXc2VjIG1lc3NhZ2UgaW5j bHVkaW5nIHRoZSBpbml0aWFsIGxldHRlciBpbmRpY2F0aW5nIHRoZSBtb2RlLg0KDQoNCj4+IDYu IFRoZSBpbml0aWFsaXphdGlvbiB2ZWN0b3IgKElWKSBhbmQgYXV0aGVudGljYXRpb24gdGFnIGFz c29jaWF0ZWQNCj4+IHdpdGggYW4gQUVBRCBhbGdvcml0aG0gYXJlIHByZXBlbmRlZCwgYW5kIGFw cGVuZGVkIHRvIHRoZSBjaXBoZXJ0ZXh0DQo+PiByZXNwZWN0aXZlbHkgKGluc3RlYWQgb2YgdXNp bmcgYSBoZWFkZXIgZWxlbWVudCBhbmQgYW5vdGhlciBkb3QtDQo+PiBzZXBhcmF0ZWQgY29tcG9u ZW50KS4gSSB0aGluayB0aGlzIGZvcm0gaXMgYSBzbGlnaHRseSBuaWNlci4gSXQNCj4+IGVuY291 cmFnZXMgdGhlIElWIGFuZCBhdXRoZW50aWNhdGlvbiB0YWcgbGVuZ3RocyB0byBiZSBmaXhlZCBm b3IgYW4NCj4+IGFsZ29yaXRobSAoYSBzbGlnaHRseSBsYXp5IHJlY2lwaWVudCB3aWxsIG5vdCBh Y2NlcHQgd2hhdGV2ZXIgbGVuZ3RoDQo+PiB0aGUgbGFzdCBkb3Qtc2VwYXJhdGVkIG1hYyBmaWVs ZCBoYXMpLiBPbmUgc2lkZS1lZmZlY3QgaXMgdGhhdCB0aGUNCj4+IGhlYWRlciB3aWxsIG9mdGVu IHJlbWFpbiB0aGUgc2FtZSBmb3IgbWVzc2FnZXMgYmV0d2VlbiB0d28gcGFydGllcyAobm8NCj4+ IHZhcnlpbmctcGVyLW1lc3NhZ2UgZWxlbWVudHMpLCB3aGljaCBtaWdodCBhaWQgcGVyZm9ybWFu Y2UgaW4gc29tZQ0KPj4gc2l0dWF0aW9ucy4NCg0KPiB5dWNrIC0tIEkgcHJlZmVyIGhhdmluZyBl YWNoIGl0ZW0gYmVpbmcgZG90IHNlcGFyYXRlZC4gU2ltcGxlIHRvIGdldA0KPiBhbGwgaXRlbXMg cGFyc2VkIHdpdGggb25lIGxpbmUgb2YgY29kZS4gSSBkb24ndCBsaWtlIGRpZmZlcmVudCBwYXJz aW5nDQo+IHJ1bGVzLiBXZSBjdXJyZW50bHkgaGF2ZSBkb3QgcGFyc2luZywgYmFzZTY0VVJMIHBh cnNpbmcgYW5kIEpTT04NCj4gcGFyc2luZy4NCg0KQW5kIFVURi04IHBhcnNpbmcuDQpTcGxpdHRp bmcgYSBieXRlIGFycmF5IGF0IGEgc3BlY2lmaWMgbGVuZ3RoIGlzIG5vdCBvbmVyb3VzLiBJdCBw cm9iYWJseSBuZWVkcyB0byBiZSBkb25lIGZvciBzcGVjaWZpYyBhbGdvcml0aG1zIGFueXdheSAo ZWcgdXNpbmcgYSBwcmVmaXggb2YgYSBieXRlIGFycmF5IGFzIGFuIGF1dGhlbnRpY2F0aW9uIHRh Zzsgc3BsaXR0aW5nIGEgc2VjcmV0IGtleSBibG9jayBpbnRvIGJ5dGVzIGZvciBhbiBBRVMga2V5 IGFuZCBITUFDIGtleSkuDQoNCk15IHRyaWdnZXIgZm9yIGFwcGVuZGluZyB0aGUgYXV0aCB0YWcg dG8gdGhlIGNpcGhlcnRleHQgd2FzIGhvdyB0aGUgSmF2YSA3IEFQSSBhZGRlZCBzdXBwb3J0IGZv ciBBRUFEIGFsZ29yaXRobXMuIFRoZSBqYXZheC5jcnlwb3QuQ2lwaGVyIGNsYXNzIDxodHRwOi8v ZG9jcy5vcmFjbGUuY29tL2phdmFzZS83L2RvY3MvYXBpL2phdmF4L2NyeXB0by9DaXBoZXIuaHRt bD4gYWRkZWQgYW4gdXBkYXRlQUFEKCkgbWV0aG9kIHRvIHByb3ZpZGUgdGhlIGFkZGl0aW9uYWwg ZGF0YSwgYnV0IGRpZG4ndCBhZGQgYSBnZXRBdXRoVGFnKCkgbWV0aG9kLiBJbnN0ZWFkLCB0aGUg YXV0aGVudGljYXRpb24gdGFnIGlzIGFwcGVuZGVkIHRvIHRoZSBjaXBoZXJ0ZXh0LiBBIG5pY2Ug ZmVhdHVyZSBpcyB0aGF0IGFwcHMgZG9pbmcgZW5jcnlwdGlvbiwgYnV0IG5vdCB1c2luZyBhZGRp dGlvbmFsIGRhdGEsIGNhbiBzd2l0Y2ggZnJvbSBhICJub3JtYWwiIGVuY3J5cHRpb24gYWxnb3Jp dGhtIHRvIGFuIEFFQUQgYWxnb3JpdGhtIHdpdGhvdXQgY2hhbmdpbmcgdGhlIG1ldGhvZHMgdGhl eSBjYWxsLg0KDQoNCj4+IDguIERlZmluZXMgb25lIG1lZGlhIHR5cGUgImFwcGxpY2F0aW9uL2p3 c2VjIiwgbm90IHNlcGFyYXRlIG9uZXMgZm9yIHNpZ25lZCBhbmQgZW5jcnlwdGVkIG1lc3NhZ2Vz Lg0KDQo+IEknbSBpbmRpZmZlcmVudCAtLSBidXQgaWYgb25lIHR5cGUsIHRoZW4gImFwcGxpY2F0 aW9uL2p3dCINCg0KQnV0ICJKV1QiIG1lYW5zIGEgbWVzc2FnZSB3aG9zZSBjb250ZW50cyBpbiBh IEpTT04gb2JqZWN0IGhvbGRpbmcgY2xhaW1zLg0KDQoNCj4gQnV0IHdoYXQgYWJvdXQgdXNpbmcg dGhlIHR5cCBoZWFkZXIgZm9yIGlkZW50aWZ5aW5nIHRoZSBjb250ZW50DQo+IC0tIGkuZS4gYSB3 ZWIgdG9rZW4gdnMgYW4gWE1QUCBvciBBTFRPIG1lc3NhZ2U/DQoNClRoaXMgaXMgbWV0YWRhdGEg YWJvdXQgdGhlIGRhdGEsIGFzIG9wcG9zZWQgdG8gaW5mbyBhYm91dCB0aGUgc2VjdXJpdHkgYXBw bGllZC4gSSBhbSBub3Qgb3Bwb3NlZCB0byBzdXBwb3J0aW5nIHRoaXMgc29ydCBvZiBtZXRhZGF0 YSwgYW5kIHRoZSBydWxlIHRoYXQgdW5yZWNvZ25pemVkIGhlYWRlciBlbGVtZW50cyBNVVNUIGJl IGlnbm9yZWQgbWFrZXMgaXQgZWFzeSB0byBhZGRlZCB0aGlzIG9yIGFueSBvdGhlciBtZXRhZGF0 YS4NCkkgZGlkIHdhbnQgdG8gc3BsaXQgdGhlIGluZGljYXRpb24gb2YgbmVzdGVkIG1vZGVzIG9m IHByb3RlY3Rpb24gKGVnIHNpZ25lZC10aGVuLWVuY3J5cHRlZCkgZnJvbSBtZXRhZGF0YS4gVGhl IGZvcm1lciBpcyBhbiBpbXBvcnRhbnQgcGFydCBvZiB0aGUgcHJvY2Vzc2luZyBmb3IgYSBKV3Nl YyBtb2R1bGU7IHRoZSBsYXR0ZXIgaXMgb25seSBtZWFuaW5nZnVsIHRvIGEgaGlnaGVyIGxheWVy Lg0KVGhlIEpXVCBzcGVjIGFscmVhZHkgcmVwZWF0cyB0aGUgInR5cCIgZWxlbWVudCBpbiB0aGUg Y29udGVudCAodGhlIEpTT04gb2JqZWN0IGhvbGRpbmcgY2xhaW1zKSBtYWtpbmcgZHVwbGljYXRp b24gaW4gdGhlIEpXc2VjIGhlYWRlciBzb21ld2hhdCByZWR1bmRhbnQuDQoNCi0tDQpKYW1lcyBN YW5nZXINCg== From dick.hardt@gmail.com Mon Jun 11 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 4DD8121F84B4 for ; Mon, 11 Jun 2012 18:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovm2lRHDHnbn for ; Mon, 11 Jun 2012 18:40:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B27421F8460 for ; Mon, 11 Jun 2012 18:40:01 -0700 (PDT) Received: by dacx6 with SMTP id x6so6131534dac.31 for ; Mon, 11 Jun 2012 18:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=lKWAnrxi1ED/jpCa6RKoJekE0UVDNOOBqmV6KTR8WEc=; b=HUL5uVt2xRXLjLE9PXpZQ3396QSRopCJS+5PrzoVkk1i+627vkdA83ZNoP3ZKi1jHd LGyWRzHInBC1Tc/m1D1nExrwlzBOJ/CEhMVWtOGvmS3xY5aNVTbyXv1FkfSxs1KpYxxm oi3NG4ZgQZ5u45Sm4wO+60M0IhM9p6HLOKwAUA0/05N5H+fMDc+1J0UujGJi6TlzOzPE SunkUpnbTZIGLUDWl7ht9rFrFfsgNlJNuioNJJUPYRlU/oYsWR268Jf5T40Lxu6FwGES mYfabCDL6qeepLQA4/2rDrT4CNmfcY61hR8d0qkhvKUYWIvhWCjg4WjbYe5ae8DWP9pM ZpsA== Received: by 10.68.239.164 with SMTP id vt4mr30727450pbc.166.1339465201135; Mon, 11 Jun 2012 18:40:01 -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 ob9sm165703pbb.28.2012.06.11.18.39.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 18:39:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_3F09461D-B5F8-4A05-8140-3074C7B6334C" From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Jun 2012 18:39:57 -0700 Message-Id: <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 01:40:02 -0000 --Apple-Mail=_3F09461D-B5F8-4A05-8140-3074C7B6334C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 11, 2012, at 5:56 PM, Manger, James H wrote: > Responding to some comments from Dick, John, Jim and Edmund together: >=20 >>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is >>> unprotected (c.f. "alg":"none"), signed, or encrypted. >=20 >> yuck -- I don't see the advantage of this over it being in the header = - >> - I have to parse the header anyway. >=20 > With JWE/JWS there is no explicit indication of the mode = (unprotected/signed/encrypted/...?) in the header. Sure there is.=20 Per 5.1, the 'typ' property is RECOMMENDED to be JWT if unprotected and = REQUIRED to be JWS if signed and JWE if encrypted. =20 I agree "alg"=3D"none" is funky and would suggest that "typ"=3D"JWT" be = REQUIRED in the header. > e) Developers can see at a glance if a message is signed, encrypted, = or unprotected. This may be a useful feature, but I don't think it justifies the extra = parsing. The header needs to be fully parsed to really know what is = going on. >=20 >>> 6. The initialization vector (IV) and authentication tag associated >>> with an AEAD algorithm are prepended, and appended to the ciphertext >>> respectively (instead of using a header element and another dot- >>> separated component). I think this form is a slightly nicer. It >>> encourages the IV and authentication tag lengths to be fixed for an >>> algorithm (a slightly lazy recipient will not accept whatever length >>> the last dot-separated mac field has). One side-effect is that the >>> header will often remain the same for messages between two parties = (no >>> varying-per-message elements), which might aid performance in some >>> situations. >=20 >> yuck -- I prefer having each item being dot separated. Simple to get >> all items parsed with one line of code. I don't like different = parsing >> rules. We currently have dot parsing, base64URL parsing and JSON >> parsing. >=20 > And UTF-8 parsing. > Splitting a byte array at a specific length is not onerous. It = probably needs to be done for specific algorithms anyway (eg using a = prefix of a byte array as an authentication tag; splitting a secret key = block into bytes for an AES key and HMAC key). I'm writing in JavaScript. The UTF-8 parsing is a non-issue for me. :)=20= Splitting a byte array can be done, but is not as straightforward. :( >=20 > My trigger for appending the auth tag to the ciphertext was how the = Java 7 API added support for AEAD algorithms. The javax.crypot.Cipher = class = = added an updateAAD() method to provide the additional data, but didn't = add a getAuthTag() method. Instead, the authentication tag is appended = to the ciphertext. A nice feature is that apps doing encryption, but not = using additional data, can switch from a "normal" encryption algorithm = to an AEAD algorithm without changing the methods they call. People still use Java? ;) You can easily concatenate the data together for your implementation. I = looked at a few JS crypto libraries and they had different parameter = passing mechanisms. >>> 8. Defines one media type "application/jwsec", not separate ones for = signed and encrypted messages. >=20 >> I'm indifferent -- but if one type, then "application/jwt" >=20 > But "JWT" means a message whose contents in a JSON object holding = claims. I meant if we were going to have just one MIME type.=20 -- Dick= --Apple-Mail=_3F09461D-B5F8-4A05-8140-3074C7B6334C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Responding to some comments from Dick, John, Jim and = Edmund together:

2. A prefix ("U.", "S.", or "E.") indicates if a message = is
unprotected (c.f. "alg":"none"), signed, or = encrypted.

yuck= -- I don't see the advantage of this over it being in the header = -
- I have to parse the header = anyway.

With JWE/JWS there is no explicit indication = of the mode (unprotected/signed/encrypted/...?) in the header. =

Sure there = is. 
Per 5.1, the 'typ' property is RECOMMENDED to be JWT = if unprotected and REQUIRED to be JWS if signed and JWE if encrypted. =  

I agree "alg"=3D"none" is funky and = would suggest that "typ"=3D"JWT" be REQUIRED in the = header.

e) Developers can see at = a glance if a message is signed, encrypted, or = unprotected.

This may be a = useful feature, but I don't think it justifies the extra parsing. The = header needs to be fully parsed to really know what is going = on.


6. The initialization vector = (IV) and authentication tag = associated
with an AEAD algorithm are = prepended, and appended to the = ciphertext
respectively (instead of using a = header element and another dot-
separated component). I think = this form is a slightly nicer. = It
encourages the IV and authentication tag lengths to be = fixed for an
algorithm (a slightly lazy = recipient will not accept whatever = length
the last dot-separated mac field has). One side-effect is = that the
header will often remain the = same for messages between two parties = (no
varying-per-message elements), which might aid performance = in some
situations.

yuck -- I prefer having each item being dot separated. = Simple to get
all items parsed = with one line of code. I don't like different = parsing
rules. We currently = have dot parsing, base64URL parsing and JSON
parsing.

And UTF-8 = parsing.
Splitting a byte array at a specific length is not onerous. = It probably needs to be done for specific algorithms anyway (eg using a = prefix of a byte array as an authentication tag; splitting a secret key = block into bytes for an AES key and HMAC = key).

I'm writing in = JavaScript. The UTF-8 parsing is a non-issue for me. = :) 
Splitting a byte array can be done, but is not as = straightforward. :(


My = trigger for appending the auth tag to the ciphertext was how the Java 7 = API added support for AEAD algorithms. The javax.crypot.Cipher class = <http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html>= added an updateAAD() method to provide the additional data, but didn't = add a getAuthTag() method. Instead, the authentication tag is appended = to the ciphertext. A nice feature is that apps doing encryption, but not = using additional data, can switch from a "normal" encryption algorithm = to an AEAD algorithm without changing the methods they = call.

People still use Java? = ;)

You can easily concatenate the data together = for your implementation. I looked at a few JS crypto libraries and they = had different parameter passing = mechanisms.

8. Defines one media type = "application/jwsec", not separate ones for signed and encrypted = messages.

I'm = indifferent -- but if one type, then = "application/jwt"

But "JWT" means a message whose = contents in a JSON object holding = claims.

I meant if we were going to = have just one MIME type. 

-- = Dick
= --Apple-Mail=_3F09461D-B5F8-4A05-8140-3074C7B6334C-- From James.H.Manger@team.telstra.com Mon Jun 11 18:58: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 C9F5021F855B for ; Mon, 11 Jun 2012 18:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY92YeqRFE0I for ; Mon, 11 Jun 2012 18:58:21 -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 4208521F8559 for ; Mon, 11 Jun 2012 18:58:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,392,1336312800"; d="scan'208";a="76532203" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 12 Jun 2012 11:58:17 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6739"; a="63351079" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdni.tcif.telstra.com.au with ESMTP; 12 Jun 2012 11:58:18 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 12 Jun 2012 11:58:17 +1000 From: "Manger, James H" To: Dick Hardt Date: Tue, 12 Jun 2012 11:58:16 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1IPElRdr/Nc0CtR3K/zJfnq5GleAAAGMvw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F5475450@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> In-Reply-To: <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.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 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 01:58:22 -0000 Pj4gV2l0aCBKV0UvSldTIHRoZXJlIGlzIG5vIGV4cGxpY2l0IGluZGljYXRpb24gb2YgdGhlIG1v ZGUgKHVucHJvdGVjdGVkL3NpZ25lZC9lbmNyeXB0ZWQvLi4uPykgaW4gdGhlIGhlYWRlci4gDQoN Cj4gU3VyZSB0aGVyZSBpcy4gDQo+IFBlciA1LjEsIHRoZSAndHlwJyBwcm9wZXJ0eSBpcyBSRUNP TU1FTkRFRCB0byBiZSBKV1QgaWYgdW5wcm90ZWN0ZWQgYW5kIFJFUVVJUkVEIHRvIGJlIEpXUyBp ZiBzaWduZWQgYW5kIEpXRSBpZiBlbmNyeXB0ZWQuICANCg0KDQpJIGRvbid0IHRoaW5rICJ0eXAi IGFzIHBlciBKV1QgNS4xIGhlbHBzIG11Y2ggW2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDAjc2VjdGlvbi01LjFdLg0KDQpJdCBzYXlz ICJpbiB0aGUgbm9ybWFsIGNhc2UgLi4uIHVzZSBvZiB0aGlzIGhlYWRlciBwYXJhbWV0ZXIgaXMg T1BUSU9OQUwiLiBJdCB0ZWxscyB5b3UgaWYgdGhlIGlubmVyIGNvbnRlbnQgaXMgYW5vdGhlciBK V0Ugb3IgSldTIG1lc3NhZ2UuIEl0IGRvZXNuJ3QgdGVsbCB5b3Ugd2hhdCB0aGUgb3V0ZXIgbWVz c2FnZSAgaXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From dick.hardt@gmail.com Mon Jun 11 19:33: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 EAA1211E8097 for ; Mon, 11 Jun 2012 19:33:31 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJgbagZrhcVc for ; Mon, 11 Jun 2012 19:33:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3444E11E8091 for ; Mon, 11 Jun 2012 19:33:31 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so116247pbc.31 for ; Mon, 11 Jun 2012 19:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XjmbHhMrTlcs4VCyWsOglo2FpzP2zLkoQb9+C4qhs9g=; b=sfnkSMn+zmEHl75k5eYfqpqjR3wUicn1BQy7EGs3lCNvjSyE6J72yXVEatp9J1PiaJ 4rc8uQ3nWqbJubci00gP5XLBdJx9N3PqFT8eyx+akYBo2jgaQmOOf8+1gwb6349BSD7m BpMQe0l1HwgdK/Cwg6oJ6f5S+sMJi4mkPOaUTRTJnEIcbljz27g+4ihphdgy7hc7OdlE BtgsqRppclsGmsuuen1T2iAYkB6bSvNLXh1qb0gmvwKENEK/GjFE5jNgaSx4cFETaRp1 NH+PK8R9YB0ufQUT2Dny9qOpJ+EtUjtAeZK6WHmGY/fu/jyOzIGYaEm8qAsoPB4rwq8/ k1SA== Received: by 10.68.228.200 with SMTP id sk8mr32384489pbc.94.1339468411026; Mon, 11 Jun 2012 19:33:31 -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 kt1sm303865pbc.32.2012.06.11.19.33.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 19:33:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5475450@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Jun 2012 19:33:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> <255B9BB34FB7D647A506DC292726F6E114F5475450@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 02:33:32 -0000 On Jun 11, 2012, at 6:58 PM, Manger, James H wrote: >>> With JWE/JWS there is no explicit indication of the mode = (unprotected/signed/encrypted/...?) in the header.=20 >=20 >> Sure there is.=20 >> Per 5.1, the 'typ' property is RECOMMENDED to be JWT if unprotected = and REQUIRED to be JWS if signed and JWE if encrypted. =20 >=20 >=20 > I don't think "typ" as per JWT 5.1 helps much = [http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-00#section-5.1= ]. >=20 > It says "in the normal case ... use of this header parameter is = OPTIONAL". It tells you if the inner content is another JWE or JWS = message. It doesn't tell you what the outer message is. Ha ha! Now that I read it carefully, I see that you are correct and understand = why you would want to signal the type of token. I think it should = actually work as I described (typ is set to the type of token) and have = another parameter that indicates if a JWT is embedded (emb ?). That = JWT's header will then indicate if it is a JWS or JWT. Meta data about the payload should go in the header, not a meta header. -- Dick= From James.H.Manger@team.telstra.com Mon Jun 11 20:05: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 5155A21F8567 for ; Mon, 11 Jun 2012 20:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHyDcyz08YYo for ; Mon, 11 Jun 2012 20:05:39 -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 778F421F8566 for ; Mon, 11 Jun 2012 20:05:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,393,1336312800"; d="scan'208";a="76355842" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Jun 2012 13:05:38 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6739"; a="16863669" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcani.tcif.telstra.com.au with ESMTP; 12 Jun 2012 13:05:38 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 12 Jun 2012 13:05:37 +1000 From: "Manger, James H" To: Dick Hardt Date: Tue, 12 Jun 2012 13:05:36 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1IQ8LB0p+U4voiToiJOwobPJ5nFgAAH3Cw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F54755E0@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> <255B9BB34FB7D647A506DC292726F6E114F5475450@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 03:05:40 -0000 PiBIYSBoYSENCj4gDQo+IE5vdyB0aGF0IEkgcmVhZCBpdCBjYXJlZnVsbHksIEkgc2VlIHRoYXQg eW91IGFyZSBjb3JyZWN0IGFuZCB1bmRlcnN0YW5kDQo+IHdoeSB5b3Ugd291bGQgd2FudCB0byBz aWduYWwgdGhlIHR5cGUgb2YgdG9rZW4uIEkgdGhpbmsgaXQgc2hvdWxkDQo+IGFjdHVhbGx5IHdv cmsgYXMgSSBkZXNjcmliZWQgKHR5cCBpcyBzZXQgdG8gdGhlIHR5cGUgb2YgdG9rZW4pIGFuZCBo YXZlDQo+IGFub3RoZXIgcGFyYW1ldGVyIHRoYXQgaW5kaWNhdGVzIGlmIGEgSldUIGlzIGVtYmVk ZGVkIChlbWIgPykuIFRoYXQNCj4gSldUJ3MgaGVhZGVyIHdpbGwgdGhlbiBpbmRpY2F0ZSBpZiBp dCBpcyBhIEpXUyBvciBKV1QuDQo+IA0KPiBNZXRhIGRhdGEgYWJvdXQgdGhlIHBheWxvYWQgc2hv dWxkIGdvIGluIHRoZSBoZWFkZXIsIG5vdCBhIG1ldGEgaGVhZGVyLg0KDQpTbyBEaWNrLCB3b3Vs ZCB5b3UgcHJlZmVyIGEgc2lnbmVkLXRoZW4tZW5jcnlwdGVkIGNvbGxlY3Rpb24gb2YgY2xhaW1z IHRvIGxvb2sgc29tZXRoaW5nIGxpa2UgdGhpcyAoaWdub3JpbmcgdGhlIGJhc2U2NHVybCBlbmNv ZGluZyk6DQoNCnsgInR5cCI6IkpXRSIsICJlbWIiOnRydWUsIC4uYWxnIGlkLCBrZXkgaWQsIGFs ZyBwYXJhbXN9ICsgZW5ja2V5ICsgY2lwaGVydGV4dA0KDQpPbiBkZWNyeXB0aW5nLCB0aGUgcGxh aW50ZXh0IGxvb2tzIGxpa2U6DQoNCiAgeyAidHlwIjoiSldTIiwgImVtYiI6ZmFsc2UsIC4uYWxn IGlkLCBrZXkgaWQsIGFsZyBwYXJhbXN9ICsgY29udGVudCArIHNpZw0KDQpUaGUgY29udGVudCBp dHNlbGYgaXMgYSBKU09OIG9iamVjdDoNCg0KICAgIHsgImlzcyIuLi4sICJleHAiOi4uLiwgInR5 cCI6IkpXVCIgLi4uIH0NCj8NCg0KVGhpcyBwcm92aWRlcyB0aGUgc2FtZSBpbmZvIGFzIEkgd2Fz IGFmdGVyIHdpdGggbXkgIltVdVNzRWVdLiIgcHJlZml4Lg0KVXNpbmcgaGVhZGVyIGVsZW1lbnRz IGlzIHBlcmhhcHMgc2xpZ2h0bHkgbW9yZSBjb25zaXN0ZW50LCBidXQgaXQgZG9lcyBhZGQgYWJv dXQgMzAgYnl0ZXMsIHJlbW92ZXMgdGhlIHZpc3VhbCBjbHVlIGZvciBkZXZlbG9wZXJzLCBhbmQg bWFrZXMgaGlnaC1sZXZlbCBpbnB1dCB2YWxpZGF0aW9uICh3aXRoIHNheSBhIHJlZ2V4IGluIGEg V2ViIEFwcCBGaXJld2FsbCkgaGFyZGVyLg0KDQpJZiB3ZSBkbyBnbyB3aXRoIGhlYWRlciBlbGVt ZW50cyAobm90IG15IHByZWZlcmVuY2UpIHdlIHNob3VsZCBkaXRjaCAidHlwIi4gSXRzIHNlbWFu dGljcyBoYXZlIGFscmVhZHkgYmVlbiBjb25mdXNlZCB0b28gbXVjaC4gUGVyaGFwcyAidCI/DQoN Ci0tDQpKYW1lcyBNYW5nZXINCg0K From dick.hardt@gmail.com Mon Jun 11 20:35: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 EA1AF21F8534 for ; Mon, 11 Jun 2012 20:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js+asGKprc0Z for ; Mon, 11 Jun 2012 20:35:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6597921F8532 for ; Mon, 11 Jun 2012 20:35:37 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so171144pbc.31 for ; Mon, 11 Jun 2012 20:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ogGEtyc/bVb8rjp9DfC+QFzRpUz1Mq6PWk1OLVJAptc=; b=dhjrRbzdgdm+XZZA7Y8FIG/TvlUZ99qQyaPFOOLWwZYRUeXaZj1alTQw4dY9goodT0 b/nL1cxiiSH1wQIQW+h1Xn0AurAnuvvOWgzwMPaeGVdKCaybjt75m4zEJ5KAhf+EFjsE K1d32hGTqdSegJ7j5oCcjNzJ8hR/oDz0P450ARpi3QtDz2M8D6wcJJHKh06NiOOJBt+O bGziiriHs57L3PY6sVPlXZFrcJz7Z9gYbCcsNfN6iT3D+iSaAniAI3Hvx5gyC961YvlY TnZZ1L1mKyiON4pshM/udLaEuZDFbBKto/j+OhqZmcfSqIjs7bc9zpd5jL3BfbLzhQa8 6B5A== Received: by 10.68.195.106 with SMTP id id10mr24671365pbc.116.1339472137165; Mon, 11 Jun 2012 20:35:37 -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 tk1sm479590pbc.8.2012.06.11.20.35.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 20:35:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F54755E0@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Jun 2012 20:35:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <430BEB20-DD63-4F86-96F2-8B2E6C9C41BA@gmail.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> <255B9BB34FB7D647A506DC292726F6E114F5475450@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F54755E0@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 03:35:38 -0000 On Jun 11, 2012, at 8:05 PM, Manger, James H wrote: >> Ha ha! >>=20 >> Now that I read it carefully, I see that you are correct and = understand >> why you would want to signal the type of token. I think it should >> actually work as I described (typ is set to the type of token) and = have >> another parameter that indicates if a JWT is embedded (emb ?). That >> JWT's header will then indicate if it is a JWS or JWT. >>=20 >> Meta data about the payload should go in the header, not a meta = header. >=20 > So Dick, would you prefer a signed-then-encrypted collection of claims = to look something like this (ignoring the base64url encoding): >=20 > { "typ":"JWE", "emb":true, ..alg id, key id, alg params} + enckey + = ciphertext >=20 > On decrypting, the plaintext looks like: >=20 > { "typ":"JWS", "emb":false, ..alg id, key id, alg params} + content + = sig "emb":false could be dropped, default would be false >=20 > The content itself is a JSON object: >=20 > { "iss"..., "exp":..., "typ":"JWT" =85 } not sure why "typ":"JWT" is in the object itself. I have been using it = to indicate what the token is used for=20 >=20 > This provides the same info as I was after with my "[UuSsEe]." prefix. > Using header elements is perhaps slightly more consistent, but it does = add about 30 bytes, agree it is longer - I would rather it was longer and parsed correctly = than shorter and incorrect. :) If small size was the highest priority, we would be encoding bytes and = bits. :) > removes the visual clue for developers, wearing my developer hat, I probably care more about the other headers = when looking at a token and envision a editor tool that would decode it = for me. :) > and makes high-level input validation (with say a regex in a Web App = Firewall) harder. can you provide a use case / story where the hint that the token is = U|S|E would be useful in and of itself? >=20 > If we do go with header elements (not my preference) we should ditch = "typ". Its semantics have already been confused too much. Perhaps "t"? I think the 3 letter convention for reserved words is useful as a visual = clue of what is reserved. I don't care what it is called as long as it = is obvious what it does. :) btw: thanks for the dialog! -- Dick= From James.H.Manger@team.telstra.com Mon Jun 11 21:05:34 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 BFCAE11E80AB for ; Mon, 11 Jun 2012 21:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P0beZzcK7AW for ; Mon, 11 Jun 2012 21:05:34 -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 BE0E011E809C for ; Mon, 11 Jun 2012 21:05:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,393,1336312800"; d="scan'208";a="77727148" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 Jun 2012 14:05:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6739"; a="68342805" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 12 Jun 2012 14:05:32 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 12 Jun 2012 14:05:32 +1000 From: "Manger, James H" To: Dick Hardt Date: Tue, 12 Jun 2012 14:05:31 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec: IV ciphertext tag Thread-Index: Ac1IPElRdr/Nc0CtR3K/zJfnq5GleAAAo5YA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F5475748@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> In-Reply-To: <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.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 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec: IV ciphertext tag 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, 12 Jun 2012 04:05:34 -0000 Pj4gNi4gVGhlIGluaXRpYWxpemF0aW9uIHZlY3RvciAoSVYpIGFuZCBhdXRoZW50aWNhdGlvbiB0 YWcgYXNzb2NpYXRlZA0KPj4gd2l0aCBhbiBBRUFEIGFsZ29yaXRobSBhcmUgcHJlcGVuZGVkLCBh bmQgYXBwZW5kZWQgdG8gdGhlIGNpcGhlcnRleHQNCg0KPiBJJ20gd3JpdGluZyBpbiBKYXZhU2Ny aXB0LiBUaGUgVVRGLTggcGFyc2luZyBpcyBhIG5vbi1pc3N1ZSBmb3IgbWUuIDopwqANCj4gU3Bs aXR0aW5nIGEgYnl0ZSBhcnJheSBjYW4gYmUgZG9uZSwgYnV0IGlzIG5vdCBhcyBzdHJhaWdodGZv cndhcmQuIDooDQoNCj4gWW91IGNhbiBlYXNpbHkgY29uY2F0ZW5hdGUgdGhlIGRhdGEgdG9nZXRo ZXIgZm9yIHlvdXIgaW1wbGVtZW50YXRpb24uIEkgbG9va2VkIGF0IGEgZmV3IEpTID4gY3J5cHRv IGxpYnJhcmllcyBhbmQgdGhleSBoYWQgZGlmZmVyZW50IHBhcmFtZXRlciBwYXNzaW5nIG1lY2hh bmlzbXMuDQoNCkNvdWxkIHlvdSBzaGFyZSBhIGZldyBsaW5rcyB0byBKYXZhU2NyaXB0IENyeXB0 byBBUElzLg0KDQpBIHF1aWNrIHNlYXJjaCBmb3VuZCBzamNsIDxodHRwOi8vY3J5cHRvLnN0YW5m b3JkLmVkdS9zamNsLz4uDQpUaGlzIEFQSSBzZWVtcyB0byBhcHBlbmQgdGhlIGF1dGggdGFnIHRv IHRoZSBjaXBoZXJ0ZXh0LCBidXQgaGF2ZSBhIHNlcGFyYXRlIHBhcmFtZXRlciBmb3IgdGhlIElW LiBJdCBhbHNvIG1ha2VzIGl0IGVhc3kgdG8gc3BsaXQgb3Igam9pbiBhIGJ5dGUgYXJyYXkgLS0g YnV0IHBlcmhhcHMgaXQgaGFkIHRvIGRlZmluZSBpdHMgb3duIGJpdEFycmF5IG9iamVjdCB0byBk byB0aGlzLg0KDQoNCldoYXQgSSBsaWtlZCBtb3N0IGFib3V0IGNvbmNhdGVuYXRpbmcgSVYsIGNp cGhlcnRleHQsIGFuZCB0YWcgaXMgdGhhdCB0aGUgcmVjaXBpZW50IG5lZWRzIHRvIGtub3cgdGhl IGxlbmd0aHMgb2YgdGhlIElWIGFuZCB0YWcgZnJvbSB0aGUgYWxnIGlkLiBDb25zaWRlciBHYWxv aXMvQ291bnRlciBNb2RlIChHQ00pIGZvciBpbnN0YW5jZS4gVGhlIE5JU1QgR0NNIHNwZWMgYWxs b3dzIHRhZyBsZW5ndGhzIGZyb20gMTI4LWJpdHMgZG93biB0byAzMi1iaXRzLiBBIGdlbmVyaWMg Y3J5cHRvIGxpYnJhcnkgaW1wbGVtZW50aW5nIEdDTSB3aWxsIHByb2JhYmx5IHN1cHBvcnQgYWxs IHRoZXNlIGxlbmd0aHMuIEl0IHdvdWxkIGJlIHZlcnkgZWFzeSBmb3IgYSBKV0UgbGlicmFyeSB0 byBzaW1wbHkgcGFzcyB0aGUgbGFzdCBkb3Qtc2VwYXJhdGVkIGZpZWxkIGFzIHRoZSAndGFnJyBw YXJhbWV0ZXIgb2YgYSBHQ00gZGVjcnlwdCgpIGZ1bmN0aW9uIC0tIHdpdGhvdXQgZXhwbGljaXRs eSBjaGVja2luZyB0aGF0IGl0IGlzIDEyOC1iaXRzIGxvbmcgYXMgSldBIHJlcXVpcmVzLiBDb25j YXRlbmF0aW5nIHRoZSB0YWcgdG8gdGhlIGNpcGhlcnRleHQgYXZvaWRzIHRoYXQgcmlzay4NCg0K Q29uY2F0ZW5hdGluZyB0aGUgSVYgdG8gdGhlIGNpcGhlcnRleHQgbWlnaHQgYWxzbyByZW1vdmUg YW4gZWFzeSBpbXBsZW1lbnRhdGlvbiBtaXN0YWtlIG9mIG5vdCBjaGVja2luZyB0aGUgSVYgbGVu Z3RoLiBJIGFtIGxlc3MgY2VydGFpbiBvZiB0aGUgY3J5cHRvIGltcGxpY2F0aW9ucywgdGhvdWdo IElWIHVuaXF1ZW5lc3Mgc2VlbXMgY3J1Y2lhbCB0byBHQ00gc2VjdXJpdHkuIEFuIElWIGlzIGdl bmVyYWxseSB0cmVhdGVkIGFzIGFuIGlucHV0IHBhcmFtZXRlciB0byB0aGUgZW5jcnlwdGlvbi4g TXkgZ3V0IGZlZWxpbmcgKG5vdCBncmVhdCB0byByZWx5IG9uIGZvciBzZWN1cml0eSA7LSkgaXMg dGhhdCBpdCB3b3VsZCBnZW5lcmFsbHkgYmUgYmV0dGVyIGZvciB0aGUgInRvcC1sZXZlbCIgb2Yg YW4gYXBwIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBhbiBhbGcgaWQgYW5kIGtleSwgd2hpbGUgbGVh dmluZyBpdCB0byB0aGUgY3J5cHRvIGxheWVyIHRvIHBpY2sgYSByYW5kb20gSVYgb2YgdGhlIHJp Z2h0IGxlbmd0aC4gVGhhdCBkb2Vzbid0IG1lYW4gdGhlIElWIGNhbm5vdCBiZSBwdXQgaW4gdGhl IGhlYWRlciwgYnV0IGl0IG1pZ2h0IGJlIGVhc2llciB0byByZXR1cm4gYXMgcGFydCBvZiB0aGUg Y2lwaGVydGV4dC4NCg0KRGljayAoYW5kIG90aGVyIGltcGxlbWVudGVycyksDQpJdCBzb3VuZHMg bGlrZSB5b3UgaGF2ZSB3cml0dGVuIGEgSmF2YVNjcmlwdCBKT1NFIGxpYnJhcnkuIERvZXMgaXQg aW1wbGVtZW50IEFFUyBHQ00/IERvZXMgaXQgY2hlY2sgdGhlIElWIGFuZCBhdXRoZW50aWNhdGlv biB0YWcgbGVuZ3Rocz8gKGFuZCBubyBjaGVhdGluZyBieSBhZGRpbmcgdGhlIGNoZWNrcyBiZWZv cmUgYW5zd2VyaW5nIDstKQ0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Mon Jun 11 21:51:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8175F21F856C for ; Mon, 11 Jun 2012 21:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxWrVS3bBxjE for ; Mon, 11 Jun 2012 21:51:02 -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 5E51621F8568 for ; Mon, 11 Jun 2012 21:51:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,393,1336312800"; d="scan'208";a="82501744" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 12 Jun 2012 14:50:59 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6739"; a="63377889" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdni.tcif.telstra.com.au with ESMTP; 12 Jun 2012 14:50:59 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 12 Jun 2012 14:50:59 +1000 From: "Manger, James H" To: Dick Hardt Date: Tue, 12 Jun 2012 14:50:58 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1ITG9b5LAxiTr1QICrfXebYOEFWQABFGMQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F54758A2@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> <255B9BB34FB7D647A506DC292726F6E114F5475450@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F54755E0@WSMSG3153V.srv.dir.telstra.com> <430BEB20-DD63-4F86-96F2-8B2E6C9C41BA@gmail.com> In-Reply-To: <430BEB20-DD63-4F86-96F2-8B2E6C9C41BA@gmail.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 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 04:51:02 -0000 Pj4gYW5kIG1ha2VzIGhpZ2gtbGV2ZWwgaW5wdXQgdmFsaWRhdGlvbiAod2l0aCBzYXkgYSByZWdl eCBpbiBhIFdlYiBBcHANCj4+IEZpcmV3YWxsKSBoYXJkZXIuDQogDQo+IGNhbiB5b3UgcHJvdmlk ZSBhIHVzZSBjYXNlIC8gc3Rvcnkgd2hlcmUgdGhlIGhpbnQgdGhhdCB0aGUgdG9rZW4gaXMNCj4g VXxTfEUgd291bGQgYmUgdXNlZnVsIGluIGFuZCBvZiBpdHNlbGY/DQoNCkl0IGlzIHByaW1hcmls eSBhIGRlc2lnbiBjaG9pY2UuIFdlIGhhdmUgYSBoYW5kZnVsIG9mIHRvcC1sZXZlbCAidHlwZXMi IG9mIG1lc3NhZ2UgKHNpZ25lZCwgZW5jcnlwdGVkLCB1bnByb3RlY3RlZCkuIFRoZSBudW1iZXIg b2YgZG90LXNlcGFyYXRlZCBjb21wb25lbnRzIGNhbiB2YXJ5IGJldHdlZW4gInR5cGUiLiBUaGUg c2VtYW50aWNzIG9mIHRoZSBudGggY29tcG9uZW50IHZhcmllcyBiZXR3ZWVuICJ0eXBlIi4gRnV0 dXJlIHR5cGVzIG1heSBoYXZlIG90aGVyIG51bWJlcnMgb2YgY29tcG9uZW50cyBhbmQgY29tcG9u ZW50IHNlbWFudGljcy4gSSB0aGluayB0aGUgcmlnaHQgZGVzaWduIGlzIHRvIGluZGljYXRlIHRo ZSAidHlwZSIgYXQgdGhlIHNhbWUgdG9wLWxldmVsIHdoZXJlIHlvdSBzZWUgdGhlIG51bWJlciBh bmQgc2l6ZSBvZiB0aGUgcGVyLXR5cGUgY29tcG9uZW50cy4NCg0KQ29tcGFyZSB0byBDTVMgKENy eXB0byBNZXNzYWdlIFN5bnRheCwgUkZDNTY1Mik6IHRoZSB0b3AgbGV2ZWwgaGFzIGEgY29udGVu dFR5cGUgZmllbGQgdG8gZGlzdGluZ3Vpc2ggRGF0YSwgU2lnbmVkRGF0YSwgRW52ZWxvcGVkRGF0 YSwgRW5jcnlwdGVkRGF0YS4uLiBUaGUgYWN0dWFsIGFsZyBpZHMsIGtleSBpZHMsIGFuZCBtZXRh ZGF0YSBpcyBoZWxkIHNlcGFyYXRlbHkgImxvd2VyIGRvd24iIGluIHRoZSBzdHJ1Y3R1cmVzLg0K DQpJZiBzb21lIHBvaW50IGJldHdlZW4gYW4gb3JpZ2luYXRvciBhbmQgcmVjaXBpZW50IChldmVu IGlmIGp1c3QgZWFybGllciBpbiB0aGUgcmVjaXBpZW50J3Mgc3RhY2spIGhhcyBhIHBvbGljeSBv ZiAiZGF0YSBtdXN0IGJlIGVuY3J5cHRlZCBmb3IgY29uZmlkZW50aWFsaXR5IiBvciAiZGF0YSBt dXN0IE5PVCBiZSBlbmNyeXB0ZWQgc28gaXQgY2FuIGJlIGluc3BlY3RlZCIgb3IgImRhdGEgbXVz dCBiZSBkaWdpdGFsbHktc2lnbmVkIiBvciAib25seSBzaWduZWQtdGhlbi1lbmNyeXB0ZWQgZGF0 YSBpcyBleHBlY3RlZCIgb3IgImNvbmZpZGVudGlhbCBkYXRhIGlzIHByb2Nlc3NlZCBvdmVyIHRo ZXJlIiB0aGVuIHlvdSBoYXZlIGEgY2hhbmNlIG9mIGVuZm9yY2luZyB0aGUgcG9saWN5IGJ5IGxv b2tpbmcgYXQgdGhlIGluaXRpYWwgbGV0dGVyIC0tIHdpdGggYmFyZWx5IGFueSBKT1NFLXNwZWNp ZmljIGtub3dsZWRnZS4gWW91IGNhbiBwcm9iYWJseSBpbXBsZW1lbnQgdGhlc2UgcG9saWNpZXMg d2l0aCBhbiBBcGFjaGUgbW9kX2FsaWFzIHJ1bGUuIEJ1dCB0aGlzIGlzIGEgYml0IHNwZWN1bGF0 aXZlLg0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From dick.hardt@gmail.com Mon Jun 11 21:53: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 88A8321F8589 for ; Mon, 11 Jun 2012 21:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlpmcvIpNcLF for ; Mon, 11 Jun 2012 21:53:30 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A91B221F857F for ; Mon, 11 Jun 2012 21:53:29 -0700 (PDT) Received: by dacx6 with SMTP id x6so6304470dac.31 for ; Mon, 11 Jun 2012 21:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=k8pxzbhlJKrj4GSk/PQnq1lcKl8RE2A2QdwFKKNPjbM=; b=IsAXB87VC8zPUi/7amzvB5A3w2dKZ8hWPzU2qSXhPT9O23SpgLMd44EAFX8W+7g7FY arCfEEcYMJ8eg0i74cyuPOo1p6XnU4Kz3nsBEccT7d9r++VspssyBePsaD1LSuvdPInn x0JO923yVGyutDIOMI//wk4aMs5/nU9b3ZDbH44I1LR5qCJIiP5rZdv/+ZiXwp29gjXT chxBdLbuYp/7v0+u+4vBJi2R/I85eRIr9Ahk86EnnLH1n80JEdVhNF8IXZQCWs9uNjjM PvwUudq2N0gsYOeFzJBOyHqaIVmfeVu91V11osioYSauWHDNf+b3CtkActju31ZQSAk0 +7Vw== Received: by 10.68.201.2 with SMTP id jw2mr35133512pbc.106.1339476809434; Mon, 11 Jun 2012 21:53:29 -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 jv6sm677779pbc.40.2012.06.11.21.53.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 21:53:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D11CF3FF-7FC6-4E49-B06F-A05CE4F4FBF2" From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5475748@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Jun 2012 21:53:26 -0700 Message-Id: <6DD609C2-8F55-416B-A4E9-D7A89F5BC01A@gmail.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> <255B9BB34FB7D647A506DC292726F6E114F5475748@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec: IV ciphertext tag 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, 12 Jun 2012 04:53:32 -0000 --Apple-Mail=_D11CF3FF-7FC6-4E49-B06F-A05CE4F4FBF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 11, 2012, at 9:05 PM, Manger, James H wrote: >>> 6. The initialization vector (IV) and authentication tag associated >>> with an AEAD algorithm are prepended, and appended to the ciphertext >=20 >> I'm writing in JavaScript. The UTF-8 parsing is a non-issue for me. = :)=20 >> Splitting a byte array can be done, but is not as straightforward. :( >=20 >> You can easily concatenate the data together for your implementation. = I looked at a few JS > crypto libraries and they had different parameter = passing mechanisms. >=20 > Could you share a few links to JavaScript Crypto APIs. These are battle tested libraries: http://code.google.com/p/crypto-js/ http://nodejs.org/api/crypto.html >=20 > Dick (and other implementers), > It sounds like you have written a JavaScript JOSE library. Does it = implement AES GCM? Does it check the IV and authentication tag lengths? = (and no cheating by adding the checks before answering ;-) I have not yet had to implement JWE, only JWS so far. I am currently = specifying JWE for a major project (and hope the spec settles!) FYI: I recall seeing a few implementations in JS on GitHub. I know the = Mozilla guys built a JS library for node.js for their BrowserID project. -- Dick --Apple-Mail=_D11CF3FF-7FC6-4E49-B06F-A05CE4F4FBF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
6. = The initialization vector (IV) and authentication tag = associated
with an AEAD algorithm are = prepended, and appended to the = ciphertext

I'm = writing in JavaScript. The UTF-8 parsing is a non-issue for me. = :) 
Splitting a byte = array can be done, but is not as straightforward. = :(

You can easily = concatenate the data together for your implementation. I looked at a few = JS > crypto libraries and they had different parameter passing = mechanisms.

Could you share a few links to = JavaScript Crypto APIs.

These = are battle tested libraries:

http://code.google.com/p/cryp= to-js/


Dick = (and other implementers),
It sounds like you have written a = JavaScript JOSE library. Does it implement AES GCM? Does it check the IV = and authentication tag lengths? (and no cheating by adding the checks = before answering ;-)

I have not yet = had to implement JWE, only JWS so far. I am currently specifying = JWE for a major project (and hope the spec = settles!)

FYI: I recall seeing a few = implementations in JS on GitHub. I know the Mozilla guys built a JS = library for node.js for their BrowserID = project.

-- = Dick

= --Apple-Mail=_D11CF3FF-7FC6-4E49-B06F-A05CE4F4FBF2-- From rbarnes@bbn.com Tue Jun 12 05:35: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 5FAAB21F851B for ; Tue, 12 Jun 2012 05:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNiHq8cl30rg for ; Tue, 12 Jun 2012 05:35:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1E21F8510 for ; Tue, 12 Jun 2012 05:35:05 -0700 (PDT) Received: from [128.89.255.156] (port=60587) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SeQIm-000AiA-E5; Tue, 12 Jun 2012 08:34:28 -0400 From: "Richard L. Barnes" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_DE3B5F2B-F604-417B-92B0-AAD11B1AD5DA" Date: Tue, 12 Jun 2012 08:35:03 -0400 References: To: jose@ietf.org Message-Id: <1B8956F6-81C5-4921-BA03-4097BE58F471@bbn.com> X-Mailer: Apple Mail (2.1278) Cc: David McGrew Subject: [jose] Fwd: [Cfrg] Fwd: New Version Notification for draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 12:35:07 -0000 --Apple-Mail=_DE3B5F2B-F604-417B-92B0-AAD11B1AD5DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Forwarding to JOSE, since there was interest in using this document. --Richard Begin forwarded message: > From: David McGrew > Subject: [Cfrg] Fwd: New Version Notification for = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt > Date: June 11, 2012 8:46:01 PM EDT > To: cfrg@irtf.org >=20 > Hi, >=20 > Kenny and I put together this internet draft defining AEAD algorithms = based on AES-CBC and HMAC-SHA. The main idea behind this work is that = current and future standards efforts that use CBC and HMAC can use AEAD, = and thus omit unauthenticated encryption altogether. Your feedback = will be welcome. >=20 > thanks, >=20 > David >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt >> Date: June 11, 2012 8:43:34 PM EDT >> To: mcgrew@cisco.com >> Cc: kenny.paterson@rhul.ac.uk >>=20 >>=20 >> A new version of I-D, draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt >> has been successfully submitted by David A. McGrew and posted to the >> IETF repository. >>=20 >> Filename: draft-mcgrew-aead-aes-cbc-hmac-sha2 >> Revision: 00 >> Title: Authenticated Encryption with AES-CBC and = HMAC-SHA >> Creation date: 2012-06-11 >> WG ID: Individual Submission >> Number of pages: 23 >> URL: = http://www.ietf.org/internet-drafts/draft-mcgrew-aead-aes-cbc-hmac-sha2-00= .txt >> Status: = http://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2 >> Htmlized: http://tools.ietf.org/html/submission.filename }}-00 >>=20 >>=20 >> Abstract: >> This document specifies algorithms for authenticated encryption = with >> associated data (AEAD) that are based on the composition of the >> Advanced Encryption Standard (AES) in the Cipher Block Chaining = (CBC) >> mode of operation for encryption, and the HMAC-SHA message >> authentication code (MAC). >>=20 >> These are randomized encryption algorithms, and thus are suitable = for >> use with applications that cannot provide distinct nonces to each >> invocation of the AEAD encrypt operation. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_DE3B5F2B-F604-417B-92B0-AAD11B1AD5DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: David McGrew <mcgrew@cisco.com>
=
Subject: = [Cfrg] Fwd: New Version Notification for = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
Date: June 11, 2012 = 8:46:01 PM EDT

Hi,

Kenny = and I put together this internet draft defining AEAD algorithms based on = AES-CBC and HMAC-SHA.   The main idea behind this work is that = current and future standards efforts that use CBC and HMAC can use AEAD, = and thus omit unauthenticated encryption altogether.   Your = feedback will be = welcome.

thanks,

David

Begin forwarded message:

Subject: New Version Notification for = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
Date: June 11, 2012 = 8:43:34 PM EDT
Cc: kenny.paterson@rhul.ac.uk


A new version of I-D, = draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
has been successfully = submitted by David A. McGrew and posted to the
IETF = repository.

Filename: = draft-mcgrew-aead-aes-cbc-hmac-sha2
Revision: = 00
Title: = = Authenticated Encryption with AES-CBC and HMAC-SHA
Creation = date: = 2012-06-11
WG ID: Individual Submission
Number = of pages: 23
URL: =             http://www.ietf.org/internet-drafts/draft-mcgrew-aead-aes-cb= c-hmac-sha2-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2=
Htmlized:        http://tools.ietf.= org/html/submission.filename }}-00


Abstract:
=   This document specifies algorithms for authenticated = encryption with
  associated data (AEAD) that are based on = the composition of the
  Advanced Encryption Standard = (AES) in the Cipher Block Chaining (CBC)
  mode of = operation for encryption, and the HMAC-SHA message
=   authentication code (MAC).

  These are = randomized encryption algorithms, and thus are suitable for
=   use with applications that cannot provide distinct nonces to = each
  invocation of the AEAD encrypt = operation.




The IETF = Secretariat

__________________= _____________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mai= lman/listinfo/cfrg

= --Apple-Mail=_DE3B5F2B-F604-417B-92B0-AAD11B1AD5DA-- From rbarnes@bbn.com Tue Jun 12 06:24: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 5B76921F8575 for ; Tue, 12 Jun 2012 06:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljZkZrjzCtXd for ; Tue, 12 Jun 2012 06:24:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 854A621F8516 for ; Tue, 12 Jun 2012 06:24:26 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:60989) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SeR4P-000C3g-RF; Tue, 12 Jun 2012 09:23:41 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 12 Jun 2012 09:24:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C6BFDE3-CD9E-4985-A68A-7BA6303E3D38@bbn.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Jim Schaad , "'Manger, James H'" , jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 13:24:27 -0000 >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >>> John Bradley >>> Sent: Monday, June 11, 2012 12:52 PM >>> To: Manger, James H >>> Cc: jose@ietf.org >>> Subject: Re: [jose] draft-manger-jose-jwsec >>>=20 >>> I am against adding the prefix that winds up outside the integrity >> protection. >>>=20 >>> It is an un necessary and breaking change to many existing JWS >> deployments. >>>=20 >>> Taking the IV out of the header removes the integrity check over it = and >>> complicates parsing by JSON. >>=20 >> It does not necessarily remove it from the integrity check. This = depends on >> how the AEAD algorithm is defined. The stream authenticated could be = the >> header || the iv || the message body so that it is still = authenticated. >=20 > Yes if the iv is prepended or appended to the cyphertext that would = happen however the additional parsing and potential for interop problems = is not worth it. =20 What's the attack you're worried about if the IV is not = integrity-protected? --Richard >=20 >>=20 >>>=20 >>> It is not using Authenticated encryption, AEAD only adds integrity = not >> sender >>> authentication. >>=20 >> The AEAD algorithm class is called Authenticated encryption with = additional >> data. This is the term for the art. Note that this does not imply = sender >> origination which is the additional service one wants signatures for. = There >> is a debate if you get sender origination even with static-static key >> agreement. >>=20 > OK if it is used as a term of art, rather than implying sender = verification.=20 >=20 > I expect that some people are going to object to being forced to do = integrity if they intend to do signing in some other way. I personally = don't see it as the end of the world.=20 >=20 > John B. >=20 >=20 >>>=20 >>> I agree that for simplicity the output of key agreement should be = used to >>> encrypt a CMK, that adds some more processing for key agreement, = but is >>> overall more consistent. >>>=20 >>> We didn't do a okid because the WG was against my proposal to add = static >>> static key agreement in Paris. If feelings have changed then it = should >> be in. >>>=20 >>> Sorry for the short response I am traveling. >>>=20 >>> John B. >>>=20 >>> On 2012-06-11, at 4:04 PM, Manger, James H wrote: >>>=20 >>>> I have proposed various changes to JWS/JWE/JWT recently, but not = always >>> with specific text changes to the existing documents. So I have had = a go >>> putting the changes together as a vaguely complete draft spec. The = result >> is: >>>>=20 >>>> JSON Web Security Message Format (JWsec) >>>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >>>>=20 >>>> Abstract: >>>> This document describes a cryptographic message format based on >>>> JavaScript Object Notation (JSON) and base-64 encodings to be easy >>>> for web applications to generate and process. Signed, encrypted, >>>> signed-then-encrypted, and unprotected messages are supported using >>>> symmetric and/or asymmetric keys. >>>>=20 >>>> Changes from JWS/JWE/JWA/JWT: >>>>=20 >>>> 1. The nickname JWsec is used for a message that can be signed, >>> encrypted, or unprotected. All three modes are covered by one ABNF >>> syntax. All three are included in the one spec. >>>>=20 >>>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is = unprotected >> (c.f. >>> "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is = dot- >>> separated base64url-encoded components, including a JSON object = header. >>>>=20 >>>> 3. Each mode can compress the input data. >>>>=20 >>>> 4. Only uses authenticated encryption with additional data (AEAD). >>>>=20 >>>> 5. Unrecognized header elements MUST be ignored to allow new = elements >>> to be deployed without breaking interoperability. If new elements = that >>> MUST NOT be ignored are required, then a new mode can easily be = defined. >>>>=20 >>>> 6. The initialization vector (IV) and authentication tag associated = with >> an >>> AEAD algorithm are prepended, and appended to the ciphertext = respectively >>> (instead of using a header element and another dot-separated = component). >>> I think this form is a slightly nicer. It encourages the IV and >> authentication tag >>> lengths to be fixed for an algorithm (a slightly lazy recipient will = not >> accept >>> whatever length the last dot-separated mac field has). One = side-effect is >> that >>> the header will often remain the same for messages between two = parties >>> (no varying-per-message elements), which might aid performance in = some >>> situations. >>>>=20 >>>> 7. The output of a key agreement algorithm is used to encrypt a = random >>> per-message AEAD key. It is not used as the AEAD key directly. >>>>=20 >>>> 8. Defines one media type "application/jwsec", not separate ones = for >>> signed and encrypted messages. >>>>=20 >>>> 9. Has two header elements for key identifiers: "kid", and "okid". >> "okid" is >>> used to identify the originators key. You need both when using a key >>> agreement algorithm. >>>>=20 >>>> 10. No "typ" header element. There is a separate indicator for when = one >>> JWsec message envelopes another (eg signed-then-encrypted message). >>>>=20 >>>>=20 >>>> I hope this is a useful contribution to making a great JOSE suite = of >> specs. >>>>=20 >>>> -- >>>> James Manger >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From naa@google.com Tue Jun 12 14:51: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 764EB11E8073 for ; Tue, 12 Jun 2012 14:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqvxcPua3f9n for ; Tue, 12 Jun 2012 14:51:41 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E414621F847D for ; Tue, 12 Jun 2012 14:51:40 -0700 (PDT) Received: by yenq13 with SMTP id q13so18785yen.31 for ; Tue, 12 Jun 2012 14:51:40 -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=F5CUeXNkvl+OKMKrlXEmULDA7EOi5hwmrJN3DdE7TiM=; b=W/4XmQuR8Udr1ZkvuZuUOLYpLq+KowiubNVNuP3EMqv6GE+uvoran9wZmdBRJgdlVZ Kl92iVRrAo55W09Lnt1sVcS86mcQ02EEBzxyI1/c/5DKJHjrSC87O5DZ0h+WMmp9ca3P 9jvoO1CzxJsNvDLoS3+TSsS7Co6YkYrWYyfoiWUX/fsG76fJbFnx7O72NgUxE9F60rrf dbo9PWH+tEqN8VVQPVX1h2Yrsf4KK+EhCszPV4qhjxZPyx0PB47vTZTL/sj9ZCxZci5F QUBt/iIsoX2Ob/KA7gJ2EMs3dzsGkHqKlMn6iMsAsLzKHf6RHgCIRPgWN9Mf2ReQEchq ZemA== 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=F5CUeXNkvl+OKMKrlXEmULDA7EOi5hwmrJN3DdE7TiM=; b=Y5oRHfdIxqOIKHlEPZX5DfXibJHrULm2CH7pNiYu/K1vlHRIoAnU2f0h2t3+7xtXhR 3mXP2koR1ZhKvg8UX83C9CMrdQc5bEQGtn35dSGOop5ZQmFDl/cJrY3Y2gRaWGJPxFoL PX3KLXUOG7En8ULtQthjbfYJZRuMUlpy3+8RcpXmQWyd7esriPgM9ktojX/MwmmxydIH Age0hyOAZzvHinbK1ZXD52XrZSLCJ5xWZ2Q5QI1VTmRvGslQS5ZGrQ8jDl49iFoGBCZa nY/Ol5sEX2nFuF74cjxoX4VnidQ7kHOJGbq83AQrQQDm2Sn4lQKuJ/aneATEskz/DZBd 3Xlw== Received: by 10.50.196.195 with SMTP id io3mr9426369igc.39.1339537900149; Tue, 12 Jun 2012 14:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.196.195 with SMTP id io3mr9426356igc.39.1339537900000; Tue, 12 Jun 2012 14:51:40 -0700 (PDT) Received: by 10.50.135.42 with HTTP; Tue, 12 Jun 2012 14:51:39 -0700 (PDT) In-Reply-To: <5C6BFDE3-CD9E-4985-A68A-7BA6303E3D38@bbn.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> <5C6BFDE3-CD9E-4985-A68A-7BA6303E3D38@bbn.com> Date: Tue, 12 Jun 2012 14:51:39 -0700 Message-ID: From: Naveen Agarwal To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae9341193b1550d04c24d78c5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkvP1idBu+4wzYnc2vquUWBvbyxDHLKHPsPzvuAgpgt9cQxV0aIJlGWwcSH3P0CzyOZ6K5Sn6YMu1crWlU7fxtVuMWkSde1CiFzESOM1nVJYfh101tof+4Txt+cSy7gWWJKZVZa Cc: John Bradley , Jim Schaad , jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 21:51:42 -0000 --14dae9341193b1550d04c24d78c5 Content-Type: text/plain; charset=ISO-8859-1 > 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. > "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- > separated base64url-encoded components, including a JSON object header. I don't see much value in adding a prefix as there will be two places for similar information (will cause confusion) and people will do premature optimization while parsing the token. A visual indicator may have been useful if the token was for human consumption, but it is not. Also we have this working and being used in multiple places and we would like to avoid breaking changes unless there is a very compelling reason. Thanks Naveen On Tue, Jun 12, 2012 at 6:24 AM, Richard L. Barnes wrote: > >>> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > Of > >>> John Bradley > >>> Sent: Monday, June 11, 2012 12:52 PM > >>> To: Manger, James H > >>> Cc: jose@ietf.org > >>> Subject: Re: [jose] draft-manger-jose-jwsec > >>> > >>> I am against adding the prefix that winds up outside the integrity > >> protection. > >>> > >>> It is an un necessary and breaking change to many existing JWS > >> deployments. > >>> > >>> Taking the IV out of the header removes the integrity check over it and > >>> complicates parsing by JSON. > >> > >> It does not necessarily remove it from the integrity check. This > depends on > >> how the AEAD algorithm is defined. The stream authenticated could be > the > >> header || the iv || the message body so that it is still authenticated. > > > > Yes if the iv is prepended or appended to the cyphertext that would > happen however the additional parsing and potential for interop problems is > not worth it. > > > What's the attack you're worried about if the IV is not > integrity-protected? > > --Richard > > > > > > > > >> > >>> > >>> It is not using Authenticated encryption, AEAD only adds integrity not > >> sender > >>> authentication. > >> > >> The AEAD algorithm class is called Authenticated encryption with > additional > >> data. This is the term for the art. Note that this does not imply > sender > >> origination which is the additional service one wants signatures for. > There > >> is a debate if you get sender origination even with static-static key > >> agreement. > >> > > OK if it is used as a term of art, rather than implying sender > verification. > > > > I expect that some people are going to object to being forced to do > integrity if they intend to do signing in some other way. I personally > don't see it as the end of the world. > > > > John B. > > > > > >>> > >>> I agree that for simplicity the output of key agreement should be used > to > >>> encrypt a CMK, that adds some more processing for key agreement, > but is > >>> overall more consistent. > >>> > >>> We didn't do a okid because the WG was against my proposal to add > static > >>> static key agreement in Paris. If feelings have changed then it > should > >> be in. > >>> > >>> Sorry for the short response I am traveling. > >>> > >>> John B. > >>> > >>> On 2012-06-11, at 4:04 PM, Manger, James H wrote: > >>> > >>>> I have proposed various changes to JWS/JWE/JWT recently, but not > always > >>> with specific text changes to the existing documents. So I have had a > go > >>> putting the changes together as a vaguely complete draft spec. The > result > >> is: > >>>> > >>>> JSON Web Security Message Format (JWsec) > >>>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 > >>>> > >>>> Abstract: > >>>> This document describes a cryptographic message format based on > >>>> JavaScript Object Notation (JSON) and base-64 encodings to be easy > >>>> for web applications to generate and process. Signed, encrypted, > >>>> signed-then-encrypted, and unprotected messages are supported using > >>>> symmetric and/or asymmetric keys. > >>>> > >>>> Changes from JWS/JWE/JWA/JWT: > >>>> > >>>> 1. The nickname JWsec is used for a message that can be signed, > >>> encrypted, or unprotected. All three modes are covered by one ABNF > >>> syntax. All three are included in the one spec. > >>>> > >>>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is > unprotected > >> (c.f. > >>> "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- > >>> separated base64url-encoded components, including a JSON object header. > >>>> > >>>> 3. Each mode can compress the input data. > >>>> > >>>> 4. Only uses authenticated encryption with additional data (AEAD). > >>>> > >>>> 5. Unrecognized header elements MUST be ignored to allow new elements > >>> to be deployed without breaking interoperability. If new elements that > >>> MUST NOT be ignored are required, then a new mode can easily be > defined. > >>>> > >>>> 6. The initialization vector (IV) and authentication tag associated > with > >> an > >>> AEAD algorithm are prepended, and appended to the ciphertext > respectively > >>> (instead of using a header element and another dot-separated > component). > >>> I think this form is a slightly nicer. It encourages the IV and > >> authentication tag > >>> lengths to be fixed for an algorithm (a slightly lazy recipient will > not > >> accept > >>> whatever length the last dot-separated mac field has). One side-effect > is > >> that > >>> the header will often remain the same for messages between two parties > >>> (no varying-per-message elements), which might aid performance in some > >>> situations. > >>>> > >>>> 7. The output of a key agreement algorithm is used to encrypt a random > >>> per-message AEAD key. It is not used as the AEAD key directly. > >>>> > >>>> 8. Defines one media type "application/jwsec", not separate ones for > >>> signed and encrypted messages. > >>>> > >>>> 9. Has two header elements for key identifiers: "kid", and "okid". > >> "okid" is > >>> used to identify the originators key. You need both when using a key > >>> agreement algorithm. > >>>> > >>>> 10. No "typ" header element. There is a separate indicator for when > one > >>> JWsec message envelopes another (eg signed-then-encrypted message). > >>>> > >>>> > >>>> I hope this is a useful contribution to making a great JOSE suite of > >> specs. > >>>> > >>>> -- > >>>> 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 > --14dae9341193b1550d04c24d78c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> 2. A prefix ("U.", "S.", or &q= uot;E.") indicates if a message is unprotected=A0(c.f.
> = "alg":"none"), signed, or encrypted. The rest (as in JW= S/JWE) is dot-
> separated base64url-encoded components, including a JSON object header= .

I don't see much value in adding a prefix as = there will be two places for similar information (will cause confusion) and= people will do premature optimization while parsing the token. A visual in= dicator may have been useful if the token was for human consumption, but it= is not.
Also we have this working and being used in multiple places and we would li= ke to avoid breaking changes unless there is a very compelling reason.
<= div>
Thanks

Naveen



On Tue, Jun 12, 2012 at 6:24 AM, Ri= chard L. Barnes <rbarnes@bbn.com> wrote:
>>>
>>> -----Original Message-----
>>> From: jose-bounces@ie= tf.org [mailto:jose-bounces@ie= tf.org] On Behalf Of
>>> John Bradley
>>> Sent: Monday, June 11, 2012 12:52 PM
>>> To: Manger, James H
>>> Cc: jose@ietf.org
>>> Subject: Re: [jose] draft-manger-jose-jwsec
>>>
>>> I am against adding the prefix that winds up outside the integ= rity
>> protection.
>>>
>>> It is an un necessary and breaking change to many existing JWS=
>> deployments.
>>>
>>> Taking the IV out of the header removes the integrity check ov= er it and
>>> complicates parsing by JSON.
>>
>> It does not necessarily remove it from the integrity check. =A0Thi= s depends on
>> how the AEAD algorithm is defined. =A0The stream authenticated cou= ld be the
>> header || the iv || the message body so that it is still authentic= ated.
>
> Yes if the iv is prepended or appended to the cyphertext that would ha= ppen however the additional parsing and potential for interop problems is n= ot worth it.


What's the attack you're worried about if the IV is not integrity-p= rotected?

--Richard





>
>>
>>>
>>> It is not using Authenticated encryption, =A0AEAD only adds in= tegrity not
>> sender
>>> authentication.
>>
>> The AEAD algorithm class is called Authenticated encryption with a= dditional
>> data. =A0This is the term for the art. =A0Note that this does not = imply sender
>> origination which is the additional service one wants signatures f= or. =A0There
>> is a debate if you get sender origination even with static-static = key
>> agreement.
>>
> OK if it is used as a term of art, rather than implying sender verific= ation.
>
> I expect that some people are going to object to being forced to do in= tegrity if they intend to do signing in some other way. =A0 I personally do= n't see it as the end of the world.
>
> John B.
>
>
>>>
>>> I agree that for simplicity the output of key agreement should= be used to
>>> encrypt a CMK, =A0that adds some =A0more processing for key ag= reement, =A0but is
>>> overall more consistent.
>>>
>>> We didn't do a okid because the WG was against my proposal= to add static
>>> static key agreement in Paris. =A0 If feelings have changed th= en it should
>> be in.
>>>
>>> Sorry for the short response I am traveling.
>>>
>>> John B.
>>>
>>> On 2012-06-11, at 4:04 PM, Manger, James H wrote:
>>>
>>>> I have proposed various changes to JWS/JWE/JWT recently, b= ut not always
>>> with specific text changes to the existing documents. So I hav= e had a go
>>> putting the changes together as a vaguely complete draft spec.= The result
>> is:
>>>>
>>>> JSON Web Security Message Format (JWsec)
>>>> http://tools.ietf.org/html/draft-manger-jose-jwse= c-00
>>>>
>>>> Abstract:
>>>> This document describes a cryptographic message format bas= ed on
>>>> JavaScript Object Notation (JSON) and base-64 encodings to= be easy
>>>> for web applications to generate and process. =A0Signed, e= ncrypted,
>>>> signed-then-encrypted, and unprotected messages are suppor= ted using
>>>> symmetric and/or asymmetric keys.
>>>>
>>>> Changes from JWS/JWE/JWA/JWT:
>>>>
>>>> 1. The nickname JWsec is used for a message that can be si= gned,
>>> encrypted, or unprotected. All three modes are covered by one = ABNF
>>> syntax. All three are included in the one spec.
>>>>
>>>> 2. A prefix ("U.", "S.", or "E.&q= uot;) indicates if a message is unprotected
>> (c.f.
>>> "alg":"none"), signed, or encrypted. The r= est (as in JWS/JWE) is dot-
>>> separated base64url-encoded components, including a JSON objec= t header.
>>>>
>>>> 3. Each mode can compress the input data.
>>>>
>>>> 4. Only uses authenticated encryption with additional data= (AEAD).
>>>>
>>>> 5. Unrecognized header elements MUST be ignored to allow n= ew elements
>>> to be deployed without breaking interoperability. If new eleme= nts that
>>> MUST NOT be ignored are required, then a new mode can easily b= e defined.
>>>>
>>>> 6. The initialization vector (IV) and authentication tag a= ssociated with
>> an
>>> AEAD algorithm are prepended, and appended to the ciphertext r= espectively
>>> (instead of using a header element and another dot-separated c= omponent).
>>> I think this form is a slightly nicer. It encourages the IV an= d
>> authentication tag
>>> lengths to be fixed for an algorithm (a slightly lazy recipien= t will not
>> accept
>>> whatever length the last dot-separated mac field has). One sid= e-effect is
>> that
>>> the header will often remain the same for messages between two= parties
>>> (no varying-per-message elements), which might aid performance= in some
>>> situations.
>>>>
>>>> 7. The output of a key agreement algorithm is used to encr= ypt a random
>>> per-message AEAD key. It is not used as the AEAD key directly.=
>>>>
>>>> 8. Defines one media type "application/jwsec", n= ot separate ones for
>>> signed and encrypted messages.
>>>>
>>>> 9. Has two header elements for key identifiers: "kid&= quot;, and "okid".
>> "okid" is
>>> used to identify the originators key. You need both when using= a key
>>> agreement algorithm.
>>>>
>>>> 10. No "typ" header element. There is a separate= indicator for when one
>>> JWsec message envelopes another (eg signed-then-encrypted mess= age).
>>>>
>>>>
>>>> I hope this is a useful contribution to making a great JOS= E suite of
>> specs.
>>>>
>>>> --
>>>> 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
ht= tps://www.ietf.org/mailman/listinfo/jose

--14dae9341193b1550d04c24d78c5-- From breno@google.com Tue Jun 12 15:04: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 D8E0221F869F for ; Tue, 12 Jun 2012 15:04:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOPdUPCYBggr for ; Tue, 12 Jun 2012 15:04:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A394921F86F5 for ; Tue, 12 Jun 2012 15:04:01 -0700 (PDT) Received: by yhq56 with SMTP id 56so42197yhq.31 for ; Tue, 12 Jun 2012 15:04:01 -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:content-transfer-encoding:x-system-of-record; bh=XZlvUfJ/w8s0GMXmoAazfKEuK+c3AXpW7HjYWIERmHE=; b=GhxM0VZZdDMJJ86TTCxiNcCcJ5h9wPuBtsguBZ+wwbUUqgkK+3WgL385v/c9ZUeLlg Vzz63dSpQ4zQJfKEq1e0a1JV85+AzSnH8jK/vnh8NW0eB2TxMqrhogTW4r5iJDcz5mtM +ZOkUUKLUQT6llEdLlCqpFh1Oq53STupRUwRe+JoS/BHHvsz5JCKySCeuGtx2v7fOSvf MdbCZ6FruW38AHlNxWmsNXDnfcBC/5Xen84W8/Q+rGFsIiFhfYe7sFB0hMH3ILsOw5On zSGzzl/sJTexAB/zNx2kpNytsnFT7s1ZMju+CkL8Wi6GFtNnynXRlAHwbXYnrIG2jLvF 2uYQ== 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:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=XZlvUfJ/w8s0GMXmoAazfKEuK+c3AXpW7HjYWIERmHE=; b=cjJExocEbmIQO0b1Mtsmyy9+5RYdy/RPI5UTD9fvItBFBfxZKX0XIxhqRErPUWyohu FBmDC005eiIAM07iu9tK6zB265jDCJsk1WHiJZ2H2lsiHSrCNabom/lqlgT4DFJNokH1 WeozyuVwOCQoUi62LbtvquPfweOk8ZaDTYQ60g5hDsBqrGZgBqpMg5JU8BFGDly9h1+a hSHAiq/7sCHzLBWGnCMRuBPnguA7wqO8dJ9P/jT8NJ1qCkDWKggNOItX0E2Vq4lHAsXE dhZjeEWRYdysZKiQVCasa70qqS9MiW+C4Ud4xCRBc+NoiY9lSjqMjc4abFG0tj9g0n2W 8jrA== Received: by 10.50.169.73 with SMTP id ac9mr9498414igc.29.1339538641089; Tue, 12 Jun 2012 15:04:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.169.73 with SMTP id ac9mr9498404igc.29.1339538640923; Tue, 12 Jun 2012 15:04:00 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Tue, 12 Jun 2012 15:04:00 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> <5C6BFDE3-CD9E-4985-A68A-7BA6303E3D38@bbn.com> Date: Tue, 12 Jun 2012 15:04:00 -0700 Message-ID: From: Breno de Medeiros To: Naveen Agarwal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQn/cJxbniIyA4fMT5wuucnwFBVxAmtymHHCB2ibmG+XJ6NV6SFAqL/ODvxwwCr2AmXMJowUeLuHM1yrHU4Aha+hEuGX9CiyvqxyVZyPHqI/LQSTbpT7D/FFSUbpP+REM8R3ZTGg Cc: John Bradley , Jim Schaad , "Manger, James H" , jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 12 Jun 2012 22:04:03 -0000 I also don't see any value in this indication. Information such as 'S' without the algorithm value present in the header is not actionable information. So parsers will ignore this information and use the header instead. On the other hand, if the information is _not_ to be ignored, then we introduce a whole new layer of validation. If a token is signed and encrypted, should it be type 'S', or type 'E'? This adds no value and creates more opportunities for interoperability issues. On Tue, Jun 12, 2012 at 2:51 PM, Naveen Agarwal wrote: > >> 2. A prefix ("U.", "S.", or "E.") indicates if a message is >> unprotected=A0(c.f. >> "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- >> separated base64url-encoded components, including a JSON object header. > > I don't see much value in adding a prefix as there will be two places for > similar information (will cause confusion) and people will do premature > optimization while parsing the token. A visual indicator may have been > useful if the token was for human consumption, but it is not. > Also we have this working and being used in multiple places and we would > like to avoid breaking changes unless there is a very compelling reason. > > Thanks > > Naveen > > > > On Tue, Jun 12, 2012 at 6:24 AM, Richard L. Barnes wrot= e: >> >> >>> >> >>> -----Original Message----- >> >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> >>> Of >> >>> John Bradley >> >>> Sent: Monday, June 11, 2012 12:52 PM >> >>> To: Manger, James H >> >>> Cc: jose@ietf.org >> >>> Subject: Re: [jose] draft-manger-jose-jwsec >> >>> >> >>> I am against adding the prefix that winds up outside the integrity >> >> protection. >> >>> >> >>> It is an un necessary and breaking change to many existing JWS >> >> deployments. >> >>> >> >>> Taking the IV out of the header removes the integrity check over it >> >>> and >> >>> complicates parsing by JSON. >> >> >> >> It does not necessarily remove it from the integrity check. =A0This >> >> depends on >> >> how the AEAD algorithm is defined. =A0The stream authenticated could = be >> >> the >> >> header || the iv || the message body so that it is still authenticate= d. >> > >> > Yes if the iv is prepended or appended to the cyphertext that would >> > happen however the additional parsing and potential for interop proble= ms is >> > not worth it. >> >> >> What's the attack you're worried about if the IV is not >> integrity-protected? >> >> --Richard >> >> >> >> >> >> > >> >> >> >>> >> >>> It is not using Authenticated encryption, =A0AEAD only adds integrit= y >> >>> not >> >> sender >> >>> authentication. >> >> >> >> The AEAD algorithm class is called Authenticated encryption with >> >> additional >> >> data. =A0This is the term for the art. =A0Note that this does not imp= ly >> >> sender >> >> origination which is the additional service one wants signatures for. >> >> =A0There >> >> is a debate if you get sender origination even with static-static key >> >> agreement. >> >> >> > OK if it is used as a term of art, rather than implying sender >> > verification. >> > >> > I expect that some people are going to object to being forced to do >> > integrity if they intend to do signing in some other way. =A0 I person= ally >> > don't see it as the end of the world. >> > >> > John B. >> > >> > >> >>> >> >>> I agree that for simplicity the output of key agreement should be us= ed >> >>> to >> >>> encrypt a CMK, =A0that adds some =A0more processing for key agreemen= t, >> >>> =A0but is >> >>> overall more consistent. >> >>> >> >>> We didn't do a okid because the WG was against my proposal to add >> >>> static >> >>> static key agreement in Paris. =A0 If feelings have changed then it >> >>> should >> >> be in. >> >>> >> >>> Sorry for the short response I am traveling. >> >>> >> >>> John B. >> >>> >> >>> On 2012-06-11, at 4:04 PM, Manger, James H wrote: >> >>> >> >>>> I have proposed various changes to JWS/JWE/JWT recently, but not >> >>>> always >> >>> with specific text changes to the existing documents. So I have had = a >> >>> go >> >>> putting the changes together as a vaguely complete draft spec. The >> >>> result >> >> is: >> >>>> >> >>>> JSON Web Security Message Format (JWsec) >> >>>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >> >>>> >> >>>> Abstract: >> >>>> This document describes a cryptographic message format based on >> >>>> JavaScript Object Notation (JSON) and base-64 encodings to be easy >> >>>> for web applications to generate and process. =A0Signed, encrypted, >> >>>> signed-then-encrypted, and unprotected messages are supported using >> >>>> symmetric and/or asymmetric keys. >> >>>> >> >>>> Changes from JWS/JWE/JWA/JWT: >> >>>> >> >>>> 1. The nickname JWsec is used for a message that can be signed, >> >>> encrypted, or unprotected. All three modes are covered by one ABNF >> >>> syntax. All three are included in the one spec. >> >>>> >> >>>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is >> >>>> unprotected >> >> (c.f. >> >>> "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot= - >> >>> separated base64url-encoded components, including a JSON object >> >>> header. >> >>>> >> >>>> 3. Each mode can compress the input data. >> >>>> >> >>>> 4. Only uses authenticated encryption with additional data (AEAD). >> >>>> >> >>>> 5. Unrecognized header elements MUST be ignored to allow new elemen= ts >> >>> to be deployed without breaking interoperability. If new elements th= at >> >>> MUST NOT be ignored are required, then a new mode can easily be >> >>> defined. >> >>>> >> >>>> 6. The initialization vector (IV) and authentication tag associated >> >>>> with >> >> an >> >>> AEAD algorithm are prepended, and appended to the ciphertext >> >>> respectively >> >>> (instead of using a header element and another dot-separated >> >>> component). >> >>> I think this form is a slightly nicer. It encourages the IV and >> >> authentication tag >> >>> lengths to be fixed for an algorithm (a slightly lazy recipient will >> >>> not >> >> accept >> >>> whatever length the last dot-separated mac field has). One side-effe= ct >> >>> is >> >> that >> >>> the header will often remain the same for messages between two parti= es >> >>> (no varying-per-message elements), which might aid performance in so= me >> >>> situations. >> >>>> >> >>>> 7. The output of a key agreement algorithm is used to encrypt a >> >>>> random >> >>> per-message AEAD key. It is not used as the AEAD key directly. >> >>>> >> >>>> 8. Defines one media type "application/jwsec", not separate ones fo= r >> >>> signed and encrypted messages. >> >>>> >> >>>> 9. Has two header elements for key identifiers: "kid", and "okid". >> >> "okid" is >> >>> used to identify the originators key. You need both when using a key >> >>> agreement algorithm. >> >>>> >> >>>> 10. No "typ" header element. There is a separate indicator for when >> >>>> one >> >>> JWsec message envelopes another (eg signed-then-encrypted message). >> >>>> >> >>>> >> >>>> I hope this is a useful contribution to making a great JOSE suite o= f >> >> specs. >> >>>> >> >>>> -- >> >>>> 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 > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 --Breno From James.H.Manger@team.telstra.com Tue Jun 12 17:21: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 F150311E8080 for ; Tue, 12 Jun 2012 17:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_44=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrzmPFjpX186 for ; Tue, 12 Jun 2012 17:21:24 -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 0A0D121F873D for ; Tue, 12 Jun 2012 17:21:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,400,1336312800"; d="scan'208";a="76492454" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 13 Jun 2012 10:21:20 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6740"; a="69177829" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbni.tcif.telstra.com.au with ESMTP; 13 Jun 2012 10:21:20 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Wed, 13 Jun 2012 10:21:19 +1000 From: "Manger, James H" To: Naveen Agarwal Date: Wed, 13 Jun 2012 10:21:18 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1I5ZCNe3uP7oGES061FiqPPU27SgADt8UQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F557C914@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> <5C6BFDE3-CD9E-4985-A68A-7BA6303E3D38@bbn.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 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 00:21:25 -0000 Pj4gMi4gQSBwcmVmaXggKCJVLiIsICJTLiIsIG9yICJFLiIpIGluZGljYXRlcyBpZiBhIG1lc3Nh Z2UgaXMgdW5wcm90ZWN0ZWTCoChjLmYuDQo+PiAiYWxnIjoibm9uZSIpLCBzaWduZWQsIG9yIGVu Y3J5cHRlZC4gVGhlIHJlc3QgKGFzIGluIEpXUy9KV0UpIGlzIGRvdC0NCj4+IHNlcGFyYXRlZCBi YXNlNjR1cmwtZW5jb2RlZCBjb21wb25lbnRzLCBpbmNsdWRpbmcgYSBKU09OIG9iamVjdCBoZWFk ZXIuDQoNCj4gSSBkb24ndCBzZWUgbXVjaCB2YWx1ZSBpbiBhZGRpbmcgYSBwcmVmaXggYXMgdGhl cmUgd2lsbCBiZSB0d28gcGxhY2VzIGZvciBzaW1pbGFyIGluZm9ybWF0aW9uICh3aWxsIGNhdXNl IGNvbmZ1c2lvbikgYW5kIHBlb3BsZSB3aWxsIGRvIHByZW1hdHVyZSBvcHRpbWl6YXRpb24gd2hp bGUgcGFyc2luZyB0aGUgdG9rZW4uIEEgdmlzdWFsIGluZGljYXRvciBtYXkgaGF2ZSBiZWVuIHVz ZWZ1bCBpZiB0aGUgdG9rZW4gd2FzIGZvciBodW1hbiBjb25zdW1wdGlvbiwgYnV0IGl0IGlzIG5v dC4NCg0KTmF2ZWVuLA0KDQpUaGVyZSB3aWxsIGJlIG5vIGNvbmZ1c2lvbi4gVGhlIHByZWZpeCB0 ZWxscyB5b3Ugd2hldGhlciB5b3UgaGF2ZSBoZWFkLmRhdGEuc2lnIG9yIGhlYWQuZW5ja2V5LmNp cGhlcnRleHQgb3IgaGVhZC5kYXRhIG9yIGEgbW9kZSB5b3VyIGNvZGUgZG9lc24ndCBzdXBwb3J0 IHlldC4gV2hlbiB5b3UgZ2V0IHRvIHlvdXIgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBjb2RlIHlv dSB1c2UgdGhlICJhbGciIChvciAic2lnIikgaGVhZGVyIHZhbHVlIHRvIGluc3RhbnRpYXRlIHRo ZSByaWdodCBTaWduYXR1cmUgY3J5cHRvIGNsYXNzLg0KDQpBdCB0aGUgbW9tZW50IHdlIGFscmVh ZHkgaGF2ZSAidHdvIHBsYWNlcyBmb3Igc2ltaWxhciBpbmZvcm1hdGlvbiAod2lsbCBjYXVzZSBj b25mdXNpb24pIi4gV2UgaGF2ZSB0d28gaGV1cmlzdGljcyBmb3IgZGlzdGluZ3Vpc2hpbmcgc2ln bmVkL2VuY3J5cHRlZC91bnByb3RlY3RlZC9vdGhlcjogZWl0aGVyIGxvb2sgYXQgdGhlICJhbGci IHZhbHVlLCBvciBsb29rIGZvciB0aGUgcHJlc2VuY2Ugb2YgYW4gImVuYyIgZWxlbWVudC4gVGhl IGZpcnN0IGhldXJpc3RpYyBmYWlscyBpZiB5b3UgZG9uJ3QgcmVjb2duaXplIHRoZSAiYWxnIiB2 YWx1ZSAoYXQgdGhhdCBwb2ludCBpbiB5b3VyIGNvZGUpLiBUaGUgc2Vjb25kIGhldXJpc3RpYyBm YWlscyBpZiB3ZSBldmVyIGNvbWUgdXAgd2l0aCBhbm90aGVyIG1vZGUgKHRob3NlIG1lc3NhZ2Vz IHdpbGwgYmUgbWlzaW50ZXJwcmV0ZWQgYXMgZW5jcnlwdGVkIG9yIHNpZ25lZCBiYXNlZCBvbiB0 aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiAiZW5jIikuIFRoZSBmaXJzdCBzaWduIG9mIGZhaWx1 cmUgaXMgdGhhdCB0aGUgYWRkaXRpb24gb2YgInVucHJvdGVjdGVkIiBtb2RlIHJlcXVpcmVkIGEg ZmFrZSBzaWduYXR1cmUgYWxnb3JpdGhtICgiYWxnIjoibm9uZSIpIHRvIGJlIGRlZmluZWQuIFdo YXQgZG8gd2UgZG8gZm9yIHRoZSBuZXh0IG1vZGU/DQoNCkZvciBleGFtcGxlLCBpdCBpcyBlYXN5 IHRvIGltYWdpbmUgZW5jcnlwdGlvbiB0aGF0IGlkZW50aWZpZXMgYSBrZXkgYnV0IG5vdCBhbiBh bGdvcml0aG0uIFRoZSBhbGdvcml0aG0gaXMgaW1wbGllZCBieSB0aGUga2V5LCB0byBlbmZvcmNl IGdvb2QgY3J5cHRvIHByYWN0aWNlIG9mIG9ubHkgdXNpbmcgYW55IGdpdmVuIGtleSB3aXRoIG9u ZSBhbGdvcml0aG0uIEltcGxlbWVudGluZyB0aGF0IHdvdWxkIG5lZWQgaGFja3MgdG8gYXZvaWQg YnJlYWtpbmcgdGhlICJhbGciIGFuZCAiZW5jIiBoZXVyaXN0aWNzLg0KDQoNCk15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdCBEaWNrIEhhcmR0IHdvdWxkIG5vdyBsaWtlIHRoZSBpbmZvIHByb3ZpZGVk IGJ5IHRoZSBwcmVmaXgsIGJ1dCB3YW50cyBpdCBpbiBkZWRpY2F0ZWQgaGVhZGVyIGVsZW1lbnRz LiBEbyB5b3Ugbm90IGV2ZW4gd2FudCB0aGF0LCBOYXZlZW4/DQoNCi0tDQpKYW1lcyBNYW5nZXIN Cg0K From James.H.Manger@team.telstra.com Tue Jun 12 17:44:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2021F8754 for ; Tue, 12 Jun 2012 17:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7I9JtqHD-+6 for ; Tue, 12 Jun 2012 17:44:33 -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 9E2A421F8717 for ; Tue, 12 Jun 2012 17:44:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,400,1336312800"; d="scan'208";a="82629092" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 13 Jun 2012 10:44:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6740"; a="69552918" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 13 Jun 2012 10:44:31 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 13 Jun 2012 10:44:30 +1000 From: "Manger, James H" To: Breno de Medeiros Date: Wed, 13 Jun 2012 10:44:29 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1I50iuCOW/EHIqRzSR3gpEfti5qQAE2Eug Message-ID: <255B9BB34FB7D647A506DC292726F6E114F557C9A4@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> <5C6BFDE3-CD9E-4985-A68A-7BA6303E3D38@bbn.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 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 00:44:34 -0000 PiBJZiBhIHRva2VuIGlzIHNpZ25lZCBhbmQgZW5jcnlwdGVkLCBzaG91bGQgaXQgYmUNCj4gdHlw ZSAnUycsIG9yIHR5cGUgJ0UnPyBUaGlzIGFkZHMgbm8gdmFsdWUgYW5kDQo+IGNyZWF0ZXMgbW9y ZSBvcHBvcnR1bml0aWVzIGZvciBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4NCg0KSWYgaXQgaXMg c2lnbmVkLXRoZW4tZW5jcnlwdGVkIHRoZSBvdXRlciBzdHJ1Y3R1cmUgaXMgaGVhZC5lbmNrZXku Y2lwaGVydGV4dCBzbyB0aGUgcHJlZml4IGlzICJlLiIgKCJlIiBmb3IgZW5jcnlwdGVkIG1lc3Nh Z2U7IGxvd2VyY2FzZSBiZWNhdXNlIHRoZSBwbGFpbnRleHQgaXMgYW5vdGhlciBKT1NFIG1lc3Nh Z2UsIHdoaWNoIGhhcyBhICJTLiIgcHJlZml4KS4NCg0KSWYgaXQgaXMgZW5jcnlwdGVkLXRoZW4t c2lnbmVkIHRoZSBvdXRlciBzdHJ1Y3R1cmUgaXMgaGVhZC5kYXRhLnNpZ25hdHVyZSBzbyB0aGUg cHJlZml4IGlzICJzLiIgKCJzIiBmb3Igc2lnbmVkIG1lc3NhZ2U7IGxvd2VyY2FzZSBiZWNhdXNl IHRoZSBkYXRhIGlzIGFub3RoZXIgSk9TRSBtZXNzYWdlLCB3aGljaCBoYXMgYW4gIkUuIiBwcmVm aXgpLg0KDQpJZiB3ZSBjb21lIHVwIHdpdGggYSBjb21iaW5lZCBzaWduZWQgKHdpdGggcHVibGlj L3ByaXZhdGUga2V5IHBhaXIpIGFuZCBlbmNyeXB0ZWQgbW9kZSAodGhhdCBpc24ndCBvbmUgb2Yg dGhlIGFib3ZlIHR3bykgdGhlbiBhIG5ldyB0eXBlL3ByZWZpeCB3b3VsZCBiZSByZWFsbHkgaGVs cGZ1bC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From progrium@gmail.com Tue Jun 12 17:45: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 BA2B011E8098 for ; Tue, 12 Jun 2012 17:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LVD618nEVFi for ; Tue, 12 Jun 2012 17:45:42 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C27C621F8717 for ; Tue, 12 Jun 2012 17:45:41 -0700 (PDT) Received: by ggnc4 with SMTP id c4so15732ggn.31 for ; Tue, 12 Jun 2012 17:45:41 -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=Aos3p6atxelh44RNcDtpoL/UGxFYv+MkfSku8rvoE4Q=; b=NoAX7LHMpTGa8UNY306l0UgmysQcB1hokgAnydrP/wzaKp2m65GC8hOZ2I2r5IWME3 ACohnZhzpVkvbuA3S/FeBF40SCcgztWY6MondVBqaqMhm/T7WUqY4tr2w6MxUhp9yu9d UsC5q0ig3f0r3/6KaT6uwekxwKGbkiv7dJx7WgzHaAoaLHGJoMTdsLW4erA4yiKFtgxc HaCD6zQL+RsdJ++/N/gJC9ZJ/fr9THgusVuRAwuPbtcMYiNsIPTDbuhP18wvx5u5nlv0 2NbnGSFMdVmZETvs/11kmM7hFnzx9hQ/HkGZJcpSOO7mGInUBMsfaslF5yOyl5rGgC0L QVZA== MIME-Version: 1.0 Received: by 10.101.141.21 with SMTP id t21mr9562633ann.34.1339548341329; Tue, 12 Jun 2012 17:45:41 -0700 (PDT) Received: by 10.236.170.97 with HTTP; Tue, 12 Jun 2012 17:45:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jun 2012 17:45:41 -0700 Message-ID: From: Jeff Lindsay To: jose@ietf.org Content-Type: multipart/alternative; boundary=0016e6d3de570b5f0504c24fe7b2 X-Mailman-Approved-At: Tue, 12 Jun 2012 21:38:27 -0700 Subject: [jose] Fwd: JWT library timing attack vulnerability 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, 13 Jun 2012 00:46:21 -0000 --0016e6d3de570b5f0504c24fe7b2 Content-Type: text/plain; charset=ISO-8859-1 FYI. Perhaps worth mentioning in the spec under security considerations. ---------- Forwarded message ---------- From: Jack Date: Thu, Jun 7, 2012 at 8:34 PM Subject: JWT library timing attack vulnerability To: edchavez@gmail.com, dirk.balfanz@gmail.com, progrium@gmail.com, neuman@ashmoremusic.com I noticed a timing attack vulnerability in your code for JWT hmac verification. When comparing the hmac signature of a foreign JWT with the calculated signature, the computation shortcircuits depending on how many bytes of the signatures match. This timing leak allows attackers to gain information about the secret signing key by sending specially crafted signatures. Here are some blogs posts describing the problem and fix in more detail: http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/ http://rdist.root.org/2010/01/07/timing-independent-array-comparison/ I found this vulnerability because I made the same mistake while implementing a JWT library in Lua. The solution requires making the string comparison always loop over the length of the signatures. Another potential pitfall is that the char by char checks should be performed with bitwise OR's as opposed to logical comparisons because the latter also leaks timing information. I've sent this email to the authors of all the libraries that google references in the in-app payment docs affected by this vulnerability. Thanks, Jack -- Jeff Lindsay http://progrium.com --0016e6d3de570b5f0504c24fe7b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI. Perhaps worth mentioning in the spec under security considerations.
---------- Forwarded message ----------
= From: Jack <moonboots08@gmail.com>
Date: Thu, Jun 7, 2012 at 8:34 PM
Subject: JWT library timing attack vul= nerability
To: edchavez@gmail.com<= /a>, dirk.balfanz@gmail.com, = progrium@gmail.com, neuman@ashmoremusic.com


I noticed a timing attack vulnerability in your code for JWT hmac v= erification. When comparing the hmac signature of a foreign JWT with the ca= lculated signature, the computation shortcircuits depending on how many byt= es of the signatures match. This timing leak allows attackers to gain infor= mation about the secret signing key by sending specially crafted signatures= . Here are some blogs posts describing the problem and fix in more detail:<= div>

I found this vulnerability because I made the same mist= ake while implementing a JWT library in Lua. The solution requires making t= he string comparison always loop over the length of the signatures. Another= potential pitfall is that the char by char checks should be performed with= bitwise OR's as opposed to logical comparisons because the latter also= leaks timing information.

I've sent this email to the authors of all the libr= aries that google references in the in-app payment docs=A0affected by this = vulnerability.

Thanks,
Jack



--
Jeff Lindsay
http://progrium.com
--0016e6d3de570b5f0504c24fe7b2-- From vladimir@nimbusds.com Wed Jun 13 00:02: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 73F9F21F854A for ; Wed, 13 Jun 2012 00:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wI30Ht2bI6a for ; Wed, 13 Jun 2012 00:02: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 6E36A21F8496 for ; Wed, 13 Jun 2012 00:02:18 -0700 (PDT) Received: (qmail 3939 invoked from network); 13 Jun 2012 07:02:16 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 13 Jun 2012 07:02:16 -0000 Received: (qmail 12750 invoked by uid 99); 13 Jun 2012 07:02:16 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 95.43.44.226 User-Agent: Workspace Webmail 5.6.18 Message-Id: <20120613000215.cc40c4f3d92d2001859047cd8cabb9ab.5a32b7a273.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Manger, James H" Date: Wed, 13 Jun 2012 00:02:15 -0700 Mime-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 07:02:19 -0000 Hi James,=0A=0AWhat should happen when there is a mismatch between the "S"/= "E"/...=0Aprefix and the actual type of the applied algorithm?=0A=0A=0AChee= rs,=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimi= r@nimbusds.com=0A=0A From James.H.Manger@team.telstra.com Wed Jun 13 00:21: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 D83ED21F85B4 for ; Wed, 13 Jun 2012 00:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TnHpBUjQ5+m for ; Wed, 13 Jun 2012 00:21:54 -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 72DD321F85A5 for ; Wed, 13 Jun 2012 00:21:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,402,1336312800"; d="scan'208";a="77937856" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 13 Jun 2012 17:21:49 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6740"; a="68532456" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccvi.tcif.telstra.com.au with ESMTP; 13 Jun 2012 17:21:49 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 13 Jun 2012 17:21:49 +1000 From: "Manger, James H" To: Vladimir Dzhuvinov / NimbusDS Date: Wed, 13 Jun 2012 17:21:48 +1000 Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1JMnw5vAbe/v3aSWi2UlkoyF9rewAAAr0g Message-ID: <255B9BB34FB7D647A506DC292726F6E114F55FC28C@WSMSG3153V.srv.dir.telstra.com> References: <20120613000215.cc40c4f3d92d2001859047cd8cabb9ab.5a32b7a273.wbe@email07.europe.secureserver.net> In-Reply-To: <20120613000215.cc40c4f3d92d2001859047cd8cabb9ab.5a32b7a273.wbe@email07.europe.secureserver.net> 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 Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 07:21:55 -0000 PiBXaGF0IHNob3VsZCBoYXBwZW4gd2hlbiB0aGVyZSBpcyBhIG1pc21hdGNoIGJldHdlZW4gdGhl ICJTIi8iRSIvLi4uDQo+IHByZWZpeCBhbmQgdGhlIGFjdHVhbCB0eXBlIG9mIHRoZSBhcHBsaWVk IGFsZ29yaXRobT8NCg0KRVJST1I6ICJBMTI4S1ciIGlzIG5vdCBhIHN1cHBvcnRlZCBzaWduYXR1 cmUgYWxnb3JpdGhtDQoNCg0KSW4gSmF2YSwgZm9yIGluc3RhbmNlLCBpZiB5b3UgY2FsbA0KICBq YXZheC5jcnlwdG8uQ2lwaGVyLmdldEluc3RhbmNlKCJIbWFjU0hBNTEyIikNCnlvdSBnZXQNCiAg RXhjZXB0aW9uIGluIHRocmVhZCAibWFpbiIgamF2YS5zZWN1cml0eS5Ob1N1Y2hBbGdvcml0aG1F eGNlcHRpb246IENhbm5vdCBmaW5kIGFueSBwcm92aWRlciBzdXBwb3J0aW5nIEhNQUNTSEE1MTIN CiAgICAgICAgYXQgamF2YXguY3J5cHRvLkNpcGhlci5nZXRJbnN0YW5jZShEYXNob0ExMyouLikN Cg0KDQpKV0UvSldTIG1pZ2h0IGhhdmUgZW5jb3VyYWdlZCBsaWJyYXJpZXMgdG8gaGF2ZSBvbmUg Y29uc29saWRhdGVkIGxpc3Qgb2YgYWxsIHBvc3NpYmxlIGFsZ29yaXRobXMuIEkgc3VzcGVjdCB0 aGF0IGlzIGEgYml0IHVudXN1YWwsIGhvd2V2ZXIuIEkgZXhwZWN0IG1vc3QgY3J5cHRvIGxpYnJh cmllcyBoYXZlIHNlcGFyYXRlIGxpc3RzIGZvciBlbmNyeXB0aW9uLCBNQUMsIGRpZ2l0YWwgc2ln bmF0dXJlLCBjb21wcmVzc2lvbiBldGMgYWxnb3JpdGhtcy4NCg0KDQpXaXRoIGRyYWZ0LW1hbmdl ci1qb3NlLWp3c2VjIEkgZG9uJ3QgcmV1c2UgdGhlICJhbGciIGVsZW1lbnQuIEkgdXNlICJrbWci IGZvciB0aGUga2V5IG1hbmFnZW1lbnQgYWxnb3JpdGhtIGlkZW50aWZpZXIgd2hlbiBkb2luZyBl bmNyeXB0aW9uIGFuZCAic2lnIiB3aGVuIHNpZ25pbmcuIElmIHlvdSBpbmNvcnJlY3RseSBwdXQg dGhlICJTIiBwcmVmaXggb24gYW4gZW5jcnlwdGVkIEpXc2VjIG1lc3NhZ2UgdGhlIGVycm9yIGlz IGxpa2VseSB0byBiZToNCiAgRVJST1I6ICJzaWciIGVsZW1lbnQgaXMgbWlzc2luZw0KDQotLQ0K SmFtZXMgTWFuZ2VyDQo= From breno@google.com Wed Jun 13 00:27:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E9421F869A for ; Wed, 13 Jun 2012 00:27:39 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wQjNLl1hAxV for ; Wed, 13 Jun 2012 00:27:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D086721F8693 for ; Wed, 13 Jun 2012 00:27:38 -0700 (PDT) Received: by yenq13 with SMTP id q13so276127yen.31 for ; Wed, 13 Jun 2012 00:27:38 -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=2rGUK67yyYjTqTyZNHLNVydCAW6lw1WI68bcLbaBZWU=; b=dJNeBJ5pR4JciJvjcNvnD0na9NYpFz68pSlRGiTkUIJAcHhji8mHia3dvLH9EmtKld m5fF2kW45oqlG1bxK34xQcw+YTJ91iXpVUBqNNPVJoq/IENNePUdLuBW9Fm0Gx8BBcgp TIEFhaLTDij29jso1fsKeTvn7fKnocq+IBdGI2pcSCVZ4cAHdxzkttDqoz1u7NbKvszI a4oqCGwwat3FbS+3d/HWDaqegx+KxZbJ4/K1h2+rLWBRmpMAmY8fLi/obWqJNOGge05D LzSmgRM2L1E5ZUQVPa+mJ8764/kMnbS2xlGXRfawPsewkzUW0VN7astahPSdk9/Z1CVz eTjw== 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=2rGUK67yyYjTqTyZNHLNVydCAW6lw1WI68bcLbaBZWU=; b=Et0mxzplDmiXQnpBvNgJaLqD4EjNGh26x5EOcUXimqscma3vU5efoKDpEO7p/cSxdE CCK2Mv+BSFbxoBAFXMj1/WZdorGjyL1wmIS7A4qqNN8lgliqxB9b5oH8jCEbBBckdgKN ausqqVPLh2GUAIX7otwXAQ5tESRAU41efuODO0/4J1V7Wogu5f7yAvPtn7Rz0dUS0vE5 fMcjClsjUxWAyEibc9fiU5tl8xLSR5RryL7WampYOdz7tsHNqdyjx1TY4V7zaRQka7US FFT1BEBSX9YL8TqSb3KEqsyiypBKbmGGkdfwdUwLwVtjhDQPqWqbf5qsJbMq8P7c3F3y s6jg== Received: by 10.50.222.162 with SMTP id qn2mr2058704igc.46.1339572457927; Wed, 13 Jun 2012 00:27:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.222.162 with SMTP id qn2mr2058698igc.46.1339572457759; Wed, 13 Jun 2012 00:27:37 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Wed, 13 Jun 2012 00:27:37 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Wed, 13 Jun 2012 00:27:37 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F55FC28C@WSMSG3153V.srv.dir.telstra.com> References: <20120613000215.cc40c4f3d92d2001859047cd8cabb9ab.5a32b7a273.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114F55FC28C@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 13 Jun 2012 00:27:37 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae9340fbf7ee31704c2558413 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk+Zsw2GonfBwVPp53wlsfEZ4m76i78chUWHL/Hzi8boYr2ZGvn3E1VqLgPtukiwNNilTqkevx88N+RWiC7tCcxzw5SOPp9QNqF6gmUsI/rwdju6/F2HRn/ZnQcI1MUhddcqSrk Cc: "jose@ietf.org" , Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 07:27:39 -0000 --14dae9340fbf7ee31704c2558413 Content-Type: text/plain; charset=ISO-8859-1 What is the benefit of such approach? Redundant information never helped write better code or promoted interoperability. The information needed to process the token is available in the envelope. On Jun 13, 2012 12:21 AM, "Manger, James H" wrote: > > What should happen when there is a mismatch between the "S"/"E"/... > > prefix and the actual type of the applied algorithm? > > ERROR: "A128KW" is not a supported signature algorithm > > > In Java, for instance, if you call > javax.crypto.Cipher.getInstance("HmacSHA512") > you get > Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot > find any provider supporting HMACSHA512 > at javax.crypto.Cipher.getInstance(DashoA13*..) > > > JWE/JWS might have encouraged libraries to have one consolidated list of > all possible algorithms. I suspect that is a bit unusual, however. I expect > most crypto libraries have separate lists for encryption, MAC, digital > signature, compression etc algorithms. > > > With draft-manger-jose-jwsec I don't reuse the "alg" element. I use "kmg" > for the key management algorithm identifier when doing encryption and "sig" > when signing. If you incorrectly put the "S" prefix on an encrypted JWsec > message the error is likely to be: > ERROR: "sig" element is missing > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --14dae9340fbf7ee31704c2558413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

What is the benefit of such approach? Redundant information never helped= write better code or promoted interoperability. The information needed to = process the token is available in the envelope.

On Jun 13, 2012 12:21 AM, "Manger, James H&= quot; <James.H.Manger= @team.telstra.com> wrote:
> What should happen when there is a mismatch between the "S"/= "E"/...
> prefix and the actual type of the applied algorithm?

ERROR: "A128KW" is not a supported signature algorithm


In Java, for instance, if you call
=A0javax.crypto.Cipher.getInstance("HmacSHA512")
you get
=A0Exception in thread "main" java.security.NoSuchAlgorithmExcep= tion: Cannot find any provider supporting HMACSHA512
=A0 =A0 =A0 =A0at javax.crypto.Cipher.getInstance(DashoA13*..)


JWE/JWS might have encouraged libraries to have one consolidated list of al= l possible algorithms. I suspect that is a bit unusual, however. I expect m= ost crypto libraries have separate lists for encryption, MAC, digital signa= ture, compression etc algorithms.


With draft-manger-jose-jwsec I don't reuse the "alg" element.= I use "kmg" for the key management algorithm identifier when doi= ng encryption and "sig" when signing. If you incorrectly put the = "S" prefix on an encrypted JWsec message the error is likely to b= e:
=A0ERROR: "sig" element is missing

--
James Manger
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
--14dae9340fbf7ee31704c2558413-- From tonynad@microsoft.com Wed Jun 13 01:58: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 7624F21F8652 for ; Wed, 13 Jun 2012 01:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIORLbyMJRrl for ; Wed, 13 Jun 2012 01:58:11 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 760CA21F863E for ; Wed, 13 Jun 2012 01:58:10 -0700 (PDT) Received: from mail27-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Jun 2012 08:57:05 +0000 Received: from mail27-am1 (localhost [127.0.0.1]) by mail27-am1-R.bigfish.com (Postfix) with ESMTP id A66964E0256 for ; Wed, 13 Jun 2012 08:57:04 +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: -26 X-BigFish: VS-26(zz98dI9371I936eIc85fh542M1432Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail27-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1 (MessageSwitch) id 1339577821510398_15817; Wed, 13 Jun 2012 08:57:01 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.248]) by mail27-am1.bigfish.com (Postfix) with ESMTP id 70E8180048 for ; Wed, 13 Jun 2012 08:57:01 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Jun 2012 08:57:00 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 13 Jun 2012 08:58:02 +0000 Received: from mail77-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Jun 2012 08:56:57 +0000 Received: from mail77-va3 (localhost [127.0.0.1]) by mail77-va3-R.bigfish.com (Postfix) with ESMTP id 3CA1B4C04BE for ; Wed, 13 Jun 2012 08:56:57 +0000 (UTC) Received: from mail77-va3 (localhost.localdomain [127.0.0.1]) by mail77-va3 (MessageSwitch) id 1339577814648966_12202; Wed, 13 Jun 2012 08:56:54 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.237]) by mail77-va3.bigfish.com (Postfix) with ESMTP id 9A6764A024E; Wed, 13 Jun 2012 08:56:54 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Jun 2012 08:56:53 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.180]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0152.000; Wed, 13 Jun 2012 08:57:56 +0000 From: Anthony Nadalin To: Naveen Agarwal , "Manger, James H" Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: Ac1H43jaczmQ35m0T9GUeedFjwFKggAKCvuAAADEZoAAALtOAAAjQaMAABG4XIAAFz50wA== Date: Wed, 13 Jun 2012 08:57:56 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> <01d301cd480e$bcfbc110$36f34330$@augustcellars.com> <5C6BFDE3-CD9E-4985-A68A-7BA6303E3D38@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.245.127.15] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E746077306BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$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: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: John Bradley , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 08:58:13 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E746077306BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would have to agree here, still don't see a compelling reason for the cha= nge From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nav= een Agarwal Sent: Tuesday, June 12, 2012 2:52 PM To: Manger, James H Cc: John Bradley; Jim Schaad; jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec > 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (= c.f. > "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- > separated base64url-encoded components, including a JSON object header. I don't see much value in adding a prefix as there will be two places for s= imilar information (will cause confusion) and people will do premature opti= mization while parsing the token. A visual indicator may have been useful i= f the token was for human consumption, but it is not. Also we have this working and being used in multiple places and we would li= ke to avoid breaking changes unless there is a very compelling reason. Thanks Naveen On Tue, Jun 12, 2012 at 6:24 AM, Richard L. Barnes > wrote: >>> >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of >>> John Bradley >>> Sent: Monday, June 11, 2012 12:52 PM >>> To: Manger, James H >>> Cc: jose@ietf.org >>> Subject: Re: [jose] draft-manger-jose-jwsec >>> >>> I am against adding the prefix that winds up outside the integrity >> protection. >>> >>> It is an un necessary and breaking change to many existing JWS >> deployments. >>> >>> Taking the IV out of the header removes the integrity check over it and >>> complicates parsing by JSON. >> >> It does not necessarily remove it from the integrity check. This depend= s on >> how the AEAD algorithm is defined. The stream authenticated could be th= e >> header || the iv || the message body so that it is still authenticated. > > Yes if the iv is prepended or appended to the cyphertext that would happe= n however the additional parsing and potential for interop problems is not = worth it. What's the attack you're worried about if the IV is not integrity-protected= ? --Richard > >> >>> >>> It is not using Authenticated encryption, AEAD only adds integrity not >> sender >>> authentication. >> >> The AEAD algorithm class is called Authenticated encryption with additio= nal >> data. This is the term for the art. Note that this does not imply send= er >> origination which is the additional service one wants signatures for. T= here >> is a debate if you get sender origination even with static-static key >> agreement. >> > OK if it is used as a term of art, rather than implying sender verificati= on. > > I expect that some people are going to object to being forced to do integ= rity if they intend to do signing in some other way. I personally don't s= ee it as the end of the world. > > John B. > > >>> >>> I agree that for simplicity the output of key agreement should be used = to >>> encrypt a CMK, that adds some more processing for key agreement, but= is >>> overall more consistent. >>> >>> We didn't do a okid because the WG was against my proposal to add stati= c >>> static key agreement in Paris. If feelings have changed then it shoul= d >> be in. >>> >>> Sorry for the short response I am traveling. >>> >>> John B. >>> >>> On 2012-06-11, at 4:04 PM, Manger, James H wrote: >>> >>>> I have proposed various changes to JWS/JWE/JWT recently, but not alway= s >>> with specific text changes to the existing documents. So I have had a g= o >>> putting the changes together as a vaguely complete draft spec. The resu= lt >> is: >>>> >>>> JSON Web Security Message Format (JWsec) >>>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >>>> >>>> Abstract: >>>> This document describes a cryptographic message format based on >>>> JavaScript Object Notation (JSON) and base-64 encodings to be easy >>>> for web applications to generate and process. Signed, encrypted, >>>> signed-then-encrypted, and unprotected messages are supported using >>>> symmetric and/or asymmetric keys. >>>> >>>> Changes from JWS/JWE/JWA/JWT: >>>> >>>> 1. The nickname JWsec is used for a message that can be signed, >>> encrypted, or unprotected. All three modes are covered by one ABNF >>> syntax. All three are included in the one spec. >>>> >>>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotecte= d >> (c.f. >>> "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot- >>> separated base64url-encoded components, including a JSON object header. >>>> >>>> 3. Each mode can compress the input data. >>>> >>>> 4. Only uses authenticated encryption with additional data (AEAD). >>>> >>>> 5. Unrecognized header elements MUST be ignored to allow new elements >>> to be deployed without breaking interoperability. If new elements that >>> MUST NOT be ignored are required, then a new mode can easily be defined= . >>>> >>>> 6. The initialization vector (IV) and authentication tag associated wi= th >> an >>> AEAD algorithm are prepended, and appended to the ciphertext respective= ly >>> (instead of using a header element and another dot-separated component)= . >>> I think this form is a slightly nicer. It encourages the IV and >> authentication tag >>> lengths to be fixed for an algorithm (a slightly lazy recipient will no= t >> accept >>> whatever length the last dot-separated mac field has). One side-effect = is >> that >>> the header will often remain the same for messages between two parties >>> (no varying-per-message elements), which might aid performance in some >>> situations. >>>> >>>> 7. The output of a key agreement algorithm is used to encrypt a random >>> per-message AEAD key. It is not used as the AEAD key directly. >>>> >>>> 8. Defines one media type "application/jwsec", not separate ones for >>> signed and encrypted messages. >>>> >>>> 9. Has two header elements for key identifiers: "kid", and "okid". >> "okid" is >>> used to identify the originators key. You need both when using a key >>> agreement algorithm. >>>> >>>> 10. No "typ" header element. There is a separate indicator for when on= e >>> JWsec message envelopes another (eg signed-then-encrypted message). >>>> >>>> >>>> I hope this is a useful contribution to making a great JOSE suite of >> specs. >>>> >>>> -- >>>> 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_B26C1EF377CB694EAB6BDDC8E624B6E746077306BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would have to agree her= e, still don’t see a compelling reason for the change

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Naveen Agarwal
Sent: Tuesday, June 12, 2012 2:52 PM
To: Manger, James H
Cc: John Bradley; Jim Schaad; jose@ietf.org
Subject: Re: [jose] draft-manger-jose-jwsec

 

 

> 2. A prefix ("U.", "S.", or= "E.") indicates if a message is unprotected (c.f.

> "alg":"none"), signed, or e= ncrypted. The rest (as in JWS/JWE) is dot-
> separated base64url-encoded components, including a JSON object header= .

 

I don't see much value in adding a prefix as there w= ill be two places for similar information (will cause confusion) and people= will do premature optimization while parsing the token. A visual indicator= may have been useful if the token was for human consumption, but it is not.

Also we have this working and being used in multiple= places and we would like to avoid breaking changes unless there is a very = compelling reason.

 

Thanks

 

Naveen

 

 

On Tue, Jun 12, 2012 at 6:24 AM, Richard L. Barnes &= lt;rbarnes@bbn.com= > wrote:

>>>
>>> -----Original Message-----
>>> From: jose-bounces@ie= tf.org [mailto:jose-bounces@ie= tf.org] On Behalf Of
>>> John Bradley
>>> Sent: Monday, June 11, 2012 12:52 PM
>>> To: Manger, James H
>>> Cc: jose@ietf.org
>>> Subject: Re: [jose] draft-manger-jose-jwsec
>>>
>>> I am against adding the prefix that winds up outside the integ= rity
>> protection.
>>>
>>> It is an un necessary and breaking change to many existing JWS=
>> deployments.
>>>
>>> Taking the IV out of the header removes the integrity check ov= er it and
>>> complicates parsing by JSON.
>>
>> It does not necessarily remove it from the integrity check.  = This depends on
>> how the AEAD algorithm is defined.  The stream authenticated = could be the
>> header || the iv || the message body so that it is still authentic= ated.
>
> Yes if the iv is prepended or appended to the cyphertext that would ha= ppen however the additional parsing and potential for interop problems is n= ot worth it.


What's the attack you're worried about if the IV is not integrity-protected= ?

--Richard





>
>>
>>>
>>> It is not using Authenticated encryption,  AEAD only adds= integrity not
>> sender
>>> authentication.
>>
>> The AEAD algorithm class is called Authenticated encryption with a= dditional
>> data.  This is the term for the art.  Note that this doe= s not imply sender
>> origination which is the additional service one wants signatures f= or.  There
>> is a debate if you get sender origination even with static-static = key
>> agreement.
>>
> OK if it is used as a term of art, rather than implying sender verific= ation.
>
> I expect that some people are going to object to being forced to do in= tegrity if they intend to do signing in some other way.   I personally= don't see it as the end of the world.
>
> John B.
>
>
>>>
>>> I agree that for simplicity the output of key agreement should= be used to
>>> encrypt a CMK,  that adds some  more processing for = key agreement,  but is
>>> overall more consistent.
>>>
>>> We didn't do a okid because the WG was against my proposal to = add static
>>> static key agreement in Paris.   If feelings have changed= then it should
>> be in.
>>>
>>> Sorry for the short response I am traveling.
>>>
>>> John B.
>>>
>>> On 2012-06-11, at 4:04 PM, Manger, James H wrote:
>>>
>>>> I have proposed various changes to JWS/JWE/JWT recently, b= ut not always
>>> with specific text changes to the existing documents. So I hav= e had a go
>>> putting the changes together as a vaguely complete draft spec.= The result
>> is:
>>>>
>>>> JSON Web Security Message Format (JWsec)
>>>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00
>>>>
>>>> Abstract:
>>>> This document describes a cryptographic message format bas= ed on
>>>> JavaScript Object Notation (JSON) and base-64 encodings to= be easy
>>>> for web applications to generate and process.  Signed= , encrypted,
>>>> signed-then-encrypted, and unprotected messages are suppor= ted using
>>>> symmetric and/or asymmetric keys.
>>>>
>>>> Changes from JWS/JWE/JWA/JWT:
>>>>
>>>> 1. The nickname JWsec is used for a message that can be si= gned,
>>> encrypted, or unprotected. All three modes are covered by one = ABNF
>>> syntax. All three are included in the one spec.
>>>>
>>>> 2. A prefix ("U.", "S.", or "E.&q= uot;) indicates if a message is unprotected
>> (c.f.
>>> "alg":"none"), signed, or encrypted. The r= est (as in JWS/JWE) is dot-
>>> separated base64url-encoded components, including a JSON objec= t header.
>>>>
>>>> 3. Each mode can compress the input data.
>>>>
>>>> 4. Only uses authenticated encryption with additional data= (AEAD).
>>>>
>>>> 5. Unrecognized header elements MUST be ignored to allow n= ew elements
>>> to be deployed without breaking interoperability. If new eleme= nts that
>>> MUST NOT be ignored are required, then a new mode can easily b= e defined.
>>>>
>>>> 6. The initialization vector (IV) and authentication tag a= ssociated with
>> an
>>> AEAD algorithm are prepended, and appended to the ciphertext r= espectively
>>> (instead of using a header element and another dot-separated c= omponent).
>>> I think this form is a slightly nicer. It encourages the IV an= d
>> authentication tag
>>> lengths to be fixed for an algorithm (a slightly lazy recipien= t will not
>> accept
>>> whatever length the last dot-separated mac field has). One sid= e-effect is
>> that
>>> the header will often remain the same for messages between two= parties
>>> (no varying-per-message elements), which might aid performance= in some
>>> situations.
>>>>
>>>> 7. The output of a key agreement algorithm is used to encr= ypt a random
>>> per-message AEAD key. It is not used as the AEAD key directly.=
>>>>
>>>> 8. Defines one media type "application/jwsec", n= ot separate ones for
>>> signed and encrypted messages.
>>>>
>>>> 9. Has two header elements for key identifiers: "kid&= quot;, and "okid".
>> "okid" is
>>> used to identify the originators key. You need both when using= a key
>>> agreement algorithm.
>>>>
>>>> 10. No "typ" header element. There is a separate= indicator for when one
>>> JWsec message envelopes another (eg signed-then-encrypted mess= age).
>>>>
>>>>
>>>> I hope this is a useful contribution to making a great JOS= E suite of
>> specs.
>>>>
>>>> --
>>>> 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
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E746077306BL2PRD0310MB362_-- From tonynad@microsoft.com Wed Jun 13 02:00: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 B112721F8652 for ; Wed, 13 Jun 2012 02:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJTPkbjcPOAv for ; Wed, 13 Jun 2012 02:00:25 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 116F221F863E for ; Wed, 13 Jun 2012 02:00:24 -0700 (PDT) Received: from mail16-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Jun 2012 08:59:20 +0000 Received: from mail16-tx2 (localhost [127.0.0.1]) by mail16-tx2-R.bigfish.com (Postfix) with ESMTP id F2307E0282 for ; Wed, 13 Jun 2012 08:59:19 +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: -23 X-BigFish: VS-23(zz9371I542Mzz1202h1082kzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail16-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail16-tx2 (localhost.localdomain [127.0.0.1]) by mail16-tx2 (MessageSwitch) id 1339577958880594_2234; Wed, 13 Jun 2012 08:59:18 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.235]) by mail16-tx2.bigfish.com (Postfix) with ESMTP id D23923E05D6 for ; Wed, 13 Jun 2012 08:59:18 +0000 (UTC) Received: from TK5EX14HUBC105.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; Wed, 13 Jun 2012 08:59:18 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 13 Jun 2012 09:00:20 +0000 Received: from mail77-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Jun 2012 08:59:16 +0000 Received: from mail77-tx2 (localhost [127.0.0.1]) by mail77-tx2-R.bigfish.com (Postfix) with ESMTP id 2C802404A2 for ; Wed, 13 Jun 2012 08:59:16 +0000 (UTC) Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2 (MessageSwitch) id 1339577953494029_12817; Wed, 13 Jun 2012 08:59:13 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.253]) by mail77-tx2.bigfish.com (Postfix) with ESMTP id 6BF4B460049; Wed, 13 Jun 2012 08:59:13 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Jun 2012 08:59:12 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.180]) by BL2PRD0310HT005.namprd03.prod.outlook.com ([10.255.97.40]) with mapi id 14.16.0152.000; Wed, 13 Jun 2012 09:00:15 +0000 From: Anthony Nadalin To: "Manger, James H" , Vladimir Dzhuvinov / NimbusDS Thread-Topic: [jose] draft-manger-jose-jwsec Thread-Index: AQHNSTJ2czmQ35m0T9GUeedFjwFKgpb31/4AgAAbKkA= Date: Wed, 13 Jun 2012 09:00:14 +0000 Message-ID: References: <20120613000215.cc40c4f3d92d2001859047cd8cabb9ab.5a32b7a273.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114F55FC28C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F55FC28C@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.245.127.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NIMBUSDS.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-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 09:00:25 -0000 That is an implementation specific error as there could have been an alias = set prior in JCE -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Wednesday, June 13, 2012 12:22 AM To: Vladimir Dzhuvinov / NimbusDS Cc: jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec > What should happen when there is a mismatch between the "S"/"E"/... > prefix and the actual type of the applied algorithm? ERROR: "A128KW" is not a supported signature algorithm In Java, for instance, if you call javax.crypto.Cipher.getInstance("HmacSHA512") you get Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot= find any provider supporting HMACSHA512 at javax.crypto.Cipher.getInstance(DashoA13*..) JWE/JWS might have encouraged libraries to have one consolidated list of al= l possible algorithms. I suspect that is a bit unusual, however. I expect m= ost crypto libraries have separate lists for encryption, MAC, digital signa= ture, compression etc algorithms. With draft-manger-jose-jwsec I don't reuse the "alg" element. I use "kmg" f= or the key management algorithm identifier when doing encryption and "sig" = when signing. If you incorrectly put the "S" prefix on an encrypted JWsec m= essage the error is likely to be: ERROR: "sig" element is missing -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From lef.mutualauth@gmail.com Wed Jun 13 02:46:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7C21F867B for ; Wed, 13 Jun 2012 02:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG-446tizp0v for ; Wed, 13 Jun 2012 02:46:37 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 431AD21F8668 for ; Wed, 13 Jun 2012 02:46:37 -0700 (PDT) Received: by qabj40 with SMTP id j40so1159108qab.15 for ; Wed, 13 Jun 2012 02:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=itYxMJnoOMmwJgSCNB7BrN/KJ9P/bkjg7lx8wVx2AtQ=; b=F+XzCbxqViebR08PDRDTrvfKj+sh1XQPoWsBhMP65M3ZAxbpjMR4Tz6FR9obaCUJy0 oA/W5ghRJ4jbDIe5zxNyvfyitngVWcXV4ia4gsIwR50VKgj5cC4SzVvXk1CegRgQLOS3 gq4hwiMC+zHN4YCErV4S+B+rD7u57Xa5Q4IYjpPXP3A6tUH3t8CVuaYYaVcrwCqQ4SzS gkiqEM3ctTcF4bMWZ+3zMkgYMqIGm1On2DMqna7tTEC1VAisU3k+u4yzHm0yWB0n+/Bb F7cY3ptVenNtNieif2pqSW6zbSvQVGdMiwE1Vk4iTABH08TfjWBGumZtQclveSasRhRA 1pSA== MIME-Version: 1.0 Received: by 10.224.199.6 with SMTP id eq6mr25516437qab.90.1339580796304; Wed, 13 Jun 2012 02:46:36 -0700 (PDT) Received: by 10.229.97.209 with HTTP; Wed, 13 Jun 2012 02:46:35 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <9F5568F5-9F98-4C27-B026-FD40288BE34A@ve7jtb.com> Date: Wed, 13 Jun 2012 18:46:35 +0900 Message-ID: From: "HAYASHI, Tatsuya" To: Chuck Mortimore , "jose@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John Bradley , "Manger, James H" Subject: Re: [jose] draft-manger-jose-jwsec 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, 13 Jun 2012 09:46:38 -0000 +1 I'm not sure this I-D has enough advantages to adopt at this time, especially when thinking about current deployments. (Besides, changing syntax will be painful as an implementer.) Tatsuya On Tue, Jun 12, 2012 at 7:48 AM, Chuck Mortimore wrote: > +1 > > - would be concerned if this was outside the integrity check > - in abstract the proposal looks fine, but I'm not sure there is enough i= ncremental value vs cost of breaking existing deployments > > -cmort > > On Jun 11, 2012, at 12:51 PM, John Bradley wrote: > >> I am against adding the prefix that winds up outside the integrity prote= ction. >> >> It is an un necessary and breaking change to many existing JWS deploymen= ts. >> >> Taking the IV out of the header removes the integrity check over it and = complicates parsing by JSON. >> >> It is not using Authenticated encryption, =A0AEAD only adds integrity no= t sender authentication. >> >> I agree that for simplicity the output of key agreement should be used t= o encrypt a CMK, =A0that adds some =A0more processing for key agreement, = =A0but is overall more consistent. >> >> We didn't do a okid because the WG was against my proposal to add static= static key agreement in Paris. =A0 If feelings have changed then it should= be in. >> >> Sorry for the short response I am traveling. >> >> John B. >> >> On 2012-06-11, at 4:04 PM, Manger, James H wrote: >> >>> I have proposed various changes to JWS/JWE/JWT recently, but not always= with specific text changes to the existing documents. So I have had a go p= utting the changes together as a vaguely complete draft spec. The result is= : >>> >>> JSON Web Security Message Format (JWsec) >>> http://tools.ietf.org/html/draft-manger-jose-jwsec-00 >>> >>> Abstract: >>> =A0This document describes a cryptographic message format based on >>> =A0JavaScript Object Notation (JSON) and base-64 encodings to be easy >>> =A0for web applications to generate and process. =A0Signed, encrypted, >>> =A0signed-then-encrypted, and unprotected messages are supported using >>> =A0symmetric and/or asymmetric keys. >>> >>> Changes from JWS/JWE/JWA/JWT: >>> >>> 1. The nickname JWsec is used for a message that can be signed, encrypt= ed, or unprotected. All three modes are covered by one ABNF syntax. All thr= ee are included in the one spec. >>> >>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected= (c.f. "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot= -separated base64url-encoded components, including a JSON object header. >>> >>> 3. Each mode can compress the input data. >>> >>> 4. Only uses authenticated encryption with additional data (AEAD). >>> >>> 5. Unrecognized header elements MUST be ignored to allow new elements t= o be deployed without breaking interoperability. If new elements that MUST = NOT be ignored are required, then a new mode can easily be defined. >>> >>> 6. The initialization vector (IV) and authentication tag associated wit= h an AEAD algorithm are prepended, and appended to the ciphertext respectiv= ely (instead of using a header element and another dot-separated component)= . I think this form is a slightly nicer. It encourages the IV and authentic= ation tag lengths to be fixed for an algorithm (a slightly lazy recipient w= ill not accept whatever length the last dot-separated mac field has). One s= ide-effect is that the header will often remain the same for messages betwe= en two parties (no varying-per-message elements), which might aid performan= ce in some situations. >>> >>> 7. The output of a key agreement algorithm is used to encrypt a random = per-message AEAD key. It is not used as the AEAD key directly. >>> >>> 8. Defines one media type "application/jwsec", not separate ones for si= gned and encrypted messages. >>> >>> 9. Has two header elements for key identifiers: "kid", and "okid". "oki= d" is used to identify the originators key. You need both when using a key = agreement algorithm. >>> >>> 10. No "typ" header element. There is a separate indicator for when one= JWsec message envelopes another (eg signed-then-encrypted message). >>> >>> >>> I hope this is a useful contribution to making a great JOSE suite of sp= ecs. >>> >>> -- >>> 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 HAYASHI, Tatsuya Lepidum Co. Ltd. From rbarnes@bbn.com Fri Jun 15 14:08: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 4791611E80C4 for ; Fri, 15 Jun 2012 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfJ5LBztMeCx for ; Fri, 15 Jun 2012 14:08:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 415CF11E8088 for ; Fri, 15 Jun 2012 14:08:18 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:56808) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sfdk4-000FL5-UQ for jose@ietf.org; Fri, 15 Jun 2012 17:07:40 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2012 17:08:17 -0400 References: <20120615205609.5363.19252.idtracker@ietfa.amsl.com> To: jose@ietf.org Message-Id: <8F2950A0-CF95-46D3-812B-236AD24B554E@bbn.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 21:08:19 -0000 Dear JOSE WG, Like Mr. Manger, once I finally got around to doing a thorough review of = the JW* specs, I was kind of puzzled by some of the design decisions. = So I also went through and wrote an alternative format, this time taking = a more of a cue from CMS. A link to the document is below. Summary of differences: o JSMS is pure JSON, whereas in JWE and JWS only the header parameters are represented in JSON. o JSMS allows for full algorithm agility in key agreement, while JWE only allows ECDH-ES. o JSMS supports multiple recipients for EncryptedData and AuthenticatedData objects via the inclusion of multiple WrappedKey objects. Sending a JWE to multiple recipients requires re- encryption of the entire object for each recipient. o The signature and MAC functions of the JWS object are separated into SignedData and AuthenticatedData JSMS objects. o JSMS parameters are not integrity-protected, as they are in JWE and JWS. o The "typ" and "zip" parameters are not defined in JSMS, but could be added without significant change. o JSMS requires that recipients MUST ignore unknown header parameters, in order to facilitate extensibility. I've also thrown together an initial JavaScript implementation (based on = NodeJS for some python crypto glue), which is on github: Comments are very welcome. =20 Thanks, --Richard Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-barnes-jose-jsms-00.txt > Date: June 15, 2012 4:56:09 PM EDT > To: rbarnes@bbn.com >=20 >=20 > A new version of I-D, draft-barnes-jose-jsms-00.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. >=20 > Filename: draft-barnes-jose-jsms > Revision: 00 > Title: JavaScript Message Security Format > Creation date: 2012-06-15 > WG ID: Individual Submission > Number of pages: 25 > URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt > Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >=20 >=20 > Abstract: > Many applications require the ability to send cryptographically > secured messages. While the IETF has defined a number of formats = for > such messages (e.g. CMS) those formats use encodings which are not > easy to use in modern applications. This document describes the > JavaScript Message Security format (JSMS), a new cryptographic > message format which is based on JavaScript Object Notation (JSON) > and thus is easy for many applications to generate and parse. >=20 >=20 >=20 >=20 > The IETF Secretariat From Michael.Jones@microsoft.com Fri Jun 15 14:43:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCDC11E80DF for ; Fri, 15 Jun 2012 14:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.257 X-Spam-Level: X-Spam-Status: No, score=-5.257 tagged_above=-999 required=5 tests=[AWL=1.342, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gBgWtpzqOai for ; Fri, 15 Jun 2012 14:43:37 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id A4F3E11E80CE for ; Fri, 15 Jun 2012 14:43:37 -0700 (PDT) Received: from mail18-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 21:42:26 +0000 Received: from mail18-tx2 (localhost [127.0.0.1]) by mail18-tx2-R.bigfish.com (Postfix) with ESMTP id F3B59420917; Fri, 15 Jun 2012 21:42:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zf7Iz9371I936eI542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail18-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=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail18-tx2 (localhost.localdomain [127.0.0.1]) by mail18-tx2 (MessageSwitch) id 1339796544558716_32058; Fri, 15 Jun 2012 21:42:24 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.241]) by mail18-tx2.bigfish.com (Postfix) with ESMTP id 84FD5160048; Fri, 15 Jun 2012 21:42:24 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 21:42:24 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Fri, 15 Jun 2012 21:43:34 +0000 From: Mike Jones To: "Richard L. Barnes" , "jose@ietf.org" Thread-Topic: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: Ac1LP+fspDEUYmahQDWRKCnENGlR3w== Date: Fri, 15 Jun 2012 21:43:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 21:43:38 -0000 Hi Richard, If you're puzzled by specific design decisions in the JOSE documents, I enc= ourage you to ask about them on the list. The documents have significant h= istory going back to mid-2010 when convergence discussions started among pe= ople with four different JSON signing & encryption proposals. JWT and the = current JOSE specs and implementations are the result. I realize that not = all the JOSE participants were part of those discussions from the beginning= (although many were) and so teasing out the rationale for specific decisio= ns might help people better understand the choices made, and hopefully ther= eby increase consensus behind the eventual working group choices. If the list that you're puzzled by is the bulleted list below, maybe we can= start a discussion on that basis. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Friday, June 15, 2012 2:08 PM To: jose@ietf.org Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00= .txt Dear JOSE WG, Like Mr. Manger, once I finally got around to doing a thorough review of th= e JW* specs, I was kind of puzzled by some of the design decisions. So I a= lso went through and wrote an alternative format, this time taking a more o= f a cue from CMS. A link to the document is below. Summary of differences: o JSMS is pure JSON, whereas in JWE and JWS only the header parameters are represented in JSON. o JSMS allows for full algorithm agility in key agreement, while JWE only allows ECDH-ES. o JSMS supports multiple recipients for EncryptedData and AuthenticatedData objects via the inclusion of multiple WrappedKey objects. Sending a JWE to multiple recipients requires re- encryption of the entire object for each recipient. o The signature and MAC functions of the JWS object are separated into SignedData and AuthenticatedData JSMS objects. o JSMS parameters are not integrity-protected, as they are in JWE and JWS. o The "typ" and "zip" parameters are not defined in JSMS, but could be added without significant change. o JSMS requires that recipients MUST ignore unknown header parameters, in order to facilitate extensibility. I've also thrown together an initial JavaScript implementation (based on No= deJS for some python crypto glue), which is on github: Comments are very welcome. =20 Thanks, --Richard Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-barnes-jose-jsms-00.txt > Date: June 15, 2012 4:56:09 PM EDT > To: rbarnes@bbn.com >=20 >=20 > A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 > successfully submitted by Richard Barnes and posted to the IETF=20 > repository. >=20 > Filename: draft-barnes-jose-jsms > Revision: 00 > Title: JavaScript Message Security Format > Creation date: 2012-06-15 > WG ID: Individual Submission > Number of pages: 25 > URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-js= ms-00.txt > Status: http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >=20 >=20 > Abstract: > Many applications require the ability to send cryptographically > secured messages. While the IETF has defined a number of formats for > such messages (e.g. CMS) those formats use encodings which are not > easy to use in modern applications. This document describes the > JavaScript Message Security format (JSMS), a new cryptographic > message format which is based on JavaScript Object Notation (JSON) > and thus is easy for many applications to generate and parse. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jun 15 14:47:34 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 7BEB911E80E5 for ; Fri, 15 Jun 2012 14:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1bYIcxht0FJ for ; Fri, 15 Jun 2012 14:47:33 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 451C611E80CE for ; Fri, 15 Jun 2012 14:47:33 -0700 (PDT) Received: from mail114-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 21:46:21 +0000 Received: from mail114-va3 (localhost [127.0.0.1]) by mail114-va3-R.bigfish.com (Postfix) with ESMTP id 76A0A602DE; Fri, 15 Jun 2012 21:46:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zf7Iz9371I936eI542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail114-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=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail114-va3 (localhost.localdomain [127.0.0.1]) by mail114-va3 (MessageSwitch) id 1339796779332558_14235; Fri, 15 Jun 2012 21:46:19 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.248]) by mail114-va3.bigfish.com (Postfix) with ESMTP id 4E2EB38003F; Fri, 15 Jun 2012 21:46:19 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 21:46:19 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 21:47:28 +0000 From: Mike Jones To: "Richard L. Barnes" , "jose@ietf.org" Thread-Topic: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: Ac1LP+fspDEUYmahQDWRKCnENGlR3wAAGyrA Date: Fri, 15 Jun 2012 21:47:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665507BE@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 21:47:34 -0000 P.S. I should add that since the initial discussions, many good ideas were= also picked up from Eric & Joe's JSMS draft and incorporated into the JOSE= specs - especially JWE and JWA. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Friday, June 15, 2012 2:44 PM To: Richard L. Barnes; jose@ietf.org Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsm= s-00.txt Hi Richard, If you're puzzled by specific design decisions in the JOSE documents, I enc= ourage you to ask about them on the list. The documents have significant h= istory going back to mid-2010 when convergence discussions started among pe= ople with four different JSON signing & encryption proposals. JWT and the = current JOSE specs and implementations are the result. I realize that not = all the JOSE participants were part of those discussions from the beginning= (although many were) and so teasing out the rationale for specific decisio= ns might help people better understand the choices made, and hopefully ther= eby increase consensus behind the eventual working group choices. If the list that you're puzzled by is the bulleted list below, maybe we can= start a discussion on that basis. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Friday, June 15, 2012 2:08 PM To: jose@ietf.org Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00= .txt Dear JOSE WG, Like Mr. Manger, once I finally got around to doing a thorough review of th= e JW* specs, I was kind of puzzled by some of the design decisions. So I a= lso went through and wrote an alternative format, this time taking a more o= f a cue from CMS. A link to the document is below. Summary of differences: o JSMS is pure JSON, whereas in JWE and JWS only the header parameters are represented in JSON. o JSMS allows for full algorithm agility in key agreement, while JWE only allows ECDH-ES. o JSMS supports multiple recipients for EncryptedData and AuthenticatedData objects via the inclusion of multiple WrappedKey objects. Sending a JWE to multiple recipients requires re- encryption of the entire object for each recipient. o The signature and MAC functions of the JWS object are separated into SignedData and AuthenticatedData JSMS objects. o JSMS parameters are not integrity-protected, as they are in JWE and JWS. o The "typ" and "zip" parameters are not defined in JSMS, but could be added without significant change. o JSMS requires that recipients MUST ignore unknown header parameters, in order to facilitate extensibility. I've also thrown together an initial JavaScript implementation (based on No= deJS for some python crypto glue), which is on github: Comments are very welcome. =20 Thanks, --Richard Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-barnes-jose-jsms-00.txt > Date: June 15, 2012 4:56:09 PM EDT > To: rbarnes@bbn.com >=20 >=20 > A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 > successfully submitted by Richard Barnes and posted to the IETF=20 > repository. >=20 > Filename: draft-barnes-jose-jsms > Revision: 00 > Title: JavaScript Message Security Format > Creation date: 2012-06-15 > WG ID: Individual Submission > Number of pages: 25 > URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-js= ms-00.txt > Status: http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >=20 >=20 > Abstract: > Many applications require the ability to send cryptographically > secured messages. While the IETF has defined a number of formats for > such messages (e.g. CMS) those formats use encodings which are not > easy to use in modern applications. This document describes the > JavaScript Message Security format (JSMS), a new cryptographic > message format which is based on JavaScript Object Notation (JSON) > and thus is easy for many applications to generate and parse. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ 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 rbarnes@bbn.com Fri Jun 15 15:00:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A7421F8552 for ; Fri, 15 Jun 2012 15:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AtcaXB3JHqS for ; Fri, 15 Jun 2012 15:00:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEA121F8551 for ; Fri, 15 Jun 2012 15:00:21 -0700 (PDT) Received: from [128.89.253.96] (port=57178) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SfeYQ-000FvJ-1i; Fri, 15 Jun 2012 17:59:42 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 15 Jun 2012 18:00:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 22:00:24 -0000 Ok, so maybe I should have phrased my lead-in differently. IMO, the = current JW* specs are deficient in several ways, e.g.: -- Not being JSON -- Not supporting multiple recipients -- Lacking clear distinctions between signing and MAC -- Lacking clear processing instructions for different key establishment = modalities -- Lack of clear typing of objects -- Lack of versioning for future extensibility Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. Cheers, --Richard On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > Hi Richard, >=20 > If you're puzzled by specific design decisions in the JOSE documents, = I encourage you to ask about them on the list. The documents have = significant history going back to mid-2010 when convergence discussions = started among people with four different JSON signing & encryption = proposals. JWT and the current JOSE specs and implementations are the = result. I realize that not all the JOSE participants were part of those = discussions from the beginning (although many were) and so teasing out = the rationale for specific decisions might help people better understand = the choices made, and hopefully thereby increase consensus behind the = eventual working group choices. >=20 > If the list that you're puzzled by is the bulleted list below, maybe = we can start a discussion on that basis. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L. Barnes > Sent: Friday, June 15, 2012 2:08 PM > To: jose@ietf.org > Subject: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > Dear JOSE WG, >=20 > Like Mr. Manger, once I finally got around to doing a thorough review = of the JW* specs, I was kind of puzzled by some of the design decisions. = So I also went through and wrote an alternative format, this time = taking a more of a cue from CMS. A link to the document is below. >=20 > Summary of differences: >=20 > o JSMS is pure JSON, whereas in JWE and JWS only the header > parameters are represented in JSON. >=20 > o JSMS allows for full algorithm agility in key agreement, while = JWE > only allows ECDH-ES. >=20 > o JSMS supports multiple recipients for EncryptedData and > AuthenticatedData objects via the inclusion of multiple = WrappedKey > objects. Sending a JWE to multiple recipients requires re- > encryption of the entire object for each recipient. >=20 > o The signature and MAC functions of the JWS object are separated > into SignedData and AuthenticatedData JSMS objects. >=20 > o JSMS parameters are not integrity-protected, as they are in JWE > and JWS. >=20 > o The "typ" and "zip" parameters are not defined in JSMS, but could > be added without significant change. >=20 > o JSMS requires that recipients MUST ignore unknown header > parameters, in order to facilitate extensibility. >=20 > I've also thrown together an initial JavaScript implementation (based = on NodeJS for some python crypto glue), which is on github: > >=20 > Comments are very welcome. =20 >=20 > Thanks, > --Richard >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >> Date: June 15, 2012 4:56:09 PM EDT >> To: rbarnes@bbn.com >>=20 >>=20 >> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >> successfully submitted by Richard Barnes and posted to the IETF=20 >> repository. >>=20 >> Filename: draft-barnes-jose-jsms >> Revision: 00 >> Title: JavaScript Message Security Format >> Creation date: 2012-06-15 >> WG ID: Individual Submission >> Number of pages: 25 >> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>=20 >>=20 >> Abstract: >> Many applications require the ability to send cryptographically >> secured messages. While the IETF has defined a number of formats = for >> such messages (e.g. CMS) those formats use encodings which are not >> easy to use in modern applications. This document describes the >> JavaScript Message Security format (JSMS), a new cryptographic >> message format which is based on JavaScript Object Notation (JSON) >> and thus is easy for many applications to generate and parse. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jun 15 15:31: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 A7D0421F8469 for ; Fri, 15 Jun 2012 15:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OgvqtebW1qL for ; Fri, 15 Jun 2012 15:31:51 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3921F8464 for ; Fri, 15 Jun 2012 15:31:50 -0700 (PDT) Received: from mail77-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 22:30:32 +0000 Received: from mail77-ch1 (localhost [127.0.0.1]) by mail77-ch1-R.bigfish.com (Postfix) with ESMTP id 71BE7380283; Fri, 15 Jun 2012 22:30:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zf7Iz98dI9371I936eI542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail77-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=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail77-ch1 (localhost.localdomain [127.0.0.1]) by mail77-ch1 (MessageSwitch) id 1339799430429530_12866; Fri, 15 Jun 2012 22:30:30 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail77-ch1.bigfish.com (Postfix) with ESMTP id 675922A0046; Fri, 15 Jun 2012 22:30:30 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 22:30:30 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 22:31:40 +0000 From: Mike Jones To: "Richard L. Barnes" Thread-Topic: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: Ac1LP+fspDEUYmahQDWRKCnENGlR3wAAlemAAAAMKRA= Date: Fri, 15 Jun 2012 22:31:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> In-Reply-To: <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 22:31:52 -0000 Fair enough. I'll briefly respond to each in turn. Before doing so, I'll = say that I'm writing in the spirit of trying to increase mutual understandi= ng and consensus, rather than taking the point of view that the status quo = is the only reasonable outcome. -- Not being JSON This was by design, so that the results are URL-safe. This is required, fo= r instance, for them to be used as OAuth Bearer Tokens. At the request of = the working group, closely related pure-JSON drafts were also published. S= ee: http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializatio= n-01 and http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializati= on-01 Use them if you prefer if they better suit your use cases. They could be a= dopted as working group documents, if there's interest. -- Not supporting multiple recipients The JSON serialization drafts above do, again, in response to use cases pre= sented by the working group. -- Lacking clear distinctions between signing and MAC Functionally, these are very similar operations, at least from an implement= ation perspective, so it's not clear that making a clear distinction would = help either developers or adoption in any practical way. They achieve over= lapping, but admittedly sometimes different goals. I believe that develope= rs can be trusted to use the algorithms that achieve their applications' go= als without making a hard distinction between the two. But I'd be interest= ed in hearing your thoughts on why you believe a brighter-line distinction = might be useful or necessary. -- Lacking clear processing instructions for different key establishment mo= dalities This seems like an area where the existing drafts could be refined to add d= escriptions for additional establishment modalities, possibly based upon yo= ur ideas and descriptions, should the working group decide to do so. What = additional modalities do you have use cases for that you believe are not ac= hievable or straightforward with the existing drafts? The existing modalit= ies supported are largely those that existing developers had told us they n= eeded and draw both from the precursor draft-jones-json-web-* documents and= draft-rescorla-jsms. Bear in mind that the balance that the current drafts try to strike is keep= ing the Mandatory to Implement (MTI) feature footprint small enough that de= velopers, including Web developers, are likely to adopt the specs, while st= ill providing enough functionality to make them generally useful. As in an= y balance, it's often possible to shift things a bit and still maintain the= balance, but I'd like people to keep the ubiquitous adoption goal front-an= d-center when proposing additional functionality. Ubiquitous deployment and usefulness trump theoretical completeness. (Just= look at XMLDSIG and XMLENC to understand that!)=20 -- Lack of clear typing of objects Most JSON documents aren't clearly typed; instead, developers and implement= ations understand from context what the meaning of each field is. XML is c= learly typed, but developers are voting with their feet by moving to JSON. What practical advantages resulting from overlaying a typing infrastructure= on JSON do you believe are worth the potential costs of doing so? BTW, I'= m not opposed to having a JSON schema description of the JOSE JSON data str= uctures like JSMS did in http://tools.ietf.org/html/draft-rescorla-jsms-00#= appendix-A, but I'll remark that this an informative tool, not a normative = one. -- Lack of versioning for future extensibility An optional version field could be added if the working group desires, howe= ver the last time the working group discussed it, they decided not to do so= . Rather, specs like this effectively become "versioned" when revised in a= way that new fields are added. If you understand the new fields, you supp= ort that new version. (Note that this is independent of whether there is a= version number field, which according to some participants in the previous= discussion, they regarded as therefore being redundant information.) I'm not religious about not having a version number field, but often "less = is more". Best wishes, -- Mike -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Friday, June 15, 2012 3:00 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsm= s-00.txt Ok, so maybe I should have phrased my lead-in differently. IMO, the curren= t JW* specs are deficient in several ways, e.g.: -- Not being JSON -- Not supporting multiple recipients -- Lacking clear distinctions between signing and MAC -- Lacking clear processing instructions for different key establishment mo= dalities -- Lack of clear typing of objects -- Lack of versioning for future extensibility Looking at the current specs, it didn't seem to me that it would be simple = to adapt them to address these deficiencies. So I just did a re-write. If= you think they can be addressed within the current framework, please expla= in. I just found it simpler to start from whole cloth. Cheers, --Richard On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > Hi Richard, >=20 > If you're puzzled by specific design decisions in the JOSE documents, I e= ncourage you to ask about them on the list. The documents have significant= history going back to mid-2010 when convergence discussions started among = people with four different JSON signing & encryption proposals. JWT and th= e current JOSE specs and implementations are the result. I realize that no= t all the JOSE participants were part of those discussions from the beginni= ng (although many were) and so teasing out the rationale for specific decis= ions might help people better understand the choices made, and hopefully th= ereby increase consensus behind the eventual working group choices. >=20 > If the list that you're puzzled by is the bulleted list below, maybe we c= an start a discussion on that basis. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Richard L. Barnes > Sent: Friday, June 15, 2012 2:08 PM > To: jose@ietf.org > Subject: [jose] Fwd: New Version Notification for=20 > draft-barnes-jose-jsms-00.txt >=20 > Dear JOSE WG, >=20 > Like Mr. Manger, once I finally got around to doing a thorough review of = the JW* specs, I was kind of puzzled by some of the design decisions. So I= also went through and wrote an alternative format, this time taking a more= of a cue from CMS. A link to the document is below. >=20 > Summary of differences: >=20 > o JSMS is pure JSON, whereas in JWE and JWS only the header > parameters are represented in JSON. >=20 > o JSMS allows for full algorithm agility in key agreement, while JWE > only allows ECDH-ES. >=20 > o JSMS supports multiple recipients for EncryptedData and > AuthenticatedData objects via the inclusion of multiple WrappedKey > objects. Sending a JWE to multiple recipients requires re- > encryption of the entire object for each recipient. >=20 > o The signature and MAC functions of the JWS object are separated > into SignedData and AuthenticatedData JSMS objects. >=20 > o JSMS parameters are not integrity-protected, as they are in JWE > and JWS. >=20 > o The "typ" and "zip" parameters are not defined in JSMS, but could > be added without significant change. >=20 > o JSMS requires that recipients MUST ignore unknown header > parameters, in order to facilitate extensibility. >=20 > I've also thrown together an initial JavaScript implementation (based on = NodeJS for some python crypto glue), which is on github: > >=20 > Comments are very welcome. =20 >=20 > Thanks, > --Richard >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >> Date: June 15, 2012 4:56:09 PM EDT >> To: rbarnes@bbn.com >>=20 >>=20 >> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >> successfully submitted by Richard Barnes and posted to the IETF=20 >> repository. >>=20 >> Filename: draft-barnes-jose-jsms >> Revision: 00 >> Title: JavaScript Message Security Format >> Creation date: 2012-06-15 >> WG ID: Individual Submission >> Number of pages: 25 >> URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-j= sms-00.txt >> Status: http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>=20 >>=20 >> Abstract: >> Many applications require the ability to send cryptographically =20 >> secured messages. While the IETF has defined a number of formats for =20 >> such messages (e.g. CMS) those formats use encodings which are not =20 >> easy to use in modern applications. This document describes the =20 >> JavaScript Message Security format (JSMS), a new cryptographic =20 >> message format which is based on JavaScript Object Notation (JSON) =20 >> and thus is easy for many applications to generate and parse. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jun 15 17:08: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 63DDB11E8108 for ; Fri, 15 Jun 2012 17:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.303 X-Spam-Level: X-Spam-Status: No, score=-5.303 tagged_above=-999 required=5 tests=[AWL=1.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVrR1rDYsSJT for ; Fri, 15 Jun 2012 17:07:59 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8934B11E8103 for ; Fri, 15 Jun 2012 17:07:58 -0700 (PDT) Received: from mail67-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Jun 2012 00:06:46 +0000 Received: from mail67-tx2 (localhost [127.0.0.1]) by mail67-tx2-R.bigfish.com (Postfix) with ESMTP id 1C6D13A039B; Sat, 16 Jun 2012 00:06:46 +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: -31 X-BigFish: VS-31(zf7Iz98dI9371I936eI542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail67-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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail67-tx2 (localhost.localdomain [127.0.0.1]) by mail67-tx2 (MessageSwitch) id 1339805204154610_20896; Sat, 16 Jun 2012 00:06:44 +0000 (UTC) Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.250]) by mail67-tx2.bigfish.com (Postfix) with ESMTP id 2184E30004F; Sat, 16 Jun 2012 00:06:44 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Jun 2012 00:06:43 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Sat, 16 Jun 2012 00:07:53 +0000 From: Mike Jones To: "Richard L. Barnes" Thread-Topic: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: Ac1LP+fspDEUYmahQDWRKCnENGlR3wAAlemAAAAMKRAABCTLAA== Date: Sat, 16 Jun 2012 00:07:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366551A9E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 00:08:01 -0000 Hi Richard, Since your message has been kicking around in the back of my mind, I'll add= one more data point on the "Not being JSON" comment. As the designers of = JWT and the resulting JOSE specs saw it, there were two clear choices to ab= le to sign/encrypt JSON data structures: (1) Define a canonicalization algorithm and always operate on the canonica= l forms (2) Base64 encode a representation of the data structure to preserve the p= recise representation XML Canonicalization has proven to be a horror, leading to more interoperab= ility problems than any other aspect of XMLDSIG, XMLENC, SAML, or WS-*. We chose #2. :-) -- Mike -----Original Message----- From: Mike Jones=20 Sent: Friday, June 15, 2012 3:32 PM To: 'Richard L. Barnes' Cc: jose@ietf.org Subject: RE: [jose] Fwd: New Version Notification for draft-barnes-jose-jsm= s-00.txt Fair enough. I'll briefly respond to each in turn. Before doing so, I'll = say that I'm writing in the spirit of trying to increase mutual understandi= ng and consensus, rather than taking the point of view that the status quo = is the only reasonable outcome. -- Not being JSON This was by design, so that the results are URL-safe. This is required, fo= r instance, for them to be used as OAuth Bearer Tokens. At the request of = the working group, closely related pure-JSON drafts were also published. S= ee: http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializatio= n-01 and http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializati= on-01 Use them if you prefer if they better suit your use cases. They could be a= dopted as working group documents, if there's interest. -- Not supporting multiple recipients The JSON serialization drafts above do, again, in response to use cases pre= sented by the working group. -- Lacking clear distinctions between signing and MAC Functionally, these are very similar operations, at least from an implement= ation perspective, so it's not clear that making a clear distinction would = help either developers or adoption in any practical way. They achieve over= lapping, but admittedly sometimes different goals. I believe that develope= rs can be trusted to use the algorithms that achieve their applications' go= als without making a hard distinction between the two. But I'd be interest= ed in hearing your thoughts on why you believe a brighter-line distinction = might be useful or necessary. -- Lacking clear processing instructions for different key establishment mo= dalities This seems like an area where the existing drafts could be refined to add d= escriptions for additional establishment modalities, possibly based upon yo= ur ideas and descriptions, should the working group decide to do so. What = additional modalities do you have use cases for that you believe are not ac= hievable or straightforward with the existing drafts? The existing modalit= ies supported are largely those that existing developers had told us they n= eeded and draw both from the precursor draft-jones-json-web-* documents and= draft-rescorla-jsms. Bear in mind that the balance that the current drafts try to strike is keep= ing the Mandatory to Implement (MTI) feature footprint small enough that de= velopers, including Web developers, are likely to adopt the specs, while st= ill providing enough functionality to make them generally useful. As in an= y balance, it's often possible to shift things a bit and still maintain the= balance, but I'd like people to keep the ubiquitous adoption goal front-an= d-center when proposing additional functionality. Ubiquitous deployment and usefulness trump theoretical completeness. (Just= look at XMLDSIG and XMLENC to understand that!)=20 -- Lack of clear typing of objects Most JSON documents aren't clearly typed; instead, developers and implement= ations understand from context what the meaning of each field is. XML is c= learly typed, but developers are voting with their feet by moving to JSON. What practical advantages resulting from overlaying a typing infrastructure= on JSON do you believe are worth the potential costs of doing so? BTW, I'= m not opposed to having a JSON schema description of the JOSE JSON data str= uctures like JSMS did in http://tools.ietf.org/html/draft-rescorla-jsms-00#= appendix-A, but I'll remark that this an informative tool, not a normative = one. -- Lack of versioning for future extensibility An optional version field could be added if the working group desires, howe= ver the last time the working group discussed it, they decided not to do so= . Rather, specs like this effectively become "versioned" when revised in a= way that new fields are added. If you understand the new fields, you supp= ort that new version. (Note that this is independent of whether there is a= version number field, which according to some participants in the previous= discussion, they regarded as therefore being redundant information.) I'm not religious about not having a version number field, but often "less = is more". Best wishes, -- Mike -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Friday, June 15, 2012 3:00 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsm= s-00.txt Ok, so maybe I should have phrased my lead-in differently. IMO, the curren= t JW* specs are deficient in several ways, e.g.: -- Not being JSON -- Not supporting multiple recipients -- Lacking clear distinctions between signing and MAC -- Lacking clear processing instructions for different key establishment mo= dalities -- Lack of clear typing of objects -- Lack of versioning for future extensibility Looking at the current specs, it didn't seem to me that it would be simple = to adapt them to address these deficiencies. So I just did a re-write. If= you think they can be addressed within the current framework, please expla= in. I just found it simpler to start from whole cloth. Cheers, --Richard On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > Hi Richard, >=20 > If you're puzzled by specific design decisions in the JOSE documents, I e= ncourage you to ask about them on the list. The documents have significant= history going back to mid-2010 when convergence discussions started among = people with four different JSON signing & encryption proposals. JWT and th= e current JOSE specs and implementations are the result. I realize that no= t all the JOSE participants were part of those discussions from the beginni= ng (although many were) and so teasing out the rationale for specific decis= ions might help people better understand the choices made, and hopefully th= ereby increase consensus behind the eventual working group choices. >=20 > If the list that you're puzzled by is the bulleted list below, maybe we c= an start a discussion on that basis. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Richard L. Barnes > Sent: Friday, June 15, 2012 2:08 PM > To: jose@ietf.org > Subject: [jose] Fwd: New Version Notification for=20 > draft-barnes-jose-jsms-00.txt >=20 > Dear JOSE WG, >=20 > Like Mr. Manger, once I finally got around to doing a thorough review of = the JW* specs, I was kind of puzzled by some of the design decisions. So I= also went through and wrote an alternative format, this time taking a more= of a cue from CMS. A link to the document is below. >=20 > Summary of differences: >=20 > o JSMS is pure JSON, whereas in JWE and JWS only the header > parameters are represented in JSON. >=20 > o JSMS allows for full algorithm agility in key agreement, while JWE > only allows ECDH-ES. >=20 > o JSMS supports multiple recipients for EncryptedData and > AuthenticatedData objects via the inclusion of multiple WrappedKey > objects. Sending a JWE to multiple recipients requires re- > encryption of the entire object for each recipient. >=20 > o The signature and MAC functions of the JWS object are separated > into SignedData and AuthenticatedData JSMS objects. >=20 > o JSMS parameters are not integrity-protected, as they are in JWE > and JWS. >=20 > o The "typ" and "zip" parameters are not defined in JSMS, but could > be added without significant change. >=20 > o JSMS requires that recipients MUST ignore unknown header > parameters, in order to facilitate extensibility. >=20 > I've also thrown together an initial JavaScript implementation (based on = NodeJS for some python crypto glue), which is on github: > >=20 > Comments are very welcome. =20 >=20 > Thanks, > --Richard >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >> Date: June 15, 2012 4:56:09 PM EDT >> To: rbarnes@bbn.com >>=20 >>=20 >> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >> successfully submitted by Richard Barnes and posted to the IETF=20 >> repository. >>=20 >> Filename: draft-barnes-jose-jsms >> Revision: 00 >> Title: JavaScript Message Security Format >> Creation date: 2012-06-15 >> WG ID: Individual Submission >> Number of pages: 25 >> URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-j= sms-00.txt >> Status: http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>=20 >>=20 >> Abstract: >> Many applications require the ability to send cryptographically=20 >> secured messages. While the IETF has defined a number of formats for=20 >> such messages (e.g. CMS) those formats use encodings which are not=20 >> easy to use in modern applications. This document describes the=20 >> JavaScript Message Security format (JSMS), a new cryptographic=20 >> message format which is based on JavaScript Object Notation (JSON)=20 >> and thus is easy for many applications to generate and parse. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From breno@google.com Fri Jun 15 17:22: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 7FC6721F84A5 for ; Fri, 15 Jun 2012 17:22:49 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKVCA-2JxP3w for ; Fri, 15 Jun 2012 17:22:48 -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 357BE21F8472 for ; Fri, 15 Jun 2012 17:22:48 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3939616obb.31 for ; Fri, 15 Jun 2012 17:22:47 -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:content-transfer-encoding:x-system-of-record; bh=ewDxIw3nt8h/1hURak8a5Qz28kJOoFGM9mgzAnuxzrA=; b=JP2tkmlzd8L6ZvQhxrTykmY3zAJZ5gm2u4e9Knj0WVy8pC5aH7fJ4MzFtbWWt1nnVn h/IItnTOXBOhBFy4ZFuVEw4/vxZD8stpCA9Mg/Po9MDHOvNjUXK76xyKf2HIulohF/YM vZBrmmywx9lhzBMfM1oJmzLJvNxp88y4HQ8lPO9/HthAtLUSE/4aBQFI2EQBBxbaC44H FY2PurEY1InfbBW5vh8Xrhw8HvqHFrj3UdS5VH/07U60zm2oD49K4pSj3Ur0TSs/150m Zke8V8x0zVU0QjjPgjtqhoBDXHVKY18zuAYnkKaJG0ggRl3n4ABuQSHdRCmpb1nl5s3S vDTA== 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:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=ewDxIw3nt8h/1hURak8a5Qz28kJOoFGM9mgzAnuxzrA=; b=bt53wW3NydoEZlmvG81nZgu2/PCI2mkdcH82smqcgZN7T+/6FGZ3lcP0IG6b4ga4sI jGlDtIDcO9b0XRssn0Tul87ky3yiQ2+nlDYVbBV6QS23niIm3VeWpFAJ6j+XnTjsXHsd xl15xY4Fv95YyJIhXA14OMRmhW/6LLn0/ZlWU5f8TJoji1mLfaF35xBpqzirLWsJxslR Enj/yejUEzXzoSN1q7N5NXKS2t2sBspI0jOzCtuU+GZj3iqrJuHh8LNarQVk1AU0xDEl hmb9nfDfWGtICgXEHaRL1wuriSVVfPU/IiRI5FmJL25Muy9tRxywAfp07s2v9GM4lngx 9w3Q== Received: by 10.50.169.38 with SMTP id ab6mr3571790igc.46.1339806167562; Fri, 15 Jun 2012 17:22:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.169.38 with SMTP id ab6mr3571782igc.46.1339806167384; Fri, 15 Jun 2012 17:22:47 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Fri, 15 Jun 2012 17:22:47 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366551A9E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366551A9E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 15 Jun 2012 17:22:47 -0700 Message-ID: From: Breno de Medeiros To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmif57qXEBbeXORsy+rG7Jd5lbJtt2bEpGCC1PvlQK65wrcnW272p+SaR8H7sSl3fD5WkUtR5NOCjYjJm+kBMvLtfVE/5uM1XtLqA9uxKFAUYho9/UyzM2sBQ5tlsVgL3s7V/bFFypmx3o/u4yN0o6J98xMpNusGdE7fUnUlSUPAWppUFQ= Cc: "Richard L. Barnes" , "jose@ietf.org" Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 00:22:49 -0000 On Fri, Jun 15, 2012 at 5:07 PM, Mike Jones w= rote: > Hi Richard, > > Since your message has been kicking around in the back of my mind, I'll a= dd one more data point on the "Not being JSON" comment. =A0As the designers= of JWT and the resulting JOSE specs saw it, there were two clear choices t= o able to sign/encrypt JSON data structures: > > (1) =A0Define a canonicalization algorithm and always operate on the cano= nical forms > (2) =A0Base64 encode a representation of the data structure to preserve t= he precise representation > > XML Canonicalization has proven to be a horror, leading to more interoper= ability problems than any other aspect of XMLDSIG, XMLENC, SAML, or WS-*. All our experience with signatures says that defining new canonicalization mechanisms should be avoided at all costs. Not only they lead to expensive interoperability issues, they may lead to frequent security issues. > > We chose #2. :-) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: Mike Jones > Sent: Friday, June 15, 2012 3:32 PM > To: 'Richard L. Barnes' > Cc: jose@ietf.org > Subject: RE: [jose] Fwd: New Version Notification for draft-barnes-jose-j= sms-00.txt > > Fair enough. =A0I'll briefly respond to each in turn. =A0Before doing so,= I'll say that I'm writing in the spirit of trying to increase mutual under= standing and consensus, rather than taking the point of view that the statu= s quo is the only reasonable outcome. > > -- Not being JSON > > This was by design, so that the results are URL-safe. =A0This is required= , for instance, for them to be used as OAuth Bearer Tokens. =A0At the reque= st of the working group, closely related pure-JSON drafts were also publish= ed. =A0See: > > http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializat= ion-01 and > http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializa= tion-01 > > Use them if you prefer if they better suit your use cases. =A0They could = be adopted as working group documents, if there's interest. > > -- Not supporting multiple recipients > > The JSON serialization drafts above do, again, in response to use cases p= resented by the working group. > > -- Lacking clear distinctions between signing and MAC > > Functionally, these are very similar operations, at least from an impleme= ntation perspective, so it's not clear that making a clear distinction woul= d help either developers or adoption in any practical way. =A0They achieve = overlapping, but admittedly sometimes different goals. =A0I believe that de= velopers can be trusted to use the algorithms that achieve their applicatio= ns' goals without making a hard distinction between the two. =A0But I'd be = interested in hearing your thoughts on why you believe a brighter-line dist= inction might be useful or necessary. > > -- Lacking clear processing instructions for different key establishment = modalities > > This seems like an area where the existing drafts could be refined to add= descriptions for additional establishment modalities, possibly based upon = your ideas and descriptions, should the working group decide to do so. =A0W= hat additional modalities do you have use cases for that you believe are no= t achievable or straightforward with the existing drafts? =A0The existing m= odalities supported are largely those that existing developers had told us = they needed and draw both from the precursor draft-jones-json-web-* documen= ts and draft-rescorla-jsms. > > Bear in mind that the balance that the current drafts try to strike is ke= eping the Mandatory to Implement (MTI) feature footprint small enough that = developers, including Web developers, are likely to adopt the specs, while = still providing enough functionality to make them generally useful. =A0As i= n any balance, it's often possible to shift things a bit and still maintain= the balance, but I'd like people to keep the ubiquitous adoption goal fron= t-and-center when proposing additional functionality. > > Ubiquitous deployment and usefulness trump theoretical completeness. =A0(= Just look at XMLDSIG and XMLENC to understand that!) > > -- Lack of clear typing of objects > > Most JSON documents aren't clearly typed; instead, developers and impleme= ntations understand from context what the meaning of each field is. =A0XML = is clearly typed, but developers are voting with their feet by moving to JS= ON. > > What practical advantages resulting from overlaying a typing infrastructu= re on JSON do you believe are worth the potential costs of doing so? =A0BTW= , I'm not opposed to having a JSON schema description of the JOSE JSON data= structures like JSMS did in http://tools.ietf.org/html/draft-rescorla-jsms= -00#appendix-A, but I'll remark that this an informative tool, not a normat= ive one. > > -- Lack of versioning for future extensibility > > An optional version field could be added if the working group desires, ho= wever the last time the working group discussed it, they decided not to do = so. =A0Rather, specs like this effectively become "versioned" when revised = in a way that new fields are added. =A0If you understand the new fields, yo= u support that new version. =A0(Note that this is independent of whether th= ere is a version number field, which according to some participants in the = previous discussion, they regarded as therefore being redundant information= .) > > I'm not religious about not having a version number field, but often "les= s is more". > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best wishe= s, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Friday, June 15, 2012 3:00 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-j= sms-00.txt > > Ok, so maybe I should have phrased my lead-in differently. =A0IMO, the cu= rrent JW* specs are deficient in several ways, e.g.: > -- Not being JSON > -- Not supporting multiple recipients > -- Lacking clear distinctions between signing and MAC > -- Lacking clear processing instructions for different key establishment = modalities > -- Lack of clear typing of objects > -- Lack of versioning for future extensibility > > Looking at the current specs, it didn't seem to me that it would be simpl= e to adapt them to address these deficiencies. =A0So I just did a re-write.= =A0If you think they can be addressed within the current framework, please= explain. =A0I just found it simpler to start from whole cloth. > > Cheers, > --Richard > > > > On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > >> Hi Richard, >> >> If you're puzzled by specific design decisions in the JOSE documents, I = encourage you to ask about them on the list. =A0The documents have signific= ant history going back to mid-2010 when convergence discussions started amo= ng people with four different JSON signing & encryption proposals. =A0JWT a= nd the current JOSE specs and implementations are the result. =A0I realize = that not all the JOSE participants were part of those discussions from the = beginning (although many were) and so teasing out the rationale for specifi= c decisions might help people better understand the choices made, and hopef= ully thereby increase consensus behind the eventual working group choices. >> >> If the list that you're puzzled by is the bulleted list below, maybe we = can start a discussion on that basis. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best wishes, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> Of Richard L. Barnes >> Sent: Friday, June 15, 2012 2:08 PM >> To: jose@ietf.org >> Subject: [jose] Fwd: New Version Notification for >> draft-barnes-jose-jsms-00.txt >> >> Dear JOSE WG, >> >> Like Mr. Manger, once I finally got around to doing a thorough review of= the JW* specs, I was kind of puzzled by some of the design decisions. =A0S= o I also went through and wrote an alternative format, this time taking a m= ore of a cue from CMS. =A0A link to the document is below. >> >> Summary of differences: >> >> =A0 o =A0JSMS is pure JSON, whereas in JWE and JWS only the header >> =A0 =A0 =A0parameters are represented in JSON. >> >> =A0 o =A0JSMS allows for full algorithm agility in key agreement, while = JWE >> =A0 =A0 =A0only allows ECDH-ES. >> >> =A0 o =A0JSMS supports multiple recipients for EncryptedData and >> =A0 =A0 =A0AuthenticatedData objects via the inclusion of multiple Wrapp= edKey >> =A0 =A0 =A0objects. =A0Sending a JWE to multiple recipients requires re- >> =A0 =A0 =A0encryption of the entire object for each recipient. >> >> =A0 o =A0The signature and MAC functions of the JWS object are separated >> =A0 =A0 =A0into SignedData and AuthenticatedData JSMS objects. >> >> =A0 o =A0JSMS parameters are not integrity-protected, as they are in JWE >> =A0 =A0 =A0and JWS. >> >> =A0 o =A0The "typ" and "zip" parameters are not defined in JSMS, but cou= ld >> =A0 =A0 =A0be added without significant change. >> >> =A0 o =A0JSMS requires that recipients MUST ignore unknown header >> =A0 =A0 =A0parameters, in order to facilitate extensibility. >> >> I've also thrown together an initial JavaScript implementation (based on= NodeJS for some python crypto glue), which is on github: >> >> >> Comments are very welcome. >> >> Thanks, >> --Richard >> >> >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >>> Date: June 15, 2012 4:56:09 PM EDT >>> To: rbarnes@bbn.com >>> >>> >>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>> successfully submitted by Richard Barnes and posted to the IETF >>> repository. >>> >>> Filename: =A0 =A0 draft-barnes-jose-jsms >>> Revision: =A0 =A0 00 >>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0JavaScript Message Security Forma= t >>> Creation date: =A0 =A0 =A0 =A02012-06-15 >>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Individual Submission >>> Number of pages: 25 >>> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-= barnes-jose-jsms-00.txt >>> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-barnes= -jose-jsms >>> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-barnes-jose-j= sms-00 >>> >>> >>> Abstract: >>> =A0Many applications require the ability to send cryptographically >>> secured messages. =A0While the IETF has defined a number of formats for >>> such messages (e.g. =A0CMS) those formats use encodings which are not >>> easy to use in modern applications. =A0This document describes the >>> JavaScript Message Security format (JSMS), a new cryptographic >>> message format which is based on JavaScript Object Notation (JSON) >>> and thus is easy for many applications to generate and parse. >>> >>> >>> >>> >>> The IETF Secretariat >> >> _______________________________________________ >> 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 --Breno From sakimura@gmail.com Fri Jun 15 17:37: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 A88A211E808C for ; Fri, 15 Jun 2012 17:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43C7jBsXRkYp for ; Fri, 15 Jun 2012 17:37:51 -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 4C33011E807F for ; Fri, 15 Jun 2012 17:37:51 -0700 (PDT) Received: by bkty8 with SMTP id y8so3143262bkt.31 for ; Fri, 15 Jun 2012 17:37:50 -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=j1M2huiyw/flfJdIexGjMrKlyYfRtZ975gl1itefaP4=; b=T/R7pCAVTgAKLr2NBdRwDv3WbowJvuImFu3x2GwB2/Vnp5r7pJSQwltEQrLZgfXwhw xzwnnCIA/Q2HOjzamh+ukeGZc4XhCM6o5iU9Mfu79crW20EUTGHpQtuX85nZOsZ1mPp1 Nbtv4yJyAQBdmaE27C3qm5iIXU1sq8KlekTHomukmIJmp1jH1XFy15Tjc8dXYv357VZD xI+mWsmqim+KuVyK/nmHprkqxWTyH+gaPxSuBCOHCmRnHqPNskGcgANr5Xxp6FFnoc+C ePKlpGxURU0EhbjkrkQVgtjeOhf6c4y+EEhnj7uBqUacPOoz3qv00CmNNhN0SstQ4cWu KpSA== MIME-Version: 1.0 Received: by 10.204.145.78 with SMTP id c14mr3513183bkv.43.1339807070136; Fri, 15 Jun 2012 17:37:50 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Fri, 15 Jun 2012 17:37:50 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366551A9E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 16 Jun 2012 09:37:50 +0900 Message-ID: From: Nat Sakimura To: Breno de Medeiros Content-Type: multipart/alternative; boundary=00151759338c7ba92404c28c24ca Cc: "Richard L. Barnes" , Mike Jones , "jose@ietf.org" Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 00:37:53 -0000 --00151759338c7ba92404c28c24ca Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 16, 2012 at 9:22 AM, Breno de Medeiros wrote: > On Fri, Jun 15, 2012 at 5:07 PM, Mike Jones > wrote: > > Hi Richard, > > > > Since your message has been kicking around in the back of my mind, I'll > add one more data point on the "Not being JSON" comment. As the designers > of JWT and the resulting JOSE specs saw it, there were two clear choices to > able to sign/encrypt JSON data structures: > > > > (1) Define a canonicalization algorithm and always operate on the > canonical forms > > (2) Base64 encode a representation of the data structure to preserve > the precise representation > > > > XML Canonicalization has proven to be a horror, leading to more > interoperability problems than any other aspect of XMLDSIG, XMLENC, SAML, > or WS-*. > > All our experience with signatures says that defining new > canonicalization mechanisms should be avoided at all costs. Not only > they lead to expensive interoperability issues, they may lead to > frequent security issues. > +1 > > > > > We chose #2. :-) > > > > -- Mike > > > > -----Original Message----- > > From: Mike Jones > > Sent: Friday, June 15, 2012 3:32 PM > > To: 'Richard L. Barnes' > > Cc: jose@ietf.org > > Subject: RE: [jose] Fwd: New Version Notification for > draft-barnes-jose-jsms-00.txt > > > > Fair enough. I'll briefly respond to each in turn. Before doing so, > I'll say that I'm writing in the spirit of trying to increase mutual > understanding and consensus, rather than taking the point of view that the > status quo is the only reasonable outcome. > > > > -- Not being JSON > > > > This was by design, so that the results are URL-safe. This is required, > for instance, for them to be used as OAuth Bearer Tokens. At the request > of the working group, closely related pure-JSON drafts were also published. > See: > > > > > http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-01and > > > http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serialization-01 > > > > Use them if you prefer if they better suit your use cases. They could > be adopted as working group documents, if there's interest. > > > > -- Not supporting multiple recipients > > > > The JSON serialization drafts above do, again, in response to use cases > presented by the working group. > > > > -- Lacking clear distinctions between signing and MAC > > > > Functionally, these are very similar operations, at least from an > implementation perspective, so it's not clear that making a clear > distinction would help either developers or adoption in any practical way. > They achieve overlapping, but admittedly sometimes different goals. I > believe that developers can be trusted to use the algorithms that achieve > their applications' goals without making a hard distinction between the > two. But I'd be interested in hearing your thoughts on why you believe a > brighter-line distinction might be useful or necessary. > > > > -- Lacking clear processing instructions for different key establishment > modalities > > > > This seems like an area where the existing drafts could be refined to > add descriptions for additional establishment modalities, possibly based > upon your ideas and descriptions, should the working group decide to do so. > What additional modalities do you have use cases for that you believe are > not achievable or straightforward with the existing drafts? The existing > modalities supported are largely those that existing developers had told us > they needed and draw both from the precursor draft-jones-json-web-* > documents and draft-rescorla-jsms. > > > > Bear in mind that the balance that the current drafts try to strike is > keeping the Mandatory to Implement (MTI) feature footprint small enough > that developers, including Web developers, are likely to adopt the specs, > while still providing enough functionality to make them generally useful. > As in any balance, it's often possible to shift things a bit and still > maintain the balance, but I'd like people to keep the ubiquitous adoption > goal front-and-center when proposing additional functionality. > > > > Ubiquitous deployment and usefulness trump theoretical completeness. > (Just look at XMLDSIG and XMLENC to understand that!) > > > > -- Lack of clear typing of objects > > > > Most JSON documents aren't clearly typed; instead, developers and > implementations understand from context what the meaning of each field is. > XML is clearly typed, but developers are voting with their feet by moving > to JSON. > > > > What practical advantages resulting from overlaying a typing > infrastructure on JSON do you believe are worth the potential costs of > doing so? BTW, I'm not opposed to having a JSON schema description of the > JOSE JSON data structures like JSMS did in > http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll > remark that this an informative tool, not a normative one. > > > > -- Lack of versioning for future extensibility > > > > An optional version field could be added if the working group desires, > however the last time the working group discussed it, they decided not to > do so. Rather, specs like this effectively become "versioned" when revised > in a way that new fields are added. If you understand the new fields, you > support that new version. (Note that this is independent of whether there > is a version number field, which according to some participants in the > previous discussion, they regarded as therefore being redundant > information.) > > > > I'm not religious about not having a version number field, but often > "less is more". > > > > Best wishes, > > -- Mike > > > > -----Original Message----- > > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > > Sent: Friday, June 15, 2012 3:00 PM > > To: Mike Jones > > Cc: jose@ietf.org > > Subject: Re: [jose] Fwd: New Version Notification for > draft-barnes-jose-jsms-00.txt > > > > Ok, so maybe I should have phrased my lead-in differently. IMO, the > current JW* specs are deficient in several ways, e.g.: > > -- Not being JSON > > -- Not supporting multiple recipients > > -- Lacking clear distinctions between signing and MAC > > -- Lacking clear processing instructions for different key establishment > modalities > > -- Lack of clear typing of objects > > -- Lack of versioning for future extensibility > > > > Looking at the current specs, it didn't seem to me that it would be > simple to adapt them to address these deficiencies. So I just did a > re-write. If you think they can be addressed within the current framework, > please explain. I just found it simpler to start from whole cloth. > > > > Cheers, > > --Richard > > > > > > > > On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > > > >> Hi Richard, > >> > >> If you're puzzled by specific design decisions in the JOSE documents, I > encourage you to ask about them on the list. The documents have > significant history going back to mid-2010 when convergence discussions > started among people with four different JSON signing & encryption > proposals. JWT and the current JOSE specs and implementations are the > result. I realize that not all the JOSE participants were part of those > discussions from the beginning (although many were) and so teasing out the > rationale for specific decisions might help people better understand the > choices made, and hopefully thereby increase consensus behind the eventual > working group choices. > >> > >> If the list that you're puzzled by is the bulleted list below, maybe we > can start a discussion on that basis. > >> > >> Best wishes, > >> -- Mike > >> > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >> Of Richard L. Barnes > >> Sent: Friday, June 15, 2012 2:08 PM > >> To: jose@ietf.org > >> Subject: [jose] Fwd: New Version Notification for > >> draft-barnes-jose-jsms-00.txt > >> > >> Dear JOSE WG, > >> > >> Like Mr. Manger, once I finally got around to doing a thorough review > of the JW* specs, I was kind of puzzled by some of the design decisions. > So I also went through and wrote an alternative format, this time taking a > more of a cue from CMS. A link to the document is below. > >> > >> Summary of differences: > >> > >> o JSMS is pure JSON, whereas in JWE and JWS only the header > >> parameters are represented in JSON. > >> > >> o JSMS allows for full algorithm agility in key agreement, while JWE > >> only allows ECDH-ES. > >> > >> o JSMS supports multiple recipients for EncryptedData and > >> AuthenticatedData objects via the inclusion of multiple WrappedKey > >> objects. Sending a JWE to multiple recipients requires re- > >> encryption of the entire object for each recipient. > >> > >> o The signature and MAC functions of the JWS object are separated > >> into SignedData and AuthenticatedData JSMS objects. > >> > >> o JSMS parameters are not integrity-protected, as they are in JWE > >> and JWS. > >> > >> o The "typ" and "zip" parameters are not defined in JSMS, but could > >> be added without significant change. > >> > >> o JSMS requires that recipients MUST ignore unknown header > >> parameters, in order to facilitate extensibility. > >> > >> I've also thrown together an initial JavaScript implementation (based > on NodeJS for some python crypto glue), which is on github: > >> > >> > >> Comments are very welcome. > >> > >> Thanks, > >> --Richard > >> > >> > >> > >> Begin forwarded message: > >> > >>> From: internet-drafts@ietf.org > >>> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt > >>> Date: June 15, 2012 4:56:09 PM EDT > >>> To: rbarnes@bbn.com > >>> > >>> > >>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been > >>> successfully submitted by Richard Barnes and posted to the IETF > >>> repository. > >>> > >>> Filename: draft-barnes-jose-jsms > >>> Revision: 00 > >>> Title: JavaScript Message Security Format > >>> Creation date: 2012-06-15 > >>> WG ID: Individual Submission > >>> Number of pages: 25 > >>> URL: > http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt > >>> Status: > http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > >>> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 > >>> > >>> > >>> Abstract: > >>> Many applications require the ability to send cryptographically > >>> secured messages. While the IETF has defined a number of formats for > >>> such messages (e.g. CMS) those formats use encodings which are not > >>> easy to use in modern applications. This document describes the > >>> JavaScript Message Security format (JSMS), a new cryptographic > >>> message format which is based on JavaScript Object Notation (JSON) > >>> and thus is easy for many applications to generate and parse. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >> > >> _______________________________________________ > >> 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 > > > > -- > --Breno > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --00151759338c7ba92404c28c24ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jun 16, 2012 at 9:22 AM, Breno d= e Medeiros <breno@google.com> wrote:
On Fri, Jun 15, 2012 at 5:07 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:
> Hi Richard,
>
> Since your message has been kicking around in the back of my mind, I&#= 39;ll add one more data point on the "Not being JSON" comment. = =A0As the designers of JWT and the resulting JOSE specs saw it, there were = two clear choices to able to sign/encrypt JSON data structures:
>
> (1) =A0Define a canonicalization algorithm and always operate on the c= anonical forms
> (2) =A0Base64 encode a representation of the data structure to preserv= e the precise representation
>
> XML Canonicalization has proven to be a horror, leading to more intero= perability problems than any other aspect of XMLDSIG, XMLENC, SAML, or WS-*= .

All our experience with signatures says that defining new
canonicalization mechanisms should be avoided at all costs. Not only
they lead to expensive interoperability issues, they may lead to
frequent security issues.

+1=A0
=A0

>
> We chose #2. :-)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike=
>
> -----Original Message-----
> From: Mike Jones
> Sent: Friday, June 15, 2012 3:32 PM
> To: 'Richard L. Barnes'
> Cc: jose@ietf.org
> Subject: RE: [jose] Fwd: New Version Notification for draft-barnes-jos= e-jsms-00.txt
>
> Fair enough. =A0I'll briefly respond to each in turn. =A0Before do= ing so, I'll say that I'm writing in the spirit of trying to increa= se mutual understanding and consensus, rather than taking the point of view= that the status quo is the only reasonable outcome.
>
> -- Not being JSON
>
> This was by design, so that the results are URL-safe. =A0This is requi= red, for instance, for them to be used as OAuth Bearer Tokens. =A0At the re= quest of the working group, closely related pure-JSON drafts were also publ= ished. =A0See:
>
> http://tools.ietf.org/html/draft-jo= nes-json-web-signature-json-serialization-01 and
> http://tools.ietf.org/html/draft-j= ones-json-web-encryption-json-serialization-01
>
> Use them if you prefer if they better suit your use cases. =A0They cou= ld be adopted as working group documents, if there's interest.
>
> -- Not supporting multiple recipients
>
> The JSON serialization drafts above do, again, in response to use case= s presented by the working group.
>
> -- Lacking clear distinctions between signing and MAC
>
> Functionally, these are very similar operations, at least from an impl= ementation perspective, so it's not clear that making a clear distincti= on would help either developers or adoption in any practical way. =A0They a= chieve overlapping, but admittedly sometimes different goals. =A0I believe = that developers can be trusted to use the algorithms that achieve their app= lications' goals without making a hard distinction between the two. =A0= But I'd be interested in hearing your thoughts on why you believe a bri= ghter-line distinction might be useful or necessary.
>
> -- Lacking clear processing instructions for different key establishme= nt modalities
>
> This seems like an area where the existing drafts could be refined to = add descriptions for additional establishment modalities, possibly based up= on your ideas and descriptions, should the working group decide to do so. = =A0What additional modalities do you have use cases for that you believe ar= e not achievable or straightforward with the existing drafts? =A0The existi= ng modalities supported are largely those that existing developers had told= us they needed and draw both from the precursor draft-jones-json-web-* doc= uments and draft-rescorla-jsms.
>
> Bear in mind that the balance that the current drafts try to strike is= keeping the Mandatory to Implement (MTI) feature footprint small enough th= at developers, including Web developers, are likely to adopt the specs, whi= le still providing enough functionality to make them generally useful. =A0A= s in any balance, it's often possible to shift things a bit and still m= aintain the balance, but I'd like people to keep the ubiquitous adoptio= n goal front-and-center when proposing additional functionality.
>
> Ubiquitous deployment and usefulness trump theoretical completeness. = =A0(Just look at XMLDSIG and XMLENC to understand that!)
>
> -- Lack of clear typing of objects
>
> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field is. = =A0XML is clearly typed, but developers are voting with their feet by movin= g to JSON.
>
> What practical advantages resulting from overlaying a typing infrastru= cture on JSON do you believe are worth the potential costs of doing so? =A0= BTW, I'm not opposed to having a JSON schema description of the JOSE JS= ON data structures like JSMS did in http://tools.ietf.org/h= tml/draft-rescorla-jsms-00#appendix-A, but I'll remark that this an= informative tool, not a normative one.
>
> -- Lack of versioning for future extensibility
>
> An optional version field could be added if the working group desires,= however the last time the working group discussed it, they decided not to = do so. =A0Rather, specs like this effectively become "versioned" = when revised in a way that new fields are added. =A0If you understand the n= ew fields, you support that new version. =A0(Note that this is independent = of whether there is a version number field, which according to some partici= pants in the previous discussion, they regarded as therefore being redundan= t information.)
>
> I'm not religious about not having a version number field, but oft= en "less is more".
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best wi= shes,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike=
>
> -----Original Message-----
> From: Richard L. Barnes [mailto:rba= rnes@bbn.com]
> Sent: Friday, June 15, 2012 3:00 PM
> To: Mike Jones
> Cc: jose@ietf.org
> Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jos= e-jsms-00.txt
>
> Ok, so maybe I should have phrased my lead-in differently. =A0IMO, the= current JW* specs are deficient in several ways, e.g.:
> -- Not being JSON
> -- Not supporting multiple recipients
> -- Lacking clear distinctions between signing and MAC
> -- Lacking clear processing instructions for different key establishme= nt modalities
> -- Lack of clear typing of objects
> -- Lack of versioning for future extensibility
>
> Looking at the current specs, it didn't seem to me that it would b= e simple to adapt them to address these deficiencies. =A0So I just did a re= -write. =A0If you think they can be addressed within the current framework,= please explain. =A0I just found it simpler to start from whole cloth.
>
> Cheers,
> --Richard
>
>
>
> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote:
>
>> Hi Richard,
>>
>> If you're puzzled by specific design decisions in the JOSE doc= uments, I encourage you to ask about them on the list. =A0The documents hav= e significant history going back to mid-2010 when convergence discussions s= tarted among people with four different JSON signing & encryption propo= sals. =A0JWT and the current JOSE specs and implementations are the result.= =A0I realize that not all the JOSE participants were part of those discuss= ions from the beginning (although many were) and so teasing out the rationa= le for specific decisions might help people better understand the choices m= ade, and hopefully thereby increase consensus behind the eventual working g= roup choices.
>>
>> If the list that you're puzzled by is the bulleted list below,= maybe we can start a discussion on that basis.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best w= ishes,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mik= e
>>
>> -----Original Message-----
>> From: jose-bounces@ietf.o= rg [mailto:jose-bounces@ietf.o= rg] On Behalf
>> Of Richard L. Barnes
>> Sent: Friday, June 15, 2012 2:08 PM
>> To: jose@ietf.org
>> Subject: [jose] Fwd: New Version Notification for
>> draft-barnes-jose-jsms-00.txt
>>
>> Dear JOSE WG,
>>
>> Like Mr. Manger, once I finally got around to doing a thorough rev= iew of the JW* specs, I was kind of puzzled by some of the design decisions= . =A0So I also went through and wrote an alternative format, this time taki= ng a more of a cue from CMS. =A0A link to the document is below.
>>
>> Summary of differences:
>>
>> =A0 o =A0JSMS is pure JSON, whereas in JWE and JWS only the header=
>> =A0 =A0 =A0parameters are represented in JSON.
>>
>> =A0 o =A0JSMS allows for full algorithm agility in key agreement, = while JWE
>> =A0 =A0 =A0only allows ECDH-ES.
>>
>> =A0 o =A0JSMS supports multiple recipients for EncryptedData and >> =A0 =A0 =A0AuthenticatedData objects via the inclusion of multiple= WrappedKey
>> =A0 =A0 =A0objects. =A0Sending a JWE to multiple recipients requir= es re-
>> =A0 =A0 =A0encryption of the entire object for each recipient.
>>
>> =A0 o =A0The signature and MAC functions of the JWS object are sep= arated
>> =A0 =A0 =A0into SignedData and AuthenticatedData JSMS objects.
>>
>> =A0 o =A0JSMS parameters are not integrity-protected, as they are = in JWE
>> =A0 =A0 =A0and JWS.
>>
>> =A0 o =A0The "typ" and "zip" parameters are no= t defined in JSMS, but could
>> =A0 =A0 =A0be added without significant change.
>>
>> =A0 o =A0JSMS requires that recipients MUST ignore unknown header<= br> >> =A0 =A0 =A0parameters, in order to facilitate extensibility.
>>
>> I've also thrown together an initial JavaScript implementation= (based on NodeJS for some python crypto glue), which is on github:
>> <https://github.com/bifurcation/jsms>
>>
>> Comments are very welcome.
>>
>> Thanks,
>> --Richard
>>
>>
>>
>> Begin forwarded message:
>>
>>> From: internet-dra= fts@ietf.org
>>> Subject: New Version Notification for draft-barnes-jose-jsms-0= 0.txt
>>> Date: June 15, 2012 4:56:09 PM EDT
>>> To: rbarnes@bbn.com
>>>
>>>
>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>> successfully submitted by Richard Barnes and posted to the IET= F
>>> repository.
>>>
>>> Filename: =A0 =A0 draft-barnes-jose-jsms
>>> Revision: =A0 =A0 00
>>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0JavaScript Message Secur= ity Format
>>> Creation date: =A0 =A0 =A0 =A02012-06-15
>>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Individual Submission >>> Number of pages: 25
>>> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.i= etf.org/internet-drafts/draft-barnes-jose-jsms-00.txt
>>> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-barnes-jose-jsms
>>> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-barnes-jose-jsms-00
>>>
>>>
>>> Abstract:
>>> =A0Many applications require the ability to send cryptographic= ally
>>> secured messages. =A0While the IETF has defined a number of fo= rmats for
>>> such messages (e.g. =A0CMS) those formats use encodings which = are not
>>> easy to use in modern applications. =A0This document describes= the
>>> JavaScript Message Security format (JSMS), a new cryptographic=
>>> message format which is based on JavaScript Object Notation (J= SON)
>>> and thus is easy for many applications to generate and parse.<= br> >>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>
>> _______________________________________________
>> 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



--
--Breno
_____________________= __________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en

--00151759338c7ba92404c28c24ca-- From ve7jtb@ve7jtb.com Fri Jun 15 20:17: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 0EDB611E8105 for ; Fri, 15 Jun 2012 20:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOH2iZTqXlEl for ; Fri, 15 Jun 2012 20:17:57 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 813C211E80BD for ; Fri, 15 Jun 2012 20:17:57 -0700 (PDT) Received: by yenq13 with SMTP id q13so3242324yen.31 for ; Fri, 15 Jun 2012 20:17:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=NXrp8DN/6QUcgjnrh9iGvxbtfBkNn7sxTg8inzlX5VQ=; b=XZ7/464MBFmwhsGVlR+PjXGRfZ9GEpEiw6V6zojj0dy3F6tcK5fjcyPeDBgUpawP22 fbhvyTulqcjnJxLsFarYrrtFYiyRStvaS4i6kExABFdXI+ABjuxmzz9GWYU2mkhTc0SS FX21mKzDcvGN0gWP+kBY72HntqjFa6xtJzSDTcTU5cIi5SwUyZUabDKqLXbOBWbLnHc7 GviJwRIi8bqkdHUhsukbe7ozQTk6xqMmqtZXU1JxYDcCGrjesbxseV8o/0ym1B5g61sp rPtcop6ssTcGWtNceCyTAHRI6ZdDi0OkmpT4gkBi7CM368BLUvngfjZOTBW+s80WtTJ7 vn9A== Received: by 10.236.76.233 with SMTP id b69mr10676529yhe.52.1339816676772; Fri, 15 Jun 2012 20:17:56 -0700 (PDT) Received: from [192.168.1.213] (190-20-60-13.baf.movistar.cl. [190.20.60.13]) by mx.google.com with ESMTPS id j39sm19128965ani.3.2012.06.15.20.17.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 20:17:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_B74963A9-ED60-4D83-944E-89EEDA51770E"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Fri, 15 Jun 2012 23:17:12 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366551A9E@TK5EX14MBXC283.redmond.corp.microsoft.com> To: jose@ietf.org X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlLtnjIwyeBwUJbWpPPUho7ElgLBhK2LJkY01xM8Jk6QCT6wgLToIjnURecdj0p8S7sKAnX Cc: "Richard L. Barnes" , Mike Jones Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 03:17:59 -0000 --Apple-Mail=_B74963A9-ED60-4D83-944E-89EEDA51770E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 On 2012-06-15, at 8:22 PM, Breno de Medeiros wrote: > On Fri, Jun 15, 2012 at 5:07 PM, Mike Jones = wrote: >> Hi Richard, >>=20 >> Since your message has been kicking around in the back of my mind, = I'll add one more data point on the "Not being JSON" comment. As the = designers of JWT and the resulting JOSE specs saw it, there were two = clear choices to able to sign/encrypt JSON data structures: >>=20 >> (1) Define a canonicalization algorithm and always operate on the = canonical forms >> (2) Base64 encode a representation of the data structure to preserve = the precise representation >>=20 >> XML Canonicalization has proven to be a horror, leading to more = interoperability problems than any other aspect of XMLDSIG, XMLENC, = SAML, or WS-*. >=20 > All our experience with signatures says that defining new > canonicalization mechanisms should be avoided at all costs. Not only > they lead to expensive interoperability issues, they may lead to > frequent security issues. >=20 >>=20 >> We chose #2. :-) >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Mike Jones >> Sent: Friday, June 15, 2012 3:32 PM >> To: 'Richard L. Barnes' >> Cc: jose@ietf.org >> Subject: RE: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >>=20 >> Fair enough. I'll briefly respond to each in turn. Before doing so, = I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >>=20 >> -- Not being JSON >>=20 >> This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >>=20 >> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 and >> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 >>=20 >> Use them if you prefer if they better suit your use cases. They = could be adopted as working group documents, if there's interest. >>=20 >> -- Not supporting multiple recipients >>=20 >> The JSON serialization drafts above do, again, in response to use = cases presented by the working group. >>=20 >> -- Lacking clear distinctions between signing and MAC >>=20 >> Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. >>=20 >> -- Lacking clear processing instructions for different key = establishment modalities >>=20 >> This seems like an area where the existing drafts could be refined to = add descriptions for additional establishment modalities, possibly based = upon your ideas and descriptions, should the working group decide to do = so. What additional modalities do you have use cases for that you = believe are not achievable or straightforward with the existing drafts? = The existing modalities supported are largely those that existing = developers had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and draft-rescorla-jsms. >>=20 >> Bear in mind that the balance that the current drafts try to strike = is keeping the Mandatory to Implement (MTI) feature footprint small = enough that developers, including Web developers, are likely to adopt = the specs, while still providing enough functionality to make them = generally useful. As in any balance, it's often possible to shift = things a bit and still maintain the balance, but I'd like people to keep = the ubiquitous adoption goal front-and-center when proposing additional = functionality. >>=20 >> Ubiquitous deployment and usefulness trump theoretical completeness. = (Just look at XMLDSIG and XMLENC to understand that!) >>=20 >> -- Lack of clear typing of objects >>=20 >> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >>=20 >> What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. >>=20 >> -- Lack of versioning for future extensibility >>=20 >> An optional version field could be added if the working group = desires, however the last time the working group discussed it, they = decided not to do so. Rather, specs like this effectively become = "versioned" when revised in a way that new fields are added. If you = understand the new fields, you support that new version. (Note that = this is independent of whether there is a version number field, which = according to some participants in the previous discussion, they regarded = as therefore being redundant information.) >>=20 >> I'm not religious about not having a version number field, but often = "less is more". >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >> Sent: Friday, June 15, 2012 3:00 PM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >>=20 >> Ok, so maybe I should have phrased my lead-in differently. IMO, the = current JW* specs are deficient in several ways, e.g.: >> -- Not being JSON >> -- Not supporting multiple recipients >> -- Lacking clear distinctions between signing and MAC >> -- Lacking clear processing instructions for different key = establishment modalities >> -- Lack of clear typing of objects >> -- Lack of versioning for future extensibility >>=20 >> Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >>=20 >> Cheers, >> --Richard >>=20 >>=20 >>=20 >> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>=20 >>> Hi Richard, >>>=20 >>> If you're puzzled by specific design decisions in the JOSE = documents, I encourage you to ask about them on the list. The documents = have significant history going back to mid-2010 when convergence = discussions started among people with four different JSON signing & = encryption proposals. JWT and the current JOSE specs and = implementations are the result. I realize that not all the JOSE = participants were part of those discussions from the beginning (although = many were) and so teasing out the rationale for specific decisions might = help people better understand the choices made, and hopefully thereby = increase consensus behind the eventual working group choices. >>>=20 >>> If the list that you're puzzled by is the bulleted list below, maybe = we can start a discussion on that basis. >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>> Of Richard L. Barnes >>> Sent: Friday, June 15, 2012 2:08 PM >>> To: jose@ietf.org >>> Subject: [jose] Fwd: New Version Notification for >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> Dear JOSE WG, >>>=20 >>> Like Mr. Manger, once I finally got around to doing a thorough = review of the JW* specs, I was kind of puzzled by some of the design = decisions. So I also went through and wrote an alternative format, this = time taking a more of a cue from CMS. A link to the document is below. >>>=20 >>> Summary of differences: >>>=20 >>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>> parameters are represented in JSON. >>>=20 >>> o JSMS allows for full algorithm agility in key agreement, while = JWE >>> only allows ECDH-ES. >>>=20 >>> o JSMS supports multiple recipients for EncryptedData and >>> AuthenticatedData objects via the inclusion of multiple = WrappedKey >>> objects. Sending a JWE to multiple recipients requires re- >>> encryption of the entire object for each recipient. >>>=20 >>> o The signature and MAC functions of the JWS object are separated >>> into SignedData and AuthenticatedData JSMS objects. >>>=20 >>> o JSMS parameters are not integrity-protected, as they are in JWE >>> and JWS. >>>=20 >>> o The "typ" and "zip" parameters are not defined in JSMS, but = could >>> be added without significant change. >>>=20 >>> o JSMS requires that recipients MUST ignore unknown header >>> parameters, in order to facilitate extensibility. >>>=20 >>> I've also thrown together an initial JavaScript implementation = (based on NodeJS for some python crypto glue), which is on github: >>> >>>=20 >>> Comments are very welcome. >>>=20 >>> Thanks, >>> --Richard >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >>>> Date: June 15, 2012 4:56:09 PM EDT >>>> To: rbarnes@bbn.com >>>>=20 >>>>=20 >>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>> successfully submitted by Richard Barnes and posted to the IETF >>>> repository. >>>>=20 >>>> Filename: draft-barnes-jose-jsms >>>> Revision: 00 >>>> Title: JavaScript Message Security Format >>>> Creation date: 2012-06-15 >>>> WG ID: Individual Submission >>>> Number of pages: 25 >>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> Many applications require the ability to send cryptographically >>>> secured messages. While the IETF has defined a number of formats = for >>>> such messages (e.g. CMS) those formats use encodings which are not >>>> easy to use in modern applications. This document describes the >>>> JavaScript Message Security format (JSMS), a new cryptographic >>>> message format which is based on JavaScript Object Notation (JSON) >>>> and thus is easy for many applications to generate and parse. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > --=20 > --Breno > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_B74963A9-ED60-4D83-944E-89EEDA51770E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx NjAzMTcxMlowIwYJKoZIhvcNAQkEMRYEFA+ooZUxypxcTdJoO07HD6CSgnErMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AA3x4Wok3kCH6Uq9pFOqfY9WACzjdqWYnw7nO1x5udIRBHwMLidxvt85J/nuvH+sQURV6gz6udbw OLHX9ykrHsw8eDWptEyS7NR/dC0FRYXlL/l9M7Ked7QUGV9nVPwPaZqvLIjwIUsrg5T4HTOVYMjd OJrDprIdlXTC/C8iNcJVjWNvBdvO8PaI5TVyThpmiV9MUQAMeXxgmJL+6Eq9bgVUNpSx3qnT82rV MeCgI/nqCsl6CblMeTQ8m0PIqKzxqTKkRMZFkO1DV0i7oyhI8uNs12lRPHh0WEKF+c+yqXW2UGze pyN+AWtAxzmUaHfzbvIUT7o12hSXX5Jij82BDcEAAAAAAAA= --Apple-Mail=_B74963A9-ED60-4D83-944E-89EEDA51770E-- From lef.mutualauth@gmail.com Sat Jun 16 11:11: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 A484921F8542 for ; Sat, 16 Jun 2012 11:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F60vRfT6uwZ9 for ; Sat, 16 Jun 2012 11:11:29 -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 B1B4021F8534 for ; Sat, 16 Jun 2012 11:11:29 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2640470qcs.31 for ; Sat, 16 Jun 2012 11:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NlJGCX/4yM1hv3fAtQpe/XDnsCnyiKXWlzZn54dkhNU=; b=eLepj7CV6enFUhEl1ovCsOTdNOAO6p4qtzhYcFv2oinf33x8k03rKp1mLfG5jOthLH eV3u4sSERIpKFky/wM50NaCD7H1+NXZ6CspvWUT7b746TOs38r21Z/T4+ANgiQBXjKEl 33RnDR+5txvDtaAns36qO23qKuRakC4pTfka0cjsVC7SkL43+rwdELNV6jvzSGAY6SaH JogZoBpFr0W+EtrJZyl1TvhzHSjRw2spgURWlfvwCw3uaWws+SPoSUtyGqzyMyuO0I0Y zq0PXPu2pOQnuUf/qYJTAMSils8NLrFnB3/rgcTbUtnAQSkDy6ngIpZeUUdaK/bS2Hka SE7w== MIME-Version: 1.0 Received: by 10.224.184.75 with SMTP id cj11mr18310458qab.16.1339870288979; Sat, 16 Jun 2012 11:11:28 -0700 (PDT) Received: by 10.229.35.209 with HTTP; Sat, 16 Jun 2012 11:11:28 -0700 (PDT) In-Reply-To: <6DD609C2-8F55-416B-A4E9-D7A89F5BC01A@gmail.com> References: <255B9BB34FB7D647A506DC292726F6E114F5474E28@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F547526A@WSMSG3153V.srv.dir.telstra.com> <206BAF5F-6D9B-4D16-A0E6-A4AD8B9ECE2D@gmail.com> <255B9BB34FB7D647A506DC292726F6E114F5475748@WSMSG3153V.srv.dir.telstra.com> <6DD609C2-8F55-416B-A4E9-D7A89F5BC01A@gmail.com> Date: Sun, 17 Jun 2012 03:11:28 +0900 Message-ID: From: "HAYASHI, Tatsuya" To: "Manger, James H" , jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dick Hardt Subject: Re: [jose] draft-manger-jose-jwsec: IV ciphertext tag 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, 16 Jun 2012 18:11:30 -0000 FYI: W3C (and IETF?) are doing relevant work now. http://www.w3.org/2012/webcrypto/ (based on Mozilla DOMCrypt) (sorry if wrong.) --=20 Tatsuya On Tue, Jun 12, 2012 at 1:53 PM, Dick Hardt wrote: > > On Jun 11, 2012, at 9:05 PM, Manger, James H wrote: > > 6. The initialization vector (IV) and authentication tag associated > > with an AEAD algorithm are prepended, and appended to the ciphertext > > > I'm writing in JavaScript. The UTF-8 parsing is a non-issue for me. :) > > Splitting a byte array can be done, but is not as straightforward. :( > > > You can easily concatenate the data together for your implementation. I > looked at a few JS > crypto libraries and they had different parameter > passing mechanisms. > > > Could you share a few links to JavaScript Crypto APIs. > > > These are battle tested libraries: > > http://code.google.com/p/crypto-js/ > http://nodejs.org/api/crypto.html > > > Dick (and other implementers), > It sounds like you have written a JavaScript JOSE library. Does it implem= ent > AES GCM? Does it check the IV and authentication tag lengths? (and no > cheating by adding the checks before answering ;-) > > > I have not yet had to implement JWE, only JWS so far.=A0I am currently > specifying JWE for a major project (and hope the spec settles!) > > FYI: I recall seeing a few implementations in JS on GitHub. I know the > Mozilla guys built a JS library for node.js for their BrowserID project. > > -- Dick > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 HAYASHI, Tatsuya Lepidum Co. Ltd. From ietf@augustcellars.com Sun Jun 17 20: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 D48D421F8602 for ; Sun, 17 Jun 2012 20:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+Mn-qfRliGI for ; Sun, 17 Jun 2012 20:19:22 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA7B21F85F2 for ; Sun, 17 Jun 2012 20:19:21 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 3C9182C9BC; Sun, 17 Jun 2012 20:19:21 -0700 (PDT) From: "Jim Schaad" To: "'Vladimir Dzhuvinov / NimbusDS'" , "'Manger, James H'" References: <20120613000215.cc40c4f3d92d2001859047cd8cabb9ab.5a32b7a273.wbe@email07.europe.secureserver.net> In-Reply-To: <20120613000215.cc40c4f3d92d2001859047cd8cabb9ab.5a32b7a273.wbe@email07.europe.secureserver.net> Date: Sun, 17 Jun 2012 20:17:54 -0700 Message-ID: <002201cd4d00$fc3b35d0$f4b1a170$@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: AQHf/vbljPqupnMBCuGZOebdpZs8apbZ99Lg Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] draft-manger-jose-jwsec 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, 18 Jun 2012 03:19:22 -0000 I think that this question may be of relevance for the current specification as well. What happens if I put an encryption algorithm in the alg field but do signature processing? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Vladimir Dzhuvinov / NimbusDS > Sent: Wednesday, June 13, 2012 12:02 AM > To: Manger, James H > Cc: jose@ietf.org > Subject: Re: [jose] draft-manger-jose-jwsec > > Hi James, > > What should happen when there is a mismatch between the "S"/"E"/... > prefix and the actual type of the applied algorithm? > > > Cheers, > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Sun Jun 17 20:21:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B0111E8083 for ; Sun, 17 Jun 2012 20:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PX41nEyB3v4 for ; Sun, 17 Jun 2012 20:21:03 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93D1C21F8608 for ; Sun, 17 Jun 2012 20:21:01 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.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 A52D92CA0D; Sun, 17 Jun 2012 20:21:00 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Richard L. Barnes'" References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366551A9E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366551A9E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 17 Jun 2012 20:19:45 -0700 Message-ID: <000001cd4d01$377d7f90$a6787eb0$@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: AQJ6s2P3lJsknAEva6+8prWEcJez9QIZryYEAdf0JN+VhQLIIA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 03:21:05 -0000 While I agree that there are issues that have been amply demonstrated with XML and canonicalization. I don't know that I would completely agree with the fact that no canonicalization algorithm has been defined. I believe that there may be a benefit in having a canonicalization for writing out the JSON, and then transporting the canonicalized version of the JSON structure to the recipient. The problem with XML was that the recipient had to read in the structure and then attempt to perform the same canonicalization as the sender did. Note that CMS does not require that the same steps as occur as for XML, however S/MIME does say that one needs to canonicalize the body before performing the hash functions. However there is a requirement that the body not be changed in transport and that the recipient can just use the string received. I am not convinced that the JOSE work is not going to need to require that a new serialization/de-serialization functions are not going to be required to be written in order for the system to be secure. Already the documents are imposing requirements on the serialization process that are not in the core JSON documents and thus it may not be reasonable to assume that the standard code will work correctly. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Friday, June 15, 2012 5:08 PM > To: Richard L. Barnes > Cc: jose@ietf.org > Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose- > jsms-00.txt > > Hi Richard, > > Since your message has been kicking around in the back of my mind, I'll add > one more data point on the "Not being JSON" comment. As the designers of > JWT and the resulting JOSE specs saw it, there were two clear choices to able > to sign/encrypt JSON data structures: > > (1) Define a canonicalization algorithm and always operate on the canonical > forms > (2) Base64 encode a representation of the data structure to preserve the > precise representation > > XML Canonicalization has proven to be a horror, leading to more > interoperability problems than any other aspect of XMLDSIG, XMLENC, > SAML, or WS-*. > > We chose #2. :-) > > -- Mike > > -----Original Message----- > From: Mike Jones > Sent: Friday, June 15, 2012 3:32 PM > To: 'Richard L. Barnes' > Cc: jose@ietf.org > Subject: RE: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms- > 00.txt > > Fair enough. I'll briefly respond to each in turn. Before doing so, I'll say that > I'm writing in the spirit of trying to increase mutual understanding and > consensus, rather than taking the point of view that the status quo is the > only reasonable outcome. > > -- Not being JSON > > This was by design, so that the results are URL-safe. This is required, for > instance, for them to be used as OAuth Bearer Tokens. At the request of the > working group, closely related pure-JSON drafts were also published. See: > > http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization - > 01 and > http://tools.ietf.org/html/draft-jones-json-web-encryption-json- > serialization-01 > > Use them if you prefer if they better suit your use cases. They could be > adopted as working group documents, if there's interest. > > -- Not supporting multiple recipients > > The JSON serialization drafts above do, again, in response to use cases > presented by the working group. > > -- Lacking clear distinctions between signing and MAC > > Functionally, these are very similar operations, at least from an > implementation perspective, so it's not clear that making a clear distinction > would help either developers or adoption in any practical way. They achieve > overlapping, but admittedly sometimes different goals. I believe that > developers can be trusted to use the algorithms that achieve their > applications' goals without making a hard distinction between the two. But > I'd be interested in hearing your thoughts on why you believe a brighter-line > distinction might be useful or necessary. > > -- Lacking clear processing instructions for different key establishment > modalities > > This seems like an area where the existing drafts could be refined to add > descriptions for additional establishment modalities, possibly based upon > your ideas and descriptions, should the working group decide to do so. What > additional modalities do you have use cases for that you believe are not > achievable or straightforward with the existing drafts? The existing > modalities supported are largely those that existing developers had told us > they needed and draw both from the precursor draft-jones-json-web-* > documents and draft-rescorla-jsms. > > Bear in mind that the balance that the current drafts try to strike is keeping > the Mandatory to Implement (MTI) feature footprint small enough that > developers, including Web developers, are likely to adopt the specs, while > still providing enough functionality to make them generally useful. As in any > balance, it's often possible to shift things a bit and still maintain the balance, > but I'd like people to keep the ubiquitous adoption goal front-and-center > when proposing additional functionality. > > Ubiquitous deployment and usefulness trump theoretical completeness. > (Just look at XMLDSIG and XMLENC to understand that!) > > -- Lack of clear typing of objects > > Most JSON documents aren't clearly typed; instead, developers and > implementations understand from context what the meaning of each field is. > XML is clearly typed, but developers are voting with their feet by moving to > JSON. > > What practical advantages resulting from overlaying a typing infrastructure > on JSON do you believe are worth the potential costs of doing so? BTW, I'm > not opposed to having a JSON schema description of the JOSE JSON data > structures like JSMS did in http://tools.ietf.org/html/draft-rescorla-jsms- > 00#appendix-A, but I'll remark that this an informative tool, not a normative > one. > > -- Lack of versioning for future extensibility > > An optional version field could be added if the working group desires, > however the last time the working group discussed it, they decided not to do > so. Rather, specs like this effectively become "versioned" when revised in a > way that new fields are added. If you understand the new fields, you > support that new version. (Note that this is independent of whether there is > a version number field, which according to some participants in the previous > discussion, they regarded as therefore being redundant information.) > > I'm not religious about not having a version number field, but often "less is > more". > > Best wishes, > -- Mike > > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Friday, June 15, 2012 3:00 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose- > jsms-00.txt > > Ok, so maybe I should have phrased my lead-in differently. IMO, the current > JW* specs are deficient in several ways, e.g.: > -- Not being JSON > -- Not supporting multiple recipients > -- Lacking clear distinctions between signing and MAC > -- Lacking clear processing instructions for different key establishment > modalities > -- Lack of clear typing of objects > -- Lack of versioning for future extensibility > > Looking at the current specs, it didn't seem to me that it would be simple to > adapt them to address these deficiencies. So I just did a re-write. If you > think they can be addressed within the current framework, please explain. I > just found it simpler to start from whole cloth. > > Cheers, > --Richard > > > > On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > > > Hi Richard, > > > > If you're puzzled by specific design decisions in the JOSE documents, I > encourage you to ask about them on the list. The documents have significant > history going back to mid-2010 when convergence discussions started among > people with four different JSON signing & encryption proposals. JWT and the > current JOSE specs and implementations are the result. I realize that not all > the JOSE participants were part of those discussions from the beginning > (although many were) and so teasing out the rationale for specific decisions > might help people better understand the choices made, and hopefully > thereby increase consensus behind the eventual working group choices. > > > > If the list that you're puzzled by is the bulleted list below, maybe we can > start a discussion on that basis. > > > > Best wishes, > > -- Mike > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of Richard L. Barnes > > Sent: Friday, June 15, 2012 2:08 PM > > To: jose@ietf.org > > Subject: [jose] Fwd: New Version Notification for > > draft-barnes-jose-jsms-00.txt > > > > Dear JOSE WG, > > > > Like Mr. Manger, once I finally got around to doing a thorough review of > the JW* specs, I was kind of puzzled by some of the design decisions. So I > also went through and wrote an alternative format, this time taking a more > of a cue from CMS. A link to the document is below. > > > > Summary of differences: > > > > o JSMS is pure JSON, whereas in JWE and JWS only the header > > parameters are represented in JSON. > > > > o JSMS allows for full algorithm agility in key agreement, while JWE > > only allows ECDH-ES. > > > > o JSMS supports multiple recipients for EncryptedData and > > AuthenticatedData objects via the inclusion of multiple WrappedKey > > objects. Sending a JWE to multiple recipients requires re- > > encryption of the entire object for each recipient. > > > > o The signature and MAC functions of the JWS object are separated > > into SignedData and AuthenticatedData JSMS objects. > > > > o JSMS parameters are not integrity-protected, as they are in JWE > > and JWS. > > > > o The "typ" and "zip" parameters are not defined in JSMS, but could > > be added without significant change. > > > > o JSMS requires that recipients MUST ignore unknown header > > parameters, in order to facilitate extensibility. > > > > I've also thrown together an initial JavaScript implementation (based on > NodeJS for some python crypto glue), which is on github: > > > > > > Comments are very welcome. > > > > Thanks, > > --Richard > > > > > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt > >> Date: June 15, 2012 4:56:09 PM EDT > >> To: rbarnes@bbn.com > >> > >> > >> A new version of I-D, draft-barnes-jose-jsms-00.txt has been > >> successfully submitted by Richard Barnes and posted to the IETF > >> repository. > >> > >> Filename: draft-barnes-jose-jsms > >> Revision: 00 > >> Title: JavaScript Message Security Format > >> Creation date: 2012-06-15 > >> WG ID: Individual Submission > >> Number of pages: 25 > >> URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms- > 00.txt > >> Status: http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > >> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 > >> > >> > >> Abstract: > >> Many applications require the ability to send cryptographically > >> secured messages. While the IETF has defined a number of formats for > >> such messages (e.g. CMS) those formats use encodings which are not > >> easy to use in modern applications. This document describes the > >> JavaScript Message Security format (JSMS), a new cryptographic > >> message format which is based on JavaScript Object Notation (JSON) > >> and thus is easy for many applications to generate and parse. > >> > >> > >> > >> > >> The IETF Secretariat > > > > _______________________________________________ > > 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 From vladimir@nimbusds.com Mon Jun 18 01:00: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 77CBF21F863E for ; Mon, 18 Jun 2012 01:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiK5ndfNb44W for ; Mon, 18 Jun 2012 01:00:16 -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 308B721F8638 for ; Mon, 18 Jun 2012 01:00:15 -0700 (PDT) Received: (qmail 14946 invoked from network); 18 Jun 2012 08:00:14 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 18 Jun 2012 08:00:11 -0000 Received: (qmail 22738 invoked by uid 99); 18 Jun 2012 08:00:11 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.139.44 User-Agent: Workspace Webmail 5.6.19 Message-Id: <20120618010010.cc40c4f3d92d2001859047cd8cabb9ab.0fa100781e.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "HAYASHI, Tatsuya" , jose@ietf.org Date: Mon, 18 Jun 2012 01:00:10 -0700 Mime-Version: 1.0 Subject: Re: [jose] draft-manger-jose-jwsec: IV ciphertext tag 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, 18 Jun 2012 08:00:17 -0000 Cheers, this is very good news to us! Right now, if an JavaScript app=0Anee= d to do JWT verification in the browser it has to load a whole bunch=0Aof m= aths + crypto lib code, and this obviously cannot run at native=0Aspeed. = =0A=0AI hope they'll do a good job!=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvi= nov : www.NimbusDS.com : vladimir@nimbusds.com=0A =0A=0A=0A=0A=0A=0A=0A=0A-= ------- Original Message --------=0ASubject: Re: [jose] draft-manger-jose-j= wsec: IV ciphertext tag=0AFrom: "HAYASHI, Tatsuya" =0ADate: Sat, June 16, 2012 7:11 pm=0ATo: "Manger, James H" , jose@ietf.org=0ACc: Dick Hardt = =0A=0A=0AFYI:=0A=0AW3C (and IETF?) are doing relevant work now.=0A http://w= ww.w3.org/2012/webcrypto/=0A (based on Mozilla DOMCrypt)=0A=0A(sorry if wro= ng.)=0A=0A-- =0ATatsuya=0A=0AOn Tue, Jun 12, 2012 at 1:53 PM, Dick Hardt =0Awrote:=0A>=0A> On Jun 11, 2012, at 9:05 PM, Manger, = James H wrote:=0A>=0A> 6. The initialization vector (IV) and authentication= tag associated=0A>=0A> with an AEAD algorithm are prepended, and appended = to the ciphertext=0A>=0A>=0A> I'm writing in JavaScript. The UTF-8 parsing = is a non-issue for me. :)=0A>=0A> Splitting a byte array can be done, but i= s not as straightforward. :(=0A>=0A>=0A> You can easily concatenate the dat= a together for your implementation. I=0A> looked at a few JS > crypto libra= ries and they had different parameter=0A> passing mechanisms.=0A>=0A>=0A> C= ould you share a few links to JavaScript Crypto APIs.=0A>=0A>=0A> These are= battle tested libraries:=0A>=0A> http://code.google.com/p/crypto-js/=0A> h= ttp://nodejs.org/api/crypto.html=0A>=0A>=0A> Dick (and other implementers),= =0A> It sounds like you have written a JavaScript JOSE library. Does it imp= lement=0A> AES GCM? Does it check the IV and authentication tag lengths? (a= nd no=0A> cheating by adding the checks before answering ;-)=0A>=0A>=0A> I = have not yet had to implement JWE, only JWS so far. I am currently=0A> spec= ifying JWE for a major project (and hope the spec settles!)=0A>=0A> FYI: I = recall seeing a few implementations in JS on GitHub. I know the=0A> Mozilla= guys built a JS library for node.js for their BrowserID project.=0A>=0A> -= - Dick=0A>=0A>=0A> _______________________________________________=0A> jose= mailing list=0A> jose@ietf.org=0A> https://www.ietf.org/mailman/listinfo/j= ose=0A>=0A=0A=0A=0A-- =0AHAYASHI, Tatsuya=0ALepidum Co. Ltd.=0A____________= ___________________________________=0Ajose mailing list=0Ajose@ietf.org=0Ah= ttps://www.ietf.org/mailman/listinfo/jose=0A From vladimir@nimbusds.com Mon Jun 18 01:24: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 EE69D21F84AF for ; Mon, 18 Jun 2012 01:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kct-BbbEUkN1 for ; Mon, 18 Jun 2012 01:24: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 96F4E21F8550 for ; Mon, 18 Jun 2012 01:24:23 -0700 (PDT) Received: (qmail 17412 invoked from network); 18 Jun 2012 08:24:21 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 18 Jun 2012 08:24:20 -0000 Received: (qmail 16037 invoked by uid 99); 18 Jun 2012 08:24:20 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.139.44 User-Agent: Workspace Webmail 5.6.19 Message-Id: <20120618012419.cc40c4f3d92d2001859047cd8cabb9ab.35d9904f72.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: Cc: jose@ietf.org Date: Mon, 18 Jun 2012 01:24:19 -0700 Mime-Version: 1.0 Subject: Re: [jose] draft-manger-jose-jwsec 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, 18 Jun 2012 08:24:25 -0000 Hi Jim,=0A=0ASignature verification should obviously fail.=0A=0AOur Nimbus-= JWT library has an enum of all supported algs and their type=0A(JWS/JWE), s= o this error is detected fairly early in the process.=0A=0AI was however wo= ndering about James' use case for having the prefix - to=0Aallow routers an= d firewalls to inspect the security of the message. I=0Anow realise that th= is method is rather limited, as the message may still=0Abe invalid. But the= n, I don't know what inspection depth he seeks to=0Ahave.=0A=0AVladimir=0A= =0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A= =0A=0A-------- Original Message --------=0ASubject: RE: [jose] draft-manger= -jose-jwsec=0AFrom: "Jim Schaad" =0ADate: Mon, June= 18, 2012 4:17 am=0ATo: "'Vladimir Dzhuvinov / NimbusDS'" ,=0A"'Manger, James H'" =0ACc: =0A=0A=0A=0A=0AI think that this question may be of relev= ance for the current=0Aspecification=0Aas well. What happens if I put an en= cryption algorithm in the alg field=0Abut=0Ado signature processing?=0A=0AJ= im=0A=0A=0A> -----Original Message-----=0A> From: jose-bounces@ietf.org [ma= ilto:jose-bounces@ietf.org] On Behalf Of=0A> Vladimir Dzhuvinov / NimbusDS= =0A> Sent: Wednesday, June 13, 2012 12:02 AM=0A> To: Manger, James H=0A> Cc= : jose@ietf.org=0A> Subject: Re: [jose] draft-manger-jose-jwsec=0A> =0A> Hi= James,=0A> =0A> What should happen when there is a mismatch between the "S= "/"E"/...=0A> prefix and the actual type of the applied algorithm?=0A> =0A>= =0A> Cheers,=0A> =0A> Vladimir=0A> =0A> --=0A> Vladimir Dzhuvinov : www.Ni= mbusDS.com : vladimir@nimbusds.com=0A> =0A> =0A> __________________________= _____________________=0A> jose mailing list=0A> jose@ietf.org=0A> https://w= ww.ietf.org/mailman/listinfo/jose=0A From rbarnes@bbn.com Mon Jun 18 19:02: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 C2A4511E80D7 for ; Mon, 18 Jun 2012 19:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilbneTGO2e83 for ; Mon, 18 Jun 2012 19:02:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEAC11E8097 for ; Mon, 18 Jun 2012 19:02:46 -0700 (PDT) Received: from [128.89.253.228] (port=64666) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sgnlf-000M1Q-4U; Mon, 18 Jun 2012 22:02:07 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard L. Barnes In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 18 Jun 2012 22:02:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 02:02:47 -0000 Hey Mike, Thanks for having some back-and-forth with me on this. I think this is = a good discussion to have right now. I would like to discuss some = high-level points, and then I'll respond inline to your precise points. tl;dr: In order to meet its deliverables, the WG needs to define = JSON-based formats for integrity and confidentiality protections. JWE = and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates. Major points: 1. JOSE is JSON 2. JSON does not imply canonicalization 3. Compactness and URL-safeness are still OK, as derivatives Part 1: JOSE is JSON The JOSE WG charter calls out four deliverables, three of which are = explicitly required to be JSON: -- "JSON-structured integrity protection" -- "JSON-structured encryption" -- "public keys as JSON-structured objects" (The fourth is just a list of algorithms, which should be JSON as well, = just as RFC 3370 is ASN.1.) In light of these requirements, JWE and JWS are clearly not suitable = candidates to fulfill the working group's milestones. (At least in = their current form.) So ISTM that we need to step back and re-evaluate = alternatives for the three above milestones, especially the first two. = (JWK is not as far off.) As JSON-based mechanisms, though, the "JSON serialization" drafts are = pretty half-hearted. Because JWS and JWE include the cryptographic = parameters within the integrity protection, they have to have the = headers included as base64-encoded strings. That obviously adds a lot = of complexity to encoding and decoding -- for example, you have to keep = the encoded header around even after you've decoded it! -- and just = plain more octets. The support for multiple recipients and multiple = signatures is both unweildy (matching up parallel indices for headers = and signatures) and inefficient (multiple integrity check values in = encrypted objects). By contrast, JSMS takes advantage of the cryptographic wisdom that went = into CMS, while making the syntax pure JSON and as simple as possible. = Multiple signatures and multiple recipients are supported with absolute = minimum overhead. So I think it's worth consideration by the working = group. Part 2: JSON !=3D> canonicalization I would like to dispel the myth that a JSON-based format requires = canonicalization. In JWE/JWS, the JSON header requires = "canonicalization" (via base64url encoding) because it's included within = the integrity protection. I'm not aware of any reason for including the = cryptographic parameters in the integrity check, instead of only = integrity-protecting the content itself. Indeed, if there were an = attack based on non-integrity-protected cryptographic parameters, it = would be a pretty big deal, since neither CMS nor IKE nor provides this = protection. (TLS does provide a signature over the algorithms, but only = as a way to bind the public key to the session.) Indeed CMS doesn't require canonicalization at all, except for = attributes that are included in the protected content (signedAttrs / = authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't = allow those parameters, so there is no need for canonicalization at all. = All the "canonicalization" that's needed is to base64url-encode the = protected content. In that regard, JSMS is even simpler than JWE/JWS. Part 3: Compactness and URL-safeness are still OK, as derivatives I have absolutely no objection to defining a compact, URL-safe format. = Indeed, I did so in the JSMS draft, in Section 5. Encoding the example = from Section 3.1 of the JWS spec, we get the following JSMS object: {=20 "v":1, "t":"au", "a":"hs256", "c":"eyJpc3MiOiJqb2...0cnVlfQ", "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", "ki":"rSIilRk8Ego" } If we remove the decorative spaces and base64url-encode, we only use 88 = octets more than JWS (267 vs. 179). If we take this a step further and = define an explicit compact format for AuthenticatedData, we can emulate = JWS by moving the content and MAC fields outside and dot-combining. = That avoids double-base64url-encoding, and only takes up 11 more octets = than a JWS (190 vs 179). (I've put the code to generate these in the = Github project linked earlier.) So it's fine to have a compact, URL-safe format for an objective, but it = makes *much* more sense to derive that from a full-size, usable, JSON = format than the other way around. Responses to specific points inline below. > Fair enough. I'll briefly respond to each in turn. Before doing so, = I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >=20 > -- Not being JSON >=20 > This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >=20 > = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 and > = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 >=20 > Use them if you prefer if they better suit your use cases. They could = be adopted as working group documents, if there's interest. See above. These are super-clunky, and the need to be the main focus of = the WG, not an afterthought. > -- Not supporting multiple recipients >=20 > The JSON serialization drafts above do, again, in response to use = cases presented by the working group. See above. Because of the unnecessary inclusion of the header in the = integrity check, this is far less efficient than it should be. > -- Lacking clear distinctions between signing and MAC >=20 > Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. It's important if you want to do MACs with anything other than = pre-shared keys. If you want to do anything more advanced, you need to = have wrapped keys, in which case an object with a MAC starts to look a = lot more like a JWE than a JWS. > -- Lacking clear processing instructions for different key = establishment modalities >=20 > This seems like an area where the existing drafts could be refined to = add descriptions for additional establishment modalities, possibly based = upon your ideas and descriptions, should the working group decide to do = so. What additional modalities do you have use cases for that you = believe are not achievable or straightforward with the existing drafts? = The existing modalities supported are largely those that existing = developers had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and draft-rescorla-jsms. >=20 > Bear in mind that the balance that the current drafts try to strike is = keeping the Mandatory to Implement (MTI) feature footprint small enough = that developers, including Web developers, are likely to adopt the = specs, while still providing enough functionality to make them generally = useful. As in any balance, it's often possible to shift things a bit = and still maintain the balance, but I'd like people to keep the = ubiquitous adoption goal front-and-center when proposing additional = functionality. >=20 > Ubiquitous deployment and usefulness trump theoretical completeness. = (Just look at XMLDSIG and XMLENC to understand that!)=20 I agree that we need to find a reasonable MTI. The current JSMS draft = doesn't really specify which parts are MTI, beyond basic things like = base64url encoding and ignoring unknown fields. My main concern is that JWS and JWE don't really tell me which fields = need to be present for which use case. If I'm putting a MAC on a JWS = vs. a signature, do I need "jwk" or "jku" fields to be populated? = Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into sub-objects. > -- Lack of clear typing of objects >=20 > Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >=20 > What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. I actualy don't have a hugely urgent requirement here either. It's = something that others in the WG had requested, which is trivial to add = in JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity protection of the header. > -- Lack of versioning for future extensibility >=20 > An optional version field could be added if the working group desires, = however the last time the working group discussed it, they decided not = to do so. Rather, specs like this effectively become "versioned" when = revised in a way that new fields are added. If you understand the new = fields, you support that new version. (Note that this is independent of = whether there is a version number field, which according to some = participants in the previous discussion, they regarded as therefore = being redundant information.) >=20 > I'm not religious about not having a version number field, but often = "less is more". Indeed, I'm not religious either. It just seems like a general good = idea to state this directly as opposed to having parsers divine it based = on which fields are present. To quote RFC 5652: " Each of the major data structures includes a version number as the first item in the data structure. The version numbers are intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and if a decode error occurs, then the version number is checked as part of the error handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender. " Best, --Richard >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 > Sent: Friday, June 15, 2012 3:00 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > Ok, so maybe I should have phrased my lead-in differently. IMO, the = current JW* specs are deficient in several ways, e.g.: > -- Not being JSON > -- Not supporting multiple recipients > -- Lacking clear distinctions between signing and MAC > -- Lacking clear processing instructions for different key = establishment modalities > -- Lack of clear typing of objects > -- Lack of versioning for future extensibility >=20 > Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >=20 > Cheers, > --Richard >=20 >=20 >=20 > On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >=20 >> Hi Richard, >>=20 >> If you're puzzled by specific design decisions in the JOSE documents, = I encourage you to ask about them on the list. The documents have = significant history going back to mid-2010 when convergence discussions = started among people with four different JSON signing & encryption = proposals. JWT and the current JOSE specs and implementations are the = result. I realize that not all the JOSE participants were part of those = discussions from the beginning (although many were) and so teasing out = the rationale for specific decisions might help people better understand = the choices made, and hopefully thereby increase consensus behind the = eventual working group choices. >>=20 >> If the list that you're puzzled by is the bulleted list below, maybe = we can start a discussion on that basis. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20= >> Of Richard L. Barnes >> Sent: Friday, June 15, 2012 2:08 PM >> To: jose@ietf.org >> Subject: [jose] Fwd: New Version Notification for=20 >> draft-barnes-jose-jsms-00.txt >>=20 >> Dear JOSE WG, >>=20 >> Like Mr. Manger, once I finally got around to doing a thorough review = of the JW* specs, I was kind of puzzled by some of the design decisions. = So I also went through and wrote an alternative format, this time = taking a more of a cue from CMS. A link to the document is below. >>=20 >> Summary of differences: >>=20 >> o JSMS is pure JSON, whereas in JWE and JWS only the header >> parameters are represented in JSON. >>=20 >> o JSMS allows for full algorithm agility in key agreement, while = JWE >> only allows ECDH-ES. >>=20 >> o JSMS supports multiple recipients for EncryptedData and >> AuthenticatedData objects via the inclusion of multiple = WrappedKey >> objects. Sending a JWE to multiple recipients requires re- >> encryption of the entire object for each recipient. >>=20 >> o The signature and MAC functions of the JWS object are separated >> into SignedData and AuthenticatedData JSMS objects. >>=20 >> o JSMS parameters are not integrity-protected, as they are in JWE >> and JWS. >>=20 >> o The "typ" and "zip" parameters are not defined in JSMS, but could >> be added without significant change. >>=20 >> o JSMS requires that recipients MUST ignore unknown header >> parameters, in order to facilitate extensibility. >>=20 >> I've also thrown together an initial JavaScript implementation (based = on NodeJS for some python crypto glue), which is on github: >> >>=20 >> Comments are very welcome. =20 >>=20 >> Thanks, >> --Richard >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >>> Date: June 15, 2012 4:56:09 PM EDT >>> To: rbarnes@bbn.com >>>=20 >>>=20 >>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >>> successfully submitted by Richard Barnes and posted to the IETF=20 >>> repository. >>>=20 >>> Filename: draft-barnes-jose-jsms >>> Revision: 00 >>> Title: JavaScript Message Security Format >>> Creation date: 2012-06-15 >>> WG ID: Individual Submission >>> Number of pages: 25 >>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>=20 >>>=20 >>> Abstract: >>> Many applications require the ability to send cryptographically =20 >>> secured messages. While the IETF has defined a number of formats = for =20 >>> such messages (e.g. CMS) those formats use encodings which are not =20= >>> easy to use in modern applications. This document describes the =20 >>> JavaScript Message Security format (JSMS), a new cryptographic =20 >>> message format which is based on JavaScript Object Notation (JSON) =20= >>> and thus is easy for many applications to generate and parse. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From tonynad@microsoft.com Tue Jun 19 08:33: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 B8A3B21F8540 for ; Tue, 19 Jun 2012 08:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUyOpMXyd1x6 for ; Tue, 19 Jun 2012 08:33:33 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id AC92B11E8099 for ; Tue, 19 Jun 2012 08:33:33 -0700 (PDT) Received: from mail176-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Jun 2012 15:32:11 +0000 Received: from mail176-ch1 (localhost [127.0.0.1]) by mail176-ch1-R.bigfish.com (Postfix) with ESMTP id E35921E01AF for ; Tue, 19 Jun 2012 15:32:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zz98dI9371I936eI168aJ148cI542M1432I41c5N4015Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail176-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail176-ch1 (localhost.localdomain [127.0.0.1]) by mail176-ch1 (MessageSwitch) id 1340119928346760_4530; Tue, 19 Jun 2012 15:32:08 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail176-ch1.bigfish.com (Postfix) with ESMTP id 52C16180046 for ; Tue, 19 Jun 2012 15:32:08 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Jun 2012 15:32:06 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 19 Jun 2012 15:33:10 +0000 Received: from mail106-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Jun 2012 15:31:16 +0000 Received: from mail106-va3 (localhost [127.0.0.1]) by mail106-va3-R.bigfish.com (Postfix) with ESMTP id 6A8C116084A for ; Tue, 19 Jun 2012 15:21:18 +0000 (UTC) Received: from mail106-va3 (localhost.localdomain [127.0.0.1]) by mail106-va3 (MessageSwitch) id 1340119276126137_8503; Tue, 19 Jun 2012 15:21:16 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.250]) by mail106-va3.bigfish.com (Postfix) with ESMTP id 1A4C21401BA; Tue, 19 Jun 2012 15:21:16 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Jun 2012 15:21:13 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.180]) by BL2PRD0310HT005.namprd03.prod.outlook.com ([10.255.97.40]) with mapi id 14.16.0152.000; Tue, 19 Jun 2012 15:22:34 +0000 From: Anthony Nadalin To: Richard L.Barnes , Mike Jones Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: AQHNTb+1XOiINfZfTkKBZtMrv63E2JcBr/pw Date: Tue, 19 Jun 2012 15:22:33 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%BBN.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: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:33:35 -0000 That is certainly a unique interpretation, which I would have to disagree w= ith based upon the charter, as the charter does state as you point out "JSO= N-structured" and not "JSON-based". I'm still struggling to understand your= issues with the current drafts. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L.Barnes Sent: Monday, June 18, 2012 7:03 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt Hey Mike, Thanks for having some back-and-forth with me on this. I think this is a g= ood discussion to have right now. I would like to discuss some high-level = points, and then I'll respond inline to your precise points. tl;dr: In order to meet its deliverables, the WG needs to define JSON-based= formats for integrity and confidentiality protections. JWE and JWS don't = fit that requirement, so we should re-consider their adoption and call for = new candidates. Major points: 1. JOSE is JSON 2. JSON does not imply canonicalization 3. Compactness and URL-safeness are still OK, as derivatives Part 1: JOSE is JSON The JOSE WG charter calls out four deliverables, three of which are explici= tly required to be JSON: -- "JSON-structured integrity protection" -- "JSON-structured encryption" -- "public keys as JSON-structured objects" (The fourth is just a list of algorithms, which should be JSON as well, jus= t as RFC 3370 is ASN.1.) In light of these requirements, JWE and JWS are clearly not suitable candid= ates to fulfill the working group's milestones. (At least in their current= form.) So ISTM that we need to step back and re-evaluate alternatives for= the three above milestones, especially the first two. (JWK is not as far = off.) As JSON-based mechanisms, though, the "JSON serialization" drafts are prett= y half-hearted. Because JWS and JWE include the cryptographic parameters w= ithin the integrity protection, they have to have the headers included as b= ase64-encoded strings. That obviously adds a lot of complexity to encoding= and decoding -- for example, you have to keep the encoded header around ev= en after you've decoded it! -- and just plain more octets. The support for= multiple recipients and multiple signatures is both unweildy (matching up = parallel indices for headers and signatures) and inefficient (multiple inte= grity check values in encrypted objects). By contrast, JSMS takes advantage of the cryptographic wisdom that went int= o CMS, while making the syntax pure JSON and as simple as possible. Multip= le signatures and multiple recipients are supported with absolute minimum o= verhead. So I think it's worth consideration by the working group. Part 2: JSON !=3D> canonicalization I would like to dispel the myth that a JSON-based format requires canonical= ization. In JWE/JWS, the JSON header requires "canonicalization" (via base= 64url encoding) because it's included within the integrity protection. I'm= not aware of any reason for including the cryptographic parameters in the = integrity check, instead of only integrity-protecting the content itself. = Indeed, if there were an attack based on non-integrity-protected cryptograp= hic parameters, it would be a pretty big deal, since neither CMS nor IKE no= r provides this protection. (TLS does provide a signature over the algorit= hms, but only as a way to bind the public key to the session.) Indeed CMS doesn't require canonicalization at all, except for attributes t= hat are included in the protected content (signedAttrs / authenticatedAttrs= ), which need to be DER-encoded. In JSMS, we don't allow those parameters,= so there is no need for canonicalization at all. All the "canonicalizatio= n" that's needed is to base64url-encode the protected content. In that reg= ard, JSMS is even simpler than JWE/JWS. Part 3: Compactness and URL-safeness are still OK, as derivatives I have absolutely no objection to defining a compact, URL-safe format. Ind= eed, I did so in the JSMS draft, in Section 5. Encoding the example from S= ection 3.1 of the JWS spec, we get the following JSMS object: {=20 "v":1, "t":"au", "a":"hs256", "c":"eyJpc3MiOiJqb2...0cnVlfQ", "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", "ki":"rSIilRk8Ego" } If we remove the decorative spaces and base64url-encode, we only use 88 oct= ets more than JWS (267 vs. 179). If we take this a step further and define= an explicit compact format for AuthenticatedData, we can emulate JWS by mo= ving the content and MAC fields outside and dot-combining. That avoids dou= ble-base64url-encoding, and only takes up 11 more octets than a JWS (190 vs= 179). (I've put the code to generate these in the Github project linked e= arlier.) So it's fine to have a compact, URL-safe format for an objective, but it ma= kes *much* more sense to derive that from a full-size, usable, JSON format = than the other way around. Responses to specific points inline below. > Fair enough. I'll briefly respond to each in turn. Before doing so, I'l= l say that I'm writing in the spirit of trying to increase mutual understan= ding and consensus, rather than taking the point of view that the status qu= o is the only reasonable outcome. >=20 > -- Not being JSON >=20 > This was by design, so that the results are URL-safe. This is required, = for instance, for them to be used as OAuth Bearer Tokens. At the request o= f the working group, closely related pure-JSON drafts were also published. = See: >=20 > http://tools.ietf.org/html/draft-jones-json-web-signature-json-seriali > zation-01 and > http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serial > ization-01 >=20 > Use them if you prefer if they better suit your use cases. They could be= adopted as working group documents, if there's interest. See above. These are super-clunky, and the need to be the main focus of th= e WG, not an afterthought. > -- Not supporting multiple recipients >=20 > The JSON serialization drafts above do, again, in response to use cases p= resented by the working group. See above. Because of the unnecessary inclusion of the header in the integ= rity check, this is far less efficient than it should be. > -- Lacking clear distinctions between signing and MAC >=20 > Functionally, these are very similar operations, at least from an impleme= ntation perspective, so it's not clear that making a clear distinction woul= d help either developers or adoption in any practical way. They achieve ov= erlapping, but admittedly sometimes different goals. I believe that develo= pers can be trusted to use the algorithms that achieve their applications' = goals without making a hard distinction between the two. But I'd be intere= sted in hearing your thoughts on why you believe a brighter-line distinctio= n might be useful or necessary. It's important if you want to do MACs with anything other than pre-shared k= eys. If you want to do anything more advanced, you need to have wrapped ke= ys, in which case an object with a MAC starts to look a lot more like a JWE= than a JWS. > -- Lacking clear processing instructions for different key=20 > establishment modalities >=20 > This seems like an area where the existing drafts could be refined to add= descriptions for additional establishment modalities, possibly based upon = your ideas and descriptions, should the working group decide to do so. Wha= t additional modalities do you have use cases for that you believe are not = achievable or straightforward with the existing drafts? The existing modal= ities supported are largely those that existing developers had told us they= needed and draw both from the precursor draft-jones-json-web-* documents a= nd draft-rescorla-jsms. >=20 > Bear in mind that the balance that the current drafts try to strike is ke= eping the Mandatory to Implement (MTI) feature footprint small enough that = developers, including Web developers, are likely to adopt the specs, while = still providing enough functionality to make them generally useful. As in = any balance, it's often possible to shift things a bit and still maintain t= he balance, but I'd like people to keep the ubiquitous adoption goal front-= and-center when proposing additional functionality. >=20 > Ubiquitous deployment and usefulness trump theoretical completeness. =20 > (Just look at XMLDSIG and XMLENC to understand that!) I agree that we need to find a reasonable MTI. The current JSMS draft does= n't really specify which parts are MTI, beyond basic things like base64url = encoding and ignoring unknown fields. My main concern is that JWS and JWE don't really tell me which fields need = to be present for which use case. If I'm putting a MAC on a JWS vs. a sign= ature, do I need "jwk" or "jku" fields to be populated? Whereas in JSMS, I= think these things are much clearer due to the separation of the use cases= (Signed/Authenticated/Encrypted) and the isolation of signatures and wrapp= ed keys into sub-objects. > -- Lack of clear typing of objects >=20 > Most JSON documents aren't clearly typed; instead, developers and impleme= ntations understand from context what the meaning of each field is. XML is= clearly typed, but developers are voting with their feet by moving to JSON= . >=20 > What practical advantages resulting from overlaying a typing infrastructu= re on JSON do you believe are worth the potential costs of doing so? BTW, = I'm not opposed to having a JSON schema description of the JOSE JSON data s= tructures like JSMS did in http://tools.ietf.org/html/draft-rescorla-jsms-0= 0#appendix-A, but I'll remark that this an informative tool, not a normativ= e one. I actualy don't have a hugely urgent requirement here either. It's somethi= ng that others in the WG had requested, which is trivial to add in JSMS, bu= t not in JWE/JWS -- again because of the unnecessary integrity protection o= f the header. > -- Lack of versioning for future extensibility >=20 > An optional version field could be added if the working group desires,=20 > however the last time the working group discussed it, they decided not=20 > to do so. Rather, specs like this effectively become "versioned" when=20 > revised in a way that new fields are added. If you understand the new=20 > fields, you support that new version. (Note that this is independent=20 > of whether there is a version number field, which according to some=20 > participants in the previous discussion, they regarded as therefore=20 > being redundant information.) >=20 > I'm not religious about not having a version number field, but often "les= s is more". Indeed, I'm not religious either. It just seems like a general good idea t= o state this directly as opposed to having parsers divine it based on which= fields are present. To quote RFC 5652: " Each of the major data structures includes a version number as the first item in the data structure. The version numbers are intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and if a decode error occurs, then the version number is checked as part of the error handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender. " Best, --Richard >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Friday, June 15, 2012 3:00 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] Fwd: New Version Notification for=20 > draft-barnes-jose-jsms-00.txt >=20 > Ok, so maybe I should have phrased my lead-in differently. IMO, the curr= ent JW* specs are deficient in several ways, e.g.: > -- Not being JSON > -- Not supporting multiple recipients > -- Lacking clear distinctions between signing and MAC > -- Lacking clear processing instructions for different key=20 > establishment modalities > -- Lack of clear typing of objects > -- Lack of versioning for future extensibility >=20 > Looking at the current specs, it didn't seem to me that it would be simpl= e to adapt them to address these deficiencies. So I just did a re-write. = If you think they can be addressed within the current framework, please exp= lain. I just found it simpler to start from whole cloth. >=20 > Cheers, > --Richard >=20 >=20 >=20 > On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >=20 >> Hi Richard, >>=20 >> If you're puzzled by specific design decisions in the JOSE documents, I = encourage you to ask about them on the list. The documents have significan= t history going back to mid-2010 when convergence discussions started among= people with four different JSON signing & encryption proposals. JWT and t= he current JOSE specs and implementations are the result. I realize that n= ot all the JOSE participants were part of those discussions from the beginn= ing (although many were) and so teasing out the rationale for specific deci= sions might help people better understand the choices made, and hopefully t= hereby increase consensus behind the eventual working group choices. >>=20 >> If the list that you're puzzled by is the bulleted list below, maybe we = can start a discussion on that basis. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >> Of Richard L. Barnes >> Sent: Friday, June 15, 2012 2:08 PM >> To: jose@ietf.org >> Subject: [jose] Fwd: New Version Notification for=20 >> draft-barnes-jose-jsms-00.txt >>=20 >> Dear JOSE WG, >>=20 >> Like Mr. Manger, once I finally got around to doing a thorough review of= the JW* specs, I was kind of puzzled by some of the design decisions. So = I also went through and wrote an alternative format, this time taking a mor= e of a cue from CMS. A link to the document is below. >>=20 >> Summary of differences: >>=20 >> o JSMS is pure JSON, whereas in JWE and JWS only the header >> parameters are represented in JSON. >>=20 >> o JSMS allows for full algorithm agility in key agreement, while JWE >> only allows ECDH-ES. >>=20 >> o JSMS supports multiple recipients for EncryptedData and >> AuthenticatedData objects via the inclusion of multiple WrappedKey >> objects. Sending a JWE to multiple recipients requires re- >> encryption of the entire object for each recipient. >>=20 >> o The signature and MAC functions of the JWS object are separated >> into SignedData and AuthenticatedData JSMS objects. >>=20 >> o JSMS parameters are not integrity-protected, as they are in JWE >> and JWS. >>=20 >> o The "typ" and "zip" parameters are not defined in JSMS, but could >> be added without significant change. >>=20 >> o JSMS requires that recipients MUST ignore unknown header >> parameters, in order to facilitate extensibility. >>=20 >> I've also thrown together an initial JavaScript implementation (based on= NodeJS for some python crypto glue), which is on github: >> >>=20 >> Comments are very welcome. =20 >>=20 >> Thanks, >> --Richard >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >>> Date: June 15, 2012 4:56:09 PM EDT >>> To: rbarnes@bbn.com >>>=20 >>>=20 >>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >>> successfully submitted by Richard Barnes and posted to the IETF=20 >>> repository. >>>=20 >>> Filename: draft-barnes-jose-jsms >>> Revision: 00 >>> Title: JavaScript Message Security Format >>> Creation date: 2012-06-15 >>> WG ID: Individual Submission >>> Number of pages: 25 >>> URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-= jsms-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>=20 >>>=20 >>> Abstract: >>> Many applications require the ability to send cryptographically=20 >>> secured messages. While the IETF has defined a number of formats=20 >>> for such messages (e.g. CMS) those formats use encodings which are=20 >>> not easy to use in modern applications. This document describes the=20 >>> JavaScript Message Security format (JSMS), a new cryptographic=20 >>> message format which is based on JavaScript Object Notation (JSON)=20 >>> and thus is easy for many applications to generate and parse. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > 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 rbarnes@bbn.com Tue Jun 19 08:39:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB82E21F8569 for ; Tue, 19 Jun 2012 08:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpr3rroipJm8 for ; Tue, 19 Jun 2012 08:39:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 199DE21F8567 for ; Tue, 19 Jun 2012 08:39:36 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:54991) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh0W9-0004ul-FR; Tue, 19 Jun 2012 11:38:57 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 19 Jun 2012 11:39:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:39:37 -0000 Not to rat-hole on semantics, but I have a hard time reading = "JSON-structured" as meaning something other than "compliant with RFC = 4627". And JWS/JWE objects are not. To again try to summarize major issues with the current drafts: 1. They're not JSON, thus not responsive to the charter 2. They include cryptographic parameters under integrity protection, = which means: 2.1. They essentially preclude a pure JSON encoding, unless there is = JSON canonicalization 2.2. It is very inefficient for them to support things like multiple = recipients=20 As a result of the above, they're very difficult to use for anything but = the simplest use cases. =20 My proposal would be for the WG to start from a format that (1) is JSON, = and (2) has simpler cryptographic processing. =46rom there, we can = profile down to something simpler, that looks more like JWE/JWS. = Existence proof is below. --Richard On Jun 19, 2012, at 11:22 AM, Anthony Nadalin wrote: > That is certainly a unique interpretation, which I would have to = disagree with based upon the charter, as the charter does state as you = point out "JSON-structured" and not "JSON-based". I'm still struggling = to understand your issues with the current drafts. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L.Barnes > Sent: Monday, June 18, 2012 7:03 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > Hey Mike, >=20 > Thanks for having some back-and-forth with me on this. I think this = is a good discussion to have right now. I would like to discuss some = high-level points, and then I'll respond inline to your precise points. >=20 > tl;dr: In order to meet its deliverables, the WG needs to define = JSON-based formats for integrity and confidentiality protections. JWE = and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates. >=20 > Major points: > 1. JOSE is JSON > 2. JSON does not imply canonicalization > 3. Compactness and URL-safeness are still OK, as derivatives >=20 > Part 1: JOSE is JSON >=20 > The JOSE WG charter calls out four deliverables, three of which are = explicitly required to be JSON: > -- "JSON-structured integrity protection" > -- "JSON-structured encryption" > -- "public keys as JSON-structured objects" > (The fourth is just a list of algorithms, which should be JSON as = well, just as RFC 3370 is ASN.1.) >=20 > In light of these requirements, JWE and JWS are clearly not suitable = candidates to fulfill the working group's milestones. (At least in = their current form.) So ISTM that we need to step back and re-evaluate = alternatives for the three above milestones, especially the first two. = (JWK is not as far off.) >=20 > As JSON-based mechanisms, though, the "JSON serialization" drafts are = pretty half-hearted. Because JWS and JWE include the cryptographic = parameters within the integrity protection, they have to have the = headers included as base64-encoded strings. That obviously adds a lot = of complexity to encoding and decoding -- for example, you have to keep = the encoded header around even after you've decoded it! -- and just = plain more octets. The support for multiple recipients and multiple = signatures is both unweildy (matching up parallel indices for headers = and signatures) and inefficient (multiple integrity check values in = encrypted objects). >=20 > By contrast, JSMS takes advantage of the cryptographic wisdom that = went into CMS, while making the syntax pure JSON and as simple as = possible. Multiple signatures and multiple recipients are supported = with absolute minimum overhead. So I think it's worth consideration by = the working group. >=20 >=20 > Part 2: JSON !=3D> canonicalization >=20 > I would like to dispel the myth that a JSON-based format requires = canonicalization. In JWE/JWS, the JSON header requires = "canonicalization" (via base64url encoding) because it's included within = the integrity protection. I'm not aware of any reason for including the = cryptographic parameters in the integrity check, instead of only = integrity-protecting the content itself. Indeed, if there were an = attack based on non-integrity-protected cryptographic parameters, it = would be a pretty big deal, since neither CMS nor IKE nor provides this = protection. (TLS does provide a signature over the algorithms, but only = as a way to bind the public key to the session.) >=20 > Indeed CMS doesn't require canonicalization at all, except for = attributes that are included in the protected content (signedAttrs / = authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't = allow those parameters, so there is no need for canonicalization at all. = All the "canonicalization" that's needed is to base64url-encode the = protected content. In that regard, JSMS is even simpler than JWE/JWS. >=20 >=20 > Part 3: Compactness and URL-safeness are still OK, as derivatives >=20 > I have absolutely no objection to defining a compact, URL-safe format. = Indeed, I did so in the JSMS draft, in Section 5. Encoding the example = from Section 3.1 of the JWS spec, we get the following JSMS object: >=20 > {=20 > "v":1, > "t":"au", > "a":"hs256", > "c":"eyJpc3MiOiJqb2...0cnVlfQ", > "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", > "ki":"rSIilRk8Ego" > } >=20 > If we remove the decorative spaces and base64url-encode, we only use = 88 octets more than JWS (267 vs. 179). If we take this a step further = and define an explicit compact format for AuthenticatedData, we can = emulate JWS by moving the content and MAC fields outside and = dot-combining. That avoids double-base64url-encoding, and only takes up = 11 more octets than a JWS (190 vs 179). (I've put the code to generate = these in the Github project linked earlier.) >=20 > So it's fine to have a compact, URL-safe format for an objective, but = it makes *much* more sense to derive that from a full-size, usable, JSON = format than the other way around. >=20 > Responses to specific points inline below. >=20 >=20 >> Fair enough. I'll briefly respond to each in turn. Before doing so, = I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >>=20 >> -- Not being JSON >>=20 >> This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >>=20 >> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-seriali >> zation-01 and >> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serial >> ization-01 >>=20 >> Use them if you prefer if they better suit your use cases. They = could be adopted as working group documents, if there's interest. >=20 > See above. These are super-clunky, and the need to be the main focus = of the WG, not an afterthought. >=20 >=20 >> -- Not supporting multiple recipients >>=20 >> The JSON serialization drafts above do, again, in response to use = cases presented by the working group. >=20 >=20 > See above. Because of the unnecessary inclusion of the header in the = integrity check, this is far less efficient than it should be. >=20 >=20 >> -- Lacking clear distinctions between signing and MAC >>=20 >> Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. >=20 > It's important if you want to do MACs with anything other than = pre-shared keys. If you want to do anything more advanced, you need to = have wrapped keys, in which case an object with a MAC starts to look a = lot more like a JWE than a JWS. >=20 >=20 >> -- Lacking clear processing instructions for different key=20 >> establishment modalities >>=20 >> This seems like an area where the existing drafts could be refined to = add descriptions for additional establishment modalities, possibly based = upon your ideas and descriptions, should the working group decide to do = so. What additional modalities do you have use cases for that you = believe are not achievable or straightforward with the existing drafts? = The existing modalities supported are largely those that existing = developers had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and draft-rescorla-jsms. >>=20 >> Bear in mind that the balance that the current drafts try to strike = is keeping the Mandatory to Implement (MTI) feature footprint small = enough that developers, including Web developers, are likely to adopt = the specs, while still providing enough functionality to make them = generally useful. As in any balance, it's often possible to shift = things a bit and still maintain the balance, but I'd like people to keep = the ubiquitous adoption goal front-and-center when proposing additional = functionality. >>=20 >> Ubiquitous deployment and usefulness trump theoretical completeness. =20= >> (Just look at XMLDSIG and XMLENC to understand that!) >=20 > I agree that we need to find a reasonable MTI. The current JSMS draft = doesn't really specify which parts are MTI, beyond basic things like = base64url encoding and ignoring unknown fields. >=20 > My main concern is that JWS and JWE don't really tell me which fields = need to be present for which use case. If I'm putting a MAC on a JWS = vs. a signature, do I need "jwk" or "jku" fields to be populated? = Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into sub-objects. >=20 >=20 >> -- Lack of clear typing of objects >>=20 >> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >>=20 >> What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. >=20 > I actualy don't have a hugely urgent requirement here either. It's = something that others in the WG had requested, which is trivial to add = in JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity protection of the header. >=20 >=20 >> -- Lack of versioning for future extensibility >>=20 >> An optional version field could be added if the working group = desires,=20 >> however the last time the working group discussed it, they decided = not=20 >> to do so. Rather, specs like this effectively become "versioned" = when=20 >> revised in a way that new fields are added. If you understand the = new=20 >> fields, you support that new version. (Note that this is independent=20= >> of whether there is a version number field, which according to some=20= >> participants in the previous discussion, they regarded as therefore=20= >> being redundant information.) >>=20 >> I'm not religious about not having a version number field, but often = "less is more". >=20 > Indeed, I'm not religious either. It just seems like a general good = idea to state this directly as opposed to having parsers divine it based = on which fields are present. To quote RFC 5652: > " > Each of the major data structures includes a version number as the > first item in the data structure. The version numbers are intended > to avoid ASN.1 decode errors. Some implementations do not check the > version number prior to attempting a decode, and if a decode error > occurs, then the version number is checked as part of the error > handling routine. This is a reasonable approach; it places error > processing outside of the fast path. This approach is also = forgiving > when an incorrect version number is used by the sender. > " >=20 >=20 > Best, > --Richard >=20 >=20 >=20 >=20 >=20 >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >> Sent: Friday, June 15, 2012 3:00 PM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Re: [jose] Fwd: New Version Notification for=20 >> draft-barnes-jose-jsms-00.txt >>=20 >> Ok, so maybe I should have phrased my lead-in differently. IMO, the = current JW* specs are deficient in several ways, e.g.: >> -- Not being JSON >> -- Not supporting multiple recipients >> -- Lacking clear distinctions between signing and MAC >> -- Lacking clear processing instructions for different key=20 >> establishment modalities >> -- Lack of clear typing of objects >> -- Lack of versioning for future extensibility >>=20 >> Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >>=20 >> Cheers, >> --Richard >>=20 >>=20 >>=20 >> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>=20 >>> Hi Richard, >>>=20 >>> If you're puzzled by specific design decisions in the JOSE = documents, I encourage you to ask about them on the list. The documents = have significant history going back to mid-2010 when convergence = discussions started among people with four different JSON signing & = encryption proposals. JWT and the current JOSE specs and = implementations are the result. I realize that not all the JOSE = participants were part of those discussions from the beginning (although = many were) and so teasing out the rationale for specific decisions might = help people better understand the choices made, and hopefully thereby = increase consensus behind the eventual working group choices. >>>=20 >>> If the list that you're puzzled by is the bulleted list below, maybe = we can start a discussion on that basis. >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20= >>> Of Richard L. Barnes >>> Sent: Friday, June 15, 2012 2:08 PM >>> To: jose@ietf.org >>> Subject: [jose] Fwd: New Version Notification for=20 >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> Dear JOSE WG, >>>=20 >>> Like Mr. Manger, once I finally got around to doing a thorough = review of the JW* specs, I was kind of puzzled by some of the design = decisions. So I also went through and wrote an alternative format, this = time taking a more of a cue from CMS. A link to the document is below. >>>=20 >>> Summary of differences: >>>=20 >>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>> parameters are represented in JSON. >>>=20 >>> o JSMS allows for full algorithm agility in key agreement, while = JWE >>> only allows ECDH-ES. >>>=20 >>> o JSMS supports multiple recipients for EncryptedData and >>> AuthenticatedData objects via the inclusion of multiple = WrappedKey >>> objects. Sending a JWE to multiple recipients requires re- >>> encryption of the entire object for each recipient. >>>=20 >>> o The signature and MAC functions of the JWS object are separated >>> into SignedData and AuthenticatedData JSMS objects. >>>=20 >>> o JSMS parameters are not integrity-protected, as they are in JWE >>> and JWS. >>>=20 >>> o The "typ" and "zip" parameters are not defined in JSMS, but could >>> be added without significant change. >>>=20 >>> o JSMS requires that recipients MUST ignore unknown header >>> parameters, in order to facilitate extensibility. >>>=20 >>> I've also thrown together an initial JavaScript implementation = (based on NodeJS for some python crypto glue), which is on github: >>> >>>=20 >>> Comments are very welcome. =20 >>>=20 >>> Thanks, >>> --Richard >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >>>> Date: June 15, 2012 4:56:09 PM EDT >>>> To: rbarnes@bbn.com >>>>=20 >>>>=20 >>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >>>> successfully submitted by Richard Barnes and posted to the IETF=20 >>>> repository. >>>>=20 >>>> Filename: draft-barnes-jose-jsms >>>> Revision: 00 >>>> Title: JavaScript Message Security Format >>>> Creation date: 2012-06-15 >>>> WG ID: Individual Submission >>>> Number of pages: 25 >>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> Many applications require the ability to send cryptographically=20 >>>> secured messages. While the IETF has defined a number of formats=20= >>>> for such messages (e.g. CMS) those formats use encodings which are=20= >>>> not easy to use in modern applications. This document describes = the=20 >>>> JavaScript Message Security format (JSMS), a new cryptographic=20 >>>> message format which is based on JavaScript Object Notation (JSON)=20= >>>> and thus is easy for many applications to generate and parse. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 >=20 From ve7jtb@ve7jtb.com Tue Jun 19 14:10: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 B108821F8681 for ; Tue, 19 Jun 2012 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63kYzGwx2PfR for ; Tue, 19 Jun 2012 14:10:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8221F8669 for ; Tue, 19 Jun 2012 14:10:34 -0700 (PDT) Received: by yhq56 with SMTP id 56so5771267yhq.31 for ; Tue, 19 Jun 2012 14:10:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=5/Y8ZLRR0MbnIxCjZU7rYZWKYEdUAATBQNLlpUy+ep0=; b=P5+01BNyST4NeKU1Ee+oQYMCWmi9xPeZ2C59S7qGiwFI7PDvU2hOGBPa76uwx88XGo RWt3msgyyX0BKYji1VuziU2y7ruRG5BQF28dVpofMTae7bS/WrlN0mtaFLmjRwvvFbBJ S25jrTfpTNkuFFzz9bAh8dZRCTzZIMUzISeCC/Vo/3W7tb0Jom+YaSaFT+RMz86cv8Ir 3L1db3GVg3OgqSk5ZNZranKPvf9UetfxTLpvG/oVJ/eTvFWe6QkbQL413oxR42hZXCjj fA4imrmdqzvfgR4Ljnnnaw/HZKPHTdEKX5GeYsYNtMZ13SZyKATXLQR6ZTIwPCCzUB36 P0nw== Received: by 10.236.9.34 with SMTP id 22mr24986955yhs.13.1340140233997; Tue, 19 Jun 2012 14:10:33 -0700 (PDT) Received: from [192.168.1.213] (190-20-33-245.baf.movistar.cl. [190.20.33.245]) by mx.google.com with ESMTPS id n37sm36987480anq.0.2012.06.19.14.10.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 14:10:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_5C893157-2B23-4D37-8569-1842D7B92A12"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 19 Jun 2012 17:10:21 -0400 Message-Id: <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmyO6G3b+GSauZgIDFvS/9iz0ZodLY90NHXWUhuVYP+SU3udyU8MOu4ocGJevLL14hWj/76 Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 21:10:37 -0000 --Apple-Mail=_5C893157-2B23-4D37-8569-1842D7B92A12 Content-Type: multipart/alternative; boundary="Apple-Mail=_0E7F449C-13DB-420B-A2CD-2D264BA8A55D" --Apple-Mail=_0E7F449C-13DB-420B-A2CD-2D264BA8A55D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard, Originally we only integrity protected the header for signing. We added = the integrity protection to encryption as part of AEAD, as encryption = can also be used for sender verification. I understand the argument that it makes things simpler if we don't = integrity protect the header information. However xmldsig, provides integrity over those elements to prevent = possible downgrade attacks by manipulating the algorithms. =20 CMS may not typically provide that integrity protection but I think Jim = Schaad and Sean Terner created RFC5752 to address downgrade attacks. Given they are on this list they can speak to their view on integrity = over the crypto parameters. I also recall when working on InfoCards there was a Monte Carlo/Brown = Bag attack that needs to be considered if we move to something more like = a detached signature. The other design consideration is that we wanted to be able to sign = arbitrary byte strings not just JSON. You could sign XML if you = wanted.=20 That prevented us from including meta-data in the body as we didn't want = to touch it. That left us with the header to include additional = elements in. =20 Not integrity protecting those elements as well would be a problem. =20 I am not a CMS expert but I believe it allows for signing of arbitrary = attributes not unlike the current JOSE spec. Especially for something that will be used with JWT security tokens I = will have a hard time making the argument to NIST and others that need = to approve this format that not integrity protecting the header = parameters is appropriate defence in depth, for something that might be = replacing signed SAML assertions in some applications. I do understand how not integrity protecting the header will make some = things easier, however I can't agree that the benefit outweighs the = disadvantages. Regards John B. On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: > Hey Mike, >=20 > Thanks for having some back-and-forth with me on this. I think this = is a good discussion to have right now. I would like to discuss some = high-level points, and then I'll respond inline to your precise points. >=20 > tl;dr: In order to meet its deliverables, the WG needs to define = JSON-based formats for integrity and confidentiality protections. JWE = and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates. >=20 > Major points: > 1. JOSE is JSON > 2. JSON does not imply canonicalization > 3. Compactness and URL-safeness are still OK, as derivatives >=20 > Part 1: JOSE is JSON >=20 > The JOSE WG charter calls out four deliverables, three of which are = explicitly required to be JSON: > -- "JSON-structured integrity protection" > -- "JSON-structured encryption" > -- "public keys as JSON-structured objects" > (The fourth is just a list of algorithms, which should be JSON as = well, just as RFC 3370 is ASN.1.) >=20 > In light of these requirements, JWE and JWS are clearly not suitable = candidates to fulfill the working group's milestones. (At least in = their current form.) So ISTM that we need to step back and re-evaluate = alternatives for the three above milestones, especially the first two. = (JWK is not as far off.) >=20 > As JSON-based mechanisms, though, the "JSON serialization" drafts are = pretty half-hearted. Because JWS and JWE include the cryptographic = parameters within the integrity protection, they have to have the = headers included as base64-encoded strings. That obviously adds a lot = of complexity to encoding and decoding -- for example, you have to keep = the encoded header around even after you've decoded it! -- and just = plain more octets. The support for multiple recipients and multiple = signatures is both unweildy (matching up parallel indices for headers = and signatures) and inefficient (multiple integrity check values in = encrypted objects). >=20 > By contrast, JSMS takes advantage of the cryptographic wisdom that = went into CMS, while making the syntax pure JSON and as simple as = possible. Multiple signatures and multiple recipients are supported = with absolute minimum overhead. So I think it's worth consideration by = the working group. >=20 >=20 > Part 2: JSON !=3D> canonicalization >=20 > I would like to dispel the myth that a JSON-based format requires = canonicalization. In JWE/JWS, the JSON header requires = "canonicalization" (via base64url encoding) because it's included within = the integrity protection. I'm not aware of any reason for including the = cryptographic parameters in the integrity check, instead of only = integrity-protecting the content itself. Indeed, if there were an = attack based on non-integrity-protected cryptographic parameters, it = would be a pretty big deal, since neither CMS nor IKE nor provides this = protection. (TLS does provide a signature over the algorithms, but only = as a way to bind the public key to the session.) >=20 > Indeed CMS doesn't require canonicalization at all, except for = attributes that are included in the protected content (signedAttrs / = authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't = allow those parameters, so there is no need for canonicalization at all. = All the "canonicalization" that's needed is to base64url-encode the = protected content. In that regard, JSMS is even simpler than JWE/JWS. >=20 >=20 > Part 3: Compactness and URL-safeness are still OK, as derivatives >=20 > I have absolutely no objection to defining a compact, URL-safe format. = Indeed, I did so in the JSMS draft, in Section 5. Encoding the example = from Section 3.1 of the JWS spec, we get the following JSMS object: >=20 > {=20 > "v":1, > "t":"au", > "a":"hs256", > "c":"eyJpc3MiOiJqb2...0cnVlfQ", > "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", > "ki":"rSIilRk8Ego" > } >=20 > If we remove the decorative spaces and base64url-encode, we only use = 88 octets more than JWS (267 vs. 179). If we take this a step further = and define an explicit compact format for AuthenticatedData, we can = emulate JWS by moving the content and MAC fields outside and = dot-combining. That avoids double-base64url-encoding, and only takes up = 11 more octets than a JWS (190 vs 179). (I've put the code to generate = these in the Github project linked earlier.) >=20 > So it's fine to have a compact, URL-safe format for an objective, but = it makes *much* more sense to derive that from a full-size, usable, JSON = format than the other way around. >=20 > Responses to specific points inline below. >=20 >=20 >> Fair enough. I'll briefly respond to each in turn. Before doing so, = I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >>=20 >> -- Not being JSON >>=20 >> This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >>=20 >> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 and >> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 >>=20 >> Use them if you prefer if they better suit your use cases. They = could be adopted as working group documents, if there's interest. >=20 > See above. These are super-clunky, and the need to be the main focus = of the WG, not an afterthought. >=20 >=20 >> -- Not supporting multiple recipients >>=20 >> The JSON serialization drafts above do, again, in response to use = cases presented by the working group. >=20 >=20 > See above. Because of the unnecessary inclusion of the header in the = integrity check, this is far less efficient than it should be. >=20 >=20 >> -- Lacking clear distinctions between signing and MAC >>=20 >> Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. >=20 > It's important if you want to do MACs with anything other than = pre-shared keys. If you want to do anything more advanced, you need to = have wrapped keys, in which case an object with a MAC starts to look a = lot more like a JWE than a JWS. >=20 >=20 >> -- Lacking clear processing instructions for different key = establishment modalities >>=20 >> This seems like an area where the existing drafts could be refined to = add descriptions for additional establishment modalities, possibly based = upon your ideas and descriptions, should the working group decide to do = so. What additional modalities do you have use cases for that you = believe are not achievable or straightforward with the existing drafts? = The existing modalities supported are largely those that existing = developers had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and draft-rescorla-jsms. >>=20 >> Bear in mind that the balance that the current drafts try to strike = is keeping the Mandatory to Implement (MTI) feature footprint small = enough that developers, including Web developers, are likely to adopt = the specs, while still providing enough functionality to make them = generally useful. As in any balance, it's often possible to shift = things a bit and still maintain the balance, but I'd like people to keep = the ubiquitous adoption goal front-and-center when proposing additional = functionality. >>=20 >> Ubiquitous deployment and usefulness trump theoretical completeness. = (Just look at XMLDSIG and XMLENC to understand that!)=20 >=20 > I agree that we need to find a reasonable MTI. The current JSMS draft = doesn't really specify which parts are MTI, beyond basic things like = base64url encoding and ignoring unknown fields. >=20 > My main concern is that JWS and JWE don't really tell me which fields = need to be present for which use case. If I'm putting a MAC on a JWS = vs. a signature, do I need "jwk" or "jku" fields to be populated? = Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into sub-objects. >=20 >=20 >> -- Lack of clear typing of objects >>=20 >> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >>=20 >> What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. >=20 > I actualy don't have a hugely urgent requirement here either. It's = something that others in the WG had requested, which is trivial to add = in JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity protection of the header. >=20 >=20 >> -- Lack of versioning for future extensibility >>=20 >> An optional version field could be added if the working group = desires, however the last time the working group discussed it, they = decided not to do so. Rather, specs like this effectively become = "versioned" when revised in a way that new fields are added. If you = understand the new fields, you support that new version. (Note that = this is independent of whether there is a version number field, which = according to some participants in the previous discussion, they regarded = as therefore being redundant information.) >>=20 >> I'm not religious about not having a version number field, but often = "less is more". >=20 > Indeed, I'm not religious either. It just seems like a general good = idea to state this directly as opposed to having parsers divine it based = on which fields are present. To quote RFC 5652: > " > Each of the major data structures includes a version number as the > first item in the data structure. The version numbers are intended > to avoid ASN.1 decode errors. Some implementations do not check the > version number prior to attempting a decode, and if a decode error > occurs, then the version number is checked as part of the error > handling routine. This is a reasonable approach; it places error > processing outside of the fast path. This approach is also = forgiving > when an incorrect version number is used by the sender. > " >=20 >=20 > Best, > --Richard >=20 >=20 >=20 >=20 >=20 >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >> Sent: Friday, June 15, 2012 3:00 PM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >>=20 >> Ok, so maybe I should have phrased my lead-in differently. IMO, the = current JW* specs are deficient in several ways, e.g.: >> -- Not being JSON >> -- Not supporting multiple recipients >> -- Lacking clear distinctions between signing and MAC >> -- Lacking clear processing instructions for different key = establishment modalities >> -- Lack of clear typing of objects >> -- Lack of versioning for future extensibility >>=20 >> Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >>=20 >> Cheers, >> --Richard >>=20 >>=20 >>=20 >> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>=20 >>> Hi Richard, >>>=20 >>> If you're puzzled by specific design decisions in the JOSE = documents, I encourage you to ask about them on the list. The documents = have significant history going back to mid-2010 when convergence = discussions started among people with four different JSON signing & = encryption proposals. JWT and the current JOSE specs and = implementations are the result. I realize that not all the JOSE = participants were part of those discussions from the beginning (although = many were) and so teasing out the rationale for specific decisions might = help people better understand the choices made, and hopefully thereby = increase consensus behind the eventual working group choices. >>>=20 >>> If the list that you're puzzled by is the bulleted list below, maybe = we can start a discussion on that basis. >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20= >>> Of Richard L. Barnes >>> Sent: Friday, June 15, 2012 2:08 PM >>> To: jose@ietf.org >>> Subject: [jose] Fwd: New Version Notification for=20 >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> Dear JOSE WG, >>>=20 >>> Like Mr. Manger, once I finally got around to doing a thorough = review of the JW* specs, I was kind of puzzled by some of the design = decisions. So I also went through and wrote an alternative format, this = time taking a more of a cue from CMS. A link to the document is below. >>>=20 >>> Summary of differences: >>>=20 >>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>> parameters are represented in JSON. >>>=20 >>> o JSMS allows for full algorithm agility in key agreement, while = JWE >>> only allows ECDH-ES. >>>=20 >>> o JSMS supports multiple recipients for EncryptedData and >>> AuthenticatedData objects via the inclusion of multiple = WrappedKey >>> objects. Sending a JWE to multiple recipients requires re- >>> encryption of the entire object for each recipient. >>>=20 >>> o The signature and MAC functions of the JWS object are separated >>> into SignedData and AuthenticatedData JSMS objects. >>>=20 >>> o JSMS parameters are not integrity-protected, as they are in JWE >>> and JWS. >>>=20 >>> o The "typ" and "zip" parameters are not defined in JSMS, but could >>> be added without significant change. >>>=20 >>> o JSMS requires that recipients MUST ignore unknown header >>> parameters, in order to facilitate extensibility. >>>=20 >>> I've also thrown together an initial JavaScript implementation = (based on NodeJS for some python crypto glue), which is on github: >>> >>>=20 >>> Comments are very welcome. =20 >>>=20 >>> Thanks, >>> --Richard >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt >>>> Date: June 15, 2012 4:56:09 PM EDT >>>> To: rbarnes@bbn.com >>>>=20 >>>>=20 >>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >>>> successfully submitted by Richard Barnes and posted to the IETF=20 >>>> repository. >>>>=20 >>>> Filename: draft-barnes-jose-jsms >>>> Revision: 00 >>>> Title: JavaScript Message Security Format >>>> Creation date: 2012-06-15 >>>> WG ID: Individual Submission >>>> Number of pages: 25 >>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> Many applications require the ability to send cryptographically =20 >>>> secured messages. While the IETF has defined a number of formats = for =20 >>>> such messages (e.g. CMS) those formats use encodings which are not = =20 >>>> easy to use in modern applications. This document describes the =20= >>>> JavaScript Message Security format (JSMS), a new cryptographic =20 >>>> message format which is based on JavaScript Object Notation (JSON) =20= >>>> and thus is easy for many applications to generate and parse. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_0E7F449C-13DB-420B-A2CD-2D264BA8A55D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Richard,

Originally we only integrity protected the = header for signing.  We added the integrity protection to = encryption as part of AEAD, as encryption can also be used for sender = verification.

I understand the argument that it = makes things simpler if we don't integrity protect the header = information.

However xmldsig,  provides = integrity over those elements to prevent possible downgrade attacks by = manipulating the algorithms.   

CMS = may not typically provide that integrity protection but I think Jim = Schaad and Sean Terner created RFC5752 to address = downgrade attacks.
Given they are on this list they can speak = to their view on integrity over the crypto = parameters.

I also recall when working on = InfoCards there was a Monte Carlo/Brown Bag attack that needs to be = considered if we move to something more like a detached = signature.

The other design consideration is = that we wanted to be able to sign arbitrary byte strings not just JSON. =   You could sign XML if you wanted. 
That prevented = us from including meta-data in the body as we didn't want to touch it. =   That left us with the header to include additional elements in. =  
Not integrity protecting those elements as well would = be a problem.  

I am not a CMS expert but = I believe it allows for signing of arbitrary attributes not unlike the = current JOSE spec.

Especially for something = that will be used with JWT security tokens I will have a hard time = making the argument to NIST and others that need to approve this format = that not integrity protecting the header parameters is appropriate = defence in depth, for something that might be replacing signed SAML = assertions in some applications.

I do = understand how not integrity protecting the header will make some things = easier, however I can't agree that the benefit outweighs the = disadvantages.

Regards
John = B.


On 2012-06-18, at = 10:02 PM, Richard L. Barnes wrote:

Hey = Mike,

Thanks for having some back-and-forth with me on this. =  I think this is a good discussion to have right now.  I would = like to discuss some high-level points, and then I'll respond inline to = your precise points.

tl;dr: In order to meet its deliverables, = the WG needs to define JSON-based formats for integrity and = confidentiality protections.  JWE and JWS don't fit that = requirement, so we should re-consider their adoption and call for new = candidates.

Major points:
1. JOSE is JSON
2. JSON does not = imply canonicalization
3. Compactness and URL-safeness are still OK, = as derivatives

Part 1: JOSE is JSON

The JOSE WG charter = calls out four deliverables, three of which are explicitly required to = be JSON:
-- "JSON-structured integrity protection"
-- = "JSON-structured encryption"
-- "public keys as JSON-structured = objects"
(The fourth is just a list of algorithms, which should be = JSON as well, just as RFC 3370 is ASN.1.)

In light of these = requirements, JWE and JWS are clearly not suitable candidates to fulfill = the working group's milestones.  (At least in their current form.) =  So ISTM that we need to step back and re-evaluate alternatives for = the three above milestones, especially the first two.  (JWK is not = as far off.)

As JSON-based mechanisms, though, the "JSON = serialization" drafts are pretty half-hearted.  Because JWS and JWE = include the cryptographic parameters within the integrity protection, = they have to have the headers included as base64-encoded strings. =  That obviously adds a lot of complexity to encoding and decoding = -- for example, you have to keep the encoded header around even after = you've decoded it! -- and just plain more octets.  The support for = multiple recipients and multiple signatures is both unweildy (matching = up parallel indices for headers and signatures) and inefficient = (multiple integrity check values in encrypted objects).

By = contrast, JSMS takes advantage of the cryptographic wisdom that went = into CMS, while making the syntax pure JSON and as simple as possible. =  Multiple signatures and multiple recipients are supported with = absolute minimum overhead.  So I think it's worth consideration by = the working group.


Part 2: JSON !=3D> = canonicalization

I would like to dispel the myth that a = JSON-based format requires canonicalization.  In JWE/JWS, the JSON = header requires "canonicalization" (via base64url encoding) because it's = included within the integrity protection.  I'm not aware of any = reason for including the cryptographic parameters in the integrity = check, instead of only integrity-protecting the content itself. =  Indeed, if there were an attack based on non-integrity-protected = cryptographic parameters, it would be a pretty big deal, since neither = CMS nor IKE nor provides this protection.  (TLS does provide a = signature over the algorithms, but only as a way to bind the public key = to the session.)

Indeed CMS doesn't require canonicalization at = all, except for attributes that are included in the protected content = (signedAttrs / authenticatedAttrs), which need to be DER-encoded. =  In JSMS, we don't allow those parameters, so there is no need for = canonicalization at all.  All the "canonicalization" that's needed = is to base64url-encode the protected content.  In that regard, JSMS = is even simpler than JWE/JWS.


Part 3: Compactness and = URL-safeness are still OK, as derivatives

I have absolutely no = objection to defining a compact, URL-safe format.  Indeed, I did so = in the JSMS draft, in Section 5.  Encoding the example from Section = 3.1 of the JWS spec, we get the following JSMS object:

{
=    "v":1,
   "t":"au",
=    "a":"hs256",
=    "c":"eyJpc3MiOiJqb2...0cnVlfQ",
=    "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo",
=    "ki":"rSIilRk8Ego"
}

If we remove the = decorative spaces and base64url-encode, we only use 88 octets more than = JWS (267 vs. 179).  If we take this a step further and define an = explicit compact format for AuthenticatedData, we can emulate JWS by = moving the content and MAC fields outside and dot-combining.  That = avoids double-base64url-encoding, and only takes up 11 more octets than = a JWS (190 vs 179).  (I've put the code to generate these in the = Github project linked earlier.)

So it's fine to have a compact, = URL-safe format for an objective, but it makes *much* more sense to = derive that from a full-size, usable, JSON format than the other way = around.

Responses to specific points inline = below.


Fair enough.  I'll = briefly respond to each in turn.  Before doing so, I'll say that = I'm writing in the spirit of trying to increase mutual understanding and = consensus, rather than taking the point of view that the status quo is = the only reasonable outcome.

-- Not being = JSON

This was by = design, so that the results are URL-safe.  This is required, for = instance, for them to be used as OAuth Bearer Tokens.  At the = request of the working group, closely related pure-JSON drafts were also = published.  See:

http://tools.ietf.org/html/draft-jones-json-web-signature-j= son-serialization-01 and
http://tools.ietf.org/html/draft-jones-json-web-encryption= -json-serialization-01

Use them if you = prefer if they better suit your use cases.  They could be adopted = as working group documents, if there's interest.

See = above.  These are super-clunky, and the need to be the main focus = of the WG, not an afterthought.


-- = Not supporting multiple recipients

The JSON = serialization drafts above do, again, in response to use cases presented = by the working group.


See above.  Because = of the unnecessary inclusion of the header in the integrity check, this = is far less efficient than it should be.


-- Lacking clear distinctions between signing and = MAC

Functionally, these are very similar operations, at least = from an implementation perspective, so it's not clear that making a = clear distinction would help either developers or adoption in any = practical way.  They achieve overlapping, but admittedly sometimes = different goals.  I believe that developers can be trusted to use = the algorithms that achieve their applications' goals without making a = hard distinction between the two.  But I'd be interested in hearing = your thoughts on why you believe a brighter-line distinction might be = useful or necessary.

It's important if you want to = do MACs with anything other than pre-shared keys.  If you want to = do anything more advanced, you need to have wrapped keys, in which case = an object with a MAC starts to look a lot more like a JWE than a = JWS.


-- Lacking clear processing = instructions for different key establishment = modalities

This seems like = an area where the existing drafts could be refined to add descriptions = for additional establishment modalities, possibly based upon your ideas = and descriptions, should the working group decide to do so.  What = additional modalities do you have use cases for that you believe are not = achievable or straightforward with the existing drafts?  The = existing modalities supported are largely those that existing developers = had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and = draft-rescorla-jsms.

Bear in mind = that the balance that the current drafts try to strike is keeping the = Mandatory to Implement (MTI) feature footprint small enough that = developers, including Web developers, are likely to adopt the specs, = while still providing enough functionality to make them generally = useful.  As in any balance, it's often possible to shift things a = bit and still maintain the balance, but I'd like people to keep the = ubiquitous adoption goal front-and-center when proposing additional = functionality.

Ubiquitous = deployment and usefulness trump theoretical completeness.  (Just = look at XMLDSIG and XMLENC to understand that!)

I = agree that we need to find a reasonable MTI.  The current JSMS = draft doesn't really specify which parts are MTI, beyond basic things = like base64url encoding and ignoring unknown fields.

My main = concern is that JWS and JWE don't really tell me which fields need to be = present for which use case.  If I'm putting a MAC on a JWS vs. a = signature, do I need "jwk" or "jku" fields to be populated? =  Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into = sub-objects.


-- Lack of clear = typing of objects

Most JSON = documents aren't clearly typed; instead, developers and implementations = understand from context what the meaning of each field is.  XML is = clearly typed, but developers are voting with their feet by moving to = JSON.

What practical = advantages resulting from overlaying a typing infrastructure on JSON do = you believe are worth the potential costs of doing so?  BTW, I'm = not opposed to having a JSON schema description of the JOSE JSON data = structures like JSMS did in http= ://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative = one.

I actualy don't have a hugely urgent = requirement here either.  It's something that others in the WG had = requested, which is trivial to add in JSMS, but not in JWE/JWS -- again = because of the unnecessary integrity protection of the = header.


-- Lack of versioning for = future extensibility

An optional = version field could be added if the working group desires, however the = last time the working group discussed it, they decided not to do so. =  Rather, specs like this effectively become "versioned" when = revised in a way that new fields are added.  If you understand the = new fields, you support that new version.  (Note that this is = independent of whether there is a version number field, which according = to some participants in the previous discussion, they regarded as = therefore being redundant information.)

I'm not = religious about not having a version number field, but often "less is = more".

Indeed, I'm not religious either.  It = just seems like a general good idea to state this directly as opposed to = having parsers divine it based on which fields are present.  To = quote RFC 5652:
"
  Each of the major data structures = includes a version number as the
  first item in the data = structure.  The version numbers are intended
  to = avoid ASN.1 decode errors.  Some implementations do not check = the
  version number prior to attempting a decode, and if = a decode error
  occurs, then the version number is = checked as part of the error
  handling routine. =  This is a reasonable approach; it places error
=   processing outside of the fast path.  This approach is = also forgiving
  when an incorrect version number is used = by the = sender.
"


Best,
--Richard






Best = wishes,
-- = Mike

-----Original = Message-----
From: Richard L. = Barnes [mailto:rbarnes@bbn.com]
Sent: Friday, June 15, 2012 3:00 = PM
To: Mike = Jones
Cc: jose@ietf.org
Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt

Ok, so maybe I = should have phrased my lead-in differently.  IMO, the current JW* = specs are deficient in several ways, e.g.:
-- Not being JSON
-- Not supporting multiple = recipients
-- Lacking clear = distinctions between signing and MAC
-- Lacking clear processing instructions for different key = establishment modalities
-- = Lack of clear typing of objects
-- Lack of versioning for future = extensibility

Looking at the = current specs, it didn't seem to me that it would be simple to adapt = them to address these deficiencies.  So I just did a re-write. =  If you think they can be addressed within the current framework, = please explain.  I just found it simpler to start from whole = cloth.

Cheers,
--Richard



On Jun 15, = 2012, at 5:43 PM, Mike Jones wrote:

Hi Richard,

If you're puzzled by specific = design decisions in the JOSE documents, I encourage you to ask about = them on the list.  The documents have significant history going = back to mid-2010 when convergence discussions started among people with = four different JSON signing & encryption proposals.  JWT and = the current JOSE specs and implementations are the result.  I = realize that not all the JOSE participants were part of those = discussions from the beginning (although many were) and so teasing out = the rationale for specific decisions might help people better understand = the choices made, and hopefully thereby increase consensus behind the = eventual working group choices.

If the list that you're puzzled = by is the bulleted list below, maybe we can start a discussion on that = basis.

Best = wishes,
= = = = -- Mike

-----Original = Message-----
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf =
Of Richard L. = Barnes
Sent: Friday, June 15, 2012 2:08 = PM
To: jose@ietf.org
Subject: [jose] = Fwd: New Version Notification for =
draft-barnes-jose-jsms-00.txt
<= blockquote type=3D"cite">

Dear JOSE = WG,

Like Mr. Manger, once I finally = got around to doing a thorough review of the JW* specs, I was kind of = puzzled by some of the design decisions.  So I also went through = and wrote an alternative format, this time taking a more of a cue from = CMS.  A link to the document is = below.

Summary of = differences:

o  JSMS is pure JSON, = whereas in JWE and JWS only the = header
   parameters are represented in = JSON.

o  JSMS allows for full = algorithm agility in key agreement, while = JWE
   only allows = ECDH-ES.

o  JSMS supports multiple = recipients for EncryptedData = and
   AuthenticatedData objects via the = inclusion of multiple = WrappedKey
   objects. =  Sending a JWE to multiple recipients requires = re-
   encryption of the entire object for = each recipient.

o  The signature and MAC = functions of the JWS object are = separated
   into = SignedData and AuthenticatedData JSMS = objects.

o  JSMS parameters are not = integrity-protected, as they are in = JWE
   and = JWS.

o  The "typ" and "zip" = parameters are not defined in JSMS, but = could
   be added without significant = change.

o  JSMS requires that = recipients MUST ignore unknown = header
   parameters, in order to facilitate = extensibility.

I've also thrown together an = initial JavaScript implementation (based on NodeJS for some python = crypto glue), which is on = github:
<https://github.com/bifurcatio= n/jsms>

Comments are very welcome. =  

Thanks,
--Richard



Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /blockquote>
Subject:= New Version Notification for = draft-barnes-jose-jsms-00.txt
Date: June 15, 2012 4:56:09 PM = EDT
To: rbarnes@bbn.com


A new = version of I-D, draft-barnes-jose-jsms-00.txt has been =
successfully submitted by Richard Barnes and posted to the = IETF
repository.

Filename: = draft-barnes-jose-jsms
Revision: = 00
Title: JavaScript Message Security = Format
Creation= date: = 2012-06-15
WG = ID: = = Individual = Submission
Number = of pages: 25
URL: =             http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt
=
Status: =          http://dat= atracker.ietf.org/doc/draft-barnes-jose-jsms
Htmlized: =        http://tools= .ietf.org/html/draft-barnes-jose-jsms-00
=


Abstract:
Many= applications require the ability to send cryptographically =  
secured = messages.  While the IETF has defined a number of formats for =  
such = messages (e.g.  CMS) those formats use encodings which are not =  
easy = to use in modern applications.  This document describes the =  
JavaScript Message Security format (JSMS), a new = cryptographic =  
message = format which is based on JavaScript Object Notation (JSON) =  
and = thus is easy for many applications to generate and = parse.




The = IETF Secretariat

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


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



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

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

= --Apple-Mail=_0E7F449C-13DB-420B-A2CD-2D264BA8A55D-- --Apple-Mail=_5C893157-2B23-4D37-8569-1842D7B92A12 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx OTIxMTAyMlowIwYJKoZIhvcNAQkEMRYEFF+Bb3L+ajwKGxUDamo1JCgX5qKIMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AEvYUqcbZlyM5kXhgDHlJh9NUey+7zZS7DITi7iji4TJntakuHdMcpe7cHIALN4bRplP6JFv6+xG C8Fj4rI9Ch3Sq6VudjH7TuEnn2pqn7tHlJDGb0vFjQvHEITJlBdT4tXoTxm8o2odP52JvGocmImq u8Z4dZTcTLYDxl2ET8Wphhr3jEIjCyiNnPAqFYm5fXk49Stl5SFpJuR1eDWWHtZxsXdHnJ3yAAId RLQsM6EmstefODhcKfFmVd4Q3XUttIWqUU2qm9Y6Trf/sJJab9aJ/67u29XvL667i8VR8PMwNO7Y Aq0yuWpbqjkAyPMLcrVqWrycUBQbJc2LXh8HyiYAAAAAAAA= --Apple-Mail=_5C893157-2B23-4D37-8569-1842D7B92A12-- From ve7jtb@ve7jtb.com Tue Jun 19 14:19: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 9864611E8098 for ; Tue, 19 Jun 2012 14:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lkd+NeDcl-nz for ; Tue, 19 Jun 2012 14:19:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD4B21F86BE for ; Tue, 19 Jun 2012 14:19:35 -0700 (PDT) Received: by yenq13 with SMTP id q13so5751786yen.31 for ; Tue, 19 Jun 2012 14:19:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=UQbNw0OaSv8b5avfYc/G6Kl5IwxJUFTAU6MGI5cn9Jo=; b=HeKlom5BUu5WjeD2/qvFQzUjqtV1goPICI63OYgAvRFC7Mhin7Omq5cx3QeLMVtPks vD0VV+55P34kabBh/8DxZacDfDtEeJTruGtA3LJw0PSbbkxrPJaEdwE6jokXabFybzcM h/LJPmEM5ZQI+hHiAlkQaoFFU/TUnJc7FbUYXwwfJqHC4K1tnkqkWGR3PA5UzY4J3bWl jQAhV9Hp1WzJ7vpIFTuwOXt6edyVD8XZOzKnSQeTIz1+VBrw6AQq2b8hh7BwIiqX+YFP PgVDOzUEaTJ/xLnKwUlml9hT4Gsf51q40xUTjLZeW/opQ8J0msau/MM9kvLZDe52+QYu l4xg== Received: by 10.236.46.74 with SMTP id q50mr25013356yhb.30.1340140774310; Tue, 19 Jun 2012 14:19:34 -0700 (PDT) Received: from [192.168.1.213] (190-20-33-245.baf.movistar.cl. [190.20.33.245]) by mx.google.com with ESMTPS id a64sm84207917yhe.11.2012.06.19.14.19.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 14:19:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_E738CE33-8BDE-4335-BBD3-C75286431960"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> Date: Tue, 19 Jun 2012 17:19:21 -0400 Message-Id: <7ECE7F37-0359-4597-8636-9A652EF917D1@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkztfSG1qg7/oQo+AH1gotGzneVwYhASMgXjJWkdyzaNMned+qCO1tLkjDdrofEjp5+SksW Cc: "Richard L. Barnes" , Mike Jones , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 21:19:41 -0000 --Apple-Mail=_E738CE33-8BDE-4335-BBD3-C75286431960 Content-Type: multipart/alternative; boundary="Apple-Mail=_9A8C510C-6419-44B9-8BE1-4436A5486DE1" --Apple-Mail=_9A8C510C-6419-44B9-8BE1-4436A5486DE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry I included the wrong link for the Monte Carlo/Brown Bag attack. = This is a paper better explaining it. = http://domino.research.ibm.com/library/cyberdig.nsf/papers/73053F26BFE5D1D= 385257067004CFD80/$File/rc23691.pdf Regards John B. On 2012-06-19, at 5:10 PM, John Bradley wrote: > Hi Richard, >=20 > Originally we only integrity protected the header for signing. We = added the integrity protection to encryption as part of AEAD, as = encryption can also be used for sender verification. >=20 > I understand the argument that it makes things simpler if we don't = integrity protect the header information. >=20 > However xmldsig, provides integrity over those elements to prevent = possible downgrade attacks by manipulating the algorithms. =20 >=20 > CMS may not typically provide that integrity protection but I think = Jim Schaad and Sean Terner created RFC5752 to address downgrade attacks. > Given they are on this list they can speak to their view on integrity = over the crypto parameters. >=20 > I also recall when working on InfoCards there was a Monte Carlo/Brown = Bag attack that needs to be considered if we move to something more like = a detached signature. >=20 > The other design consideration is that we wanted to be able to sign = arbitrary byte strings not just JSON. You could sign XML if you = wanted.=20 > That prevented us from including meta-data in the body as we didn't = want to touch it. That left us with the header to include additional = elements in. =20 > Not integrity protecting those elements as well would be a problem. =20= >=20 > I am not a CMS expert but I believe it allows for signing of arbitrary = attributes not unlike the current JOSE spec. >=20 > Especially for something that will be used with JWT security tokens I = will have a hard time making the argument to NIST and others that need = to approve this format that not integrity protecting the header = parameters is appropriate defence in depth, for something that might be = replacing signed SAML assertions in some applications. >=20 > I do understand how not integrity protecting the header will make some = things easier, however I can't agree that the benefit outweighs the = disadvantages. >=20 > Regards > John B. >=20 >=20 > On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >=20 >> Hey Mike, >>=20 >> Thanks for having some back-and-forth with me on this. I think this = is a good discussion to have right now. I would like to discuss some = high-level points, and then I'll respond inline to your precise points. >>=20 >> tl;dr: In order to meet its deliverables, the WG needs to define = JSON-based formats for integrity and confidentiality protections. JWE = and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates. >>=20 >> Major points: >> 1. JOSE is JSON >> 2. JSON does not imply canonicalization >> 3. Compactness and URL-safeness are still OK, as derivatives >>=20 >> Part 1: JOSE is JSON >>=20 >> The JOSE WG charter calls out four deliverables, three of which are = explicitly required to be JSON: >> -- "JSON-structured integrity protection" >> -- "JSON-structured encryption" >> -- "public keys as JSON-structured objects" >> (The fourth is just a list of algorithms, which should be JSON as = well, just as RFC 3370 is ASN.1.) >>=20 >> In light of these requirements, JWE and JWS are clearly not suitable = candidates to fulfill the working group's milestones. (At least in = their current form.) So ISTM that we need to step back and re-evaluate = alternatives for the three above milestones, especially the first two. = (JWK is not as far off.) >>=20 >> As JSON-based mechanisms, though, the "JSON serialization" drafts are = pretty half-hearted. Because JWS and JWE include the cryptographic = parameters within the integrity protection, they have to have the = headers included as base64-encoded strings. That obviously adds a lot = of complexity to encoding and decoding -- for example, you have to keep = the encoded header around even after you've decoded it! -- and just = plain more octets. The support for multiple recipients and multiple = signatures is both unweildy (matching up parallel indices for headers = and signatures) and inefficient (multiple integrity check values in = encrypted objects). >>=20 >> By contrast, JSMS takes advantage of the cryptographic wisdom that = went into CMS, while making the syntax pure JSON and as simple as = possible. Multiple signatures and multiple recipients are supported = with absolute minimum overhead. So I think it's worth consideration by = the working group. >>=20 >>=20 >> Part 2: JSON !=3D> canonicalization >>=20 >> I would like to dispel the myth that a JSON-based format requires = canonicalization. In JWE/JWS, the JSON header requires = "canonicalization" (via base64url encoding) because it's included within = the integrity protection. I'm not aware of any reason for including the = cryptographic parameters in the integrity check, instead of only = integrity-protecting the content itself. Indeed, if there were an = attack based on non-integrity-protected cryptographic parameters, it = would be a pretty big deal, since neither CMS nor IKE nor provides this = protection. (TLS does provide a signature over the algorithms, but only = as a way to bind the public key to the session.) >>=20 >> Indeed CMS doesn't require canonicalization at all, except for = attributes that are included in the protected content (signedAttrs / = authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't = allow those parameters, so there is no need for canonicalization at all. = All the "canonicalization" that's needed is to base64url-encode the = protected content. In that regard, JSMS is even simpler than JWE/JWS. >>=20 >>=20 >> Part 3: Compactness and URL-safeness are still OK, as derivatives >>=20 >> I have absolutely no objection to defining a compact, URL-safe = format. Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example from Section 3.1 of the JWS spec, we get the following JSMS = object: >>=20 >> {=20 >> "v":1, >> "t":"au", >> "a":"hs256", >> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >> "ki":"rSIilRk8Ego" >> } >>=20 >> If we remove the decorative spaces and base64url-encode, we only use = 88 octets more than JWS (267 vs. 179). If we take this a step further = and define an explicit compact format for AuthenticatedData, we can = emulate JWS by moving the content and MAC fields outside and = dot-combining. That avoids double-base64url-encoding, and only takes up = 11 more octets than a JWS (190 vs 179). (I've put the code to generate = these in the Github project linked earlier.) >>=20 >> So it's fine to have a compact, URL-safe format for an objective, but = it makes *much* more sense to derive that from a full-size, usable, JSON = format than the other way around. >>=20 >> Responses to specific points inline below. >>=20 >>=20 >>> Fair enough. I'll briefly respond to each in turn. Before doing = so, I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >>>=20 >>> -- Not being JSON >>>=20 >>> This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >>>=20 >>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 and >>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 >>>=20 >>> Use them if you prefer if they better suit your use cases. They = could be adopted as working group documents, if there's interest. >>=20 >> See above. These are super-clunky, and the need to be the main focus = of the WG, not an afterthought. >>=20 >>=20 >>> -- Not supporting multiple recipients >>>=20 >>> The JSON serialization drafts above do, again, in response to use = cases presented by the working group. >>=20 >>=20 >> See above. Because of the unnecessary inclusion of the header in the = integrity check, this is far less efficient than it should be. >>=20 >>=20 >>> -- Lacking clear distinctions between signing and MAC >>>=20 >>> Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. >>=20 >> It's important if you want to do MACs with anything other than = pre-shared keys. If you want to do anything more advanced, you need to = have wrapped keys, in which case an object with a MAC starts to look a = lot more like a JWE than a JWS. >>=20 >>=20 >>> -- Lacking clear processing instructions for different key = establishment modalities >>>=20 >>> This seems like an area where the existing drafts could be refined = to add descriptions for additional establishment modalities, possibly = based upon your ideas and descriptions, should the working group decide = to do so. What additional modalities do you have use cases for that you = believe are not achievable or straightforward with the existing drafts? = The existing modalities supported are largely those that existing = developers had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and draft-rescorla-jsms. >>>=20 >>> Bear in mind that the balance that the current drafts try to strike = is keeping the Mandatory to Implement (MTI) feature footprint small = enough that developers, including Web developers, are likely to adopt = the specs, while still providing enough functionality to make them = generally useful. As in any balance, it's often possible to shift = things a bit and still maintain the balance, but I'd like people to keep = the ubiquitous adoption goal front-and-center when proposing additional = functionality. >>>=20 >>> Ubiquitous deployment and usefulness trump theoretical completeness. = (Just look at XMLDSIG and XMLENC to understand that!)=20 >>=20 >> I agree that we need to find a reasonable MTI. The current JSMS = draft doesn't really specify which parts are MTI, beyond basic things = like base64url encoding and ignoring unknown fields. >>=20 >> My main concern is that JWS and JWE don't really tell me which fields = need to be present for which use case. If I'm putting a MAC on a JWS = vs. a signature, do I need "jwk" or "jku" fields to be populated? = Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into sub-objects. >>=20 >>=20 >>> -- Lack of clear typing of objects >>>=20 >>> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >>>=20 >>> What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. >>=20 >> I actualy don't have a hugely urgent requirement here either. It's = something that others in the WG had requested, which is trivial to add = in JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity protection of the header. >>=20 >>=20 >>> -- Lack of versioning for future extensibility >>>=20 >>> An optional version field could be added if the working group = desires, however the last time the working group discussed it, they = decided not to do so. Rather, specs like this effectively become = "versioned" when revised in a way that new fields are added. If you = understand the new fields, you support that new version. (Note that = this is independent of whether there is a version number field, which = according to some participants in the previous discussion, they regarded = as therefore being redundant information.) >>>=20 >>> I'm not religious about not having a version number field, but often = "less is more". >>=20 >> Indeed, I'm not religious either. It just seems like a general good = idea to state this directly as opposed to having parsers divine it based = on which fields are present. To quote RFC 5652: >> " >> Each of the major data structures includes a version number as the >> first item in the data structure. The version numbers are intended >> to avoid ASN.1 decode errors. Some implementations do not check = the >> version number prior to attempting a decode, and if a decode error >> occurs, then the version number is checked as part of the error >> handling routine. This is a reasonable approach; it places error >> processing outside of the fast path. This approach is also = forgiving >> when an incorrect version number is used by the sender. >> " >>=20 >>=20 >> Best, >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>> Sent: Friday, June 15, 2012 3:00 PM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >>>=20 >>> Ok, so maybe I should have phrased my lead-in differently. IMO, the = current JW* specs are deficient in several ways, e.g.: >>> -- Not being JSON >>> -- Not supporting multiple recipients >>> -- Lacking clear distinctions between signing and MAC >>> -- Lacking clear processing instructions for different key = establishment modalities >>> -- Lack of clear typing of objects >>> -- Lack of versioning for future extensibility >>>=20 >>> Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >>>=20 >>> Cheers, >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>=20 >>>> Hi Richard, >>>>=20 >>>> If you're puzzled by specific design decisions in the JOSE = documents, I encourage you to ask about them on the list. The documents = have significant history going back to mid-2010 when convergence = discussions started among people with four different JSON signing & = encryption proposals. JWT and the current JOSE specs and = implementations are the result. I realize that not all the JOSE = participants were part of those discussions from the beginning (although = many were) and so teasing out the rationale for specific decisions might = help people better understand the choices made, and hopefully thereby = increase consensus behind the eventual working group choices. >>>>=20 >>>> If the list that you're puzzled by is the bulleted list below, = maybe we can start a discussion on that basis. >>>>=20 >>>> Best wishes, >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf=20 >>>> Of Richard L. Barnes >>>> Sent: Friday, June 15, 2012 2:08 PM >>>> To: jose@ietf.org >>>> Subject: [jose] Fwd: New Version Notification for=20 >>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>> Dear JOSE WG, >>>>=20 >>>> Like Mr. Manger, once I finally got around to doing a thorough = review of the JW* specs, I was kind of puzzled by some of the design = decisions. So I also went through and wrote an alternative format, this = time taking a more of a cue from CMS. A link to the document is below. >>>>=20 >>>> Summary of differences: >>>>=20 >>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>> parameters are represented in JSON. >>>>=20 >>>> o JSMS allows for full algorithm agility in key agreement, while = JWE >>>> only allows ECDH-ES. >>>>=20 >>>> o JSMS supports multiple recipients for EncryptedData and >>>> AuthenticatedData objects via the inclusion of multiple = WrappedKey >>>> objects. Sending a JWE to multiple recipients requires re- >>>> encryption of the entire object for each recipient. >>>>=20 >>>> o The signature and MAC functions of the JWS object are separated >>>> into SignedData and AuthenticatedData JSMS objects. >>>>=20 >>>> o JSMS parameters are not integrity-protected, as they are in JWE >>>> and JWS. >>>>=20 >>>> o The "typ" and "zip" parameters are not defined in JSMS, but = could >>>> be added without significant change. >>>>=20 >>>> o JSMS requires that recipients MUST ignore unknown header >>>> parameters, in order to facilitate extensibility. >>>>=20 >>>> I've also thrown together an initial JavaScript implementation = (based on NodeJS for some python crypto glue), which is on github: >>>> >>>>=20 >>>> Comments are very welcome. =20 >>>>=20 >>>> Thanks, >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for = draft-barnes-jose-jsms-00.txt >>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>> To: rbarnes@bbn.com >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >>>>> successfully submitted by Richard Barnes and posted to the IETF=20 >>>>> repository. >>>>>=20 >>>>> Filename: draft-barnes-jose-jsms >>>>> Revision: 00 >>>>> Title: JavaScript Message Security Format >>>>> Creation date: 2012-06-15 >>>>> WG ID: Individual Submission >>>>> Number of pages: 25 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> Many applications require the ability to send cryptographically =20= >>>>> secured messages. While the IETF has defined a number of formats = for =20 >>>>> such messages (e.g. CMS) those formats use encodings which are = not =20 >>>>> easy to use in modern applications. This document describes the =20= >>>>> JavaScript Message Security format (JSMS), a new cryptographic =20 >>>>> message format which is based on JavaScript Object Notation (JSON) = =20 >>>>> and thus is easy for many applications to generate and parse. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_9A8C510C-6419-44B9-8BE1-4436A5486DE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sorry = I included the wrong link for the Monte Carlo/Brown Bag attack. This is = a paper better explaining it. http://domino.research.ibm.co= m/library/cyberdig.nsf/papers/73053F26BFE5D1D385257067004CFD80/$File/rc236= 91.pdf

Regards
John = B.

On 2012-06-19, at 5:10 PM, John = Bradley wrote:

Hi = Richard,

Originally we only integrity protected the = header for signing.  We added the integrity protection to = encryption as part of AEAD, as encryption can also be used for sender = verification.

I understand the argument that it = makes things simpler if we don't integrity protect the header = information.

However xmldsig,  provides = integrity over those elements to prevent possible downgrade attacks by = manipulating the algorithms.   

CMS = may not typically provide that integrity protection but I think Jim = Schaad and Sean Terner created RFC5752 to address = downgrade attacks.
Given they are on this list they can speak = to their view on integrity over the crypto = parameters.

I also recall when working on = InfoCards there was a Monte Carlo/Brown Bag attack that needs to be = considered if we move to something more like a detached = signature.

The other design consideration is = that we wanted to be able to sign arbitrary byte strings not just JSON. =   You could sign XML if you wanted. 
That prevented = us from including meta-data in the body as we didn't want to touch it. =   That left us with the header to include additional elements in. =  
Not integrity protecting those elements as well would = be a problem.  

I am not a CMS expert but = I believe it allows for signing of arbitrary attributes not unlike the = current JOSE spec.

Especially for something = that will be used with JWT security tokens I will have a hard time = making the argument to NIST and others that need to approve this format = that not integrity protecting the header parameters is appropriate = defence in depth, for something that might be replacing signed SAML = assertions in some applications.

I do = understand how not integrity protecting the header will make some things = easier, however I can't agree that the benefit outweighs the = disadvantages.

Regards
John = B.


On 2012-06-18, at = 10:02 PM, Richard L. Barnes wrote:

Hey = Mike,

Thanks for having some back-and-forth with me on this. =  I think this is a good discussion to have right now.  I would = like to discuss some high-level points, and then I'll respond inline to = your precise points.

tl;dr: In order to meet its deliverables, = the WG needs to define JSON-based formats for integrity and = confidentiality protections.  JWE and JWS don't fit that = requirement, so we should re-consider their adoption and call for new = candidates.

Major points:
1. JOSE is JSON
2. JSON does not = imply canonicalization
3. Compactness and URL-safeness are still OK, = as derivatives

Part 1: JOSE is JSON

The JOSE WG charter = calls out four deliverables, three of which are explicitly required to = be JSON:
-- "JSON-structured integrity protection"
-- = "JSON-structured encryption"
-- "public keys as JSON-structured = objects"
(The fourth is just a list of algorithms, which should be = JSON as well, just as RFC 3370 is ASN.1.)

In light of these = requirements, JWE and JWS are clearly not suitable candidates to fulfill = the working group's milestones.  (At least in their current form.) =  So ISTM that we need to step back and re-evaluate alternatives for = the three above milestones, especially the first two.  (JWK is not = as far off.)

As JSON-based mechanisms, though, the "JSON = serialization" drafts are pretty half-hearted.  Because JWS and JWE = include the cryptographic parameters within the integrity protection, = they have to have the headers included as base64-encoded strings. =  That obviously adds a lot of complexity to encoding and decoding = -- for example, you have to keep the encoded header around even after = you've decoded it! -- and just plain more octets.  The support for = multiple recipients and multiple signatures is both unweildy (matching = up parallel indices for headers and signatures) and inefficient = (multiple integrity check values in encrypted objects).

By = contrast, JSMS takes advantage of the cryptographic wisdom that went = into CMS, while making the syntax pure JSON and as simple as possible. =  Multiple signatures and multiple recipients are supported with = absolute minimum overhead.  So I think it's worth consideration by = the working group.


Part 2: JSON !=3D> = canonicalization

I would like to dispel the myth that a = JSON-based format requires canonicalization.  In JWE/JWS, the JSON = header requires "canonicalization" (via base64url encoding) because it's = included within the integrity protection.  I'm not aware of any = reason for including the cryptographic parameters in the integrity = check, instead of only integrity-protecting the content itself. =  Indeed, if there were an attack based on non-integrity-protected = cryptographic parameters, it would be a pretty big deal, since neither = CMS nor IKE nor provides this protection.  (TLS does provide a = signature over the algorithms, but only as a way to bind the public key = to the session.)

Indeed CMS doesn't require canonicalization at = all, except for attributes that are included in the protected content = (signedAttrs / authenticatedAttrs), which need to be DER-encoded. =  In JSMS, we don't allow those parameters, so there is no need for = canonicalization at all.  All the "canonicalization" that's needed = is to base64url-encode the protected content.  In that regard, JSMS = is even simpler than JWE/JWS.


Part 3: Compactness and = URL-safeness are still OK, as derivatives

I have absolutely no = objection to defining a compact, URL-safe format.  Indeed, I did so = in the JSMS draft, in Section 5.  Encoding the example from Section = 3.1 of the JWS spec, we get the following JSMS object:

{
=    "v":1,
   "t":"au",
=    "a":"hs256",
=    "c":"eyJpc3MiOiJqb2...0cnVlfQ",
=    "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo",
=    "ki":"rSIilRk8Ego"
}

If we remove the = decorative spaces and base64url-encode, we only use 88 octets more than = JWS (267 vs. 179).  If we take this a step further and define an = explicit compact format for AuthenticatedData, we can emulate JWS by = moving the content and MAC fields outside and dot-combining.  That = avoids double-base64url-encoding, and only takes up 11 more octets than = a JWS (190 vs 179).  (I've put the code to generate these in the = Github project linked earlier.)

So it's fine to have a compact, = URL-safe format for an objective, but it makes *much* more sense to = derive that from a full-size, usable, JSON format than the other way = around.

Responses to specific points inline = below.


Fair enough.  I'll = briefly respond to each in turn.  Before doing so, I'll say that = I'm writing in the spirit of trying to increase mutual understanding and = consensus, rather than taking the point of view that the status quo is = the only reasonable outcome.

-- Not being = JSON

This was by = design, so that the results are URL-safe.  This is required, for = instance, for them to be used as OAuth Bearer Tokens.  At the = request of the working group, closely related pure-JSON drafts were also = published.  See:

http://tools.ietf.org/html/draft-jones-json-web-signature-j= son-serialization-01 and
http://tools.ietf.org/html/draft-jones-json-web-encryption= -json-serialization-01

Use them if you = prefer if they better suit your use cases.  They could be adopted = as working group documents, if there's interest.

See = above.  These are super-clunky, and the need to be the main focus = of the WG, not an afterthought.


-- = Not supporting multiple recipients

The JSON = serialization drafts above do, again, in response to use cases presented = by the working group.


See above.  Because = of the unnecessary inclusion of the header in the integrity check, this = is far less efficient than it should be.


-- Lacking clear distinctions between signing and = MAC

Functionally, these are very similar operations, at least = from an implementation perspective, so it's not clear that making a = clear distinction would help either developers or adoption in any = practical way.  They achieve overlapping, but admittedly sometimes = different goals.  I believe that developers can be trusted to use = the algorithms that achieve their applications' goals without making a = hard distinction between the two.  But I'd be interested in hearing = your thoughts on why you believe a brighter-line distinction might be = useful or necessary.

It's important if you want to = do MACs with anything other than pre-shared keys.  If you want to = do anything more advanced, you need to have wrapped keys, in which case = an object with a MAC starts to look a lot more like a JWE than a = JWS.


-- Lacking clear processing = instructions for different key establishment = modalities

This seems like = an area where the existing drafts could be refined to add descriptions = for additional establishment modalities, possibly based upon your ideas = and descriptions, should the working group decide to do so.  What = additional modalities do you have use cases for that you believe are not = achievable or straightforward with the existing drafts?  The = existing modalities supported are largely those that existing developers = had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and = draft-rescorla-jsms.

Bear in mind = that the balance that the current drafts try to strike is keeping the = Mandatory to Implement (MTI) feature footprint small enough that = developers, including Web developers, are likely to adopt the specs, = while still providing enough functionality to make them generally = useful.  As in any balance, it's often possible to shift things a = bit and still maintain the balance, but I'd like people to keep the = ubiquitous adoption goal front-and-center when proposing additional = functionality.

Ubiquitous = deployment and usefulness trump theoretical completeness.  (Just = look at XMLDSIG and XMLENC to understand that!)

I = agree that we need to find a reasonable MTI.  The current JSMS = draft doesn't really specify which parts are MTI, beyond basic things = like base64url encoding and ignoring unknown fields.

My main = concern is that JWS and JWE don't really tell me which fields need to be = present for which use case.  If I'm putting a MAC on a JWS vs. a = signature, do I need "jwk" or "jku" fields to be populated? =  Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into = sub-objects.


-- Lack of clear = typing of objects

Most JSON = documents aren't clearly typed; instead, developers and implementations = understand from context what the meaning of each field is.  XML is = clearly typed, but developers are voting with their feet by moving to = JSON.

What practical = advantages resulting from overlaying a typing infrastructure on JSON do = you believe are worth the potential costs of doing so?  BTW, I'm = not opposed to having a JSON schema description of the JOSE JSON data = structures like JSMS did in http= ://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative = one.

I actualy don't have a hugely urgent = requirement here either.  It's something that others in the WG had = requested, which is trivial to add in JSMS, but not in JWE/JWS -- again = because of the unnecessary integrity protection of the = header.


-- Lack of versioning for = future extensibility

An optional = version field could be added if the working group desires, however the = last time the working group discussed it, they decided not to do so. =  Rather, specs like this effectively become "versioned" when = revised in a way that new fields are added.  If you understand the = new fields, you support that new version.  (Note that this is = independent of whether there is a version number field, which according = to some participants in the previous discussion, they regarded as = therefore being redundant information.)

I'm not = religious about not having a version number field, but often "less is = more".

Indeed, I'm not religious either.  It = just seems like a general good idea to state this directly as opposed to = having parsers divine it based on which fields are present.  To = quote RFC 5652:
"
  Each of the major data structures = includes a version number as the
  first item in the data = structure.  The version numbers are intended
  to = avoid ASN.1 decode errors.  Some implementations do not check = the
  version number prior to attempting a decode, and if = a decode error
  occurs, then the version number is = checked as part of the error
  handling routine. =  This is a reasonable approach; it places error
=   processing outside of the fast path.  This approach is = also forgiving
  when an incorrect version number is used = by the = sender.
"


Best,
--Richard






Best = wishes,
-- = Mike

-----Original = Message-----
From: Richard L. = Barnes [mailto:rbarnes@bbn.com]
Sent: Friday, June 15, 2012 3:00 = PM
To: Mike = Jones
Cc: jose@ietf.org
Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt

Ok, so maybe I = should have phrased my lead-in differently.  IMO, the current JW* = specs are deficient in several ways, e.g.:
-- Not being JSON
-- Not supporting multiple = recipients
-- Lacking clear = distinctions between signing and MAC
-- Lacking clear processing instructions for different key = establishment modalities
-- = Lack of clear typing of objects
-- Lack of versioning for future = extensibility

Looking at the = current specs, it didn't seem to me that it would be simple to adapt = them to address these deficiencies.  So I just did a re-write. =  If you think they can be addressed within the current framework, = please explain.  I just found it simpler to start from whole = cloth.

Cheers,
--Richard



On Jun 15, = 2012, at 5:43 PM, Mike Jones wrote:

Hi Richard,

If you're puzzled by specific = design decisions in the JOSE documents, I encourage you to ask about = them on the list.  The documents have significant history going = back to mid-2010 when convergence discussions started among people with = four different JSON signing & encryption proposals.  JWT and = the current JOSE specs and implementations are the result.  I = realize that not all the JOSE participants were part of those = discussions from the beginning (although many were) and so teasing out = the rationale for specific decisions might help people better understand = the choices made, and hopefully thereby increase consensus behind the = eventual working group choices.

If the list that you're puzzled = by is the bulleted list below, maybe we can start a discussion on that = basis.

Best = wishes,
= = = = -- Mike

-----Original = Message-----
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf =
Of Richard L. = Barnes
Sent: Friday, June 15, 2012 2:08 = PM
To: jose@ietf.org
Subject: [jose] = Fwd: New Version Notification for =
draft-barnes-jose-jsms-00.txt
<= blockquote type=3D"cite">

Dear JOSE = WG,

Like Mr. Manger, once I finally = got around to doing a thorough review of the JW* specs, I was kind of = puzzled by some of the design decisions.  So I also went through = and wrote an alternative format, this time taking a more of a cue from = CMS.  A link to the document is = below.

Summary of = differences:

o  JSMS is pure JSON, = whereas in JWE and JWS only the = header
   parameters are represented in = JSON.

o  JSMS allows for full = algorithm agility in key agreement, while = JWE
   only allows = ECDH-ES.

o  JSMS supports multiple = recipients for EncryptedData = and
   AuthenticatedData objects via the = inclusion of multiple = WrappedKey
   objects. =  Sending a JWE to multiple recipients requires = re-
   encryption of the entire object for = each recipient.

o  The signature and MAC = functions of the JWS object are = separated
   into = SignedData and AuthenticatedData JSMS = objects.

o  JSMS parameters are not = integrity-protected, as they are in = JWE
   and = JWS.

o  The "typ" and "zip" = parameters are not defined in JSMS, but = could
   be added without significant = change.

o  JSMS requires that = recipients MUST ignore unknown = header
   parameters, in order to facilitate = extensibility.

I've also thrown together an = initial JavaScript implementation (based on NodeJS for some python = crypto glue), which is on = github:
<https://github.com/bifurcatio= n/jsms>

Comments are very welcome. =  

Thanks,
--Richard



Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /blockquote>
Subject:= New Version Notification for = draft-barnes-jose-jsms-00.txt
Date: June 15, 2012 4:56:09 PM = EDT
To: rbarnes@bbn.com


A new = version of I-D, draft-barnes-jose-jsms-00.txt has been =
successfully submitted by Richard Barnes and posted to the = IETF
repository.

Filename: = draft-barnes-jose-jsms
Revision: = 00
Title: JavaScript Message Security = Format
Creation= date: = 2012-06-15
WG = ID: = = Individual = Submission
Number = of pages: 25
URL: =             http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt
=
Status: =          http://dat= atracker.ietf.org/doc/draft-barnes-jose-jsms
Htmlized: =        http://tools= .ietf.org/html/draft-barnes-jose-jsms-00
=


Abstract:
Many= applications require the ability to send cryptographically =  
secured = messages.  While the IETF has defined a number of formats for =  
such = messages (e.g.  CMS) those formats use encodings which are not =  
easy = to use in modern applications.  This document describes the =  
JavaScript Message Security format (JSMS), a new = cryptographic =  
message = format which is based on JavaScript Object Notation (JSON) =  
and = thus is easy for many applications to generate and = parse.




The = IETF Secretariat

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


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



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

_____________________________= __________________
jose mailing list
jose@ietf.org
https://www.ietf.org/m= ailman/listinfo/jose


= --Apple-Mail=_9A8C510C-6419-44B9-8BE1-4436A5486DE1-- --Apple-Mail=_E738CE33-8BDE-4335-BBD3-C75286431960 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx OTIxMTkyMlowIwYJKoZIhvcNAQkEMRYEFOZ9u6CCT5jmSi807TF/6Mw43Jr/MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AGyknqEJXY0Ijz58XLvQqWotBamB//4up/FOLxS2MvhcZWZIFebaVaFt5bFcfdGltgLzly8+nVlZ gXDQ+aCPRg9I0JneJdR8sBnBloNgf2gMFDyKAwgqqbUw5RzYFYvb3wrlgldqaqA+0zQ5b0Wg+57V nzTrEUzhwdSakaMlS2FAybSzKy8WDDEcCehCJ/L9F9TKPDRn+Z7LjxbSBNtx/79pH57RxuLdQtnE Nd4qGqhIlhUamf/RmIvRE6orY/evQYNCNj4dAGDUDl3bZyCADD4FIsCTG6IqYLu+1BCi3Z4UU5nu xuiUQ65+OwWHMSELqLpEHpv1OodRuF48LB0gO7YAAAAAAAA= --Apple-Mail=_E738CE33-8BDE-4335-BBD3-C75286431960-- From rbarnes@bbn.com Tue Jun 19 16:00: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 E014711E808F for ; Tue, 19 Jun 2012 16:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILI+eQBsRy8T for ; Tue, 19 Jun 2012 16:00:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B4B6911E8085 for ; Tue, 19 Jun 2012 16:00:04 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:58929) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh7OO-000EE9-3f; Tue, 19 Jun 2012 18:59:24 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> Date: Tue, 19 Jun 2012 19:00:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 23:00:07 -0000 Hey John, Interesting points, but I don't think they actually apply here. With regard to downgrade attacks:=20 The attack that RFC 5752 is concerned with is when an attacker strips = signatures from a signed message, so that the only ones left are ones he = can tamper with. So the integrity protection here is "horizontal"; it = goes across signatures. The integrity protection in JWS/JWE is = "vertical" -- it only protects one signer's parameters -- so it is, so = to speak, orthogonal. With regard to "brown bag" attacks: The root of this attack is ambiguity about what content is *signed* vs. = what content is *used*. If an application doesn't verify that it's = actually using the stuff that's signed, then it can be tricked into = accepting something unsigned. (Cf. = ) =20 However, I don't think any of the current proposals have that problem. = In JWE/JWS, the signed content is right there between the dots, and in = JSMS, it's in the "content" element. The current JSMS draft does allow = detached signatures, but with a "voids your warranty" sticker on it. In any case, these attacks have nothing to do with whether the = cryptographic parameters are integrity-protected with the content. The = example attacks in the IBM still work regardless -- the whole point of = the attack is that the cryptographic processing is the same, only the = (non-crypto) matching of content is flawed. With regard to "arbitrary attributes": We can have that here, too, but you need canonicalization. And = base64-encoding is not not canonicalization -- it just waves its hands = over the question of equivalence. In my opinion, we should keep the = cryptographic object simple by disallowing attributes, and push the = attributes you would sign inside of the thing being signed. If people = really do want attributes, it doesn't seem to me like JSON = canonicalization is very hard. I can do it in 19 lines of python:=20 With regard too "meta-data in the body": It seems to me like if we're trying to define a general format for = applying security protections, then we ought to keep out things that = aren't strictly security relevant. Those things can go in = application-specific content types (e.g., SAML) without polluting the = general purpose header. =20 With regard to "defense in depth" and selling this to government = agencies: CMS, via S/MIME, is in broad use across multiple federal agencies and = large enterprises. JSMS is essentially a profile of CMS (see Section = 7), and has the same security properties. Cheers, --Richard On Jun 19, 2012, at 5:10 PM, John Bradley wrote: > Hi Richard, >=20 > Originally we only integrity protected the header for signing. We = added the integrity protection to encryption as part of AEAD, as = encryption can also be used for sender verification. >=20 > I understand the argument that it makes things simpler if we don't = integrity protect the header information. >=20 > However xmldsig, provides integrity over those elements to prevent = possible downgrade attacks by manipulating the algorithms. =20 >=20 > CMS may not typically provide that integrity protection but I think = Jim Schaad and Sean Terner created RFC5752 to address downgrade attacks. > Given they are on this list they can speak to their view on integrity = over the crypto parameters. >=20 > I also recall when working on InfoCards there was a Monte Carlo/Brown = Bag attack that needs to be considered if we move to something more like = a detached signature. >=20 > The other design consideration is that we wanted to be able to sign = arbitrary byte strings not just JSON. You could sign XML if you = wanted.=20 > That prevented us from including meta-data in the body as we didn't = want to touch it. That left us with the header to include additional = elements in. =20 > Not integrity protecting those elements as well would be a problem. =20= >=20 > I am not a CMS expert but I believe it allows for signing of arbitrary = attributes not unlike the current JOSE spec. >=20 > Especially for something that will be used with JWT security tokens I = will have a hard time making the argument to NIST and others that need = to approve this format that not integrity protecting the header = parameters is appropriate defence in depth, for something that might be = replacing signed SAML assertions in some applications. >=20 > I do understand how not integrity protecting the header will make some = things easier, however I can't agree that the benefit outweighs the = disadvantages. >=20 > Regards > John B. >=20 >=20 > On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >=20 >> Hey Mike, >>=20 >> Thanks for having some back-and-forth with me on this. I think this = is a good discussion to have right now. I would like to discuss some = high-level points, and then I'll respond inline to your precise points. >>=20 >> tl;dr: In order to meet its deliverables, the WG needs to define = JSON-based formats for integrity and confidentiality protections. JWE = and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates. >>=20 >> Major points: >> 1. JOSE is JSON >> 2. JSON does not imply canonicalization >> 3. Compactness and URL-safeness are still OK, as derivatives >>=20 >> Part 1: JOSE is JSON >>=20 >> The JOSE WG charter calls out four deliverables, three of which are = explicitly required to be JSON: >> -- "JSON-structured integrity protection" >> -- "JSON-structured encryption" >> -- "public keys as JSON-structured objects" >> (The fourth is just a list of algorithms, which should be JSON as = well, just as RFC 3370 is ASN.1.) >>=20 >> In light of these requirements, JWE and JWS are clearly not suitable = candidates to fulfill the working group's milestones. (At least in = their current form.) So ISTM that we need to step back and re-evaluate = alternatives for the three above milestones, especially the first two. = (JWK is not as far off.) >>=20 >> As JSON-based mechanisms, though, the "JSON serialization" drafts are = pretty half-hearted. Because JWS and JWE include the cryptographic = parameters within the integrity protection, they have to have the = headers included as base64-encoded strings. That obviously adds a lot = of complexity to encoding and decoding -- for example, you have to keep = the encoded header around even after you've decoded it! -- and just = plain more octets. The support for multiple recipients and multiple = signatures is both unweildy (matching up parallel indices for headers = and signatures) and inefficient (multiple integrity check values in = encrypted objects). >>=20 >> By contrast, JSMS takes advantage of the cryptographic wisdom that = went into CMS, while making the syntax pure JSON and as simple as = possible. Multiple signatures and multiple recipients are supported = with absolute minimum overhead. So I think it's worth consideration by = the working group. >>=20 >>=20 >> Part 2: JSON !=3D> canonicalization >>=20 >> I would like to dispel the myth that a JSON-based format requires = canonicalization. In JWE/JWS, the JSON header requires = "canonicalization" (via base64url encoding) because it's included within = the integrity protection. I'm not aware of any reason for including the = cryptographic parameters in the integrity check, instead of only = integrity-protecting the content itself. Indeed, if there were an = attack based on non-integrity-protected cryptographic parameters, it = would be a pretty big deal, since neither CMS nor IKE nor provides this = protection. (TLS does provide a signature over the algorithms, but only = as a way to bind the public key to the session.) >>=20 >> Indeed CMS doesn't require canonicalization at all, except for = attributes that are included in the protected content (signedAttrs / = authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't = allow those parameters, so there is no need for canonicalization at all. = All the "canonicalization" that's needed is to base64url-encode the = protected content. In that regard, JSMS is even simpler than JWE/JWS. >>=20 >>=20 >> Part 3: Compactness and URL-safeness are still OK, as derivatives >>=20 >> I have absolutely no objection to defining a compact, URL-safe = format. Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example from Section 3.1 of the JWS spec, we get the following JSMS = object: >>=20 >> {=20 >> "v":1, >> "t":"au", >> "a":"hs256", >> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >> "ki":"rSIilRk8Ego" >> } >>=20 >> If we remove the decorative spaces and base64url-encode, we only use = 88 octets more than JWS (267 vs. 179). If we take this a step further = and define an explicit compact format for AuthenticatedData, we can = emulate JWS by moving the content and MAC fields outside and = dot-combining. That avoids double-base64url-encoding, and only takes up = 11 more octets than a JWS (190 vs 179). (I've put the code to generate = these in the Github project linked earlier.) >>=20 >> So it's fine to have a compact, URL-safe format for an objective, but = it makes *much* more sense to derive that from a full-size, usable, JSON = format than the other way around. >>=20 >> Responses to specific points inline below. >>=20 >>=20 >>> Fair enough. I'll briefly respond to each in turn. Before doing = so, I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >>>=20 >>> -- Not being JSON >>>=20 >>> This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >>>=20 >>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 and >>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 >>>=20 >>> Use them if you prefer if they better suit your use cases. They = could be adopted as working group documents, if there's interest. >>=20 >> See above. These are super-clunky, and the need to be the main focus = of the WG, not an afterthought. >>=20 >>=20 >>> -- Not supporting multiple recipients >>>=20 >>> The JSON serialization drafts above do, again, in response to use = cases presented by the working group. >>=20 >>=20 >> See above. Because of the unnecessary inclusion of the header in the = integrity check, this is far less efficient than it should be. >>=20 >>=20 >>> -- Lacking clear distinctions between signing and MAC >>>=20 >>> Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. >>=20 >> It's important if you want to do MACs with anything other than = pre-shared keys. If you want to do anything more advanced, you need to = have wrapped keys, in which case an object with a MAC starts to look a = lot more like a JWE than a JWS. >>=20 >>=20 >>> -- Lacking clear processing instructions for different key = establishment modalities >>>=20 >>> This seems like an area where the existing drafts could be refined = to add descriptions for additional establishment modalities, possibly = based upon your ideas and descriptions, should the working group decide = to do so. What additional modalities do you have use cases for that you = believe are not achievable or straightforward with the existing drafts? = The existing modalities supported are largely those that existing = developers had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and draft-rescorla-jsms. >>>=20 >>> Bear in mind that the balance that the current drafts try to strike = is keeping the Mandatory to Implement (MTI) feature footprint small = enough that developers, including Web developers, are likely to adopt = the specs, while still providing enough functionality to make them = generally useful. As in any balance, it's often possible to shift = things a bit and still maintain the balance, but I'd like people to keep = the ubiquitous adoption goal front-and-center when proposing additional = functionality. >>>=20 >>> Ubiquitous deployment and usefulness trump theoretical completeness. = (Just look at XMLDSIG and XMLENC to understand that!)=20 >>=20 >> I agree that we need to find a reasonable MTI. The current JSMS = draft doesn't really specify which parts are MTI, beyond basic things = like base64url encoding and ignoring unknown fields. >>=20 >> My main concern is that JWS and JWE don't really tell me which fields = need to be present for which use case. If I'm putting a MAC on a JWS = vs. a signature, do I need "jwk" or "jku" fields to be populated? = Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into sub-objects. >>=20 >>=20 >>> -- Lack of clear typing of objects >>>=20 >>> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >>>=20 >>> What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. >>=20 >> I actualy don't have a hugely urgent requirement here either. It's = something that others in the WG had requested, which is trivial to add = in JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity protection of the header. >>=20 >>=20 >>> -- Lack of versioning for future extensibility >>>=20 >>> An optional version field could be added if the working group = desires, however the last time the working group discussed it, they = decided not to do so. Rather, specs like this effectively become = "versioned" when revised in a way that new fields are added. If you = understand the new fields, you support that new version. (Note that = this is independent of whether there is a version number field, which = according to some participants in the previous discussion, they regarded = as therefore being redundant information.) >>>=20 >>> I'm not religious about not having a version number field, but often = "less is more". >>=20 >> Indeed, I'm not religious either. It just seems like a general good = idea to state this directly as opposed to having parsers divine it based = on which fields are present. To quote RFC 5652: >> " >> Each of the major data structures includes a version number as the >> first item in the data structure. The version numbers are intended >> to avoid ASN.1 decode errors. Some implementations do not check = the >> version number prior to attempting a decode, and if a decode error >> occurs, then the version number is checked as part of the error >> handling routine. This is a reasonable approach; it places error >> processing outside of the fast path. This approach is also = forgiving >> when an incorrect version number is used by the sender. >> " >>=20 >>=20 >> Best, >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>> Sent: Friday, June 15, 2012 3:00 PM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >>>=20 >>> Ok, so maybe I should have phrased my lead-in differently. IMO, the = current JW* specs are deficient in several ways, e.g.: >>> -- Not being JSON >>> -- Not supporting multiple recipients >>> -- Lacking clear distinctions between signing and MAC >>> -- Lacking clear processing instructions for different key = establishment modalities >>> -- Lack of clear typing of objects >>> -- Lack of versioning for future extensibility >>>=20 >>> Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >>>=20 >>> Cheers, >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>=20 >>>> Hi Richard, >>>>=20 >>>> If you're puzzled by specific design decisions in the JOSE = documents, I encourage you to ask about them on the list. The documents = have significant history going back to mid-2010 when convergence = discussions started among people with four different JSON signing & = encryption proposals. JWT and the current JOSE specs and = implementations are the result. I realize that not all the JOSE = participants were part of those discussions from the beginning (although = many were) and so teasing out the rationale for specific decisions might = help people better understand the choices made, and hopefully thereby = increase consensus behind the eventual working group choices. >>>>=20 >>>> If the list that you're puzzled by is the bulleted list below, = maybe we can start a discussion on that basis. >>>>=20 >>>> Best wishes, >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf=20 >>>> Of Richard L. Barnes >>>> Sent: Friday, June 15, 2012 2:08 PM >>>> To: jose@ietf.org >>>> Subject: [jose] Fwd: New Version Notification for=20 >>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>> Dear JOSE WG, >>>>=20 >>>> Like Mr. Manger, once I finally got around to doing a thorough = review of the JW* specs, I was kind of puzzled by some of the design = decisions. So I also went through and wrote an alternative format, this = time taking a more of a cue from CMS. A link to the document is below. >>>>=20 >>>> Summary of differences: >>>>=20 >>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>> parameters are represented in JSON. >>>>=20 >>>> o JSMS allows for full algorithm agility in key agreement, while = JWE >>>> only allows ECDH-ES. >>>>=20 >>>> o JSMS supports multiple recipients for EncryptedData and >>>> AuthenticatedData objects via the inclusion of multiple = WrappedKey >>>> objects. Sending a JWE to multiple recipients requires re- >>>> encryption of the entire object for each recipient. >>>>=20 >>>> o The signature and MAC functions of the JWS object are separated >>>> into SignedData and AuthenticatedData JSMS objects. >>>>=20 >>>> o JSMS parameters are not integrity-protected, as they are in JWE >>>> and JWS. >>>>=20 >>>> o The "typ" and "zip" parameters are not defined in JSMS, but = could >>>> be added without significant change. >>>>=20 >>>> o JSMS requires that recipients MUST ignore unknown header >>>> parameters, in order to facilitate extensibility. >>>>=20 >>>> I've also thrown together an initial JavaScript implementation = (based on NodeJS for some python crypto glue), which is on github: >>>> >>>>=20 >>>> Comments are very welcome. =20 >>>>=20 >>>> Thanks, >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for = draft-barnes-jose-jsms-00.txt >>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>> To: rbarnes@bbn.com >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >>>>> successfully submitted by Richard Barnes and posted to the IETF=20 >>>>> repository. >>>>>=20 >>>>> Filename: draft-barnes-jose-jsms >>>>> Revision: 00 >>>>> Title: JavaScript Message Security Format >>>>> Creation date: 2012-06-15 >>>>> WG ID: Individual Submission >>>>> Number of pages: 25 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> Many applications require the ability to send cryptographically =20= >>>>> secured messages. While the IETF has defined a number of formats = for =20 >>>>> such messages (e.g. CMS) those formats use encodings which are = not =20 >>>>> easy to use in modern applications. This document describes the =20= >>>>> JavaScript Message Security format (JSMS), a new cryptographic =20 >>>>> message format which is based on JavaScript Object Notation (JSON) = =20 >>>>> and thus is easy for many applications to generate and parse. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From breno@google.com Tue Jun 19 16:08: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 39A4B11E80E5 for ; Tue, 19 Jun 2012 16:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epGkHwtHb-Yf for ; Tue, 19 Jun 2012 16:08:06 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B109411E808F for ; Tue, 19 Jun 2012 16:08:06 -0700 (PDT) Received: by yhq56 with SMTP id 56so5859601yhq.31 for ; Tue, 19 Jun 2012 16:08:06 -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:content-transfer-encoding:x-system-of-record; bh=1rIzFRLxZHzbjb4zzEwvJcjwYQXXTVebPewVZseuXvk=; b=mv7lIlQrG0PDs3BXnm9TWTf8juuu9lIoOBn7VGRJf52duGcZRo+NhQvz6l9bvF+33R 7U39BtM91pVWeaJJpF7FYUpSWWIe4rpCeyQx5brwHc8Z4fAajFpuGROYJx2ikxVck7Sq LbW8wPiE1KzZOpD8C3aFopmNMV4RgN33+TAPYFaKOrPbl+fXgVQj6te6MzxBamk3rkGl 42OAzX70lo0JoMdjy6+O5jZiD8hjI1SMwhFh0AwMhqYGjPC8kcGhTVtwUnVv+FTzKi7q Yl58wMVGwwYGqNHS4hMAXTMvEYWgpBMd/o0rVjkYMATJO+1xJMhvhBZZcVI9sOT7Oo9m 7GNw== 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:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=1rIzFRLxZHzbjb4zzEwvJcjwYQXXTVebPewVZseuXvk=; b=O28n7ofS19RBQe3/3AINIaATYfPucQ9VSpc57F5pvgSPNgDxt1o4E6WdrXWNr54gSX mUEnIhgjYFGg4g3UoJPokDAyk467+ngeBx1MdUq/RxKFaU4+IdRZVB7ptRwyvK0Dkqnf dI+BOGESvcT1m8bmfZvWsQiQdxeqOaQk5T6GvDXIlw6Zvfm00C2i6rZifwno5XJMWrf0 MCg766j6TcT67x9QWC9enTA7E4Luq1Zsi3TF9uvqVtjixg2Qj1IU7Dsn3Ge4ZKqH86ZC bzsTJWkfRBlIt5t/ieraboTy6Q2QheccXoXkgdKc1CgkbagV4W/aG+WEYJhPVDsp6/lr M5fA== Received: by 10.50.220.129 with SMTP id pw1mr2844820igc.29.1340147285845; Tue, 19 Jun 2012 16:08:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.220.129 with SMTP id pw1mr2844810igc.29.1340147285756; Tue, 19 Jun 2012 16:08:05 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Tue, 19 Jun 2012 16:08:05 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> Date: Tue, 19 Jun 2012 16:08:05 -0700 Message-ID: From: Breno de Medeiros To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmJLwvVbBkGGV7tFsDQVUGXh9q0taOo9GnUkI31rXVbMHr4zqvnpHTmmmEcUlASvqrTEEhsYt+B7V/l/tHlGdYoa43KqDSo1ceUGs9xjJy8SF+vw8gTsU0X8pRJTaf1B5eVLlsr Cc: John Bradley , Mike Jones , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 23:08:07 -0000 On Tue, Jun 19, 2012 at 4:00 PM, Richard L. Barnes wrote: > However, I don't think any of the current proposals have that problem. = =A0In JWE/JWS, the signed content is right there between the dots, and in J= SMS, it's in the "content" element. =A0The current JSMS draft does allow de= tached signatures, but with a "voids your warranty" sticker on it. There is no point of defining a security mechanism with a *void* warranty. It's harmful. --=20 --Breno From rbarnes@bbn.com Tue Jun 19 16:15: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 52AB311E8126 for ; Tue, 19 Jun 2012 16:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFFU5y7s7K0f for ; Tue, 19 Jun 2012 16:15:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D152111E808A for ; Tue, 19 Jun 2012 16:15:15 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:58949) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh7d6-000ENM-CT; Tue, 19 Jun 2012 19:14:36 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Richard L. Barnes" In-Reply-To: Date: Tue, 19 Jun 2012 19:15:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> To: Breno de Medeiros X-Mailer: Apple Mail (2.1278) Cc: John Bradley , Mike Jones , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 23:15:16 -0000 On Jun 19, 2012, at 7:08 PM, Breno de Medeiros wrote: > On Tue, Jun 19, 2012 at 4:00 PM, Richard L. Barnes = wrote: >> However, I don't think any of the current proposals have that = problem. In JWE/JWS, the signed content is right there between the = dots, and in JSMS, it's in the "content" element. The current JSMS = draft does allow detached signatures, but with a "voids your warranty" = sticker on it. >=20 > There is no point of defining a security mechanism with a *void* > warranty. It's harmful. Heh, that's the story of XML-DSig in a nutshell. Seriously, what I meant to say was that to cover the "Brown bag" risks, = the document just needs to say something like, "if your application uses = JOSE as a detached signature, then you need to make sure that the = content that's used is the content that was signed." JSMS does that = currently, to an extent, but could be stronger. The only way you get around that is to disallow detached signatures, = which I think is probably not something we want to do, given the large = number of use cases that would rule out. (E.g., anything resembling = S/MIME) --Richard From ve7jtb@ve7jtb.com Wed Jun 20 15:57: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 1CF4911E80D1 for ; Wed, 20 Jun 2012 15:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiIQRmjTGWMQ for ; Wed, 20 Jun 2012 15:57:39 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id DC55711E80CB for ; Wed, 20 Jun 2012 15:57:38 -0700 (PDT) Received: by yhp26 with SMTP id 26so7159yhp.26 for ; Wed, 20 Jun 2012 15:57:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=vY2KhohraazzYo6vT5h6ywB7YXxBH/Ak2cwmgLO1prk=; b=frzms+XKR/TrIWGmU9JSHO1oJw7L2YMTrikP9XSldW3OxaDXuB4ppWLpmvf+7F2GVl sSHCnLAgnXOJ1YZMJWb2vhl93cSXFgd8modhqAv3hJXbHzPFmu3HZfYqfc5o8MK9yQvq cpMdF7w221uPXffPUzawWgyyGc+wO3Los3xHB3xaZBQdribrrHACqT4yXpLzkmF7CrSr EfX0MaAftwDQW0dAq7vQX8WYHI8lEFLuFYk43fIFF0F1jjSotHmhzb0HORJxu7zQHaBU TkVWc3P0ymVIgd+seFrEIndOVnfDhY43KGWj4nqCn4M714YblzB0Bl7Q/Vg5wGjF906m hYwA== Received: by 10.236.46.74 with SMTP id q50mr30227181yhb.30.1340233058398; Wed, 20 Jun 2012 15:57:38 -0700 (PDT) Received: from [192.168.1.213] ([190.20.13.0]) by mx.google.com with ESMTPS id g22sm100035367yhh.20.2012.06.20.15.57.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jun 2012 15:57:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_56A7E968-76B7-4EDB-89B0-BE72324690F0"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Wed, 20 Jun 2012 18:57:26 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnadc4uCr8J59Ie/LMszt8WotnkCnb0T7dA0L+7nqyNfmO3LSY9eBY0jEMh5D+PAlmIxeq8 Cc: jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 22:57:41 -0000 --Apple-Mail=_56A7E968-76B7-4EDB-89B0-BE72324690F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard, While for PKCS 1.5 the hash algorithm is baked into the padding and not = susceptible to modification with ECDH or RSA-PSS it is not. There are possible hash truncation attacks by shortening SHA256 to = SHA224 as an example (I know we preclude truncated hashes at the = moment). The bad feeling I get around this is that if there is a scenario where = the attacker controls the plaintext to be signed and there is no signer = controlled text contributed there are potential bad things that could = happen down the road. This bit us with x509 certs not that long ago (yes with MD5 admittedly) = where the attacker could use a certificate extension to include extra = data and cause a pre collided hash to be generated. Having part of the signed data outside the control of an attacker is a = good thing. (having a nonce or message ID in the envelope is possible = though not yet required in JWS.) I am still of the opinion that putting the base64 encoded envelope = inside the hash calculation is a valid way to allow additional = attributes. =20 Another structure to hold the attributes adds more complexity, as would = saying that they need to be inside the signed object. I think part of this is that as one of the openID Connect authors I look = at this as a necessary security token format, for OAuth and Connect. =20 For that simple processing with one signature is a high priority for = adoption. =46rom a general signing/encrypting of documents point of view you = legitimately have different priorities. I know it is hard to prove a negative but It is also going to be = difficult for me to go back to security people at google Facebook and = other places and explain how not integrity protecting the header could = be better than integrity protecting it. It seems that I would be reduced to arguing that this is no worse than = CMS and that hasn't been proven insecure yet. =20 Allowing a possible attacker to control the hash output, and not = integrity protecting the additional data, seems like something I am = bound to regret in the future. Regards John B. On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: > Hey John, >=20 > Interesting points, but I don't think they actually apply here. >=20 > With regard to downgrade attacks:=20 >=20 > The attack that RFC 5752 is concerned with is when an attacker strips = signatures from a signed message, so that the only ones left are ones he = can tamper with. So the integrity protection here is "horizontal"; it = goes across signatures. The integrity protection in JWS/JWE is = "vertical" -- it only protects one signer's parameters -- so it is, so = to speak, orthogonal. >=20 >=20 > With regard to "brown bag" attacks: >=20 > The root of this attack is ambiguity about what content is *signed* = vs. what content is *used*. If an application doesn't verify that it's = actually using the stuff that's signed, then it can be tricked into = accepting something unsigned. (Cf. = ) =20 >=20 > However, I don't think any of the current proposals have that problem. = In JWE/JWS, the signed content is right there between the dots, and in = JSMS, it's in the "content" element. The current JSMS draft does allow = detached signatures, but with a "voids your warranty" sticker on it. >=20 > In any case, these attacks have nothing to do with whether the = cryptographic parameters are integrity-protected with the content. The = example attacks in the IBM still work regardless -- the whole point of = the attack is that the cryptographic processing is the same, only the = (non-crypto) matching of content is flawed. >=20 >=20 > With regard to "arbitrary attributes": >=20 > We can have that here, too, but you need canonicalization. And = base64-encoding is not not canonicalization -- it just waves its hands = over the question of equivalence. In my opinion, we should keep the = cryptographic object simple by disallowing attributes, and push the = attributes you would sign inside of the thing being signed. If people = really do want attributes, it doesn't seem to me like JSON = canonicalization is very hard. I can do it in 19 lines of python:=20 > >=20 >=20 > With regard too "meta-data in the body": >=20 > It seems to me like if we're trying to define a general format for = applying security protections, then we ought to keep out things that = aren't strictly security relevant. Those things can go in = application-specific content types (e.g., SAML) without polluting the = general purpose header. =20 >=20 >=20 > With regard to "defense in depth" and selling this to government = agencies: >=20 > CMS, via S/MIME, is in broad use across multiple federal agencies and = large enterprises. JSMS is essentially a profile of CMS (see Section = 7), and has the same security properties. >=20 >=20 > Cheers, > --Richard >=20 >=20 >=20 >=20 > On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >=20 >> Hi Richard, >>=20 >> Originally we only integrity protected the header for signing. We = added the integrity protection to encryption as part of AEAD, as = encryption can also be used for sender verification. >>=20 >> I understand the argument that it makes things simpler if we don't = integrity protect the header information. >>=20 >> However xmldsig, provides integrity over those elements to prevent = possible downgrade attacks by manipulating the algorithms. =20 >>=20 >> CMS may not typically provide that integrity protection but I think = Jim Schaad and Sean Terner created RFC5752 to address downgrade attacks. >> Given they are on this list they can speak to their view on integrity = over the crypto parameters. >>=20 >> I also recall when working on InfoCards there was a Monte Carlo/Brown = Bag attack that needs to be considered if we move to something more like = a detached signature. >>=20 >> The other design consideration is that we wanted to be able to sign = arbitrary byte strings not just JSON. You could sign XML if you = wanted.=20 >> That prevented us from including meta-data in the body as we didn't = want to touch it. That left us with the header to include additional = elements in. =20 >> Not integrity protecting those elements as well would be a problem. =20= >>=20 >> I am not a CMS expert but I believe it allows for signing of = arbitrary attributes not unlike the current JOSE spec. >>=20 >> Especially for something that will be used with JWT security tokens I = will have a hard time making the argument to NIST and others that need = to approve this format that not integrity protecting the header = parameters is appropriate defence in depth, for something that might be = replacing signed SAML assertions in some applications. >>=20 >> I do understand how not integrity protecting the header will make = some things easier, however I can't agree that the benefit outweighs the = disadvantages. >>=20 >> Regards >> John B. >>=20 >>=20 >> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>=20 >>> Hey Mike, >>>=20 >>> Thanks for having some back-and-forth with me on this. I think this = is a good discussion to have right now. I would like to discuss some = high-level points, and then I'll respond inline to your precise points. >>>=20 >>> tl;dr: In order to meet its deliverables, the WG needs to define = JSON-based formats for integrity and confidentiality protections. JWE = and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates. >>>=20 >>> Major points: >>> 1. JOSE is JSON >>> 2. JSON does not imply canonicalization >>> 3. Compactness and URL-safeness are still OK, as derivatives >>>=20 >>> Part 1: JOSE is JSON >>>=20 >>> The JOSE WG charter calls out four deliverables, three of which are = explicitly required to be JSON: >>> -- "JSON-structured integrity protection" >>> -- "JSON-structured encryption" >>> -- "public keys as JSON-structured objects" >>> (The fourth is just a list of algorithms, which should be JSON as = well, just as RFC 3370 is ASN.1.) >>>=20 >>> In light of these requirements, JWE and JWS are clearly not suitable = candidates to fulfill the working group's milestones. (At least in = their current form.) So ISTM that we need to step back and re-evaluate = alternatives for the three above milestones, especially the first two. = (JWK is not as far off.) >>>=20 >>> As JSON-based mechanisms, though, the "JSON serialization" drafts = are pretty half-hearted. Because JWS and JWE include the cryptographic = parameters within the integrity protection, they have to have the = headers included as base64-encoded strings. That obviously adds a lot = of complexity to encoding and decoding -- for example, you have to keep = the encoded header around even after you've decoded it! -- and just = plain more octets. The support for multiple recipients and multiple = signatures is both unweildy (matching up parallel indices for headers = and signatures) and inefficient (multiple integrity check values in = encrypted objects). >>>=20 >>> By contrast, JSMS takes advantage of the cryptographic wisdom that = went into CMS, while making the syntax pure JSON and as simple as = possible. Multiple signatures and multiple recipients are supported = with absolute minimum overhead. So I think it's worth consideration by = the working group. >>>=20 >>>=20 >>> Part 2: JSON !=3D> canonicalization >>>=20 >>> I would like to dispel the myth that a JSON-based format requires = canonicalization. In JWE/JWS, the JSON header requires = "canonicalization" (via base64url encoding) because it's included within = the integrity protection. I'm not aware of any reason for including the = cryptographic parameters in the integrity check, instead of only = integrity-protecting the content itself. Indeed, if there were an = attack based on non-integrity-protected cryptographic parameters, it = would be a pretty big deal, since neither CMS nor IKE nor provides this = protection. (TLS does provide a signature over the algorithms, but only = as a way to bind the public key to the session.) >>>=20 >>> Indeed CMS doesn't require canonicalization at all, except for = attributes that are included in the protected content (signedAttrs / = authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't = allow those parameters, so there is no need for canonicalization at all. = All the "canonicalization" that's needed is to base64url-encode the = protected content. In that regard, JSMS is even simpler than JWE/JWS. >>>=20 >>>=20 >>> Part 3: Compactness and URL-safeness are still OK, as derivatives >>>=20 >>> I have absolutely no objection to defining a compact, URL-safe = format. Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example from Section 3.1 of the JWS spec, we get the following JSMS = object: >>>=20 >>> {=20 >>> "v":1, >>> "t":"au", >>> "a":"hs256", >>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>> "ki":"rSIilRk8Ego" >>> } >>>=20 >>> If we remove the decorative spaces and base64url-encode, we only use = 88 octets more than JWS (267 vs. 179). If we take this a step further = and define an explicit compact format for AuthenticatedData, we can = emulate JWS by moving the content and MAC fields outside and = dot-combining. That avoids double-base64url-encoding, and only takes up = 11 more octets than a JWS (190 vs 179). (I've put the code to generate = these in the Github project linked earlier.) >>>=20 >>> So it's fine to have a compact, URL-safe format for an objective, = but it makes *much* more sense to derive that from a full-size, usable, = JSON format than the other way around. >>>=20 >>> Responses to specific points inline below. >>>=20 >>>=20 >>>> Fair enough. I'll briefly respond to each in turn. Before doing = so, I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >>>>=20 >>>> -- Not being JSON >>>>=20 >>>> This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >>>>=20 >>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 and >>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 >>>>=20 >>>> Use them if you prefer if they better suit your use cases. They = could be adopted as working group documents, if there's interest. >>>=20 >>> See above. These are super-clunky, and the need to be the main = focus of the WG, not an afterthought. >>>=20 >>>=20 >>>> -- Not supporting multiple recipients >>>>=20 >>>> The JSON serialization drafts above do, again, in response to use = cases presented by the working group. >>>=20 >>>=20 >>> See above. Because of the unnecessary inclusion of the header in = the integrity check, this is far less efficient than it should be. >>>=20 >>>=20 >>>> -- Lacking clear distinctions between signing and MAC >>>>=20 >>>> Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. >>>=20 >>> It's important if you want to do MACs with anything other than = pre-shared keys. If you want to do anything more advanced, you need to = have wrapped keys, in which case an object with a MAC starts to look a = lot more like a JWE than a JWS. >>>=20 >>>=20 >>>> -- Lacking clear processing instructions for different key = establishment modalities >>>>=20 >>>> This seems like an area where the existing drafts could be refined = to add descriptions for additional establishment modalities, possibly = based upon your ideas and descriptions, should the working group decide = to do so. What additional modalities do you have use cases for that you = believe are not achievable or straightforward with the existing drafts? = The existing modalities supported are largely those that existing = developers had told us they needed and draw both from the precursor = draft-jones-json-web-* documents and draft-rescorla-jsms. >>>>=20 >>>> Bear in mind that the balance that the current drafts try to strike = is keeping the Mandatory to Implement (MTI) feature footprint small = enough that developers, including Web developers, are likely to adopt = the specs, while still providing enough functionality to make them = generally useful. As in any balance, it's often possible to shift = things a bit and still maintain the balance, but I'd like people to keep = the ubiquitous adoption goal front-and-center when proposing additional = functionality. >>>>=20 >>>> Ubiquitous deployment and usefulness trump theoretical = completeness. (Just look at XMLDSIG and XMLENC to understand that!)=20 >>>=20 >>> I agree that we need to find a reasonable MTI. The current JSMS = draft doesn't really specify which parts are MTI, beyond basic things = like base64url encoding and ignoring unknown fields. >>>=20 >>> My main concern is that JWS and JWE don't really tell me which = fields need to be present for which use case. If I'm putting a MAC on a = JWS vs. a signature, do I need "jwk" or "jku" fields to be populated? = Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into sub-objects. >>>=20 >>>=20 >>>> -- Lack of clear typing of objects >>>>=20 >>>> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >>>>=20 >>>> What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. >>>=20 >>> I actualy don't have a hugely urgent requirement here either. It's = something that others in the WG had requested, which is trivial to add = in JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity protection of the header. >>>=20 >>>=20 >>>> -- Lack of versioning for future extensibility >>>>=20 >>>> An optional version field could be added if the working group = desires, however the last time the working group discussed it, they = decided not to do so. Rather, specs like this effectively become = "versioned" when revised in a way that new fields are added. If you = understand the new fields, you support that new version. (Note that = this is independent of whether there is a version number field, which = according to some participants in the previous discussion, they regarded = as therefore being redundant information.) >>>>=20 >>>> I'm not religious about not having a version number field, but = often "less is more". >>>=20 >>> Indeed, I'm not religious either. It just seems like a general good = idea to state this directly as opposed to having parsers divine it based = on which fields are present. To quote RFC 5652: >>> " >>> Each of the major data structures includes a version number as the >>> first item in the data structure. The version numbers are intended >>> to avoid ASN.1 decode errors. Some implementations do not check = the >>> version number prior to attempting a decode, and if a decode error >>> occurs, then the version number is checked as part of the error >>> handling routine. This is a reasonable approach; it places error >>> processing outside of the fast path. This approach is also = forgiving >>> when an incorrect version number is used by the sender. >>> " >>>=20 >>>=20 >>> Best, >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Best wishes, >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>>> Sent: Friday, June 15, 2012 3:00 PM >>>> To: Mike Jones >>>> Cc: jose@ietf.org >>>> Subject: Re: [jose] Fwd: New Version Notification for = draft-barnes-jose-jsms-00.txt >>>>=20 >>>> Ok, so maybe I should have phrased my lead-in differently. IMO, = the current JW* specs are deficient in several ways, e.g.: >>>> -- Not being JSON >>>> -- Not supporting multiple recipients >>>> -- Lacking clear distinctions between signing and MAC >>>> -- Lacking clear processing instructions for different key = establishment modalities >>>> -- Lack of clear typing of objects >>>> -- Lack of versioning for future extensibility >>>>=20 >>>> Looking at the current specs, it didn't seem to me that it would be = simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >>>>=20 >>>> Cheers, >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>=20 >>>>> Hi Richard, >>>>>=20 >>>>> If you're puzzled by specific design decisions in the JOSE = documents, I encourage you to ask about them on the list. The documents = have significant history going back to mid-2010 when convergence = discussions started among people with four different JSON signing & = encryption proposals. JWT and the current JOSE specs and = implementations are the result. I realize that not all the JOSE = participants were part of those discussions from the beginning (although = many were) and so teasing out the rationale for specific decisions might = help people better understand the choices made, and hopefully thereby = increase consensus behind the eventual working group choices. >>>>>=20 >>>>> If the list that you're puzzled by is the bulleted list below, = maybe we can start a discussion on that basis. >>>>>=20 >>>>> Best wishes, >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf=20 >>>>> Of Richard L. Barnes >>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>> To: jose@ietf.org >>>>> Subject: [jose] Fwd: New Version Notification for=20 >>>>> draft-barnes-jose-jsms-00.txt >>>>>=20 >>>>> Dear JOSE WG, >>>>>=20 >>>>> Like Mr. Manger, once I finally got around to doing a thorough = review of the JW* specs, I was kind of puzzled by some of the design = decisions. So I also went through and wrote an alternative format, this = time taking a more of a cue from CMS. A link to the document is below. >>>>>=20 >>>>> Summary of differences: >>>>>=20 >>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>> parameters are represented in JSON. >>>>>=20 >>>>> o JSMS allows for full algorithm agility in key agreement, while = JWE >>>>> only allows ECDH-ES. >>>>>=20 >>>>> o JSMS supports multiple recipients for EncryptedData and >>>>> AuthenticatedData objects via the inclusion of multiple = WrappedKey >>>>> objects. Sending a JWE to multiple recipients requires re- >>>>> encryption of the entire object for each recipient. >>>>>=20 >>>>> o The signature and MAC functions of the JWS object are separated >>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>=20 >>>>> o JSMS parameters are not integrity-protected, as they are in JWE >>>>> and JWS. >>>>>=20 >>>>> o The "typ" and "zip" parameters are not defined in JSMS, but = could >>>>> be added without significant change. >>>>>=20 >>>>> o JSMS requires that recipients MUST ignore unknown header >>>>> parameters, in order to facilitate extensibility. >>>>>=20 >>>>> I've also thrown together an initial JavaScript implementation = (based on NodeJS for some python crypto glue), which is on github: >>>>> >>>>>=20 >>>>> Comments are very welcome. =20 >>>>>=20 >>>>> Thanks, >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> Subject: New Version Notification for = draft-barnes-jose-jsms-00.txt >>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>> To: rbarnes@bbn.com >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been=20 >>>>>> successfully submitted by Richard Barnes and posted to the IETF=20= >>>>>> repository. >>>>>>=20 >>>>>> Filename: draft-barnes-jose-jsms >>>>>> Revision: 00 >>>>>> Title: JavaScript Message Security Format >>>>>> Creation date: 2012-06-15 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 25 >>>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >>>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>=20 >>>>>>=20 >>>>>> Abstract: >>>>>> Many applications require the ability to send cryptographically =20= >>>>>> secured messages. While the IETF has defined a number of formats = for =20 >>>>>> such messages (e.g. CMS) those formats use encodings which are = not =20 >>>>>> easy to use in modern applications. This document describes the =20= >>>>>> JavaScript Message Security format (JSMS), a new cryptographic =20= >>>>>> message format which is based on JavaScript Object Notation = (JSON) =20 >>>>>> and thus is easy for many applications to generate and parse. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 --Apple-Mail=_56A7E968-76B7-4EDB-89B0-BE72324690F0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy MDIyNTcyOFowIwYJKoZIhvcNAQkEMRYEFM1b1FLjWlNBxGb1840VmBx64dUaMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJMqI9yiknL5W9OCtbr6LtPTXeEi4Cb3laWRRK5irOuo7qOQi/b73c31yoDy17GHazu4vUBbom3C ai1Uc8Tk5R2KV4W7x3D3Cu4cXjteb+cGlmQd88MsK7lmgGeDYYcSA7tF1b9BNZePlcptzCzuvEqt RHNhVgzI/tb5kTucOh9lbv6V4XHyYTxkWHM8iftasuXpG8spArFyf/IxPl67dgF3Sf4oRxoLxqUu Ogy9VqBNJcb2FahO47kPPGBvnW+4QB1UVCgvsQuo80r+4/KqgFvaZZKTipEm+Lm7HVUF2gAzoPtS h7X6+5A96DgQqq42vTMooxzL4q+T7Qpbgy3vV1QAAAAAAAA= --Apple-Mail=_56A7E968-76B7-4EDB-89B0-BE72324690F0-- From Michael.Jones@microsoft.com Wed Jun 20 16:08: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 5BAF011E8091 for ; Wed, 20 Jun 2012 16:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.282 X-Spam-Level: X-Spam-Status: No, score=-5.282 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPXdRZNoOhsy for ; Wed, 20 Jun 2012 16:07:53 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 803D921F8594 for ; Wed, 20 Jun 2012 16:07:53 -0700 (PDT) Received: from mail192-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 23:06:28 +0000 Received: from mail192-tx2 (localhost [127.0.0.1]) by mail192-tx2-R.bigfish.com (Postfix) with ESMTP id D46E21002F1; Wed, 20 Jun 2012 23:06:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VS-18(zz98dI9371I936eIc85fh168aJ148cI542M1432I41c5N4015Izz1202hzz1033IL8275eh8275bh8275dhf73b6ila1495iz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail192-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=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail192-tx2 (localhost.localdomain [127.0.0.1]) by mail192-tx2 (MessageSwitch) id 1340233581440450_18312; Wed, 20 Jun 2012 23:06:21 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.239]) by mail192-tx2.bigfish.com (Postfix) with ESMTP id 67A5C320050; Wed, 20 Jun 2012 23:06:21 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 23:06:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Wed, 20 Jun 2012 23:07:14 +0000 From: Mike Jones To: Richard L.Barnes Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: Ac1POW14BDAT7gbjSzmo5e7FyidPFQ== Date: Wed, 20 Jun 2012 23:07:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366560A72TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 23:08:09 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366560A72TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two years ago when the developer community needing a JSON-friendly token fo= rmat was designing the JSON Web Token (JWT), we explicitly asked security e= xperts whether the header parameters should be integrity protected or not. = Among them, Ben Laurie was one of the voices saying that securing them was= the right thing to do. He argued that if the parameters can be protected in a practical manner, th= en they should. Doing so provides an additional hurdle that attackers woul= d have to surmount. For example, if they can try to substitute a weaker au= thentication scheme, then they must figure out how to make it authenticate = correctly despite some plaintext they can't control - the header parameters= . Ben also took the position that paring security protocols down to the least= you can get away with, given attacks you can think of, is not a good desig= n principle. If there is not a strong argument against including a feature= that may make it harder for attackers, then that feature should be include= d. I agree with him. The decision to provide integrity protection for the headers is documented = in the session notes at http://self-issued.info/?p=3D361, which said: * What to sign (envelope.payload or just payload)? Given that the envelope is extensible and therefore may contain security-se= nsitive information, we reached a consensus (with input from Ben Laurie via IM) that the combination envelope.payload must be s= igned. I believe that logic is as sound today as it was then. For all these reasons, I therefore personally stand by the community's deci= sion to provide integrity protection for the headers. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Joh= n Bradley Sent: Wednesday, June 20, 2012 3:57 PM To: Richard L.Barnes Cc: jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt Hi Richard, While for PKCS 1.5 the hash algorithm is baked into the padding and not sus= ceptible to modification with ECDH or RSA-PSS it is not. There are possible hash truncation attacks by shortening SHA256 to SHA224 a= s an example (I know we preclude truncated hashes at the moment). The bad feeling I get around this is that if there is a scenario where the = attacker controls the plaintext to be signed and there is no signer control= led text contributed there are potential bad things that could happen down = the road. This bit us with x509 certs not that long ago (yes with MD5 admittedly) whe= re the attacker could use a certificate extension to include extra data and= cause a pre collided hash to be generated. Having part of the signed data outside the control of an attacker is a good= thing. (having a nonce or message ID in the envelope is possible though n= ot yet required in JWS.) I am still of the opinion that putting the base64 encoded envelope inside t= he hash calculation is a valid way to allow additional attributes. Another structure to hold the attributes adds more complexity, as would sa= ying that they need to be inside the signed object. I think part of this is that as one of the openID Connect authors I look at= this as a necessary security token format, for OAuth and Connect. For that simple processing with one signature is a high priority for adopti= on. >From a general signing/encrypting of documents point of view you legitimate= ly have different priorities. I know it is hard to prove a negative but It is also going to be difficult = for me to go back to security people at google Facebook and other places an= d explain how not integrity protecting the header could be better than inte= grity protecting it. It seems that I would be reduced to arguing that this is no worse than CMS = and that hasn't been proven insecure yet. Allowing a possible attacker to control the hash output, and not integrity = protecting the additional data, seems like something I am bound to regret i= n the future. Regards John B. On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: > Hey John, > > Interesting points, but I don't think they actually apply here. > > With regard to downgrade attacks: > > The attack that RFC 5752 is concerned with is when an attacker strips sig= natures from a signed message, so that the only ones left are ones he can t= amper with. So the integrity protection here is "horizontal"; it goes acro= ss signatures. The integrity protection in JWS/JWE is "vertical" -- it onl= y protects one signer's parameters -- so it is, so to speak, orthogonal. > > > With regard to "brown bag" attacks: > > The root of this attack is ambiguity about what content is *signed* > vs. what content is *used*. If an application doesn't verify that > it's actually using the stuff that's signed, then it can be tricked > into accepting something unsigned. (Cf. > ) > > However, I don't think any of the current proposals have that problem. I= n JWE/JWS, the signed content is right there between the dots, and in JSMS,= it's in the "content" element. The current JSMS draft does allow detached= signatures, but with a "voids your warranty" sticker on it. > > In any case, these attacks have nothing to do with whether the cryptograp= hic parameters are integrity-protected with the content. The example attac= ks in the IBM still work regardless -- the whole point of the attack is tha= t the cryptographic processing is the same, only the (non-crypto) matching = of content is flawed. > > > With regard to "arbitrary attributes": > > We can have that here, too, but you need canonicalization. And base64-en= coding is not not canonicalization -- it just waves its hands over the ques= tion of equivalence. In my opinion, we should keep the cryptographic objec= t simple by disallowing attributes, and push the attributes you would sign = inside of the thing being signed. If people really do want attributes, it = doesn't seem to me like JSON canonicalization is very hard. I can do it in= 19 lines of python: > > > > With regard too "meta-data in the body": > > It seems to me like if we're trying to define a general format for applyi= ng security protections, then we ought to keep out things that aren't stric= tly security relevant. Those things can go in application-specific content= types (e.g., SAML) without polluting the general purpose header. > > > With regard to "defense in depth" and selling this to government agencies= : > > CMS, via S/MIME, is in broad use across multiple federal agencies and lar= ge enterprises. JSMS is essentially a profile of CMS (see Section 7), and = has the same security properties. > > > Cheers, > --Richard > > > > > On Jun 19, 2012, at 5:10 PM, John Bradley wrote: > >> Hi Richard, >> >> Originally we only integrity protected the header for signing. We added= the integrity protection to encryption as part of AEAD, as encryption can = also be used for sender verification. >> >> I understand the argument that it makes things simpler if we don't integ= rity protect the header information. >> >> However xmldsig, provides integrity over those elements to prevent poss= ible downgrade attacks by manipulating the algorithms. >> >> CMS may not typically provide that integrity protection but I think Jim = Schaad and Sean Terner created RFC5752 to address downgrade attacks. >> Given they are on this list they can speak to their view on integrity ov= er the crypto parameters. >> >> I also recall when working on InfoCards there was a Monte Carlo/Brown Ba= g attack that needs to be considered if we move to something more like a de= tached signature. >> >> The other design consideration is that we wanted to be able to sign arbi= trary byte strings not just JSON. You could sign XML if you wanted. >> That prevented us from including meta-data in the body as we didn't want= to touch it. That left us with the header to include additional elements= in. >> Not integrity protecting those elements as well would be a problem. >> >> I am not a CMS expert but I believe it allows for signing of arbitrary a= ttributes not unlike the current JOSE spec. >> >> Especially for something that will be used with JWT security tokens I wi= ll have a hard time making the argument to NIST and others that need to app= rove this format that not integrity protecting the header parameters is app= ropriate defence in depth, for something that might be replacing signed SAM= L assertions in some applications. >> >> I do understand how not integrity protecting the header will make some t= hings easier, however I can't agree that the benefit outweighs the disadvan= tages. >> >> Regards >> John B. >> >> >> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >> >>> Hey Mike, >>> >>> Thanks for having some back-and-forth with me on this. I think this is= a good discussion to have right now. I would like to discuss some high-le= vel points, and then I'll respond inline to your precise points. >>> >>> tl;dr: In order to meet its deliverables, the WG needs to define JSON-b= ased formats for integrity and confidentiality protections. JWE and JWS do= n't fit that requirement, so we should re-consider their adoption and call = for new candidates. >>> >>> Major points: >>> 1. JOSE is JSON >>> 2. JSON does not imply canonicalization 3. Compactness and >>> URL-safeness are still OK, as derivatives >>> >>> Part 1: JOSE is JSON >>> >>> The JOSE WG charter calls out four deliverables, three of which are exp= licitly required to be JSON: >>> -- "JSON-structured integrity protection" >>> -- "JSON-structured encryption" >>> -- "public keys as JSON-structured objects" >>> (The fourth is just a list of algorithms, which should be JSON as >>> well, just as RFC 3370 is ASN.1.) >>> >>> In light of these requirements, JWE and JWS are clearly not suitable >>> candidates to fulfill the working group's milestones. (At least in >>> their current form.) So ISTM that we need to step back and >>> re-evaluate alternatives for the three above milestones, especially >>> the first two. (JWK is not as far off.) >>> >>> As JSON-based mechanisms, though, the "JSON serialization" drafts are p= retty half-hearted. Because JWS and JWE include the cryptographic paramete= rs within the integrity protection, they have to have the headers included = as base64-encoded strings. That obviously adds a lot of complexity to enco= ding and decoding -- for example, you have to keep the encoded header aroun= d even after you've decoded it! -- and just plain more octets. The support= for multiple recipients and multiple signatures is both unweildy (matching= up parallel indices for headers and signatures) and inefficient (multiple = integrity check values in encrypted objects). >>> >>> By contrast, JSMS takes advantage of the cryptographic wisdom that went= into CMS, while making the syntax pure JSON and as simple as possible. Mu= ltiple signatures and multiple recipients are supported with absolute minim= um overhead. So I think it's worth consideration by the working group. >>> >>> >>> Part 2: JSON !=3D> canonicalization >>> >>> I would like to dispel the myth that a JSON-based format requires >>> canonicalization. In JWE/JWS, the JSON header requires >>> "canonicalization" (via base64url encoding) because it's included >>> within the integrity protection. I'm not aware of any reason for >>> including the cryptographic parameters in the integrity check, >>> instead of only integrity-protecting the content itself. Indeed, if >>> there were an attack based on non-integrity-protected cryptographic >>> parameters, it would be a pretty big deal, since neither CMS nor IKE >>> nor provides this protection. (TLS does provide a signature over >>> the algorithms, but only as a way to bind the public key to the >>> session.) >>> >>> Indeed CMS doesn't require canonicalization at all, except for attribut= es that are included in the protected content (signedAttrs / authenticatedA= ttrs), which need to be DER-encoded. In JSMS, we don't allow those paramet= ers, so there is no need for canonicalization at all. All the "canonicaliz= ation" that's needed is to base64url-encode the protected content. In that= regard, JSMS is even simpler than JWE/JWS. >>> >>> >>> Part 3: Compactness and URL-safeness are still OK, as derivatives >>> >>> I have absolutely no objection to defining a compact, URL-safe format. = Indeed, I did so in the JSMS draft, in Section 5. Encoding the example fr= om Section 3.1 of the JWS spec, we get the following JSMS object: >>> >>> { >>> "v":1, >>> "t":"au", >>> "a":"hs256", >>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>> "ki":"rSIilRk8Ego" >>> } >>> >>> If we remove the decorative spaces and base64url-encode, we only use >>> 88 octets more than JWS (267 vs. 179). If we take this a step >>> further and define an explicit compact format for AuthenticatedData, >>> we can emulate JWS by moving the content and MAC fields outside and >>> dot-combining. That avoids double-base64url-encoding, and only >>> takes up 11 more octets than a JWS (190 vs 179). (I've put the code >>> to generate these in the Github project linked earlier.) >>> >>> So it's fine to have a compact, URL-safe format for an objective, but i= t makes *much* more sense to derive that from a full-size, usable, JSON for= mat than the other way around. >>> >>> Responses to specific points inline below. >>> >>> >>>> Fair enough. I'll briefly respond to each in turn. Before doing so, = I'll say that I'm writing in the spirit of trying to increase mutual unders= tanding and consensus, rather than taking the point of view that the status= quo is the only reasonable outcome. >>>> >>>> -- Not being JSON >>>> >>>> This was by design, so that the results are URL-safe. This is require= d, for instance, for them to be used as OAuth Bearer Tokens. At the reques= t of the working group, closely related pure-JSON drafts were also publishe= d. See: >>>> >>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri >>>> alization-01 and >>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser >>>> ialization-01 >>>> >>>> Use them if you prefer if they better suit your use cases. They could= be adopted as working group documents, if there's interest. >>> >>> See above. These are super-clunky, and the need to be the main focus o= f the WG, not an afterthought. >>> >>> >>>> -- Not supporting multiple recipients >>>> >>>> The JSON serialization drafts above do, again, in response to use case= s presented by the working group. >>> >>> >>> See above. Because of the unnecessary inclusion of the header in the i= ntegrity check, this is far less efficient than it should be. >>> >>> >>>> -- Lacking clear distinctions between signing and MAC >>>> >>>> Functionally, these are very similar operations, at least from an impl= ementation perspective, so it's not clear that making a clear distinction w= ould help either developers or adoption in any practical way. They achieve= overlapping, but admittedly sometimes different goals. I believe that dev= elopers can be trusted to use the algorithms that achieve their application= s' goals without making a hard distinction between the two. But I'd be int= erested in hearing your thoughts on why you believe a brighter-line distinc= tion might be useful or necessary. >>> >>> It's important if you want to do MACs with anything other than pre-shar= ed keys. If you want to do anything more advanced, you need to have wrappe= d keys, in which case an object with a MAC starts to look a lot more like a= JWE than a JWS. >>> >>> >>>> -- Lacking clear processing instructions for different key >>>> establishment modalities >>>> >>>> This seems like an area where the existing drafts could be refined to = add descriptions for additional establishment modalities, possibly based up= on your ideas and descriptions, should the working group decide to do so. = What additional modalities do you have use cases for that you believe are n= ot achievable or straightforward with the existing drafts? The existing mo= dalities supported are largely those that existing developers had told us t= hey needed and draw both from the precursor draft-jones-json-web-* document= s and draft-rescorla-jsms. >>>> >>>> Bear in mind that the balance that the current drafts try to strike is= keeping the Mandatory to Implement (MTI) feature footprint small enough th= at developers, including Web developers, are likely to adopt the specs, whi= le still providing enough functionality to make them generally useful. As = in any balance, it's often possible to shift things a bit and still maintai= n the balance, but I'd like people to keep the ubiquitous adoption goal fro= nt-and-center when proposing additional functionality. >>>> >>>> Ubiquitous deployment and usefulness trump theoretical >>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>> that!) >>> >>> I agree that we need to find a reasonable MTI. The current JSMS draft = doesn't really specify which parts are MTI, beyond basic things like base64= url encoding and ignoring unknown fields. >>> >>> My main concern is that JWS and JWE don't really tell me which fields n= eed to be present for which use case. If I'm putting a MAC on a JWS vs. a = signature, do I need "jwk" or "jku" fields to be populated? Whereas in JSM= S, I think these things are much clearer due to the separation of the use c= ases (Signed/Authenticated/Encrypted) and the isolation of signatures and w= rapped keys into sub-objects. >>> >>> >>>> -- Lack of clear typing of objects >>>> >>>> Most JSON documents aren't clearly typed; instead, developers and impl= ementations understand from context what the meaning of each field is. XML= is clearly typed, but developers are voting with their feet by moving to J= SON. >>>> >>>> What practical advantages resulting from overlaying a typing infrastru= cture on JSON do you believe are worth the potential costs of doing so? BT= W, I'm not opposed to having a JSON schema description of the JOSE JSON dat= a structures like JSMS did in http://tools.ietf.org/html/draft-rescorla-jsm= s-00#appendix-A, but I'll remark that this an informative tool, not a norma= tive one. >>> >>> I actualy don't have a hugely urgent requirement here either. It's som= ething that others in the WG had requested, which is trivial to add in JSMS= , but not in JWE/JWS -- again because of the unnecessary integrity protecti= on of the header. >>> >>> >>>> -- Lack of versioning for future extensibility >>>> >>>> An optional version field could be added if the working group >>>> desires, however the last time the working group discussed it, they >>>> decided not to do so. Rather, specs like this effectively become >>>> "versioned" when revised in a way that new fields are added. If >>>> you understand the new fields, you support that new version. (Note >>>> that this is independent of whether there is a version number >>>> field, which according to some participants in the previous >>>> discussion, they regarded as therefore being redundant >>>> information.) >>>> >>>> I'm not religious about not having a version number field, but often "= less is more". >>> >>> Indeed, I'm not religious either. It just seems like a general good id= ea to state this directly as opposed to having parsers divine it based on w= hich fields are present. To quote RFC 5652: >>> " >>> Each of the major data structures includes a version number as the >>> first item in the data structure. The version numbers are intended >>> to avoid ASN.1 decode errors. Some implementations do not check the >>> version number prior to attempting a decode, and if a decode error >>> occurs, then the version number is checked as part of the error >>> handling routine. This is a reasonable approach; it places error >>> processing outside of the fast path. This approach is also >>> forgiving when an incorrect version number is used by the sender. >>> " >>> >>> >>> Best, >>> --Richard >>> >>> >>> >>> >>> >>>> >>>> Best wishes, >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Friday, June 15, 2012 3:00 PM >>>> To: Mike Jones >>>> Cc: jose@ietf.org >>>> Subject: Re: [jose] Fwd: New Version Notification for >>>> draft-barnes-jose-jsms-00.txt >>>> >>>> Ok, so maybe I should have phrased my lead-in differently. IMO, the c= urrent JW* specs are deficient in several ways, e.g.: >>>> -- Not being JSON >>>> -- Not supporting multiple recipients >>>> -- Lacking clear distinctions between signing and MAC >>>> -- Lacking clear processing instructions for different key >>>> establishment modalities >>>> -- Lack of clear typing of objects >>>> -- Lack of versioning for future extensibility >>>> >>>> Looking at the current specs, it didn't seem to me that it would be si= mple to adapt them to address these deficiencies. So I just did a re-write= . If you think they can be addressed within the current framework, please = explain. I just found it simpler to start from whole cloth. >>>> >>>> Cheers, >>>> --Richard >>>> >>>> >>>> >>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> If you're puzzled by specific design decisions in the JOSE documents,= I encourage you to ask about them on the list. The documents have signifi= cant history going back to mid-2010 when convergence discussions started am= ong people with four different JSON signing & encryption proposals. JWT an= d the current JOSE specs and implementations are the result. I realize tha= t not all the JOSE participants were part of those discussions from the beg= inning (although many were) and so teasing out the rationale for specific d= ecisions might help people better understand the choices made, and hopefull= y thereby increase consensus behind the eventual working group choices. >>>>> >>>>> If the list that you're puzzled by is the bulleted list below, maybe = we can start a discussion on that basis. >>>>> >>>>> Best wishes, >>>>> -- Mike >>>>> >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jos= e-bounces@ietf.org] On >>>>> Behalf Of Richard L. Barnes >>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>> To: jose@ietf.org >>>>> Subject: [jose] Fwd: New Version Notification for >>>>> draft-barnes-jose-jsms-00.txt >>>>> >>>>> Dear JOSE WG, >>>>> >>>>> Like Mr. Manger, once I finally got around to doing a thorough review= of the JW* specs, I was kind of puzzled by some of the design decisions. = So I also went through and wrote an alternative format, this time taking a = more of a cue from CMS. A link to the document is below. >>>>> >>>>> Summary of differences: >>>>> >>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>> parameters are represented in JSON. >>>>> >>>>> o JSMS allows for full algorithm agility in key agreement, while JWE >>>>> only allows ECDH-ES. >>>>> >>>>> o JSMS supports multiple recipients for EncryptedData and >>>>> AuthenticatedData objects via the inclusion of multiple WrappedKey >>>>> objects. Sending a JWE to multiple recipients requires re- >>>>> encryption of the entire object for each recipient. >>>>> >>>>> o The signature and MAC functions of the JWS object are separated >>>>> into SignedData and AuthenticatedData JSMS objects. >>>>> >>>>> o JSMS parameters are not integrity-protected, as they are in JWE >>>>> and JWS. >>>>> >>>>> o The "typ" and "zip" parameters are not defined in JSMS, but could >>>>> be added without significant change. >>>>> >>>>> o JSMS requires that recipients MUST ignore unknown header >>>>> parameters, in order to facilitate extensibility. >>>>> >>>>> I've also thrown together an initial JavaScript implementation (based= on NodeJS for some python crypto glue), which is on github: >>>>> >>>>> >>>>> Comments are very welcome. >>>>> >>>>> Thanks, >>>>> --Richard >>>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: internet-drafts@ietf.org >>>>>> Subject: New Version Notification for >>>>>> draft-barnes-jose-jsms-00.txt >>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>> To: rbarnes@bbn.com >>>>>> >>>>>> >>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>>>> successfully submitted by Richard Barnes and posted to the IETF >>>>>> repository. >>>>>> >>>>>> Filename: draft-barnes-jose-jsms >>>>>> Revision: 00 >>>>>> Title: JavaScript Message Security Format >>>>>> Creation date: 2012-06-15 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 25 >>>>>> URL: http://www.ietf.org/internet-drafts/draft-barnes-jo= se-jsms-00.txt >>>>>> Status: http://datatracker.ietf.org/doc/draft-barnes-jose-j= sms >>>>>> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-0= 0 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> Many applications require the ability to send cryptographically >>>>>> secured messages. While the IETF has defined a number of formats >>>>>> for such messages (e.g. CMS) those formats use encodings which >>>>>> are not easy to use in modern applications. This document >>>>>> describes the JavaScript Message Security format (JSMS), a new >>>>>> cryptographic message format which is based on JavaScript Object >>>>>> Notation (JSON) and thus is easy for many applications to generate a= nd parse. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>> >>>>> _______________________________________________ >>>>> 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_4E1F6AAD24975D4BA5B168042967394366560A72TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Two years ago when the developer community needing a= JSON-friendly token format was designing the JSON Web Token (JWT), we expl= icitly asked security experts whether the header parameters should be integ= rity protected or not.  Among them, Ben Laurie was one of the voices saying that securing them was the right t= hing to do.

 

He argued that if the parameters can be protected in= a practical manner, then they should.  Doing so provides an additiona= l hurdle that attackers would have to surmount.  For example, if they = can try to substitute a weaker authentication scheme, then they must figure out how to make it authenticate correctly de= spite some plaintext they can't control – the header parameters.=

 

Ben also took the position that paring security prot= ocols down to the least you can get away with, given attacks you can think = of, is not a good design principle.  If there is not a strong argument= against including a feature that may make it harder for attackers, then that feature should be included.<= /p>

 

I agree with him.

 

The decision to provide integrity protection for the= headers is documented in the session notes at http://self-issued.info/?p=3D3= 61, which said:

 

= ·  What to sign (envelope.payload or just payload)?

Given that the envelope is extensible and t= herefore may contain security-sensitive information, we reached a consensus= (with input from Ben Laurie via IM) that the combinati= on envelope.payload must be signed.

 

I believe that logic is as sound today as it was the= n.

 

For all these reasons, I therefore personally stand = by the community’s decision to provide integrity protection for the h= eaders.

 

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

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

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Joh= n Bradley
Sent: Wednesday, June 20, 2012 3:57 PM
To: Richard L.Barnes
Cc: jose@ietf.org
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt

 

Hi Richard,

 

While for PKCS 1.5 the hash algorithm is baked in= to the padding and not susceptible to modification with ECDH or RSA-PSS it = is not.

There are possible hash truncation attacks by sho= rtening SHA256 to SHA224 as an example (I know we preclude truncated hashes= at the moment).

 

The bad feeling I get around this is that if ther= e is a scenario where the attacker controls the plaintext to be signed and = there is no signer controlled text contributed there are potential bad thin= gs that could happen down the road.

 

This bit us with x509 certs not that long ago (ye= s with MD5 admittedly) where the attacker could use a certificate extension= to include extra data and cause a pre collided hash to be generated.<= /o:p>

Having part of the signed data outside the contro= l of an attacker is a good thing.  (having a nonce or message ID in th= e envelope is possible though not yet required in JWS.)

 

I am still of the opinion that putting the base64= encoded envelope inside the hash calculation is a valid way to allow addit= ional attributes. 

Another structure to hold the attributes adds mor= e complexity,  as would saying that they need to be inside the signed = object.

 

I think part of this is that as one of the openID= Connect authors I look at this as a necessary security token format, for O= Auth and Connect. 

For that simple processing with one signature is = a high priority for adoption.

 

From a general signing/encrypting of documents po= int of view you legitimately have different priorities.

 

I know it is hard to prove a negative but It is a= lso going to be difficult for me to go back to security people at google Fa= cebook and other places and explain how not integrity protecting the header= could be better than integrity protecting it.

 

It seems that I would be reduced to arguing that = this is no worse than CMS and that hasn't been proven insecure yet. &n= bsp;

 

Allowing a possible attacker to control the hash = output, and not integrity protecting the additional data, seems like someth= ing I am bound to regret in the future.

 

Regards

John B.

 

On 2012-06-19, at 7:00 PM, Richard L. Barnes wrot= e:

 

> Hey John,

>

> Interesting points, but I don't think they a= ctually apply here.

>

> With regard to downgrade attacks:

>

> The attack that RFC 5752 is concerned with i= s when an attacker strips signatures from a signed message, so that the onl= y ones left are ones he can tamper with.  So the integrity protection = here is "horizontal"; it goes across signatures.  The integrity protection in JWS/JWE is "vertical" -- it only pro= tects one signer's parameters -- so it is, so to speak, orthogonal.

>

>

> With regard to "brown bag" attacks= :

>

> The root of this attack is ambiguity about w= hat content is *signed*

> vs. what content is *used*.  If an appl= ication doesn't verify that

> it's actually using the stuff that's signed,= then it can be tricked

> into accepting something unsigned. (Cf.

> <http= ://en.wikipedia.org/wiki/Confused_Deputy>)

>

> However, I don't think any of the current pr= oposals have that problem.  In JWE/JWS, the signed content is right th= ere between the dots, and in JSMS, it's in the "content" element.=   The current JSMS draft does allow detached signatures, but with a "voids your warranty" sticker on it.

>

> In any case, these attacks have nothing to d= o with whether the cryptographic parameters are integrity-protected with th= e content.  The example attacks in the IBM still work regardless -- th= e whole point of the attack is that the cryptographic processing is the same, only the (non-crypto) matching of content is flawe= d.

>

>

> With regard to "arbitrary attributes&qu= ot;:

>

> We can have that here, too, but you need can= onicalization.  And base64-encoding is not not canonicalization -- it = just waves its hands over the question of equivalence.  In my opinion,= we should keep the cryptographic object simple by disallowing attributes, and push the attributes you would sign inside o= f the thing being signed.  If people really do want attributes, it doe= sn't seem to me like JSON canonicalization is very hard.  I can do it = in 19 lines of python:

> <http://pastebin.com/= ptUfn0c3>

>

>

> With regard too "meta-data in the body&= quot;:

>

> It seems to me like if we're trying to defin= e a general format for applying security protections, then we ought to keep= out things that aren't strictly security relevant.  Those things can = go in application-specific content types (e.g., SAML) without polluting the general purpose header. 

>

>

> With regard to "defense in depth" = and selling this to government agencies:

>

> CMS, via S/MIME, is in broad use across mult= iple federal agencies and large enterprises.  JSMS is essentially a pr= ofile of CMS (see Section 7), and has the same security properties.

>

>

> Cheers,

> --Richard

>

>

>

>

> On Jun 19, 2012, at 5:10 PM, John Bradley wr= ote:

>

>> Hi Richard,

>>

>> Originally we only integrity protected t= he header for signing.  We added the integrity protection to encryptio= n as part of AEAD, as encryption can also be used for sender verification.<= o:p>

>>

>> I understand the argument that it makes = things simpler if we don't integrity protect the header information.

>>

>> However xmldsig,  provides integrit= y over those elements to prevent possible downgrade attacks by manipulating= the algorithms.   

>>

>> CMS may not typically provide that integ= rity protection but I think Jim Schaad and Sean Terner created RFC5752 to a= ddress downgrade attacks.

>> Given they are on this list they can spe= ak to their view on integrity over the crypto parameters.

>>

>> I also recall when working on InfoCards = there was a Monte Carlo/Brown Bag attack that needs to be considered if we = move to something more like a detached signature.

>>

>> The other design consideration is that w= e wanted to be able to sign arbitrary byte strings not just JSON. &nbs= p; You could sign XML if you wanted.

>> That prevented us from including meta-da= ta in the body as we didn't want to touch it.   That left us with= the header to include additional elements in. 

>> Not integrity protecting those elements = as well would be a problem. 

>>

>> I am not a CMS expert but I believe it a= llows for signing of arbitrary attributes not unlike the current JOSE spec.=

>>

>> Especially for something that will be us= ed with JWT security tokens I will have a hard time making the argument to = NIST and others that need to approve this format that not integrity protect= ing the header parameters is appropriate defence in depth, for something that might be replacing signed SAML assert= ions in some applications.

>>

>> I do understand how not integrity protec= ting the header will make some things easier, however I can't agree that th= e benefit outweighs the disadvantages.

>>

>> Regards

>> John B.

>>

>>

>> On 2012-06-18, at 10:02 PM, Richard L. B= arnes wrote:

>>

>>> Hey Mike,

>>>

>>> Thanks for having some back-and-fort= h with me on this.  I think this is a good discussion to have right no= w.  I would like to discuss some high-level points, and then I'll resp= ond inline to your precise points.

>>>

>>> tl;dr: In order to meet its delivera= bles, the WG needs to define JSON-based formats for integrity and confident= iality protections.  JWE and JWS don't fit that requirement, so we sho= uld re-consider their adoption and call for new candidates.

>>>

>>> Major points:

>>> 1. JOSE is JSON

>>> 2. JSON does not imply canonicalizat= ion 3. Compactness and

>>> URL-safeness are still OK, as deriva= tives

>>>

>>> Part 1: JOSE is JSON

>>>

>>> The JOSE WG charter calls out four d= eliverables, three of which are explicitly required to be JSON:<= /p>

>>> -- "JSON-structured integrity p= rotection"

>>> -- "JSON-structured encryption&= quot;

>>> -- "public keys as JSON-structu= red objects"

>>> (The fourth is just a list of algori= thms, which should be JSON as

>>> well, just as RFC 3370 is ASN.1.)

>>>

>>> In light of these requirements, JWE = and JWS are clearly not suitable

>>> candidates to fulfill the working gr= oup's milestones.  (At least in

>>> their current form.)  So ISTM t= hat we need to step back and

>>> re-evaluate alternatives for the thr= ee above milestones, especially

>>> the first two.  (JWK is not as = far off.)

>>>

>>> As JSON-based mechanisms, though, th= e "JSON serialization" drafts are pretty half-hearted.  Beca= use JWS and JWE include the cryptographic parameters within the integrity p= rotection, they have to have the headers included as base64-encoded strings.  That obviously adds a lot of complexity to encoding and dec= oding -- for example, you have to keep the encoded header around even after= you've decoded it! -- and just plain more octets.  The support for mu= ltiple recipients and multiple signatures is both unweildy (matching up parallel indices for headers and signatures)= and inefficient (multiple integrity check values in encrypted objects).

>>>

>>> By contrast, JSMS takes advantage of= the cryptographic wisdom that went into CMS, while making the syntax pure = JSON and as simple as possible.  Multiple signatures and multiple reci= pients are supported with absolute minimum overhead.  So I think it's worth consideration by the working group.

>>>

>>>

>>> Part 2: JSON !=3D> canonicalizati= on

>>>

>>> I would like to dispel the myth that= a JSON-based format requires

>>> canonicalization.  In JWE/JWS, = the JSON header requires

>>> "canonicalization" (via ba= se64url encoding) because it's included

>>> within the integrity protection.&nbs= p; I'm not aware of any reason for

>>> including the cryptographic paramete= rs in the integrity check,

>>> instead of only integrity-protecting= the content itself.  Indeed, if

>>> there were an attack based on non-in= tegrity-protected cryptographic

>>> parameters, it would be a pretty big= deal, since neither CMS nor IKE

>>> nor provides this protection.  = (TLS does provide a signature over

>>> the algorithms, but only as a way to= bind the public key to the

>>> session.)

>>>

>>> Indeed CMS doesn't require canonical= ization at all, except for attributes that are included in the protected co= ntent (signedAttrs / authenticatedAttrs), which need to be DER-encoded.&nbs= p; In JSMS, we don't allow those parameters, so there is no need for canonicalization at all.  All the "canonica= lization" that's needed is to base64url-encode the protected content.&= nbsp; In that regard, JSMS is even simpler than JWE/JWS.

>>>

>>>

>>> Part 3: Compactness and URL-safeness= are still OK, as derivatives

>>>

>>> I have absolutely no objection to de= fining a compact, URL-safe format.  Indeed, I did so in the JSMS draft= , in Section 5.  Encoding the example from Section 3.1 of the JWS spec= , we get the following JSMS object:

>>>

>>> {

>>>   "v":1,

>>>   "t":"au&q= uot;,

>>>   "a":"hs25= 6",

>>>   "c":"eyJp= c3MiOiJqb2...0cnVlfQ",

>>>   "mac":"pw= M0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo",

>>>   "ki":"rSI= ilRk8Ego"

>>> }

>>>

>>> If we remove the decorative spaces a= nd base64url-encode, we only use

>>> 88 octets more than JWS (267 vs. 179= ).  If we take this a step

>>> further and define an explicit compa= ct format for AuthenticatedData,

>>> we can emulate JWS by moving the con= tent and MAC fields outside and

>>> dot-combining.  That avoids dou= ble-base64url-encoding, and only

>>> takes up 11 more octets than a JWS (= 190 vs 179).  (I've put the code

>>> to generate these in the Github proj= ect linked earlier.)

>>>

>>> So it's fine to have a compact, URL-= safe format for an objective, but it makes *much* more sense to derive that= from a full-size, usable, JSON format than the other way around.

>>>

>>> Responses to specific points inline = below.

>>>

>>>

>>>> Fair enough.  I'll briefly = respond to each in turn.  Before doing so, I'll say that I'm writing i= n the spirit of trying to increase mutual understanding and consensus, rath= er than taking the point of view that the status quo is the only reasonable outcome.

>>>>

>>>> -- Not being JSON

>>>>

>>>> This was by design, so that the = results are URL-safe.  This is required, for instance, for them to be = used as OAuth Bearer Tokens.  At the request of the working group, clo= sely related pure-JSON drafts were also published.  See:

>>>>

>>>> http://tools.ietf.org= /html/draft-jones-json-web-signature-json-seri

>>>> alization-01 and

>>>> http://tools.ietf.org= /html/draft-jones-json-web-encryption-json-ser

>>>> ialization-01

>>>>

>>>> Use them if you prefer if they b= etter suit your use cases.  They could be adopted as working group doc= uments, if there's interest.

>>>

>>> See above.  These are super-clu= nky, and the need to be the main focus of the WG, not an afterthought.=

>>>

>>>

>>>> -- Not supporting multiple recip= ients

>>>>

>>>> The JSON serialization drafts ab= ove do, again, in response to use cases presented by the working group.

>>>

>>>

>>> See above.  Because of the unne= cessary inclusion of the header in the integrity check, this is far less ef= ficient than it should be.

>>>

>>>

>>>> -- Lacking clear distinctions be= tween signing and MAC

>>>>

>>>> Functionally, these are very sim= ilar operations, at least from an implementation perspective, so it's not c= lear that making a clear distinction would help either developers or adopti= on in any practical way.  They achieve overlapping, but admittedly sometimes different goals.  I believe that developers = can be trusted to use the algorithms that achieve their applications' goals= without making a hard distinction between the two.  But I'd be intere= sted in hearing your thoughts on why you believe a brighter-line distinction might be useful or necessary.

>>>

>>> It's important if you want to do MAC= s with anything other than pre-shared keys.  If you want to do anythin= g more advanced, you need to have wrapped keys, in which case an object wit= h a MAC starts to look a lot more like a JWE than a JWS.

>>>

>>>

>>>> -- Lacking clear processing inst= ructions for different key

>>>> establishment modalities

>>>>

>>>> This seems like an area where th= e existing drafts could be refined to add descriptions for additional estab= lishment modalities, possibly based upon your ideas and descriptions, shoul= d the working group decide to do so.  What additional modalities do you have use cases for that you believe are not achievable o= r straightforward with the existing drafts?  The existing modalities s= upported are largely those that existing developers had told us they needed= and draw both from the precursor draft-jones-json-web-* documents and draft-rescorla-jsms.

>>>>

>>>> Bear in mind that the balance th= at the current drafts try to strike is keeping the Mandatory to Implement (= MTI) feature footprint small enough that developers, including Web develope= rs, are likely to adopt the specs, while still providing enough functionality to make them generally useful.  As in = any balance, it's often possible to shift things a bit and still maintain t= he balance, but I'd like people to keep the ubiquitous adoption goal front-= and-center when proposing additional functionality.

>>>>

>>>> Ubiquitous deployment and useful= ness trump theoretical

>>>> completeness.  (Just look a= t XMLDSIG and XMLENC to understand

>>>> that!)

>>>

>>> I agree that we need to find a reaso= nable MTI.  The current JSMS draft doesn't really specify which parts = are MTI, beyond basic things like base64url encoding and ignoring unknown f= ields.

>>>

>>> My main concern is that JWS and JWE = don't really tell me which fields need to be present for which use case.&nb= sp; If I'm putting a MAC on a JWS vs. a signature, do I need "jwk"= ; or "jku" fields to be populated?  Whereas in JSMS, I think these things are much clearer due to the separation of the use cases (Sign= ed/Authenticated/Encrypted) and the isolation of signatures and wrapped key= s into sub-objects.

>>>

>>>

>>>> -- Lack of clear typing of objec= ts

>>>>

>>>> Most JSON documents aren't clear= ly typed; instead, developers and implementations understand from context w= hat the meaning of each field is.  XML is clearly typed, but developer= s are voting with their feet by moving to JSON.

>>>>

>>>> What practical advantages result= ing from overlaying a typing infrastructure on JSON do you believe are wort= h the potential costs of doing so?  BTW, I'm not opposed to having a J= SON schema description of the JOSE JSON data structures like JSMS did in http://tools.ietf.org= /html/draft-rescorla-jsms-00#appendix-A, but I'll remark that th= is an informative tool, not a normative one.

>>>

>>> I actualy don't have a hugely urgent= requirement here either.  It's something that others in the WG had re= quested, which is trivial to add in JSMS, but not in JWE/JWS -- again becau= se of the unnecessary integrity protection of the header.

>>>

>>>

>>>> -- Lack of versioning for future= extensibility

>>>>

>>>> An optional version field could = be added if the working group

>>>> desires, however the last time t= he working group discussed it, they

>>>> decided not to do so.  Rath= er, specs like this effectively become

>>>> "versioned" when revis= ed in a way that new fields are added.  If

>>>> you understand the new fields, y= ou support that new version.  (Note

>>>> that this is independent of whet= her there is a version number

>>>> field, which according to some p= articipants in the previous

>>>> discussion, they regarded as the= refore being redundant

>>>> information.)

>>>>

>>>> I'm not religious about not havi= ng a version number field, but often "less is more".

>>>

>>> Indeed, I'm not religious either.&nb= sp; It just seems like a general good idea to state this directly as oppose= d to having parsers divine it based on which fields are present.  To q= uote RFC 5652:

>>> "

>>>  Each of the major data structu= res includes a version number as the 

>>> first item in the data structure.&nb= sp; The version numbers are intended 

>>> to avoid ASN.1 decode errors.  = Some implementations do not check the 

>>> version number prior to attempting a= decode, and if a decode error 

>>> occurs, then the version number is c= hecked as part of the error 

>>> handling routine.  This is a re= asonable approach; it places error 

>>> processing outside of the fast path.=   This approach is also

>>> forgiving  when an incorrect ve= rsion number is used by the sender.

>>> "

>>>

>>>

>>> Best,

>>> --Richard

>>>

>>>

>>>

>>>

>>>

>>>>

>>>>      &n= bsp;            = ;            &n= bsp;            = ;       Best wishes,

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

>>>>

>>>> -----Original Message-----<= /o:p>

>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.c= om]

>>>> Sent: Friday, June 15, 2012 3:00= PM

>>>> To: Mike Jones

>>>> Cc: jose@ietf.org

>>>> Subject: Re: [jose] Fwd: New Ver= sion Notification for

>>>> draft-barnes-jose-jsms-00.txt

>>>>

>>>> Ok, so maybe I should have phras= ed my lead-in differently.  IMO, the current JW* specs are deficient i= n several ways, e.g.:

>>>> -- Not being JSON

>>>> -- Not supporting multiple recip= ients

>>>> -- Lacking clear distinctions be= tween signing and MAC

>>>> -- Lacking clear processing inst= ructions for different key

>>>> establishment modalities

>>>> -- Lack of clear typing of objec= ts

>>>> -- Lack of versioning for future= extensibility

>>>>

>>>> Looking at the current specs, it= didn't seem to me that it would be simple to adapt them to address these d= eficiencies.  So I just did a re-write.  If you think they can be= addressed within the current framework, please explain.  I just found it simpler to start from whole cloth.

>>>>

>>>> Cheers,

>>>> --Richard

>>>>

>>>>

>>>>

>>>> On Jun 15, 2012, at 5:43 PM, Mik= e Jones wrote:

>>>>

>>>>> Hi Richard,

>>>>>

>>>>> If you're puzzled by specifi= c design decisions in the JOSE documents, I encourage you to ask about them= on the list.  The documents have significant history going back to mi= d-2010 when convergence discussions started among people with four different JSON signing & encryption proposals.  JWT and= the current JOSE specs and implementations are the result.  I realize= that not all the JOSE participants were part of those discussions from the= beginning (although many were) and so teasing out the rationale for specific decisions might help people better understa= nd the choices made, and hopefully thereby increase consensus behind the ev= entual working group choices.

>>>>>

>>>>> If the list that you're puzz= led by is the bulleted list below, maybe we can start a discussion on that = basis.

>>>>>

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

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

>>>>>

>>>>> -----Original Message-----

>>>>> From: jo= se-bounces@ietf.org [mailto:jose-bounces@ietf.org] On

>>>>> Behalf Of Richard L. Barnes<= o:p>

>>>>> Sent: Friday, June 15, 2012 = 2:08 PM

>>>>> To: jose@ietf.or= g

>>>>> Subject: [jose] Fwd: New Ver= sion Notification for

>>>>> draft-barnes-jose-jsms-00.tx= t

>>>>>

>>>>> Dear JOSE WG,

>>>>>

>>>>> Like Mr. Manger, once I fina= lly got around to doing a thorough review of the JW* specs, I was kind of p= uzzled by some of the design decisions.  So I also went through and wr= ote an alternative format, this time taking a more of a cue from CMS.  A link to the document is below.

>>>>>

>>>>> Summary of differences:=

>>>>>

>>>>> o  JSMS is pure JSON, w= hereas in JWE and JWS only the header

>>>>>   parameters are r= epresented in JSON.

>>>>>

>>>>> o  JSMS allows for full= algorithm agility in key agreement, while JWE

>>>>>   only allows ECDH= -ES.

>>>>>

>>>>> o  JSMS supports multip= le recipients for EncryptedData and

>>>>>   AuthenticatedDat= a objects via the inclusion of multiple WrappedKey

>>>>>   objects.  S= ending a JWE to multiple recipients requires re-

>>>>>   encryption of th= e entire object for each recipient.

>>>>>

>>>>> o  The signature and MA= C functions of the JWS object are separated

>>>>>   into SignedData = and AuthenticatedData JSMS objects.

>>>>>

>>>>> o  JSMS parameters are = not integrity-protected, as they are in JWE

>>>>>   and JWS.

>>>>>

>>>>> o  The "typ" = and "zip" parameters are not defined in JSMS, but could

>>>>>   be added without= significant change.

>>>>>

>>>>> o  JSMS requires that r= ecipients MUST ignore unknown header

>>>>>   parameters, in o= rder to facilitate extensibility.

>>>>>

>>>>> I've also thrown together an= initial JavaScript implementation (based on NodeJS for some python crypto = glue), which is on github:

>>>>> <https://github.com/bifurcation/jsms>

>>>>>

>>>>> Comments are very welcome.&n= bsp;

>>>>>

>>>>> Thanks,

>>>>> --Richard

>>>>>

>>>>>

>>>>>

>>>>> Begin forwarded message:

>>>>>

>>>>>> From: internet-drafts@ietf.org

>>>>>> Subject: New Version Not= ification for

>>>>>> draft-barnes-jose-jsms-0= 0.txt

>>>>>> Date: June 15, 2012 4:56= :09 PM EDT

>>>>>> To: rbarne= s@bbn.com

>>>>>>

>>>>>>

>>>>>> A new version of I-D, dr= aft-barnes-jose-jsms-00.txt has been

>>>>>> successfully submitted b= y Richard Barnes and posted to the IETF

>>>>>> repository.

>>>>>>

>>>>>> Filename:  &nb= sp;          draft-barnes-jose= -jsms

>>>>>> Revision:  &nb= sp;           00

>>>>>> Title:   =             &nb= sp;     JavaScript Message Security Format

>>>>>> Creation date: &nbs= p;  2012-06-15

>>>>>> WG ID:   =             &nb= sp;  Individual Submission

>>>>>> Number of pages: 25=

>>>>>> URL:   &n= bsp;         http://www.ietf.org/i= nternet-drafts/draft-barnes-jose-jsms-00.txt

>>>>>> Status:   = ;       http://datatracker.ie= tf.org/doc/draft-barnes-jose-jsms

>>>>>> Htmlized:  &nb= sp;     http://tools.ietf.org= /html/draft-barnes-jose-jsms-00

>>>>>>

>>>>>>

>>>>>> Abstract:

>>>>>> Many applications requir= e the ability to send cryptographically

>>>>>> secured messages.  = While the IETF has defined a number of formats

>>>>>> for such messages (e.g.&= nbsp; CMS) those formats use encodings which

>>>>>> are not easy to use in m= odern applications.  This document

>>>>>> describes the JavaScript= Message Security format (JSMS), a new

>>>>>> cryptographic message fo= rmat which is based on JavaScript Object

>>>>>> Notation (JSON) and thus= is easy for many applications to generate and parse.

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>> The IETF Secretariat

>>>>>

>>>>> ____________________________= ___________________

>>>>> 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_4E1F6AAD24975D4BA5B168042967394366560A72TK5EX14MBXC283r_-- From sakimura@gmail.com Thu Jun 21 08:11: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 64E7621F8715 for ; Thu, 21 Jun 2012 08:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gizqp0T0fHHX for ; Thu, 21 Jun 2012 08:11:25 -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 3E48121F8716 for ; Thu, 21 Jun 2012 08:11:24 -0700 (PDT) Received: by bkty8 with SMTP id y8so735383bkt.31 for ; Thu, 21 Jun 2012 08:11: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=cww32FyiucyWRzbBcnl/A+TNAhJ3DiHrKdaWh6at+zo=; b=QsrArx0Lk8QFl7A6tAqOuObvJgmv5/BUlYLz684kKcKx0yHC+lxny2oGqjx2g/9xYP sJcW3q4vuOcqPuEXRFocgB5QIqhLhisjytrinJUZDEmP9/DsbXZnEBTrAlwCXDRaTN7k V57TSg2k9dC/JTXu8UDgczmtXGsP09T+55bjov6EBVYROMgEHtvWUX7AClSjRTL6M21f hPQ6yxX4LazrqKkQ9En5wZoMlQb1IO8luhn4G1ZxI/rQQW2mFlmN4y+ZZgfzqbSdsjTg 2OnR9K8hZppQ204ECMpV3mVSOF3aEISmk1k2+/SDrjE/LP6nhkeuXrGOY9jqeb2jfg/R uNSg== MIME-Version: 1.0 Received: by 10.205.133.13 with SMTP id hw13mr11993912bkc.30.1340291480803; Thu, 21 Jun 2012 08:11:20 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Thu, 21 Jun 2012 08:11:20 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 22 Jun 2012 00:11:20 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=000e0ce0d6729bdbec04c2fced86 Cc: "Richard L.Barnes" , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 15:11:29 -0000 --000e0ce0d6729bdbec04c2fced86 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Especially after the X.509 fiasco, I strongly believe that having integrity check over the metadata is a good thing. It is such a little effort that gives us much more protection down the road. In this sense, I fully agree with Ben here. We should have integrity protection over the header. Nat On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones wr= ote: > Two years ago when the developer community needing a JSON-friendly token > format was designing the JSON Web Token (JWT), we explicitly asked securi= ty > experts whether the header parameters should be integrity protected or > not. Among them, Ben Laurie was one of the voices saying that securing > them was the right thing to do.**** > > ** ** > > He argued that if the parameters can be protected in a practical manner, > then they should. Doing so provides an additional hurdle that attackers > would have to surmount. For example, if they can try to substitute a > weaker authentication scheme, then they must figure out how to make it > authenticate correctly despite some plaintext they can't control =96 the > header parameters.**** > > ** ** > > Ben also took the position that paring security protocols down to the > least you can get away with, given attacks you can think of, is not a goo= d > design principle. If there is not a strong argument against including a > feature that may make it harder for attackers, then that feature should b= e > included.**** > > ** ** > > I agree with him.**** > > ** ** > > The decision to provide integrity protection for the headers is documente= d > in the session notes at http://self-issued.info/?p=3D361, which said:**** > > ** ** > > *=B7** What to sign (envelope.payload or just payload)?***** > > Given that the envelope is extensible and therefore may contain > security-sensitive information, we reached a consensus (with input from B= en > Laurie via IM) that the combination > envelope.payload must be signed.**** > > ** ** > > I believe that logic is as sound today as it was then.**** > > ** ** > > For all these reasons, I therefore personally stand by the community=92s > decision to provide integrity protection for the headers.**** > > ** ** > > Best wishes,*= * > ** > > -- Mike**** > > ** ** > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > John Bradley > Sent: Wednesday, June 20, 2012 3:57 PM > To: Richard L.Barnes > Cc: jose@ietf.org > Subject: Re: [jose] New Version Notification for > draft-barnes-jose-jsms-00.txt > > ** ** > > Hi Richard,**** > > ** ** > > While for PKCS 1.5 the hash algorithm is baked into the padding and not > susceptible to modification with ECDH or RSA-PSS it is not.**** > > There are possible hash truncation attacks by shortening SHA256 to SHA224 > as an example (I know we preclude truncated hashes at the moment).**** > > ** ** > > The bad feeling I get around this is that if there is a scenario where th= e > attacker controls the plaintext to be signed and there is no signer > controlled text contributed there are potential bad things that could > happen down the road.**** > > ** ** > > This bit us with x509 certs not that long ago (yes with MD5 admittedly) > where the attacker could use a certificate extension to include extra dat= a > and cause a pre collided hash to be generated.**** > > Having part of the signed data outside the control of an attacker is a > good thing. (having a nonce or message ID in the envelope is possible > though not yet required in JWS.)**** > > ** ** > > I am still of the opinion that putting the base64 encoded envelope inside > the hash calculation is a valid way to allow additional attributes. **** > > Another structure to hold the attributes adds more complexity, as would > saying that they need to be inside the signed object.**** > > ** ** > > I think part of this is that as one of the openID Connect authors I look > at this as a necessary security token format, for OAuth and Connect. ***= * > > For that simple processing with one signature is a high priority for > adoption.**** > > ** ** > > From a general signing/encrypting of documents point of view you > legitimately have different priorities.**** > > ** ** > > I know it is hard to prove a negative but It is also going to be difficul= t > for me to go back to security people at google Facebook and other places > and explain how not integrity protecting the header could be better than > integrity protecting it.**** > > ** ** > > It seems that I would be reduced to arguing that this is no worse than CM= S > and that hasn't been proven insecure yet. **** > > ** ** > > Allowing a possible attacker to control the hash output, and not integrit= y > protecting the additional data, seems like something I am bound to regret > in the future.**** > > ** ** > > Regards**** > > John B.**** > > ** ** > > On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote:**** > > ** ** > > > Hey John,**** > > > **** > > > Interesting points, but I don't think they actually apply here.**** > > > **** > > > With regard to downgrade attacks: **** > > > **** > > > The attack that RFC 5752 is concerned with is when an attacker strips > signatures from a signed message, so that the only ones left are ones he > can tamper with. So the integrity protection here is "horizontal"; it go= es > across signatures. The integrity protection in JWS/JWE is "vertical" -- = it > only protects one signer's parameters -- so it is, so to speak, orthogona= l. > **** > > > **** > > > **** > > > With regard to "brown bag" attacks:**** > > > **** > > > The root of this attack is ambiguity about what content is *signed* ***= * > > > vs. what content is *used*. If an application doesn't verify that **** > > > it's actually using the stuff that's signed, then it can be tricked ***= * > > > into accepting something unsigned. (Cf. **** > > > )**** > > > **** > > > However, I don't think any of the current proposals have that problem. > In JWE/JWS, the signed content is right there between the dots, and in > JSMS, it's in the "content" element. The current JSMS draft does allow > detached signatures, but with a "voids your warranty" sticker on it.**** > > > **** > > > In any case, these attacks have nothing to do with whether the > cryptographic parameters are integrity-protected with the content. The > example attacks in the IBM still work regardless -- the whole point of th= e > attack is that the cryptographic processing is the same, only the > (non-crypto) matching of content is flawed.**** > > > **** > > > **** > > > With regard to "arbitrary attributes":**** > > > **** > > > We can have that here, too, but you need canonicalization. And > base64-encoding is not not canonicalization -- it just waves its hands ov= er > the question of equivalence. In my opinion, we should keep the > cryptographic object simple by disallowing attributes, and push the > attributes you would sign inside of the thing being signed. If people > really do want attributes, it doesn't seem to me like JSON canonicalizati= on > is very hard. I can do it in 19 lines of python: **** > > > **** > > > **** > > > **** > > > With regard too "meta-data in the body":**** > > > **** > > > It seems to me like if we're trying to define a general format for > applying security protections, then we ought to keep out things that aren= 't > strictly security relevant. Those things can go in application-specific > content types (e.g., SAML) without polluting the general purpose header. > **** > > > **** > > > **** > > > With regard to "defense in depth" and selling this to government > agencies:**** > > > **** > > > CMS, via S/MIME, is in broad use across multiple federal agencies and > large enterprises. JSMS is essentially a profile of CMS (see Section 7), > and has the same security properties.**** > > > **** > > > **** > > > Cheers,**** > > > --Richard**** > > > **** > > > **** > > > **** > > > **** > > > On Jun 19, 2012, at 5:10 PM, John Bradley wrote:**** > > > **** > > >> Hi Richard,**** > > >> **** > > >> Originally we only integrity protected the header for signing. We > added the integrity protection to encryption as part of AEAD, as encrypti= on > can also be used for sender verification.**** > > >> **** > > >> I understand the argument that it makes things simpler if we don't > integrity protect the header information.**** > > >> **** > > >> However xmldsig, provides integrity over those elements to prevent > possible downgrade attacks by manipulating the algorithms. **** > > >> **** > > >> CMS may not typically provide that integrity protection but I think Ji= m > Schaad and Sean Terner created RFC5752 to address downgrade attacks.**** > > >> Given they are on this list they can speak to their view on integrity > over the crypto parameters.**** > > >> **** > > >> I also recall when working on InfoCards there was a Monte Carlo/Brown > Bag attack that needs to be considered if we move to something more like = a > detached signature.**** > > >> **** > > >> The other design consideration is that we wanted to be able to sign > arbitrary byte strings not just JSON. You could sign XML if you wanted. > **** > > >> That prevented us from including meta-data in the body as we didn't > want to touch it. That left us with the header to include additional > elements in. **** > > >> Not integrity protecting those elements as well would be a problem. *= * > ** > > >> **** > > >> I am not a CMS expert but I believe it allows for signing of arbitrary > attributes not unlike the current JOSE spec.**** > > >> **** > > >> Especially for something that will be used with JWT security tokens I > will have a hard time making the argument to NIST and others that need to > approve this format that not integrity protecting the header parameters i= s > appropriate defence in depth, for something that might be replacing signe= d > SAML assertions in some applications.**** > > >> **** > > >> I do understand how not integrity protecting the header will make some > things easier, however I can't agree that the benefit outweighs the > disadvantages.**** > > >> **** > > >> Regards**** > > >> John B.**** > > >> **** > > >> **** > > >> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote:**** > > >> **** > > >>> Hey Mike,**** > > >>> **** > > >>> Thanks for having some back-and-forth with me on this. I think this > is a good discussion to have right now. I would like to discuss some > high-level points, and then I'll respond inline to your precise points.**= * > * > > >>> **** > > >>> tl;dr: In order to meet its deliverables, the WG needs to define > JSON-based formats for integrity and confidentiality protections. JWE an= d > JWS don't fit that requirement, so we should re-consider their adoption a= nd > call for new candidates.**** > > >>> **** > > >>> Major points:**** > > >>> 1. JOSE is JSON**** > > >>> 2. JSON does not imply canonicalization 3. Compactness and **** > > >>> URL-safeness are still OK, as derivatives**** > > >>> **** > > >>> Part 1: JOSE is JSON**** > > >>> **** > > >>> The JOSE WG charter calls out four deliverables, three of which are > explicitly required to be JSON:**** > > >>> -- "JSON-structured integrity protection"**** > > >>> -- "JSON-structured encryption"**** > > >>> -- "public keys as JSON-structured objects"**** > > >>> (The fourth is just a list of algorithms, which should be JSON as ***= * > > >>> well, just as RFC 3370 is ASN.1.)**** > > >>> **** > > >>> In light of these requirements, JWE and JWS are clearly not suitable = * > *** > > >>> candidates to fulfill the working group's milestones. (At least in *= * > ** > > >>> their current form.) So ISTM that we need to step back and **** > > >>> re-evaluate alternatives for the three above milestones, especially *= * > ** > > >>> the first two. (JWK is not as far off.)**** > > >>> **** > > >>> As JSON-based mechanisms, though, the "JSON serialization" drafts are > pretty half-hearted. Because JWS and JWE include the cryptographic > parameters within the integrity protection, they have to have the headers > included as base64-encoded strings. That obviously adds a lot of > complexity to encoding and decoding -- for example, you have to keep the > encoded header around even after you've decoded it! -- and just plain mor= e > octets. The support for multiple recipients and multiple signatures is > both unweildy (matching up parallel indices for headers and signatures) a= nd > inefficient (multiple integrity check values in encrypted objects).**** > > >>> **** > > >>> By contrast, JSMS takes advantage of the cryptographic wisdom that > went into CMS, while making the syntax pure JSON and as simple as > possible. Multiple signatures and multiple recipients are supported with > absolute minimum overhead. So I think it's worth consideration by the > working group.**** > > >>> **** > > >>> **** > > >>> Part 2: JSON !=3D> canonicalization**** > > >>> **** > > >>> I would like to dispel the myth that a JSON-based format requires ***= * > > >>> canonicalization. In JWE/JWS, the JSON header requires **** > > >>> "canonicalization" (via base64url encoding) because it's included ***= * > > >>> within the integrity protection. I'm not aware of any reason for ***= * > > >>> including the cryptographic parameters in the integrity check, **** > > >>> instead of only integrity-protecting the content itself. Indeed, if = * > *** > > >>> there were an attack based on non-integrity-protected cryptographic *= * > ** > > >>> parameters, it would be a pretty big deal, since neither CMS nor IKE = * > *** > > >>> nor provides this protection. (TLS does provide a signature over ***= * > > >>> the algorithms, but only as a way to bind the public key to the **** > > >>> session.)**** > > >>> **** > > >>> Indeed CMS doesn't require canonicalization at all, except for > attributes that are included in the protected content (signedAttrs / > authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't all= ow > those parameters, so there is no need for canonicalization at all. All t= he > "canonicalization" that's needed is to base64url-encode the protected > content. In that regard, JSMS is even simpler than JWE/JWS.**** > > >>> **** > > >>> **** > > >>> Part 3: Compactness and URL-safeness are still OK, as derivatives**** > > >>> **** > > >>> I have absolutely no objection to defining a compact, URL-safe > format. Indeed, I did so in the JSMS draft, in Section 5. Encoding the > example from Section 3.1 of the JWS spec, we get the following JSMS objec= t: > **** > > >>> **** > > >>> { **** > > >>> "v":1,**** > > >>> "t":"au",**** > > >>> "a":"hs256",**** > > >>> "c":"eyJpc3MiOiJqb2...0cnVlfQ",**** > > >>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo",**** > > >>> "ki":"rSIilRk8Ego"**** > > >>> }**** > > >>> **** > > >>> If we remove the decorative spaces and base64url-encode, we only use = * > *** > > >>> 88 octets more than JWS (267 vs. 179). If we take this a step **** > > >>> further and define an explicit compact format for AuthenticatedData, = * > *** > > >>> we can emulate JWS by moving the content and MAC fields outside and *= * > ** > > >>> dot-combining. That avoids double-base64url-encoding, and only **** > > >>> takes up 11 more octets than a JWS (190 vs 179). (I've put the code = * > *** > > >>> to generate these in the Github project linked earlier.)**** > > >>> **** > > >>> So it's fine to have a compact, URL-safe format for an objective, but > it makes *much* more sense to derive that from a full-size, usable, JSON > format than the other way around.**** > > >>> **** > > >>> Responses to specific points inline below.**** > > >>> **** > > >>> **** > > >>>> Fair enough. I'll briefly respond to each in turn. Before doing so= , > I'll say that I'm writing in the spirit of trying to increase mutual > understanding and consensus, rather than taking the point of view that th= e > status quo is the only reasonable outcome.**** > > >>>> **** > > >>>> -- Not being JSON**** > > >>>> **** > > >>>> This was by design, so that the results are URL-safe. This is > required, for instance, for them to be used as OAuth Bearer Tokens. At t= he > request of the working group, closely related pure-JSON drafts were also > published. See:**** > > >>>> **** > > >>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri*= * > ** > > >>>> alization-01 and**** > > >>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser*= * > ** > > >>>> ialization-01**** > > >>>> **** > > >>>> Use them if you prefer if they better suit your use cases. They > could be adopted as working group documents, if there's interest.**** > > >>> **** > > >>> See above. These are super-clunky, and the need to be the main focus > of the WG, not an afterthought.**** > > >>> **** > > >>> **** > > >>>> -- Not supporting multiple recipients**** > > >>>> **** > > >>>> The JSON serialization drafts above do, again, in response to use > cases presented by the working group.**** > > >>> **** > > >>> **** > > >>> See above. Because of the unnecessary inclusion of the header in the > integrity check, this is far less efficient than it should be.**** > > >>> **** > > >>> **** > > >>>> -- Lacking clear distinctions between signing and MAC**** > > >>>> **** > > >>>> Functionally, these are very similar operations, at least from an > implementation perspective, so it's not clear that making a clear > distinction would help either developers or adoption in any practical way= . > They achieve overlapping, but admittedly sometimes different goals. I > believe that developers can be trusted to use the algorithms that achieve > their applications' goals without making a hard distinction between the > two. But I'd be interested in hearing your thoughts on why you believe a > brighter-line distinction might be useful or necessary.**** > > >>> **** > > >>> It's important if you want to do MACs with anything other than > pre-shared keys. If you want to do anything more advanced, you need to > have wrapped keys, in which case an object with a MAC starts to look a lo= t > more like a JWE than a JWS.**** > > >>> **** > > >>> **** > > >>>> -- Lacking clear processing instructions for different key **** > > >>>> establishment modalities**** > > >>>> **** > > >>>> This seems like an area where the existing drafts could be refined t= o > add descriptions for additional establishment modalities, possibly based > upon your ideas and descriptions, should the working group decide to do > so. What additional modalities do you have use cases for that you believ= e > are not achievable or straightforward with the existing drafts? The > existing modalities supported are largely those that existing developers > had told us they needed and draw both from the precursor > draft-jones-json-web-* documents and draft-rescorla-jsms.**** > > >>>> **** > > >>>> Bear in mind that the balance that the current drafts try to strike > is keeping the Mandatory to Implement (MTI) feature footprint small enoug= h > that developers, including Web developers, are likely to adopt the specs, > while still providing enough functionality to make them generally useful. > As in any balance, it's often possible to shift things a bit and still > maintain the balance, but I'd like people to keep the ubiquitous adoption > goal front-and-center when proposing additional functionality.**** > > >>>> **** > > >>>> Ubiquitous deployment and usefulness trump theoretical **** > > >>>> completeness. (Just look at XMLDSIG and XMLENC to understand **** > > >>>> that!)**** > > >>> **** > > >>> I agree that we need to find a reasonable MTI. The current JSMS draf= t > doesn't really specify which parts are MTI, beyond basic things like > base64url encoding and ignoring unknown fields.**** > > >>> **** > > >>> My main concern is that JWS and JWE don't really tell me which fields > need to be present for which use case. If I'm putting a MAC on a JWS vs.= a > signature, do I need "jwk" or "jku" fields to be populated? Whereas in > JSMS, I think these things are much clearer due to the separation of the > use cases (Signed/Authenticated/Encrypted) and the isolation of signature= s > and wrapped keys into sub-objects.**** > > >>> **** > > >>> **** > > >>>> -- Lack of clear typing of objects**** > > >>>> **** > > >>>> Most JSON documents aren't clearly typed; instead, developers and > implementations understand from context what the meaning of each field is= . > XML is clearly typed, but developers are voting with their feet by moving > to JSON.**** > > >>>> **** > > >>>> What practical advantages resulting from overlaying a typing > infrastructure on JSON do you believe are worth the potential costs of > doing so? BTW, I'm not opposed to having a JSON schema description of th= e > JOSE JSON data structures like JSMS did in > http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll > remark that this an informative tool, not a normative one.**** > > >>> **** > > >>> I actualy don't have a hugely urgent requirement here either. It's > something that others in the WG had requested, which is trivial to add in > JSMS, but not in JWE/JWS -- again because of the unnecessary integrity > protection of the header.**** > > >>> **** > > >>> **** > > >>>> -- Lack of versioning for future extensibility**** > > >>>> **** > > >>>> An optional version field could be added if the working group **** > > >>>> desires, however the last time the working group discussed it, they = * > *** > > >>>> decided not to do so. Rather, specs like this effectively become **= * > * > > >>>> "versioned" when revised in a way that new fields are added. If ***= * > > >>>> you understand the new fields, you support that new version. (Note = * > *** > > >>>> that this is independent of whether there is a version number **** > > >>>> field, which according to some participants in the previous **** > > >>>> discussion, they regarded as therefore being redundant **** > > >>>> information.)**** > > >>>> **** > > >>>> I'm not religious about not having a version number field, but often > "less is more".**** > > >>> **** > > >>> Indeed, I'm not religious either. It just seems like a general good > idea to state this directly as opposed to having parsers divine it based = on > which fields are present. To quote RFC 5652:**** > > >>> "**** > > >>> Each of the major data structures includes a version number as the = * > *** > > >>> first item in the data structure. The version numbers are intended = * > *** > > >>> to avoid ASN.1 decode errors. Some implementations do not check the > **** > > >>> version number prior to attempting a decode, and if a decode error *= * > ** > > >>> occurs, then the version number is checked as part of the error **** > > >>> handling routine. This is a reasonable approach; it places error **= * > * > > >>> processing outside of the fast path. This approach is also **** > > >>> forgiving when an incorrect version number is used by the sender.***= * > > >>> "**** > > >>> **** > > >>> **** > > >>> Best,**** > > >>> --Richard**** > > >>> **** > > >>> **** > > >>> **** > > >>> **** > > >>> **** > > >>>> **** > > >>>> Best wishes,**** > > >>>> -- Mike**** > > >>>> **** > > >>>> -----Original Message-----**** > > >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]**** > > >>>> Sent: Friday, June 15, 2012 3:00 PM**** > > >>>> To: Mike Jones**** > > >>>> Cc: jose@ietf.org**** > > >>>> Subject: Re: [jose] Fwd: New Version Notification for **** > > >>>> draft-barnes-jose-jsms-00.txt**** > > >>>> **** > > >>>> Ok, so maybe I should have phrased my lead-in differently. IMO, the > current JW* specs are deficient in several ways, e.g.:**** > > >>>> -- Not being JSON**** > > >>>> -- Not supporting multiple recipients**** > > >>>> -- Lacking clear distinctions between signing and MAC**** > > >>>> -- Lacking clear processing instructions for different key **** > > >>>> establishment modalities**** > > >>>> -- Lack of clear typing of objects**** > > >>>> -- Lack of versioning for future extensibility**** > > >>>> **** > > >>>> Looking at the current specs, it didn't seem to me that it would be > simple to adapt them to address these deficiencies. So I just did a > re-write. If you think they can be addressed within the current framewor= k, > please explain. I just found it simpler to start from whole cloth.**** > > >>>> **** > > >>>> Cheers,**** > > >>>> --Richard**** > > >>>> **** > > >>>> **** > > >>>> **** > > >>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote:**** > > >>>> **** > > >>>>> Hi Richard,**** > > >>>>> **** > > >>>>> If you're puzzled by specific design decisions in the JOSE > documents, I encourage you to ask about them on the list. The documents > have significant history going back to mid-2010 when convergence > discussions started among people with four different JSON signing & > encryption proposals. JWT and the current JOSE specs and implementations > are the result. I realize that not all the JOSE participants were part o= f > those discussions from the beginning (although many were) and so teasing > out the rationale for specific decisions might help people better > understand the choices made, and hopefully thereby increase consensus > behind the eventual working group choices.**** > > >>>>> **** > > >>>>> If the list that you're puzzled by is the bulleted list below, mayb= e > we can start a discussion on that basis.**** > > >>>>> **** > > >>>>> Best wishes,**** > > >>>>> -- Mike**** > > >>>>> **** > > >>>>> -----Original Message-----**** > > >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On **** > > >>>>> Behalf Of Richard L. Barnes**** > > >>>>> Sent: Friday, June 15, 2012 2:08 PM**** > > >>>>> To: jose@ietf.org**** > > >>>>> Subject: [jose] Fwd: New Version Notification for ** ** > > >>>>> draft-barnes-jose-jsms-00.txt**** > > >>>>> **** > > >>>>> Dear JOSE WG,**** > > >>>>> **** > > >>>>> Like Mr. Manger, once I finally got around to doing a thorough > review of the JW* specs, I was kind of puzzled by some of the design > decisions. So I also went through and wrote an alternative format, this > time taking a more of a cue from CMS. A link to the document is below.**= * > * > > >>>>> **** > > >>>>> Summary of differences:**** > > >>>>> **** > > >>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header**** > > >>>>> parameters are represented in JSON.**** > > >>>>> **** > > >>>>> o JSMS allows for full algorithm agility in key agreement, while J= WE > **** > > >>>>> only allows ECDH-ES.**** > > >>>>> **** > > >>>>> o JSMS supports multiple recipients for EncryptedData and**** > > >>>>> AuthenticatedData objects via the inclusion of multiple WrappedKe= y > **** > > >>>>> objects. Sending a JWE to multiple recipients requires re-**** > > >>>>> encryption of the entire object for each recipient.**** > > >>>>> **** > > >>>>> o The signature and MAC functions of the JWS object are separated*= * > ** > > >>>>> into SignedData and AuthenticatedData JSMS objects.**** > > >>>>> **** > > >>>>> o JSMS parameters are not integrity-protected, as they are in JWE*= * > ** > > >>>>> and JWS.**** > > >>>>> **** > > >>>>> o The "typ" and "zip" parameters are not defined in JSMS, but coul= d > **** > > >>>>> be added without significant change.**** > > >>>>> **** > > >>>>> o JSMS requires that recipients MUST ignore unknown header**** > > >>>>> parameters, in order to facilitate extensibility.**** > > >>>>> **** > > >>>>> I've also thrown together an initial JavaScript implementation > (based on NodeJS for some python crypto glue), which is on github:**** > > >>>>> **** > > >>>>> **** > > >>>>> Comments are very welcome. **** > > >>>>> **** > > >>>>> Thanks,**** > > >>>>> --Richard**** > > >>>>> **** > > >>>>> **** > > >>>>> **** > > >>>>> Begin forwarded message:**** > > >>>>> **** > > >>>>>> From: internet-drafts@ietf.org**** > > >>>>>> Subject: New Version Notification for **** > > >>>>>> draft-barnes-jose-jsms-00.txt**** > > >>>>>> Date: June 15, 2012 4:56:09 PM EDT**** > > >>>>>> To: rbarnes@bbn.com**** > > >>>>>> **** > > >>>>>> **** > > >>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been **** > > >>>>>> successfully submitted by Richard Barnes and posted to the IETF **= * > * > > >>>>>> repository.**** > > >>>>>> **** > > >>>>>> Filename: draft-barnes-jose-jsms**** > > >>>>>> Revision: 00**** > > >>>>>> Title: JavaScript Message Security Format**** > > >>>>>> Creation date: 2012-06-15**** > > >>>>>> WG ID: Individual Submission**** > > >>>>>> Number of pages: 25**** > > >>>>>> URL: > http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt**** > > >>>>>> Status: > http://datatracker.ietf.org/doc/draft-barnes-jose-jsms**** > > >>>>>> Htmlized: > http://tools.ietf.org/html/draft-barnes-jose-jsms-00**** > > >>>>>> **** > > >>>>>> **** > > >>>>>> Abstract:**** > > >>>>>> Many applications require the ability to send cryptographically **= * > * > > >>>>>> secured messages. While the IETF has defined a number of formats = * > *** > > >>>>>> for such messages (e.g. CMS) those formats use encodings which **= * > * > > >>>>>> are not easy to use in modern applications. This document **** > > >>>>>> describes the JavaScript Message Security format (JSMS), a new ***= * > > >>>>>> cryptographic message format which is based on JavaScript Object *= * > ** > > >>>>>> Notation (JSON) and thus is easy for many applications to generate > and parse.**** > > >>>>>> **** > > >>>>>> **** > > >>>>>> **** > > >>>>>> **** > > >>>>>> The IETF Secretariat**** > > >>>>> **** > > >>>>> _______________________________________________**** > > >>>>> jose mailing list**** > > >>>>> jose@ietf.org**** > > >>>>> https://www.ietf.org/mailman/listinfo/jose**** > > >>>>> **** > > >>>>> **** > > >>>>> _______________________________________________**** > > >>>>> jose mailing list**** > > >>>>> jose@ietf.org**** > > >>>>> https://www.ietf.org/mailman/listinfo/jose**** > > >>>> **** > > >>>> **** > > >>>> **** > > >>>> _______________________________________________**** > > >>>> jose mailing list**** > > >>>> jose@ietf.org**** > > >>>> https://www.ietf.org/mailman/listinfo/jose**** > > >>> **** > > >>> _______________________________________________**** > > >>> jose mailing list**** > > >>> jose@ietf.org**** > > >>> https://www.ietf.org/mailman/listinfo/jose**** > > >> **** > > > **** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000e0ce0d6729bdbec04c2fced86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Especially after the X.509 fiasco, I strongly believe that having integrity= check over the metadata is a good thing. It is such a little effort that g= ives us much more protection down the road. In this sense, I fully agree wi= th Ben here. We should have integrity protection over the header.=A0

Nat

On Thu, Jun 21, 2012 a= t 8:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Two years ago when the developer community needing a= JSON-friendly token format was designing the JSON Web Token (JWT), we expl= icitly asked security experts whether the header parameters should be integ= rity protected or not.=A0 Among them, Ben Laurie was one of the voices saying that securing them was the right t= hing to do.

=A0

He argued that if the parameters can be protected in= a practical manner, then they should.=A0 Doing so provides an additional h= urdle that attackers would have to surmount.=A0 For example, if they can tr= y to substitute a weaker authentication scheme, then they must figure out how to make it authenticate correctly de= spite some plaintext they can't control =96 the header parameters.

=A0

Ben also took the position that paring security prot= ocols down to the least you can get away with, given attacks you can think = of, is not a good design principle.=A0 If there is not a strong argument ag= ainst including a feature that may make it harder for attackers, then that feature should be included.

=A0

I agree with him.

=A0

The decision to provide integrity protection for the= headers is documented in the session notes at http://self-= issued.info/?p=3D361, which said:

=A0

= =B7=A0 What to sign (envelope.payload or just payload)?

Given that the envelope is extensible and t= herefore may contain security-sensitive information, we reached a consensus= (with input from Ben Laurie via IM) = that the combination envelope.payload must be signed.<= /p>

=A0

I believe that logic is as sound today as it was the= n.

=A0

For all these reasons, I therefore personally stand = by the community=92s decision to provide integrity protection for the heade= rs.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Best wishes,<= /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 -- Mike

=A0

-----Original Message-----
From: jose-bounc= es@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, June 20, 2012 3:57 PM
To: Richard L.Barnes
Cc: jose@ietf.org
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt

=A0

Hi Richard,

=A0

While for PKCS 1.5 the hash algorithm is baked into the padding and not = susceptible to modification with ECDH or RSA-PSS it is not.

There are possible hash truncation attacks by shortening SHA256 to SHA22= 4 as an example (I know we preclude truncated hashes at the moment).=

=A0

The bad feeling I get around this is that if there is a scenario where t= he attacker controls the plaintext to be signed and there is no signer cont= rolled text contributed there are potential bad things that could happen do= wn the road.

=A0

This bit us with x509 certs not that long ago (yes with MD5 admittedly) = where the attacker could use a certificate extension to include extra data = and cause a pre collided hash to be generated.

Having part of the signed data outside the control of an attacker is a g= ood thing.=A0 (having a nonce or message ID in the envelope is possible tho= ugh not yet required in JWS.)

=A0

I am still of the opinion that putting the base64 encoded envelope insid= e the hash calculation is a valid way to allow additional attributes.=A0

Another structure to hold the attributes adds more complexity,=A0 as wou= ld saying that they need to be inside the signed object.

=A0

I think part of this is that as one of the openID Connect authors I look= at this as a necessary security token format, for OAuth and Connect.=A0

For that simple processing with one signature is a high priority for ado= ption.

=A0

From a general signing/encrypting of documents point of view you legitim= ately have different priorities.

=A0

I know it is hard to prove a negative but It is also going to be difficu= lt for me to go back to security people at google Facebook and other places= and explain how not integrity protecting the header could be better than i= ntegrity protecting it.

=A0

It seems that I would be reduced to arguing that this is no worse than C= MS and that hasn't been proven insecure yet.=A0=A0

=A0

Allowing a possible attacker to control the hash output, and not integri= ty protecting the additional data, seems like something I am bound to regre= t in the future.

=A0

Regards

John B.

=A0

On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote:

=A0

> Hey John,

>

> Interesting points, but I don't think they actually apply here.=

>

> With regard to downgrade attacks:

>

> The attack that RFC 5752 is concerned with is when an attacker stri= ps signatures from a signed message, so that the only ones left are ones he= can tamper with.=A0 So the integrity protection here is "horizontal&q= uot;; it goes across signatures.=A0 The integrity protection in JWS/JWE is "vertical" -- it only pro= tects one signer's parameters -- so it is, so to speak, orthogonal.<= /u>

>

>

> With regard to "brown bag" attacks:

>

> The root of this attack is ambiguity about what content is *signed*

> vs. what content is *used*.=A0 If an application doesn't verify= that

> it's actually using the stuff that's signed, then it can be= tricked

> into accepting something unsigned. (Cf.

> <http://en= .wikipedia.org/wiki/Confused_Deputy>)

>

> However, I don't think any of the current proposals have that p= roblem.=A0 In JWE/JWS, the signed content is right there between the dots, = and in JSMS, it's in the "content" element.=A0 The current JS= MS draft does allow detached signatures, but with a "voids your warranty" sticker on it.

>

> In any case, these attacks have nothing to do with whether the cryp= tographic parameters are integrity-protected with the content.=A0 The examp= le attacks in the IBM still work regardless -- the whole point of the attac= k is that the cryptographic processing is the same, only the (non-crypto) matching of content is flawe= d.

>

>

> With regard to "arbitrary attributes":

>

> We can have that here, too, but you need canonicalization.=A0 And b= ase64-encoding is not not canonicalization -- it just waves its hands over = the question of equivalence.=A0 In my opinion, we should keep the cryptogra= phic object simple by disallowing attributes, and push the attributes you would sign inside o= f the thing being signed.=A0 If people really do want attributes, it doesn&= #39;t seem to me like JSON canonicalization is very hard.=A0 I can do it in= 19 lines of python:

> <http://pastebin.com/ptUfn= 0c3>

>

>

> With regard too "meta-data in the body":

>

> It seems to me like if we're trying to define a general format = for applying security protections, then we ought to keep out things that ar= en't strictly security relevant.=A0 Those things can go in application-= specific content types (e.g., SAML) without polluting the general purpose header.=A0

>

>

> With regard to "defense in depth" and selling this to gov= ernment agencies:

>

> CMS, via S/MIME, is in broad use across multiple federal agencies a= nd large enterprises.=A0 JSMS is essentially a profile of CMS (see Section = 7), and has the same security properties.

>

>

> Cheers,

> --Richard

>

>

>

>

> On Jun 19, 2012, at 5:10 PM, John Bradley wrote:

>

>> Hi Richard,

>>

>> Originally we only integrity protected the header for signing.= =A0 We added the integrity protection to encryption as part of AEAD, as enc= ryption can also be used for sender verification.

>>

>> I understand the argument that it makes things simpler if we do= n't integrity protect the header information.

>>

>> However xmldsig,=A0 provides integrity over those elements to p= revent possible downgrade attacks by manipulating the algorithms.=A0 =A0=

>>

>> CMS may not typically provide that integrity protection but I t= hink Jim Schaad and Sean Terner created RFC5752 to address downgrade attack= s.

>> Given they are on this list they can speak to their view on int= egrity over the crypto parameters.

>>

>> I also recall when working on InfoCards there was a Monte Carlo= /Brown Bag attack that needs to be considered if we move to something more = like a detached signature.

>>

>> The other design consideration is that we wanted to be able to = sign arbitrary byte strings not just JSON.=A0=A0 You could sign XML if you = wanted.

>> That prevented us from including meta-data in the body as we di= dn't want to touch it.=A0=A0 That left us with the header to include ad= ditional elements in.=A0

>> Not integrity protecting those elements as well would be a prob= lem.=A0

>>

>> I am not a CMS expert but I believe it allows for signing of ar= bitrary attributes not unlike the current JOSE spec.

>>

>> Especially for something that will be used with JWT security to= kens I will have a hard time making the argument to NIST and others that ne= ed to approve this format that not integrity protecting the header paramete= rs is appropriate defence in depth, for something that might be replacing signed SAML assert= ions in some applications.

>>

>> I do understand how not integrity protecting the header will ma= ke some things easier, however I can't agree that the benefit outweighs= the disadvantages.

>>

>> Regards

>> John B.

>>

>>

>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote:<= /u>

>>

>>> Hey Mike,

>>>

>>> Thanks for having some back-and-forth with me on this.=A0 I= think this is a good discussion to have right now.=A0 I would like to disc= uss some high-level points, and then I'll respond inline to your precis= e points.

>>>

>>> tl;dr: In order to meet its deliverables, the WG needs to d= efine JSON-based formats for integrity and confidentiality protections.=A0 = JWE and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates.

>>>

>>> Major points:

>>> 1. JOSE is JSON

>>> 2. JSON does not imply canonicalization 3. Compactness and

>>> URL-safeness are still OK, as derivatives

>>>

>>> Part 1: JOSE is JSON

>>>

>>> The JOSE WG charter calls out four deliverables, three of w= hich are explicitly required to be JSON:

>>> -- "JSON-structured integrity protection"<= u>

>>> -- "JSON-structured encryption"

>>> -- "public keys as JSON-structured objects"

>>> (The fourth is just a list of algorithms, which should be J= SON as

>>> well, just as RFC 3370 is ASN.1.)

>>>

>>> In light of these requirements, JWE and JWS are clearly not= suitable

>>> candidates to fulfill the working group's milestones.= =A0 (At least in

>>> their current form.)=A0 So ISTM that we need to step back a= nd

>>> re-evaluate alternatives for the three above milestones, es= pecially

>>> the first two.=A0 (JWK is not as far off.)

>>>

>>> As JSON-based mechanisms, though, the "JSON serializat= ion" drafts are pretty half-hearted.=A0 Because JWS and JWE include th= e cryptographic parameters within the integrity protection, they have to ha= ve the headers included as base64-encoded strings.=A0 That obviously adds a lot of complexity to encoding and decodi= ng -- for example, you have to keep the encoded header around even after yo= u've decoded it! -- and just plain more octets.=A0 The support for mult= iple recipients and multiple signatures is both unweildy (matching up parallel indices for headers and signatures)= and inefficient (multiple integrity check values in encrypted objects).=

>>>

>>> By contrast, JSMS takes advantage of the cryptographic wisd= om that went into CMS, while making the syntax pure JSON and as simple as p= ossible.=A0 Multiple signatures and multiple recipients are supported with = absolute minimum overhead.=A0 So I think it's worth consideration by the working group.

>>>

>>>

>>> Part 2: JSON !=3D> canonicalization

>>>

>>> I would like to dispel the myth that a JSON-based format re= quires

>>> canonicalization.=A0 In JWE/JWS, the JSON header requires

>>> "canonicalization" (via base64url encoding) becau= se it's included

>>> within the integrity protection.=A0 I'm not aware of an= y reason for

>>> including the cryptographic parameters in the integrity che= ck,

>>> instead of only integrity-protecting the content itself.=A0= Indeed, if

>>> there were an attack based on non-integrity-protected crypt= ographic

>>> parameters, it would be a pretty big deal, since neither CM= S nor IKE

>>> nor provides this protection.=A0 (TLS does provide a signat= ure over

>>> the algorithms, but only as a way to bind the public key to= the

>>> session.)

>>>

>>> Indeed CMS doesn't require canonicalization at all, exc= ept for attributes that are included in the protected content (signedAttrs = / authenticatedAttrs), which need to be DER-encoded.=A0 In JSMS, we don'= ;t allow those parameters, so there is no need for canonicalization at all.=A0 All the "canonicaliz= ation" that's needed is to base64url-encode the protected content.= =A0 In that regard, JSMS is even simpler than JWE/JWS.

>>>

>>>

>>> Part 3: Compactness and URL-safeness are still OK, as deriv= atives

>>>

>>> I have absolutely no objection to defining a compact, URL-s= afe format.=A0 Indeed, I did so in the JSMS draft, in Section 5.=A0 Encodin= g the example from Section 3.1 of the JWS spec, we get the following JSMS o= bject:

>>>

>>> {

>>>=A0=A0 "v":1,

>>>=A0=A0 "t":"au",

>>>=A0=A0 "a":"hs256",

>>>=A0=A0 "c":"eyJpc3MiOiJqb2...0cnVlfQ",

>>>=A0=A0 "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_F= eKIH3wIM_OAo",

>>>=A0=A0 "ki":"rSIilRk8Ego"<= /p>

>>> }

>>>

>>> If we remove the decorative spaces and base64url-encode, we= only use

>>> 88 octets more than JWS (267 vs. 179).=A0 If we take this a= step

>>> further and define an explicit compact format for Authentic= atedData,

>>> we can emulate JWS by moving the content and MAC fields out= side and

>>> dot-combining.=A0 That avoids double-base64url-encoding, an= d only

>>> takes up 11 more octets than a JWS (190 vs 179).=A0 (I'= ve put the code

>>> to generate these in the Github project linked earlier.)=

>>>

>>> So it's fine to have a compact, URL-safe format for an = objective, but it makes *much* more sense to derive that from a full-size, = usable, JSON format than the other way around.

>>>

>>> Responses to specific points inline below.

>>>

>>>

>>>> Fair enough.=A0 I'll briefly respond to each in tur= n.=A0 Before doing so, I'll say that I'm writing in the spirit of t= rying to increase mutual understanding and consensus, rather than taking th= e point of view that the status quo is the only reasonable outcome.

>>>>

>>>> -- Not being JSON

>>>>

>>>> This was by design, so that the results are URL-safe.= =A0 This is required, for instance, for them to be used as OAuth Bearer Tok= ens.=A0 At the request of the working group, closely related pure-JSON draf= ts were also published.=A0 See:

>>>>

>>>> http://tools.ietf.org= /html/draft-jones-json-web-signature-json-seri

>>>> alization-01 and

>>>> http://tools.ietf.org= /html/draft-jones-json-web-encryption-json-ser

>>>> ialization-01

>>>>

>>>> Use them if you prefer if they better suit your use cas= es.=A0 They could be adopted as working group documents, if there's int= erest.

>>>

>>> See above.=A0 These are super-clunky, and the need to be th= e main focus of the WG, not an afterthought.

>>>

>>>

>>>> -- Not supporting multiple recipients

>>>>

>>>> The JSON serialization drafts above do, again, in respo= nse to use cases presented by the working group.

>>>

>>>

>>> See above.=A0 Because of the unnecessary inclusion of the h= eader in the integrity check, this is far less efficient than it should be.=

>>>

>>>

>>>> -- Lacking clear distinctions between signing and MAC

>>>>

>>>> Functionally, these are very similar operations, at lea= st from an implementation perspective, so it's not clear that making a = clear distinction would help either developers or adoption in any practical= way.=A0 They achieve overlapping, but admittedly sometimes different goals.=A0 I believe that developers can= be trusted to use the algorithms that achieve their applications' goal= s without making a hard distinction between the two.=A0 But I'd be inte= rested in hearing your thoughts on why you believe a brighter-line distinction might be useful or necessary.

>>>

>>> It's important if you want to do MACs with anything oth= er than pre-shared keys.=A0 If you want to do anything more advanced, you n= eed to have wrapped keys, in which case an object with a MAC starts to look= a lot more like a JWE than a JWS.

>>>

>>>

>>>> -- Lacking clear processing instructions for different = key

>>>> establishment modalities

>>>>

>>>> This seems like an area where the existing drafts could= be refined to add descriptions for additional establishment modalities, po= ssibly based upon your ideas and descriptions, should the working group dec= ide to do so.=A0 What additional modalities do you have use cases for that you believe are not achievable o= r straightforward with the existing drafts?=A0 The existing modalities supp= orted are largely those that existing developers had told us they needed an= d draw both from the precursor draft-jones-json-web-* documents and draft-rescorla-jsms.

>>>>

>>>> Bear in mind that the balance that the current drafts t= ry to strike is keeping the Mandatory to Implement (MTI) feature footprint = small enough that developers, including Web developers, are likely to adopt= the specs, while still providing enough functionality to make them generally useful.=A0 As in any= balance, it's often possible to shift things a bit and still maintain = the balance, but I'd like people to keep the ubiquitous adoption goal f= ront-and-center when proposing additional functionality.

>>>>

>>>> Ubiquitous deployment and usefulness trump theoretical

>>>> completeness.=A0 (Just look at XMLDSIG and XMLENC to un= derstand

>>>> that!)

>>>

>>> I agree that we need to find a reasonable MTI.=A0 The curre= nt JSMS draft doesn't really specify which parts are MTI, beyond basic = things like base64url encoding and ignoring unknown fields.

>>>

>>> My main concern is that JWS and JWE don't really tell m= e which fields need to be present for which use case.=A0 If I'm putting= a MAC on a JWS vs. a signature, do I need "jwk" or "jku&quo= t; fields to be populated?=A0 Whereas in JSMS, I think these things are much clearer due to the separation of the use cases (Sign= ed/Authenticated/Encrypted) and the isolation of signatures and wrapped key= s into sub-objects.

>>>

>>>

>>>> -- Lack of clear typing of objects

>>>>

>>>> Most JSON documents aren't clearly typed; instead, = developers and implementations understand from context what the meaning of = each field is.=A0 XML is clearly typed, but developers are voting with thei= r feet by moving to JSON.

>>>>

>>>> What practical advantages resulting from overlaying a t= yping infrastructure on JSON do you believe are worth the potential costs o= f doing so?=A0 BTW, I'm not opposed to having a JSON schema description= of the JOSE JSON data structures like JSMS did in http://tools.ietf.org= /html/draft-rescorla-jsms-00#appendix-A, but I'll remark tha= t this an informative tool, not a normative one.

>>>

>>> I actualy don't have a hugely urgent requirement here e= ither.=A0 It's something that others in the WG had requested, which is = trivial to add in JSMS, but not in JWE/JWS -- again because of the unnecess= ary integrity protection of the header.

>>>

>>>

>>>> -- Lack of versioning for future extensibility

>>>>

>>>> An optional version field could be added if the working= group

>>>> desires, however the last time the working group discus= sed it, they

>>>> decided not to do so.=A0 Rather, specs like this effect= ively become

>>>> "versioned" when revised in a way that new fi= elds are added.=A0 If

>>>> you understand the new fields, you support that new ver= sion.=A0 (Note

>>>> that this is independent of whether there is a version = number

>>>> field, which according to some participants in the prev= ious

>>>> discussion, they regarded as therefore being redundant

>>>> information.)

>>>>

>>>> I'm not religious about not having a version number= field, but often "less is more".

>>>

>>> Indeed, I'm not religious either.=A0 It just seems like= a general good idea to state this directly as opposed to having parsers di= vine it based on which fields are present.=A0 To quote RFC 5652:<= /u>

>>> "

>>>=A0 Each of the major data structures includes a version num= ber as the=A0

>>> first item in the data structure.=A0 The version numbers ar= e intended=A0

>>> to avoid ASN.1 decode errors.=A0 Some implementations do no= t check the=A0

>>> version number prior to attempting a decode, and if a decod= e error=A0

>>> occurs, then the version number is checked as part of the e= rror=A0

>>> handling routine.=A0 This is a reasonable approach; it plac= es error=A0

>>> processing outside of the fast path.=A0 This approach is al= so

>>> forgiving=A0 when an incorrect version number is used by th= e sender.

>>> "

>>>

>>>

>>> Best,

>>> --Richard

>>>

>>>

>>>

>>>

>>>

>>>>

>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Best wishes,

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

>>>>

>>>> -----Original Message-----

>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.c= om]

>>>> Sent: Friday, June 15, 2012 3:00 PM

>>>> To: Mike Jones

>>>> Cc: = jose@ietf.org<= /a>

>>>> Subject: Re: [jose] Fwd: New Version Notification for

>>>> draft-barnes-jose-jsms-00.txt

>>>>

>>>> Ok, so maybe I should have phrased my lead-in different= ly.=A0 IMO, the current JW* specs are deficient in several ways, e.g.:

>>>> -- Not being JSON

>>>> -- Not supporting multiple recipients

>>>> -- Lacking clear distinctions between signing and MAC

>>>> -- Lacking clear processing instructions for different = key

>>>> establishment modalities

>>>> -- Lack of clear typing of objects

>>>> -- Lack of versioning for future extensibility

>>>>

>>>> Looking at the current specs, it didn't seem to me = that it would be simple to adapt them to address these deficiencies.=A0 So = I just did a re-write.=A0 If you think they can be addressed within the cur= rent framework, please explain.=A0 I just found it simpler to start from whole cloth.

>>>>

>>>> Cheers,

>>>> --Richard

>>>>

>>>>

>>>>

>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote:

>>>>

>>>>> Hi Richard,

>>>>>

>>>>> If you're puzzled by specific design decisions = in the JOSE documents, I encourage you to ask about them on the list.=A0 Th= e documents have significant history going back to mid-2010 when convergenc= e discussions started among people with four different JSON signing & encryption proposals.=A0 JWT and th= e current JOSE specs and implementations are the result.=A0 I realize that = not all the JOSE participants were part of those discussions from the begin= ning (although many were) and so teasing out the rationale for specific decisions might help people better understa= nd the choices made, and hopefully thereby increase consensus behind the ev= entual working group choices.

>>>>>

>>>>> If the list that you're puzzled by is the bulle= ted list below, maybe we can start a discussion on that basis.

>>>>>

>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Best wishes,

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

>>>>>

>>>>> -----Original Message-----

>>>>> From: jose-bo= unces@ietf.org [mailto:jose-bounces@ietf.or= g] On

>>>>> Behalf Of Richard L. Barnes

>>>>> Sent: Friday, June 15, 2012 2:08 PM

>>>>> To: jose@ietf.org

>>>>> Subject: [jose] Fwd: New Version Notification for <= u>

>>>>> draft-barnes-jose-jsms-00.txt

>>>>>

>>>>> Dear JOSE WG,

>>>>>

>>>>> Like Mr. Manger, once I finally got around to doing= a thorough review of the JW* specs, I was kind of puzzled by some of the d= esign decisions.=A0 So I also went through and wrote an alternative format,= this time taking a more of a cue from CMS.=A0 A link to the document is below.

>>>>>

>>>>> Summary of differences:

>>>>>

>>>>> o=A0 JSMS is pure JSON, whereas in JWE and JWS only= the header

>>>>>=A0=A0 parameters are represented in JSON.=

>>>>>

>>>>> o=A0 JSMS allows for full algorithm agility in key = agreement, while JWE

>>>>>=A0=A0 only allows ECDH-ES.

>>>>>

>>>>> o=A0 JSMS supports multiple recipients for Encrypte= dData and

>>>>>=A0=A0 AuthenticatedData objects via the inclusion o= f multiple WrappedKey

>>>>>=A0=A0 objects.=A0 Sending a JWE to multiple recipie= nts requires re-

>>>>>=A0=A0 encryption of the entire object for each reci= pient.

>>>>>

>>>>> o=A0 The signature and MAC functions of the JWS obj= ect are separated

>>>>>=A0=A0 into SignedData and AuthenticatedData JSMS ob= jects.

>>>>>

>>>>> o=A0 JSMS parameters are not integrity-protected, a= s they are in JWE

>>>>>=A0=A0 and JWS.

>>>>>

>>>>> o=A0 The "typ" and "zip" parame= ters are not defined in JSMS, but could

>>>>>=A0=A0 be added without significant change.

>>>>>

>>>>> o=A0 JSMS requires that recipients MUST ignore unkn= own header

>>>>>=A0=A0 parameters, in order to facilitate extensibil= ity.

>>>>>

>>>>> I've also thrown together an initial JavaScript= implementation (based on NodeJS for some python crypto glue), which is on = github:

>>>>> <ht= tps://github.com/bifurcation/jsms>

>>>>>

>>>>> Comments are very welcome.=A0

>>>>>

>>>>> Thanks,

>>>>> --Richard

>>>>>

>>>>>

>>>>>

>>>>> Begin forwarded message:

>>>>>

>>>>>> From: = internet-drafts@ietf.org

>>>>>> Subject: New Version Notification for

>>>>>> draft-barnes-jose-jsms-00.txt

>>>>>> Date: June 15, 2012 4:56:09 PM EDT

>>>>>> To: rbarnes@b= bn.com

>>>>>>

>>>>>>

>>>>>> A new version of I-D, draft-barnes-jose-jsms-00= .txt has been

>>>>>> successfully submitted by Richard Barnes and po= sted to the IETF

>>>>>> repository.

>>>>>>

>>>>>> Filename:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 d= raft-barnes-jose-jsms

>>>>>> Revision:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 00

>>>>>> Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 JavaScript Message Security Format

>>>>>> Creation date:=A0=A0=A0 2012-06-15

>>>>>> WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Individual Submission

>>>>>> Number of pages: 25

>>>>>> URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/i= nternet-drafts/draft-barnes-jose-jsms-00.txt

>>>>>> Status:=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://datatracker.ie= tf.org/doc/draft-barnes-jose-jsms

>>>>>> Htmlized:=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org= /html/draft-barnes-jose-jsms-00

>>>>>>

>>>>>>

>>>>>> Abstract:

>>>>>> Many applications require the ability to send c= ryptographically

>>>>>> secured messages.=A0 While the IETF has defined= a number of formats

>>>>>> for such messages (e.g.=A0 CMS) those formats u= se encodings which

>>>>>> are not easy to use in modern applications.=A0 = This document

>>>>>> describes the JavaScript Message Security forma= t (JSMS), a new

>>>>>> cryptographic message format which is based on = JavaScript Object

>>>>>> Notation (JSON) and thus is easy for many appli= cations to generate and parse.

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>> The IETF Secretariat

>>>>>

>>>>> _______________________________________________<= /u>

>>>>> jose mailing list

>>>>> = jose@ietf.org<= /a>

>>>>> https://www.ietf.org/= mailman/listinfo/jose

>>>>>

>>>>>

>>>>> _______________________________________________<= /u>

>>>>> jose mailing list

>>>>> = jose@ietf.org<= /a>

>>>>> https://www.ietf.org/= mailman/listinfo/jose

>>>>

>>>>

>>>>

>>>> _______________________________________________<= u>

>>>> jose mailing list

>>>> jose@ietf.org<= u>

>>>> https://www.ietf.org/= mailman/listinfo/jose

>>>

>>> _______________________________________________

>>> jose mailing list

>>> jose@ietf.org

>>> https://www.ietf.org/= mailman/listinfo/jose

>>

>

=A0


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
--000e0ce0d6729bdbec04c2fced86-- From bcampbell@pingidentity.com Thu Jun 21 08:47: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 D2AD821F86E3 for ; Thu, 21 Jun 2012 08:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.857 X-Spam-Level: X-Spam-Status: No, score=-5.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZD7Bjmpkbmw for ; Thu, 21 Jun 2012 08:47:16 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD0B21F86DE for ; Thu, 21 Jun 2012 08:47:15 -0700 (PDT) Received: from mail-qc0-f179.google.com ([209.85.216.179]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKT+NCA3r+tkKMkzFOZx6gjz36u05utih3@postini.com; Thu, 21 Jun 2012 08:47:16 PDT Received: by qcse14 with SMTP id e14so432107qcs.38 for ; Thu, 21 Jun 2012 08:47:14 -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=yuzmtcQEUf2PRzgsRCg6CvEobTbAzPt2VSz9ks5QGcI=; b=n6l7ZO/41wOfH/9mRI2/gCTX8osFoeWOB6BojV7qLXV+WVK+00Cx/lXzrNkGlxjOFT u/PC5csq+4liOtb53oPifGsqbU+bwFWSIFky554kHRwltQPfISxwbZ8jPZFKItMOJpCJ mZh+OWF4uFkihAB8G2KzTr7HbB31oeNOfHl2iXia6w5CbuIoYy+aCwi4dJ+MuyWeljGO n6vzYfyVR3TqD2FjU6q3XGDs8GKJ7JPDWiDdA2UvpybuhnLgB3e0aZ7PMPKRcaKejdGv ZL8UF4MZ2M3+O8gnaYGbNILNSesUiaejb82tFigr8XJX2imcYFDcOOg2LTp4ykzx1gJ6 Ax0w== Received: by 10.229.135.146 with SMTP id n18mr10793368qct.138.1340293634742; Thu, 21 Jun 2012 08:47:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 08:46:44 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> From: Brian Campbell Date: Thu, 21 Jun 2012 09:46:44 -0600 Message-ID: To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmMsAM8e0/poyW6DGaQP5WcQ+jIr6ck4xo5E/jfXmKqeqrFodzBnlPPsh9Zvi1b4onuxh1r Cc: "Richard L. Barnes" , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 15:47:17 -0000 On Wed, Jun 20, 2012 at 4:57 PM, John Bradley wrote: > > I think part of this is that as one of the openID Connect authors I look at this as a necessary security token format, for OAuth and Connect. > For that simple processing with one signature is a high priority for adoption. +1. A simple JSON friendly model supporting a single signature over the entire message (including headers) is an important case for adoption (and security). JWS provides that now and there are already numerous interoperable JWS implementations available or in the works. From ietf@augustcellars.com Thu Jun 21 12:12: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 BF4A621F8790 for ; Thu, 21 Jun 2012 12:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hreH2xXJX-JZ for ; Thu, 21 Jun 2012 12:12:01 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1174E21F8793 for ; Thu, 21 Jun 2012 12:12:01 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (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 AEA2838F06 for ; Thu, 21 Jun 2012 12:12:00 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 21 Jun 2012 12:10:33 -0700 Message-ID: <010201cd4fe1$8f264be0$ad72e3a0$@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: Ac1P4Wc2cInpa98uRZKGT5rWgh75LQ== Content-Language: en-us Subject: [jose] Call for Presentations for Vancouver 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, 21 Jun 2012 19:12:01 -0000 Please advise the chairs if you want to do a presentation in Vancouver. Let us know the topic, related document (if any), who the presenter is going to be and an estimate of the amount of time you believe will be necessary. Thanks Jim From mamille2@cisco.com Fri Jun 22 06:20: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 5AFB421F8596 for ; Fri, 22 Jun 2012 06:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCuR8csH3lm3 for ; Fri, 22 Jun 2012 06:20:31 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3DE21F8592 for ; Fri, 22 Jun 2012 06:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6060; q=dns/txt; s=iport; t=1340371231; x=1341580831; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=l0ceAFnB1hNn0wYFBXmBAo74i2SqdJN6dUiPhJqa5i0=; b=ZEE7oVavIzKD8ecb5yA6fQ0mJtqi1yTn8Wwm3NvtUgjp6wxycNReo000 47wdgtLBEacRBnzq1u6SHG4bYPWaWFSbvhrgECKx5HBQooW3hnuqG3aUQ kEaQ6BdPHD3tbrVWFvQiUsCN2Yi+m++9fS4Eeo/QAlgszbcLqtDcz93Jb o=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKhw5E+rRDoJ/2dsb2JhbABFtWSBB4IYAQEBAwEBAQEPAVsQCxwDAQIvAiUfBwIIGQkZh2QEAQuZcKAKiy6CZoMcA4hHhX2GaIEShESFL4MWgWaCfg X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="sig'?p7s'?scan'208";a="46770851" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 22 Jun 2012 13:20:30 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5MDJeOY020555 for ; Fri, 22 Jun 2012 13:20:29 GMT From: Matt Miller Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-20--860701765" Date: Fri, 22 Jun 2012 07:20:34 -0600 References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> To: jose@ietf.org Message-Id: <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Subject: [jose] Fwd: I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 13:20:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-20--860701765 Content-Type: multipart/signed; boundary=Apple-Mail-19--860701769; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-19--860701769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, a proposal for XMPP E2E, using JOSE. This has been updated to the = latest JOSE WG drafts. - m&m Matt Miller - Cisco Systems, Inc. Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 22, 2012 07:00:24 MDT > To: i-d-announce@ietf.org > Subject: I-D Action: draft-miller-xmpp-e2e-01.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) > Author(s) : Matthew Miller > Filename : draft-miller-xmpp-e2e-01.txt > Pages : 22 > Date : 2012-06-21 >=20 > Abstract: > This document defines a method of end-to-end object encryption for > the Extensible Messaging and Presence Protocol (XMPP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-19--860701769 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMjEzMjAz NVowIwYJKoZIhvcNAQkEMRYEFLYAl6FgWAe+ueP7hTQJ5bZlUpYoMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAwY8/nLlSU6gk1xCWHYo3aWbY7HJhWRHKE4LGjvxH0PJIciTB4c3kAdX7B r7tnigtqHN4On6OTUvzurFj5uipU9wSNYTeMmt/j1B6OSUUS1hhMGtmTE121i0VwDfwPlnBIae43 JtKqaC+ZmeKWpLuyV97XUKvaPNSEDJdqVYcDE7udFo5wu83DWC6GrsrS9jLdz9Z4LdLeCjOi2wEn FfJwEubcX3ey6AitvH7kumcLd3sw3EAlxUnF2dvC96vhTmivfEr1E4Y2qfYDlQH21ZE5v5VIs8H3 GFM989A5drlvGBolwbLZAc+GRwOB6Wy4ucyFZl1wzFieTtQj9i4HkwCXAAAAAAAA --Apple-Mail-19--860701769-- --Apple-Mail-20--860701765 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP5HEiAAoJEJq6Ou0cgrSPBKoH/35DSRTcrUIp1/sFjfWc2QLl 8shXvsUYiM1JUq4dEB1r2Rl0D5AhINu3civKy01GDBYETeky+Cw8xnY2FfkCRPPq YOeNh6dQPywZPwOVb07o6BThuIITD17e1BrNHpyXEaa0jVxCXOCr7y/jcWufFodg 0/4Eh/w8ul8enQTQ257rgWvxjxq/Ldj1WIOe9ZsMOEFpP04mXI+gj4xEiKA2U1Ik iyzQ/LfLssyb2IHj/PZIbaBl7Dykiw7Vq2347uckv3zUXxcI4UXNUOzfRWhXlweI tOpabf8WGj2Vpj5UFLTaY2ZKu9HYjUkvnJxryQO6lCn440S/DuAxYNdknVQNknQ= =ipIL -----END PGP SIGNATURE----- --Apple-Mail-20--860701765-- From mamille2@cisco.com Fri Jun 22 08: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 A22F421F8621 for ; Fri, 22 Jun 2012 08:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67q4r9u8tis5 for ; Fri, 22 Jun 2012 08:19:16 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0743521F8613 for ; Fri, 22 Jun 2012 08:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6954; q=dns/txt; s=iport; t=1340378356; x=1341587956; h=from:mime-version:subject:date:in-reply-to:to:references: message-id:content-transfer-encoding; bh=RiJRXXIwSTeKesy3X2o49H3rAiyWiO+Lr6aOWmkVggs=; b=grguzHj6PtE6eHwl6Ra5aqJouZ5tiH4uqm/UOnxaBhwVmseSqdEA/jCS 9DQcRDtWCaSxfCKCg6QlPkeZdb2mXqBjXkVJ5S5Z6EJnM10C+i3LFHPZh qsuVrq5UFmzPa7gMSAzklbME9Ra04A6hsmc/Dhz84PHxXaflqYycIscK5 U=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAC2M5E+rRDoH/2dsb2JhbABFtWSBB4IUBAEBAQMBAQEBDwFbGwsRAwECLwIlHwkIGQkZhScHgiQSBAELmgugEosugmaCPGADiEeFfYZogRKERIUvgxaBZoJ+ X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="sig'?p7s'?scan'208";a="49809715" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 22 Jun 2012 15:19:15 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5MFJFFR024839 for ; Fri, 22 Jun 2012 15:19:15 GMT From: Matt Miller Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26--853576517" Date: Fri, 22 Jun 2012 09:19:19 -0600 In-Reply-To: <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> To: jose@ietf.org References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> Message-Id: <01AE1D01-E8B8-4FC6-B71B-3BB8F0935E51@cisco.com> Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Subject: Re: [jose] Fwd: I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 15:19:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26--853576517 Content-Type: multipart/signed; boundary=Apple-Mail-25--853576521; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-25--853576521 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A significant item of note: this draft attempts to use "alg":"none" in = order to separate the keys from the content, and rely on an exchange of = keys outside of the JOSE containers. I opted not to use "draft-jones-json-web-encryption-json-serialization" = because the duplication of headers, with rather minor variances between = them, felt overly cumbersome; lots of decoding and parsing to find the = right header/key/int combo. I also have a key distribution problem that = I felt the serialization draft makes worse for me. If there were a good way to separate "properties of the content = encryption" from "properties of key encryption", that might make it more = palatable. It wouldn't completely solve my key distribution problem, = but I think it would might help. - m&m Matt Miller - Cisco Systems, Inc. On Jun 22, 2012, at 07:20, Matt Miller wrote: >> From: internet-drafts@ietf.org >> Date: June 22, 2012 07:00:24 MDT >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >> Author(s) : Matthew Miller >> Filename : draft-miller-xmpp-e2e-01.txt >> Pages : 22 >> Date : 2012-06-21 >>=20 >> Abstract: >> This document defines a method of end-to-end object encryption for >> the Extensible Messaging and Presence Protocol (XMPP). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-25--853576521 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMjE1MTky MFowIwYJKoZIhvcNAQkEMRYEFJE+gqp5Y5sGP9dct73tEOeZmLCGMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAf/MyDQ9hyw2xANzmVeFdQut+QyY1oV5GuWTv6TPLcBfoiIsY2ipJVHVb2 nzcZmX1o3tY6L/iKeb7dQVRbwnbbJ0Th3ZrdlG5X3yWCGsJkR2fvnYbiZn4VrrwqwyTFhOVE0Lxe 9RBK4JcupAOc0+9fKtCSLn9ri9ML6/EIYTdClpsgamlfkHGqK/8gEyA6KeSISd4Exorl8HazOghj W2urPy1Qe3rRQXEhCtlK79BcMfsxOI0KnIYCTLtBeM/1HAGduo5430tX1DrHu2/y2Bp57wetwUSJ HUBuaxQjAymGzFcBIzKhx4s+UGQvYgvC87CYZ7+ZnYEC9+RWU8keD5naAAAAAAAA --Apple-Mail-25--853576521-- --Apple-Mail-26--853576517 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP5Iz4AAoJEJq6Ou0cgrSP4PIIANGg6QsDgq9u+wyneia6R+Ob zs20kO/eIUJhTE5F+m4TLvG4voA8WMEk2+42e0igteOzoa9oBX2+lUGwaWNcMJez qDZC293CwyR2Z4L+n3iCtT8WHhunTT6aT/vjioP/HuL12ytmOvcrfX6ufoGYNI+n TW3CClt1nGlXCrcB1dYPMyN2qBCCLgB88qhTe+jGkkopcTq7wOObTagjhXEYb3of vjx1Xi5H6nhS9uZiRLIYZ9SBknadAEkNvgwo8p4XdXP/62Fx0u4s0FO52iO5+IeI hDryksclsxIAhjt/BRLF2qxlP6KrRw6gsSJ0rOhb5qU9V8WlhcapXuGPU+jKUd0= =7lQi -----END PGP SIGNATURE----- --Apple-Mail-26--853576517-- From ve7jtb@ve7jtb.com Fri Jun 22 09:12: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 8D29421F8795 for ; Fri, 22 Jun 2012 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWfG22w95sDL for ; Fri, 22 Jun 2012 09:12:28 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC121F876E for ; Fri, 22 Jun 2012 09:12:28 -0700 (PDT) Received: by yenq13 with SMTP id q13so1838503yen.31 for ; Fri, 22 Jun 2012 09:12:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=MQDJtAP89inPAK3Yl2Vr6cr0WqtAenyC7ob6rUBCxoc=; b=I0gKt7288wMhlkZUtt5z7OO5TD1BCEk0+yHBGZ5zQ/joKNLf1Bsttiv6KG1AdoCj18 6tbQajz92bg8mCqNpfNrpPuqq+gtGDZsoegBFNwOsG8PvuI2zo2piFgfF0slAsoc0Vgq yUdSVL+UGAUCP2lYbJGdR/d2vdqxMM+3ZfcV252DZQFvRTsmzUN/tzlGvIavkBZsCXll K2UhOnYQJamLZMwDV+LeHrY/NLbwT93IUiWifAf8G1vgcFNW3ka+Wz4RuVSNu3foEMz1 Vbp+OGxKJY+kZMomctLyCvyyoKU+O8rICnP96gsaZV5MSoQgcwFdvWj6VvuY9x6XfcSZ dVgg== Received: by 10.236.190.4 with SMTP id d4mr2988881yhn.73.1340381547789; Fri, 22 Jun 2012 09:12:27 -0700 (PDT) Received: from [192.168.1.213] (190-20-0-157.baf.movistar.cl. [190.20.0.157]) by mx.google.com with ESMTPS id x42sm115273988yhd.3.2012.06.22.09.12.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jun 2012 09:12:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0A41A1F4-8AC1-44DE-8185-48F54A88353F"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> Date: Fri, 22 Jun 2012 12:12:18 -0400 Message-Id: <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQm9g3vDLoOcchps5mi8WJs47slz/TT1ccWXTZB+H3B/Ji8tAHrN0YluxwhX5moQq4Vhev8/ Cc: jose@ietf.org Subject: Re: [jose] Fwd: I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 16:12:29 -0000 --Apple-Mail=_0A41A1F4-8AC1-44DE-8185-48F54A88353F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Matt, Complements on updating the draft. The issue I see is that you are attempting to distribute the CMK out of = band and use "none" as the alg. There has been a fair amount of discussion on this. In some earlier JWE = drafts before mandatory integrity you could directly encrypt/decrypt = with the out of band shared secret. Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. =20 =46rom a implementation point of view the symmetric cypher always gets = the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. I also suspect that you intended to use A256GCM as the enc alg and not = A256CCM.=20 I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is = properly supported. Regards John B. On 2012-06-22, at 9:20 AM, Matt Miller wrote: > FYI, a proposal for XMPP E2E, using JOSE. This has been updated to = the latest JOSE WG drafts. >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: June 22, 2012 07:00:24 MDT >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >> Author(s) : Matthew Miller >> Filename : draft-miller-xmpp-e2e-01.txt >> Pages : 22 >> Date : 2012-06-21 >>=20 >> Abstract: >> This document defines a method of end-to-end object encryption for >> the Extensible Messaging and Presence Protocol (XMPP). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_0A41A1F4-8AC1-44DE-8185-48F54A88353F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy MjE2MTIxOVowIwYJKoZIhvcNAQkEMRYEFIuUedTyIxQ64qbDsforEdn5TDv3MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AI+vgEy4UaMuBYDi3oSRW4y2qvyNWcAJkj2Of2cVA7kbbOhEigCIQGkzHWeA9aA64fSZ9jmM1Htk +BpevmN2Qm2Doz2H7Xac2pisJZ3XvK/sUYrr8tmrLyuOZiExNPVcC5fyIn3DrAixdfQOQ7nAGdek rbA7C6qxAaY/+DYmqTxg5QvqRNZbOzHPOl2dQhwFnSHZL/0w1DgZ7C2KbFwEDEoh3m0hWEcHSh90 8gp7erVuVXy2ETk68hzP6h3Z8y1ZDC/PPgHAIO85nWSz1iHDU80eXJkMfBbBL96rJGYCK8p2h2fg qB2vqVcnWAYi1oSoM7i+YXwa5XB/RJ4J+UwDCekAAAAAAAA= --Apple-Mail=_0A41A1F4-8AC1-44DE-8185-48F54A88353F-- From rbarnes@bbn.com Fri Jun 22 12:34: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 69CE021F85A8 for ; Fri, 22 Jun 2012 12:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uysv8zSi3WHx for ; Fri, 22 Jun 2012 12:34:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A821F8682 for ; Fri, 22 Jun 2012 12:34:21 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:50668) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Si9cP-000Czh-8P; Fri, 22 Jun 2012 15:34:09 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> Date: Fri, 22 Jun 2012 15:34:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org, Matt Miller Subject: Re: [jose] Fwd: I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 19:34:22 -0000 Hey John, I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. --Richard On Jun 22, 2012, at 12:12 PM, John Bradley wrote: > Hi Matt, >=20 > Complements on updating the draft. >=20 > The issue I see is that you are attempting to distribute the CMK out = of band and use "none" as the alg. >=20 > There has been a fair amount of discussion on this. In some earlier = JWE drafts before mandatory integrity you could directly encrypt/decrypt = with the out of band shared secret. >=20 > Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. =20 > =46rom a implementation point of view the symmetric cypher always gets = the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >=20 > That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >=20 > So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >=20 > I also suspect that you intended to use A256GCM as the enc alg and not = A256CCM.=20 >=20 > I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is = properly supported. >=20 > Regards > John B. >=20 >=20 > On 2012-06-22, at 9:20 AM, Matt Miller wrote: >=20 >> FYI, a proposal for XMPP E2E, using JOSE. This has been updated to = the latest JOSE WG drafts. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller - >> Cisco Systems, Inc. >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: June 22, 2012 07:00:24 MDT >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>> Reply-To: internet-drafts@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>> Author(s) : Matthew Miller >>> Filename : draft-miller-xmpp-e2e-01.txt >>> Pages : 22 >>> Date : 2012-06-21 >>>=20 >>> Abstract: >>> This document defines a method of end-to-end object encryption for >>> the Extensible Messaging and Presence Protocol (XMPP). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>=20 >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From mamille2@cisco.com Fri Jun 22 16:09: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 6291111E8095 for ; Fri, 22 Jun 2012 16:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngw0lNjTJ5SB for ; Fri, 22 Jun 2012 16:09:29 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 978A611E8093 for ; Fri, 22 Jun 2012 16:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=8476; q=dns/txt; s=iport; t=1340406569; x=1341616169; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=JoluNzaRgVK7rN4PNbpmiIIP8lPYDYzUGHNa6xCMJsg=; b=SzYpR4oZ3aTMfGviSKKgB2tRE4aI2qvajf56/HhksHCuKZx7CUUAQe3h j9eUMKGM7emDhvjK1dF4A6WBOCmyhZZSoCZlm208HIEVrGpNaaKPGVTto R87NxO5z+fwwP5CowtPjjFJzqo+TFjoXUWbkvOvOD5i6/+rhy5RwRm9Sz s=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGH65E+rRDoJ/2dsb2JhbABFtWeBB4IYAQEBAgEBAQEBDwFYAwsFCwsOAwMBAgEuAiUfCQgGEwkZh2QEAQuaL59niy6FImADiEeFfYZogRKERIUvgxaBZoJ+ X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="sig'?p7s'?scan'208";a="47354552" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 22 Jun 2012 23:09:29 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5MN9SGo010054; Fri, 22 Jun 2012 23:09:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-47--825363606" From: Matt Miller In-Reply-To: <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> Date: Fri, 22 Jun 2012 17:09:32 -0600 Message-Id: References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> To: John Bradley Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: jose@ietf.org Subject: Re: [jose] Fwd: I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 23:09:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-47--825363606 Content-Type: multipart/signed; boundary=Apple-Mail-46--825363615; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-46--825363615 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 22, 2012, at 10:12, John Bradley wrote: > Hi Matt, >=20 > Complements on updating the draft. >=20 > The issue I see is that you are attempting to distribute the CMK out = of band and use "none" as the alg. >=20 > There has been a fair amount of discussion on this. In some earlier = JWE drafts before mandatory integrity you could directly encrypt/decrypt = with the out of band shared secret. >=20 > Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. =20 > =46rom a implementation point of view the symmetric cypher always gets = the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >=20 > That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >=20 > So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >=20 I had not fully considered that; I'll have to ponder this. > I also suspect that you intended to use A256GCM as the enc alg and not = A256CCM.=20 >=20 I like real examples, and I had an implementation of CCM handy but not = one for GCM (-: I'll most likely update the examples to = draft-mcgrew-aead-aes-cbc-hmac-sha2 in a future version, since I have = the "pieces" to implement this; I strongly recommend the WG look at = adopting this, too. > I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is = properly supported. >=20 I believe Richard Barnes summed it up in his JOSE usecases[1] = presentation in Paris. There's also the presentation I did on = XMPP-E2E[2] I did for Paris. - m&m Matt Miller - Cisco Systems, Inc. [1] < http://www.ietf.org/proceedings/83/slides/slides-83-jose-7.pdf > [2] < http://www.ietf.org/proceedings/83/slides/slides-83-xmpp-1.pdf > > Regards > John B. >=20 >=20 > On 2012-06-22, at 9:20 AM, Matt Miller wrote: >=20 >> FYI, a proposal for XMPP E2E, using JOSE. This has been updated to = the latest JOSE WG drafts. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller - >> Cisco Systems, Inc. >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: June 22, 2012 07:00:24 MDT >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>> Reply-To: internet-drafts@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>> Author(s) : Matthew Miller >>> Filename : draft-miller-xmpp-e2e-01.txt >>> Pages : 22 >>> Date : 2012-06-21 >>>=20 >>> Abstract: >>> This document defines a method of end-to-end object encryption for >>> the Extensible Messaging and Presence Protocol (XMPP). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>=20 >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail-46--825363615 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMjIzMDkz M1owIwYJKoZIhvcNAQkEMRYEFCAVyejGafrkZW8PPMhZ5mmwJUCpMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAHQZRK7C31IbpX0C2w8AP6hCkdaRCerWRHAFGATkgIo4xX9kquS1/KGgRJ tR6CawGBp9peRr4eRkNQXcBduJvrxOf5SJaEmYZgEd+d9Oy0uBo/YKoyUOeLt/gdAAPptrfnAcx6 h1XvnQ9KcpVQAiFCcEwirZqo8H61mfLWa+fQjQpQ8D4usGFkGKtrMIJ4T3JKMfludBZbv6FS+v/F xag4jdRKdauZod4vgtXossT0ucaOpBQIxBJJ4yM8mSl6bMFvzPK4r/vUqOA/QaD9e3Vv2bpqDgS+ SKmtEGlGahcAeqFpfSLZedDQM5RakatxmK2yKOem4TaLdwSWbfdta4l9AAAAAAAA --Apple-Mail-46--825363615-- --Apple-Mail-47--825363606 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP5PstAAoJEJq6Ou0cgrSPVzQH/jVIbkWGT6A7UiCnmsJFbQH2 Tbalc98izS/mSVmW9mpKdinKYBCRoisvPC8HBU/eCSUFzFTpDT1IXA5+aFSor/EY knOjv7V1Tzgq97IOfU68u6gbg4qNPxZCrjH6Pkhvav152ZLcDIB+F2DrKd1fN6+7 SM58NRP/IWFXapVo+2ri0tqraXrIAAMKKV/3eC4f6LWmetEYGXaXAvu59voTID8j ACKi+L/Th6CKmsW+vrtGXCCy9Sy+oGZXp8zolBcFH+ngSXpmonBL9YZLLle3phIk uDWeKscMuezIEGQDiyyRoseSRtNsO1vx1GSoMDfhFM8OKODHjtGw2V62GiqznnU= =gMn5 -----END PGP SIGNATURE----- --Apple-Mail-47--825363606-- From ve7jtb@ve7jtb.com Fri Jun 22 16:12:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A87011E8093 for ; Fri, 22 Jun 2012 16:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj0V5YVu6dmN for ; Fri, 22 Jun 2012 16:12:08 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDEA21F8528 for ; Fri, 22 Jun 2012 16:12:06 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2162497ggn.31 for ; Fri, 22 Jun 2012 16:12:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer:x-gm-message-state; bh=4WXlcAubEy1qwTH7mgOOER7uvvBB63JGK4+dcDZVm1Y=; b=UnUOLRdvzjztCjU0n9V7wCUT40pVIa2/2PNcIPrP4IcZSueODju9rUWMCfaaPNG28e D6BeZyS7ar087efGdmMd4gVz/+9ZjgupYAWbabroSQVm3uJVSzHgM9YMbT4ivbfrd7b7 HYgOTs1TARxML4I8JA4Loc7ZrJ/e8AxaLIUSBAyqLUvk3aurzEsGGgGW7Fz/YGGmGr+q X+i2L7igrrAHToAYUbdTkUt87Dv33E+XWBSVUeBuAYpHsowgqc5LUHMpkVKQ69TWg06C 5PNL0EN76rLd9dXh/CNkNAvjQAqwOpr/e6UpXjgNVUofJc5vQziX0/XqagaHtJE/8pnr 7vpA== Received: by 10.100.243.23 with SMTP id q23mr1392306anh.37.1340406725856; Fri, 22 Jun 2012 16:12:05 -0700 (PDT) Received: from [192.168.1.213] (190-20-54-57.baf.movistar.cl. [190.20.54.57]) by mx.google.com with ESMTPS id r8sm50412056ani.9.2012.06.22.16.12.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jun 2012 16:12:05 -0700 (PDT) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_708A3CBB-D9F0-4C65-B516-A5A99D9D4B8B"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 22 Jun 2012 19:11:57 -0400 References: <213C613D-3901-457D-91E3-FB961C785903@mac.com> To: jose@ietf.org Message-Id: <3ABA4A4A-ECD3-4DD6-A8B3-4545C48382DF@ve7jtb.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl4nENdXU5j4TtLiC2M3uKJD70dFLbWnCsTKVYhJ8SICT7rxYwB+elx/w2d5Z8ibaXo/kI8 Subject: [jose] I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 23:12:10 -0000 --Apple-Mail=_708A3CBB-D9F0-4C65-B516-A5A99D9D4B8B Content-Type: multipart/alternative; boundary="Apple-Mail=_E1404CD1-9C80-448C-9B81-C173DC907378" --Apple-Mail=_E1404CD1-9C80-448C-9B81-C173DC907378 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Richard, =20 Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" =20 I should also point out that the messages are transported in XML, and as = such, the addition of a JSON wrapper for the JWE probably is not useful = as it would need escaping anyway. By not sending the CMK as part of the = message, you get a small reduction in message size, but you increase the = number of separate key transport messages required. In any event it = has nothing to do with integrity protecting the header. =20 There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. =20 For the transmission of the messages, I can't see any reason to not use = the JWE spec as currently written. It certainly supports the use case = without modification. Matt's creative use of "none" as the algorithm is = not required and likely only requires a short conversation to sort out. =20 Currently the message on the wire looks like: =20
eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX NpemUiOiIxNiJ9
7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- eCGP =20 I would have sent header and data as one element using the normal JWE = dot separated format, but I need to talk to Matt to understand his = reasoning. =20 I note that his example is using AES-CCM, and so not documented in JWA. = That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. =20 I don't quite get your point on integrity protecting the wrapped key = causing the integrity value to change. For HMAC, GCM, and I think CCM, = changing the encryption key changes the tag value anyway (sort of the = point I thought). The only time it would stay the same would be if you = were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). =20 There are some interesting things Matt=92s spec is attempting with using = asymmetrically encrypted/signed JWE/JWS as a key transport protocol. I = need to go through that more closely. =20 I am happy to work with Matt to refine his ID. =20 I recommend others read it as well so we can understand if there are any = real issues. =20 Regards John B. On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: > Hey John, >=20 > I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. >=20 > This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >=20 > On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >=20 >> Hi Matt, >>=20 >> Complements on updating the draft. >>=20 >> The issue I see is that you are attempting to distribute the CMK out = of band and use "none" as the alg. >>=20 >> There has been a fair amount of discussion on this. In some earlier = JWE drafts before mandatory integrity you could directly encrypt/decrypt = with the out of band shared secret. >>=20 >> Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. =20 >> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>=20 >> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>=20 >> So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>=20 >> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>=20 >> I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is = properly supported. >>=20 >> Regards >> John B. >>=20 >>=20 >> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>=20 >>> FYI, a proposal for XMPP E2E, using JOSE. This has been updated to = the latest JOSE WG drafts. >>>=20 >>>=20 >>> - m&m >>>=20 >>> Matt Miller - >>> Cisco Systems, Inc. >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: June 22, 2012 07:00:24 MDT >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>> Reply-To: internet-drafts@ietf.org >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>=20 >>>>=20 >>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>> Author(s) : Matthew Miller >>>> Filename : draft-miller-xmpp-e2e-01.txt >>>> Pages : 22 >>>> Date : 2012-06-21 >>>>=20 >>>> Abstract: >>>> This document defines a method of end-to-end object encryption for >>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_E1404CD1-9C80-448C-9B81-C173DC907378 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Richard,
 
"This = document specifies an approach for encrypting communications between two = entities which each might have multiple end-points"
 
I should = also point out that the messages are transported in XML, and as such, = the addition of a JSON wrapper for the JWE probably is not useful as it = would need escaping anyway.  By not sending the CMK as part of the = message, you get a small reduction in message size, but you increase the = number of separate key transport messages required.   In any event = it has nothing to do with integrity protecting the header.
 
There = are two somewhat separate uses for JWE in the spec:  one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys.
 
For the = transmission of the messages, I can't see any reason to not use the JWE = spec as currently written.   It certainly supports the use case = without modification.  Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out.
 
Currently the message on the wire looks = like:
 
<message xmlns=3D'jabber:client'
            from=3D'juliet@capulet.lit/= balcony'
        =     id=3D'fJZd9WFIIwNjFctT'
to=3D'romeo@montegue.lit/gard= en'
          =   type=3D'chat'>
  =    <e2e xmlns=3D'urn:ietf:params:xml:ns:xmpp-e2e:2'
          = id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
      =  <header>
      =   =  eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS
        =  HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX
        =  NpemUiOiIxNiJ9
      =  </header>
      =  <data>
      =   =  7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO
        =  9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41
        =  wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME
        =  KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk
        =  RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0
        =  1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O
        =  LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg
        =  g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti
        =  JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7
        =  TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD
        =  MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g
        =  E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo-
        =  eCGP
      =  </data>
      =  <mac/>
    =  </e2e>
  =  </message>
 
I would have sent header and data as one = element using the normal JWE dot separated format, but I need to talk to = Matt to understand his reasoning.
I note that his example is = using AES-CCM, and so not documented in JWA.  That isn't a big deal = if we want to add it.  CCM supports extra authenticated data and = outputs an authentication tag like GCM.  In CMS RFC 5084, the tag = seems to be carried separately from the encrypted data and in RFC 3610, = the tag is concatenated to the encrypted data.   If we want to = support CCM, then we need to pick one of the ways to transport the tag = info.  Either would work.   We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the = ciphertext.
 
I don't quite get your point on integrity = protecting the wrapped key causing the integrity value to change.   = For HMAC, GCM, and I think CCM, changing the encryption key changes the = tag value anyway (sort of the point I thought).  The only time it = would stay the same would be if you were just using a MAC over the body = and that is a touch useless for integrity protection.  Perhaps I am = missing the point, but as far as I know even without protecting the = header, the tag value is different for every key (and = nonce/IV).
 
There are some interesting things Matt=92s = spec is attempting with using asymmetrically encrypted/signed JWE/JWS as = a key transport protocol.   I need to go through that more = closely.
 
I am happy to work with Matt to refine his = ID.
 
I = recommend others read it as well so we can understand if there are any = real issues.
 
Regards
John = B.
Hey = John,

I think you're missing the bigger point here, which is: In = order to allow for multiple recipients, Matt had to break = JWE.

This is yet another reason to abandon integrity protection = for cryptographic parameters.  Namely, it makes allowing for = multiple recipients much harder than it needs to be.  If you = integrity-protect the wrapped key, then you need to change the integrity = value whenever you wrap the key for a new recipient.  In addition = to increasing overhead in computing and communicating objects for = multiple recipients, now you've locked yourself out of algorithms that = don't have a separate integrity check value, such as = AES-CCM.

--Richard






On Jun 22, 2012, at = 12:12 PM, John Bradley wrote:

Hi = Matt,

Complements on = updating the draft.

The issue I see = is that you are attempting to distribute the CMK out of band and use = "none" as the alg.

There has been = a fair amount of discussion on this.  In some earlier JWE drafts = before mandatory integrity you could directly encrypt/decrypt with the = out of band shared secret.

Based on JSMS = and mandatory integrity we adopted having a CMK always included in the = message to allow for rotation.  
=46rom a implementation point of view the symmetric cypher = always gets the CEK derived from the CMK in the message independent of = if it is using RSA or A128KW/A256KW.

That imposes = some extra steps for people using symmetric keys but encourages rotation = of the CEK that would likely not happen = otherwise.

So in your spec = I would expect you to distribute a shared secret via keyreq for use in = A256KW and be using that decrypt the CMK at the = receiver.

I also suspect = that you intended to use A256GCM as the enc alg and not A256CCM. =

I am not a XMPP expert so it will take me some time to go = over it in detail.   I would like to understand the use case = to be certain it is properly supported.

Regards
John = B.


On 2012-06-22, = at 9:20 AM, Matt Miller wrote:

FYI, a proposal for XMPP E2E, using JOSE.  This has = been updated to the latest JOSE WG = drafts.


- = m&m

Matt Miller - <mamille2@cisco.com>
Cisco= Systems, Inc.

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /blockquote>
Date: = June 22, 2012 07:00:24 = MDT
To: i-d-announce@ietf.org
Subject: I-D Action: = draft-miller-xmpp-e2e-01.txt
Reply-To: internet-drafts@ietf.org
<= /blockquote>


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


Title =           : End-to-End = Object Encryption for the Extensible Messaging and Presence Protocol = (XMPP)
Author(s) =       : Matthew = Miller
Filename =        : = draft-miller-xmpp-e2e-01.txt
= Pages =           : = 22
Date =            : = 2012-06-21

Abstract:
This= document defines a method of end-to-end object encryption = for
the = Extensible Messaging and Presence Protocol = (XMPP).


The = IETF datatracker status page for this draft = is:
https://da= tatracker.ietf.org/doc/draft-miller-xmpp-e2e

There's = also a htmlized version available = at:
http://tools.= ietf.org/html/draft-miller-xmpp-e2e-01

A diff = from previous version is available = at:
htt= p://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01


Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-d= rafts/

_______________________________________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt

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

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


=


= --Apple-Mail=_E1404CD1-9C80-448C-9B81-C173DC907378-- --Apple-Mail=_708A3CBB-D9F0-4C65-B516-A5A99D9D4B8B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy MjIzMTE1N1owIwYJKoZIhvcNAQkEMRYEFFP7HwHXzbXWWk7Xejrf5S0DTtCqMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJXp7CoiOOxzhd//vXNGZL972o0icCXZVjQ2YRMf3WhH92ugal5rgW3x6UcnUSs3zufGwbYsKkw9 DJstJu/kvBrlK1GDglWx5sx3pnhTWAGjfNsqUuCg71Sz8J3SoIxZZM2XASG0YlSH8a71YY94gTtR 2S/FqcvFRWJU+UPYHewIbQKtdDtOouTAoB1j1WXNTBhc2VYOtoNtLyhKwIVuvHiwWolyQ9+D8ZkZ ZzY/9dbW8k7k700U1F6a0SiTFk2xcl92nazm8nh/iTf2DmoDLvwLGZv532DIZtWVFQWQfn/m9Xui ubpVW3bV7/TCeevJ2IYQNMffyQfeH4rbWvirp24AAAAAAAA= --Apple-Mail=_708A3CBB-D9F0-4C65-B516-A5A99D9D4B8B-- From ve7jtb@ve7jtb.com Fri Jun 22 16:38:12 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A73821F858D for ; Fri, 22 Jun 2012 16:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe2i8PiRgMAq for ; Fri, 22 Jun 2012 16:38:11 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67DCD21F858A for ; Fri, 22 Jun 2012 16:38:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2172626ggn.31 for ; Fri, 22 Jun 2012 16:38:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=JStvsKl41V4LaG3+dPYLfAT7PzeK4qY985Zk5jwgjEQ=; b=Wbzn6t2CpM5mIE4WuoUB53eal2arvdoQ4zr1JBOlEwsy2L6W15bwZQzBZiXQYYy4ro NUydiopduYpjY6ME5hv0IINtAy0dqyhgxg54q/LeIO6NuEOrf8pOuT8yDB9JDjk8WvJe UcRTn6xqE4XyuKekCjlG/891bHSOsgJ5T5+2vBzSHcN7kmTARkaK/bMIrrfsACBSd77+ Gk52XNPOPyA9SGOQj3eeFt3dRhNEd/B7URvR0ZcnDAibgBE2SyPX9OaNpRisqj9BU/Eo nT4H/KwpCk1I6Ixf7RKvcLGk+zAXhi5ILes/HSV6qVkZRDUo0Cm/UwN2yDIAGOSJoh2K c2AA== Received: by 10.101.136.17 with SMTP id o17mr1382468ann.87.1340408275163; Fri, 22 Jun 2012 16:37:55 -0700 (PDT) Received: from [192.168.1.213] (190-20-54-57.baf.movistar.cl. [190.20.54.57]) by mx.google.com with ESMTPS id e19sm50462992ann.10.2012.06.22.16.37.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jun 2012 16:37:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_6AB61196-EA76-4177-8668-EDB87CE61E62"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Fri, 22 Jun 2012 19:37:46 -0400 Message-Id: <677D4D69-8A7F-4C02-A81C-CD31A18ABD13@ve7jtb.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> To: Matt Miller X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmG9/9vlXk5hn1oGv49kzP/LZUrb4BahoHzmmRiLfeM/Pnyiflu4wW2CVsMBLzuIeuRcSQe Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 23:38:12 -0000 --Apple-Mail=_6AB61196-EA76-4177-8668-EDB87CE61E62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Matt, No problem with using CCM, but it is not one of the supported algorithms = yet so where to put the tag needs to be defined. That seems to vary = between implementations from what I can see. That can be sorted out if it gets added. =46rom Richard's presentation he has a single message going to multiple = recipients, but in your spec and presentation I only see two party = symmetric key encryption/decryption with the shared keys distributed via = the key request mechanism. Perhaps you can point me to an example of two endpoints with different = keys receiving and decrypting the same message. =20 One possible way to make things simpler would be to not bother with = distributing the symmetric keys separately. You could have the receiver send it's public key to the sender as you do = now, but use that to RSA encrypt the CMK in each JWE. =20 There may be good reasons you have for not doing that. If you are = coming to IETF in Vancouver perhaps we could whiteboard some options. Also as you are sending the JWE in XML you could just leave it as one = dot separated value. Is there some reason you want the header in a = separate XML element? I see that you are sending the keyid as part of the e2e element, that is = not a problem, though normally that would be in the header. The other thing to consider is using a static-static key agreement = mechanism.=20 There are a bunch of trust issues that I probably need to understand = better in your use case. Regards John B. On 2012-06-22, at 7:09 PM, Matt Miller wrote: >=20 > On Jun 22, 2012, at 10:12, John Bradley wrote: >=20 >> Hi Matt, >>=20 >> Complements on updating the draft. >>=20 >> The issue I see is that you are attempting to distribute the CMK out = of band and use "none" as the alg. >>=20 >> There has been a fair amount of discussion on this. In some earlier = JWE drafts before mandatory integrity you could directly encrypt/decrypt = with the out of band shared secret. >>=20 >> Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. =20 >> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>=20 >> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>=20 >> So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>=20 >=20 > I had not fully considered that; I'll have to ponder this. >=20 >> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>=20 >=20 > I like real examples, and I had an implementation of CCM handy but not = one for GCM (-: >=20 > I'll most likely update the examples to = draft-mcgrew-aead-aes-cbc-hmac-sha2 in a future version, since I have = the "pieces" to implement this; I strongly recommend the WG look at = adopting this, too. >=20 >> I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is = properly supported. >>=20 >=20 > I believe Richard Barnes summed it up in his JOSE usecases[1] = presentation in Paris. There's also the presentation I did on = XMPP-E2E[2] I did for Paris. >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > [1] < http://www.ietf.org/proceedings/83/slides/slides-83-jose-7.pdf > > [2] < http://www.ietf.org/proceedings/83/slides/slides-83-xmpp-1.pdf > >=20 >> Regards >> John B. >>=20 >>=20 >> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>=20 >>> FYI, a proposal for XMPP E2E, using JOSE. This has been updated to = the latest JOSE WG drafts. >>>=20 >>>=20 >>> - m&m >>>=20 >>> Matt Miller - >>> Cisco Systems, Inc. >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: June 22, 2012 07:00:24 MDT >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>> Reply-To: internet-drafts@ietf.org >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>=20 >>>>=20 >>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>> Author(s) : Matthew Miller >>>> Filename : draft-miller-xmpp-e2e-01.txt >>>> Pages : 22 >>>> Date : 2012-06-21 >>>>=20 >>>> Abstract: >>>> This document defines a method of end-to-end object encryption for >>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_6AB61196-EA76-4177-8668-EDB87CE61E62 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy MjIzMzc0NlowIwYJKoZIhvcNAQkEMRYEFB81ZrxcEP2jiPOkuBoUhEtANGTcMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AK0zdw1O8gAZ8zZnbJfvudPTWuOgepdOSoGpKM5Xr+EYEUGlm89kneqaiKtpLnGDr23A29shFqp0 pnbixh0DlHsKtzo1pbcWiT0zGgIAIdIgR/42n2bBtY0yHtpmzDCGWI0xeHBNfY5pNHTIWHT+7WlR w5wLOWyCHSxqkYTVVa9o9/mhbSFPcJ/3T2nh0XNAccjO3ixkS5JNGKCwtfTd2fO1eDoDTsBEMA83 IcuMrYyegqEFF62h5xer/3rbNIvl8sNIoWOP6yqoPP6VqjUbX2XsTzcYE6KJ+wJ/4URm5hCLdJ6V /yyRtBYR05A/cT8UjmtEuItE3sz+YA1lcV2lyXoAAAAAAAA= --Apple-Mail=_6AB61196-EA76-4177-8668-EDB87CE61E62-- From mamille2@cisco.com Fri Jun 22 16:41:34 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 3990721F858F for ; Fri, 22 Jun 2012 16:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPFqbP1iqA2K for ; Fri, 22 Jun 2012 16:41:33 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4053121F858D for ; Fri, 22 Jun 2012 16:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=12075; q=dns/txt; s=iport; t=1340408493; x=1341618093; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=InljNg+rOFH/3OpDsxvrJ3iRimtn3w4aBWyQF11zxOc=; b=JaX716RpsKbRwIXwrtby4GbZzOp8X0YkWYOFM1etQ9cHk64QwvDFYpD4 jyHbhbxIeuHxKXI2Yuc4wv5Rud6B5ovq0dxWo9JFENgAV2ygPg75xcB2R Xuyl9NFMu0S8vOB4DB9sDveUHpq8UFnfbjMOd9/Sow8jyzjYjbBjrXFcZ w=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGkB5U+rRDoI/2dsb2JhbAA9CLVngQeCGAEBAQMBEgFUBA4FCwsOCi4CVQYTIodkBAGaM59kiy4WhQxgA4hHhX2DPIMshVaIRYFmgn6BNwc X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="sig'?p7s'?scan'208";a="49928755" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 22 Jun 2012 23:41:32 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5MNfWf7022102; Fri, 22 Jun 2012 23:41:32 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-49--823440014" From: Matt Miller In-Reply-To: <213C613D-3901-457D-91E3-FB961C785903@mac.com> Date: Fri, 22 Jun 2012 17:41:36 -0600 Message-Id: References: <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <213C613D-3901-457D-91E3-FB961C785903@mac.com> To: John Bradley Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 23:41:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-49--823440014 Content-Type: multipart/signed; boundary=Apple-Mail-48--823440035; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-48--823440035 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 22, 2012, at 17:00, John Bradley wrote: > Hi Richard, >=20 > Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: > "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" >=20 > I should also point out that the messages are transported in XML, and = as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >=20 > There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >=20 > For the transmission of the messages, I can't see any reason to not = use the JWE spec as currently written. It certainly supports the use = case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >=20 I'll ponder more on the key wrapping, as I said in another reply (-: > Currently the message on the wire looks like: >=20 > from=3D'juliet@capulet.lit/balcony' > id=3D'fJZd9WFIIwNjFctT' > to=3D'romeo@montegue.lit/garden' > type=3D'chat'> > id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >
> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS > HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX > NpemUiOiIxNiJ9 >
> > 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO > 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 > wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME > KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk > RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 > 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O > LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg > g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti > JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 > TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD > MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g > E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- > eCGP > > > > >=20 > I would have sent header and data as one element using the normal JWE = dot separated format, but I need to talk to Matt to understand his = reasoning. >=20 The original rationale for not using dot-separated was because = originally (-00) I needed to parse the header before decrypting, to = determine what was missing. With the newer version (-01), it might not = still be necessary. > I note that his example is using AES-CCM, and so not documented in = JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >=20 I personally don't care either way. At one point CCM was mentioned on = the list, so there might be desire there beyond my example. > I don't quite get your point on integrity protecting the wrapped key = causing the integrity value to change. For HMAC, GCM, and I think CCM, = changing the encryption key changes the tag value anyway (sort of the = point I thought). The only time it would stay the same would be if you = were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >=20 > There are some interesting things Matt=92s spec is attempting with = using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >=20 I'll add the rationale to my next version. I think the presentations in = Paris by Richard (in JOSE) and myself (in XMPP) spell it out; in a = nutshell, a single message to a recipient (read: end user) can be = routed/multiplexed to multiple endpoints (resources in XMPP = nomenclature), including instances the sender is not aware of at the = moment of transmission. > I am happy to work with Matt to refine his ID. >=20 > I recommend others read it as well so we can understand if there are = any real issues. >=20 >=20 Suggestions and feedback are appreciated! - m&m Matt Miller - Cisco Systems, Inc. > On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >=20 >> Hey John, >>=20 >> I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. >>=20 >> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>=20 >>> Hi Matt, >>>=20 >>> Complements on updating the draft. >>>=20 >>> The issue I see is that you are attempting to distribute the CMK out = of band and use "none" as the alg. >>>=20 >>> There has been a fair amount of discussion on this. In some earlier = JWE drafts before mandatory integrity you could directly encrypt/decrypt = with the out of band shared secret. >>>=20 >>> Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. =20 >>> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>>=20 >>> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>>=20 >>> So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>>=20 >>> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>>=20 >>> I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is = properly supported. >>>=20 >>> Regards >>> John B. --Apple-Mail-48--823440035 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMjIzNDEz NlowIwYJKoZIhvcNAQkEMRYEFE1GxA81iDYNO+LgoaKTxqCnS0jaMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBu+hPg4xP9QGQ5xpRBL9rOBYnecjKMnEEYfqc639pYH6IS3GT3qArGDoEQ qudtqMURMo6pZMW5pR5gVz4r0FyrVJeeGqsEeVK9+QPCG05U/3XDTHvG5hhGwo9X1K4vGb8anJsb 8JZX4EFi8u0Bqa9xUMt28B9LiQahctKxVB6xDpq1wZ6oMzx0aTwDUnKoFd/xEvNStOsRAT+2IItq QYsuCtMtirVL1khlszuAV395e2WVdQ1gDO08DmN19lXvRLUkeAORyvb+hS/z0CBVvzg/qF6egF6a LTzdFznoNoEyRr2ZjkRonqWH/TP5oh1J6vFAKLTRydbb2VmDSHo0/19RAAAAAAAA --Apple-Mail-48--823440035-- --Apple-Mail-49--823440014 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP5QKwAAoJEJq6Ou0cgrSPQjUH/RbxuxHKOQxPMS1sutfU3bm7 C6E5OlFrVLe8ZPa1MUESzYK2Pie7TScsCf/cF/90II/JRVhUFSw+cBYU7nV3FlOw bCc8U+UUIZpM+QKG+ah+fu4eBWEqfrPTkwym7ZADTViAPrae33pXnJCgU/M9FnEJ +5EnObk+lUWhrizRQwfbkdn1JLg7co/so272ag/lucrCYcCZMjgHL5DhTR4nzEcF avPglpzImZd62u/UqicPvPHbeF8DDbsRFwQRa+gdYEuxb/PqGx0uCPXQcGm/4vjj x1MOJrdAspG3gK19rVKuJNdEdq+loopIjdAvvd9vXsod34Xsthn86D0UnjyPDts= =IaA8 -----END PGP SIGNATURE----- --Apple-Mail-49--823440014-- From jbradley@mac.com Fri Jun 22 16:00:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0211E808D for ; Fri, 22 Jun 2012 16:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.465 X-Spam-Level: X-Spam-Status: No, score=-4.465 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjfsXV31tZGS for ; Fri, 22 Jun 2012 16:00:53 -0700 (PDT) Received: from nk11p04mm-asmtpout002.mac.com (nk11p04mm-asmtp002.mac.com [17.158.236.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8576A21F85F1 for ; Fri, 22 Jun 2012 16:00:53 -0700 (PDT) MIME-version: 1.0 Received: from [192.168.1.213] ([190.20.54.57]) by nk11p04mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M61006DTJX4C240@nk11p04mm-asmtp002.mac.com> for jose@ietf.org; Fri, 22 Jun 2012 23:00:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-06-22_06:2012-06-22, 2012-06-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1206220284 From: John Bradley Content-type: multipart/signed; boundary="Apple-Mail=_F45CF422-BD90-4E8A-9F3C-6BF12C0A6262"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 22 Jun 2012 19:00:30 -0400 References: <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> To: jose@ietf.org Message-id: <213C613D-3901-457D-91E3-FB961C785903@mac.com> X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Fri, 22 Jun 2012 16:50:26 -0700 Cc: Matt Miller Subject: [jose] I-D Action: draft-miller-xmpp-e2e-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: Fri, 22 Jun 2012 23:00:55 -0000 --Apple-Mail=_F45CF422-BD90-4E8A-9F3C-6BF12C0A6262 Content-Type: multipart/alternative; boundary="Apple-Mail=_AB045AE3-104F-4660-9A34-CD8A6FA7E979" --Apple-Mail=_AB045AE3-104F-4660-9A34-CD8A6FA7E979 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Richard, =20 Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" =20 I should also point out that the messages are transported in XML, and as = such, the addition of a JSON wrapper for the JWE probably is not useful = as it would need escaping anyway. By not sending the CMK as part of the = message, you get a small reduction in message size, but you increase the = number of separate key transport messages required. In any event it = has nothing to do with integrity protecting the header. =20 There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. =20 For the transmission of the messages, I can't see any reason to not use = the JWE spec as currently written. It certainly supports the use case = without modification. Matt's creative use of "none" as the algorithm is = not required and likely only requires a short conversation to sort out. =20 Currently the message on the wire looks like: =20
eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX NpemUiOiIxNiJ9
7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- eCGP =20 I would have sent header and data as one element using the normal JWE = dot separated format, but I need to talk to Matt to understand his = reasoning. =20 I note that his example is using AES-CCM, and so not documented in JWA. = That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. =20 I don't quite get your point on integrity protecting the wrapped key = causing the integrity value to change. For HMAC, GCM, and I think CCM, = changing the encryption key changes the tag value anyway (sort of the = point I thought). The only time it would stay the same would be if you = were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). =20 There are some interesting things Matt=92s spec is attempting with using = asymmetrically encrypted/signed JWE/JWS as a key transport protocol. I = need to go through that more closely. =20 I am happy to work with Matt to refine his ID. =20 I recommend others read it as well so we can understand if there are any = real issues. =20 Regards John B. On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: > Hey John, >=20 > I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. >=20 > This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >=20 > On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >=20 >> Hi Matt, >>=20 >> Complements on updating the draft. >>=20 >> The issue I see is that you are attempting to distribute the CMK out = of band and use "none" as the alg. >>=20 >> There has been a fair amount of discussion on this. In some earlier = JWE drafts before mandatory integrity you could directly encrypt/decrypt = with the out of band shared secret. >>=20 >> Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. =20 >> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>=20 >> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>=20 >> So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>=20 >> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>=20 >> I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is = properly supported. >>=20 >> Regards >> John B. >>=20 >>=20 >> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>=20 >>> FYI, a proposal for XMPP E2E, using JOSE. This has been updated to = the latest JOSE WG drafts. >>>=20 >>>=20 >>> - m&m >>>=20 >>> Matt Miller - >>> Cisco Systems, Inc. >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: June 22, 2012 07:00:24 MDT >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>> Reply-To: internet-drafts@ietf.org >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>=20 >>>>=20 >>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>> Author(s) : Matthew Miller >>>> Filename : draft-miller-xmpp-e2e-01.txt >>>> Pages : 22 >>>> Date : 2012-06-21 >>>>=20 >>>> Abstract: >>>> This document defines a method of end-to-end object encryption for >>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_AB045AE3-104F-4660-9A34-CD8A6FA7E979 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Richard,
 
Having = read Matt's spec, he is not breaking JWE to send to multiple recipients. =  As the spec says:
"This = document specifies an approach for encrypting communications between two = entities which each might have multiple end-points"
 
I should = also point out that the messages are transported in XML, and as such, = the addition of a JSON wrapper for the JWE probably is not useful as it = would need escaping anyway.  By not sending the CMK as part of the = message, you get a small reduction in message size, but you increase the = number of separate key transport messages required.   In any event = it has nothing to do with integrity protecting the header.
 
There = are two somewhat separate uses for JWE in the spec:  one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys.
 
For the = transmission of the messages, I can't see any reason to not use the JWE = spec as currently written.   It certainly supports the use case = without modification.  Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out.
 
Currently the message on the wire looks = like:
 
<message xmlns=3D'jabber:client'
            from=3D'juliet@capulet.lit/= balcony'
        =     id=3D'fJZd9WFIIwNjFctT'
to=3D'romeo@montegue.lit/gard= en'
          =   type=3D'chat'>
  =    <e2e xmlns=3D'urn:ietf:params:xml:ns:xmpp-e2e:2'
          = id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
      =  <header>
      =   =  eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS
        =  HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX
        =  NpemUiOiIxNiJ9
      =  </header>
      =  <data>
      =   =  7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO
        =  9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41
        =  wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME
        =  KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk
        =  RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0
        =  1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O
        =  LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg
        =  g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti
        =  JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7
        =  TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD
        =  MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g
        =  E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo-
        =  eCGP
      =  </data>
      =  <mac/>
    =  </e2e>
  =  </message>
 
I would have sent header and data as one = element using the normal JWE dot separated format, but I need to talk to = Matt to understand his reasoning.
I note that his example is = using AES-CCM, and so not documented in JWA.  That isn't a big deal = if we want to add it.  CCM supports extra authenticated data and = outputs an authentication tag like GCM.  In CMS RFC 5084, the tag = seems to be carried separately from the encrypted data and in RFC 3610, = the tag is concatenated to the encrypted data.   If we want to = support CCM, then we need to pick one of the ways to transport the tag = info.  Either would work.   We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the = ciphertext.
 
I don't quite get your point on integrity = protecting the wrapped key causing the integrity value to change.   = For HMAC, GCM, and I think CCM, changing the encryption key changes the = tag value anyway (sort of the point I thought).  The only time it = would stay the same would be if you were just using a MAC over the body = and that is a touch useless for integrity protection.  Perhaps I am = missing the point, but as far as I know even without protecting the = header, the tag value is different for every key (and = nonce/IV).
 
There are some interesting things Matt=92s = spec is attempting with using asymmetrically encrypted/signed JWE/JWS as = a key transport protocol.   I need to go through that more = closely.
 
I am happy to work with Matt to refine his = ID.
 
I = recommend others read it as well so we can understand if there are any = real issues.
 
Regards
John = B.
Hey = John,

I think you're missing the bigger point here, which is: In = order to allow for multiple recipients, Matt had to break = JWE.

This is yet another reason to abandon integrity protection = for cryptographic parameters.  Namely, it makes allowing for = multiple recipients much harder than it needs to be.  If you = integrity-protect the wrapped key, then you need to change the integrity = value whenever you wrap the key for a new recipient.  In addition = to increasing overhead in computing and communicating objects for = multiple recipients, now you've locked yourself out of algorithms that = don't have a separate integrity check value, such as = AES-CCM.

--Richard






On Jun 22, 2012, at = 12:12 PM, John Bradley wrote:

Hi = Matt,

Complements on = updating the draft.

The issue I see = is that you are attempting to distribute the CMK out of band and use = "none" as the alg.

There has been = a fair amount of discussion on this.  In some earlier JWE drafts = before mandatory integrity you could directly encrypt/decrypt with the = out of band shared secret.

Based on JSMS = and mandatory integrity we adopted having a CMK always included in the = message to allow for rotation.  
=46rom a implementation point of view the symmetric cypher = always gets the CEK derived from the CMK in the message independent of = if it is using RSA or A128KW/A256KW.

That imposes = some extra steps for people using symmetric keys but encourages rotation = of the CEK that would likely not happen = otherwise.

So in your spec = I would expect you to distribute a shared secret via keyreq for use in = A256KW and be using that decrypt the CMK at the = receiver.

I also suspect = that you intended to use A256GCM as the enc alg and not A256CCM. =

I am not a XMPP expert so it will take me some time to go = over it in detail.   I would like to understand the use case = to be certain it is properly supported.

Regards
John = B.


On 2012-06-22, = at 9:20 AM, Matt Miller wrote:

FYI, a proposal for XMPP E2E, using JOSE.  This has = been updated to the latest JOSE WG = drafts.


- = m&m

Matt Miller - <mamille2@cisco.com>
Cisco= Systems, Inc.

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /blockquote>
Date: = June 22, 2012 07:00:24 = MDT
To: i-d-announce@ietf.org
Subject: I-D Action: = draft-miller-xmpp-e2e-01.txt
Reply-To: internet-drafts@ietf.org
<= /blockquote>


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


Title =           : End-to-End = Object Encryption for the Extensible Messaging and Presence Protocol = (XMPP)
Author(s) =       : Matthew = Miller
Filename =        : = draft-miller-xmpp-e2e-01.txt
= Pages =           : = 22
Date =            : = 2012-06-21

Abstract:
This= document defines a method of end-to-end object encryption = for
the = Extensible Messaging and Presence Protocol = (XMPP).


The = IETF datatracker status page for this draft = is:
https://da= tatracker.ietf.org/doc/draft-miller-xmpp-e2e

There's = also a htmlized version available = at:
http://tools.= ietf.org/html/draft-miller-xmpp-e2e-01

A diff = from previous version is available = at:
htt= p://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01


Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-d= rafts/

_______________________________________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt

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

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


=
= --Apple-Mail=_AB045AE3-104F-4660-9A34-CD8A6FA7E979-- --Apple-Mail=_F45CF422-BD90-4E8A-9F3C-6BF12C0A6262 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy MjIzMDA0MFowIwYJKoZIhvcNAQkEMRYEFE4+1HI5kvBTwKN4eObbC/2HNUmjMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AERuANJEHCh1CcJOt20x/CRNlGKvlT/Z+lxtW4Y0wDWlvAw8NH8CMnp7Y0CU8UfU1zh5JkJTrdzX X8EX57i1s/Gefdf8uvSux8fJi6n+jPWcuqAC9E3b8aP3NuDE0CdS+W/jENvauGHun0EFPp56NjWj UgA47hPMTkFczUrjQQEl/GeIsnZ06OrhDQ3t1N2vmdDwD/x2ddCRrtKz5JsaDN78ML1qdatC5aOI Zazam7MyuIFqYzdyb4xMdPutJyyf9E/oTr6xVMbNXAOOCgjo0f8O48VnchXgyNdooM/60B9qMYvR 8qpb935xCDCp7vYggG7FHbUAO+VuOf05oHoalIYAAAAAAAA= --Apple-Mail=_F45CF422-BD90-4E8A-9F3C-6BF12C0A6262-- From mamille2@cisco.com Fri Jun 22 17: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 1EF5A11E8098 for ; Fri, 22 Jun 2012 17:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in30N2baFiR7 for ; Fri, 22 Jun 2012 17:16:11 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8A921F859A for ; Fri, 22 Jun 2012 17:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=14250; q=dns/txt; s=iport; t=1340410563; x=1341620163; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=8Rw7c83eZ5stKckGcWmFa34e4JlVT1nHTj+4JTfGRd4=; b=civ8DCu9R4lim9pi8ZNEeinwR2qQqFvKnLmy8XCMM3p4wm4RHqYFLQOR KsCxS1onsaPAbr6lFDbVYf14ZVQIS0mhEQktaQkL2665I2WHAGA/FAq+Z 9V/h5LYuqldpwsd1hvy6lOmHD0FqZIi15dX2eH0UulHKWIPEkzCljYcJn Q=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIQJ5U+Q/khM/2dsb2JhbAA9CLVngQeCGAEBAQMBEgFUBA4FCwsOCi4CVQYTIodkBZoxn2GLLhaFDGADiEeFfYM8gyyFVohFgWaCfoE3Bw X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="sig'?p7s'?scan'208";a="6127017" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 23 Jun 2012 00:16:02 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5N0G1t6018697; Sat, 23 Jun 2012 00:16:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-55--821370998" From: Matt Miller In-Reply-To: <6FC7B84E-8647-47A3-A664-8AF455F4AC8C@mac.com> Date: Fri, 22 Jun 2012 18:16:05 -0600 Message-Id: References: <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <213C613D-3901-457D-91E3-FB961C785903@mac.com> <6FC7B84E-8647-47A3-A664-8AF455F4AC8C@mac.com> To: John Bradley Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Sat, 23 Jun 2012 00:16:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-55--821370998 Content-Type: multipart/signed; boundary=Apple-Mail-54--821371011; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-54--821371011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 22, 2012, at 18:01, John Bradley wrote: > Sorry I sent this at the same time your reply went out. >=20 > So let me know if I have this correct: > 1 sender creates key and keyid. > 2 Sender encrypts message with key (or derived key)=20 > 3 Sender sends message=20 > 4 XMPP server distributes message to n endpoints (resources). > 5 one or more endpoints send there public key in key request messages = to sender based on the received keyid. > 6 sender sends back key encrypted with endpoint's public key to = endpoint. > 7 endpoint decrypts keyrequest and gets shared secret > 8 endpoint decrypts message with shared secret. >=20 That is the flow. I'll make that explicit in a future version of = -xmpp-e2e. > So the message to the endpoint arrives before the key negotiation. = Now I see why the client is requesting the symmetric key. > I will think about it. I don't see anything on the face of it that = should be an issue with JWE. >=20 > I don't quite get what stops an intermediate node from intercepting = the message and asking for the key, so there is more I need to learn. >=20 In XMPP, there's a certain amount of trust users put into their servers. = In SMTP it would be relatively trivial for Richard to send you messages = as me; In XMPP the bar is higher. Note that endpoint here means a specific resource for a user. The = intent here is the message is sent to a single user, but could be = multiplexed by the server to multiple clients for that user. Also, nothing stops a client from rejecting a keyreq because of some = outside factor (e.g. third-party clearing house, existing CA = infrastructure, etc). I will be in Vancouver, and would be happy to explain more about XMPP. > Thanks for the response. > John B. >=20 > On 2012-06-22, at 7:41 PM, Matt Miller wrote: >=20 >>=20 >> On Jun 22, 2012, at 17:00, John Bradley wrote: >>=20 >>> Hi Richard, >>>=20 >>> Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: >>> "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" >>>=20 >>> I should also point out that the messages are transported in XML, = and as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>=20 >>> There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>=20 >>> For the transmission of the messages, I can't see any reason to not = use the JWE spec as currently written. It certainly supports the use = case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>=20 >>=20 >> I'll ponder more on the key wrapping, as I said in another reply (-: >>=20 >>> Currently the message on the wire looks like: >>>=20 >>> >> from=3D'juliet@capulet.lit/balcony' >>> id=3D'fJZd9WFIIwNjFctT' >>> to=3D'romeo@montegue.lit/garden' >>> type=3D'chat'> >>> >> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>
>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>> NpemUiOiIxNiJ9 >>>
>>> >>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>> eCGP >>> >>> >>> >>> >>>=20 >>> I would have sent header and data as one element using the normal = JWE dot separated format, but I need to talk to Matt to understand his = reasoning. >>>=20 >>=20 >> The original rationale for not using dot-separated was because = originally (-00) I needed to parse the header before decrypting, to = determine what was missing. With the newer version (-01), it might not = still be necessary. >>=20 >>> I note that his example is using AES-CCM, and so not documented in = JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>>=20 >>=20 >> I personally don't care either way. At one point CCM was mentioned = on the list, so there might be desire there beyond my example. >>=20 >>> I don't quite get your point on integrity protecting the wrapped key = causing the integrity value to change. For HMAC, GCM, and I think CCM, = changing the encryption key changes the tag value anyway (sort of the = point I thought). The only time it would stay the same would be if you = were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >>>=20 >>> There are some interesting things Matt=92s spec is attempting with = using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>>=20 >>=20 >> I'll add the rationale to my next version. I think the presentations = in Paris by Richard (in JOSE) and myself (in XMPP) spell it out; in a = nutshell, a single message to a recipient (read: end user) can be = routed/multiplexed to multiple endpoints (resources in XMPP = nomenclature), including instances the sender is not aware of at the = moment of transmission. >>=20 >>> I am happy to work with Matt to refine his ID. >>>=20 >>> I recommend others read it as well so we can understand if there are = any real issues. >>>=20 >>>=20 >>=20 >> Suggestions and feedback are appreciated! >>=20 >>=20 >> - m&m >>=20 >> Matt Miller - >> Cisco Systems, Inc. >>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>=20 >>>> Hey John, >>>>=20 >>>> I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. >>>>=20 >>>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>=20 >>>>> Hi Matt, >>>>>=20 >>>>> Complements on updating the draft. >>>>>=20 >>>>> The issue I see is that you are attempting to distribute the CMK = out of band and use "none" as the alg. >>>>>=20 >>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>=20 >>>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>>> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>>>>=20 >>>>> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>>>>=20 >>>>> So in your spec I would expect you to distribute a shared secret = via keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>>>>=20 >>>>> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>>>>=20 >>>>> I am not a XMPP expert so it will take me some time to go over it = in detail. I would like to understand the use case to be certain it is = properly supported. >>>>>=20 >>>>> Regards >>>>> John B. >>=20 >=20 - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-54--821371011 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMzAwMTYw NVowIwYJKoZIhvcNAQkEMRYEFLfL819t7KdUIBVvcYN0Y0hBZU+FMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBs3CKEbzhxtiTgXgKbvC8q6I4mqN2ulYz7zv1X/Lioun3RlCH2DsUfE5ox fr2ExniH3uqW2N21xi7t6VsAcQx7lJc3QKXDHiBvfcUQ03GogWSG40Xe7vaqUTkEwk6+jiTa6EKX bXijiMZ4ezzWhTa4YGJpX946fKYy8XQcsIKkS8vMKW61eXeKt64KD3cmU8htKEvkldDvg9NEwga3 M1WknM/GuGY1hGh5sE35pM+KP7GhET8ixST8F0l5gF3YKst/DS2a58+5ciSJhKkw1C2TFgVINYHj bddOrmJiZuF887XbOkfZiPmYnFrF3QxXMI7q6ujmpq7p7qHkcOd/N5b5AAAAAAAA --Apple-Mail-54--821371011-- --Apple-Mail-55--821370998 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP5QrFAAoJEJq6Ou0cgrSP7HcIALp5w1y8cUcJSfZjjU+Ep7yt vksGpY8U3FlKVQmUOLJfXbnX2F8iZTdJJ1+ykn9aLSsGoVXap/GcYf2Syy+RZcbL 1UCGXmUB2SXGoed/6r/t6A3t2UgEBNdxTmGgVTKIhvv8djchuOXn6s98Y5ppisom 4AYngjxpTxug5u6AEakPcT77jICZgYtkUEqd/KJMqcCVoOu9x+8k7KHezQhbyBSy pu4QaAYSC1ObeefGrkeiBCMeDZnb1sfzJxXj4M+t19iUOov/4uWvhJ2eDvlIXkMI xQ6RyAXPQzYdc3MrTALHzu/HeO8OnbFMWeqj4jFgsueRg9M+o+tFO7iH046X0tU= =QPXx -----END PGP SIGNATURE----- --Apple-Mail-55--821370998-- From Michael.Jones@microsoft.com Fri Jun 22 18:47: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 4119721F8541 for ; Fri, 22 Jun 2012 18:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.408 X-Spam-Level: X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQJAE4ouUf1x for ; Fri, 22 Jun 2012 18:47:49 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFAD21F8540 for ; Fri, 22 Jun 2012 18:47:49 -0700 (PDT) Received: from mail100-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Sat, 23 Jun 2012 01:46:17 +0000 Received: from mail100-tx2 (localhost [127.0.0.1]) by mail100-tx2-R.bigfish.com (Postfix) with ESMTP id C6D78E05FD; Sat, 23 Jun 2012 01:46:17 +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: -19 X-BigFish: VS-19(zzbb2dI98dI9371I936eIc85eh1432I1447Ib975ozz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail100-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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail100-tx2 (localhost.localdomain [127.0.0.1]) by mail100-tx2 (MessageSwitch) id 1340415975848033_18127; Sat, 23 Jun 2012 01:46:15 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.250]) by mail100-tx2.bigfish.com (Postfix) with ESMTP id BF7C046004F; Sat, 23 Jun 2012 01:46:15 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 23 Jun 2012 01:46:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Sat, 23 Jun 2012 01:47:44 +0000 From: Mike Jones To: Matt Miller , John Bradley Thread-Topic: [jose] I-D Action: draft-miller-xmpp-e2e-01.txt Thread-Index: AQHNUNVhz8HbC1aerkKGwJGvIN3d9ZcHIrNK Date: Sat, 23 Jun 2012 01:47:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656576B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <213C613D-3901-457D-91E3-FB961C785903@mac.com> <6FC7B84E-8647-47A3-A664-8AF455F4AC8C@mac.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436656576BTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Sat, 23 Jun 2012 01:47:51 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436656576BTK5EX14MBXC283r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'd be glad to be part of the XMPP discussion as well to better understand = your use case. See you in Vancouver... -- Mike ________________________________ From: Matt Miller Sent: 6/22/2012 5:17 PM To: John Bradley Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-01.txt On Jun 22, 2012, at 18:01, John Bradley wrote: > Sorry I sent this at the same time your reply went out. > > So let me know if I have this correct: > 1 sender creates key and keyid. > 2 Sender encrypts message with key (or derived key) > 3 Sender sends message > 4 XMPP server distributes message to n endpoints (resources). > 5 one or more endpoints send there public key in key request messages to = sender based on the received keyid. > 6 sender sends back key encrypted with endpoint's public key to endpoint. > 7 endpoint decrypts keyrequest and gets shared secret > 8 endpoint decrypts message with shared secret. > That is the flow. I'll make that explicit in a future version of -xmpp-e2e= . > So the message to the endpoint arrives before the key negotiation. Now = I see why the client is requesting the symmetric key. > I will think about it. I don't see anything on the face of it that sho= uld be an issue with JWE. > > I don't quite get what stops an intermediate node from intercepting the m= essage and asking for the key, so there is more I need to learn. > In XMPP, there's a certain amount of trust users put into their servers. I= n SMTP it would be relatively trivial for Richard to send you messages as m= e; In XMPP the bar is higher. Note that endpoint here means a specific resource for a user. The intent h= ere is the message is sent to a single user, but could be multiplexed by th= e server to multiple clients for that user. Also, nothing stops a client from rejecting a keyreq because of some outsid= e factor (e.g. third-party clearing house, existing CA infrastructure, etc)= . I will be in Vancouver, and would be happy to explain more about XMPP. > Thanks for the response. > John B. > > On 2012-06-22, at 7:41 PM, Matt Miller wrote: > >> >> On Jun 22, 2012, at 17:00, John Bradley wrote: >> >>> Hi Richard, >>> >>> Having read Matt's spec, he is not breaking JWE to send to multiple rec= ipients. As the spec says: >>> "This document specifies an approach for encrypting communications betw= een two entities which each might have multiple end-points" >>> >>> I should also point out that the messages are transported in XML, and a= s such, the addition of a JSON wrapper for the JWE probably is not useful a= s it would need escaping anyway. By not sending the CMK as part of the mes= sage, you get a small reduction in message size, but you increase the numbe= r of separate key transport messages required. In any event it has nothin= g to do with integrity protecting the header. >>> >>> There are two somewhat separate uses for JWE in the spec: one for encr= ypting the messages themselves using symmetric keys, and another using asym= metric keys for requesting symmetric keys. >>> >>> For the transmission of the messages, I can't see any reason to not use= the JWE spec as currently written. It certainly supports the use case wi= thout modification. Matt's creative use of "none" as the algorithm is not = required and likely only requires a short conversation to sort out. >>> >> >> I'll ponder more on the key wrapping, as I said in another reply (-: >> >>> Currently the message on the wire looks like: >>> >>> >> from=3D'juliet@capulet.lit/balcony' >>> id=3D'fJZd9WFIIwNjFctT' >>> to=3D'romeo@montegue.lit/garden' >>> type=3D'chat'> >>> >> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>
>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>> NpemUiOiIxNiJ9 >>>
>>> >>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>> eCGP >>> >>> >>> >>> >>> >>> I would have sent header and data as one element using the normal JWE d= ot separated format, but I need to talk to Matt to understand his reasoning= . >>> >> >> The original rationale for not using dot-separated was because originall= y (-00) I needed to parse the header before decrypting, to determine what w= as missing. With the newer version (-01), it might not still be necessary. >> >>> I note that his example is using AES-CCM, and so not documented in JWA.= That isn't a big deal if we want to add it. CCM supports extra authentic= ated data and outputs an authentication tag like GCM. In CMS RFC 5084, the= tag seems to be carried separately from the encrypted data and in RFC 3610= , the tag is concatenated to the encrypted data. If we want to support CC= M, then we need to pick one of the ways to transport the tag info. Either = would work. We would just need to define that the integrity element conta= ins a zero byte string as Matt has, if we want to concatenate the integrity= tag value after the ciphertext. >>> >> >> I personally don't care either way. At one point CCM was mentioned on t= he list, so there might be desire there beyond my example. >> >>> I don't quite get your point on integrity protecting the wrapped key ca= using the integrity value to change. For HMAC, GCM, and I think CCM, chan= ging the encryption key changes the tag value anyway (sort of the point I t= hought). The only time it would stay the same would be if you were just us= ing a MAC over the body and that is a touch useless for integrity protectio= n. Perhaps I am missing the point, but as far as I know even without prote= cting the header, the tag value is different for every key (and nonce/IV). >>> >>> There are some interesting things Matt=92s spec is attempting with usin= g asymmetrically encrypted/signed JWE/JWS as a key transport protocol. I = need to go through that more closely. >>> >> >> I'll add the rationale to my next version. I think the presentations in= Paris by Richard (in JOSE) and myself (in XMPP) spell it out; in a nutshel= l, a single message to a recipient (read: end user) can be routed/multiplex= ed to multiple endpoints (resources in XMPP nomenclature), including instan= ces the sender is not aware of at the moment of transmission. >> >>> I am happy to work with Matt to refine his ID. >>> >>> I recommend others read it as well so we can understand if there are an= y real issues. >>> >>> >> >> Suggestions and feedback are appreciated! >> >> >> - m&m >> >> Matt Miller - >> Cisco Systems, Inc. >>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>> >>>> Hey John, >>>> >>>> I think you're missing the bigger point here, which is: In order to al= low for multiple recipients, Matt had to break JWE. >>>> >>>> This is yet another reason to abandon integrity protection for cryptog= raphic parameters. Namely, it makes allowing for multiple recipients much = harder than it needs to be. If you integrity-protect the wrapped key, then= you need to change the integrity value whenever you wrap the key for a new= recipient. In addition to increasing overhead in computing and communicat= ing objects for multiple recipients, now you've locked yourself out of algo= rithms that don't have a separate integrity check value, such as AES-CCM. >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>> >>>>> Hi Matt, >>>>> >>>>> Complements on updating the draft. >>>>> >>>>> The issue I see is that you are attempting to distribute the CMK out = of band and use "none" as the alg. >>>>> >>>>> There has been a fair amount of discussion on this. In some earlier = JWE drafts before mandatory integrity you could directly encrypt/decrypt wi= th the out of band shared secret. >>>>> >>>>> Based on JSMS and mandatory integrity we adopted having a CMK always = included in the message to allow for rotation. >>>>> From a implementation point of view the symmetric cypher always gets = the CEK derived from the CMK in the message independent of if it is using R= SA or A128KW/A256KW. >>>>> >>>>> That imposes some extra steps for people using symmetric keys but enc= ourages rotation of the CEK that would likely not happen otherwise. >>>>> >>>>> So in your spec I would expect you to distribute a shared secret via = keyreq for use in A256KW and be using that decrypt the CMK at the receiver. >>>>> >>>>> I also suspect that you intended to use A256GCM as the enc alg and no= t A256CCM. >>>>> >>>>> I am not a XMPP expert so it will take me some time to go over it in = detail. I would like to understand the use case to be certain it is prope= rly supported. >>>>> >>>>> Regards >>>>> John B. >> > - m&m Matt Miller - Cisco Systems, Inc. --_000_4E1F6AAD24975D4BA5B16804296739436656576BTK5EX14MBXC283r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I'd be glad t= o be part of the XMPP discussion as well to better understand your use case= .  See you in Vancouver...

-- Mike

From: Matt M= iller
Sent: 6/22/2= 012 5:17 PM
To: John B= radley
Cc: jose@i= etf.org
Subject: Re: [j= ose] I-D Action: draft-miller-xmpp-e2e-01.txt


On Jun 22, 2012, at 18:01, John Bradley wrote:

> Sorry I sent this at the same time your reply went out.
>
> So let me know if I have this correct:
> 1 sender creates key and keyid.
> 2 Sender encrypts message with key (or derived key)
> 3 Sender sends message
> 4 XMPP server distributes message to n endpoints (resources).
> 5 one or more endpoints send there public key in key request messages = to sender based on the received keyid.
> 6 sender sends back key encrypted with endpoint's public key to endpoi= nt.
> 7 endpoint decrypts keyrequest and gets shared secret
> 8 endpoint decrypts message with shared secret.
>

That is the flow.  I'll make that explicit in a future version of -xmp= p-e2e.

> So the message to the endpoint arrives before the key negotiation.&nbs= p;  Now I see why the client is requesting the symmetric key.
> I will think about it.    I don't see anything on the f= ace of it that should be an issue with JWE.
>
> I don't quite get what stops an intermediate node from intercepting th= e message and asking for the key, so there is more I need to learn.
>

In XMPP, there's a certain amount of trust users put into their servers.&nb= sp; In SMTP it would be relatively trivial for Richard to send you messages= as me; In XMPP the bar is higher.

Note that endpoint here means a specific resource for a user.  The int= ent here is the message is sent to a single user, but could be multiplexed = by the server to multiple clients for that user.

Also, nothing stops a client from rejecting a keyreq because of some outsid= e factor (e.g. third-party clearing house, existing CA infrastructure, etc)= .

I will be in Vancouver, and would be happy to explain more about XMPP.

> Thanks for the response.
> John B.
>
> On 2012-06-22, at 7:41 PM, Matt Miller wrote:
>
>>
>> On Jun 22, 2012, at 17:00, John Bradley wrote:
>>
>>> Hi Richard,
>>>
>>> Having read Matt's spec, he is not breaking JWE to send to mul= tiple recipients.  As the spec says:
>>> "This document specifies an approach for encrypting commu= nications between two entities which each might have multiple end-points&qu= ot;
>>>
>>> I should also point out that the messages are transported in X= ML, and as such, the addition of a JSON wrapper for the JWE probably is not= useful as it would need escaping anyway.  By not sending the CMK as p= art of the message, you get a small reduction in message size, but you increase the number of separate key transport mes= sages required.   In any event it has nothing to do with integrit= y protecting the header.
>>>
>>> There are two somewhat separate uses for JWE in the spec: = ; one for encrypting the messages themselves using symmetric keys, and anot= her using asymmetric keys for requesting symmetric keys.
>>>
>>> For the transmission of the messages, I can't see any reason t= o not use the JWE spec as currently written.   It certainly suppo= rts the use case without modification.  Matt's creative use of "n= one" as the algorithm is not required and likely only requires a short conversation to sort out.
>>>
>>
>> I'll ponder more on the key wrapping, as I said in another reply (= -:
>>
>>> Currently the message on the wire looks like:
>>>
>>> <message xmlns=3D'jabber:client'
>>>          from=3D'= juliet@capulet.lit/balcony'
>>>          id=3D'fJ= Zd9WFIIwNjFctT'
>>>          to=3D'ro= meo@montegue.lit/garden'
>>>          type=3D'= chat'>
>>>   <e2e xmlns=3D'urn:ietf:params:xml:ns:xmpp-e2e:2= '
>>>        id=3D'835c92a8-94cd-= 4e96-b3f3-b2e75a438f92'>
>>>     <header>
>>>       eyJlbmMiOiJBMjU2Q0NNIiwiaX= YiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS
>>>       HJBPT0iLCJhZGF0YSI6IjQ5Mi0= wNS0xMlQyMDowNzozNy4wMTJaIiwibX
>>>       NpemUiOiIxNiJ9
>>>     </header>
>>>     <data>
>>>       7LlMXd-qqPAQ_LZm6u9AR2csyD= gT09z5DWdn8K5GLr_qbWRDKw2ufZrmO
>>>       9YZ-jHl1IDeXeQ9azbNNViv8gp= a-prDYkXOo3QoqYOJiA0RAkPU-UjN41
>>>       wqqVvV62gad_OBDd9q2xsNnK1P= I5frIGTCZSexOIeSD3EcP0cDI_0MzME
>>>       KqpVnPbYQDkWQNrtxPs2blE15K= cQXbHVxA9rEz7y0a-ITXruV_fOXGftk
>>>       RVDuiF1yVh2xNRPa-TQxDegZh1= D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0
>>>       1YGtDDQeyzrQWnQNEBJ4G5jFpC= yqtCszbgx9kjWjxLYNLLGxbMOtwF45O
>>>       LCd8JFUIQAHoLeKp4aIWr5yp7a= ATX8dKvQm5_TFICtnLonaM1e5mRPnRg
>>>       g5zNeMErx6FFkqowOI1h7hVl_Q= HF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti
>>>       JMHnAEn2Q-10-fWuIHIEA0u4Gw= BaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7
>>>       TL-5jwSuuQHX6efS8Hhi7fujmq= w9VXekeubsY2btl5put0SWT8_0S8ZBD
>>>       MjrkXjy7iI5NUOhQMms3ou1r01= NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g
>>>       E_HalWUL0HoqL93Fr1nfFLNhXL= CZYhZ7By6T9NN8omp4ZYE92HMpPzgo-
>>>       eCGP
>>>     </data>
>>>     <mac/>
>>>   </e2e>
>>> </message>
>>>
>>> I would have sent header and data as one element using the nor= mal JWE dot separated format, but I need to talk to Matt to understand his = reasoning.
>>>
>>
>> The original rationale for not using dot-separated was because ori= ginally (-00) I needed to parse the header before decrypting, to determine = what was missing.  With the newer version (-01), it might not still be= necessary.
>>
>>> I note that his example is using AES-CCM, and so not documente= d in JWA.  That isn't a big deal if we want to add it.  CCM suppo= rts extra authenticated data and outputs an authentication tag like GCM.&nb= sp; In CMS RFC 5084, the tag seems to be carried separately from the encrypted data and in RFC 3610, the tag is concatenated to the en= crypted data.   If we want to support CCM, then we need to pick o= ne of the ways to transport the tag info.  Either would work. &nb= sp; We would just need to define that the integrity element contains a zero byte string as Matt has, if we want to concatenate the int= egrity tag value after the ciphertext.
>>>
>>
>> I personally don't care either way.  At one point CCM was men= tioned on the list, so there might be desire there beyond my example.
>>
>>> I don't quite get your point on integrity protecting the wrapp= ed key causing the integrity value to change.   For HMAC, GCM, an= d I think CCM, changing the encryption key changes the tag value anyway (so= rt of the point I thought).  The only time it would stay the same would be if you were just using a MAC over the body and that= is a touch useless for integrity protection.  Perhaps I am missing th= e point, but as far as I know even without protecting the header, the tag v= alue is different for every key (and nonce/IV).
>>>
>>> There are some interesting things Matt=92s spec is attempting = with using asymmetrically encrypted/signed JWE/JWS as a key transport proto= col.   I need to go through that more closely.
>>>
>>
>> I'll add the rationale to my next version.  I think the prese= ntations in Paris by Richard (in JOSE) and myself (in XMPP) spell it out; i= n a nutshell, a single message to a recipient (read: end user) can be route= d/multiplexed to multiple endpoints (resources in XMPP nomenclature), including instances the sender is not aware of at t= he moment of transmission.
>>
>>> I am happy to work with Matt to refine his ID.
>>>
>>> I recommend others read it as well so we can understand if the= re are any real issues.
>>>
>>>
>>
>> Suggestions and feedback are appreciated!
>>
>>
>> - m&m
>>
>> Matt Miller - <mamille2@cisco.com>
>> Cisco Systems, Inc.
>>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote:
>>>
>>>> Hey John,
>>>>
>>>> I think you're missing the bigger point here, which is: In= order to allow for multiple recipients, Matt had to break JWE.
>>>>
>>>> This is yet another reason to abandon integrity protection= for cryptographic parameters.  Namely, it makes allowing for multiple= recipients much harder than it needs to be.  If you integrity-protect= the wrapped key, then you need to change the integrity value whenever you wrap the key for a new recipient.  In addition to = increasing overhead in computing and communicating objects for multiple rec= ipients, now you've locked yourself out of algorithms that don't have a sep= arate integrity check value, such as AES-CCM.
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote:
>>>>
>>>>> Hi Matt,
>>>>>
>>>>> Complements on updating the draft.
>>>>>
>>>>> The issue I see is that you are attempting to distribu= te the CMK out of band and use "none" as the alg.
>>>>>
>>>>> There has been a fair amount of discussion on this.&nb= sp; In some earlier JWE drafts before mandatory integrity you could directl= y encrypt/decrypt with the out of band shared secret.
>>>>>
>>>>> Based on JSMS and mandatory integrity we adopted havin= g a CMK always included in the message to allow for rotation. 
>>>>> From a implementation point of view the symmetric cyph= er always gets the CEK derived from the CMK in the message independent of i= f it is using RSA or A128KW/A256KW.
>>>>>
>>>>> That imposes some extra steps for people using symmetr= ic keys but encourages rotation of the CEK that would likely not happen oth= erwise.
>>>>>
>>>>> So in your spec I would expect you to distribute a sha= red secret via keyreq for use in A256KW and be using that decrypt the CMK a= t the receiver.
>>>>>
>>>>> I also suspect that you intended to use A256GCM as the= enc alg and not A256CCM.
>>>>>
>>>>> I am not a XMPP expert so it will take me some time to= go over it in detail.   I would like to understand the use case = to be certain it is properly supported.
>>>>>
>>>>> Regards
>>>>> John B.
>>
>


- m&m

Matt Miller - <mamille2@cisco.com>
Cisco Systems, Inc.

 --_000_4E1F6AAD24975D4BA5B16804296739436656576BTK5EX14MBXC283r_-- From ietf@augustcellars.com Sat Jun 23 15:05: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 5CC8A21F860F for ; Sat, 23 Jun 2012 15:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwOe7drL+SXl for ; Sat, 23 Jun 2012 15:05:19 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF321F8615 for ; Sat, 23 Jun 2012 15:05:19 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (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 6FCF938F20 for ; Sat, 23 Jun 2012 15:05:19 -0700 (PDT) From: "Jim Schaad" To: References: <20120623220210.22320.33157.idtracker@ietfa.amsl.com> In-Reply-To: <20120623220210.22320.33157.idtracker@ietfa.amsl.com> Date: Sat, 23 Jun 2012 15:04:02 -0700 Message-ID: <020901cd518c$1a9b0250$4fd106f0$@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: AQLjKMjNdatpA8D+xFgHtqHXxeiC0ZTcxlxg Content-Language: en-us Subject: [jose] FW: New Version Notification for draft-schaad-jose-serialize-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:05:20 -0000 Yet another strawman draft that looks at the serialization issues. This = document changes some things and provides a new serialization for = dealing with either single or multiple recipients or signers. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Saturday, June 23, 2012 3:02 PM > To: ietf@augustcellars.com > Subject: New Version Notification for = draft-schaad-jose-serialize-00.txt >=20 >=20 > A new version of I-D, draft-schaad-jose-serialize-00.txt > has been successfully submitted by Jim Schaad and posted to the IETF > repository. >=20 > Filename: draft-schaad-jose-serialize > Revision: 00 > Title: JOSE Serialization Proposal for Multiple People > Creation date: 2012-06-23 > WG ID: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-schaad-jose-serialize- > 00.txt > Status: = http://datatracker.ietf.org/doc/draft-schaad-jose-serialize > Htmlized: = http://tools.ietf.org/html/draft-schaad-jose-serialize-00 >=20 >=20 > Abstract: > This is a fast proposal for doing serialization of JOSE signature, > authentication and encryption formats. >=20 >=20 >=20 >=20 > The IETF Secretariat From ve7jtb@ve7jtb.com Sat Jun 23 17:45: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 AAE5021F8681 for ; Sat, 23 Jun 2012 17:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APl67wsquO-E for ; Sat, 23 Jun 2012 17:45:46 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B82C21F8680 for ; Sat, 23 Jun 2012 17:45:46 -0700 (PDT) Received: by yenq13 with SMTP id q13so2480891yen.31 for ; Sat, 23 Jun 2012 17:45:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer:x-gm-message-state; bh=3fBZlUs4RXLkzPS5HnPxI6a/oLskzwGKhmWtEasSeWA=; b=dWr50QTNk52CKvyBM2BFVNPQlrmzXBWJDElLjwE8UQGMe29aFIc6rxCK0U1BHw75zT bj50rEQJlHtQgqOPB4Sd9R+69EVAQRELcFZgIWzDaQ6fVaZyMAwsAyesV0evPs7trhRd mg2sNslX4jPlKipMdf8Uqs9IBqNlZgWppNcxK3ONdQmT14b0Vc7mOGlgRiy+O6GTcblM jqLOykLEe7/lN8SqSkYBLSW5RbcMjp4um3HBzccFEX/fiLiGilc77UPAoiX2PA88UjC7 k9jA2bzzMOqG/o0jRPDZn7RQaNOUfYS+/gH5gydjJeFOVc2NVq88v5KZt8ZkQE85OLDu NV+g== Received: by 10.236.154.69 with SMTP id g45mr7932281yhk.47.1340498746162; Sat, 23 Jun 2012 17:45:46 -0700 (PDT) Received: from [192.168.1.213] (190-20-11-217.baf.movistar.cl. [190.20.11.217]) by mx.google.com with ESMTPS id w61sm124110115yhi.5.2012.06.23.17.45.41 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 17:45:44 -0700 (PDT) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_DEDD8005-1280-4694-A6F2-20CED72C3E30"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sat, 23 Jun 2012 20:45:31 -0400 References: <6FC7B84E-8647-47A3-A664-8AF455F4AC8C@mac.com> To: jose@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkIx17bQVC3+TyUmUxoBH0S0XoF88P3d7ElTON9ziwO2obZAdVBZ9LgzTkTpbVWYKPolHSn Subject: [jose] Fwd: I-D Action: draft-miller-xmpp-e2e-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: Sun, 24 Jun 2012 00:45:47 -0000 --Apple-Mail=_DEDD8005-1280-4694-A6F2-20CED72C3E30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry I sent this at the same time your reply went out. So let me know if I have this correct: 1 sender creates key and keyid. 2 Sender encrypts message with key (or derived key)=20 3 Sender sends message=20 4 XMPP server distributes message to n endpoints (resources). 5 one or more endpoints send there public key in key request messages to = sender based on the received keyid. 6 sender sends back key encrypted with endpoint's public key to = endpoint. 7 endpoint decrypts keyrequest and gets shared secret 8 endpoint decrypts message with shared secret. So the message to the endpoint arrives before the key negotiation. Now = I see why the client is requesting the symmetric key. I will think about it. I don't see anything on the face of it that = should be an issue with JWE. I don't quite get what stops an intermediate node from intercepting the = message and asking for the key, so there is more I need to learn. Thanks for the response. John B. On 2012-06-22, at 7:41 PM, Matt Miller wrote: >=20 > On Jun 22, 2012, at 17:00, John Bradley wrote: >=20 >> Hi Richard, >>=20 >> Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: >> "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" >>=20 >> I should also point out that the messages are transported in XML, and = as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>=20 >> There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>=20 >> For the transmission of the messages, I can't see any reason to not = use the JWE spec as currently written. It certainly supports the use = case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>=20 >=20 > I'll ponder more on the key wrapping, as I said in another reply (-: >=20 >> Currently the message on the wire looks like: >>=20 >> > from=3D'juliet@capulet.lit/balcony' >> id=3D'fJZd9WFIIwNjFctT' >> to=3D'romeo@montegue.lit/garden' >> type=3D'chat'> >> > id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>
>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >> NpemUiOiIxNiJ9 >>
>> >> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >> eCGP >> >> >> >> >>=20 >> I would have sent header and data as one element using the normal JWE = dot separated format, but I need to talk to Matt to understand his = reasoning. >>=20 >=20 > The original rationale for not using dot-separated was because = originally (-00) I needed to parse the header before decrypting, to = determine what was missing. With the newer version (-01), it might not = still be necessary. >=20 >> I note that his example is using AES-CCM, and so not documented in = JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>=20 >=20 > I personally don't care either way. At one point CCM was mentioned on = the list, so there might be desire there beyond my example. >=20 >> I don't quite get your point on integrity protecting the wrapped key = causing the integrity value to change. For HMAC, GCM, and I think CCM, = changing the encryption key changes the tag value anyway (sort of the = point I thought). The only time it would stay the same would be if you = were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >>=20 >> There are some interesting things Matt=92s spec is attempting with = using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>=20 >=20 > I'll add the rationale to my next version. I think the presentations = in Paris by Richard (in JOSE) and myself (in XMPP) spell it out; in a = nutshell, a single message to a recipient (read: end user) can be = routed/multiplexed to multiple endpoints (resources in XMPP = nomenclature), including instances the sender is not aware of at the = moment of transmission. >=20 >> I am happy to work with Matt to refine his ID. >>=20 >> I recommend others read it as well so we can understand if there are = any real issues. >>=20 >>=20 >=20 > Suggestions and feedback are appreciated! >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>=20 >>> Hey John, >>>=20 >>> I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. >>>=20 >>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>=20 >>>> Hi Matt, >>>>=20 >>>> Complements on updating the draft. >>>>=20 >>>> The issue I see is that you are attempting to distribute the CMK = out of band and use "none" as the alg. >>>>=20 >>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>=20 >>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>>>=20 >>>> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>>>=20 >>>> So in your spec I would expect you to distribute a shared secret = via keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>>>=20 >>>> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>>>=20 >>>> I am not a XMPP expert so it will take me some time to go over it = in detail. I would like to understand the use case to be certain it is = properly supported. >>>>=20 >>>> Regards >>>> John B. >=20 --Apple-Mail=_DEDD8005-1280-4694-A6F2-20CED72C3E30 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NDAwNDUzMlowIwYJKoZIhvcNAQkEMRYEFOt/TttULp/SvUlERFDGArQY5JRIMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AABahCB2aDOoUSjgSq1s4irHP0Tt+rlzNHY/C0b/KNU6f8JkMqWtDJbX9rXwQQcuVQqv2CeVF53s zpIiNOcQRIpeyZjqRejDJ2Wlt5jP0W9tOCCo/lfmXDSsWdZ022ybnaDqDhoX5P6MDQ3CCvOVyu+i PF8v5zmUGMNu6/SYraSptZ5kL8+LvheOp+OPELjX/DhiAoS0UbEWZZsQdkYPg222BibZApkHSVHs MJXDyu8Mvfvf5uSLaVzUIBapLVMWz4i8KO37sN/pKTjze5/cUCkrw488SXQlE0xBFrP6vny5n4cM jKvzhAD1KIcS0XKbAJt3aqi/nof9KP+ZReMNuwUAAAAAAAA= --Apple-Mail=_DEDD8005-1280-4694-A6F2-20CED72C3E30-- From rbarnes@bbn.com Mon Jun 25 14:34: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 C97EA11E80A4 for ; Mon, 25 Jun 2012 14:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcBFrS0YyuZd for ; Mon, 25 Jun 2012 14:34:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 22A3511E808C for ; Mon, 25 Jun 2012 14:34:44 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:56139) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjGv3-000Nit-D1; Mon, 25 Jun 2012 17:34:01 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Mon, 25 Jun 2012 17:34:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 21:34:46 -0000 Hi Nat,=20 I'm not sure what X.509 fiasco you're referring to. There was a recent = MD5 fiasco [1], but that's an attack on MD5, not X.509. In fact, there = have been recommendations for preventing this attack in X.509 since 2005 = [2]. As was noted on the SAAG list, the real news here is that = Microsoft wasn't following any of those recommendations. JWS would have had the same problem as X.509. The attack did not modify = the cryptographic parameters (anything that would have gone in the = header), it would not have been thwarted by the integrity protection = we're worrying about. =20 Actually, the header signing that JWS does makes it even nicer for the = attacker: Flame used a "chosen prefix" attack, so since the JWS header = value is entirely static for a given signer, it's easy to use as a fixed = prefix. If JWS just signed the content, then the application could = include a something random up front to prevent such prefix-based = attacks. It's tempting to say that we should just add randomness to the JOSE = format. But the real lesson of the Flame/MD5 attacks is operational: = If you're signing something that somebody else gave you, make sure that = you're not signing exactly what they gave you. Follow the = recommendations of RFC 4270. In other contexts, there's no need of = similar random elements; it just adds complexity. =20 --Richard [1] [2] On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: > Especially after the X.509 fiasco, I strongly believe that having = integrity check over the metadata is a good thing. It is such a little = effort that gives us much more protection down the road. In this sense, = I fully agree with Ben here. We should have integrity protection over = the header.=20 >=20 > Nat >=20 > On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones = wrote: > Two years ago when the developer community needing a JSON-friendly = token format was designing the JSON Web Token (JWT), we explicitly asked = security experts whether the header parameters should be integrity = protected or not. Among them, Ben Laurie was one of the voices saying = that securing them was the right thing to do. >=20 > =20 >=20 > He argued that if the parameters can be protected in a practical = manner, then they should. Doing so provides an additional hurdle that = attackers would have to surmount. For example, if they can try to = substitute a weaker authentication scheme, then they must figure out how = to make it authenticate correctly despite some plaintext they can't = control =96 the header parameters. >=20 > =20 >=20 > Ben also took the position that paring security protocols down to the = least you can get away with, given attacks you can think of, is not a = good design principle. If there is not a strong argument against = including a feature that may make it harder for attackers, then that = feature should be included. >=20 > =20 >=20 > I agree with him. >=20 > =20 >=20 > The decision to provide integrity protection for the headers is = documented in the session notes at http://self-issued.info/?p=3D361, = which said: >=20 > =20 >=20 > =B7 What to sign (envelope.payload or just payload)? >=20 > Given that the envelope is extensible and therefore may contain = security-sensitive information, we reached a consensus (with input from = Ben Laurie via IM) that the combination envelope.payload must be signed. > =20 >=20 > I believe that logic is as sound today as it was then. >=20 > =20 >=20 > For all these reasons, I therefore personally stand by the community=92s= decision to provide integrity protection for the headers. >=20 > =20 >=20 > Best = wishes, >=20 > -- Mike >=20 > =20 >=20 >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of John Bradley > Sent: Wednesday, June 20, 2012 3:57 PM > To: Richard L.Barnes > Cc: jose@ietf.org > Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > =20 >=20 > Hi Richard, >=20 > =20 >=20 > While for PKCS 1.5 the hash algorithm is baked into the padding and = not susceptible to modification with ECDH or RSA-PSS it is not. >=20 > There are possible hash truncation attacks by shortening SHA256 to = SHA224 as an example (I know we preclude truncated hashes at the = moment). >=20 > =20 >=20 > The bad feeling I get around this is that if there is a scenario where = the attacker controls the plaintext to be signed and there is no signer = controlled text contributed there are potential bad things that could = happen down the road. >=20 > =20 >=20 > This bit us with x509 certs not that long ago (yes with MD5 = admittedly) where the attacker could use a certificate extension to = include extra data and cause a pre collided hash to be generated. >=20 > Having part of the signed data outside the control of an attacker is a = good thing. (having a nonce or message ID in the envelope is possible = though not yet required in JWS.) >=20 > =20 >=20 > I am still of the opinion that putting the base64 encoded envelope = inside the hash calculation is a valid way to allow additional = attributes.=20 >=20 > Another structure to hold the attributes adds more complexity, as = would saying that they need to be inside the signed object. >=20 > =20 >=20 > I think part of this is that as one of the openID Connect authors I = look at this as a necessary security token format, for OAuth and = Connect.=20 >=20 > For that simple processing with one signature is a high priority for = adoption. >=20 > =20 >=20 > =46rom a general signing/encrypting of documents point of view you = legitimately have different priorities. >=20 > =20 >=20 > I know it is hard to prove a negative but It is also going to be = difficult for me to go back to security people at google Facebook and = other places and explain how not integrity protecting the header could = be better than integrity protecting it. >=20 > =20 >=20 > It seems that I would be reduced to arguing that this is no worse than = CMS and that hasn't been proven insecure yet. =20 >=20 > =20 >=20 > Allowing a possible attacker to control the hash output, and not = integrity protecting the additional data, seems like something I am = bound to regret in the future. >=20 > =20 >=20 > Regards >=20 > John B. >=20 > =20 >=20 > On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >=20 > =20 >=20 > > Hey John, >=20 > > >=20 > > Interesting points, but I don't think they actually apply here. >=20 > > >=20 > > With regard to downgrade attacks: >=20 > > >=20 > > The attack that RFC 5752 is concerned with is when an attacker = strips signatures from a signed message, so that the only ones left are = ones he can tamper with. So the integrity protection here is = "horizontal"; it goes across signatures. The integrity protection in = JWS/JWE is "vertical" -- it only protects one signer's parameters -- so = it is, so to speak, orthogonal. >=20 > > >=20 > > >=20 > > With regard to "brown bag" attacks: >=20 > > >=20 > > The root of this attack is ambiguity about what content is *signed* >=20 > > vs. what content is *used*. If an application doesn't verify that >=20 > > it's actually using the stuff that's signed, then it can be tricked >=20 > > into accepting something unsigned. (Cf. >=20 > > ) >=20 > > >=20 > > However, I don't think any of the current proposals have that = problem. In JWE/JWS, the signed content is right there between the = dots, and in JSMS, it's in the "content" element. The current JSMS = draft does allow detached signatures, but with a "voids your warranty" = sticker on it. >=20 > > >=20 > > In any case, these attacks have nothing to do with whether the = cryptographic parameters are integrity-protected with the content. The = example attacks in the IBM still work regardless -- the whole point of = the attack is that the cryptographic processing is the same, only the = (non-crypto) matching of content is flawed. >=20 > > >=20 > > >=20 > > With regard to "arbitrary attributes": >=20 > > >=20 > > We can have that here, too, but you need canonicalization. And = base64-encoding is not not canonicalization -- it just waves its hands = over the question of equivalence. In my opinion, we should keep the = cryptographic object simple by disallowing attributes, and push the = attributes you would sign inside of the thing being signed. If people = really do want attributes, it doesn't seem to me like JSON = canonicalization is very hard. I can do it in 19 lines of python: >=20 > > >=20 > > >=20 > > >=20 > > With regard too "meta-data in the body": >=20 > > >=20 > > It seems to me like if we're trying to define a general format for = applying security protections, then we ought to keep out things that = aren't strictly security relevant. Those things can go in = application-specific content types (e.g., SAML) without polluting the = general purpose header.=20 >=20 > > >=20 > > >=20 > > With regard to "defense in depth" and selling this to government = agencies: >=20 > > >=20 > > CMS, via S/MIME, is in broad use across multiple federal agencies = and large enterprises. JSMS is essentially a profile of CMS (see = Section 7), and has the same security properties. >=20 > > >=20 > > >=20 > > Cheers, >=20 > > --Richard >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >=20 > > >=20 > >> Hi Richard, >=20 > >> >=20 > >> Originally we only integrity protected the header for signing. We = added the integrity protection to encryption as part of AEAD, as = encryption can also be used for sender verification. >=20 > >> >=20 > >> I understand the argument that it makes things simpler if we don't = integrity protect the header information. >=20 > >> >=20 > >> However xmldsig, provides integrity over those elements to prevent = possible downgrade attacks by manipulating the algorithms. =20 >=20 > >> >=20 > >> CMS may not typically provide that integrity protection but I think = Jim Schaad and Sean Terner created RFC5752 to address downgrade attacks. >=20 > >> Given they are on this list they can speak to their view on = integrity over the crypto parameters. >=20 > >> >=20 > >> I also recall when working on InfoCards there was a Monte = Carlo/Brown Bag attack that needs to be considered if we move to = something more like a detached signature. >=20 > >> >=20 > >> The other design consideration is that we wanted to be able to sign = arbitrary byte strings not just JSON. You could sign XML if you = wanted. >=20 > >> That prevented us from including meta-data in the body as we didn't = want to touch it. That left us with the header to include additional = elements in.=20 >=20 > >> Not integrity protecting those elements as well would be a problem.=20= >=20 > >> >=20 > >> I am not a CMS expert but I believe it allows for signing of = arbitrary attributes not unlike the current JOSE spec. >=20 > >> >=20 > >> Especially for something that will be used with JWT security tokens = I will have a hard time making the argument to NIST and others that need = to approve this format that not integrity protecting the header = parameters is appropriate defence in depth, for something that might be = replacing signed SAML assertions in some applications. >=20 > >> >=20 > >> I do understand how not integrity protecting the header will make = some things easier, however I can't agree that the benefit outweighs the = disadvantages. >=20 > >> >=20 > >> Regards >=20 > >> John B. >=20 > >> >=20 > >> >=20 > >> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >=20 > >> >=20 > >>> Hey Mike, >=20 > >>> >=20 > >>> Thanks for having some back-and-forth with me on this. I think = this is a good discussion to have right now. I would like to discuss = some high-level points, and then I'll respond inline to your precise = points. >=20 > >>> >=20 > >>> tl;dr: In order to meet its deliverables, the WG needs to define = JSON-based formats for integrity and confidentiality protections. JWE = and JWS don't fit that requirement, so we should re-consider their = adoption and call for new candidates. >=20 > >>> >=20 > >>> Major points: >=20 > >>> 1. JOSE is JSON >=20 > >>> 2. JSON does not imply canonicalization 3. Compactness and >=20 > >>> URL-safeness are still OK, as derivatives >=20 > >>> >=20 > >>> Part 1: JOSE is JSON >=20 > >>> >=20 > >>> The JOSE WG charter calls out four deliverables, three of which = are explicitly required to be JSON: >=20 > >>> -- "JSON-structured integrity protection" >=20 > >>> -- "JSON-structured encryption" >=20 > >>> -- "public keys as JSON-structured objects" >=20 > >>> (The fourth is just a list of algorithms, which should be JSON as >=20 > >>> well, just as RFC 3370 is ASN.1.) >=20 > >>> >=20 > >>> In light of these requirements, JWE and JWS are clearly not = suitable >=20 > >>> candidates to fulfill the working group's milestones. (At least = in >=20 > >>> their current form.) So ISTM that we need to step back and >=20 > >>> re-evaluate alternatives for the three above milestones, = especially >=20 > >>> the first two. (JWK is not as far off.) >=20 > >>> >=20 > >>> As JSON-based mechanisms, though, the "JSON serialization" drafts = are pretty half-hearted. Because JWS and JWE include the cryptographic = parameters within the integrity protection, they have to have the = headers included as base64-encoded strings. That obviously adds a lot = of complexity to encoding and decoding -- for example, you have to keep = the encoded header around even after you've decoded it! -- and just = plain more octets. The support for multiple recipients and multiple = signatures is both unweildy (matching up parallel indices for headers = and signatures) and inefficient (multiple integrity check values in = encrypted objects). >=20 > >>> >=20 > >>> By contrast, JSMS takes advantage of the cryptographic wisdom that = went into CMS, while making the syntax pure JSON and as simple as = possible. Multiple signatures and multiple recipients are supported = with absolute minimum overhead. So I think it's worth consideration by = the working group. >=20 > >>> >=20 > >>> >=20 > >>> Part 2: JSON !=3D> canonicalization >=20 > >>> >=20 > >>> I would like to dispel the myth that a JSON-based format requires >=20 > >>> canonicalization. In JWE/JWS, the JSON header requires >=20 > >>> "canonicalization" (via base64url encoding) because it's included >=20 > >>> within the integrity protection. I'm not aware of any reason for >=20 > >>> including the cryptographic parameters in the integrity check, >=20 > >>> instead of only integrity-protecting the content itself. Indeed, = if >=20 > >>> there were an attack based on non-integrity-protected = cryptographic >=20 > >>> parameters, it would be a pretty big deal, since neither CMS nor = IKE >=20 > >>> nor provides this protection. (TLS does provide a signature over >=20 > >>> the algorithms, but only as a way to bind the public key to the >=20 > >>> session.) >=20 > >>> >=20 > >>> Indeed CMS doesn't require canonicalization at all, except for = attributes that are included in the protected content (signedAttrs / = authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't = allow those parameters, so there is no need for canonicalization at all. = All the "canonicalization" that's needed is to base64url-encode the = protected content. In that regard, JSMS is even simpler than JWE/JWS. >=20 > >>> >=20 > >>> >=20 > >>> Part 3: Compactness and URL-safeness are still OK, as derivatives >=20 > >>> >=20 > >>> I have absolutely no objection to defining a compact, URL-safe = format. Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example from Section 3.1 of the JWS spec, we get the following JSMS = object: >=20 > >>> >=20 > >>> { >=20 > >>> "v":1, >=20 > >>> "t":"au", >=20 > >>> "a":"hs256", >=20 > >>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >=20 > >>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >=20 > >>> "ki":"rSIilRk8Ego" >=20 > >>> } >=20 > >>> >=20 > >>> If we remove the decorative spaces and base64url-encode, we only = use >=20 > >>> 88 octets more than JWS (267 vs. 179). If we take this a step >=20 > >>> further and define an explicit compact format for = AuthenticatedData, >=20 > >>> we can emulate JWS by moving the content and MAC fields outside = and >=20 > >>> dot-combining. That avoids double-base64url-encoding, and only >=20 > >>> takes up 11 more octets than a JWS (190 vs 179). (I've put the = code >=20 > >>> to generate these in the Github project linked earlier.) >=20 > >>> >=20 > >>> So it's fine to have a compact, URL-safe format for an objective, = but it makes *much* more sense to derive that from a full-size, usable, = JSON format than the other way around. >=20 > >>> >=20 > >>> Responses to specific points inline below. >=20 > >>> >=20 > >>> >=20 > >>>> Fair enough. I'll briefly respond to each in turn. Before doing = so, I'll say that I'm writing in the spirit of trying to increase mutual = understanding and consensus, rather than taking the point of view that = the status quo is the only reasonable outcome. >=20 > >>>> >=20 > >>>> -- Not being JSON >=20 > >>>> >=20 > >>>> This was by design, so that the results are URL-safe. This is = required, for instance, for them to be used as OAuth Bearer Tokens. At = the request of the working group, closely related pure-JSON drafts were = also published. See: >=20 > >>>> >=20 > >>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri >=20 > >>>> alization-01 and >=20 > >>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser >=20 > >>>> ialization-01 >=20 > >>>> >=20 > >>>> Use them if you prefer if they better suit your use cases. They = could be adopted as working group documents, if there's interest. >=20 > >>> >=20 > >>> See above. These are super-clunky, and the need to be the main = focus of the WG, not an afterthought. >=20 > >>> >=20 > >>> >=20 > >>>> -- Not supporting multiple recipients >=20 > >>>> >=20 > >>>> The JSON serialization drafts above do, again, in response to use = cases presented by the working group. >=20 > >>> >=20 > >>> >=20 > >>> See above. Because of the unnecessary inclusion of the header in = the integrity check, this is far less efficient than it should be. >=20 > >>> >=20 > >>> >=20 > >>>> -- Lacking clear distinctions between signing and MAC >=20 > >>>> >=20 > >>>> Functionally, these are very similar operations, at least from an = implementation perspective, so it's not clear that making a clear = distinction would help either developers or adoption in any practical = way. They achieve overlapping, but admittedly sometimes different = goals. I believe that developers can be trusted to use the algorithms = that achieve their applications' goals without making a hard distinction = between the two. But I'd be interested in hearing your thoughts on why = you believe a brighter-line distinction might be useful or necessary. >=20 > >>> >=20 > >>> It's important if you want to do MACs with anything other than = pre-shared keys. If you want to do anything more advanced, you need to = have wrapped keys, in which case an object with a MAC starts to look a = lot more like a JWE than a JWS. >=20 > >>> >=20 > >>> >=20 > >>>> -- Lacking clear processing instructions for different key >=20 > >>>> establishment modalities >=20 > >>>> >=20 > >>>> This seems like an area where the existing drafts could be = refined to add descriptions for additional establishment modalities, = possibly based upon your ideas and descriptions, should the working = group decide to do so. What additional modalities do you have use cases = for that you believe are not achievable or straightforward with the = existing drafts? The existing modalities supported are largely those = that existing developers had told us they needed and draw both from the = precursor draft-jones-json-web-* documents and draft-rescorla-jsms. >=20 > >>>> >=20 > >>>> Bear in mind that the balance that the current drafts try to = strike is keeping the Mandatory to Implement (MTI) feature footprint = small enough that developers, including Web developers, are likely to = adopt the specs, while still providing enough functionality to make them = generally useful. As in any balance, it's often possible to shift = things a bit and still maintain the balance, but I'd like people to keep = the ubiquitous adoption goal front-and-center when proposing additional = functionality. >=20 > >>>> >=20 > >>>> Ubiquitous deployment and usefulness trump theoretical >=20 > >>>> completeness. (Just look at XMLDSIG and XMLENC to understand >=20 > >>>> that!) >=20 > >>> >=20 > >>> I agree that we need to find a reasonable MTI. The current JSMS = draft doesn't really specify which parts are MTI, beyond basic things = like base64url encoding and ignoring unknown fields. >=20 > >>> >=20 > >>> My main concern is that JWS and JWE don't really tell me which = fields need to be present for which use case. If I'm putting a MAC on a = JWS vs. a signature, do I need "jwk" or "jku" fields to be populated? = Whereas in JSMS, I think these things are much clearer due to the = separation of the use cases (Signed/Authenticated/Encrypted) and the = isolation of signatures and wrapped keys into sub-objects. >=20 > >>> >=20 > >>> >=20 > >>>> -- Lack of clear typing of objects >=20 > >>>> >=20 > >>>> Most JSON documents aren't clearly typed; instead, developers and = implementations understand from context what the meaning of each field = is. XML is clearly typed, but developers are voting with their feet by = moving to JSON. >=20 > >>>> >=20 > >>>> What practical advantages resulting from overlaying a typing = infrastructure on JSON do you believe are worth the potential costs of = doing so? BTW, I'm not opposed to having a JSON schema description of = the JOSE JSON data structures like JSMS did in = http://tools.ietf.org/html/draft-rescorla-jsms-00#appendix-A, but I'll = remark that this an informative tool, not a normative one. >=20 > >>> >=20 > >>> I actualy don't have a hugely urgent requirement here either. = It's something that others in the WG had requested, which is trivial to = add in JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity protection of the header. >=20 > >>> >=20 > >>> >=20 > >>>> -- Lack of versioning for future extensibility >=20 > >>>> >=20 > >>>> An optional version field could be added if the working group >=20 > >>>> desires, however the last time the working group discussed it, = they >=20 > >>>> decided not to do so. Rather, specs like this effectively become >=20 > >>>> "versioned" when revised in a way that new fields are added. If >=20 > >>>> you understand the new fields, you support that new version. = (Note >=20 > >>>> that this is independent of whether there is a version number >=20 > >>>> field, which according to some participants in the previous >=20 > >>>> discussion, they regarded as therefore being redundant >=20 > >>>> information.) >=20 > >>>> >=20 > >>>> I'm not religious about not having a version number field, but = often "less is more". >=20 > >>> >=20 > >>> Indeed, I'm not religious either. It just seems like a general = good idea to state this directly as opposed to having parsers divine it = based on which fields are present. To quote RFC 5652: >=20 > >>> " >=20 > >>> Each of the major data structures includes a version number as = the=20 >=20 > >>> first item in the data structure. The version numbers are = intended=20 >=20 > >>> to avoid ASN.1 decode errors. Some implementations do not check = the=20 >=20 > >>> version number prior to attempting a decode, and if a decode error=20= >=20 > >>> occurs, then the version number is checked as part of the error=20 >=20 > >>> handling routine. This is a reasonable approach; it places error=20= >=20 > >>> processing outside of the fast path. This approach is also >=20 > >>> forgiving when an incorrect version number is used by the sender. >=20 > >>> " >=20 > >>> >=20 > >>> >=20 > >>> Best, >=20 > >>> --Richard >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>>> >=20 > >>>> Best wishes, >=20 > >>>> -- Mike >=20 > >>>> >=20 > >>>> -----Original Message----- >=20 > >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >=20 > >>>> Sent: Friday, June 15, 2012 3:00 PM >=20 > >>>> To: Mike Jones >=20 > >>>> Cc: jose@ietf.org >=20 > >>>> Subject: Re: [jose] Fwd: New Version Notification for >=20 > >>>> draft-barnes-jose-jsms-00.txt >=20 > >>>> >=20 > >>>> Ok, so maybe I should have phrased my lead-in differently. IMO, = the current JW* specs are deficient in several ways, e.g.: >=20 > >>>> -- Not being JSON >=20 > >>>> -- Not supporting multiple recipients >=20 > >>>> -- Lacking clear distinctions between signing and MAC >=20 > >>>> -- Lacking clear processing instructions for different key >=20 > >>>> establishment modalities >=20 > >>>> -- Lack of clear typing of objects >=20 > >>>> -- Lack of versioning for future extensibility >=20 > >>>> >=20 > >>>> Looking at the current specs, it didn't seem to me that it would = be simple to adapt them to address these deficiencies. So I just did a = re-write. If you think they can be addressed within the current = framework, please explain. I just found it simpler to start from whole = cloth. >=20 > >>>> >=20 > >>>> Cheers, >=20 > >>>> --Richard >=20 > >>>> >=20 > >>>> >=20 > >>>> >=20 > >>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >=20 > >>>> >=20 > >>>>> Hi Richard, >=20 > >>>>> >=20 > >>>>> If you're puzzled by specific design decisions in the JOSE = documents, I encourage you to ask about them on the list. The documents = have significant history going back to mid-2010 when convergence = discussions started among people with four different JSON signing & = encryption proposals. JWT and the current JOSE specs and = implementations are the result. I realize that not all the JOSE = participants were part of those discussions from the beginning (although = many were) and so teasing out the rationale for specific decisions might = help people better understand the choices made, and hopefully thereby = increase consensus behind the eventual working group choices. >=20 > >>>>> >=20 > >>>>> If the list that you're puzzled by is the bulleted list below, = maybe we can start a discussion on that basis. >=20 > >>>>> >=20 > >>>>> Best wishes, >=20 > >>>>> -- Mike >=20 > >>>>> >=20 > >>>>> -----Original Message----- >=20 > >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >=20 > >>>>> Behalf Of Richard L. Barnes >=20 > >>>>> Sent: Friday, June 15, 2012 2:08 PM >=20 > >>>>> To: jose@ietf.org >=20 > >>>>> Subject: [jose] Fwd: New Version Notification for >=20 > >>>>> draft-barnes-jose-jsms-00.txt >=20 > >>>>> >=20 > >>>>> Dear JOSE WG, >=20 > >>>>> >=20 > >>>>> Like Mr. Manger, once I finally got around to doing a thorough = review of the JW* specs, I was kind of puzzled by some of the design = decisions. So I also went through and wrote an alternative format, this = time taking a more of a cue from CMS. A link to the document is below. >=20 > >>>>> >=20 > >>>>> Summary of differences: >=20 > >>>>> >=20 > >>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >=20 > >>>>> parameters are represented in JSON. >=20 > >>>>> >=20 > >>>>> o JSMS allows for full algorithm agility in key agreement, = while JWE >=20 > >>>>> only allows ECDH-ES. >=20 > >>>>> >=20 > >>>>> o JSMS supports multiple recipients for EncryptedData and >=20 > >>>>> AuthenticatedData objects via the inclusion of multiple = WrappedKey >=20 > >>>>> objects. Sending a JWE to multiple recipients requires re- >=20 > >>>>> encryption of the entire object for each recipient. >=20 > >>>>> >=20 > >>>>> o The signature and MAC functions of the JWS object are = separated >=20 > >>>>> into SignedData and AuthenticatedData JSMS objects. >=20 > >>>>> >=20 > >>>>> o JSMS parameters are not integrity-protected, as they are in = JWE >=20 > >>>>> and JWS. >=20 > >>>>> >=20 > >>>>> o The "typ" and "zip" parameters are not defined in JSMS, but = could >=20 > >>>>> be added without significant change. >=20 > >>>>> >=20 > >>>>> o JSMS requires that recipients MUST ignore unknown header >=20 > >>>>> parameters, in order to facilitate extensibility. >=20 > >>>>> >=20 > >>>>> I've also thrown together an initial JavaScript implementation = (based on NodeJS for some python crypto glue), which is on github: >=20 > >>>>> >=20 > >>>>> >=20 > >>>>> Comments are very welcome.=20 >=20 > >>>>> >=20 > >>>>> Thanks, >=20 > >>>>> --Richard >=20 > >>>>> >=20 > >>>>> >=20 > >>>>> >=20 > >>>>> Begin forwarded message: >=20 > >>>>> >=20 > >>>>>> From: internet-drafts@ietf.org >=20 > >>>>>> Subject: New Version Notification for >=20 > >>>>>> draft-barnes-jose-jsms-00.txt >=20 > >>>>>> Date: June 15, 2012 4:56:09 PM EDT >=20 > >>>>>> To: rbarnes@bbn.com >=20 > >>>>>> >=20 > >>>>>> >=20 > >>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >=20 > >>>>>> successfully submitted by Richard Barnes and posted to the IETF >=20 > >>>>>> repository. >=20 > >>>>>> >=20 > >>>>>> Filename: draft-barnes-jose-jsms >=20 > >>>>>> Revision: 00 >=20 > >>>>>> Title: JavaScript Message Security Format >=20 > >>>>>> Creation date: 2012-06-15 >=20 > >>>>>> WG ID: Individual Submission >=20 > >>>>>> Number of pages: 25 >=20 > >>>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt >=20 > >>>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >=20 > >>>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >=20 > >>>>>> >=20 > >>>>>> >=20 > >>>>>> Abstract: >=20 > >>>>>> Many applications require the ability to send cryptographically >=20 > >>>>>> secured messages. While the IETF has defined a number of = formats >=20 > >>>>>> for such messages (e.g. CMS) those formats use encodings which >=20 > >>>>>> are not easy to use in modern applications. This document >=20 > >>>>>> describes the JavaScript Message Security format (JSMS), a new >=20 > >>>>>> cryptographic message format which is based on JavaScript = Object >=20 > >>>>>> Notation (JSON) and thus is easy for many applications to = generate and parse. >=20 > >>>>>> >=20 > >>>>>> >=20 > >>>>>> >=20 > >>>>>> >=20 > >>>>>> The IETF Secretariat >=20 > >>>>> >=20 > >>>>> _______________________________________________ >=20 > >>>>> jose mailing list >=20 > >>>>> jose@ietf.org >=20 > >>>>> https://www.ietf.org/mailman/listinfo/jose >=20 > >>>>> >=20 > >>>>> >=20 > >>>>> _______________________________________________ >=20 > >>>>> jose mailing list >=20 > >>>>> jose@ietf.org >=20 > >>>>> https://www.ietf.org/mailman/listinfo/jose >=20 > >>>> >=20 > >>>> >=20 > >>>> >=20 > >>>> _______________________________________________ >=20 > >>>> jose mailing list >=20 > >>>> jose@ietf.org >=20 > >>>> https://www.ietf.org/mailman/listinfo/jose >=20 > >>> >=20 > >>> _______________________________________________ >=20 > >>> jose mailing list >=20 > >>> jose@ietf.org >=20 > >>> https://www.ietf.org/mailman/listinfo/jose >=20 > >> >=20 > > >=20 > =20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Mon Jun 25 14:53: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 6B08E11E80A0 for ; Mon, 25 Jun 2012 14:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLpR72jcKZLf for ; Mon, 25 Jun 2012 14:53:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4511E808C for ; Mon, 25 Jun 2012 14:53:08 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:56215) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjHCt-000NqD-0o; Mon, 25 Jun 2012 17:52:27 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 25 Jun 2012 17:53:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E84631F-F6C2-43F7-9B65-E57841E4E858@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.1278) Cc: John Bradley , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 21:53:09 -0000 >> I think part of this is that as one of the openID Connect authors I = look at this as a necessary security token format, for OAuth and = Connect. >> For that simple processing with one signature is a high priority for = adoption. >=20 > +1. >=20 > A simple JSON friendly model supporting a single signature over the > entire message (including headers) is an important case for adoption > (and security). JWS provides that now and there are already numerous > interoperable JWS implementations available or in the works. I'm not sure how people think that integrity-protecting the header makes = things *simpler*, especially since it adds a whole new decoding step and = makes the parsing more complicated. Pseudocode without integrity protection (assuming JSMS format, but JWS = could be made to look similar): function verify(json) { jose =3D JSON.parse(json); // Check algorithm values=20 return Crypto.SignatureAlgorithm.verify(jose.content, = jose.keys[0].signature, jose.keys[0].key); } Pseudocode with integrity protection (assuming JWS format): function verify(jws) { (txtHeader, content, signature) =3D jws.split("\."); protectedBody =3D header + "." + content jsonHeader =3D base64url.decode(txtHeader); header =3D JSON.parse(jsonHeader); return Crypto.SignatureAlgorithm.verify(content, signature, = header.jwk); } From rbarnes@bbn.com Mon Jun 25 14:55:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D45611E80C0 for ; Mon, 25 Jun 2012 14:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkByhPZfcsHz for ; Mon, 25 Jun 2012 14:55:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A595D11E808C for ; Mon, 25 Jun 2012 14:55:23 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:56216) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjHFi-000I3y-Lv; Mon, 25 Jun 2012 17:55:22 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <6E84631F-F6C2-43F7-9B65-E57841E4E858@bbn.com> Date: Mon, 25 Jun 2012 17:55:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C25B651-4E65-4D6F-AA9F-F76C98626E54@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> <6E84631F-F6C2-43F7-9B65-E57841E4E858@bbn.com> To: Brian Campbell X-Mailer: Apple Mail (2.1278) Cc: John Bradley , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 21:55:24 -0000 On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: >>> I think part of this is that as one of the openID Connect authors I = look at this as a necessary security token format, for OAuth and = Connect. >>> For that simple processing with one signature is a high priority for = adoption. >>=20 >> +1. >>=20 >> A simple JSON friendly model supporting a single signature over the >> entire message (including headers) is an important case for adoption >> (and security). JWS provides that now and there are already numerous >> interoperable JWS implementations available or in the works. >=20 > I'm not sure how people think that integrity-protecting the header = makes things *simpler*, especially since it adds a whole new decoding = step and makes the parsing more complicated. >=20 > Pseudocode without integrity protection (assuming JSMS format, but JWS = could be made to look similar): > function verify(json) { > jose =3D JSON.parse(json); > // Check algorithm values=20 > return Crypto.SignatureAlgorithm.verify(jose.content, = jose.keys[0].signature, jose.keys[0].key); > } >=20 > Pseudocode with integrity protection (assuming JWS format): > function verify(jws) { > (txtHeader, content, signature) =3D jws.split("\."); > protectedBody =3D header + "." + content > jsonHeader =3D base64url.decode(txtHeader); > header =3D JSON.parse(jsonHeader); > return Crypto.SignatureAlgorithm.verify(content, signature, = header.jwk); > } >=20 Err, sorry, that should read: protectedBody =3D txtHeader + "." + content; and=20 return Crypto.SignatureAlgorithm.verify(protectedBody, signature, = header.jwk); See how hard it is to get right? :) --Richard= From ve7jtb@ve7jtb.com Mon Jun 25 16:02: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 7F7D311E808F for ; Mon, 25 Jun 2012 16:02:40 -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.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L1xckK+8o5Y for ; Mon, 25 Jun 2012 16:02:39 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F81711E80B8 for ; Mon, 25 Jun 2012 16:02:39 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3689718ghb.31 for ; Mon, 25 Jun 2012 16:02:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=MXG/lSxZ7veE4vsPYLd+WrlYaAUaB8AxpfRZXKncMSE=; b=oEhhw9XtPwoolORkPKuzk9uY8t9UPZas8Tr7JzdfSg0BQk7NTaEiBm6xfAIZosyRtV yi0lK7JvyOsxLZwm26Ojdmufddt1z8quaZDVhbgwHY9FqplzpYIw4ejNnaEGVc4VeCBv mcCgoRurdGonZsKBhDEGvl9Xq3FHkC28JHhKq7pQrgcDHOAcj/LNXUJSOm+mAQYWN0vi dEsTOEpIuIKl0LIDBRx3KjOlPfErOxCDu/mngOotLeVm+uNZ/OhThaqcdLIXtfmKhJrP EhzVZg5eVeBoR50zxO1AiiHrsuJ4FLUh6TswfK4akeUIf1Ywo0zEt7B7l5RdIM1fc2O5 HxRw== Received: by 10.101.151.23 with SMTP id d23mr4728541ano.26.1340665357764; Mon, 25 Jun 2012 16:02:37 -0700 (PDT) Received: from [192.168.1.213] (190-20-27-74.baf.movistar.cl. [190.20.27.74]) by mx.google.com with ESMTPS id i16sm58537198anm.12.2012.06.25.16.02.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 16:02:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_53C4ACF3-4804-4A55-B44C-90B5780F18C6"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> Date: Mon, 25 Jun 2012 19:02:07 -0400 Message-Id: <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnALAJw2Q0TiscDrdtdTK+Ib9Q4Ph+TOwPwswaR3+G+1mO2uMaiz/QnsGimIjc537d1UPZl Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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, 25 Jun 2012 23:02:40 -0000 --Apple-Mail=_53C4ACF3-4804-4A55-B44C-90B5780F18C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Richard, There was some other back and for with Matt. He is only encrypting to one recipient at a time. Not that encrypting the CMK to multiple recipients is not valid, that = is just not how the protocol works. The message is encrypted once and whatever endpoint gets it calls back = to the sender to get the key. The issue as I understand it is that the sender doesn't know the public = key for the recipient before it sends the message. I am happy to work on Matts issues, but I think they are separate from = the point you are making on integrity protecting the header. John B. On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >> Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: >> "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" >=20 > He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >=20 > Compare JSMS and the WrappedKey structure, or CMS and RecipientInfo. > > >=20 >=20 >> I should also point out that the messages are transported in XML, and = as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>=20 >> There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>=20 >> For the transmission of the messages, I can't see any reason to not = use the JWE spec as currently written. It certainly supports the use = case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>=20 >> Currently the message on the wire looks like: >>=20 >> > from=3D'juliet@capulet.lit/balcony' >> id=3D'fJZd9WFIIwNjFctT' >> to=3D'romeo@montegue.lit/garden' >> type=3D'chat'> >> > id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>
>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >> NpemUiOiIxNiJ9 >>
>> >> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >> eCGP >> >> >> >> >>=20 >> I would have sent header and data as one element using the normal JWE = dot separated format, but I need to talk to Matt to understand his = reasoning. >>=20 >> I note that his example is using AES-CCM, and so not documented in = JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >=20 > Valid point. I had missed that RFC 5084 handled the ICV separately. >=20 >=20 >> I don't quite get your point on integrity protecting the wrapped key = causing the integrity value to change. For HMAC, GCM, and I think CCM, = changing the encryption key changes the tag value anyway (sort of the = point I thought). The only time it would stay the same would be if you = were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >=20 > The point is that you have to re-compute the ICV over the entire = header+content every time you wrap a new key. This is kind of a big = deal for the XMPP case. =20 >=20 > Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >=20 > So integrity protecting the headers has real costs in terms of both = scalability (state) and security. >=20 >=20 >> There are some interesting things Matt=92s spec is attempting with = using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >=20 > My point is that we shouldn't need a whole new protocol for this. CMS = RecipientInfos do exactly what we want. (Er, what *Matt* wants.) We = should just be copying and pasting. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >>=20 >> I am happy to work with Matt to refine his ID. >>=20 >> I recommend others read it as well so we can understand if there are = any real issues. >>=20 >> Regards >> John B. >>=20 >> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>=20 >>> Hey John, >>>=20 >>> I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. >>>=20 >>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>=20 >>>> Hi Matt, >>>>=20 >>>> Complements on updating the draft. >>>>=20 >>>> The issue I see is that you are attempting to distribute the CMK = out of band and use "none" as the alg. >>>>=20 >>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>=20 >>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>>>=20 >>>> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>>>=20 >>>> So in your spec I would expect you to distribute a shared secret = via keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>>>=20 >>>> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>>>=20 >>>> I am not a XMPP expert so it will take me some time to go over it = in detail. I would like to understand the use case to be certain it is = properly supported. >>>>=20 >>>> Regards >>>> John B. >>>>=20 >>>>=20 >>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>=20 >>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been updated = to the latest JOSE WG drafts. >>>>>=20 >>>>>=20 >>>>> - m&m >>>>>=20 >>>>> Matt Miller - >>>>> Cisco Systems, Inc. >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>> To: i-d-announce@ietf.org >>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>> Reply-To: internet-drafts@ietf.org >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>=20 >>>>>>=20 >>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>> Author(s) : Matthew Miller >>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>> Pages : 22 >>>>>> Date : 2012-06-21 >>>>>>=20 >>>>>> Abstract: >>>>>> This document defines a method of end-to-end object encryption = for >>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>=20 >>>>>> A diff from previous version is available at: >>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >=20 --Apple-Mail=_53C4ACF3-4804-4A55-B44C-90B5780F18C6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NTIzMDIwN1owIwYJKoZIhvcNAQkEMRYEFIv3LvHY3FcKrWrh0/m0M/kzgehPMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AG2xii/uECFQvRUGekGHMMTgC4uED8Sc4tU3PipDFQ6X5WFnXq78979W8o9Xqa/COGLRKW0ahS8T KvFWacRTq7yn8+PdcRnvzAbO5UcaseewM6Y9hE51G2Ar8/PdXQeP74E6HRLg5bEM8judsoVe7g/k Y/AgvkZ8iDB0KO9GyVzRWz3BChq2oLL2Fe+KUe6JRGJ0PHmOu1SrPjvhKc0700e+0YI3PgGadfK8 rf5+K6StlTycfVnkozGuISgrsfQDdECk4gCPoWVLRLZJU3dDLqlANKsFo9UZfYD6fQ2+Ik2TIKgV Bv/3MKgfwTpW6xqdcdHPTcWDkLVrhKB18uDqJW8AAAAAAAA= --Apple-Mail=_53C4ACF3-4804-4A55-B44C-90B5780F18C6-- From ietf@augustcellars.com Mon Jun 25 16:49: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 06D8B11E808C for ; Mon, 25 Jun 2012 16:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCGdrmBbGa5e for ; Mon, 25 Jun 2012 16:49:20 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58021F85C5 for ; Mon, 25 Jun 2012 16:49:19 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (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 53F2B38F01; Mon, 25 Jun 2012 16:49:19 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Date: Mon, 25 Jun 2012 16:48:00 -0700 Message-ID: <007301cd532c$f4e7f0c0$deb7d240$@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: AQD47QI5KEiTUDL2CmgL/J0d6D+eqAIQ+tNPAngGm3uYkDVCkA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:49:23 -0000 Richard, > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Monday, June 25, 2012 2:35 PM > To: Nat Sakimura > Cc: Mike Jones; jose@ietf.org > Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms- > 00.txt > > Hi Nat, > > I'm not sure what X.509 fiasco you're referring to. There was a recent MD5 > fiasco [1], but that's an attack on MD5, not X.509. In fact, there have been > recommendations for preventing this attack in X.509 since 2005 [2]. As was > noted on the SAAG list, the real news here is that Microsoft wasn't following > any of those recommendations. > > JWS would have had the same problem as X.509. The attack did not modify > the cryptographic parameters (anything that would have gone in the > header), it would not have been thwarted by the integrity protection we're > worrying about. > > Actually, the header signing that JWS does makes it even nicer for the > attacker: Flame used a "chosen prefix" attack, so since the JWS header value > is entirely static for a given signer, it's easy to use as a fixed prefix. If JWS just > signed the content, then the application could include a something random > up front to prevent such prefix-based attacks. > I don't believe that this is a true statement. If you had a prefix or just signed what was given to you (i.e. no prefix), it would make no difference in terms of the attack for Flame. Flame could always use a fixed prefix of its own design rather than using the fixed header that is generated by having JWS sign the header information. > It's tempting to say that we should just add randomness to the JOSE format. > But the real lesson of the Flame/MD5 attacks is operational: If you're signing > something that somebody else gave you, make sure that you're not signing > exactly what they gave you. Follow the recommendations of RFC 4270. In > other contexts, there's no need of similar random elements; it just adds > complexity. This is definitely a true statement in all events and is something that should be added to the Security Considerations section. That being said, I think that there are valid reasons for wanting to protect the header information by some authentication processing. PKIX certificates protect the signature algorithm information (by copying the data into the to be signed block) and CMS has long allowed for information to be included in the signed attributes area that identifies the algorithms used, the certificates used and so forth. There are also other things that we might find to be convenient to be placed in the header information that is current not there (a signing time and embedded content type comes to mind) that would be a product either of specific types of signatures or becomes a common attribute to be placed there. In terms of encryption operations, I remember in the past that I have had either corrupted encrypted streams or corrupted IVs and had a successful decryption that later generated other problems when trying to parse. This is less of an issue with AEAD algorithms as they have a much stricter rule on when the stream decrypts correctly. Jim > > --Richard > > > > [1] > [2] > > > On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: > > > Especially after the X.509 fiasco, I strongly believe that having integrity > check over the metadata is a good thing. It is such a little effort that gives us > much more protection down the road. In this sense, I fully agree with Ben > here. We should have integrity protection over the header. > > > > Nat > > > > On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones > wrote: > > Two years ago when the developer community needing a JSON-friendly > token format was designing the JSON Web Token (JWT), we explicitly asked > security experts whether the header parameters should be integrity > protected or not. Among them, Ben Laurie was one of the voices saying that > securing them was the right thing to do. > > > > > > > > He argued that if the parameters can be protected in a practical manner, > then they should. Doing so provides an additional hurdle that attackers > would have to surmount. For example, if they can try to substitute a weaker > authentication scheme, then they must figure out how to make it > authenticate correctly despite some plaintext they can't control - the header > parameters. > > > > > > > > Ben also took the position that paring security protocols down to the least > you can get away with, given attacks you can think of, is not a good design > principle. If there is not a strong argument against including a feature that > may make it harder for attackers, then that feature should be included. > > > > > > > > I agree with him. > > > > > > > > The decision to provide integrity protection for the headers is documented > in the session notes at http://self-issued.info/?p=361, which said: > > > > > > > > . What to sign (envelope.payload or just payload)? > > > > Given that the envelope is extensible and therefore may contain security- > sensitive information, we reached a consensus (with input from Ben Laurie > via IM) that the combination envelope.payload must be signed. > > > > > > I believe that logic is as sound today as it was then. > > > > > > > > For all these reasons, I therefore personally stand by the community's > decision to provide integrity protection for the headers. > > > > > > > > Best wishes, > > > > -- Mike > > > > > > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > John Bradley > > Sent: Wednesday, June 20, 2012 3:57 PM > > To: Richard L.Barnes > > Cc: jose@ietf.org > > Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms- > 00.txt > > > > > > > > Hi Richard, > > > > > > > > While for PKCS 1.5 the hash algorithm is baked into the padding and not > susceptible to modification with ECDH or RSA-PSS it is not. > > > > There are possible hash truncation attacks by shortening SHA256 to SHA224 > as an example (I know we preclude truncated hashes at the moment). > > > > > > > > The bad feeling I get around this is that if there is a scenario where the > attacker controls the plaintext to be signed and there is no signer controlled > text contributed there are potential bad things that could happen down the > road. > > > > > > > > This bit us with x509 certs not that long ago (yes with MD5 admittedly) > where the attacker could use a certificate extension to include extra data and > cause a pre collided hash to be generated. > > > > Having part of the signed data outside the control of an attacker is a good > thing. (having a nonce or message ID in the envelope is possible though not > yet required in JWS.) > > > > > > > > I am still of the opinion that putting the base64 encoded envelope inside > the hash calculation is a valid way to allow additional attributes. > > > > Another structure to hold the attributes adds more complexity, as would > saying that they need to be inside the signed object. > > > > > > > > I think part of this is that as one of the openID Connect authors I look at this > as a necessary security token format, for OAuth and Connect. > > > > For that simple processing with one signature is a high priority for adoption. > > > > > > > > From a general signing/encrypting of documents point of view you > legitimately have different priorities. > > > > > > > > I know it is hard to prove a negative but It is also going to be difficult for me > to go back to security people at google Facebook and other places and > explain how not integrity protecting the header could be better than > integrity protecting it. > > > > > > > > It seems that I would be reduced to arguing that this is no worse than CMS > and that hasn't been proven insecure yet. > > > > > > > > Allowing a possible attacker to control the hash output, and not integrity > protecting the additional data, seems like something I am bound to regret in > the future. > > > > > > > > Regards > > > > John B. > > > > > > > > On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: > > > > > > > > > Hey John, > > > > > > > > > > Interesting points, but I don't think they actually apply here. > > > > > > > > > > With regard to downgrade attacks: > > > > > > > > > > The attack that RFC 5752 is concerned with is when an attacker strips > signatures from a signed message, so that the only ones left are ones he can > tamper with. So the integrity protection here is "horizontal"; it goes across > signatures. The integrity protection in JWS/JWE is "vertical" -- it only protects > one signer's parameters -- so it is, so to speak, orthogonal. > > > > > > > > > > > > > > > With regard to "brown bag" attacks: > > > > > > > > > > The root of this attack is ambiguity about what content is *signed* > > > > > vs. what content is *used*. If an application doesn't verify that > > > > > it's actually using the stuff that's signed, then it can be tricked > > > > > into accepting something unsigned. (Cf. > > > > > ) > > > > > > > > > > However, I don't think any of the current proposals have that problem. > In JWE/JWS, the signed content is right there between the dots, and in JSMS, > it's in the "content" element. The current JSMS draft does allow detached > signatures, but with a "voids your warranty" sticker on it. > > > > > > > > > > In any case, these attacks have nothing to do with whether the > cryptographic parameters are integrity-protected with the content. The > example attacks in the IBM still work regardless -- the whole point of the > attack is that the cryptographic processing is the same, only the (non-crypto) > matching of content is flawed. > > > > > > > > > > > > > > > With regard to "arbitrary attributes": > > > > > > > > > > We can have that here, too, but you need canonicalization. And base64- > encoding is not not canonicalization -- it just waves its hands over the > question of equivalence. In my opinion, we should keep the cryptographic > object simple by disallowing attributes, and push the attributes you would > sign inside of the thing being signed. If people really do want attributes, it > doesn't seem to me like JSON canonicalization is very hard. I can do it in 19 > lines of python: > > > > > > > > > > > > > > > > > > > > With regard too "meta-data in the body": > > > > > > > > > > It seems to me like if we're trying to define a general format for applying > security protections, then we ought to keep out things that aren't strictly > security relevant. Those things can go in application-specific content types > (e.g., SAML) without polluting the general purpose header. > > > > > > > > > > > > > > > With regard to "defense in depth" and selling this to government > agencies: > > > > > > > > > > CMS, via S/MIME, is in broad use across multiple federal agencies and > large enterprises. JSMS is essentially a profile of CMS (see Section 7), and > has the same security properties. > > > > > > > > > > > > > > > Cheers, > > > > > --Richard > > > > > > > > > > > > > > > > > > > > > > > > > On Jun 19, 2012, at 5:10 PM, John Bradley wrote: > > > > > > > > > >> Hi Richard, > > > > >> > > > > >> Originally we only integrity protected the header for signing. We added > the integrity protection to encryption as part of AEAD, as encryption can also > be used for sender verification. > > > > >> > > > > >> I understand the argument that it makes things simpler if we don't > integrity protect the header information. > > > > >> > > > > >> However xmldsig, provides integrity over those elements to prevent > possible downgrade attacks by manipulating the algorithms. > > > > >> > > > > >> CMS may not typically provide that integrity protection but I think Jim > Schaad and Sean Terner created RFC5752 to address downgrade attacks. > > > > >> Given they are on this list they can speak to their view on integrity over > the crypto parameters. > > > > >> > > > > >> I also recall when working on InfoCards there was a Monte Carlo/Brown > Bag attack that needs to be considered if we move to something more like a > detached signature. > > > > >> > > > > >> The other design consideration is that we wanted to be able to sign > arbitrary byte strings not just JSON. You could sign XML if you wanted. > > > > >> That prevented us from including meta-data in the body as we didn't > want to touch it. That left us with the header to include additional elements > in. > > > > >> Not integrity protecting those elements as well would be a problem. > > > > >> > > > > >> I am not a CMS expert but I believe it allows for signing of arbitrary > attributes not unlike the current JOSE spec. > > > > >> > > > > >> Especially for something that will be used with JWT security tokens I will > have a hard time making the argument to NIST and others that need to > approve this format that not integrity protecting the header parameters is > appropriate defence in depth, for something that might be replacing signed > SAML assertions in some applications. > > > > >> > > > > >> I do understand how not integrity protecting the header will make some > things easier, however I can't agree that the benefit outweighs the > disadvantages. > > > > >> > > > > >> Regards > > > > >> John B. > > > > >> > > > > >> > > > > >> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: > > > > >> > > > > >>> Hey Mike, > > > > >>> > > > > >>> Thanks for having some back-and-forth with me on this. I think this is a > good discussion to have right now. I would like to discuss some high-level > points, and then I'll respond inline to your precise points. > > > > >>> > > > > >>> tl;dr: In order to meet its deliverables, the WG needs to define JSON- > based formats for integrity and confidentiality protections. JWE and JWS > don't fit that requirement, so we should re-consider their adoption and call > for new candidates. > > > > >>> > > > > >>> Major points: > > > > >>> 1. JOSE is JSON > > > > >>> 2. JSON does not imply canonicalization 3. Compactness and > > > > >>> URL-safeness are still OK, as derivatives > > > > >>> > > > > >>> Part 1: JOSE is JSON > > > > >>> > > > > >>> The JOSE WG charter calls out four deliverables, three of which are > explicitly required to be JSON: > > > > >>> -- "JSON-structured integrity protection" > > > > >>> -- "JSON-structured encryption" > > > > >>> -- "public keys as JSON-structured objects" > > > > >>> (The fourth is just a list of algorithms, which should be JSON as > > > > >>> well, just as RFC 3370 is ASN.1.) > > > > >>> > > > > >>> In light of these requirements, JWE and JWS are clearly not suitable > > > > >>> candidates to fulfill the working group's milestones. (At least in > > > > >>> their current form.) So ISTM that we need to step back and > > > > >>> re-evaluate alternatives for the three above milestones, especially > > > > >>> the first two. (JWK is not as far off.) > > > > >>> > > > > >>> As JSON-based mechanisms, though, the "JSON serialization" drafts > are pretty half-hearted. Because JWS and JWE include the cryptographic > parameters within the integrity protection, they have to have the headers > included as base64-encoded strings. That obviously adds a lot of complexity > to encoding and decoding -- for example, you have to keep the encoded > header around even after you've decoded it! -- and just plain more octets. > The support for multiple recipients and multiple signatures is both unweildy > (matching up parallel indices for headers and signatures) and inefficient > (multiple integrity check values in encrypted objects). > > > > >>> > > > > >>> By contrast, JSMS takes advantage of the cryptographic wisdom that > went into CMS, while making the syntax pure JSON and as simple as possible. > Multiple signatures and multiple recipients are supported with absolute > minimum overhead. So I think it's worth consideration by the working group. > > > > >>> > > > > >>> > > > > >>> Part 2: JSON !=> canonicalization > > > > >>> > > > > >>> I would like to dispel the myth that a JSON-based format requires > > > > >>> canonicalization. In JWE/JWS, the JSON header requires > > > > >>> "canonicalization" (via base64url encoding) because it's included > > > > >>> within the integrity protection. I'm not aware of any reason for > > > > >>> including the cryptographic parameters in the integrity check, > > > > >>> instead of only integrity-protecting the content itself. Indeed, if > > > > >>> there were an attack based on non-integrity-protected cryptographic > > > > >>> parameters, it would be a pretty big deal, since neither CMS nor IKE > > > > >>> nor provides this protection. (TLS does provide a signature over > > > > >>> the algorithms, but only as a way to bind the public key to the > > > > >>> session.) > > > > >>> > > > > >>> Indeed CMS doesn't require canonicalization at all, except for > attributes that are included in the protected content (signedAttrs / > authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't > allow those parameters, so there is no need for canonicalization at all. All the > "canonicalization" that's needed is to base64url-encode the protected > content. In that regard, JSMS is even simpler than JWE/JWS. > > > > >>> > > > > >>> > > > > >>> Part 3: Compactness and URL-safeness are still OK, as derivatives > > > > >>> > > > > >>> I have absolutely no objection to defining a compact, URL-safe format. > Indeed, I did so in the JSMS draft, in Section 5. Encoding the example from > Section 3.1 of the JWS spec, we get the following JSMS object: > > > > >>> > > > > >>> { > > > > >>> "v":1, > > > > >>> "t":"au", > > > > >>> "a":"hs256", > > > > >>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", > > > > >>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", > > > > >>> "ki":"rSIilRk8Ego" > > > > >>> } > > > > >>> > > > > >>> If we remove the decorative spaces and base64url-encode, we only > use > > > > >>> 88 octets more than JWS (267 vs. 179). If we take this a step > > > > >>> further and define an explicit compact format for AuthenticatedData, > > > > >>> we can emulate JWS by moving the content and MAC fields outside > and > > > > >>> dot-combining. That avoids double-base64url-encoding, and only > > > > >>> takes up 11 more octets than a JWS (190 vs 179). (I've put the code > > > > >>> to generate these in the Github project linked earlier.) > > > > >>> > > > > >>> So it's fine to have a compact, URL-safe format for an objective, but it > makes *much* more sense to derive that from a full-size, usable, JSON > format than the other way around. > > > > >>> > > > > >>> Responses to specific points inline below. > > > > >>> > > > > >>> > > > > >>>> Fair enough. I'll briefly respond to each in turn. Before doing so, I'll > say that I'm writing in the spirit of trying to increase mutual understanding > and consensus, rather than taking the point of view that the status quo is the > only reasonable outcome. > > > > >>>> > > > > >>>> -- Not being JSON > > > > >>>> > > > > >>>> This was by design, so that the results are URL-safe. This is required, > for instance, for them to be used as OAuth Bearer Tokens. At the request of > the working group, closely related pure-JSON drafts were also published. > See: > > > > >>>> > > > > >>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri > > > > >>>> alization-01 and > > > > >>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser > > > > >>>> ialization-01 > > > > >>>> > > > > >>>> Use them if you prefer if they better suit your use cases. They could > be adopted as working group documents, if there's interest. > > > > >>> > > > > >>> See above. These are super-clunky, and the need to be the main > focus of the WG, not an afterthought. > > > > >>> > > > > >>> > > > > >>>> -- Not supporting multiple recipients > > > > >>>> > > > > >>>> The JSON serialization drafts above do, again, in response to use > cases presented by the working group. > > > > >>> > > > > >>> > > > > >>> See above. Because of the unnecessary inclusion of the header in the > integrity check, this is far less efficient than it should be. > > > > >>> > > > > >>> > > > > >>>> -- Lacking clear distinctions between signing and MAC > > > > >>>> > > > > >>>> Functionally, these are very similar operations, at least from an > implementation perspective, so it's not clear that making a clear distinction > would help either developers or adoption in any practical way. They achieve > overlapping, but admittedly sometimes different goals. I believe that > developers can be trusted to use the algorithms that achieve their > applications' goals without making a hard distinction between the two. But > I'd be interested in hearing your thoughts on why you believe a brighter-line > distinction might be useful or necessary. > > > > >>> > > > > >>> It's important if you want to do MACs with anything other than pre- > shared keys. If you want to do anything more advanced, you need to have > wrapped keys, in which case an object with a MAC starts to look a lot more > like a JWE than a JWS. > > > > >>> > > > > >>> > > > > >>>> -- Lacking clear processing instructions for different key > > > > >>>> establishment modalities > > > > >>>> > > > > >>>> This seems like an area where the existing drafts could be refined to > add descriptions for additional establishment modalities, possibly based > upon your ideas and descriptions, should the working group decide to do so. > What additional modalities do you have use cases for that you believe are > not achievable or straightforward with the existing drafts? The existing > modalities supported are largely those that existing developers had told us > they needed and draw both from the precursor draft-jones-json-web-* > documents and draft-rescorla-jsms. > > > > >>>> > > > > >>>> Bear in mind that the balance that the current drafts try to strike is > keeping the Mandatory to Implement (MTI) feature footprint small enough > that developers, including Web developers, are likely to adopt the specs, > while still providing enough functionality to make them generally useful. As > in any balance, it's often possible to shift things a bit and still maintain the > balance, but I'd like people to keep the ubiquitous adoption goal front-and- > center when proposing additional functionality. > > > > >>>> > > > > >>>> Ubiquitous deployment and usefulness trump theoretical > > > > >>>> completeness. (Just look at XMLDSIG and XMLENC to understand > > > > >>>> that!) > > > > >>> > > > > >>> I agree that we need to find a reasonable MTI. The current JSMS draft > doesn't really specify which parts are MTI, beyond basic things like base64url > encoding and ignoring unknown fields. > > > > >>> > > > > >>> My main concern is that JWS and JWE don't really tell me which fields > need to be present for which use case. If I'm putting a MAC on a JWS vs. a > signature, do I need "jwk" or "jku" fields to be populated? Whereas in JSMS, > I think these things are much clearer due to the separation of the use cases > (Signed/Authenticated/Encrypted) and the isolation of signatures and > wrapped keys into sub-objects. > > > > >>> > > > > >>> > > > > >>>> -- Lack of clear typing of objects > > > > >>>> > > > > >>>> Most JSON documents aren't clearly typed; instead, developers and > implementations understand from context what the meaning of each field is. > XML is clearly typed, but developers are voting with their feet by moving to > JSON. > > > > >>>> > > > > >>>> What practical advantages resulting from overlaying a typing > infrastructure on JSON do you believe are worth the potential costs of doing > so? BTW, I'm not opposed to having a JSON schema description of the JOSE > JSON data structures like JSMS did in http://tools.ietf.org/html/draft- > rescorla-jsms-00#appendix-A, but I'll remark that this an informative tool, not > a normative one. > > > > >>> > > > > >>> I actualy don't have a hugely urgent requirement here either. It's > something that others in the WG had requested, which is trivial to add in > JSMS, but not in JWE/JWS -- again because of the unnecessary integrity > protection of the header. > > > > >>> > > > > >>> > > > > >>>> -- Lack of versioning for future extensibility > > > > >>>> > > > > >>>> An optional version field could be added if the working group > > > > >>>> desires, however the last time the working group discussed it, they > > > > >>>> decided not to do so. Rather, specs like this effectively become > > > > >>>> "versioned" when revised in a way that new fields are added. If > > > > >>>> you understand the new fields, you support that new version. (Note > > > > >>>> that this is independent of whether there is a version number > > > > >>>> field, which according to some participants in the previous > > > > >>>> discussion, they regarded as therefore being redundant > > > > >>>> information.) > > > > >>>> > > > > >>>> I'm not religious about not having a version number field, but often > "less is more". > > > > >>> > > > > >>> Indeed, I'm not religious either. It just seems like a general good idea > to state this directly as opposed to having parsers divine it based on which > fields are present. To quote RFC 5652: > > > > >>> " > > > > >>> Each of the major data structures includes a version number as the > > > > >>> first item in the data structure. The version numbers are intended > > > > >>> to avoid ASN.1 decode errors. Some implementations do not check > the > > > > >>> version number prior to attempting a decode, and if a decode error > > > > >>> occurs, then the version number is checked as part of the error > > > > >>> handling routine. This is a reasonable approach; it places error > > > > >>> processing outside of the fast path. This approach is also > > > > >>> forgiving when an incorrect version number is used by the sender. > > > > >>> " > > > > >>> > > > > >>> > > > > >>> Best, > > > > >>> --Richard > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>>> > > > > >>>> Best wishes, > > > > >>>> -- Mike > > > > >>>> > > > > >>>> -----Original Message----- > > > > >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] > > > > >>>> Sent: Friday, June 15, 2012 3:00 PM > > > > >>>> To: Mike Jones > > > > >>>> Cc: jose@ietf.org > > > > >>>> Subject: Re: [jose] Fwd: New Version Notification for > > > > >>>> draft-barnes-jose-jsms-00.txt > > > > >>>> > > > > >>>> Ok, so maybe I should have phrased my lead-in differently. IMO, the > current JW* specs are deficient in several ways, e.g.: > > > > >>>> -- Not being JSON > > > > >>>> -- Not supporting multiple recipients > > > > >>>> -- Lacking clear distinctions between signing and MAC > > > > >>>> -- Lacking clear processing instructions for different key > > > > >>>> establishment modalities > > > > >>>> -- Lack of clear typing of objects > > > > >>>> -- Lack of versioning for future extensibility > > > > >>>> > > > > >>>> Looking at the current specs, it didn't seem to me that it would be > simple to adapt them to address these deficiencies. So I just did a re-write. > If you think they can be addressed within the current framework, please > explain. I just found it simpler to start from whole cloth. > > > > >>>> > > > > >>>> Cheers, > > > > >>>> --Richard > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > > > > >>>> > > > > >>>>> Hi Richard, > > > > >>>>> > > > > >>>>> If you're puzzled by specific design decisions in the JOSE documents, > I encourage you to ask about them on the list. The documents have > significant history going back to mid-2010 when convergence discussions > started among people with four different JSON signing & encryption > proposals. JWT and the current JOSE specs and implementations are the > result. I realize that not all the JOSE participants were part of those > discussions from the beginning (although many were) and so teasing out the > rationale for specific decisions might help people better understand the > choices made, and hopefully thereby increase consensus behind the > eventual working group choices. > > > > >>>>> > > > > >>>>> If the list that you're puzzled by is the bulleted list below, maybe we > can start a discussion on that basis. > > > > >>>>> > > > > >>>>> Best wishes, > > > > >>>>> -- Mike > > > > >>>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > > > > >>>>> Behalf Of Richard L. Barnes > > > > >>>>> Sent: Friday, June 15, 2012 2:08 PM > > > > >>>>> To: jose@ietf.org > > > > >>>>> Subject: [jose] Fwd: New Version Notification for > > > > >>>>> draft-barnes-jose-jsms-00.txt > > > > >>>>> > > > > >>>>> Dear JOSE WG, > > > > >>>>> > > > > >>>>> Like Mr. Manger, once I finally got around to doing a thorough > review of the JW* specs, I was kind of puzzled by some of the design > decisions. So I also went through and wrote an alternative format, this time > taking a more of a cue from CMS. A link to the document is below. > > > > >>>>> > > > > >>>>> Summary of differences: > > > > >>>>> > > > > >>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header > > > > >>>>> parameters are represented in JSON. > > > > >>>>> > > > > >>>>> o JSMS allows for full algorithm agility in key agreement, while JWE > > > > >>>>> only allows ECDH-ES. > > > > >>>>> > > > > >>>>> o JSMS supports multiple recipients for EncryptedData and > > > > >>>>> AuthenticatedData objects via the inclusion of multiple > WrappedKey > > > > >>>>> objects. Sending a JWE to multiple recipients requires re- > > > > >>>>> encryption of the entire object for each recipient. > > > > >>>>> > > > > >>>>> o The signature and MAC functions of the JWS object are separated > > > > >>>>> into SignedData and AuthenticatedData JSMS objects. > > > > >>>>> > > > > >>>>> o JSMS parameters are not integrity-protected, as they are in JWE > > > > >>>>> and JWS. > > > > >>>>> > > > > >>>>> o The "typ" and "zip" parameters are not defined in JSMS, but could > > > > >>>>> be added without significant change. > > > > >>>>> > > > > >>>>> o JSMS requires that recipients MUST ignore unknown header > > > > >>>>> parameters, in order to facilitate extensibility. > > > > >>>>> > > > > >>>>> I've also thrown together an initial JavaScript implementation (based > on NodeJS for some python crypto glue), which is on github: > > > > >>>>> > > > > >>>>> > > > > >>>>> Comments are very welcome. > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> --Richard > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> Begin forwarded message: > > > > >>>>> > > > > >>>>>> From: internet-drafts@ietf.org > > > > >>>>>> Subject: New Version Notification for > > > > >>>>>> draft-barnes-jose-jsms-00.txt > > > > >>>>>> Date: June 15, 2012 4:56:09 PM EDT > > > > >>>>>> To: rbarnes@bbn.com > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been > > > > >>>>>> successfully submitted by Richard Barnes and posted to the IETF > > > > >>>>>> repository. > > > > >>>>>> > > > > >>>>>> Filename: draft-barnes-jose-jsms > > > > >>>>>> Revision: 00 > > > > >>>>>> Title: JavaScript Message Security Format > > > > >>>>>> Creation date: 2012-06-15 > > > > >>>>>> WG ID: Individual Submission > > > > >>>>>> Number of pages: 25 > > > > >>>>>> URL: http://www.ietf.org/internet-drafts/draft-barnes-jose- > jsms-00.txt > > > > >>>>>> Status: http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > > > > >>>>>> Htmlized: http://tools.ietf.org/html/draft-barnes-jose-jsms-00 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Abstract: > > > > >>>>>> Many applications require the ability to send cryptographically > > > > >>>>>> secured messages. While the IETF has defined a number of > formats > > > > >>>>>> for such messages (e.g. CMS) those formats use encodings which > > > > >>>>>> are not easy to use in modern applications. This document > > > > >>>>>> describes the JavaScript Message Security format (JSMS), a new > > > > >>>>>> cryptographic message format which is based on JavaScript Object > > > > >>>>>> Notation (JSON) and thus is easy for many applications to generate > and parse. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> The IETF Secretariat > > > > >>>>> > > > > >>>>> _______________________________________________ > > > > >>>>> jose mailing list > > > > >>>>> jose@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/jose > > > > >>>>> > > > > >>>>> > > > > >>>>> _______________________________________________ > > > > >>>>> jose mailing list > > > > >>>>> jose@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/jose > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> jose mailing list > > > > >>>> jose@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/jose > > > > >>> > > > > >>> _______________________________________________ > > > > >>> jose mailing list > > > > >>> jose@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/jose > > > > >> > > > > > > > > > > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > -- > > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > _______________________________________________ > > 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 ve7jtb@ve7jtb.com Mon Jun 25 17:00:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEE211E80BB for ; Mon, 25 Jun 2012 17:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.083 X-Spam-Level: X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU7mdCqjTxoY for ; Mon, 25 Jun 2012 17:00:02 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8BCC21F8606 for ; Mon, 25 Jun 2012 16:59:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3718096ghb.31 for ; Mon, 25 Jun 2012 16:59:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=85fG+a8VUih91LVdLpsyhgDxpZ8E1c0BRDXcIZOgTgY=; b=ZYpNDZXM3STOKuTRTYXEw+WsyPGJS1Omn9Kd0KlOLoQ7BoxHjiewgGSXIK/P0ud0W1 u5F5DUnrgOOgk3XdqIQ9q/eHrrisvFJl3slY34fm65qcidryp8w18jtq343Z8pylhxfz lkTMV5i104my3Zcx4wFmKk9EQlFNV8/CDhvjDPglQvozDlu7vvFZrD+SpSl0TUkskhKS m5Gs+4Sfgwn8H9zGO0IU+GjDim3f8sRrtucvrGrgNbuYTUuZMU5B2A8uRKA7Xx96bN1t wiFsUpO+sDBmEND5tfWaxRzlFJu8iCAXmcvb415XWww1QT7hW6rdnO0si/iJedNLMd+0 f3gQ== Received: by 10.236.136.3 with SMTP id v3mr15312082yhi.68.1340668794355; Mon, 25 Jun 2012 16:59:54 -0700 (PDT) Received: from [192.168.1.213] (190-20-27-74.baf.movistar.cl. [190.20.27.74]) by mx.google.com with ESMTPS id b58sm136796070yhh.16.2012.06.25.16.59.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 16:59:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_77AB68A4-9219-4B6D-94FA-09A627D6FF3C"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> Date: Mon, 25 Jun 2012 19:59:41 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkacJ9nIabANxnL6cw7gnWcWsnr9YQN4L8yxiLlRWgRmLIOtF4q6pIYhGOROc0zxjRIoV9h Cc: "'Richard L. Barnes'" , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 00:00:05 -0000 --Apple-Mail=_77AB68A4-9219-4B6D-94FA-09A627D6FF3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim, Now that we are mandating JWE sender verification people will be using = JWE with symmetric keys or key agreement. In those cases one can easily argue that the header should be protected = as much as in HMAC. There may well be signing_time or other elements that would go into the = header as well for JWE. Regards John B. On 2012-06-25, at 7:48 PM, Jim Schaad wrote: > >=20 > Richard, >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Richard L. Barnes >> Sent: Monday, June 25, 2012 2:35 PM >> To: Nat Sakimura >> Cc: Mike Jones; jose@ietf.org >> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >> 00.txt >>=20 >> Hi Nat, >>=20 >> I'm not sure what X.509 fiasco you're referring to. There was a = recent > MD5 >> fiasco [1], but that's an attack on MD5, not X.509. In fact, there = have > been >> recommendations for preventing this attack in X.509 since 2005 [2]. = As > was >> noted on the SAAG list, the real news here is that Microsoft wasn't > following >> any of those recommendations. >>=20 >> JWS would have had the same problem as X.509. The attack did not = modify >> the cryptographic parameters (anything that would have gone in the >> header), it would not have been thwarted by the integrity protection = we're >> worrying about. >>=20 >> Actually, the header signing that JWS does makes it even nicer for = the >> attacker: Flame used a "chosen prefix" attack, so since the JWS = header > value >> is entirely static for a given signer, it's easy to use as a fixed = prefix. > If JWS just >> signed the content, then the application could include a something = random >> up front to prevent such prefix-based attacks. >>=20 >=20 > I don't believe that this is a true statement. If you had a prefix or = just > signed what was given to you (i.e. no prefix), it would make no = difference > in terms of the attack for Flame. Flame could always use a fixed = prefix of > its own design rather than using the fixed header that is generated by > having JWS sign the header information. >=20 >> It's tempting to say that we should just add randomness to the JOSE > format. >> But the real lesson of the Flame/MD5 attacks is operational: If = you're > signing >> something that somebody else gave you, make sure that you're not = signing >> exactly what they gave you. Follow the recommendations of RFC 4270. = In >> other contexts, there's no need of similar random elements; it just = adds >> complexity. >=20 > This is definitely a true statement in all events and is something = that > should be added to the Security Considerations section. >=20 > That being said, I think that there are valid reasons for wanting to = protect > the header information by some authentication processing. PKIX = certificates > protect the signature algorithm information (by copying the data into = the to > be signed block) and CMS has long allowed for information to be = included in > the signed attributes area that identifies the algorithms used, the > certificates used and so forth. There are also other things that we = might > find to be convenient to be placed in the header information that is = current > not there (a signing time and embedded content type comes to mind) = that > would be a product either of specific types of signatures or becomes a > common attribute to be placed there. >=20 > In terms of encryption operations, I remember in the past that I have = had > either corrupted encrypted streams or corrupted IVs and had a = successful > decryption that later generated other problems when trying to parse. = This > is less of an issue with AEAD algorithms as they have a much stricter = rule > on when the stream decrypts correctly. >=20 > Jim >=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >> [1] >> [2] >>=20 >>=20 >> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>=20 >>> Especially after the X.509 fiasco, I strongly believe that having > integrity >> check over the metadata is a good thing. It is such a little effort = that > gives us >> much more protection down the road. In this sense, I fully agree with = Ben >> here. We should have integrity protection over the header. >>>=20 >>> Nat >>>=20 >>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >> wrote: >>> Two years ago when the developer community needing a JSON-friendly >> token format was designing the JSON Web Token (JWT), we explicitly = asked >> security experts whether the header parameters should be integrity >> protected or not. Among them, Ben Laurie was one of the voices = saying > that >> securing them was the right thing to do. >>>=20 >>>=20 >>>=20 >>> He argued that if the parameters can be protected in a practical = manner, >> then they should. Doing so provides an additional hurdle that = attackers >> would have to surmount. For example, if they can try to substitute a > weaker >> authentication scheme, then they must figure out how to make it >> authenticate correctly despite some plaintext they can't control - = the > header >> parameters. >>>=20 >>>=20 >>>=20 >>> Ben also took the position that paring security protocols down to = the > least >> you can get away with, given attacks you can think of, is not a good > design >> principle. If there is not a strong argument against including a = feature > that >> may make it harder for attackers, then that feature should be = included. >>>=20 >>>=20 >>>=20 >>> I agree with him. >>>=20 >>>=20 >>>=20 >>> The decision to provide integrity protection for the headers is > documented >> in the session notes at http://self-issued.info/?p=3D361, which said: >>>=20 >>>=20 >>>=20 >>> . What to sign (envelope.payload or just payload)? >>>=20 >>> Given that the envelope is extensible and therefore may contain > security- >> sensitive information, we reached a consensus (with input from Ben = Laurie >> via IM) that the combination envelope.payload must be signed. >>>=20 >>>=20 >>> I believe that logic is as sound today as it was then. >>>=20 >>>=20 >>>=20 >>> For all these reasons, I therefore personally stand by the = community's >> decision to provide integrity protection for the headers. >>>=20 >>>=20 >>>=20 >>> Best = wishes, >>>=20 >>> -- Mike >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> John Bradley >>> Sent: Wednesday, June 20, 2012 3:57 PM >>> To: Richard L.Barnes >>> Cc: jose@ietf.org >>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >> 00.txt >>>=20 >>>=20 >>>=20 >>> Hi Richard, >>>=20 >>>=20 >>>=20 >>> While for PKCS 1.5 the hash algorithm is baked into the padding and = not >> susceptible to modification with ECDH or RSA-PSS it is not. >>>=20 >>> There are possible hash truncation attacks by shortening SHA256 to > SHA224 >> as an example (I know we preclude truncated hashes at the moment). >>>=20 >>>=20 >>>=20 >>> The bad feeling I get around this is that if there is a scenario = where > the >> attacker controls the plaintext to be signed and there is no signer > controlled >> text contributed there are potential bad things that could happen = down the >> road. >>>=20 >>>=20 >>>=20 >>> This bit us with x509 certs not that long ago (yes with MD5 = admittedly) >> where the attacker could use a certificate extension to include extra = data > and >> cause a pre collided hash to be generated. >>>=20 >>> Having part of the signed data outside the control of an attacker is = a > good >> thing. (having a nonce or message ID in the envelope is possible = though > not >> yet required in JWS.) >>>=20 >>>=20 >>>=20 >>> I am still of the opinion that putting the base64 encoded envelope > inside >> the hash calculation is a valid way to allow additional attributes. >>>=20 >>> Another structure to hold the attributes adds more complexity, as = would >> saying that they need to be inside the signed object. >>>=20 >>>=20 >>>=20 >>> I think part of this is that as one of the openID Connect authors I = look > at this >> as a necessary security token format, for OAuth and Connect. >>>=20 >>> For that simple processing with one signature is a high priority for > adoption. >>>=20 >>>=20 >>>=20 >>> =46rom a general signing/encrypting of documents point of view you >> legitimately have different priorities. >>>=20 >>>=20 >>>=20 >>> I know it is hard to prove a negative but It is also going to be > difficult for me >> to go back to security people at google Facebook and other places and >> explain how not integrity protecting the header could be better than >> integrity protecting it. >>>=20 >>>=20 >>>=20 >>> It seems that I would be reduced to arguing that this is no worse = than > CMS >> and that hasn't been proven insecure yet. >>>=20 >>>=20 >>>=20 >>> Allowing a possible attacker to control the hash output, and not > integrity >> protecting the additional data, seems like something I am bound to = regret > in >> the future. >>>=20 >>>=20 >>>=20 >>> Regards >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>=20 >>>=20 >>>=20 >>>> Hey John, >>>=20 >>>>=20 >>>=20 >>>> Interesting points, but I don't think they actually apply here. >>>=20 >>>>=20 >>>=20 >>>> With regard to downgrade attacks: >>>=20 >>>>=20 >>>=20 >>>> The attack that RFC 5752 is concerned with is when an attacker = strips >> signatures from a signed message, so that the only ones left are ones = he > can >> tamper with. So the integrity protection here is "horizontal"; it = goes > across >> signatures. The integrity protection in JWS/JWE is "vertical" -- it = only > protects >> one signer's parameters -- so it is, so to speak, orthogonal. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard to "brown bag" attacks: >>>=20 >>>>=20 >>>=20 >>>> The root of this attack is ambiguity about what content is *signed* >>>=20 >>>> vs. what content is *used*. If an application doesn't verify that >>>=20 >>>> it's actually using the stuff that's signed, then it can be tricked >>>=20 >>>> into accepting something unsigned. (Cf. >>>=20 >>>> ) >>>=20 >>>>=20 >>>=20 >>>> However, I don't think any of the current proposals have that = problem. >> In JWE/JWS, the signed content is right there between the dots, and = in > JSMS, >> it's in the "content" element. The current JSMS draft does allow = detached >> signatures, but with a "voids your warranty" sticker on it. >>>=20 >>>>=20 >>>=20 >>>> In any case, these attacks have nothing to do with whether the >> cryptographic parameters are integrity-protected with the content. = The >> example attacks in the IBM still work regardless -- the whole point = of the >> attack is that the cryptographic processing is the same, only the > (non-crypto) >> matching of content is flawed. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard to "arbitrary attributes": >>>=20 >>>>=20 >>>=20 >>>> We can have that here, too, but you need canonicalization. And > base64- >> encoding is not not canonicalization -- it just waves its hands over = the >> question of equivalence. In my opinion, we should keep the = cryptographic >> object simple by disallowing attributes, and push the attributes you = would >> sign inside of the thing being signed. If people really do want > attributes, it >> doesn't seem to me like JSON canonicalization is very hard. I can do = it > in 19 >> lines of python: >>>=20 >>>> >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard too "meta-data in the body": >>>=20 >>>>=20 >>>=20 >>>> It seems to me like if we're trying to define a general format for > applying >> security protections, then we ought to keep out things that aren't > strictly >> security relevant. Those things can go in application-specific = content > types >> (e.g., SAML) without polluting the general purpose header. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard to "defense in depth" and selling this to government >> agencies: >>>=20 >>>>=20 >>>=20 >>>> CMS, via S/MIME, is in broad use across multiple federal agencies = and >> large enterprises. JSMS is essentially a profile of CMS (see Section = 7), > and >> has the same security properties. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> Cheers, >>>=20 >>>> --Richard >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>=20 >>>>=20 >>>=20 >>>>> Hi Richard, >>>=20 >>>>>=20 >>>=20 >>>>> Originally we only integrity protected the header for signing. We > added >> the integrity protection to encryption as part of AEAD, as encryption = can > also >> be used for sender verification. >>>=20 >>>>>=20 >>>=20 >>>>> I understand the argument that it makes things simpler if we don't >> integrity protect the header information. >>>=20 >>>>>=20 >>>=20 >>>>> However xmldsig, provides integrity over those elements to = prevent >> possible downgrade attacks by manipulating the algorithms. >>>=20 >>>>>=20 >>>=20 >>>>> CMS may not typically provide that integrity protection but I = think > Jim >> Schaad and Sean Terner created RFC5752 to address downgrade attacks. >>>=20 >>>>> Given they are on this list they can speak to their view on = integrity > over >> the crypto parameters. >>>=20 >>>>>=20 >>>=20 >>>>> I also recall when working on InfoCards there was a Monte = Carlo/Brown >> Bag attack that needs to be considered if we move to something more = like a >> detached signature. >>>=20 >>>>>=20 >>>=20 >>>>> The other design consideration is that we wanted to be able to = sign >> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>=20 >>>>> That prevented us from including meta-data in the body as we = didn't >> want to touch it. That left us with the header to include = additional > elements >> in. >>>=20 >>>>> Not integrity protecting those elements as well would be a = problem. >>>=20 >>>>>=20 >>>=20 >>>>> I am not a CMS expert but I believe it allows for signing of > arbitrary >> attributes not unlike the current JOSE spec. >>>=20 >>>>>=20 >>>=20 >>>>> Especially for something that will be used with JWT security = tokens I > will >> have a hard time making the argument to NIST and others that need to >> approve this format that not integrity protecting the header = parameters is >> appropriate defence in depth, for something that might be replacing = signed >> SAML assertions in some applications. >>>=20 >>>>>=20 >>>=20 >>>>> I do understand how not integrity protecting the header will make > some >> things easier, however I can't agree that the benefit outweighs the >> disadvantages. >>>=20 >>>>>=20 >>>=20 >>>>> Regards >>>=20 >>>>> John B. >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>=20 >>>>>=20 >>>=20 >>>>>> Hey Mike, >>>=20 >>>>>>=20 >>>=20 >>>>>> Thanks for having some back-and-forth with me on this. I think = this > is a >> good discussion to have right now. I would like to discuss some > high-level >> points, and then I'll respond inline to your precise points. >>>=20 >>>>>>=20 >>>=20 >>>>>> tl;dr: In order to meet its deliverables, the WG needs to define > JSON- >> based formats for integrity and confidentiality protections. JWE and = JWS >> don't fit that requirement, so we should re-consider their adoption = and > call >> for new candidates. >>>=20 >>>>>>=20 >>>=20 >>>>>> Major points: >>>=20 >>>>>> 1. JOSE is JSON >>>=20 >>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>=20 >>>>>> URL-safeness are still OK, as derivatives >>>=20 >>>>>>=20 >>>=20 >>>>>> Part 1: JOSE is JSON >>>=20 >>>>>>=20 >>>=20 >>>>>> The JOSE WG charter calls out four deliverables, three of which = are >> explicitly required to be JSON: >>>=20 >>>>>> -- "JSON-structured integrity protection" >>>=20 >>>>>> -- "JSON-structured encryption" >>>=20 >>>>>> -- "public keys as JSON-structured objects" >>>=20 >>>>>> (The fourth is just a list of algorithms, which should be JSON as >>>=20 >>>>>> well, just as RFC 3370 is ASN.1.) >>>=20 >>>>>>=20 >>>=20 >>>>>> In light of these requirements, JWE and JWS are clearly not = suitable >>>=20 >>>>>> candidates to fulfill the working group's milestones. (At least = in >>>=20 >>>>>> their current form.) So ISTM that we need to step back and >>>=20 >>>>>> re-evaluate alternatives for the three above milestones, = especially >>>=20 >>>>>> the first two. (JWK is not as far off.) >>>=20 >>>>>>=20 >>>=20 >>>>>> As JSON-based mechanisms, though, the "JSON serialization" drafts >> are pretty half-hearted. Because JWS and JWE include the = cryptographic >> parameters within the integrity protection, they have to have the = headers >> included as base64-encoded strings. That obviously adds a lot of > complexity >> to encoding and decoding -- for example, you have to keep the encoded >> header around even after you've decoded it! -- and just plain more = octets. >> The support for multiple recipients and multiple signatures is both > unweildy >> (matching up parallel indices for headers and signatures) and = inefficient >> (multiple integrity check values in encrypted objects). >>>=20 >>>>>>=20 >>>=20 >>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom = that >> went into CMS, while making the syntax pure JSON and as simple as > possible. >> Multiple signatures and multiple recipients are supported with = absolute >> minimum overhead. So I think it's worth consideration by the working > group. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> Part 2: JSON !=3D> canonicalization >>>=20 >>>>>>=20 >>>=20 >>>>>> I would like to dispel the myth that a JSON-based format requires >>>=20 >>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>=20 >>>>>> "canonicalization" (via base64url encoding) because it's included >>>=20 >>>>>> within the integrity protection. I'm not aware of any reason for >>>=20 >>>>>> including the cryptographic parameters in the integrity check, >>>=20 >>>>>> instead of only integrity-protecting the content itself. Indeed, = if >>>=20 >>>>>> there were an attack based on non-integrity-protected = cryptographic >>>=20 >>>>>> parameters, it would be a pretty big deal, since neither CMS nor = IKE >>>=20 >>>>>> nor provides this protection. (TLS does provide a signature over >>>=20 >>>>>> the algorithms, but only as a way to bind the public key to the >>>=20 >>>>>> session.) >>>=20 >>>>>>=20 >>>=20 >>>>>> Indeed CMS doesn't require canonicalization at all, except for >> attributes that are included in the protected content (signedAttrs / >> authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't >> allow those parameters, so there is no need for canonicalization at = all. > All the >> "canonicalization" that's needed is to base64url-encode the protected >> content. In that regard, JSMS is even simpler than JWE/JWS. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> Part 3: Compactness and URL-safeness are still OK, as derivatives >>>=20 >>>>>>=20 >>>=20 >>>>>> I have absolutely no objection to defining a compact, URL-safe > format. >> Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example > from >> Section 3.1 of the JWS spec, we get the following JSMS object: >>>=20 >>>>>>=20 >>>=20 >>>>>> { >>>=20 >>>>>> "v":1, >>>=20 >>>>>> "t":"au", >>>=20 >>>>>> "a":"hs256", >>>=20 >>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>=20 >>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>=20 >>>>>> "ki":"rSIilRk8Ego" >>>=20 >>>>>> } >>>=20 >>>>>>=20 >>>=20 >>>>>> If we remove the decorative spaces and base64url-encode, we only >> use >>>=20 >>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>=20 >>>>>> further and define an explicit compact format for = AuthenticatedData, >>>=20 >>>>>> we can emulate JWS by moving the content and MAC fields outside >> and >>>=20 >>>>>> dot-combining. That avoids double-base64url-encoding, and only >>>=20 >>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put the = code >>>=20 >>>>>> to generate these in the Github project linked earlier.) >>>=20 >>>>>>=20 >>>=20 >>>>>> So it's fine to have a compact, URL-safe format for an objective, > but it >> makes *much* more sense to derive that from a full-size, usable, JSON >> format than the other way around. >>>=20 >>>>>>=20 >>>=20 >>>>>> Responses to specific points inline below. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> Fair enough. I'll briefly respond to each in turn. Before = doing > so, I'll >> say that I'm writing in the spirit of trying to increase mutual > understanding >> and consensus, rather than taking the point of view that the status = quo is > the >> only reasonable outcome. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> -- Not being JSON >>>=20 >>>>>>>=20 >>>=20 >>>>>>> This was by design, so that the results are URL-safe. This is > required, >> for instance, for them to be used as OAuth Bearer Tokens. At the = request > of >> the working group, closely related pure-JSON drafts were also = published. >> See: >>>=20 >>>>>>>=20 >>>=20 >>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri >>>=20 >>>>>>> alization-01 and >>>=20 >>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser >>>=20 >>>>>>> ialization-01 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Use them if you prefer if they better suit your use cases. They > could >> be adopted as working group documents, if there's interest. >>>=20 >>>>>>=20 >>>=20 >>>>>> See above. These are super-clunky, and the need to be the main >> focus of the WG, not an afterthought. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Not supporting multiple recipients >>>=20 >>>>>>>=20 >>>=20 >>>>>>> The JSON serialization drafts above do, again, in response to = use >> cases presented by the working group. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> See above. Because of the unnecessary inclusion of the header in > the >> integrity check, this is far less efficient than it should be. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lacking clear distinctions between signing and MAC >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Functionally, these are very similar operations, at least from = an >> implementation perspective, so it's not clear that making a clear > distinction >> would help either developers or adoption in any practical way. They > achieve >> overlapping, but admittedly sometimes different goals. I believe = that >> developers can be trusted to use the algorithms that achieve their >> applications' goals without making a hard distinction between the = two. > But >> I'd be interested in hearing your thoughts on why you believe a > brighter-line >> distinction might be useful or necessary. >>>=20 >>>>>>=20 >>>=20 >>>>>> It's important if you want to do MACs with anything other than = pre- >> shared keys. If you want to do anything more advanced, you need to = have >> wrapped keys, in which case an object with a MAC starts to look a lot = more >> like a JWE than a JWS. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lacking clear processing instructions for different key >>>=20 >>>>>>> establishment modalities >>>=20 >>>>>>>=20 >>>=20 >>>>>>> This seems like an area where the existing drafts could be = refined > to >> add descriptions for additional establishment modalities, possibly = based >> upon your ideas and descriptions, should the working group decide to = do > so. >> What additional modalities do you have use cases for that you believe = are >> not achievable or straightforward with the existing drafts? The = existing >> modalities supported are largely those that existing developers had = told > us >> they needed and draw both from the precursor draft-jones-json-web-* >> documents and draft-rescorla-jsms. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Bear in mind that the balance that the current drafts try to = strike > is >> keeping the Mandatory to Implement (MTI) feature footprint small = enough >> that developers, including Web developers, are likely to adopt the = specs, >> while still providing enough functionality to make them generally = useful. > As >> in any balance, it's often possible to shift things a bit and still > maintain the >> balance, but I'd like people to keep the ubiquitous adoption goal > front-and- >> center when proposing additional functionality. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>=20 >>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>=20 >>>>>>> that!) >>>=20 >>>>>>=20 >>>=20 >>>>>> I agree that we need to find a reasonable MTI. The current JSMS > draft >> doesn't really specify which parts are MTI, beyond basic things like > base64url >> encoding and ignoring unknown fields. >>>=20 >>>>>>=20 >>>=20 >>>>>> My main concern is that JWS and JWE don't really tell me which > fields >> need to be present for which use case. If I'm putting a MAC on a JWS = vs. > a >> signature, do I need "jwk" or "jku" fields to be populated? Whereas = in > JSMS, >> I think these things are much clearer due to the separation of the = use > cases >> (Signed/Authenticated/Encrypted) and the isolation of signatures and >> wrapped keys into sub-objects. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lack of clear typing of objects >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Most JSON documents aren't clearly typed; instead, developers = and >> implementations understand from context what the meaning of each = field is. >> XML is clearly typed, but developers are voting with their feet by = moving > to >> JSON. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> What practical advantages resulting from overlaying a typing >> infrastructure on JSON do you believe are worth the potential costs = of > doing >> so? BTW, I'm not opposed to having a JSON schema description of the = JOSE >> JSON data structures like JSMS did in = http://tools.ietf.org/html/draft- >> rescorla-jsms-00#appendix-A, but I'll remark that this an informative > tool, not >> a normative one. >>>=20 >>>>>>=20 >>>=20 >>>>>> I actualy don't have a hugely urgent requirement here either. = It's >> something that others in the WG had requested, which is trivial to = add in >> JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity >> protection of the header. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lack of versioning for future extensibility >>>=20 >>>>>>>=20 >>>=20 >>>>>>> An optional version field could be added if the working group >>>=20 >>>>>>> desires, however the last time the working group discussed it, = they >>>=20 >>>>>>> decided not to do so. Rather, specs like this effectively = become >>>=20 >>>>>>> "versioned" when revised in a way that new fields are added. If >>>=20 >>>>>>> you understand the new fields, you support that new version. = (Note >>>=20 >>>>>>> that this is independent of whether there is a version number >>>=20 >>>>>>> field, which according to some participants in the previous >>>=20 >>>>>>> discussion, they regarded as therefore being redundant >>>=20 >>>>>>> information.) >>>=20 >>>>>>>=20 >>>=20 >>>>>>> I'm not religious about not having a version number field, but > often >> "less is more". >>>=20 >>>>>>=20 >>>=20 >>>>>> Indeed, I'm not religious either. It just seems like a general = good > idea >> to state this directly as opposed to having parsers divine it based = on > which >> fields are present. To quote RFC 5652: >>>=20 >>>>>> " >>>=20 >>>>>> Each of the major data structures includes a version number as = the >>>=20 >>>>>> first item in the data structure. The version numbers are = intended >>>=20 >>>>>> to avoid ASN.1 decode errors. Some implementations do not check >> the >>>=20 >>>>>> version number prior to attempting a decode, and if a decode = error >>>=20 >>>>>> occurs, then the version number is checked as part of the error >>>=20 >>>>>> handling routine. This is a reasonable approach; it places error >>>=20 >>>>>> processing outside of the fast path. This approach is also >>>=20 >>>>>> forgiving when an incorrect version number is used by the = sender. >>>=20 >>>>>> " >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> Best, >>>=20 >>>>>> --Richard >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Best wishes, >>>=20 >>>>>>> -- Mike >>>=20 >>>>>>>=20 >>>=20 >>>>>>> -----Original Message----- >>>=20 >>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>=20 >>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>=20 >>>>>>> To: Mike Jones >>>=20 >>>>>>> Cc: jose@ietf.org >>>=20 >>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>=20 >>>>>>> draft-barnes-jose-jsms-00.txt >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Ok, so maybe I should have phrased my lead-in differently. IMO, > the >> current JW* specs are deficient in several ways, e.g.: >>>=20 >>>>>>> -- Not being JSON >>>=20 >>>>>>> -- Not supporting multiple recipients >>>=20 >>>>>>> -- Lacking clear distinctions between signing and MAC >>>=20 >>>>>>> -- Lacking clear processing instructions for different key >>>=20 >>>>>>> establishment modalities >>>=20 >>>>>>> -- Lack of clear typing of objects >>>=20 >>>>>>> -- Lack of versioning for future extensibility >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Looking at the current specs, it didn't seem to me that it would = be >> simple to adapt them to address these deficiencies. So I just did a > re-write. >> If you think they can be addressed within the current framework, = please >> explain. I just found it simpler to start from whole cloth. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Cheers, >>>=20 >>>>>>> --Richard >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>=20 >>>>>>>=20 >>>=20 >>>>>>>> Hi Richard, >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> If you're puzzled by specific design decisions in the JOSE > documents, >> I encourage you to ask about them on the list. The documents have >> significant history going back to mid-2010 when convergence = discussions >> started among people with four different JSON signing & encryption >> proposals. JWT and the current JOSE specs and implementations are = the >> result. I realize that not all the JOSE participants were part of = those >> discussions from the beginning (although many were) and so teasing = out the >> rationale for specific decisions might help people better understand = the >> choices made, and hopefully thereby increase consensus behind the >> eventual working group choices. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> If the list that you're puzzled by is the bulleted list below, > maybe we >> can start a discussion on that basis. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Best wishes, >>>=20 >>>>>>>> -- Mike >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> -----Original Message----- >>>=20 >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>=20 >>>>>>>> Behalf Of Richard L. Barnes >>>=20 >>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>=20 >>>>>>>> To: jose@ietf.org >>>=20 >>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>=20 >>>>>>>> draft-barnes-jose-jsms-00.txt >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Dear JOSE WG, >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Like Mr. Manger, once I finally got around to doing a thorough >> review of the JW* specs, I was kind of puzzled by some of the design >> decisions. So I also went through and wrote an alternative format, = this > time >> taking a more of a cue from CMS. A link to the document is below. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Summary of differences: >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>=20 >>>>>>>> parameters are represented in JSON. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS allows for full algorithm agility in key agreement, = while > JWE >>>=20 >>>>>>>> only allows ECDH-ES. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>=20 >>>>>>>> AuthenticatedData objects via the inclusion of multiple >> WrappedKey >>>=20 >>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>=20 >>>>>>>> encryption of the entire object for each recipient. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o The signature and MAC functions of the JWS object are = separated >>>=20 >>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS parameters are not integrity-protected, as they are in = JWE >>>=20 >>>>>>>> and JWS. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, but > could >>>=20 >>>>>>>> be added without significant change. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>=20 >>>>>>>> parameters, in order to facilitate extensibility. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> I've also thrown together an initial JavaScript implementation > (based >> on NodeJS for some python crypto glue), which is on github: >>>=20 >>>>>>>> >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Comments are very welcome. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Thanks, >>>=20 >>>>>>>> --Richard >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Begin forwarded message: >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>> From: internet-drafts@ietf.org >>>=20 >>>>>>>>> Subject: New Version Notification for >>>=20 >>>>>>>>> draft-barnes-jose-jsms-00.txt >>>=20 >>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>=20 >>>>>>>>> To: rbarnes@bbn.com >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>=20 >>>>>>>>> successfully submitted by Richard Barnes and posted to the = IETF >>>=20 >>>>>>>>> repository. >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> Filename: draft-barnes-jose-jsms >>>=20 >>>>>>>>> Revision: 00 >>>=20 >>>>>>>>> Title: JavaScript Message Security Format >>>=20 >>>>>>>>> Creation date: 2012-06-15 >>>=20 >>>>>>>>> WG ID: Individual Submission >>>=20 >>>>>>>>> Number of pages: 25 >>>=20 >>>>>>>>> URL: > http://www.ietf.org/internet-drafts/draft-barnes-jose- >> jsms-00.txt >>>=20 >>>>>>>>> Status: > http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>=20 >>>>>>>>> Htmlized: > http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> Abstract: >>>=20 >>>>>>>>> Many applications require the ability to send = cryptographically >>>=20 >>>>>>>>> secured messages. While the IETF has defined a number of >> formats >>>=20 >>>>>>>>> for such messages (e.g. CMS) those formats use encodings = which >>>=20 >>>>>>>>> are not easy to use in modern applications. This document >>>=20 >>>>>>>>> describes the JavaScript Message Security format (JSMS), a new >>>=20 >>>>>>>>> cryptographic message format which is based on JavaScript = Object >>>=20 >>>>>>>>> Notation (JSON) and thus is easy for many applications to > generate >> and parse. >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> The IETF Secretariat >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> _______________________________________________ >>>=20 >>>>>>>> jose mailing list >>>=20 >>>>>>>> jose@ietf.org >>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> _______________________________________________ >>>=20 >>>>>>>> jose mailing list >>>=20 >>>>>>>> jose@ietf.org >>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> _______________________________________________ >>>=20 >>>>>>> jose mailing list >>>=20 >>>>>>> jose@ietf.org >>>=20 >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>>=20 >>>=20 >>>>>> _______________________________________________ >>>=20 >>>>>> jose mailing list >>>=20 >>>>>> jose@ietf.org >>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>=20 >>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_77AB68A4-9219-4B6D-94FA-09A627D6FF3C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NTIzNTk0MlowIwYJKoZIhvcNAQkEMRYEFGa2nHTBSwaId54Z1tTWdE96BWscMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFI4/y1I5snPHJC6goYOmO+QDDjmvwckE38QrPHFqiMXQNN8wSRpzV9in3r+2N0uMw3Am/9XzBkR QCR9hwZhbTHdGS0c7TjVE5414NyZfLVIMYdsHhSyWOSmYBhQGsX3G10clrDPo/Q/aifkrxB1yiKV fHTZMPMYg9zoTIKgt9N3IE8F/xnVPDe7bl5lhSaMskuoW93rOUfxrkxzWOdbq7NDb+ABsQBO0vyN BJEVY0dJL/lB26hQa/fGIRpBYJ5OY6pMLjSPs5g+aKo7XRDhYAP0vRQVreTENpr/e9shVmEtHzrJ o9YaYBmDhjWCHwPvL1MT+Lh0xvWtJMGe948gc18AAAAAAAA= --Apple-Mail=_77AB68A4-9219-4B6D-94FA-09A627D6FF3C-- From bcampbell@pingidentity.com Tue Jun 26 09:17:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C6721F84CE for ; Tue, 26 Jun 2012 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IqpwnOwbqXv for ; Tue, 26 Jun 2012 09:17:10 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6318721F84B4 for ; Tue, 26 Jun 2012 09:17:09 -0700 (PDT) Received: from mail-ob0-f178.google.com ([209.85.214.178]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKT+ngg6wAE7ab6lJrOV53CGk4XoP7El9E@postini.com; Tue, 26 Jun 2012 09:17:09 PDT Received: by obbwd20 with SMTP id wd20so103878obb.23 for ; Tue, 26 Jun 2012 09:17:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=v4qGGh8cpyuhjvRghosW6NrsU3iywj24bvswZwCNdTE=; b=KgLMsHIgpAeSmGj0vU4QK90oWj2NFB7gMIOeTBCjZgxqBullYGSkfzm86Fg2QZQ9Y7 3MA/yCjydjQI4aD3ZAy/VxLIejKYFlaUjH5lkpBQMOntumWScoaWZ2nY5sESE6s8IC36 Htpu/rVeT7XUTKCcTgXSOVueiH3mEp1Qa2PCCWQxJuYYwzPzoajAkupnY8HbFFnhUODy ymQ1enC2QIzKFwHFjuFRYimtfLNDubzd+4c0t/FKgrUfZ0zlyWmEAm4m/OKtiLcSjuq+ FUeJBaPcv1LckWvXoq6M/MpNhNBB6IpDMBSLRUtAr88iO8Jpp9dDy3taXlb5Oiq3yldK ZAXg== Received: by 10.182.179.98 with SMTP id df2mr17061162obc.20.1340727426938; Tue, 26 Jun 2012 09:17:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.174.98 with HTTP; Tue, 26 Jun 2012 09:16:36 -0700 (PDT) In-Reply-To: <8C25B651-4E65-4D6F-AA9F-F76C98626E54@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> <6E84631F-F6C2-43F7-9B65-E57841E4E858@bbn.com> <8C25B651-4E65-4D6F-AA9F-F76C98626E54@bbn.com> From: Brian Campbell Date: Tue, 26 Jun 2012 10:16:36 -0600 Message-ID: To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkcaFNVDxUZdhe3Xnyaium21oLlNB+ZAvO9k4ctBI2B+tCxccRQmeBme4p2YMXiRVm2Mgaj Cc: John Bradley , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 16:17:11 -0000 I wasn't suggesting that integrity-protecting the header itself makes things simpler. Rather that a desirable goal is for support of a relatively simple model utilizing a single signature over the whole message. And that we already have that in JWS. On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes wrote: > > On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: > >>>> I think part of this is that as one of the openID Connect authors I lo= ok at this as a necessary security token format, for OAuth and Connect. >>>> For that simple processing with one signature is a high priority for a= doption. >>> >>> +1. >>> >>> A simple JSON friendly model supporting a single signature over the >>> entire message (including headers) is an important case for adoption >>> (and security). JWS provides that now and there are already numerous >>> interoperable JWS implementations available or in the works. >> >> I'm not sure how people think that integrity-protecting the header makes= things *simpler*, especially since it adds a whole new decoding step and m= akes the parsing more complicated. >> >> Pseudocode without integrity protection (assuming JSMS format, but JWS c= ould be made to look similar): >> function verify(json) { >> =A0 =A0jose =3D JSON.parse(json); >> =A0 =A0// Check algorithm values >> =A0 =A0return Crypto.SignatureAlgorithm.verify(jose.content, jose.keys[0= ].signature, jose.keys[0].key); >> } >> >> Pseudocode with integrity protection (assuming JWS format): >> function verify(jws) { >> =A0 =A0(txtHeader, content, signature) =3D jws.split("\."); >> =A0 =A0protectedBody =3D header + "." + content >> =A0 =A0jsonHeader =3D base64url.decode(txtHeader); >> =A0 =A0header =3D JSON.parse(jsonHeader); >> =A0 =A0return Crypto.SignatureAlgorithm.verify(content, signature, heade= r.jwk); >> } >> > > Err, sorry, that should read: > =A0 =A0protectedBody =3D txtHeader + "." + content; > and > =A0 =A0return Crypto.SignatureAlgorithm.verify(protectedBody, signature, = header.jwk); > > See how hard it is to get right? =A0:) > > --Richard From rbarnes@bbn.com Tue Jun 26 10:25:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E96A21F854D for ; Tue, 26 Jun 2012 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.446 X-Spam-Level: X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PSS5WfaGfjf for ; Tue, 26 Jun 2012 10:25:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0821F8549 for ; Tue, 26 Jun 2012 10:25:23 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:59401) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjZVI-0004Td-Jy; Tue, 26 Jun 2012 13:24:40 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> Date: Tue, 26 Jun 2012 13:25:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Tue, 26 Jun 2012 17:25:24 -0000 I think we agree about what Matt's document is doing. To summarize: Sender -> Receiver: { alg: none, enc, iv } [protected body] Receiver -> Sender: Sender -> Receiver: { kid, alg } [encrypted CMK] (Note that technically, this document doesn't use JWE at *all*, since at = no point in the protocol is there an actual JWE-encoded object.) This has a lot to do with integrity protection, actually. What the = above scheme does is remove all JWE header parameters besides "alg" and = "enc" from integrity protection. So, for example, there's no integrity = protection on the "kid", "jwk", or "x5t" parameters, nor for the JWE = Encrypted Key. =20 Are you OK with that? Would you be OK with a variant in which the = initial JWE had no header at all? After all, the recipient can actually = use the parameters until it does the transaction. BTW, Matt: If I were designing this, I would simplify it even further: Sender -> Receiver: [encrypted content] Receiver -> Sender: Sender -> Receiver: { version: 1, type: "encrypted", algorithm: [algorithm], mac: [ICV], keys: [WrappedKey for kid] } As I mentioned above, there's no reason to send the algorithms on the = first shot, since the recipient can't use them anyway. This way, the = recipient can just toss the encrypted content into the "content" field = of the JSMS object, then process it like normal. =20 Alternatively, you could provide a whole JSMS EncryptedData object on = the first shot, with WrappedKeys for keys you know. Then, if a = recipient doesn't find a WrappedKey for himself, he can for it, = and you can just respond with the WrappedKey. --Richard On Jun 25, 2012, at 7:02 PM, John Bradley wrote: > Richard, >=20 > There was some other back and for with Matt. >=20 > He is only encrypting to one recipient at a time. >=20 > Not that encrypting the CMK to multiple recipients is not valid, that = is just not how the protocol works. >=20 > The message is encrypted once and whatever endpoint gets it calls back = to the sender to get the key. >=20 > The issue as I understand it is that the sender doesn't know the = public key for the recipient before it sends the message. >=20 > I am happy to work on Matts issues, but I think they are separate from = the point you are making on integrity protecting the header. >=20 >=20 > John B. >=20 > On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >=20 >>> Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: >>> "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" >>=20 >> He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >>=20 >> Compare JSMS and the WrappedKey structure, or CMS and RecipientInfo. >> >> >>=20 >>=20 >>> I should also point out that the messages are transported in XML, = and as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>=20 >>> There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>=20 >>> For the transmission of the messages, I can't see any reason to not = use the JWE spec as currently written. It certainly supports the use = case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>=20 >>> Currently the message on the wire looks like: >>>=20 >>> >> from=3D'juliet@capulet.lit/balcony' >>> id=3D'fJZd9WFIIwNjFctT' >>> to=3D'romeo@montegue.lit/garden' >>> type=3D'chat'> >>> >> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>
>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>> NpemUiOiIxNiJ9 >>>
>>> >>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>> eCGP >>> >>> >>> >>> >>>=20 >>> I would have sent header and data as one element using the normal = JWE dot separated format, but I need to talk to Matt to understand his = reasoning. >>>=20 >>> I note that his example is using AES-CCM, and so not documented in = JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>=20 >> Valid point. I had missed that RFC 5084 handled the ICV separately. >>=20 >>=20 >>> I don't quite get your point on integrity protecting the wrapped key = causing the integrity value to change. For HMAC, GCM, and I think CCM, = changing the encryption key changes the tag value anyway (sort of the = point I thought). The only time it would stay the same would be if you = were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >>=20 >> The point is that you have to re-compute the ICV over the entire = header+content every time you wrap a new key. This is kind of a big = deal for the XMPP case. =20 >>=20 >> Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >>=20 >> So integrity protecting the headers has real costs in terms of both = scalability (state) and security. >>=20 >>=20 >>> There are some interesting things Matt=92s spec is attempting with = using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>=20 >> My point is that we shouldn't need a whole new protocol for this. = CMS RecipientInfos do exactly what we want. (Er, what *Matt* wants.) = We should just be copying and pasting. >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> I am happy to work with Matt to refine his ID. >>>=20 >>> I recommend others read it as well so we can understand if there are = any real issues. >>>=20 >>> Regards >>> John B. >>>=20 >>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>=20 >>>> Hey John, >>>>=20 >>>> I think you're missing the bigger point here, which is: In order to = allow for multiple recipients, Matt had to break JWE. >>>>=20 >>>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>=20 >>>>> Hi Matt, >>>>>=20 >>>>> Complements on updating the draft. >>>>>=20 >>>>> The issue I see is that you are attempting to distribute the CMK = out of band and use "none" as the alg. >>>>>=20 >>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>=20 >>>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>>> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>>>>=20 >>>>> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>>>>=20 >>>>> So in your spec I would expect you to distribute a shared secret = via keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>>>>=20 >>>>> I also suspect that you intended to use A256GCM as the enc alg and = not A256CCM.=20 >>>>>=20 >>>>> I am not a XMPP expert so it will take me some time to go over it = in detail. I would like to understand the use case to be certain it is = properly supported. >>>>>=20 >>>>> Regards >>>>> John B. >>>>>=20 >>>>>=20 >>>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>>=20 >>>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been updated = to the latest JOSE WG drafts. >>>>>>=20 >>>>>>=20 >>>>>> - m&m >>>>>>=20 >>>>>> Matt Miller - >>>>>> Cisco Systems, Inc. >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>>> To: i-d-announce@ietf.org >>>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>=20 >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>=20 >>>>>>>=20 >>>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>>> Author(s) : Matthew Miller >>>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>>> Pages : 22 >>>>>>> Date : 2012-06-21 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This document defines a method of end-to-end object encryption = for >>>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>>=20 >>>>>>> A diff from previous version is available at: >>>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>>>>=20 >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>=20 >>=20 >=20 From rbarnes@bbn.com Tue Jun 26 10:42: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 17FBD11E8080 for ; Tue, 26 Jun 2012 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1C0XwPFANAj for ; Tue, 26 Jun 2012 10:42:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7D11E8072 for ; Tue, 26 Jun 2012 10:42:05 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:59459) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjZm8-0004Fr-D1; Tue, 26 Jun 2012 13:42:04 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard L. Barnes In-Reply-To: <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> Date: Tue, 26 Jun 2012 13:42:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8131C5B3-5E38-4686-82AA-74018A36CCF6@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:42:08 -0000 >> I'm not sure what X.509 fiasco you're referring to. There was a = recent > MD5 >> fiasco [1], but that's an attack on MD5, not X.509. In fact, there = have > been >> recommendations for preventing this attack in X.509 since 2005 [2]. = As > was >> noted on the SAAG list, the real news here is that Microsoft wasn't > following >> any of those recommendations. >>=20 >> JWS would have had the same problem as X.509. The attack did not = modify >> the cryptographic parameters (anything that would have gone in the >> header), it would not have been thwarted by the integrity protection = we're >> worrying about. >>=20 >> Actually, the header signing that JWS does makes it even nicer for = the >> attacker: Flame used a "chosen prefix" attack, so since the JWS = header > value >> is entirely static for a given signer, it's easy to use as a fixed = prefix. > If JWS just >> signed the content, then the application could include a something = random >> up front to prevent such prefix-based attacks. >>=20 >=20 > I don't believe that this is a true statement. If you had a prefix or = just > signed what was given to you (i.e. no prefix), it would make no = difference > in terms of the attack for Flame. Flame could always use a fixed = prefix of > its own design rather than using the fixed header that is generated by > having JWS sign the header information. I'm not sure I agree. It's not really useful to speculate with full = generality. Flame didn't choose the format; X.509/PKIX did. So we have = to imagine that the attacker is exploiting an existing signed object = format. My point is that JWS defeats protections that such applications = apply. Suppose we have something like X.509 that we want to sign with JWS. The = application does the right thing and randomizes things at the beginning = like serial numbers and validity dates. If the application content were = signed under CMS or JSMS, the encapsulated content would be just be the = application content C. If it were signed with JWS, the encapsulated = content would be "H.C", where H is the large, predictable JWS header. = So even if the application tries to defend itself, JWS makes it = vulnerable to prefix attacks. (=46rom this perspective, even CMS signed parameters are harmful, in = terms of creating fixed prefixes. It's somewhat less than JWS, however, = because they're (1) shorter, and (2) binary.) =20 >> It's tempting to say that we should just add randomness to the JOSE > format. >> But the real lesson of the Flame/MD5 attacks is operational: If = you're > signing >> something that somebody else gave you, make sure that you're not = signing >> exactly what they gave you. Follow the recommendations of RFC 4270. = In >> other contexts, there's no need of similar random elements; it just = adds >> complexity. >=20 > This is definitely a true statement in all events and is something = that > should be added to the Security Considerations section. >=20 > That being said, I think that there are valid reasons for wanting to = protect > the header information by some authentication processing. PKIX = certificates > protect the signature algorithm information (by copying the data into = the to > be signed block) and CMS has long allowed for information to be = included in > the signed attributes area that identifies the algorithms used, the > certificates used and so forth. There are also other things that we = might > find to be convenient to be placed in the header information that is = current > not there (a signing time and embedded content type comes to mind) = that > would be a product either of specific types of signatures or becomes a > common attribute to be placed there. If we want to enable signed attributes, I would be OK with that. One = thing about *not* having mandatory header protection is that if an = application feels that it needs header protection, then it can copy the = headers it's concerned about into the body. Enabling = integrity-protected attributes in JOSE is one approach, which would save = applications some of the burden of figuring out how to include things in = the body. Personally, I would rather punt on this for now. --Richard > In terms of encryption operations, I remember in the past that I have = had > either corrupted encrypted streams or corrupted IVs and had a = successful > decryption that later generated other problems when trying to parse. = This > is less of an issue with AEAD algorithms as they have a much stricter = rule > on when the stream decrypts correctly. >=20 > Jim >=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >> [1] >> [2] >>=20 >>=20 >> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>=20 >>> Especially after the X.509 fiasco, I strongly believe that having > integrity >> check over the metadata is a good thing. It is such a little effort = that > gives us >> much more protection down the road. In this sense, I fully agree with = Ben >> here. We should have integrity protection over the header. >>>=20 >>> Nat >>>=20 >>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >> wrote: >>> Two years ago when the developer community needing a JSON-friendly >> token format was designing the JSON Web Token (JWT), we explicitly = asked >> security experts whether the header parameters should be integrity >> protected or not. Among them, Ben Laurie was one of the voices = saying > that >> securing them was the right thing to do. >>>=20 >>>=20 >>>=20 >>> He argued that if the parameters can be protected in a practical = manner, >> then they should. Doing so provides an additional hurdle that = attackers >> would have to surmount. For example, if they can try to substitute a > weaker >> authentication scheme, then they must figure out how to make it >> authenticate correctly despite some plaintext they can't control - = the > header >> parameters. >>>=20 >>>=20 >>>=20 >>> Ben also took the position that paring security protocols down to = the > least >> you can get away with, given attacks you can think of, is not a good > design >> principle. If there is not a strong argument against including a = feature > that >> may make it harder for attackers, then that feature should be = included. >>>=20 >>>=20 >>>=20 >>> I agree with him. >>>=20 >>>=20 >>>=20 >>> The decision to provide integrity protection for the headers is > documented >> in the session notes at http://self-issued.info/?p=3D361, which said: >>>=20 >>>=20 >>>=20 >>> . What to sign (envelope.payload or just payload)? >>>=20 >>> Given that the envelope is extensible and therefore may contain > security- >> sensitive information, we reached a consensus (with input from Ben = Laurie >> via IM) that the combination envelope.payload must be signed. >>>=20 >>>=20 >>> I believe that logic is as sound today as it was then. >>>=20 >>>=20 >>>=20 >>> For all these reasons, I therefore personally stand by the = community's >> decision to provide integrity protection for the headers. >>>=20 >>>=20 >>>=20 >>> Best = wishes, >>>=20 >>> -- Mike >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> John Bradley >>> Sent: Wednesday, June 20, 2012 3:57 PM >>> To: Richard L.Barnes >>> Cc: jose@ietf.org >>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >> 00.txt >>>=20 >>>=20 >>>=20 >>> Hi Richard, >>>=20 >>>=20 >>>=20 >>> While for PKCS 1.5 the hash algorithm is baked into the padding and = not >> susceptible to modification with ECDH or RSA-PSS it is not. >>>=20 >>> There are possible hash truncation attacks by shortening SHA256 to > SHA224 >> as an example (I know we preclude truncated hashes at the moment). >>>=20 >>>=20 >>>=20 >>> The bad feeling I get around this is that if there is a scenario = where > the >> attacker controls the plaintext to be signed and there is no signer > controlled >> text contributed there are potential bad things that could happen = down the >> road. >>>=20 >>>=20 >>>=20 >>> This bit us with x509 certs not that long ago (yes with MD5 = admittedly) >> where the attacker could use a certificate extension to include extra = data > and >> cause a pre collided hash to be generated. >>>=20 >>> Having part of the signed data outside the control of an attacker is = a > good >> thing. (having a nonce or message ID in the envelope is possible = though > not >> yet required in JWS.) >>>=20 >>>=20 >>>=20 >>> I am still of the opinion that putting the base64 encoded envelope > inside >> the hash calculation is a valid way to allow additional attributes. >>>=20 >>> Another structure to hold the attributes adds more complexity, as = would >> saying that they need to be inside the signed object. >>>=20 >>>=20 >>>=20 >>> I think part of this is that as one of the openID Connect authors I = look > at this >> as a necessary security token format, for OAuth and Connect. >>>=20 >>> For that simple processing with one signature is a high priority for > adoption. >>>=20 >>>=20 >>>=20 >>> =46rom a general signing/encrypting of documents point of view you >> legitimately have different priorities. >>>=20 >>>=20 >>>=20 >>> I know it is hard to prove a negative but It is also going to be > difficult for me >> to go back to security people at google Facebook and other places and >> explain how not integrity protecting the header could be better than >> integrity protecting it. >>>=20 >>>=20 >>>=20 >>> It seems that I would be reduced to arguing that this is no worse = than > CMS >> and that hasn't been proven insecure yet. >>>=20 >>>=20 >>>=20 >>> Allowing a possible attacker to control the hash output, and not > integrity >> protecting the additional data, seems like something I am bound to = regret > in >> the future. >>>=20 >>>=20 >>>=20 >>> Regards >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>=20 >>>=20 >>>=20 >>>> Hey John, >>>=20 >>>>=20 >>>=20 >>>> Interesting points, but I don't think they actually apply here. >>>=20 >>>>=20 >>>=20 >>>> With regard to downgrade attacks: >>>=20 >>>>=20 >>>=20 >>>> The attack that RFC 5752 is concerned with is when an attacker = strips >> signatures from a signed message, so that the only ones left are ones = he > can >> tamper with. So the integrity protection here is "horizontal"; it = goes > across >> signatures. The integrity protection in JWS/JWE is "vertical" -- it = only > protects >> one signer's parameters -- so it is, so to speak, orthogonal. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard to "brown bag" attacks: >>>=20 >>>>=20 >>>=20 >>>> The root of this attack is ambiguity about what content is *signed* >>>=20 >>>> vs. what content is *used*. If an application doesn't verify that >>>=20 >>>> it's actually using the stuff that's signed, then it can be tricked >>>=20 >>>> into accepting something unsigned. (Cf. >>>=20 >>>> ) >>>=20 >>>>=20 >>>=20 >>>> However, I don't think any of the current proposals have that = problem. >> In JWE/JWS, the signed content is right there between the dots, and = in > JSMS, >> it's in the "content" element. The current JSMS draft does allow = detached >> signatures, but with a "voids your warranty" sticker on it. >>>=20 >>>>=20 >>>=20 >>>> In any case, these attacks have nothing to do with whether the >> cryptographic parameters are integrity-protected with the content. = The >> example attacks in the IBM still work regardless -- the whole point = of the >> attack is that the cryptographic processing is the same, only the > (non-crypto) >> matching of content is flawed. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard to "arbitrary attributes": >>>=20 >>>>=20 >>>=20 >>>> We can have that here, too, but you need canonicalization. And > base64- >> encoding is not not canonicalization -- it just waves its hands over = the >> question of equivalence. In my opinion, we should keep the = cryptographic >> object simple by disallowing attributes, and push the attributes you = would >> sign inside of the thing being signed. If people really do want > attributes, it >> doesn't seem to me like JSON canonicalization is very hard. I can do = it > in 19 >> lines of python: >>>=20 >>>> >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard too "meta-data in the body": >>>=20 >>>>=20 >>>=20 >>>> It seems to me like if we're trying to define a general format for > applying >> security protections, then we ought to keep out things that aren't > strictly >> security relevant. Those things can go in application-specific = content > types >> (e.g., SAML) without polluting the general purpose header. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> With regard to "defense in depth" and selling this to government >> agencies: >>>=20 >>>>=20 >>>=20 >>>> CMS, via S/MIME, is in broad use across multiple federal agencies = and >> large enterprises. JSMS is essentially a profile of CMS (see Section = 7), > and >> has the same security properties. >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> Cheers, >>>=20 >>>> --Richard >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>>=20 >>>=20 >>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>=20 >>>>=20 >>>=20 >>>>> Hi Richard, >>>=20 >>>>>=20 >>>=20 >>>>> Originally we only integrity protected the header for signing. We > added >> the integrity protection to encryption as part of AEAD, as encryption = can > also >> be used for sender verification. >>>=20 >>>>>=20 >>>=20 >>>>> I understand the argument that it makes things simpler if we don't >> integrity protect the header information. >>>=20 >>>>>=20 >>>=20 >>>>> However xmldsig, provides integrity over those elements to = prevent >> possible downgrade attacks by manipulating the algorithms. >>>=20 >>>>>=20 >>>=20 >>>>> CMS may not typically provide that integrity protection but I = think > Jim >> Schaad and Sean Terner created RFC5752 to address downgrade attacks. >>>=20 >>>>> Given they are on this list they can speak to their view on = integrity > over >> the crypto parameters. >>>=20 >>>>>=20 >>>=20 >>>>> I also recall when working on InfoCards there was a Monte = Carlo/Brown >> Bag attack that needs to be considered if we move to something more = like a >> detached signature. >>>=20 >>>>>=20 >>>=20 >>>>> The other design consideration is that we wanted to be able to = sign >> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>=20 >>>>> That prevented us from including meta-data in the body as we = didn't >> want to touch it. That left us with the header to include = additional > elements >> in. >>>=20 >>>>> Not integrity protecting those elements as well would be a = problem. >>>=20 >>>>>=20 >>>=20 >>>>> I am not a CMS expert but I believe it allows for signing of > arbitrary >> attributes not unlike the current JOSE spec. >>>=20 >>>>>=20 >>>=20 >>>>> Especially for something that will be used with JWT security = tokens I > will >> have a hard time making the argument to NIST and others that need to >> approve this format that not integrity protecting the header = parameters is >> appropriate defence in depth, for something that might be replacing = signed >> SAML assertions in some applications. >>>=20 >>>>>=20 >>>=20 >>>>> I do understand how not integrity protecting the header will make > some >> things easier, however I can't agree that the benefit outweighs the >> disadvantages. >>>=20 >>>>>=20 >>>=20 >>>>> Regards >>>=20 >>>>> John B. >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>=20 >>>>>=20 >>>=20 >>>>>> Hey Mike, >>>=20 >>>>>>=20 >>>=20 >>>>>> Thanks for having some back-and-forth with me on this. I think = this > is a >> good discussion to have right now. I would like to discuss some > high-level >> points, and then I'll respond inline to your precise points. >>>=20 >>>>>>=20 >>>=20 >>>>>> tl;dr: In order to meet its deliverables, the WG needs to define > JSON- >> based formats for integrity and confidentiality protections. JWE and = JWS >> don't fit that requirement, so we should re-consider their adoption = and > call >> for new candidates. >>>=20 >>>>>>=20 >>>=20 >>>>>> Major points: >>>=20 >>>>>> 1. JOSE is JSON >>>=20 >>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>=20 >>>>>> URL-safeness are still OK, as derivatives >>>=20 >>>>>>=20 >>>=20 >>>>>> Part 1: JOSE is JSON >>>=20 >>>>>>=20 >>>=20 >>>>>> The JOSE WG charter calls out four deliverables, three of which = are >> explicitly required to be JSON: >>>=20 >>>>>> -- "JSON-structured integrity protection" >>>=20 >>>>>> -- "JSON-structured encryption" >>>=20 >>>>>> -- "public keys as JSON-structured objects" >>>=20 >>>>>> (The fourth is just a list of algorithms, which should be JSON as >>>=20 >>>>>> well, just as RFC 3370 is ASN.1.) >>>=20 >>>>>>=20 >>>=20 >>>>>> In light of these requirements, JWE and JWS are clearly not = suitable >>>=20 >>>>>> candidates to fulfill the working group's milestones. (At least = in >>>=20 >>>>>> their current form.) So ISTM that we need to step back and >>>=20 >>>>>> re-evaluate alternatives for the three above milestones, = especially >>>=20 >>>>>> the first two. (JWK is not as far off.) >>>=20 >>>>>>=20 >>>=20 >>>>>> As JSON-based mechanisms, though, the "JSON serialization" drafts >> are pretty half-hearted. Because JWS and JWE include the = cryptographic >> parameters within the integrity protection, they have to have the = headers >> included as base64-encoded strings. That obviously adds a lot of > complexity >> to encoding and decoding -- for example, you have to keep the encoded >> header around even after you've decoded it! -- and just plain more = octets. >> The support for multiple recipients and multiple signatures is both > unweildy >> (matching up parallel indices for headers and signatures) and = inefficient >> (multiple integrity check values in encrypted objects). >>>=20 >>>>>>=20 >>>=20 >>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom = that >> went into CMS, while making the syntax pure JSON and as simple as > possible. >> Multiple signatures and multiple recipients are supported with = absolute >> minimum overhead. So I think it's worth consideration by the working > group. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> Part 2: JSON !=3D> canonicalization >>>=20 >>>>>>=20 >>>=20 >>>>>> I would like to dispel the myth that a JSON-based format requires >>>=20 >>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>=20 >>>>>> "canonicalization" (via base64url encoding) because it's included >>>=20 >>>>>> within the integrity protection. I'm not aware of any reason for >>>=20 >>>>>> including the cryptographic parameters in the integrity check, >>>=20 >>>>>> instead of only integrity-protecting the content itself. Indeed, = if >>>=20 >>>>>> there were an attack based on non-integrity-protected = cryptographic >>>=20 >>>>>> parameters, it would be a pretty big deal, since neither CMS nor = IKE >>>=20 >>>>>> nor provides this protection. (TLS does provide a signature over >>>=20 >>>>>> the algorithms, but only as a way to bind the public key to the >>>=20 >>>>>> session.) >>>=20 >>>>>>=20 >>>=20 >>>>>> Indeed CMS doesn't require canonicalization at all, except for >> attributes that are included in the protected content (signedAttrs / >> authenticatedAttrs), which need to be DER-encoded. In JSMS, we don't >> allow those parameters, so there is no need for canonicalization at = all. > All the >> "canonicalization" that's needed is to base64url-encode the protected >> content. In that regard, JSMS is even simpler than JWE/JWS. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> Part 3: Compactness and URL-safeness are still OK, as derivatives >>>=20 >>>>>>=20 >>>=20 >>>>>> I have absolutely no objection to defining a compact, URL-safe > format. >> Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example > from >> Section 3.1 of the JWS spec, we get the following JSMS object: >>>=20 >>>>>>=20 >>>=20 >>>>>> { >>>=20 >>>>>> "v":1, >>>=20 >>>>>> "t":"au", >>>=20 >>>>>> "a":"hs256", >>>=20 >>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>=20 >>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>=20 >>>>>> "ki":"rSIilRk8Ego" >>>=20 >>>>>> } >>>=20 >>>>>>=20 >>>=20 >>>>>> If we remove the decorative spaces and base64url-encode, we only >> use >>>=20 >>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>=20 >>>>>> further and define an explicit compact format for = AuthenticatedData, >>>=20 >>>>>> we can emulate JWS by moving the content and MAC fields outside >> and >>>=20 >>>>>> dot-combining. That avoids double-base64url-encoding, and only >>>=20 >>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put the = code >>>=20 >>>>>> to generate these in the Github project linked earlier.) >>>=20 >>>>>>=20 >>>=20 >>>>>> So it's fine to have a compact, URL-safe format for an objective, > but it >> makes *much* more sense to derive that from a full-size, usable, JSON >> format than the other way around. >>>=20 >>>>>>=20 >>>=20 >>>>>> Responses to specific points inline below. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> Fair enough. I'll briefly respond to each in turn. Before = doing > so, I'll >> say that I'm writing in the spirit of trying to increase mutual > understanding >> and consensus, rather than taking the point of view that the status = quo is > the >> only reasonable outcome. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> -- Not being JSON >>>=20 >>>>>>>=20 >>>=20 >>>>>>> This was by design, so that the results are URL-safe. This is > required, >> for instance, for them to be used as OAuth Bearer Tokens. At the = request > of >> the working group, closely related pure-JSON drafts were also = published. >> See: >>>=20 >>>>>>>=20 >>>=20 >>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri >>>=20 >>>>>>> alization-01 and >>>=20 >>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser >>>=20 >>>>>>> ialization-01 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Use them if you prefer if they better suit your use cases. They > could >> be adopted as working group documents, if there's interest. >>>=20 >>>>>>=20 >>>=20 >>>>>> See above. These are super-clunky, and the need to be the main >> focus of the WG, not an afterthought. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Not supporting multiple recipients >>>=20 >>>>>>>=20 >>>=20 >>>>>>> The JSON serialization drafts above do, again, in response to = use >> cases presented by the working group. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> See above. Because of the unnecessary inclusion of the header in > the >> integrity check, this is far less efficient than it should be. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lacking clear distinctions between signing and MAC >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Functionally, these are very similar operations, at least from = an >> implementation perspective, so it's not clear that making a clear > distinction >> would help either developers or adoption in any practical way. They > achieve >> overlapping, but admittedly sometimes different goals. I believe = that >> developers can be trusted to use the algorithms that achieve their >> applications' goals without making a hard distinction between the = two. > But >> I'd be interested in hearing your thoughts on why you believe a > brighter-line >> distinction might be useful or necessary. >>>=20 >>>>>>=20 >>>=20 >>>>>> It's important if you want to do MACs with anything other than = pre- >> shared keys. If you want to do anything more advanced, you need to = have >> wrapped keys, in which case an object with a MAC starts to look a lot = more >> like a JWE than a JWS. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lacking clear processing instructions for different key >>>=20 >>>>>>> establishment modalities >>>=20 >>>>>>>=20 >>>=20 >>>>>>> This seems like an area where the existing drafts could be = refined > to >> add descriptions for additional establishment modalities, possibly = based >> upon your ideas and descriptions, should the working group decide to = do > so. >> What additional modalities do you have use cases for that you believe = are >> not achievable or straightforward with the existing drafts? The = existing >> modalities supported are largely those that existing developers had = told > us >> they needed and draw both from the precursor draft-jones-json-web-* >> documents and draft-rescorla-jsms. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Bear in mind that the balance that the current drafts try to = strike > is >> keeping the Mandatory to Implement (MTI) feature footprint small = enough >> that developers, including Web developers, are likely to adopt the = specs, >> while still providing enough functionality to make them generally = useful. > As >> in any balance, it's often possible to shift things a bit and still > maintain the >> balance, but I'd like people to keep the ubiquitous adoption goal > front-and- >> center when proposing additional functionality. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>=20 >>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>=20 >>>>>>> that!) >>>=20 >>>>>>=20 >>>=20 >>>>>> I agree that we need to find a reasonable MTI. The current JSMS > draft >> doesn't really specify which parts are MTI, beyond basic things like > base64url >> encoding and ignoring unknown fields. >>>=20 >>>>>>=20 >>>=20 >>>>>> My main concern is that JWS and JWE don't really tell me which > fields >> need to be present for which use case. If I'm putting a MAC on a JWS = vs. > a >> signature, do I need "jwk" or "jku" fields to be populated? Whereas = in > JSMS, >> I think these things are much clearer due to the separation of the = use > cases >> (Signed/Authenticated/Encrypted) and the isolation of signatures and >> wrapped keys into sub-objects. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lack of clear typing of objects >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Most JSON documents aren't clearly typed; instead, developers = and >> implementations understand from context what the meaning of each = field is. >> XML is clearly typed, but developers are voting with their feet by = moving > to >> JSON. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> What practical advantages resulting from overlaying a typing >> infrastructure on JSON do you believe are worth the potential costs = of > doing >> so? BTW, I'm not opposed to having a JSON schema description of the = JOSE >> JSON data structures like JSMS did in = http://tools.ietf.org/html/draft- >> rescorla-jsms-00#appendix-A, but I'll remark that this an informative > tool, not >> a normative one. >>>=20 >>>>>>=20 >>>=20 >>>>>> I actualy don't have a hugely urgent requirement here either. = It's >> something that others in the WG had requested, which is trivial to = add in >> JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity >> protection of the header. >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>> -- Lack of versioning for future extensibility >>>=20 >>>>>>>=20 >>>=20 >>>>>>> An optional version field could be added if the working group >>>=20 >>>>>>> desires, however the last time the working group discussed it, = they >>>=20 >>>>>>> decided not to do so. Rather, specs like this effectively = become >>>=20 >>>>>>> "versioned" when revised in a way that new fields are added. If >>>=20 >>>>>>> you understand the new fields, you support that new version. = (Note >>>=20 >>>>>>> that this is independent of whether there is a version number >>>=20 >>>>>>> field, which according to some participants in the previous >>>=20 >>>>>>> discussion, they regarded as therefore being redundant >>>=20 >>>>>>> information.) >>>=20 >>>>>>>=20 >>>=20 >>>>>>> I'm not religious about not having a version number field, but > often >> "less is more". >>>=20 >>>>>>=20 >>>=20 >>>>>> Indeed, I'm not religious either. It just seems like a general = good > idea >> to state this directly as opposed to having parsers divine it based = on > which >> fields are present. To quote RFC 5652: >>>=20 >>>>>> " >>>=20 >>>>>> Each of the major data structures includes a version number as = the >>>=20 >>>>>> first item in the data structure. The version numbers are = intended >>>=20 >>>>>> to avoid ASN.1 decode errors. Some implementations do not check >> the >>>=20 >>>>>> version number prior to attempting a decode, and if a decode = error >>>=20 >>>>>> occurs, then the version number is checked as part of the error >>>=20 >>>>>> handling routine. This is a reasonable approach; it places error >>>=20 >>>>>> processing outside of the fast path. This approach is also >>>=20 >>>>>> forgiving when an incorrect version number is used by the = sender. >>>=20 >>>>>> " >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>> Best, >>>=20 >>>>>> --Richard >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Best wishes, >>>=20 >>>>>>> -- Mike >>>=20 >>>>>>>=20 >>>=20 >>>>>>> -----Original Message----- >>>=20 >>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>=20 >>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>=20 >>>>>>> To: Mike Jones >>>=20 >>>>>>> Cc: jose@ietf.org >>>=20 >>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>=20 >>>>>>> draft-barnes-jose-jsms-00.txt >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Ok, so maybe I should have phrased my lead-in differently. IMO, > the >> current JW* specs are deficient in several ways, e.g.: >>>=20 >>>>>>> -- Not being JSON >>>=20 >>>>>>> -- Not supporting multiple recipients >>>=20 >>>>>>> -- Lacking clear distinctions between signing and MAC >>>=20 >>>>>>> -- Lacking clear processing instructions for different key >>>=20 >>>>>>> establishment modalities >>>=20 >>>>>>> -- Lack of clear typing of objects >>>=20 >>>>>>> -- Lack of versioning for future extensibility >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Looking at the current specs, it didn't seem to me that it would = be >> simple to adapt them to address these deficiencies. So I just did a > re-write. >> If you think they can be addressed within the current framework, = please >> explain. I just found it simpler to start from whole cloth. >>>=20 >>>>>>>=20 >>>=20 >>>>>>> Cheers, >>>=20 >>>>>>> --Richard >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>=20 >>>>>>>=20 >>>=20 >>>>>>>> Hi Richard, >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> If you're puzzled by specific design decisions in the JOSE > documents, >> I encourage you to ask about them on the list. The documents have >> significant history going back to mid-2010 when convergence = discussions >> started among people with four different JSON signing & encryption >> proposals. JWT and the current JOSE specs and implementations are = the >> result. I realize that not all the JOSE participants were part of = those >> discussions from the beginning (although many were) and so teasing = out the >> rationale for specific decisions might help people better understand = the >> choices made, and hopefully thereby increase consensus behind the >> eventual working group choices. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> If the list that you're puzzled by is the bulleted list below, > maybe we >> can start a discussion on that basis. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Best wishes, >>>=20 >>>>>>>> -- Mike >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> -----Original Message----- >>>=20 >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>=20 >>>>>>>> Behalf Of Richard L. Barnes >>>=20 >>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>=20 >>>>>>>> To: jose@ietf.org >>>=20 >>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>=20 >>>>>>>> draft-barnes-jose-jsms-00.txt >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Dear JOSE WG, >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Like Mr. Manger, once I finally got around to doing a thorough >> review of the JW* specs, I was kind of puzzled by some of the design >> decisions. So I also went through and wrote an alternative format, = this > time >> taking a more of a cue from CMS. A link to the document is below. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Summary of differences: >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>=20 >>>>>>>> parameters are represented in JSON. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS allows for full algorithm agility in key agreement, = while > JWE >>>=20 >>>>>>>> only allows ECDH-ES. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>=20 >>>>>>>> AuthenticatedData objects via the inclusion of multiple >> WrappedKey >>>=20 >>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>=20 >>>>>>>> encryption of the entire object for each recipient. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o The signature and MAC functions of the JWS object are = separated >>>=20 >>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS parameters are not integrity-protected, as they are in = JWE >>>=20 >>>>>>>> and JWS. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, but > could >>>=20 >>>>>>>> be added without significant change. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>=20 >>>>>>>> parameters, in order to facilitate extensibility. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> I've also thrown together an initial JavaScript implementation > (based >> on NodeJS for some python crypto glue), which is on github: >>>=20 >>>>>>>> >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Comments are very welcome. >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Thanks, >>>=20 >>>>>>>> --Richard >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> Begin forwarded message: >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>> From: internet-drafts@ietf.org >>>=20 >>>>>>>>> Subject: New Version Notification for >>>=20 >>>>>>>>> draft-barnes-jose-jsms-00.txt >>>=20 >>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>=20 >>>>>>>>> To: rbarnes@bbn.com >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>=20 >>>>>>>>> successfully submitted by Richard Barnes and posted to the = IETF >>>=20 >>>>>>>>> repository. >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> Filename: draft-barnes-jose-jsms >>>=20 >>>>>>>>> Revision: 00 >>>=20 >>>>>>>>> Title: JavaScript Message Security Format >>>=20 >>>>>>>>> Creation date: 2012-06-15 >>>=20 >>>>>>>>> WG ID: Individual Submission >>>=20 >>>>>>>>> Number of pages: 25 >>>=20 >>>>>>>>> URL: > http://www.ietf.org/internet-drafts/draft-barnes-jose- >> jsms-00.txt >>>=20 >>>>>>>>> Status: > http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>=20 >>>>>>>>> Htmlized: > http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> Abstract: >>>=20 >>>>>>>>> Many applications require the ability to send = cryptographically >>>=20 >>>>>>>>> secured messages. While the IETF has defined a number of >> formats >>>=20 >>>>>>>>> for such messages (e.g. CMS) those formats use encodings = which >>>=20 >>>>>>>>> are not easy to use in modern applications. This document >>>=20 >>>>>>>>> describes the JavaScript Message Security format (JSMS), a new >>>=20 >>>>>>>>> cryptographic message format which is based on JavaScript = Object >>>=20 >>>>>>>>> Notation (JSON) and thus is easy for many applications to > generate >> and parse. >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>> The IETF Secretariat >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> _______________________________________________ >>>=20 >>>>>>>> jose mailing list >>>=20 >>>>>>>> jose@ietf.org >>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>=20 >>>=20 >>>>>>>> _______________________________________________ >>>=20 >>>>>>>> jose mailing list >>>=20 >>>>>>>> jose@ietf.org >>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>=20 >>>>>>> _______________________________________________ >>>=20 >>>>>>> jose mailing list >>>=20 >>>>>>> jose@ietf.org >>>=20 >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>>=20 >>>=20 >>>>>> _______________________________________________ >>>=20 >>>>>> jose mailing list >>>=20 >>>>>> jose@ietf.org >>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>>>=20 >>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Tue Jun 26 10:43: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 E34FE11E8080 for ; Tue, 26 Jun 2012 10:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRMhHBrL2aWt for ; Tue, 26 Jun 2012 10:43:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8B11E8072 for ; Tue, 26 Jun 2012 10:43:18 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:59460) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjZme-0004hH-RD; Tue, 26 Jun 2012 13:42:36 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 26 Jun 2012 13:43:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Jim Schaad , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:43:21 -0000 > Now that we are mandating JWE sender verification people will be using = JWE with symmetric keys or key agreement. > In those cases one can easily argue that the header should be = protected as much as in HMAC. Can you clarify the scope of "we are mandating"? > There may well be signing_time or other elements that would go into = the header as well for JWE. Why do these need to go into the header rather than the body? --Richard > Regards > John B. >=20 > On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >=20 >> >>=20 >> Richard, >>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >>> Richard L. Barnes >>> Sent: Monday, June 25, 2012 2:35 PM >>> To: Nat Sakimura >>> Cc: Mike Jones; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >>> 00.txt >>>=20 >>> Hi Nat, >>>=20 >>> I'm not sure what X.509 fiasco you're referring to. There was a = recent >> MD5 >>> fiasco [1], but that's an attack on MD5, not X.509. In fact, there = have >> been >>> recommendations for preventing this attack in X.509 since 2005 [2]. = As >> was >>> noted on the SAAG list, the real news here is that Microsoft wasn't >> following >>> any of those recommendations. >>>=20 >>> JWS would have had the same problem as X.509. The attack did not = modify >>> the cryptographic parameters (anything that would have gone in the >>> header), it would not have been thwarted by the integrity protection = we're >>> worrying about. >>>=20 >>> Actually, the header signing that JWS does makes it even nicer for = the >>> attacker: Flame used a "chosen prefix" attack, so since the JWS = header >> value >>> is entirely static for a given signer, it's easy to use as a fixed = prefix. >> If JWS just >>> signed the content, then the application could include a something = random >>> up front to prevent such prefix-based attacks. >>>=20 >>=20 >> I don't believe that this is a true statement. If you had a prefix = or just >> signed what was given to you (i.e. no prefix), it would make no = difference >> in terms of the attack for Flame. Flame could always use a fixed = prefix of >> its own design rather than using the fixed header that is generated = by >> having JWS sign the header information. >>=20 >>> It's tempting to say that we should just add randomness to the JOSE >> format. >>> But the real lesson of the Flame/MD5 attacks is operational: If = you're >> signing >>> something that somebody else gave you, make sure that you're not = signing >>> exactly what they gave you. Follow the recommendations of RFC 4270. = In >>> other contexts, there's no need of similar random elements; it just = adds >>> complexity. >>=20 >> This is definitely a true statement in all events and is something = that >> should be added to the Security Considerations section. >>=20 >> That being said, I think that there are valid reasons for wanting to = protect >> the header information by some authentication processing. PKIX = certificates >> protect the signature algorithm information (by copying the data into = the to >> be signed block) and CMS has long allowed for information to be = included in >> the signed attributes area that identifies the algorithms used, the >> certificates used and so forth. There are also other things that we = might >> find to be convenient to be placed in the header information that is = current >> not there (a signing time and embedded content type comes to mind) = that >> would be a product either of specific types of signatures or becomes = a >> common attribute to be placed there. >>=20 >> In terms of encryption operations, I remember in the past that I have = had >> either corrupted encrypted streams or corrupted IVs and had a = successful >> decryption that later generated other problems when trying to parse. = This >> is less of an issue with AEAD algorithms as they have a much stricter = rule >> on when the stream decrypts correctly. >>=20 >> Jim >>=20 >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>> [1] >>> [2] >>>=20 >>>=20 >>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>=20 >>>> Especially after the X.509 fiasco, I strongly believe that having >> integrity >>> check over the metadata is a good thing. It is such a little effort = that >> gives us >>> much more protection down the road. In this sense, I fully agree = with Ben >>> here. We should have integrity protection over the header. >>>>=20 >>>> Nat >>>>=20 >>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>> wrote: >>>> Two years ago when the developer community needing a JSON-friendly >>> token format was designing the JSON Web Token (JWT), we explicitly = asked >>> security experts whether the header parameters should be integrity >>> protected or not. Among them, Ben Laurie was one of the voices = saying >> that >>> securing them was the right thing to do. >>>>=20 >>>>=20 >>>>=20 >>>> He argued that if the parameters can be protected in a practical = manner, >>> then they should. Doing so provides an additional hurdle that = attackers >>> would have to surmount. For example, if they can try to substitute = a >> weaker >>> authentication scheme, then they must figure out how to make it >>> authenticate correctly despite some plaintext they can't control - = the >> header >>> parameters. >>>>=20 >>>>=20 >>>>=20 >>>> Ben also took the position that paring security protocols down to = the >> least >>> you can get away with, given attacks you can think of, is not a good >> design >>> principle. If there is not a strong argument against including a = feature >> that >>> may make it harder for attackers, then that feature should be = included. >>>>=20 >>>>=20 >>>>=20 >>>> I agree with him. >>>>=20 >>>>=20 >>>>=20 >>>> The decision to provide integrity protection for the headers is >> documented >>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>=20 >>>>=20 >>>>=20 >>>> . What to sign (envelope.payload or just payload)? >>>>=20 >>>> Given that the envelope is extensible and therefore may contain >> security- >>> sensitive information, we reached a consensus (with input from Ben = Laurie >>> via IM) that the combination envelope.payload must be signed. >>>>=20 >>>>=20 >>>> I believe that logic is as sound today as it was then. >>>>=20 >>>>=20 >>>>=20 >>>> For all these reasons, I therefore personally stand by the = community's >>> decision to provide integrity protection for the headers. >>>>=20 >>>>=20 >>>>=20 >>>> Best = wishes, >>>>=20 >>>> -- Mike >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>> John Bradley >>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>> To: Richard L.Barnes >>>> Cc: jose@ietf.org >>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >>> 00.txt >>>>=20 >>>>=20 >>>>=20 >>>> Hi Richard, >>>>=20 >>>>=20 >>>>=20 >>>> While for PKCS 1.5 the hash algorithm is baked into the padding and = not >>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>=20 >>>> There are possible hash truncation attacks by shortening SHA256 to >> SHA224 >>> as an example (I know we preclude truncated hashes at the moment). >>>>=20 >>>>=20 >>>>=20 >>>> The bad feeling I get around this is that if there is a scenario = where >> the >>> attacker controls the plaintext to be signed and there is no signer >> controlled >>> text contributed there are potential bad things that could happen = down the >>> road. >>>>=20 >>>>=20 >>>>=20 >>>> This bit us with x509 certs not that long ago (yes with MD5 = admittedly) >>> where the attacker could use a certificate extension to include = extra data >> and >>> cause a pre collided hash to be generated. >>>>=20 >>>> Having part of the signed data outside the control of an attacker = is a >> good >>> thing. (having a nonce or message ID in the envelope is possible = though >> not >>> yet required in JWS.) >>>>=20 >>>>=20 >>>>=20 >>>> I am still of the opinion that putting the base64 encoded envelope >> inside >>> the hash calculation is a valid way to allow additional attributes. >>>>=20 >>>> Another structure to hold the attributes adds more complexity, as = would >>> saying that they need to be inside the signed object. >>>>=20 >>>>=20 >>>>=20 >>>> I think part of this is that as one of the openID Connect authors I = look >> at this >>> as a necessary security token format, for OAuth and Connect. >>>>=20 >>>> For that simple processing with one signature is a high priority = for >> adoption. >>>>=20 >>>>=20 >>>>=20 >>>> =46rom a general signing/encrypting of documents point of view you >>> legitimately have different priorities. >>>>=20 >>>>=20 >>>>=20 >>>> I know it is hard to prove a negative but It is also going to be >> difficult for me >>> to go back to security people at google Facebook and other places = and >>> explain how not integrity protecting the header could be better than >>> integrity protecting it. >>>>=20 >>>>=20 >>>>=20 >>>> It seems that I would be reduced to arguing that this is no worse = than >> CMS >>> and that hasn't been proven insecure yet. >>>>=20 >>>>=20 >>>>=20 >>>> Allowing a possible attacker to control the hash output, and not >> integrity >>> protecting the additional data, seems like something I am bound to = regret >> in >>> the future. >>>>=20 >>>>=20 >>>>=20 >>>> Regards >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>=20 >>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> Hey John, >>>>=20 >>>>>=20 >>>>=20 >>>>> Interesting points, but I don't think they actually apply here. >>>>=20 >>>>>=20 >>>>=20 >>>>> With regard to downgrade attacks: >>>>=20 >>>>>=20 >>>>=20 >>>>> The attack that RFC 5752 is concerned with is when an attacker = strips >>> signatures from a signed message, so that the only ones left are = ones he >> can >>> tamper with. So the integrity protection here is "horizontal"; it = goes >> across >>> signatures. The integrity protection in JWS/JWE is "vertical" -- it = only >> protects >>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> With regard to "brown bag" attacks: >>>>=20 >>>>>=20 >>>>=20 >>>>> The root of this attack is ambiguity about what content is = *signed* >>>>=20 >>>>> vs. what content is *used*. If an application doesn't verify that >>>>=20 >>>>> it's actually using the stuff that's signed, then it can be = tricked >>>>=20 >>>>> into accepting something unsigned. (Cf. >>>>=20 >>>>> ) >>>>=20 >>>>>=20 >>>>=20 >>>>> However, I don't think any of the current proposals have that = problem. >>> In JWE/JWS, the signed content is right there between the dots, and = in >> JSMS, >>> it's in the "content" element. The current JSMS draft does allow = detached >>> signatures, but with a "voids your warranty" sticker on it. >>>>=20 >>>>>=20 >>>>=20 >>>>> In any case, these attacks have nothing to do with whether the >>> cryptographic parameters are integrity-protected with the content. = The >>> example attacks in the IBM still work regardless -- the whole point = of the >>> attack is that the cryptographic processing is the same, only the >> (non-crypto) >>> matching of content is flawed. >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> With regard to "arbitrary attributes": >>>>=20 >>>>>=20 >>>>=20 >>>>> We can have that here, too, but you need canonicalization. And >> base64- >>> encoding is not not canonicalization -- it just waves its hands over = the >>> question of equivalence. In my opinion, we should keep the = cryptographic >>> object simple by disallowing attributes, and push the attributes you = would >>> sign inside of the thing being signed. If people really do want >> attributes, it >>> doesn't seem to me like JSON canonicalization is very hard. I can = do it >> in 19 >>> lines of python: >>>>=20 >>>>> >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> With regard too "meta-data in the body": >>>>=20 >>>>>=20 >>>>=20 >>>>> It seems to me like if we're trying to define a general format for >> applying >>> security protections, then we ought to keep out things that aren't >> strictly >>> security relevant. Those things can go in application-specific = content >> types >>> (e.g., SAML) without polluting the general purpose header. >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> With regard to "defense in depth" and selling this to government >>> agencies: >>>>=20 >>>>>=20 >>>>=20 >>>>> CMS, via S/MIME, is in broad use across multiple federal agencies = and >>> large enterprises. JSMS is essentially a profile of CMS (see = Section 7), >> and >>> has the same security properties. >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> Cheers, >>>>=20 >>>>> --Richard >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>=20 >>>>>=20 >>>>=20 >>>>>> Hi Richard, >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Originally we only integrity protected the header for signing. = We >> added >>> the integrity protection to encryption as part of AEAD, as = encryption can >> also >>> be used for sender verification. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> I understand the argument that it makes things simpler if we = don't >>> integrity protect the header information. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> However xmldsig, provides integrity over those elements to = prevent >>> possible downgrade attacks by manipulating the algorithms. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> CMS may not typically provide that integrity protection but I = think >> Jim >>> Schaad and Sean Terner created RFC5752 to address downgrade attacks. >>>>=20 >>>>>> Given they are on this list they can speak to their view on = integrity >> over >>> the crypto parameters. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> I also recall when working on InfoCards there was a Monte = Carlo/Brown >>> Bag attack that needs to be considered if we move to something more = like a >>> detached signature. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> The other design consideration is that we wanted to be able to = sign >>> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>>=20 >>>>>> That prevented us from including meta-data in the body as we = didn't >>> want to touch it. That left us with the header to include = additional >> elements >>> in. >>>>=20 >>>>>> Not integrity protecting those elements as well would be a = problem. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> I am not a CMS expert but I believe it allows for signing of >> arbitrary >>> attributes not unlike the current JOSE spec. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Especially for something that will be used with JWT security = tokens I >> will >>> have a hard time making the argument to NIST and others that need to >>> approve this format that not integrity protecting the header = parameters is >>> appropriate defence in depth, for something that might be replacing = signed >>> SAML assertions in some applications. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> I do understand how not integrity protecting the header will make >> some >>> things easier, however I can't agree that the benefit outweighs the >>> disadvantages. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Regards >>>>=20 >>>>>> John B. >>>>=20 >>>>>>=20 >>>>=20 >>>>>>=20 >>>>=20 >>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>=20 >>>>>>=20 >>>>=20 >>>>>>> Hey Mike, >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Thanks for having some back-and-forth with me on this. I think = this >> is a >>> good discussion to have right now. I would like to discuss some >> high-level >>> points, and then I'll respond inline to your precise points. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> tl;dr: In order to meet its deliverables, the WG needs to define >> JSON- >>> based formats for integrity and confidentiality protections. JWE = and JWS >>> don't fit that requirement, so we should re-consider their adoption = and >> call >>> for new candidates. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Major points: >>>>=20 >>>>>>> 1. JOSE is JSON >>>>=20 >>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>=20 >>>>>>> URL-safeness are still OK, as derivatives >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Part 1: JOSE is JSON >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> The JOSE WG charter calls out four deliverables, three of which = are >>> explicitly required to be JSON: >>>>=20 >>>>>>> -- "JSON-structured integrity protection" >>>>=20 >>>>>>> -- "JSON-structured encryption" >>>>=20 >>>>>>> -- "public keys as JSON-structured objects" >>>>=20 >>>>>>> (The fourth is just a list of algorithms, which should be JSON = as >>>>=20 >>>>>>> well, just as RFC 3370 is ASN.1.) >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> In light of these requirements, JWE and JWS are clearly not = suitable >>>>=20 >>>>>>> candidates to fulfill the working group's milestones. (At least = in >>>>=20 >>>>>>> their current form.) So ISTM that we need to step back and >>>>=20 >>>>>>> re-evaluate alternatives for the three above milestones, = especially >>>>=20 >>>>>>> the first two. (JWK is not as far off.) >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> As JSON-based mechanisms, though, the "JSON serialization" = drafts >>> are pretty half-hearted. Because JWS and JWE include the = cryptographic >>> parameters within the integrity protection, they have to have the = headers >>> included as base64-encoded strings. That obviously adds a lot of >> complexity >>> to encoding and decoding -- for example, you have to keep the = encoded >>> header around even after you've decoded it! -- and just plain more = octets. >>> The support for multiple recipients and multiple signatures is both >> unweildy >>> (matching up parallel indices for headers and signatures) and = inefficient >>> (multiple integrity check values in encrypted objects). >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom = that >>> went into CMS, while making the syntax pure JSON and as simple as >> possible. >>> Multiple signatures and multiple recipients are supported with = absolute >>> minimum overhead. So I think it's worth consideration by the = working >> group. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Part 2: JSON !=3D> canonicalization >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> I would like to dispel the myth that a JSON-based format = requires >>>>=20 >>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>=20 >>>>>>> "canonicalization" (via base64url encoding) because it's = included >>>>=20 >>>>>>> within the integrity protection. I'm not aware of any reason = for >>>>=20 >>>>>>> including the cryptographic parameters in the integrity check, >>>>=20 >>>>>>> instead of only integrity-protecting the content itself. = Indeed, if >>>>=20 >>>>>>> there were an attack based on non-integrity-protected = cryptographic >>>>=20 >>>>>>> parameters, it would be a pretty big deal, since neither CMS nor = IKE >>>>=20 >>>>>>> nor provides this protection. (TLS does provide a signature = over >>>>=20 >>>>>>> the algorithms, but only as a way to bind the public key to the >>>>=20 >>>>>>> session.) >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Indeed CMS doesn't require canonicalization at all, except for >>> attributes that are included in the protected content (signedAttrs / >>> authenticatedAttrs), which need to be DER-encoded. In JSMS, we = don't >>> allow those parameters, so there is no need for canonicalization at = all. >> All the >>> "canonicalization" that's needed is to base64url-encode the = protected >>> content. In that regard, JSMS is even simpler than JWE/JWS. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Part 3: Compactness and URL-safeness are still OK, as = derivatives >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> I have absolutely no objection to defining a compact, URL-safe >> format. >>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example >> from >>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> { >>>>=20 >>>>>>> "v":1, >>>>=20 >>>>>>> "t":"au", >>>>=20 >>>>>>> "a":"hs256", >>>>=20 >>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>=20 >>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>=20 >>>>>>> "ki":"rSIilRk8Ego" >>>>=20 >>>>>>> } >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> If we remove the decorative spaces and base64url-encode, we only >>> use >>>>=20 >>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>>=20 >>>>>>> further and define an explicit compact format for = AuthenticatedData, >>>>=20 >>>>>>> we can emulate JWS by moving the content and MAC fields outside >>> and >>>>=20 >>>>>>> dot-combining. That avoids double-base64url-encoding, and only >>>>=20 >>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put the = code >>>>=20 >>>>>>> to generate these in the Github project linked earlier.) >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> So it's fine to have a compact, URL-safe format for an = objective, >> but it >>> makes *much* more sense to derive that from a full-size, usable, = JSON >>> format than the other way around. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Responses to specific points inline below. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>> Fair enough. I'll briefly respond to each in turn. Before = doing >> so, I'll >>> say that I'm writing in the spirit of trying to increase mutual >> understanding >>> and consensus, rather than taking the point of view that the status = quo is >> the >>> only reasonable outcome. >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> -- Not being JSON >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> This was by design, so that the results are URL-safe. This is >> required, >>> for instance, for them to be used as OAuth Bearer Tokens. At the = request >> of >>> the working group, closely related pure-JSON drafts were also = published. >>> See: >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri >>>>=20 >>>>>>>> alization-01 and >>>>=20 >>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser >>>>=20 >>>>>>>> ialization-01 >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Use them if you prefer if they better suit your use cases. = They >> could >>> be adopted as working group documents, if there's interest. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> See above. These are super-clunky, and the need to be the main >>> focus of the WG, not an afterthought. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>> -- Not supporting multiple recipients >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> The JSON serialization drafts above do, again, in response to = use >>> cases presented by the working group. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> See above. Because of the unnecessary inclusion of the header = in >> the >>> integrity check, this is far less efficient than it should be. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Functionally, these are very similar operations, at least from = an >>> implementation perspective, so it's not clear that making a clear >> distinction >>> would help either developers or adoption in any practical way. They >> achieve >>> overlapping, but admittedly sometimes different goals. I believe = that >>> developers can be trusted to use the algorithms that achieve their >>> applications' goals without making a hard distinction between the = two. >> But >>> I'd be interested in hearing your thoughts on why you believe a >> brighter-line >>> distinction might be useful or necessary. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> It's important if you want to do MACs with anything other than = pre- >>> shared keys. If you want to do anything more advanced, you need to = have >>> wrapped keys, in which case an object with a MAC starts to look a = lot more >>> like a JWE than a JWS. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>> -- Lacking clear processing instructions for different key >>>>=20 >>>>>>>> establishment modalities >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> This seems like an area where the existing drafts could be = refined >> to >>> add descriptions for additional establishment modalities, possibly = based >>> upon your ideas and descriptions, should the working group decide to = do >> so. >>> What additional modalities do you have use cases for that you = believe are >>> not achievable or straightforward with the existing drafts? The = existing >>> modalities supported are largely those that existing developers had = told >> us >>> they needed and draw both from the precursor draft-jones-json-web-* >>> documents and draft-rescorla-jsms. >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Bear in mind that the balance that the current drafts try to = strike >> is >>> keeping the Mandatory to Implement (MTI) feature footprint small = enough >>> that developers, including Web developers, are likely to adopt the = specs, >>> while still providing enough functionality to make them generally = useful. >> As >>> in any balance, it's often possible to shift things a bit and still >> maintain the >>> balance, but I'd like people to keep the ubiquitous adoption goal >> front-and- >>> center when proposing additional functionality. >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>=20 >>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>>=20 >>>>>>>> that!) >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> I agree that we need to find a reasonable MTI. The current JSMS >> draft >>> doesn't really specify which parts are MTI, beyond basic things like >> base64url >>> encoding and ignoring unknown fields. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> My main concern is that JWS and JWE don't really tell me which >> fields >>> need to be present for which use case. If I'm putting a MAC on a = JWS vs. >> a >>> signature, do I need "jwk" or "jku" fields to be populated? Whereas = in >> JSMS, >>> I think these things are much clearer due to the separation of the = use >> cases >>> (Signed/Authenticated/Encrypted) and the isolation of signatures and >>> wrapped keys into sub-objects. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>> -- Lack of clear typing of objects >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Most JSON documents aren't clearly typed; instead, developers = and >>> implementations understand from context what the meaning of each = field is. >>> XML is clearly typed, but developers are voting with their feet by = moving >> to >>> JSON. >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> What practical advantages resulting from overlaying a typing >>> infrastructure on JSON do you believe are worth the potential costs = of >> doing >>> so? BTW, I'm not opposed to having a JSON schema description of the = JOSE >>> JSON data structures like JSMS did in = http://tools.ietf.org/html/draft- >>> rescorla-jsms-00#appendix-A, but I'll remark that this an = informative >> tool, not >>> a normative one. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> I actualy don't have a hugely urgent requirement here either. = It's >>> something that others in the WG had requested, which is trivial to = add in >>> JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity >>> protection of the header. >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>> -- Lack of versioning for future extensibility >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> An optional version field could be added if the working group >>>>=20 >>>>>>>> desires, however the last time the working group discussed it, = they >>>>=20 >>>>>>>> decided not to do so. Rather, specs like this effectively = become >>>>=20 >>>>>>>> "versioned" when revised in a way that new fields are added. = If >>>>=20 >>>>>>>> you understand the new fields, you support that new version. = (Note >>>>=20 >>>>>>>> that this is independent of whether there is a version number >>>>=20 >>>>>>>> field, which according to some participants in the previous >>>>=20 >>>>>>>> discussion, they regarded as therefore being redundant >>>>=20 >>>>>>>> information.) >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> I'm not religious about not having a version number field, but >> often >>> "less is more". >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Indeed, I'm not religious either. It just seems like a general = good >> idea >>> to state this directly as opposed to having parsers divine it based = on >> which >>> fields are present. To quote RFC 5652: >>>>=20 >>>>>>> " >>>>=20 >>>>>>> Each of the major data structures includes a version number as = the >>>>=20 >>>>>>> first item in the data structure. The version numbers are = intended >>>>=20 >>>>>>> to avoid ASN.1 decode errors. Some implementations do not check >>> the >>>>=20 >>>>>>> version number prior to attempting a decode, and if a decode = error >>>>=20 >>>>>>> occurs, then the version number is checked as part of the error >>>>=20 >>>>>>> handling routine. This is a reasonable approach; it places = error >>>>=20 >>>>>>> processing outside of the fast path. This approach is also >>>>=20 >>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>=20 >>>>>>> " >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> Best, >>>>=20 >>>>>>> --Richard >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Best wishes, >>>>=20 >>>>>>>> -- Mike >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> -----Original Message----- >>>>=20 >>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>=20 >>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>=20 >>>>>>>> To: Mike Jones >>>>=20 >>>>>>>> Cc: jose@ietf.org >>>>=20 >>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>=20 >>>>>>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Ok, so maybe I should have phrased my lead-in differently. = IMO, >> the >>> current JW* specs are deficient in several ways, e.g.: >>>>=20 >>>>>>>> -- Not being JSON >>>>=20 >>>>>>>> -- Not supporting multiple recipients >>>>=20 >>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>=20 >>>>>>>> -- Lacking clear processing instructions for different key >>>>=20 >>>>>>>> establishment modalities >>>>=20 >>>>>>>> -- Lack of clear typing of objects >>>>=20 >>>>>>>> -- Lack of versioning for future extensibility >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Looking at the current specs, it didn't seem to me that it = would be >>> simple to adapt them to address these deficiencies. So I just did a >> re-write. >>> If you think they can be addressed within the current framework, = please >>> explain. I just found it simpler to start from whole cloth. >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> Cheers, >>>>=20 >>>>>>>> --Richard >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>> Hi Richard, >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> If you're puzzled by specific design decisions in the JOSE >> documents, >>> I encourage you to ask about them on the list. The documents have >>> significant history going back to mid-2010 when convergence = discussions >>> started among people with four different JSON signing & encryption >>> proposals. JWT and the current JOSE specs and implementations are = the >>> result. I realize that not all the JOSE participants were part of = those >>> discussions from the beginning (although many were) and so teasing = out the >>> rationale for specific decisions might help people better understand = the >>> choices made, and hopefully thereby increase consensus behind the >>> eventual working group choices. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> If the list that you're puzzled by is the bulleted list below, >> maybe we >>> can start a discussion on that basis. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> Best wishes, >>>>=20 >>>>>>>>> -- Mike >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> -----Original Message----- >>>>=20 >>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>=20 >>>>>>>>> Behalf Of Richard L. Barnes >>>>=20 >>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>=20 >>>>>>>>> To: jose@ietf.org >>>>=20 >>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>=20 >>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> Dear JOSE WG, >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> Like Mr. Manger, once I finally got around to doing a thorough >>> review of the JW* specs, I was kind of puzzled by some of the design >>> decisions. So I also went through and wrote an alternative format, = this >> time >>> taking a more of a cue from CMS. A link to the document is below. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> Summary of differences: >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>=20 >>>>>>>>> parameters are represented in JSON. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> o JSMS allows for full algorithm agility in key agreement, = while >> JWE >>>>=20 >>>>>>>>> only allows ECDH-ES. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>=20 >>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>> WrappedKey >>>>=20 >>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>=20 >>>>>>>>> encryption of the entire object for each recipient. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> o The signature and MAC functions of the JWS object are = separated >>>>=20 >>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> o JSMS parameters are not integrity-protected, as they are in = JWE >>>>=20 >>>>>>>>> and JWS. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, but >> could >>>>=20 >>>>>>>>> be added without significant change. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>=20 >>>>>>>>> parameters, in order to facilitate extensibility. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> I've also thrown together an initial JavaScript implementation >> (based >>> on NodeJS for some python crypto glue), which is on github: >>>>=20 >>>>>>>>> >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> Comments are very welcome. >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> Thanks, >>>>=20 >>>>>>>>> --Richard >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> Begin forwarded message: >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>>> From: internet-drafts@ietf.org >>>>=20 >>>>>>>>>> Subject: New Version Notification for >>>>=20 >>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>=20 >>>>>>>>>> To: rbarnes@bbn.com >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>>=20 >>>>>>>>>> successfully submitted by Richard Barnes and posted to the = IETF >>>>=20 >>>>>>>>>> repository. >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>=20 >>>>>>>>>> Revision: 00 >>>>=20 >>>>>>>>>> Title: JavaScript Message Security Format >>>>=20 >>>>>>>>>> Creation date: 2012-06-15 >>>>=20 >>>>>>>>>> WG ID: Individual Submission >>>>=20 >>>>>>>>>> Number of pages: 25 >>>>=20 >>>>>>>>>> URL: >> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>> jsms-00.txt >>>>=20 >>>>>>>>>> Status: >> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>=20 >>>>>>>>>> Htmlized: >> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>> Abstract: >>>>=20 >>>>>>>>>> Many applications require the ability to send = cryptographically >>>>=20 >>>>>>>>>> secured messages. While the IETF has defined a number of >>> formats >>>>=20 >>>>>>>>>> for such messages (e.g. CMS) those formats use encodings = which >>>>=20 >>>>>>>>>> are not easy to use in modern applications. This document >>>>=20 >>>>>>>>>> describes the JavaScript Message Security format (JSMS), a = new >>>>=20 >>>>>>>>>> cryptographic message format which is based on JavaScript = Object >>>>=20 >>>>>>>>>> Notation (JSON) and thus is easy for many applications to >> generate >>> and parse. >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>> The IETF Secretariat >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> _______________________________________________ >>>>=20 >>>>>>>>> jose mailing list >>>>=20 >>>>>>>>> jose@ietf.org >>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>>=20 >>>>=20 >>>>>>>>> _______________________________________________ >>>>=20 >>>>>>>>> jose mailing list >>>>=20 >>>>>>>>> jose@ietf.org >>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>> _______________________________________________ >>>>=20 >>>>>>>> jose mailing list >>>>=20 >>>>>>>> jose@ietf.org >>>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>>>>=20 >>>>=20 >>>>>>> _______________________________________________ >>>>=20 >>>>>>> jose mailing list >>>>=20 >>>>>>> jose@ietf.org >>>>=20 >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Tue Jun 26 10:46: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 81A8F11E8079 for ; Tue, 26 Jun 2012 10:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8ynFYxHq72w for ; Tue, 26 Jun 2012 10:46:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF9CC11E8072 for ; Tue, 26 Jun 2012 10:46:14 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:59461) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjZq7-0004L2-Kl; Tue, 26 Jun 2012 13:46:11 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Richard L. Barnes" In-Reply-To: Date: Tue, 26 Jun 2012 13:46:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436654F786@TK5EX14MBXC283.redmond.corp.microsoft.com> <9025B64C-7B95-40F5-BE44-51A40E3A5001@bbn.com> <4E1F6AAD24975D4BA5B168042967394366550892@TK5EX14MBXC283.redmond.corp.microsoft.com> <3EDD6CA9-5C74-4F6A-89A6-AEAF6EA6601C@ve7jtb.com> <6E84631F-F6C2-43F7-9B65-E57841E4E858@bbn.com> <8C25B651-4E65-4D6F-AA9F-F76C98626E54@bbn.com> To: Brian Campbell X-Mailer: Apple Mail (2.1278) Cc: John Bradley , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:46:15 -0000 I agree with that goal! I disagree that JWS is a good solution. =20 It is true that JWS provides a relatively simple mechanism for a single = signature, but: 1. It could be simpler (see below) 2. JWS header protection is useless for the single-signature case, and = makes the multiple-signature/recipient case harder --Richard On Jun 26, 2012, at 12:16 PM, Brian Campbell wrote: > I wasn't suggesting that integrity-protecting the header itself makes > things simpler. Rather that a desirable goal is for support of a > relatively simple model utilizing a single signature over the whole > message. And that we already have that in JWS. >=20 > On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes = wrote: >>=20 >> On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: >>=20 >>>>> I think part of this is that as one of the openID Connect authors = I look at this as a necessary security token format, for OAuth and = Connect. >>>>> For that simple processing with one signature is a high priority = for adoption. >>>>=20 >>>> +1. >>>>=20 >>>> A simple JSON friendly model supporting a single signature over the >>>> entire message (including headers) is an important case for = adoption >>>> (and security). JWS provides that now and there are already = numerous >>>> interoperable JWS implementations available or in the works. >>>=20 >>> I'm not sure how people think that integrity-protecting the header = makes things *simpler*, especially since it adds a whole new decoding = step and makes the parsing more complicated. >>>=20 >>> Pseudocode without integrity protection (assuming JSMS format, but = JWS could be made to look similar): >>> function verify(json) { >>> jose =3D JSON.parse(json); >>> // Check algorithm values >>> return Crypto.SignatureAlgorithm.verify(jose.content, = jose.keys[0].signature, jose.keys[0].key); >>> } >>>=20 >>> Pseudocode with integrity protection (assuming JWS format): >>> function verify(jws) { >>> (txtHeader, content, signature) =3D jws.split("\."); >>> protectedBody =3D header + "." + content >>> jsonHeader =3D base64url.decode(txtHeader); >>> header =3D JSON.parse(jsonHeader); >>> return Crypto.SignatureAlgorithm.verify(content, signature, = header.jwk); >>> } >>>=20 >>=20 >> Err, sorry, that should read: >> protectedBody =3D txtHeader + "." + content; >> and >> return Crypto.SignatureAlgorithm.verify(protectedBody, signature, = header.jwk); >>=20 >> See how hard it is to get right? :) >>=20 >> --Richard > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Tue Jun 26 12:23: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 D993D11E80CE for ; Tue, 26 Jun 2012 12:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmG9M5Fr3Zya for ; Tue, 26 Jun 2012 12:23:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0D11E809F for ; Tue, 26 Jun 2012 12:23:20 -0700 (PDT) Received: by yenq13 with SMTP id q13so294920yen.31 for ; Tue, 26 Jun 2012 12:23:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=WCz12OgB8B90DHfIf32qgrbmEwLXWadqJVT+3WhOt5w=; b=EN/KxG5xWJBIfh0zYaXNz/juoP2cqOipqYetdI2tg4vlpnWtMw3bzx7A9GGY6GwMyE ka3HO3nooskwJ6c4DACMLxkFbuZjzChm1RqFFmapEZxHf8cEw235PzoXq15FqK2oNKb8 z1aRvIKm49cVudXwCe2K5FBGhNcq3QA6Cfgxmq6ZdzeWInCjXqg/yCMqfh8WXHe8gET9 ExP5MVes005jrKUngPHL7y2O5mY3I2jZxsetedHlSDxghzUN5Vd1yaklT791CxAuD/qG QJsypENXqV2sggxJNMU/+PuShbS+RgV7xgnHsTmY1ySAf8aV3SeJAiGBrzIbdwOZaeNx Aaqw== Received: by 10.236.120.7 with SMTP id o7mr19056736yhh.55.1340738599494; Tue, 26 Jun 2012 12:23:19 -0700 (PDT) Received: from [192.168.1.34] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id g66sm142110198yhf.15.2012.06.26.12.23.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 12:23:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_12601982-DADA-406D-9EA9-43D6E1B763AE"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 26 Jun 2012 15:22:49 -0400 Message-Id: <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkdNJNt5sHtHO8xNl9tJkJIVMCWvkGrn0lZxxBNICEcDaVKqyVjHEUkvDM0yAu4hnWi0RnM Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Tue, 26 Jun 2012 19:23:23 -0000 --Apple-Mail=_12601982-DADA-406D-9EA9-43D6E1B763AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > > Alternatively, you could provide a whole JSMS EncryptedData object on = the first shot, with WrappedKeys for keys you know. Then, if a = recipient doesn't find a WrappedKey for himself, he can for it, = and you can just respond with the WrappedKey. >=20 > --Richard >=20 >=20 That is what I was trying to get at. The existing spec supports sending = the wrapped content key with a keyid. You send that with every message, if the recipient doesn't have the = necessary key it requests it. The receiver retrieves the key and unwraps the CMK. There is nothing = in the current spec that stops that from working. The message and integrity are based on the wrapped key. That is the = decision the WG took a while ago. Having multiple recipients each with a different symmetric or asymmetric = key used to wrap the CMK is slightly different problem. Jim's proposal for having multiple recipients in the header has = potential, I don't support everything in it but it contributes some = useful ideas to support multiple recipient and signature use cases. John B. >=20 >=20 >=20 >=20 > On Jun 25, 2012, at 7:02 PM, John Bradley wrote: >=20 >> Richard, >>=20 >> There was some other back and for with Matt. >>=20 >> He is only encrypting to one recipient at a time. >>=20 >> Not that encrypting the CMK to multiple recipients is not valid, = that is just not how the protocol works. >>=20 >> The message is encrypted once and whatever endpoint gets it calls = back to the sender to get the key. >>=20 >> The issue as I understand it is that the sender doesn't know the = public key for the recipient before it sends the message. >>=20 >> I am happy to work on Matts issues, but I think they are separate = from the point you are making on integrity protecting the header. >>=20 >>=20 >> John B. >>=20 >> On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >>=20 >>>> Having read Matt's spec, he is not breaking JWE to send to multiple = recipients. As the spec says: >>>> "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" >>>=20 >>> He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >>>=20 >>> Compare JSMS and the WrappedKey structure, or CMS and RecipientInfo. >>> >>> >>>=20 >>>=20 >>>> I should also point out that the messages are transported in XML, = and as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>>=20 >>>> There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>>=20 >>>> For the transmission of the messages, I can't see any reason to not = use the JWE spec as currently written. It certainly supports the use = case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>>=20 >>>> Currently the message on the wire looks like: >>>>=20 >>>> >>> from=3D'juliet@capulet.lit/balcony' >>>> id=3D'fJZd9WFIIwNjFctT' >>>> to=3D'romeo@montegue.lit/garden' >>>> type=3D'chat'> >>>> >>> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>>
>>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>>> NpemUiOiIxNiJ9 >>>>
>>>> >>>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>>> eCGP >>>> >>>> >>>> >>>> >>>>=20 >>>> I would have sent header and data as one element using the normal = JWE dot separated format, but I need to talk to Matt to understand his = reasoning. >>>>=20 >>>> I note that his example is using AES-CCM, and so not documented in = JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>>=20 >>> Valid point. I had missed that RFC 5084 handled the ICV separately. >>>=20 >>>=20 >>>> I don't quite get your point on integrity protecting the wrapped = key causing the integrity value to change. For HMAC, GCM, and I think = CCM, changing the encryption key changes the tag value anyway (sort of = the point I thought). The only time it would stay the same would be if = you were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >>>=20 >>> The point is that you have to re-compute the ICV over the entire = header+content every time you wrap a new key. This is kind of a big = deal for the XMPP case. =20 >>>=20 >>> Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >>>=20 >>> So integrity protecting the headers has real costs in terms of both = scalability (state) and security. >>>=20 >>>=20 >>>> There are some interesting things Matt=92s spec is attempting with = using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>>=20 >>> My point is that we shouldn't need a whole new protocol for this. = CMS RecipientInfos do exactly what we want. (Er, what *Matt* wants.) = We should just be copying and pasting. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> I am happy to work with Matt to refine his ID. >>>>=20 >>>> I recommend others read it as well so we can understand if there = are any real issues. >>>>=20 >>>> Regards >>>> John B. >>>>=20 >>>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>>=20 >>>>> Hey John, >>>>>=20 >>>>> I think you're missing the bigger point here, which is: In order = to allow for multiple recipients, Matt had to break JWE. >>>>>=20 >>>>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>>=20 >>>>>> Hi Matt, >>>>>>=20 >>>>>> Complements on updating the draft. >>>>>>=20 >>>>>> The issue I see is that you are attempting to distribute the CMK = out of band and use "none" as the alg. >>>>>>=20 >>>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>>=20 >>>>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>>>> =46rom a implementation point of view the symmetric cypher always = gets the CEK derived from the CMK in the message independent of if it is = using RSA or A128KW/A256KW. >>>>>>=20 >>>>>> That imposes some extra steps for people using symmetric keys but = encourages rotation of the CEK that would likely not happen otherwise. >>>>>>=20 >>>>>> So in your spec I would expect you to distribute a shared secret = via keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>>>>>=20 >>>>>> I also suspect that you intended to use A256GCM as the enc alg = and not A256CCM.=20 >>>>>>=20 >>>>>> I am not a XMPP expert so it will take me some time to go over it = in detail. I would like to understand the use case to be certain it is = properly supported. >>>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>>>=20 >>>>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been updated = to the latest JOSE WG drafts. >>>>>>>=20 >>>>>>>=20 >>>>>>> - m&m >>>>>>>=20 >>>>>>> Matt Miller - >>>>>>> Cisco Systems, Inc. >>>>>>>=20 >>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>>>> Author(s) : Matthew Miller >>>>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>>>> Pages : 22 >>>>>>>> Date : 2012-06-21 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This document defines a method of end-to-end object encryption = for >>>>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>>>=20 >>>>>>>> A diff from previous version is available at: >>>>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> I-D-Announce mailing list >>>>>>>> I-D-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_12601982-DADA-406D-9EA9-43D6E1B763AE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjE5MjI0OVowIwYJKoZIhvcNAQkEMRYEFHY639mFbTreZZQLGk1XCyjLvBcUMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AA4aA4VdTmjVTd296fVUZd8wHAaECTaF6wIJ82+lCeU5SSphBpoi9O3TlUYrq1Yf4gMqRZZkNtdL sKhfz/uP7ud+yaflrjLCWaJ/9lo53+mb3XV4twbe6XQFJQGns6QK7QsyECpsY7YwLPS1J5mD7OGp hNkxbCMMU1VxG2vI35mkVXuLLhM3uIzIj6PAdTlwYOQZyrvD4flULo+lClX3n1aKTOvQS1dGKGdp KTKl6sMPi/MdC+Fzt/pTHs9v0ogX579+g3caaTYo5QaJc33Ps8+YkJY+VFOfe7LdTB6t9opoDLs7 Ls0UksdoVwb1UbCWS7PeYdn/CAwDSc424rnVGagAAAAAAAA= --Apple-Mail=_12601982-DADA-406D-9EA9-43D6E1B763AE-- From mamille2@cisco.com Tue Jun 26 12:26: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 B24EF11E80D9 for ; Tue, 26 Jun 2012 12:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whLTdXW7PyOW for ; Tue, 26 Jun 2012 12:26:11 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 053F711E80D6 for ; Tue, 26 Jun 2012 12:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5949; q=dns/txt; s=iport; t=1340738770; x=1341948370; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Ecbap52yKhEDUx4Bz6QO111fHQcy2SzQ+sL1nX8FXuk=; b=ekkgGl6KIu13xaKlpUuvuW1mgwqI6COllfQ9vtfMS5pQg7f2kJw66klG r6qD6cH9yJf7SOCNz/kOQJvyzW0TCPZlLPNnjdXSZxhM1ywPXOkk47j57 v9fs7yC2631w8FrTYdqnVcVoABv70TxQbqlcPEpioc/vqUJxRQNAXfCm4 o=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIoL6k+rRDoH/2dsb2JhbABEtjWBB4IZAQEEEgFmEAsOOAJVBhMih2gBmSGgR4s3hSRgA4hKhX2Ga4VWiEeBZoJ+ X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="sig'?p7s'?scan'208";a="47141612" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 26 Jun 2012 19:26:10 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5QJQA93015519; Tue, 26 Jun 2012 19:26:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--493153104" From: Matt Miller In-Reply-To: <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> Date: Tue, 26 Jun 2012 13:26:23 -0600 Message-Id: References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> To: John Bradley Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: "Richard L. Barnes" , jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Tue, 26 Jun 2012 19:26:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--493153104 Content-Type: multipart/signed; boundary=Apple-Mail-1--493153105; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-1--493153105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 26, 2012, at 13:22, John Bradley wrote: >> >=20 >=20 >> Alternatively, you could provide a whole JSMS EncryptedData object on = the first shot, with WrappedKeys for keys you know. Then, if a = recipient doesn't find a WrappedKey for himself, he can for it, = and you can just respond with the WrappedKey. >>=20 >> --Richard >>=20 >>=20 > That is what I was trying to get at. The existing spec supports = sending the wrapped content key with a keyid. >=20 > You send that with every message, if the recipient doesn't have the = necessary key it requests it. >=20 > The receiver retrieves the key and unwraps the CMK. There is nothing = in the current spec that stops that from working. >=20 > The message and integrity are based on the wrapped key. That is the = decision the WG took a while ago. >=20 > Having multiple recipients each with a different symmetric or = asymmetric key used to wrap the CMK is slightly different problem. >=20 > Jim's proposal for having multiple recipients in the header has = potential, I don't support everything in it but it contributes some = useful ideas to support multiple recipient and signature use cases. >=20 > John B. >=20 >=20 Allow me to work on a version of xmpp-e2e that uses "alg":"A128KW" (or = "A256KW"), and see what it looks like. I have a couple of other drafts = to get done before the -00 deadline, but I should get back to this = before 07/09. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-1--493153105 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyNjE5MjYy M1owIwYJKoZIhvcNAQkEMRYEFJfgT7v1eTlAGwHSD5yEYcszzstXMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBKRWU4n3reqy5qBE0HwBOuHB4ejg6xngpzps7CQUXzOLKSD9MUc2qfdNy6 gGDgjhQrU4bMNvc26rTychnX1uhl0+BGX3z95ufshHFUTLXiONk/A8Bn/35JLmzQ+LMpmpfsokpD PmaXTX02RFEId/r68M4lTuVKjCzVG5rSoFlaUIfbzODE3Wvs0LmDx76JJuw/I0Kq+GiKltcsNfxK 06JhulAEw4mY3ISsiDL0kWTwVSMvApjtJu3ml9JtJuCm3NPJvghWzLuE29a2owOEWnDAUrzCwusx YOBGgu/OfzrBiLoo8KVYMN6ReX514BtPsW1StiHYxtrBDBQl+Qqy6t+wAAAAAAAA --Apple-Mail-1--493153105-- --Apple-Mail-2--493153104 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP6gzfAAoJEJq6Ou0cgrSPUxkIANJhSMdOxWZUAkKDZaKylwvP hYi5cHcWNBsgEE4drAs3ES9HZN5S3moEfR7IpbLkvzLQjCIj1KAUKCbgWwYecC91 ra+bM6CE2QgpWMqeyBMBCS6OwCWTHox4PXv7sAnC+Od35VwBA/fmA+55oepknnV0 fBb3ZXcnDHw+kjtHnrhgQYffXs7FdQTQ2nMqUlh5stvXBqoyesu5GIpmtBpFuxQv 81jO2LDNiV5cyVZ5qoDt+2Zsv360ntT3B8EbSTXVA8lu66D8nKCQbtPA5qScWhjJ PrfkC+5p5rjLE0c/mtM4/GZiBdUljYqEnM5kp13s6jfyYTAKwI/yUX7nFE8Jvfs= =divD -----END PGP SIGNATURE----- --Apple-Mail-2--493153104-- From ve7jtb@ve7jtb.com Tue Jun 26 12:30: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 167C421F84E1 for ; Tue, 26 Jun 2012 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkFLIxVOeH40 for ; Tue, 26 Jun 2012 12:30:48 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02D0D21F84DD for ; Tue, 26 Jun 2012 12:30:47 -0700 (PDT) Received: by yenq13 with SMTP id q13so302861yen.31 for ; Tue, 26 Jun 2012 12:30:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=eNZClEN6FhLV6qRP3+oypS9xfvZTdKWSZXBX2303d44=; b=DE80k2a1m3w54rNae1GKjq+IQhfiBU4gFH+7ATvSrRL3/kY62ZruKsCw5uuKUmslDM b1Jrz9IVkP9zFRNxxpO3pYJPk10lQixKp69IrrP5n/VN37ooxsIulAs4KxodC31f3/Ia kVUaVJl79nfC70r2m3LGXFCJxL6Jplh+l4I3q5LQmnIt1i1SctThvy8XX1O98egXczAl WpnVtDC94biP4gb7rc+8IlWtkKPPG68y8DWI1a0eRn1qIB9+TWh9dbKif3/xlmhmxrSe 1iPOsjPDqLBZ1Wub2XRC3LaT7OdOD8NwgUKlfnqUBA7j9hExsHx8MGOHH3T/llMN9wyd pXCQ== Received: by 10.236.9.34 with SMTP id 22mr19484050yhs.13.1340739047289; Tue, 26 Jun 2012 12:30:47 -0700 (PDT) Received: from [192.168.1.34] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id g4sm142151966yhf.12.2012.06.26.12.30.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 12:30:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_5DE61160-A737-4FEA-98A9-E346B185701E"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 26 Jun 2012 15:30:09 -0400 Message-Id: <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQknSEYufmUB5QsWRLEyYa44IpLhZjFb/GsLSO0L473DXXTn/yaSMKVl7kTkfse7Wdda4qIx Cc: Jim Schaad , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 19:30:51 -0000 --Apple-Mail=_5DE61160-A737-4FEA-98A9-E346B185701E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There was a WG decision to not allow encryption without integrity. Jim = and others call that sender verification. Or on simple terms no AES-CBC without a mandatory MAC integrity. The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. We do have s JWT spec that covers the body for security tokens. The = idea was to separate that from signing and encryption so that signing = and encryption can be used for other objects. John B. On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >> In those cases one can easily argue that the header should be = protected as much as in HMAC. >=20 > Can you clarify the scope of "we are mandating"? >=20 >=20 >> There may well be signing_time or other elements that would go into = the header as well for JWE. >=20 > Why do these need to go into the header rather than the body? >=20 > --Richard >=20 >=20 >=20 >=20 >> Regards >> John B. >>=20 >> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>=20 >>> >>>=20 >>> Richard, >>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>> Richard L. Barnes >>>> Sent: Monday, June 25, 2012 2:35 PM >>>> To: Nat Sakimura >>>> Cc: Mike Jones; jose@ietf.org >>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >>>> 00.txt >>>>=20 >>>> Hi Nat, >>>>=20 >>>> I'm not sure what X.509 fiasco you're referring to. There was a = recent >>> MD5 >>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, there = have >>> been >>>> recommendations for preventing this attack in X.509 since 2005 [2]. = As >>> was >>>> noted on the SAAG list, the real news here is that Microsoft wasn't >>> following >>>> any of those recommendations. >>>>=20 >>>> JWS would have had the same problem as X.509. The attack did not = modify >>>> the cryptographic parameters (anything that would have gone in the >>>> header), it would not have been thwarted by the integrity = protection we're >>>> worrying about. >>>>=20 >>>> Actually, the header signing that JWS does makes it even nicer for = the >>>> attacker: Flame used a "chosen prefix" attack, so since the JWS = header >>> value >>>> is entirely static for a given signer, it's easy to use as a fixed = prefix. >>> If JWS just >>>> signed the content, then the application could include a something = random >>>> up front to prevent such prefix-based attacks. >>>>=20 >>>=20 >>> I don't believe that this is a true statement. If you had a prefix = or just >>> signed what was given to you (i.e. no prefix), it would make no = difference >>> in terms of the attack for Flame. Flame could always use a fixed = prefix of >>> its own design rather than using the fixed header that is generated = by >>> having JWS sign the header information. >>>=20 >>>> It's tempting to say that we should just add randomness to the JOSE >>> format. >>>> But the real lesson of the Flame/MD5 attacks is operational: If = you're >>> signing >>>> something that somebody else gave you, make sure that you're not = signing >>>> exactly what they gave you. Follow the recommendations of RFC = 4270. In >>>> other contexts, there's no need of similar random elements; it just = adds >>>> complexity. >>>=20 >>> This is definitely a true statement in all events and is something = that >>> should be added to the Security Considerations section. >>>=20 >>> That being said, I think that there are valid reasons for wanting to = protect >>> the header information by some authentication processing. PKIX = certificates >>> protect the signature algorithm information (by copying the data = into the to >>> be signed block) and CMS has long allowed for information to be = included in >>> the signed attributes area that identifies the algorithms used, the >>> certificates used and so forth. There are also other things that we = might >>> find to be convenient to be placed in the header information that is = current >>> not there (a signing time and embedded content type comes to mind) = that >>> would be a product either of specific types of signatures or becomes = a >>> common attribute to be placed there. >>>=20 >>> In terms of encryption operations, I remember in the past that I = have had >>> either corrupted encrypted streams or corrupted IVs and had a = successful >>> decryption that later generated other problems when trying to parse. = This >>> is less of an issue with AEAD algorithms as they have a much = stricter rule >>> on when the stream decrypts correctly. >>>=20 >>> Jim >>>=20 >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> [1] >>>> [2] >>>>=20 >>>>=20 >>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>=20 >>>>> Especially after the X.509 fiasco, I strongly believe that having >>> integrity >>>> check over the metadata is a good thing. It is such a little effort = that >>> gives us >>>> much more protection down the road. In this sense, I fully agree = with Ben >>>> here. We should have integrity protection over the header. >>>>>=20 >>>>> Nat >>>>>=20 >>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>> wrote: >>>>> Two years ago when the developer community needing a JSON-friendly >>>> token format was designing the JSON Web Token (JWT), we explicitly = asked >>>> security experts whether the header parameters should be integrity >>>> protected or not. Among them, Ben Laurie was one of the voices = saying >>> that >>>> securing them was the right thing to do. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> He argued that if the parameters can be protected in a practical = manner, >>>> then they should. Doing so provides an additional hurdle that = attackers >>>> would have to surmount. For example, if they can try to substitute = a >>> weaker >>>> authentication scheme, then they must figure out how to make it >>>> authenticate correctly despite some plaintext they can't control - = the >>> header >>>> parameters. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Ben also took the position that paring security protocols down to = the >>> least >>>> you can get away with, given attacks you can think of, is not a = good >>> design >>>> principle. If there is not a strong argument against including a = feature >>> that >>>> may make it harder for attackers, then that feature should be = included. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I agree with him. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The decision to provide integrity protection for the headers is >>> documented >>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> . What to sign (envelope.payload or just payload)? >>>>>=20 >>>>> Given that the envelope is extensible and therefore may contain >>> security- >>>> sensitive information, we reached a consensus (with input from Ben = Laurie >>>> via IM) that the combination envelope.payload must be signed. >>>>>=20 >>>>>=20 >>>>> I believe that logic is as sound today as it was then. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> For all these reasons, I therefore personally stand by the = community's >>>> decision to provide integrity protection for the headers. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Best = wishes, >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>> John Bradley >>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>> To: Richard L.Barnes >>>>> Cc: jose@ietf.org >>>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >>>> 00.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Hi Richard, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> While for PKCS 1.5 the hash algorithm is baked into the padding = and not >>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>=20 >>>>> There are possible hash truncation attacks by shortening SHA256 to >>> SHA224 >>>> as an example (I know we preclude truncated hashes at the moment). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The bad feeling I get around this is that if there is a scenario = where >>> the >>>> attacker controls the plaintext to be signed and there is no signer >>> controlled >>>> text contributed there are potential bad things that could happen = down the >>>> road. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This bit us with x509 certs not that long ago (yes with MD5 = admittedly) >>>> where the attacker could use a certificate extension to include = extra data >>> and >>>> cause a pre collided hash to be generated. >>>>>=20 >>>>> Having part of the signed data outside the control of an attacker = is a >>> good >>>> thing. (having a nonce or message ID in the envelope is possible = though >>> not >>>> yet required in JWS.) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I am still of the opinion that putting the base64 encoded envelope >>> inside >>>> the hash calculation is a valid way to allow additional attributes. >>>>>=20 >>>>> Another structure to hold the attributes adds more complexity, as = would >>>> saying that they need to be inside the signed object. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I think part of this is that as one of the openID Connect authors = I look >>> at this >>>> as a necessary security token format, for OAuth and Connect. >>>>>=20 >>>>> For that simple processing with one signature is a high priority = for >>> adoption. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =46rom a general signing/encrypting of documents point of view you >>>> legitimately have different priorities. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I know it is hard to prove a negative but It is also going to be >>> difficult for me >>>> to go back to security people at google Facebook and other places = and >>>> explain how not integrity protecting the header could be better = than >>>> integrity protecting it. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> It seems that I would be reduced to arguing that this is no worse = than >>> CMS >>>> and that hasn't been proven insecure yet. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Allowing a possible attacker to control the hash output, and not >>> integrity >>>> protecting the additional data, seems like something I am bound to = regret >>> in >>>> the future. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Hey John, >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> Interesting points, but I don't think they actually apply here. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to downgrade attacks: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> The attack that RFC 5752 is concerned with is when an attacker = strips >>>> signatures from a signed message, so that the only ones left are = ones he >>> can >>>> tamper with. So the integrity protection here is "horizontal"; it = goes >>> across >>>> signatures. The integrity protection in JWS/JWE is "vertical" -- = it only >>> protects >>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to "brown bag" attacks: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> The root of this attack is ambiguity about what content is = *signed* >>>>>=20 >>>>>> vs. what content is *used*. If an application doesn't verify = that >>>>>=20 >>>>>> it's actually using the stuff that's signed, then it can be = tricked >>>>>=20 >>>>>> into accepting something unsigned. (Cf. >>>>>=20 >>>>>> ) >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> However, I don't think any of the current proposals have that = problem. >>>> In JWE/JWS, the signed content is right there between the dots, and = in >>> JSMS, >>>> it's in the "content" element. The current JSMS draft does allow = detached >>>> signatures, but with a "voids your warranty" sticker on it. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> In any case, these attacks have nothing to do with whether the >>>> cryptographic parameters are integrity-protected with the content. = The >>>> example attacks in the IBM still work regardless -- the whole point = of the >>>> attack is that the cryptographic processing is the same, only the >>> (non-crypto) >>>> matching of content is flawed. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to "arbitrary attributes": >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> We can have that here, too, but you need canonicalization. And >>> base64- >>>> encoding is not not canonicalization -- it just waves its hands = over the >>>> question of equivalence. In my opinion, we should keep the = cryptographic >>>> object simple by disallowing attributes, and push the attributes = you would >>>> sign inside of the thing being signed. If people really do want >>> attributes, it >>>> doesn't seem to me like JSON canonicalization is very hard. I can = do it >>> in 19 >>>> lines of python: >>>>>=20 >>>>>> >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard too "meta-data in the body": >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> It seems to me like if we're trying to define a general format = for >>> applying >>>> security protections, then we ought to keep out things that aren't >>> strictly >>>> security relevant. Those things can go in application-specific = content >>> types >>>> (e.g., SAML) without polluting the general purpose header. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to "defense in depth" and selling this to government >>>> agencies: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> CMS, via S/MIME, is in broad use across multiple federal agencies = and >>>> large enterprises. JSMS is essentially a profile of CMS (see = Section 7), >>> and >>>> has the same security properties. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> Cheers, >>>>>=20 >>>>>> --Richard >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>> Hi Richard, >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> Originally we only integrity protected the header for signing. = We >>> added >>>> the integrity protection to encryption as part of AEAD, as = encryption can >>> also >>>> be used for sender verification. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I understand the argument that it makes things simpler if we = don't >>>> integrity protect the header information. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> However xmldsig, provides integrity over those elements to = prevent >>>> possible downgrade attacks by manipulating the algorithms. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> CMS may not typically provide that integrity protection but I = think >>> Jim >>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>=20 >>>>>>> Given they are on this list they can speak to their view on = integrity >>> over >>>> the crypto parameters. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I also recall when working on InfoCards there was a Monte = Carlo/Brown >>>> Bag attack that needs to be considered if we move to something more = like a >>>> detached signature. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> The other design consideration is that we wanted to be able to = sign >>>> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>>>=20 >>>>>>> That prevented us from including meta-data in the body as we = didn't >>>> want to touch it. That left us with the header to include = additional >>> elements >>>> in. >>>>>=20 >>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I am not a CMS expert but I believe it allows for signing of >>> arbitrary >>>> attributes not unlike the current JOSE spec. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> Especially for something that will be used with JWT security = tokens I >>> will >>>> have a hard time making the argument to NIST and others that need = to >>>> approve this format that not integrity protecting the header = parameters is >>>> appropriate defence in depth, for something that might be replacing = signed >>>> SAML assertions in some applications. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I do understand how not integrity protecting the header will = make >>> some >>>> things easier, however I can't agree that the benefit outweighs the >>>> disadvantages. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> Regards >>>>>=20 >>>>>>> John B. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>>> Hey Mike, >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Thanks for having some back-and-forth with me on this. I think = this >>> is a >>>> good discussion to have right now. I would like to discuss some >>> high-level >>>> points, and then I'll respond inline to your precise points. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to = define >>> JSON- >>>> based formats for integrity and confidentiality protections. JWE = and JWS >>>> don't fit that requirement, so we should re-consider their adoption = and >>> call >>>> for new candidates. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Major points: >>>>>=20 >>>>>>>> 1. JOSE is JSON >>>>>=20 >>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>=20 >>>>>>>> URL-safeness are still OK, as derivatives >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Part 1: JOSE is JSON >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> The JOSE WG charter calls out four deliverables, three of which = are >>>> explicitly required to be JSON: >>>>>=20 >>>>>>>> -- "JSON-structured integrity protection" >>>>>=20 >>>>>>>> -- "JSON-structured encryption" >>>>>=20 >>>>>>>> -- "public keys as JSON-structured objects" >>>>>=20 >>>>>>>> (The fourth is just a list of algorithms, which should be JSON = as >>>>>=20 >>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> In light of these requirements, JWE and JWS are clearly not = suitable >>>>>=20 >>>>>>>> candidates to fulfill the working group's milestones. (At = least in >>>>>=20 >>>>>>>> their current form.) So ISTM that we need to step back and >>>>>=20 >>>>>>>> re-evaluate alternatives for the three above milestones, = especially >>>>>=20 >>>>>>>> the first two. (JWK is not as far off.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> As JSON-based mechanisms, though, the "JSON serialization" = drafts >>>> are pretty half-hearted. Because JWS and JWE include the = cryptographic >>>> parameters within the integrity protection, they have to have the = headers >>>> included as base64-encoded strings. That obviously adds a lot of >>> complexity >>>> to encoding and decoding -- for example, you have to keep the = encoded >>>> header around even after you've decoded it! -- and just plain more = octets. >>>> The support for multiple recipients and multiple signatures is both >>> unweildy >>>> (matching up parallel indices for headers and signatures) and = inefficient >>>> (multiple integrity check values in encrypted objects). >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom = that >>>> went into CMS, while making the syntax pure JSON and as simple as >>> possible. >>>> Multiple signatures and multiple recipients are supported with = absolute >>>> minimum overhead. So I think it's worth consideration by the = working >>> group. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I would like to dispel the myth that a JSON-based format = requires >>>>>=20 >>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>=20 >>>>>>>> "canonicalization" (via base64url encoding) because it's = included >>>>>=20 >>>>>>>> within the integrity protection. I'm not aware of any reason = for >>>>>=20 >>>>>>>> including the cryptographic parameters in the integrity check, >>>>>=20 >>>>>>>> instead of only integrity-protecting the content itself. = Indeed, if >>>>>=20 >>>>>>>> there were an attack based on non-integrity-protected = cryptographic >>>>>=20 >>>>>>>> parameters, it would be a pretty big deal, since neither CMS = nor IKE >>>>>=20 >>>>>>>> nor provides this protection. (TLS does provide a signature = over >>>>>=20 >>>>>>>> the algorithms, but only as a way to bind the public key to the >>>>>=20 >>>>>>>> session.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Indeed CMS doesn't require canonicalization at all, except for >>>> attributes that are included in the protected content (signedAttrs = / >>>> authenticatedAttrs), which need to be DER-encoded. In JSMS, we = don't >>>> allow those parameters, so there is no need for canonicalization at = all. >>> All the >>>> "canonicalization" that's needed is to base64url-encode the = protected >>>> content. In that regard, JSMS is even simpler than JWE/JWS. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Part 3: Compactness and URL-safeness are still OK, as = derivatives >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I have absolutely no objection to defining a compact, URL-safe >>> format. >>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example >>> from >>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> { >>>>>=20 >>>>>>>> "v":1, >>>>>=20 >>>>>>>> "t":"au", >>>>>=20 >>>>>>>> "a":"hs256", >>>>>=20 >>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>=20 >>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>=20 >>>>>>>> "ki":"rSIilRk8Ego" >>>>>=20 >>>>>>>> } >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> If we remove the decorative spaces and base64url-encode, we = only >>>> use >>>>>=20 >>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>>>=20 >>>>>>>> further and define an explicit compact format for = AuthenticatedData, >>>>>=20 >>>>>>>> we can emulate JWS by moving the content and MAC fields outside >>>> and >>>>>=20 >>>>>>>> dot-combining. That avoids double-base64url-encoding, and only >>>>>=20 >>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put the = code >>>>>=20 >>>>>>>> to generate these in the Github project linked earlier.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> So it's fine to have a compact, URL-safe format for an = objective, >>> but it >>>> makes *much* more sense to derive that from a full-size, usable, = JSON >>>> format than the other way around. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Responses to specific points inline below. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before = doing >>> so, I'll >>>> say that I'm writing in the spirit of trying to increase mutual >>> understanding >>>> and consensus, rather than taking the point of view that the status = quo is >>> the >>>> only reasonable outcome. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Not being JSON >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> This was by design, so that the results are URL-safe. This is >>> required, >>>> for instance, for them to be used as OAuth Bearer Tokens. At the = request >>> of >>>> the working group, closely related pure-JSON drafts were also = published. >>>> See: >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri >>>>>=20 >>>>>>>>> alization-01 and >>>>>=20 >>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser >>>>>=20 >>>>>>>>> ialization-01 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Use them if you prefer if they better suit your use cases. = They >>> could >>>> be adopted as working group documents, if there's interest. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> See above. These are super-clunky, and the need to be the main >>>> focus of the WG, not an afterthought. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Not supporting multiple recipients >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> The JSON serialization drafts above do, again, in response to = use >>>> cases presented by the working group. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> See above. Because of the unnecessary inclusion of the header = in >>> the >>>> integrity check, this is far less efficient than it should be. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Functionally, these are very similar operations, at least from = an >>>> implementation perspective, so it's not clear that making a clear >>> distinction >>>> would help either developers or adoption in any practical way. = They >>> achieve >>>> overlapping, but admittedly sometimes different goals. I believe = that >>>> developers can be trusted to use the algorithms that achieve their >>>> applications' goals without making a hard distinction between the = two. >>> But >>>> I'd be interested in hearing your thoughts on why you believe a >>> brighter-line >>>> distinction might be useful or necessary. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> It's important if you want to do MACs with anything other than = pre- >>>> shared keys. If you want to do anything more advanced, you need to = have >>>> wrapped keys, in which case an object with a MAC starts to look a = lot more >>>> like a JWE than a JWS. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lacking clear processing instructions for different key >>>>>=20 >>>>>>>>> establishment modalities >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> This seems like an area where the existing drafts could be = refined >>> to >>>> add descriptions for additional establishment modalities, possibly = based >>>> upon your ideas and descriptions, should the working group decide = to do >>> so. >>>> What additional modalities do you have use cases for that you = believe are >>>> not achievable or straightforward with the existing drafts? The = existing >>>> modalities supported are largely those that existing developers had = told >>> us >>>> they needed and draw both from the precursor draft-jones-json-web-* >>>> documents and draft-rescorla-jsms. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Bear in mind that the balance that the current drafts try to = strike >>> is >>>> keeping the Mandatory to Implement (MTI) feature footprint small = enough >>>> that developers, including Web developers, are likely to adopt the = specs, >>>> while still providing enough functionality to make them generally = useful. >>> As >>>> in any balance, it's often possible to shift things a bit and still >>> maintain the >>>> balance, but I'd like people to keep the ubiquitous adoption goal >>> front-and- >>>> center when proposing additional functionality. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>=20 >>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>>>=20 >>>>>>>>> that!) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I agree that we need to find a reasonable MTI. The current = JSMS >>> draft >>>> doesn't really specify which parts are MTI, beyond basic things = like >>> base64url >>>> encoding and ignoring unknown fields. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> My main concern is that JWS and JWE don't really tell me which >>> fields >>>> need to be present for which use case. If I'm putting a MAC on a = JWS vs. >>> a >>>> signature, do I need "jwk" or "jku" fields to be populated? = Whereas in >>> JSMS, >>>> I think these things are much clearer due to the separation of the = use >>> cases >>>> (Signed/Authenticated/Encrypted) and the isolation of signatures = and >>>> wrapped keys into sub-objects. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lack of clear typing of objects >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Most JSON documents aren't clearly typed; instead, developers = and >>>> implementations understand from context what the meaning of each = field is. >>>> XML is clearly typed, but developers are voting with their feet by = moving >>> to >>>> JSON. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> What practical advantages resulting from overlaying a typing >>>> infrastructure on JSON do you believe are worth the potential costs = of >>> doing >>>> so? BTW, I'm not opposed to having a JSON schema description of = the JOSE >>>> JSON data structures like JSMS did in = http://tools.ietf.org/html/draft- >>>> rescorla-jsms-00#appendix-A, but I'll remark that this an = informative >>> tool, not >>>> a normative one. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I actualy don't have a hugely urgent requirement here either. = It's >>>> something that others in the WG had requested, which is trivial to = add in >>>> JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity >>>> protection of the header. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lack of versioning for future extensibility >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> An optional version field could be added if the working group >>>>>=20 >>>>>>>>> desires, however the last time the working group discussed it, = they >>>>>=20 >>>>>>>>> decided not to do so. Rather, specs like this effectively = become >>>>>=20 >>>>>>>>> "versioned" when revised in a way that new fields are added. = If >>>>>=20 >>>>>>>>> you understand the new fields, you support that new version. = (Note >>>>>=20 >>>>>>>>> that this is independent of whether there is a version number >>>>>=20 >>>>>>>>> field, which according to some participants in the previous >>>>>=20 >>>>>>>>> discussion, they regarded as therefore being redundant >>>>>=20 >>>>>>>>> information.) >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> I'm not religious about not having a version number field, but >>> often >>>> "less is more". >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Indeed, I'm not religious either. It just seems like a general = good >>> idea >>>> to state this directly as opposed to having parsers divine it based = on >>> which >>>> fields are present. To quote RFC 5652: >>>>>=20 >>>>>>>> " >>>>>=20 >>>>>>>> Each of the major data structures includes a version number as = the >>>>>=20 >>>>>>>> first item in the data structure. The version numbers are = intended >>>>>=20 >>>>>>>> to avoid ASN.1 decode errors. Some implementations do not = check >>>> the >>>>>=20 >>>>>>>> version number prior to attempting a decode, and if a decode = error >>>>>=20 >>>>>>>> occurs, then the version number is checked as part of the error >>>>>=20 >>>>>>>> handling routine. This is a reasonable approach; it places = error >>>>>=20 >>>>>>>> processing outside of the fast path. This approach is also >>>>>=20 >>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>=20 >>>>>>>> " >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Best, >>>>>=20 >>>>>>>> --Richard >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Best wishes, >>>>>=20 >>>>>>>>> -- Mike >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> -----Original Message----- >>>>>=20 >>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>=20 >>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>=20 >>>>>>>>> To: Mike Jones >>>>>=20 >>>>>>>>> Cc: jose@ietf.org >>>>>=20 >>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>=20 >>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. = IMO, >>> the >>>> current JW* specs are deficient in several ways, e.g.: >>>>>=20 >>>>>>>>> -- Not being JSON >>>>>=20 >>>>>>>>> -- Not supporting multiple recipients >>>>>=20 >>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>=20 >>>>>>>>> -- Lacking clear processing instructions for different key >>>>>=20 >>>>>>>>> establishment modalities >>>>>=20 >>>>>>>>> -- Lack of clear typing of objects >>>>>=20 >>>>>>>>> -- Lack of versioning for future extensibility >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Looking at the current specs, it didn't seem to me that it = would be >>>> simple to adapt them to address these deficiencies. So I just did = a >>> re-write. >>>> If you think they can be addressed within the current framework, = please >>>> explain. I just found it simpler to start from whole cloth. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Cheers, >>>>>=20 >>>>>>>>> --Richard >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Hi Richard, >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>> documents, >>>> I encourage you to ask about them on the list. The documents have >>>> significant history going back to mid-2010 when convergence = discussions >>>> started among people with four different JSON signing & encryption >>>> proposals. JWT and the current JOSE specs and implementations are = the >>>> result. I realize that not all the JOSE participants were part of = those >>>> discussions from the beginning (although many were) and so teasing = out the >>>> rationale for specific decisions might help people better = understand the >>>> choices made, and hopefully thereby increase consensus behind the >>>> eventual working group choices. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> If the list that you're puzzled by is the bulleted list = below, >>> maybe we >>>> can start a discussion on that basis. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Best wishes, >>>>>=20 >>>>>>>>>> -- Mike >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>=20 >>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>=20 >>>>>>>>>> Behalf Of Richard L. Barnes >>>>>=20 >>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>=20 >>>>>>>>>> To: jose@ietf.org >>>>>=20 >>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>=20 >>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Dear JOSE WG, >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Like Mr. Manger, once I finally got around to doing a = thorough >>>> review of the JW* specs, I was kind of puzzled by some of the = design >>>> decisions. So I also went through and wrote an alternative format, = this >>> time >>>> taking a more of a cue from CMS. A link to the document is below. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Summary of differences: >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>>=20 >>>>>>>>>> parameters are represented in JSON. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS allows for full algorithm agility in key agreement, = while >>> JWE >>>>>=20 >>>>>>>>>> only allows ECDH-ES. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>=20 >>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>> WrappedKey >>>>>=20 >>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>>=20 >>>>>>>>>> encryption of the entire object for each recipient. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o The signature and MAC functions of the JWS object are = separated >>>>>=20 >>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS parameters are not integrity-protected, as they are = in JWE >>>>>=20 >>>>>>>>>> and JWS. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, = but >>> could >>>>>=20 >>>>>>>>>> be added without significant change. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>>=20 >>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> I've also thrown together an initial JavaScript = implementation >>> (based >>>> on NodeJS for some python crypto glue), which is on github: >>>>>=20 >>>>>>>>>> >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Comments are very welcome. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Thanks, >>>>>=20 >>>>>>>>>> --Richard >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Begin forwarded message: >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> From: internet-drafts@ietf.org >>>>>=20 >>>>>>>>>>> Subject: New Version Notification for >>>>>=20 >>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>=20 >>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>=20 >>>>>>>>>>> To: rbarnes@bbn.com >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>>>=20 >>>>>>>>>>> successfully submitted by Richard Barnes and posted to the = IETF >>>>>=20 >>>>>>>>>>> repository. >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>=20 >>>>>>>>>>> Revision: 00 >>>>>=20 >>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>=20 >>>>>>>>>>> Creation date: 2012-06-15 >>>>>=20 >>>>>>>>>>> WG ID: Individual Submission >>>>>=20 >>>>>>>>>>> Number of pages: 25 >>>>>=20 >>>>>>>>>>> URL: >>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>> jsms-00.txt >>>>>=20 >>>>>>>>>>> Status: >>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>=20 >>>>>>>>>>> Htmlized: >>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> Abstract: >>>>>=20 >>>>>>>>>>> Many applications require the ability to send = cryptographically >>>>>=20 >>>>>>>>>>> secured messages. While the IETF has defined a number of >>>> formats >>>>>=20 >>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings = which >>>>>=20 >>>>>>>>>>> are not easy to use in modern applications. This document >>>>>=20 >>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a = new >>>>>=20 >>>>>>>>>>> cryptographic message format which is based on JavaScript = Object >>>>>=20 >>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>> generate >>>> and parse. >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> The IETF Secretariat >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>>>> jose mailing list >>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>>>> jose mailing list >>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>>> jose mailing list >>>>>=20 >>>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>> jose mailing list >>>>>=20 >>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_5DE61160-A737-4FEA-98A9-E346B185701E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjE5MzAwOVowIwYJKoZIhvcNAQkEMRYEFFcSMaLmkCHeeJ31elZ8snQaXB9ZMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AKRMOn8soA1pIJelsQF/y0IlHiTb1plVQHlcsBhxf6NOnUK+U1U6Orw2diOBOU+6mrMwxQxaTHtC C3l6O5e6JQfooGpLFBFOXdPu0vPlDj74AEKw6+X9KjZ03kGd6+mkFeikJpGaAyLf1fdIZ0w6xrcI JfedBc1r7heu4LuEszyQuIOrJSgw1PSWaB2VtySV1ul82Rkpyowy8OyDDXcCcEvAPXfEmeeV2EKd fZcDE7W3zI0MVaDic+3ZKe68PlgaFJBgmSVnazi+RuS9E9vbevXNGZkRB6Zh2TtjzrIs0XuaX7XC CiVcXDBM0SAUsft5WyBbci6EJIQQlCl6pZGwLbIAAAAAAAA= --Apple-Mail=_5DE61160-A737-4FEA-98A9-E346B185701E-- From rbarnes@bbn.com Tue Jun 26 12:30: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 1348621F84EC for ; Tue, 26 Jun 2012 12:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvYyD9m+XauT for ; Tue, 26 Jun 2012 12:30:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEBD21F84DD for ; Tue, 26 Jun 2012 12:30:51 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:60155) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjbSj-0005v9-Uc; Tue, 26 Jun 2012 15:30:10 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> Date: Tue, 26 Jun 2012 15:30:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2A8A4F3B-CD0D-48C5-8A65-49A2E8C4D096@bbn.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Tue, 26 Jun 2012 19:30:53 -0000 >> Alternatively, you could provide a whole JSMS EncryptedData object on = the first shot, with WrappedKeys for keys you know. Then, if a = recipient doesn't find a WrappedKey for himself, he can for it, = and you can just respond with the WrappedKey. >>=20 >> --Richard >>=20 >>=20 > That is what I was trying to get at. The existing spec supports = sending the wrapped content key with a keyid. >=20 > You send that with every message, if the recipient doesn't have the = necessary key it requests it. >=20 > The receiver retrieves the key and unwraps the CMK. There is nothing = in the current spec that stops that from working. >=20 > The message and integrity are based on the wrapped key. That is the = decision the WG took a while ago. >=20 > Having multiple recipients each with a different symmetric or = asymmetric key used to wrap the CMK is slightly different problem. Obviously, JWE key wrapping works for single recipients. I don't = contest that. Multiple recipients is the problem. =20 Unless you want to support multiple recipients, there's no point to = Matt's scheme. It's tempting to think that it addresses the case where = the sender doesn't know the single recipient's key in advance, but in = that case, it would be much simpler just to have the sender request the = key at the start. So the whole point of Matt's document is to support = multiple recipients, at the cryptographic layer, even if not at the XMPP = layer (a given JID might have multiple keys, e.g., per device). Anyway, you skipped the important question in my mail: Do you think that = Matt's scheme compromises the security of the JWE? --Richard > Jim's proposal for having multiple recipients in the header has = potential, I don't support everything in it but it contributes some = useful ideas to support multiple recipient and signature use cases. >=20 > John B. >=20 >=20 >>=20 >>=20 >>=20 >>=20 >> On Jun 25, 2012, at 7:02 PM, John Bradley wrote: >>=20 >>> Richard, >>>=20 >>> There was some other back and for with Matt. >>>=20 >>> He is only encrypting to one recipient at a time. >>>=20 >>> Not that encrypting the CMK to multiple recipients is not valid, = that is just not how the protocol works. >>>=20 >>> The message is encrypted once and whatever endpoint gets it calls = back to the sender to get the key. >>>=20 >>> The issue as I understand it is that the sender doesn't know the = public key for the recipient before it sends the message. >>>=20 >>> I am happy to work on Matts issues, but I think they are separate = from the point you are making on integrity protecting the header. >>>=20 >>>=20 >>> John B. >>>=20 >>> On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >>>=20 >>>>> Having read Matt's spec, he is not breaking JWE to send to = multiple recipients. As the spec says: >>>>> "This document specifies an approach for encrypting communications = between two entities which each might have multiple end-points" >>>>=20 >>>> He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >>>>=20 >>>> Compare JSMS and the WrappedKey structure, or CMS and = RecipientInfo. >>>> = >>>> >>>>=20 >>>>=20 >>>>> I should also point out that the messages are transported in XML, = and as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>>>=20 >>>>> There are two somewhat separate uses for JWE in the spec: one for = encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>>>=20 >>>>> For the transmission of the messages, I can't see any reason to = not use the JWE spec as currently written. It certainly supports the = use case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>>>=20 >>>>> Currently the message on the wire looks like: >>>>>=20 >>>>> >>>> from=3D'juliet@capulet.lit/balcony' >>>>> id=3D'fJZd9WFIIwNjFctT' >>>>> to=3D'romeo@montegue.lit/garden' >>>>> type=3D'chat'> >>>>> >>>> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>>>
>>>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>>>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>>>> NpemUiOiIxNiJ9 >>>>>
>>>>> >>>>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>>>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>>>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>>>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>>>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>>>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>>>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>>>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>>>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>>>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>>>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>>>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>>>> eCGP >>>>> >>>>> >>>>> >>>>> >>>>>=20 >>>>> I would have sent header and data as one element using the normal = JWE dot separated format, but I need to talk to Matt to understand his = reasoning. >>>>>=20 >>>>> I note that his example is using AES-CCM, and so not documented in = JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>>>=20 >>>> Valid point. I had missed that RFC 5084 handled the ICV = separately. >>>>=20 >>>>=20 >>>>> I don't quite get your point on integrity protecting the wrapped = key causing the integrity value to change. For HMAC, GCM, and I think = CCM, changing the encryption key changes the tag value anyway (sort of = the point I thought). The only time it would stay the same would be if = you were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >>>>=20 >>>> The point is that you have to re-compute the ICV over the entire = header+content every time you wrap a new key. This is kind of a big = deal for the XMPP case. =20 >>>>=20 >>>> Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >>>>=20 >>>> So integrity protecting the headers has real costs in terms of both = scalability (state) and security. >>>>=20 >>>>=20 >>>>> There are some interesting things Matt=92s spec is attempting with = using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>>>=20 >>>> My point is that we shouldn't need a whole new protocol for this. = CMS RecipientInfos do exactly what we want. (Er, what *Matt* wants.) = We should just be copying and pasting. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> I am happy to work with Matt to refine his ID. >>>>>=20 >>>>> I recommend others read it as well so we can understand if there = are any real issues. >>>>>=20 >>>>> Regards >>>>> John B. >>>>>=20 >>>>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>> Hey John, >>>>>>=20 >>>>>> I think you're missing the bigger point here, which is: In order = to allow for multiple recipients, Matt had to break JWE. >>>>>>=20 >>>>>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>>>=20 >>>>>>> Hi Matt, >>>>>>>=20 >>>>>>> Complements on updating the draft. >>>>>>>=20 >>>>>>> The issue I see is that you are attempting to distribute the CMK = out of band and use "none" as the alg. >>>>>>>=20 >>>>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>>>=20 >>>>>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>>>>> =46rom a implementation point of view the symmetric cypher = always gets the CEK derived from the CMK in the message independent of = if it is using RSA or A128KW/A256KW. >>>>>>>=20 >>>>>>> That imposes some extra steps for people using symmetric keys = but encourages rotation of the CEK that would likely not happen = otherwise. >>>>>>>=20 >>>>>>> So in your spec I would expect you to distribute a shared secret = via keyreq for use in A256KW and be using that decrypt the CMK at the = receiver. >>>>>>>=20 >>>>>>> I also suspect that you intended to use A256GCM as the enc alg = and not A256CCM.=20 >>>>>>>=20 >>>>>>> I am not a XMPP expert so it will take me some time to go over = it in detail. I would like to understand the use case to be certain it = is properly supported. >>>>>>>=20 >>>>>>> Regards >>>>>>> John B. >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>>>>=20 >>>>>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been = updated to the latest JOSE WG drafts. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> - m&m >>>>>>>>=20 >>>>>>>> Matt Miller - >>>>>>>> Cisco Systems, Inc. >>>>>>>>=20 >>>>>>>> Begin forwarded message: >>>>>>>>=20 >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>>>>> Author(s) : Matthew Miller >>>>>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>>>>> Pages : 22 >>>>>>>>> Date : 2012-06-21 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> This document defines a method of end-to-end object encryption = for >>>>>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>>>>=20 >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>>>>=20 >>>>>>>>> A diff from previous version is available at: >>>>>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> I-D-Announce mailing list >>>>>>>>> I-D-Announce@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From rbarnes@bbn.com Tue Jun 26 12:33:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9196421F8599 for ; Tue, 26 Jun 2012 12:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKaeda8gTXoH for ; Tue, 26 Jun 2012 12:33:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 968F321F8595 for ; Tue, 26 Jun 2012 12:33:35 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:60156) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjbW2-0006Oq-7i; Tue, 26 Jun 2012 15:33:34 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> Date: Tue, 26 Jun 2012 15:33:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Jim Schaad , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 19:33:38 -0000 > There was a WG decision to not allow encryption without integrity. = Jim and others call that sender verification. >=20 > Or on simple terms no AES-CBC without a mandatory MAC integrity. Thanks. I remembered the "AEAD-only" agreement, but didn't know the = "sender verification" term. =20 > The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. >=20 > We do have s JWT spec that covers the body for security tokens. The = idea was to separate that from signing and encryption so that signing = and encryption can be used for other objects. >=20 > John B. That's exactly my point. You can have something like JWT specify a body = format that has the protected parameters, so why does JWS/JWE need = integrity-protected attributes? --Richard > On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >=20 >>> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >>> In those cases one can easily argue that the header should be = protected as much as in HMAC. >>=20 >> Can you clarify the scope of "we are mandating"? >>=20 >>=20 >>> There may well be signing_time or other elements that would go into = the header as well for JWE. >>=20 >> Why do these need to go into the header rather than the body? >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>> Regards >>> John B. >>>=20 >>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>=20 >>>> >>>>=20 >>>> Richard, >>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>>> Richard L. Barnes >>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>> To: Nat Sakimura >>>>> Cc: Mike Jones; jose@ietf.org >>>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >>>>> 00.txt >>>>>=20 >>>>> Hi Nat, >>>>>=20 >>>>> I'm not sure what X.509 fiasco you're referring to. There was a = recent >>>> MD5 >>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, = there have >>>> been >>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. As >>>> was >>>>> noted on the SAAG list, the real news here is that Microsoft = wasn't >>>> following >>>>> any of those recommendations. >>>>>=20 >>>>> JWS would have had the same problem as X.509. The attack did not = modify >>>>> the cryptographic parameters (anything that would have gone in the >>>>> header), it would not have been thwarted by the integrity = protection we're >>>>> worrying about. >>>>>=20 >>>>> Actually, the header signing that JWS does makes it even nicer for = the >>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS = header >>>> value >>>>> is entirely static for a given signer, it's easy to use as a fixed = prefix. >>>> If JWS just >>>>> signed the content, then the application could include a something = random >>>>> up front to prevent such prefix-based attacks. >>>>>=20 >>>>=20 >>>> I don't believe that this is a true statement. If you had a prefix = or just >>>> signed what was given to you (i.e. no prefix), it would make no = difference >>>> in terms of the attack for Flame. Flame could always use a fixed = prefix of >>>> its own design rather than using the fixed header that is generated = by >>>> having JWS sign the header information. >>>>=20 >>>>> It's tempting to say that we should just add randomness to the = JOSE >>>> format. >>>>> But the real lesson of the Flame/MD5 attacks is operational: If = you're >>>> signing >>>>> something that somebody else gave you, make sure that you're not = signing >>>>> exactly what they gave you. Follow the recommendations of RFC = 4270. In >>>>> other contexts, there's no need of similar random elements; it = just adds >>>>> complexity. >>>>=20 >>>> This is definitely a true statement in all events and is something = that >>>> should be added to the Security Considerations section. >>>>=20 >>>> That being said, I think that there are valid reasons for wanting = to protect >>>> the header information by some authentication processing. PKIX = certificates >>>> protect the signature algorithm information (by copying the data = into the to >>>> be signed block) and CMS has long allowed for information to be = included in >>>> the signed attributes area that identifies the algorithms used, the >>>> certificates used and so forth. There are also other things that = we might >>>> find to be convenient to be placed in the header information that = is current >>>> not there (a signing time and embedded content type comes to mind) = that >>>> would be a product either of specific types of signatures or = becomes a >>>> common attribute to be placed there. >>>>=20 >>>> In terms of encryption operations, I remember in the past that I = have had >>>> either corrupted encrypted streams or corrupted IVs and had a = successful >>>> decryption that later generated other problems when trying to = parse. This >>>> is less of an issue with AEAD algorithms as they have a much = stricter rule >>>> on when the stream decrypts correctly. >>>>=20 >>>> Jim >>>>=20 >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> [1] >>>>> [2] >>>>>=20 >>>>>=20 >>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>=20 >>>>>> Especially after the X.509 fiasco, I strongly believe that having >>>> integrity >>>>> check over the metadata is a good thing. It is such a little = effort that >>>> gives us >>>>> much more protection down the road. In this sense, I fully agree = with Ben >>>>> here. We should have integrity protection over the header. >>>>>>=20 >>>>>> Nat >>>>>>=20 >>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>> wrote: >>>>>> Two years ago when the developer community needing a = JSON-friendly >>>>> token format was designing the JSON Web Token (JWT), we explicitly = asked >>>>> security experts whether the header parameters should be integrity >>>>> protected or not. Among them, Ben Laurie was one of the voices = saying >>>> that >>>>> securing them was the right thing to do. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> He argued that if the parameters can be protected in a practical = manner, >>>>> then they should. Doing so provides an additional hurdle that = attackers >>>>> would have to surmount. For example, if they can try to = substitute a >>>> weaker >>>>> authentication scheme, then they must figure out how to make it >>>>> authenticate correctly despite some plaintext they can't control - = the >>>> header >>>>> parameters. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Ben also took the position that paring security protocols down to = the >>>> least >>>>> you can get away with, given attacks you can think of, is not a = good >>>> design >>>>> principle. If there is not a strong argument against including a = feature >>>> that >>>>> may make it harder for attackers, then that feature should be = included. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I agree with him. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The decision to provide integrity protection for the headers is >>>> documented >>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> . What to sign (envelope.payload or just payload)? >>>>>>=20 >>>>>> Given that the envelope is extensible and therefore may contain >>>> security- >>>>> sensitive information, we reached a consensus (with input from Ben = Laurie >>>>> via IM) that the combination envelope.payload must be signed. >>>>>>=20 >>>>>>=20 >>>>>> I believe that logic is as sound today as it was then. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> For all these reasons, I therefore personally stand by the = community's >>>>> decision to provide integrity protection for the headers. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best = wishes, >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>>> John Bradley >>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>> To: Richard L.Barnes >>>>>> Cc: jose@ietf.org >>>>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >>>>> 00.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi Richard, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding = and not >>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>=20 >>>>>> There are possible hash truncation attacks by shortening SHA256 = to >>>> SHA224 >>>>> as an example (I know we preclude truncated hashes at the moment). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The bad feeling I get around this is that if there is a scenario = where >>>> the >>>>> attacker controls the plaintext to be signed and there is no = signer >>>> controlled >>>>> text contributed there are potential bad things that could happen = down the >>>>> road. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This bit us with x509 certs not that long ago (yes with MD5 = admittedly) >>>>> where the attacker could use a certificate extension to include = extra data >>>> and >>>>> cause a pre collided hash to be generated. >>>>>>=20 >>>>>> Having part of the signed data outside the control of an attacker = is a >>>> good >>>>> thing. (having a nonce or message ID in the envelope is possible = though >>>> not >>>>> yet required in JWS.) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I am still of the opinion that putting the base64 encoded = envelope >>>> inside >>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>=20 >>>>>> Another structure to hold the attributes adds more complexity, = as would >>>>> saying that they need to be inside the signed object. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I think part of this is that as one of the openID Connect authors = I look >>>> at this >>>>> as a necessary security token format, for OAuth and Connect. >>>>>>=20 >>>>>> For that simple processing with one signature is a high priority = for >>>> adoption. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =46rom a general signing/encrypting of documents point of view = you >>>>> legitimately have different priorities. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I know it is hard to prove a negative but It is also going to be >>>> difficult for me >>>>> to go back to security people at google Facebook and other places = and >>>>> explain how not integrity protecting the header could be better = than >>>>> integrity protecting it. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> It seems that I would be reduced to arguing that this is no worse = than >>>> CMS >>>>> and that hasn't been proven insecure yet. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Allowing a possible attacker to control the hash output, and not >>>> integrity >>>>> protecting the additional data, seems like something I am bound to = regret >>>> in >>>>> the future. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Hey John, >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Interesting points, but I don't think they actually apply here. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to downgrade attacks: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> The attack that RFC 5752 is concerned with is when an attacker = strips >>>>> signatures from a signed message, so that the only ones left are = ones he >>>> can >>>>> tamper with. So the integrity protection here is "horizontal"; it = goes >>>> across >>>>> signatures. The integrity protection in JWS/JWE is "vertical" -- = it only >>>> protects >>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "brown bag" attacks: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> The root of this attack is ambiguity about what content is = *signed* >>>>>>=20 >>>>>>> vs. what content is *used*. If an application doesn't verify = that >>>>>>=20 >>>>>>> it's actually using the stuff that's signed, then it can be = tricked >>>>>>=20 >>>>>>> into accepting something unsigned. (Cf. >>>>>>=20 >>>>>>> ) >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> However, I don't think any of the current proposals have that = problem. >>>>> In JWE/JWS, the signed content is right there between the dots, = and in >>>> JSMS, >>>>> it's in the "content" element. The current JSMS draft does allow = detached >>>>> signatures, but with a "voids your warranty" sticker on it. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> In any case, these attacks have nothing to do with whether the >>>>> cryptographic parameters are integrity-protected with the content. = The >>>>> example attacks in the IBM still work regardless -- the whole = point of the >>>>> attack is that the cryptographic processing is the same, only the >>>> (non-crypto) >>>>> matching of content is flawed. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "arbitrary attributes": >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> We can have that here, too, but you need canonicalization. And >>>> base64- >>>>> encoding is not not canonicalization -- it just waves its hands = over the >>>>> question of equivalence. In my opinion, we should keep the = cryptographic >>>>> object simple by disallowing attributes, and push the attributes = you would >>>>> sign inside of the thing being signed. If people really do want >>>> attributes, it >>>>> doesn't seem to me like JSON canonicalization is very hard. I can = do it >>>> in 19 >>>>> lines of python: >>>>>>=20 >>>>>>> >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard too "meta-data in the body": >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> It seems to me like if we're trying to define a general format = for >>>> applying >>>>> security protections, then we ought to keep out things that aren't >>>> strictly >>>>> security relevant. Those things can go in application-specific = content >>>> types >>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "defense in depth" and selling this to government >>>>> agencies: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> CMS, via S/MIME, is in broad use across multiple federal = agencies and >>>>> large enterprises. JSMS is essentially a profile of CMS (see = Section 7), >>>> and >>>>> has the same security properties. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Cheers, >>>>>>=20 >>>>>>> --Richard >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>> Hi Richard, >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Originally we only integrity protected the header for signing. = We >>>> added >>>>> the integrity protection to encryption as part of AEAD, as = encryption can >>>> also >>>>> be used for sender verification. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I understand the argument that it makes things simpler if we = don't >>>>> integrity protect the header information. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> However xmldsig, provides integrity over those elements to = prevent >>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> CMS may not typically provide that integrity protection but I = think >>>> Jim >>>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>>=20 >>>>>>>> Given they are on this list they can speak to their view on = integrity >>>> over >>>>> the crypto parameters. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I also recall when working on InfoCards there was a Monte = Carlo/Brown >>>>> Bag attack that needs to be considered if we move to something = more like a >>>>> detached signature. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> The other design consideration is that we wanted to be able to = sign >>>>> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>>>>=20 >>>>>>>> That prevented us from including meta-data in the body as we = didn't >>>>> want to touch it. That left us with the header to include = additional >>>> elements >>>>> in. >>>>>>=20 >>>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>> arbitrary >>>>> attributes not unlike the current JOSE spec. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Especially for something that will be used with JWT security = tokens I >>>> will >>>>> have a hard time making the argument to NIST and others that need = to >>>>> approve this format that not integrity protecting the header = parameters is >>>>> appropriate defence in depth, for something that might be = replacing signed >>>>> SAML assertions in some applications. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I do understand how not integrity protecting the header will = make >>>> some >>>>> things easier, however I can't agree that the benefit outweighs = the >>>>> disadvantages. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Regards >>>>>>=20 >>>>>>>> John B. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>>> Hey Mike, >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Thanks for having some back-and-forth with me on this. I = think this >>>> is a >>>>> good discussion to have right now. I would like to discuss some >>>> high-level >>>>> points, and then I'll respond inline to your precise points. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to = define >>>> JSON- >>>>> based formats for integrity and confidentiality protections. JWE = and JWS >>>>> don't fit that requirement, so we should re-consider their = adoption and >>>> call >>>>> for new candidates. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Major points: >>>>>>=20 >>>>>>>>> 1. JOSE is JSON >>>>>>=20 >>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>=20 >>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 1: JOSE is JSON >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> The JOSE WG charter calls out four deliverables, three of = which are >>>>> explicitly required to be JSON: >>>>>>=20 >>>>>>>>> -- "JSON-structured integrity protection" >>>>>>=20 >>>>>>>>> -- "JSON-structured encryption" >>>>>>=20 >>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>=20 >>>>>>>>> (The fourth is just a list of algorithms, which should be JSON = as >>>>>>=20 >>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> In light of these requirements, JWE and JWS are clearly not = suitable >>>>>>=20 >>>>>>>>> candidates to fulfill the working group's milestones. (At = least in >>>>>>=20 >>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>=20 >>>>>>>>> re-evaluate alternatives for the three above milestones, = especially >>>>>>=20 >>>>>>>>> the first two. (JWK is not as far off.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization" = drafts >>>>> are pretty half-hearted. Because JWS and JWE include the = cryptographic >>>>> parameters within the integrity protection, they have to have the = headers >>>>> included as base64-encoded strings. That obviously adds a lot of >>>> complexity >>>>> to encoding and decoding -- for example, you have to keep the = encoded >>>>> header around even after you've decoded it! -- and just plain more = octets. >>>>> The support for multiple recipients and multiple signatures is = both >>>> unweildy >>>>> (matching up parallel indices for headers and signatures) and = inefficient >>>>> (multiple integrity check values in encrypted objects). >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom = that >>>>> went into CMS, while making the syntax pure JSON and as simple as >>>> possible. >>>>> Multiple signatures and multiple recipients are supported with = absolute >>>>> minimum overhead. So I think it's worth consideration by the = working >>>> group. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I would like to dispel the myth that a JSON-based format = requires >>>>>>=20 >>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>=20 >>>>>>>>> "canonicalization" (via base64url encoding) because it's = included >>>>>>=20 >>>>>>>>> within the integrity protection. I'm not aware of any reason = for >>>>>>=20 >>>>>>>>> including the cryptographic parameters in the integrity check, >>>>>>=20 >>>>>>>>> instead of only integrity-protecting the content itself. = Indeed, if >>>>>>=20 >>>>>>>>> there were an attack based on non-integrity-protected = cryptographic >>>>>>=20 >>>>>>>>> parameters, it would be a pretty big deal, since neither CMS = nor IKE >>>>>>=20 >>>>>>>>> nor provides this protection. (TLS does provide a signature = over >>>>>>=20 >>>>>>>>> the algorithms, but only as a way to bind the public key to = the >>>>>>=20 >>>>>>>>> session.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Indeed CMS doesn't require canonicalization at all, except for >>>>> attributes that are included in the protected content (signedAttrs = / >>>>> authenticatedAttrs), which need to be DER-encoded. In JSMS, we = don't >>>>> allow those parameters, so there is no need for canonicalization = at all. >>>> All the >>>>> "canonicalization" that's needed is to base64url-encode the = protected >>>>> content. In that regard, JSMS is even simpler than JWE/JWS. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as = derivatives >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I have absolutely no objection to defining a compact, URL-safe >>>> format. >>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the = example >>>> from >>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> { >>>>>>=20 >>>>>>>>> "v":1, >>>>>>=20 >>>>>>>>> "t":"au", >>>>>>=20 >>>>>>>>> "a":"hs256", >>>>>>=20 >>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>=20 >>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>=20 >>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>=20 >>>>>>>>> } >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> If we remove the decorative spaces and base64url-encode, we = only >>>>> use >>>>>>=20 >>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>>>>=20 >>>>>>>>> further and define an explicit compact format for = AuthenticatedData, >>>>>>=20 >>>>>>>>> we can emulate JWS by moving the content and MAC fields = outside >>>>> and >>>>>>=20 >>>>>>>>> dot-combining. That avoids double-base64url-encoding, and = only >>>>>>=20 >>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put = the code >>>>>>=20 >>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> So it's fine to have a compact, URL-safe format for an = objective, >>>> but it >>>>> makes *much* more sense to derive that from a full-size, usable, = JSON >>>>> format than the other way around. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Responses to specific points inline below. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before = doing >>>> so, I'll >>>>> say that I'm writing in the spirit of trying to increase mutual >>>> understanding >>>>> and consensus, rather than taking the point of view that the = status quo is >>>> the >>>>> only reasonable outcome. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Not being JSON >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> This was by design, so that the results are URL-safe. This = is >>>> required, >>>>> for instance, for them to be used as OAuth Bearer Tokens. At the = request >>>> of >>>>> the working group, closely related pure-JSON drafts were also = published. >>>>> See: >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-seri >>>>>>=20 >>>>>>>>>> alization-01 and >>>>>>=20 >>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser >>>>>>=20 >>>>>>>>>> ialization-01 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Use them if you prefer if they better suit your use cases. = They >>>> could >>>>> be adopted as working group documents, if there's interest. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> See above. These are super-clunky, and the need to be the = main >>>>> focus of the WG, not an afterthought. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Not supporting multiple recipients >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> The JSON serialization drafts above do, again, in response to = use >>>>> cases presented by the working group. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> See above. Because of the unnecessary inclusion of the header = in >>>> the >>>>> integrity check, this is far less efficient than it should be. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Functionally, these are very similar operations, at least = from an >>>>> implementation perspective, so it's not clear that making a clear >>>> distinction >>>>> would help either developers or adoption in any practical way. = They >>>> achieve >>>>> overlapping, but admittedly sometimes different goals. I believe = that >>>>> developers can be trusted to use the algorithms that achieve their >>>>> applications' goals without making a hard distinction between the = two. >>>> But >>>>> I'd be interested in hearing your thoughts on why you believe a >>>> brighter-line >>>>> distinction might be useful or necessary. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> It's important if you want to do MACs with anything other than = pre- >>>>> shared keys. If you want to do anything more advanced, you need = to have >>>>> wrapped keys, in which case an object with a MAC starts to look a = lot more >>>>> like a JWE than a JWS. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>=20 >>>>>>>>>> establishment modalities >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> This seems like an area where the existing drafts could be = refined >>>> to >>>>> add descriptions for additional establishment modalities, possibly = based >>>>> upon your ideas and descriptions, should the working group decide = to do >>>> so. >>>>> What additional modalities do you have use cases for that you = believe are >>>>> not achievable or straightforward with the existing drafts? The = existing >>>>> modalities supported are largely those that existing developers = had told >>>> us >>>>> they needed and draw both from the precursor = draft-jones-json-web-* >>>>> documents and draft-rescorla-jsms. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Bear in mind that the balance that the current drafts try to = strike >>>> is >>>>> keeping the Mandatory to Implement (MTI) feature footprint small = enough >>>>> that developers, including Web developers, are likely to adopt the = specs, >>>>> while still providing enough functionality to make them generally = useful. >>>> As >>>>> in any balance, it's often possible to shift things a bit and = still >>>> maintain the >>>>> balance, but I'd like people to keep the ubiquitous adoption goal >>>> front-and- >>>>> center when proposing additional functionality. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>=20 >>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>>>>=20 >>>>>>>>>> that!) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I agree that we need to find a reasonable MTI. The current = JSMS >>>> draft >>>>> doesn't really specify which parts are MTI, beyond basic things = like >>>> base64url >>>>> encoding and ignoring unknown fields. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> My main concern is that JWS and JWE don't really tell me which >>>> fields >>>>> need to be present for which use case. If I'm putting a MAC on a = JWS vs. >>>> a >>>>> signature, do I need "jwk" or "jku" fields to be populated? = Whereas in >>>> JSMS, >>>>> I think these things are much clearer due to the separation of the = use >>>> cases >>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures = and >>>>> wrapped keys into sub-objects. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lack of clear typing of objects >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Most JSON documents aren't clearly typed; instead, developers = and >>>>> implementations understand from context what the meaning of each = field is. >>>>> XML is clearly typed, but developers are voting with their feet by = moving >>>> to >>>>> JSON. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> What practical advantages resulting from overlaying a typing >>>>> infrastructure on JSON do you believe are worth the potential = costs of >>>> doing >>>>> so? BTW, I'm not opposed to having a JSON schema description of = the JOSE >>>>> JSON data structures like JSMS did in = http://tools.ietf.org/html/draft- >>>>> rescorla-jsms-00#appendix-A, but I'll remark that this an = informative >>>> tool, not >>>>> a normative one. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I actualy don't have a hugely urgent requirement here either. = It's >>>>> something that others in the WG had requested, which is trivial to = add in >>>>> JSMS, but not in JWE/JWS -- again because of the unnecessary = integrity >>>>> protection of the header. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> An optional version field could be added if the working group >>>>>>=20 >>>>>>>>>> desires, however the last time the working group discussed = it, they >>>>>>=20 >>>>>>>>>> decided not to do so. Rather, specs like this effectively = become >>>>>>=20 >>>>>>>>>> "versioned" when revised in a way that new fields are added. = If >>>>>>=20 >>>>>>>>>> you understand the new fields, you support that new version. = (Note >>>>>>=20 >>>>>>>>>> that this is independent of whether there is a version number >>>>>>=20 >>>>>>>>>> field, which according to some participants in the previous >>>>>>=20 >>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>=20 >>>>>>>>>> information.) >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> I'm not religious about not having a version number field, = but >>>> often >>>>> "less is more". >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Indeed, I'm not religious either. It just seems like a = general good >>>> idea >>>>> to state this directly as opposed to having parsers divine it = based on >>>> which >>>>> fields are present. To quote RFC 5652: >>>>>>=20 >>>>>>>>> " >>>>>>=20 >>>>>>>>> Each of the major data structures includes a version number as = the >>>>>>=20 >>>>>>>>> first item in the data structure. The version numbers are = intended >>>>>>=20 >>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not = check >>>>> the >>>>>>=20 >>>>>>>>> version number prior to attempting a decode, and if a decode = error >>>>>>=20 >>>>>>>>> occurs, then the version number is checked as part of the = error >>>>>>=20 >>>>>>>>> handling routine. This is a reasonable approach; it places = error >>>>>>=20 >>>>>>>>> processing outside of the fast path. This approach is also >>>>>>=20 >>>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>>=20 >>>>>>>>> " >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Best, >>>>>>=20 >>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Best wishes, >>>>>>=20 >>>>>>>>>> -- Mike >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>=20 >>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>=20 >>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>=20 >>>>>>>>>> To: Mike Jones >>>>>>=20 >>>>>>>>>> Cc: jose@ietf.org >>>>>>=20 >>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>=20 >>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. = IMO, >>>> the >>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>=20 >>>>>>>>>> -- Not being JSON >>>>>>=20 >>>>>>>>>> -- Not supporting multiple recipients >>>>>>=20 >>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>=20 >>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>=20 >>>>>>>>>> establishment modalities >>>>>>=20 >>>>>>>>>> -- Lack of clear typing of objects >>>>>>=20 >>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Looking at the current specs, it didn't seem to me that it = would be >>>>> simple to adapt them to address these deficiencies. So I just did = a >>>> re-write. >>>>> If you think they can be addressed within the current framework, = please >>>>> explain. I just found it simpler to start from whole cloth. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Cheers, >>>>>>=20 >>>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Hi Richard, >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>>> documents, >>>>> I encourage you to ask about them on the list. The documents have >>>>> significant history going back to mid-2010 when convergence = discussions >>>>> started among people with four different JSON signing & encryption >>>>> proposals. JWT and the current JOSE specs and implementations are = the >>>>> result. I realize that not all the JOSE participants were part of = those >>>>> discussions from the beginning (although many were) and so teasing = out the >>>>> rationale for specific decisions might help people better = understand the >>>>> choices made, and hopefully thereby increase consensus behind the >>>>> eventual working group choices. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> If the list that you're puzzled by is the bulleted list = below, >>>> maybe we >>>>> can start a discussion on that basis. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Best wishes, >>>>>>=20 >>>>>>>>>>> -- Mike >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>=20 >>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On >>>>>>=20 >>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>=20 >>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>=20 >>>>>>>>>>> To: jose@ietf.org >>>>>>=20 >>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>=20 >>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Dear JOSE WG, >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a = thorough >>>>> review of the JW* specs, I was kind of puzzled by some of the = design >>>>> decisions. So I also went through and wrote an alternative = format, this >>>> time >>>>> taking a more of a cue from CMS. A link to the document is below. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Summary of differences: >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>>>=20 >>>>>>>>>>> parameters are represented in JSON. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS allows for full algorithm agility in key agreement, = while >>>> JWE >>>>>>=20 >>>>>>>>>>> only allows ECDH-ES. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>>=20 >>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>> WrappedKey >>>>>>=20 >>>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>>>=20 >>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o The signature and MAC functions of the JWS object are = separated >>>>>>=20 >>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS parameters are not integrity-protected, as they are = in JWE >>>>>>=20 >>>>>>>>>>> and JWS. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, = but >>>> could >>>>>>=20 >>>>>>>>>>> be added without significant change. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>>>=20 >>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> I've also thrown together an initial JavaScript = implementation >>>> (based >>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>=20 >>>>>>>>>>> >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Comments are very welcome. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>=20 >>>>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Begin forwarded message: >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>=20 >>>>>>>>>>>> Subject: New Version Notification for >>>>>>=20 >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>=20 >>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has = been >>>>>>=20 >>>>>>>>>>>> successfully submitted by Richard Barnes and posted to the = IETF >>>>>>=20 >>>>>>>>>>>> repository. >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>=20 >>>>>>>>>>>> Revision: 00 >>>>>>=20 >>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>=20 >>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>=20 >>>>>>>>>>>> WG ID: Individual Submission >>>>>>=20 >>>>>>>>>>>> Number of pages: 25 >>>>>>=20 >>>>>>>>>>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>> jsms-00.txt >>>>>>=20 >>>>>>>>>>>> Status: >>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>=20 >>>>>>>>>>>> Htmlized: >>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> Abstract: >>>>>>=20 >>>>>>>>>>>> Many applications require the ability to send = cryptographically >>>>>>=20 >>>>>>>>>>>> secured messages. While the IETF has defined a number of >>>>> formats >>>>>>=20 >>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings = which >>>>>>=20 >>>>>>>>>>>> are not easy to use in modern applications. This document >>>>>>=20 >>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a = new >>>>>>=20 >>>>>>>>>>>> cryptographic message format which is based on JavaScript = Object >>>>>>=20 >>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>>> generate >>>>> and parse. >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> The IETF Secretariat >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 From tonynad@microsoft.com Tue Jun 26 13:30: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 0B01811E80D5 for ; Tue, 26 Jun 2012 13:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eep9Q6WNSLPy for ; Tue, 26 Jun 2012 13:30:44 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2EF11E80CC for ; Tue, 26 Jun 2012 13:30:43 -0700 (PDT) Received: from mail111-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 20:29:01 +0000 Received: from mail111-db3 (localhost [127.0.0.1]) by mail111-db3-R.bigfish.com (Postfix) with ESMTP id B0339380145 for ; Tue, 26 Jun 2012 20:29:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zz98dI9371I936eI168aJ148cI542M1432I1418I41c5N4015Izz1202h1082kzz1033IL8275eh8275bh8275dh5eeeKf73b6ila1495iz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail111-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail111-db3 (localhost.localdomain [127.0.0.1]) by mail111-db3 (MessageSwitch) id 1340742538227534_12171; Tue, 26 Jun 2012 20:28:58 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.247]) by mail111-db3.bigfish.com (Postfix) with ESMTP id 35284340129 for ; Tue, 26 Jun 2012 20:28:58 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 20:28:57 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 26 Jun 2012 20:30:25 +0000 Received: from mail137-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 20:28:43 +0000 Received: from mail137-va3 (localhost [127.0.0.1]) by mail137-va3-R.bigfish.com (Postfix) with ESMTP id 3FF964C00BB for ; Tue, 26 Jun 2012 20:28:43 +0000 (UTC) Received: from mail137-va3 (localhost.localdomain [127.0.0.1]) by mail137-va3 (MessageSwitch) id 1340742520525859_20639; Tue, 26 Jun 2012 20:28:40 +0000 (UTC) Received: from VA3EHSMHS044.bigfish.com (unknown [10.7.14.243]) by mail137-va3.bigfish.com (Postfix) with ESMTP id 7BC293E0047; Tue, 26 Jun 2012 20:28:40 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS044.bigfish.com (10.7.99.54) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 20:28:40 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0164.004; Tue, 26 Jun 2012 20:30:21 +0000 From: Anthony Nadalin To: John Bradley , "Richard L. Barnes" Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: AQHNUy1ZdN25RV0AW0G+qJH9ZfeyWpcLttCAgAEpKgCAAB3dgIAAD7xA Date: Tue, 26 Jun 2012 20:30:21 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> In-Reply-To: <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%BBN.COM$RO%2$TLS%6$FQDN%131.107.125.5$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: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 20:30:47 -0000 Not sure there was a WG decision and what that would mean if there was, as = there are many libraries out there that don't support the encryption with i= ntegrity algorithms, so need to support alternative means of things like ke= y wrap that could have an integrity check. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Joh= n Bradley Sent: Tuesday, June 26, 2012 12:30 PM To: Richard L. Barnes Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt There was a WG decision to not allow encryption without integrity. Jim an= d others call that sender verification. Or on simple terms no AES-CBC without a mandatory MAC integrity. The JWE/JWS specs don't control the body. That is intended to be arbitrar= y content. We do have s JWT spec that covers the body for security tokens. The idea = was to separate that from signing and encryption so that signing and encryp= tion can be used for other objects. John B. On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >> Now that we are mandating JWE sender verification people will be using J= WE with symmetric keys or key agreement. >> In those cases one can easily argue that the header should be protected = as much as in HMAC. >=20 > Can you clarify the scope of "we are mandating"? >=20 >=20 >> There may well be signing_time or other elements that would go into the = header as well for JWE. >=20 > Why do these need to go into the header rather than the body? >=20 > --Richard >=20 >=20 >=20 >=20 >> Regards >> John B. >>=20 >> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>=20 >>> >>>=20 >>> Richard, >>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>> Behalf Of Richard L. Barnes >>>> Sent: Monday, June 25, 2012 2:35 PM >>>> To: Nat Sakimura >>>> Cc: Mike Jones; jose@ietf.org >>>> Subject: Re: [jose] New Version Notification for=20 >>>> draft-barnes-jose-jsms- 00.txt >>>>=20 >>>> Hi Nat, >>>>=20 >>>> I'm not sure what X.509 fiasco you're referring to. There was a=20 >>>> recent >>> MD5 >>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, there=20 >>>> have >>> been >>>> recommendations for preventing this attack in X.509 since 2005 [2]. =20 >>>> As >>> was >>>> noted on the SAAG list, the real news here is that Microsoft wasn't >>> following >>>> any of those recommendations. >>>>=20 >>>> JWS would have had the same problem as X.509. The attack did not=20 >>>> modify the cryptographic parameters (anything that would have gone=20 >>>> in the header), it would not have been thwarted by the integrity=20 >>>> protection we're worrying about. >>>>=20 >>>> Actually, the header signing that JWS does makes it even nicer for=20 >>>> the >>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20 >>>> header >>> value >>>> is entirely static for a given signer, it's easy to use as a fixed pre= fix. >>> If JWS just >>>> signed the content, then the application could include a something=20 >>>> random up front to prevent such prefix-based attacks. >>>>=20 >>>=20 >>> I don't believe that this is a true statement. If you had a prefix=20 >>> or just signed what was given to you (i.e. no prefix), it would make=20 >>> no difference in terms of the attack for Flame. Flame could always=20 >>> use a fixed prefix of its own design rather than using the fixed=20 >>> header that is generated by having JWS sign the header information. >>>=20 >>>> It's tempting to say that we should just add randomness to the JOSE >>> format. >>>> But the real lesson of the Flame/MD5 attacks is operational: If=20 >>>> you're >>> signing >>>> something that somebody else gave you, make sure that you're not=20 >>>> signing exactly what they gave you. Follow the recommendations of=20 >>>> RFC 4270. In other contexts, there's no need of similar random=20 >>>> elements; it just adds complexity. >>>=20 >>> This is definitely a true statement in all events and is something=20 >>> that should be added to the Security Considerations section. >>>=20 >>> That being said, I think that there are valid reasons for wanting to=20 >>> protect the header information by some authentication processing. =20 >>> PKIX certificates protect the signature algorithm information (by=20 >>> copying the data into the to be signed block) and CMS has long=20 >>> allowed for information to be included in the signed attributes area=20 >>> that identifies the algorithms used, the certificates used and so=20 >>> forth. There are also other things that we might find to be=20 >>> convenient to be placed in the header information that is current=20 >>> not there (a signing time and embedded content type comes to mind)=20 >>> that would be a product either of specific types of signatures or becom= es a common attribute to be placed there. >>>=20 >>> In terms of encryption operations, I remember in the past that I=20 >>> have had either corrupted encrypted streams or corrupted IVs and had=20 >>> a successful decryption that later generated other problems when=20 >>> trying to parse. This is less of an issue with AEAD algorithms as=20 >>> they have a much stricter rule on when the stream decrypts correctly. >>>=20 >>> Jim >>>=20 >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> [1] >>>> [2] >>>>=20 >>>>=20 >>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>=20 >>>>> Especially after the X.509 fiasco, I strongly believe that having >>> integrity >>>> check over the metadata is a good thing. It is such a little effort=20 >>>> that >>> gives us >>>> much more protection down the road. In this sense, I fully agree=20 >>>> with Ben here. We should have integrity protection over the header. >>>>>=20 >>>>> Nat >>>>>=20 >>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>> wrote: >>>>> Two years ago when the developer community needing a JSON-friendly >>>> token format was designing the JSON Web Token (JWT), we explicitly=20 >>>> asked security experts whether the header parameters should be=20 >>>> integrity protected or not. Among them, Ben Laurie was one of the=20 >>>> voices saying >>> that >>>> securing them was the right thing to do. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> He argued that if the parameters can be protected in a practical=20 >>>>> manner, >>>> then they should. Doing so provides an additional hurdle that=20 >>>> attackers would have to surmount. For example, if they can try to=20 >>>> substitute a >>> weaker >>>> authentication scheme, then they must figure out how to make it=20 >>>> authenticate correctly despite some plaintext they can't control -=20 >>>> the >>> header >>>> parameters. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Ben also took the position that paring security protocols down to=20 >>>>> the >>> least >>>> you can get away with, given attacks you can think of, is not a=20 >>>> good >>> design >>>> principle. If there is not a strong argument against including a=20 >>>> feature >>> that >>>> may make it harder for attackers, then that feature should be included= . >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I agree with him. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The decision to provide integrity protection for the headers is >>> documented >>>> in the session notes at http://self-issued.info/?p=3D361, which said: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> . What to sign (envelope.payload or just payload)? >>>>>=20 >>>>> Given that the envelope is extensible and therefore may contain >>> security- >>>> sensitive information, we reached a consensus (with input from Ben=20 >>>> Laurie via IM) that the combination envelope.payload must be signed. >>>>>=20 >>>>>=20 >>>>> I believe that logic is as sound today as it was then. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> For all these reasons, I therefore personally stand by the=20 >>>>> community's >>>> decision to provide integrity protection for the headers. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Best=20 >>>>> wishes, >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>> Behalf Of >>>> John Bradley >>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>> To: Richard L.Barnes >>>>> Cc: jose@ietf.org >>>>> Subject: Re: [jose] New Version Notification for=20 >>>>> draft-barnes-jose-jsms- >>>> 00.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Hi Richard, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> While for PKCS 1.5 the hash algorithm is baked into the padding=20 >>>>> and not >>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>=20 >>>>> There are possible hash truncation attacks by shortening SHA256 to >>> SHA224 >>>> as an example (I know we preclude truncated hashes at the moment). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The bad feeling I get around this is that if there is a scenario=20 >>>>> where >>> the >>>> attacker controls the plaintext to be signed and there is no signer >>> controlled >>>> text contributed there are potential bad things that could happen=20 >>>> down the road. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This bit us with x509 certs not that long ago (yes with MD5=20 >>>>> admittedly) >>>> where the attacker could use a certificate extension to include=20 >>>> extra data >>> and >>>> cause a pre collided hash to be generated. >>>>>=20 >>>>> Having part of the signed data outside the control of an attacker=20 >>>>> is a >>> good >>>> thing. (having a nonce or message ID in the envelope is possible=20 >>>> though >>> not >>>> yet required in JWS.) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I am still of the opinion that putting the base64 encoded envelope >>> inside >>>> the hash calculation is a valid way to allow additional attributes. >>>>>=20 >>>>> Another structure to hold the attributes adds more complexity, as=20 >>>>> would >>>> saying that they need to be inside the signed object. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I think part of this is that as one of the openID Connect authors=20 >>>>> I look >>> at this >>>> as a necessary security token format, for OAuth and Connect. >>>>>=20 >>>>> For that simple processing with one signature is a high priority=20 >>>>> for >>> adoption. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From a general signing/encrypting of documents point of view you >>>> legitimately have different priorities. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I know it is hard to prove a negative but It is also going to be >>> difficult for me >>>> to go back to security people at google Facebook and other places=20 >>>> and explain how not integrity protecting the header could be better=20 >>>> than integrity protecting it. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> It seems that I would be reduced to arguing that this is no worse=20 >>>>> than >>> CMS >>>> and that hasn't been proven insecure yet. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Allowing a possible attacker to control the hash output, and not >>> integrity >>>> protecting the additional data, seems like something I am bound to=20 >>>> regret >>> in >>>> the future. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Hey John, >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> Interesting points, but I don't think they actually apply here. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to downgrade attacks: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> The attack that RFC 5752 is concerned with is when an attacker=20 >>>>>> strips >>>> signatures from a signed message, so that the only ones left are=20 >>>> ones he >>> can >>>> tamper with. So the integrity protection here is "horizontal"; it=20 >>>> goes >>> across >>>> signatures. The integrity protection in JWS/JWE is "vertical" --=20 >>>> it only >>> protects >>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to "brown bag" attacks: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> The root of this attack is ambiguity about what content is=20 >>>>>> *signed* >>>>>=20 >>>>>> vs. what content is *used*. If an application doesn't verify=20 >>>>>> that >>>>>=20 >>>>>> it's actually using the stuff that's signed, then it can be=20 >>>>>> tricked >>>>>=20 >>>>>> into accepting something unsigned. (Cf. >>>>>=20 >>>>>> ) >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> However, I don't think any of the current proposals have that proble= m. >>>> In JWE/JWS, the signed content is right there between the dots, and=20 >>>> in >>> JSMS, >>>> it's in the "content" element. The current JSMS draft does allow=20 >>>> detached signatures, but with a "voids your warranty" sticker on it. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> In any case, these attacks have nothing to do with whether the >>>> cryptographic parameters are integrity-protected with the content. =20 >>>> The example attacks in the IBM still work regardless -- the whole=20 >>>> point of the attack is that the cryptographic processing is the=20 >>>> same, only the >>> (non-crypto) >>>> matching of content is flawed. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to "arbitrary attributes": >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> We can have that here, too, but you need canonicalization. And >>> base64- >>>> encoding is not not canonicalization -- it just waves its hands=20 >>>> over the question of equivalence. In my opinion, we should keep=20 >>>> the cryptographic object simple by disallowing attributes, and push=20 >>>> the attributes you would sign inside of the thing being signed. If=20 >>>> people really do want >>> attributes, it >>>> doesn't seem to me like JSON canonicalization is very hard. I can=20 >>>> do it >>> in 19 >>>> lines of python: >>>>>=20 >>>>>> >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard too "meta-data in the body": >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> It seems to me like if we're trying to define a general format=20 >>>>>> for >>> applying >>>> security protections, then we ought to keep out things that aren't >>> strictly >>>> security relevant. Those things can go in application-specific=20 >>>> content >>> types >>>> (e.g., SAML) without polluting the general purpose header. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> With regard to "defense in depth" and selling this to government >>>> agencies: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> CMS, via S/MIME, is in broad use across multiple federal agencies=20 >>>>>> and >>>> large enterprises. JSMS is essentially a profile of CMS (see=20 >>>> Section 7), >>> and >>>> has the same security properties. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> Cheers, >>>>>=20 >>>>>> --Richard >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>>> Hi Richard, >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> Originally we only integrity protected the header for signing. =20 >>>>>>> We >>> added >>>> the integrity protection to encryption as part of AEAD, as=20 >>>> encryption can >>> also >>>> be used for sender verification. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I understand the argument that it makes things simpler if we=20 >>>>>>> don't >>>> integrity protect the header information. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> However xmldsig, provides integrity over those elements to=20 >>>>>>> prevent >>>> possible downgrade attacks by manipulating the algorithms. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> CMS may not typically provide that integrity protection but I=20 >>>>>>> think >>> Jim >>>> Schaad and Sean Terner created RFC5752 to address downgrade attacks. >>>>>=20 >>>>>>> Given they are on this list they can speak to their view on=20 >>>>>>> integrity >>> over >>>> the crypto parameters. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>> Carlo/Brown >>>> Bag attack that needs to be considered if we move to something more=20 >>>> like a detached signature. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> The other design consideration is that we wanted to be able to=20 >>>>>>> sign >>>> arbitrary byte strings not just JSON. You could sign XML if you want= ed. >>>>>=20 >>>>>>> That prevented us from including meta-data in the body as we=20 >>>>>>> didn't >>>> want to touch it. That left us with the header to include additional >>> elements >>>> in. >>>>>=20 >>>>>>> Not integrity protecting those elements as well would be a problem. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I am not a CMS expert but I believe it allows for signing of >>> arbitrary >>>> attributes not unlike the current JOSE spec. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> Especially for something that will be used with JWT security=20 >>>>>>> tokens I >>> will >>>> have a hard time making the argument to NIST and others that need=20 >>>> to approve this format that not integrity protecting the header=20 >>>> parameters is appropriate defence in depth, for something that=20 >>>> might be replacing signed SAML assertions in some applications. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> I do understand how not integrity protecting the header will=20 >>>>>>> make >>> some >>>> things easier, however I can't agree that the benefit outweighs the=20 >>>> disadvantages. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> Regards >>>>>=20 >>>>>>> John B. >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>>> Hey Mike, >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Thanks for having some back-and-forth with me on this. I think=20 >>>>>>>> this >>> is a >>>> good discussion to have right now. I would like to discuss some >>> high-level >>>> points, and then I'll respond inline to your precise points. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 >>>>>>>> define >>> JSON- >>>> based formats for integrity and confidentiality protections. JWE=20 >>>> and JWS don't fit that requirement, so we should re-consider their=20 >>>> adoption and >>> call >>>> for new candidates. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Major points: >>>>>=20 >>>>>>>> 1. JOSE is JSON >>>>>=20 >>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>=20 >>>>>>>> URL-safeness are still OK, as derivatives >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Part 1: JOSE is JSON >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> The JOSE WG charter calls out four deliverables, three of which=20 >>>>>>>> are >>>> explicitly required to be JSON: >>>>>=20 >>>>>>>> -- "JSON-structured integrity protection" >>>>>=20 >>>>>>>> -- "JSON-structured encryption" >>>>>=20 >>>>>>>> -- "public keys as JSON-structured objects" >>>>>=20 >>>>>>>> (The fourth is just a list of algorithms, which should be JSON=20 >>>>>>>> as >>>>>=20 >>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> In light of these requirements, JWE and JWS are clearly not=20 >>>>>>>> suitable >>>>>=20 >>>>>>>> candidates to fulfill the working group's milestones. (At=20 >>>>>>>> least in >>>>>=20 >>>>>>>> their current form.) So ISTM that we need to step back and >>>>>=20 >>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>> especially >>>>>=20 >>>>>>>> the first two. (JWK is not as far off.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20 >>>>>>>> drafts >>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>> cryptographic parameters within the integrity protection, they have=20 >>>> to have the headers included as base64-encoded strings. That=20 >>>> obviously adds a lot of >>> complexity >>>> to encoding and decoding -- for example, you have to keep the=20 >>>> encoded header around even after you've decoded it! -- and just plain = more octets. >>>> The support for multiple recipients and multiple signatures is both >>> unweildy >>>> (matching up parallel indices for headers and signatures) and=20 >>>> inefficient (multiple integrity check values in encrypted objects). >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom=20 >>>>>>>> that >>>> went into CMS, while making the syntax pure JSON and as simple as >>> possible. >>>> Multiple signatures and multiple recipients are supported with=20 >>>> absolute minimum overhead. So I think it's worth consideration by=20 >>>> the working >>> group. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>> requires >>>>>=20 >>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>=20 >>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>> included >>>>>=20 >>>>>>>> within the integrity protection. I'm not aware of any reason=20 >>>>>>>> for >>>>>=20 >>>>>>>> including the cryptographic parameters in the integrity check, >>>>>=20 >>>>>>>> instead of only integrity-protecting the content itself. =20 >>>>>>>> Indeed, if >>>>>=20 >>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>> cryptographic >>>>>=20 >>>>>>>> parameters, it would be a pretty big deal, since neither CMS=20 >>>>>>>> nor IKE >>>>>=20 >>>>>>>> nor provides this protection. (TLS does provide a signature=20 >>>>>>>> over >>>>>=20 >>>>>>>> the algorithms, but only as a way to bind the public key to the >>>>>=20 >>>>>>>> session.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Indeed CMS doesn't require canonicalization at all, except for >>>> attributes that are included in the protected content (signedAttrs=20 >>>> / authenticatedAttrs), which need to be DER-encoded. In JSMS, we=20 >>>> don't allow those parameters, so there is no need for canonicalization= at all. >>> All the >>>> "canonicalization" that's needed is to base64url-encode the=20 >>>> protected content. In that regard, JSMS is even simpler than JWE/JWS. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>> derivatives >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I have absolutely no objection to defining a compact, URL-safe >>> format. >>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20 >>>> example >>> from >>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> { >>>>>=20 >>>>>>>> "v":1, >>>>>=20 >>>>>>>> "t":"au", >>>>>=20 >>>>>>>> "a":"hs256", >>>>>=20 >>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>=20 >>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>=20 >>>>>>>> "ki":"rSIilRk8Ego" >>>>>=20 >>>>>>>> } >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> If we remove the decorative spaces and base64url-encode, we=20 >>>>>>>> only >>>> use >>>>>=20 >>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>>>=20 >>>>>>>> further and define an explicit compact format for=20 >>>>>>>> AuthenticatedData, >>>>>=20 >>>>>>>> we can emulate JWS by moving the content and MAC fields outside >>>> and >>>>>=20 >>>>>>>> dot-combining. That avoids double-base64url-encoding, and only >>>>>=20 >>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put the=20 >>>>>>>> code >>>>>=20 >>>>>>>> to generate these in the Github project linked earlier.) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>> objective, >>> but it >>>> makes *much* more sense to derive that from a full-size, usable,=20 >>>> JSON format than the other way around. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Responses to specific points inline below. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before=20 >>>>>>>>> doing >>> so, I'll >>>> say that I'm writing in the spirit of trying to increase mutual >>> understanding >>>> and consensus, rather than taking the point of view that the status=20 >>>> quo is >>> the >>>> only reasonable outcome. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Not being JSON >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> This was by design, so that the results are URL-safe. This is >>> required, >>>> for instance, for them to be used as OAuth Bearer Tokens. At the=20 >>>> request >>> of >>>> the working group, closely related pure-JSON drafts were also publishe= d. >>>> See: >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json >>>>>>>>> -seri >>>>>=20 >>>>>>>>> alization-01 and >>>>>=20 >>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-jso >>>>>>>>> n-ser >>>>>=20 >>>>>>>>> ialization-01 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Use them if you prefer if they better suit your use cases. =20 >>>>>>>>> They >>> could >>>> be adopted as working group documents, if there's interest. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> See above. These are super-clunky, and the need to be the main >>>> focus of the WG, not an afterthought. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Not supporting multiple recipients >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> The JSON serialization drafts above do, again, in response to=20 >>>>>>>>> use >>>> cases presented by the working group. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> See above. Because of the unnecessary inclusion of the header=20 >>>>>>>> in >>> the >>>> integrity check, this is far less efficient than it should be. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Functionally, these are very similar operations, at least from=20 >>>>>>>>> an >>>> implementation perspective, so it's not clear that making a clear >>> distinction >>>> would help either developers or adoption in any practical way. =20 >>>> They >>> achieve >>>> overlapping, but admittedly sometimes different goals. I believe=20 >>>> that developers can be trusted to use the algorithms that achieve=20 >>>> their applications' goals without making a hard distinction between th= e two. >>> But >>>> I'd be interested in hearing your thoughts on why you believe a >>> brighter-line >>>> distinction might be useful or necessary. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> It's important if you want to do MACs with anything other than=20 >>>>>>>> pre- >>>> shared keys. If you want to do anything more advanced, you need to=20 >>>> have wrapped keys, in which case an object with a MAC starts to=20 >>>> look a lot more like a JWE than a JWS. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lacking clear processing instructions for different key >>>>>=20 >>>>>>>>> establishment modalities >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> This seems like an area where the existing drafts could be=20 >>>>>>>>> refined >>> to >>>> add descriptions for additional establishment modalities, possibly=20 >>>> based upon your ideas and descriptions, should the working group=20 >>>> decide to do >>> so. >>>> What additional modalities do you have use cases for that you=20 >>>> believe are not achievable or straightforward with the existing=20 >>>> drafts? The existing modalities supported are largely those that=20 >>>> existing developers had told >>> us >>>> they needed and draw both from the precursor draft-jones-json-web-*=20 >>>> documents and draft-rescorla-jsms. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Bear in mind that the balance that the current drafts try to=20 >>>>>>>>> strike >>> is >>>> keeping the Mandatory to Implement (MTI) feature footprint small=20 >>>> enough that developers, including Web developers, are likely to=20 >>>> adopt the specs, while still providing enough functionality to make th= em generally useful. >>> As >>>> in any balance, it's often possible to shift things a bit and still >>> maintain the >>>> balance, but I'd like people to keep the ubiquitous adoption goal >>> front-and- >>>> center when proposing additional functionality. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>=20 >>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>>>=20 >>>>>>>>> that!) >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I agree that we need to find a reasonable MTI. The current=20 >>>>>>>> JSMS >>> draft >>>> doesn't really specify which parts are MTI, beyond basic things=20 >>>> like >>> base64url >>>> encoding and ignoring unknown fields. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> My main concern is that JWS and JWE don't really tell me which >>> fields >>>> need to be present for which use case. If I'm putting a MAC on a JWS = vs. >>> a >>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>> Whereas in >>> JSMS, >>>> I think these things are much clearer due to the separation of the=20 >>>> use >>> cases >>>> (Signed/Authenticated/Encrypted) and the isolation of signatures=20 >>>> and wrapped keys into sub-objects. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lack of clear typing of objects >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Most JSON documents aren't clearly typed; instead, developers=20 >>>>>>>>> and >>>> implementations understand from context what the meaning of each field= is. >>>> XML is clearly typed, but developers are voting with their feet by=20 >>>> moving >>> to >>>> JSON. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> What practical advantages resulting from overlaying a typing >>>> infrastructure on JSON do you believe are worth the potential costs=20 >>>> of >>> doing >>>> so? BTW, I'm not opposed to having a JSON schema description of=20 >>>> the JOSE JSON data structures like JSMS did in=20 >>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, but=20 >>>> I'll remark that this an informative >>> tool, not >>>> a normative one. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> I actualy don't have a hugely urgent requirement here either. =20 >>>>>>>> It's >>>> something that others in the WG had requested, which is trivial to=20 >>>> add in JSMS, but not in JWE/JWS -- again because of the unnecessary=20 >>>> integrity protection of the header. >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>> -- Lack of versioning for future extensibility >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> An optional version field could be added if the working group >>>>>=20 >>>>>>>>> desires, however the last time the working group discussed it,=20 >>>>>>>>> they >>>>>=20 >>>>>>>>> decided not to do so. Rather, specs like this effectively=20 >>>>>>>>> become >>>>>=20 >>>>>>>>> "versioned" when revised in a way that new fields are added. =20 >>>>>>>>> If >>>>>=20 >>>>>>>>> you understand the new fields, you support that new version. =20 >>>>>>>>> (Note >>>>>=20 >>>>>>>>> that this is independent of whether there is a version number >>>>>=20 >>>>>>>>> field, which according to some participants in the previous >>>>>=20 >>>>>>>>> discussion, they regarded as therefore being redundant >>>>>=20 >>>>>>>>> information.) >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> I'm not religious about not having a version number field, but >>> often >>>> "less is more". >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Indeed, I'm not religious either. It just seems like a general=20 >>>>>>>> good >>> idea >>>> to state this directly as opposed to having parsers divine it based=20 >>>> on >>> which >>>> fields are present. To quote RFC 5652: >>>>>=20 >>>>>>>> " >>>>>=20 >>>>>>>> Each of the major data structures includes a version number as=20 >>>>>>>> the >>>>>=20 >>>>>>>> first item in the data structure. The version numbers are=20 >>>>>>>> intended >>>>>=20 >>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20 >>>>>>>> check >>>> the >>>>>=20 >>>>>>>> version number prior to attempting a decode, and if a decode=20 >>>>>>>> error >>>>>=20 >>>>>>>> occurs, then the version number is checked as part of the error >>>>>=20 >>>>>>>> handling routine. This is a reasonable approach; it places=20 >>>>>>>> error >>>>>=20 >>>>>>>> processing outside of the fast path. This approach is also >>>>>=20 >>>>>>>> forgiving when an incorrect version number is used by the sender. >>>>>=20 >>>>>>>> " >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> Best, >>>>>=20 >>>>>>>> --Richard >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Best wishes, >>>>>=20 >>>>>>>>> -- Mike >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> -----Original Message----- >>>>>=20 >>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>=20 >>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>=20 >>>>>>>>> To: Mike Jones >>>>>=20 >>>>>>>>> Cc: jose@ietf.org >>>>>=20 >>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>=20 >>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. =20 >>>>>>>>> IMO, >>> the >>>> current JW* specs are deficient in several ways, e.g.: >>>>>=20 >>>>>>>>> -- Not being JSON >>>>>=20 >>>>>>>>> -- Not supporting multiple recipients >>>>>=20 >>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>=20 >>>>>>>>> -- Lacking clear processing instructions for different key >>>>>=20 >>>>>>>>> establishment modalities >>>>>=20 >>>>>>>>> -- Lack of clear typing of objects >>>>>=20 >>>>>>>>> -- Lack of versioning for future extensibility >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Looking at the current specs, it didn't seem to me that it=20 >>>>>>>>> would be >>>> simple to adapt them to address these deficiencies. So I just did=20 >>>> a >>> re-write. >>>> If you think they can be addressed within the current framework,=20 >>>> please explain. I just found it simpler to start from whole cloth. >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> Cheers, >>>>>=20 >>>>>>>>> --Richard >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Hi Richard, >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>> documents, >>>> I encourage you to ask about them on the list. The documents have=20 >>>> significant history going back to mid-2010 when convergence=20 >>>> discussions started among people with four different JSON signing &=20 >>>> encryption proposals. JWT and the current JOSE specs and=20 >>>> implementations are the result. I realize that not all the JOSE=20 >>>> participants were part of those discussions from the beginning=20 >>>> (although many were) and so teasing out the rationale for specific=20 >>>> decisions might help people better understand the choices made, and=20 >>>> hopefully thereby increase consensus behind the eventual working group= choices. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 >>>>>>>>>> below, >>> maybe we >>>> can start a discussion on that basis. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Best wishes, >>>>>=20 >>>>>>>>>> -- Mike >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>=20 >>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>=20 >>>>>>>>>> Behalf Of Richard L. Barnes >>>>>=20 >>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>=20 >>>>>>>>>> To: jose@ietf.org >>>>>=20 >>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>=20 >>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Dear JOSE WG, >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>> thorough >>>> review of the JW* specs, I was kind of puzzled by some of the=20 >>>> design decisions. So I also went through and wrote an alternative=20 >>>> format, this >>> time >>>> taking a more of a cue from CMS. A link to the document is below. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Summary of differences: >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>>=20 >>>>>>>>>> parameters are represented in JSON. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS allows for full algorithm agility in key agreement,=20 >>>>>>>>>> while >>> JWE >>>>>=20 >>>>>>>>>> only allows ECDH-ES. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>=20 >>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>> WrappedKey >>>>>=20 >>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>>=20 >>>>>>>>>> encryption of the entire object for each recipient. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o The signature and MAC functions of the JWS object are=20 >>>>>>>>>> separated >>>>>=20 >>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS parameters are not integrity-protected, as they are=20 >>>>>>>>>> in JWE >>>>>=20 >>>>>>>>>> and JWS. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS,=20 >>>>>>>>>> but >>> could >>>>>=20 >>>>>>>>>> be added without significant change. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>>=20 >>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>> implementation >>> (based >>>> on NodeJS for some python crypto glue), which is on github: >>>>>=20 >>>>>>>>>> >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Comments are very welcome. >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Thanks, >>>>>=20 >>>>>>>>>> --Richard >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> Begin forwarded message: >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> From: internet-drafts@ietf.org >>>>>=20 >>>>>>>>>>> Subject: New Version Notification for >>>>>=20 >>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>=20 >>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>=20 >>>>>>>>>>> To: rbarnes@bbn.com >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>>>=20 >>>>>>>>>>> successfully submitted by Richard Barnes and posted to the=20 >>>>>>>>>>> IETF >>>>>=20 >>>>>>>>>>> repository. >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>=20 >>>>>>>>>>> Revision: 00 >>>>>=20 >>>>>>>>>>> Title: JavaScript Message Security Format >>>>>=20 >>>>>>>>>>> Creation date: 2012-06-15 >>>>>=20 >>>>>>>>>>> WG ID: Individual Submission >>>>>=20 >>>>>>>>>>> Number of pages: 25 >>>>>=20 >>>>>>>>>>> URL: >>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>> jsms-00.txt >>>>>=20 >>>>>>>>>>> Status: >>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>=20 >>>>>>>>>>> Htmlized: >>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> Abstract: >>>>>=20 >>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>> cryptographically >>>>>=20 >>>>>>>>>>> secured messages. While the IETF has defined a number of >>>> formats >>>>>=20 >>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings=20 >>>>>>>>>>> which >>>>>=20 >>>>>>>>>>> are not easy to use in modern applications. This document >>>>>=20 >>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a=20 >>>>>>>>>>> new >>>>>=20 >>>>>>>>>>> cryptographic message format which is based on JavaScript=20 >>>>>>>>>>> Object >>>>>=20 >>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>> generate >>>> and parse. >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>> The IETF Secretariat >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>>>> jose mailing list >>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>>=20 >>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>>>> jose mailing list >>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>>> jose mailing list >>>>>=20 >>>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>> _______________________________________________ >>>>>=20 >>>>>>>> jose mailing list >>>>>=20 >>>>>>>> jose@ietf.org >>>>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From ve7jtb@ve7jtb.com Tue Jun 26 14:00: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 2247511E80CF for ; Tue, 26 Jun 2012 14:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.364 X-Spam-Level: X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQD71T5iIDpp for ; Tue, 26 Jun 2012 14:00:02 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7A111E80CC for ; Tue, 26 Jun 2012 14:00:02 -0700 (PDT) Received: by yhp26 with SMTP id 26so579012yhp.26 for ; Tue, 26 Jun 2012 14:00:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=+Jo1vtx7lCq3K4F7fmBcoaHFLifmzSV2P+z6a4C43DY=; b=HqMydCjARbTvgapAt6gzu7aaamD5j5a6pPTBLixN1pUGd/uk1T4r19Dfk56c0BkP8i 0rcDLEmxLSoHUn/Ck27EeA75nvu+Y2yuMKS5+/oleL9NUsOho/KgVsAzePR4wiqBd1HG cSxNBABc7on6uf+maAItWS/arJkr0hdGss3EZY0fjjnG27nH08ZI2ahrE5GR+fglYnnN 7mRK0aSPyb+ZPK79a25xnthBIltXO8j08YEGTK9ymnyVQ6KWjIioQZyDK+IMD0Qjt/v0 o5npTyUel2f2jsl76sUJ+nI6O19XxK+oYxXxEqhClvPLU7i1Fp50fVpagwOB4TI3p2Wd JJJQ== Received: by 10.100.244.19 with SMTP id r19mr6042456anh.48.1340744401901; Tue, 26 Jun 2012 14:00:01 -0700 (PDT) Received: from [192.168.1.213] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id a34sm142632294yhh.0.2012.06.26.13.59.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 14:00:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_561EDE44-4BAF-44EE-A408-D44963072712"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <2A8A4F3B-CD0D-48C5-8A65-49A2E8C4D096@bbn.com> Date: Tue, 26 Jun 2012 16:58:46 -0400 Message-Id: <6821E712-0D0D-419B-9E15-789DE54798A9@ve7jtb.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> <2A8A4F3B-CD0D-48C5-8A65-49A2E8C4D096@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQll5xTbw0Q+dOU6ArN6tx3LO0uR5ZRXj28iceYWBaGhZswY10aMxsJkK8WopWHlR1M1RA+L Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Tue, 26 Jun 2012 21:00:04 -0000 --Apple-Mail=_561EDE44-4BAF-44EE-A408-D44963072712 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would prefer to let Matt update his spec before further dragging him = into this. I have always been for having multiple recipients, I raised the issue = with JWE before the JOSE work group. I just want to do that without overly complicating the simple case. The question is how to do it. I and others prefer maintaining the = integrity protection over both the header and content. =20 I prefer to find a way to have both integrity and multiple recipients. As I stated Jim's proposal has some good ideas and doesn't require = scrapping integrity. I appreciate that you are approaching this from the CMS perspective, = though the correct thing to do in CMS with integrity protecting = attributes in CMS seems to also have multiple opinions. Regards John B. On 2012-06-26, at 3:30 PM, Richard L. Barnes wrote: >>> Alternatively, you could provide a whole JSMS EncryptedData object = on the first shot, with WrappedKeys for keys you know. Then, if a = recipient doesn't find a WrappedKey for himself, he can for it, = and you can just respond with the WrappedKey. >>>=20 >>> --Richard >>>=20 >>>=20 >> That is what I was trying to get at. The existing spec supports = sending the wrapped content key with a keyid. >>=20 >> You send that with every message, if the recipient doesn't have the = necessary key it requests it. >>=20 >> The receiver retrieves the key and unwraps the CMK. There is = nothing in the current spec that stops that from working. >>=20 >> The message and integrity are based on the wrapped key. That is the = decision the WG took a while ago. >>=20 >> Having multiple recipients each with a different symmetric or = asymmetric key used to wrap the CMK is slightly different problem. >=20 > Obviously, JWE key wrapping works for single recipients. I don't = contest that. Multiple recipients is the problem. =20 >=20 > Unless you want to support multiple recipients, there's no point to = Matt's scheme. It's tempting to think that it addresses the case where = the sender doesn't know the single recipient's key in advance, but in = that case, it would be much simpler just to have the sender request the = key at the start. So the whole point of Matt's document is to support = multiple recipients, at the cryptographic layer, even if not at the XMPP = layer (a given JID might have multiple keys, e.g., per device). >=20 > Anyway, you skipped the important question in my mail: Do you think = that Matt's scheme compromises the security of the JWE? >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >> Jim's proposal for having multiple recipients in the header has = potential, I don't support everything in it but it contributes some = useful ideas to support multiple recipient and signature use cases. >>=20 >> John B. >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jun 25, 2012, at 7:02 PM, John Bradley wrote: >>>=20 >>>> Richard, >>>>=20 >>>> There was some other back and for with Matt. >>>>=20 >>>> He is only encrypting to one recipient at a time. >>>>=20 >>>> Not that encrypting the CMK to multiple recipients is not valid, = that is just not how the protocol works. >>>>=20 >>>> The message is encrypted once and whatever endpoint gets it calls = back to the sender to get the key. >>>>=20 >>>> The issue as I understand it is that the sender doesn't know the = public key for the recipient before it sends the message. >>>>=20 >>>> I am happy to work on Matts issues, but I think they are separate = from the point you are making on integrity protecting the header. >>>>=20 >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >>>>=20 >>>>>> Having read Matt's spec, he is not breaking JWE to send to = multiple recipients. As the spec says: >>>>>> "This document specifies an approach for encrypting = communications between two entities which each might have multiple = end-points" >>>>>=20 >>>>> He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >>>>>=20 >>>>> Compare JSMS and the WrappedKey structure, or CMS and = RecipientInfo. >>>>> = >>>>> >>>>>=20 >>>>>=20 >>>>>> I should also point out that the messages are transported in XML, = and as such, the addition of a JSON wrapper for the JWE probably is not = useful as it would need escaping anyway. By not sending the CMK as part = of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>>>>=20 >>>>>> There are two somewhat separate uses for JWE in the spec: one = for encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>>>>=20 >>>>>> For the transmission of the messages, I can't see any reason to = not use the JWE spec as currently written. It certainly supports the = use case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>>>>=20 >>>>>> Currently the message on the wire looks like: >>>>>>=20 >>>>>> >>>>> from=3D'juliet@capulet.lit/balcony' >>>>>> id=3D'fJZd9WFIIwNjFctT' >>>>>> to=3D'romeo@montegue.lit/garden' >>>>>> type=3D'chat'> >>>>>> >>>>> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>>>>
>>>>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>>>>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>>>>> NpemUiOiIxNiJ9 >>>>>>
>>>>>> >>>>>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>>>>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>>>>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>>>>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>>>>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>>>>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>>>>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>>>>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>>>>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>>>>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>>>>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>>>>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>>>>> eCGP >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>=20 >>>>>> I would have sent header and data as one element using the normal = JWE dot separated format, but I need to talk to Matt to understand his = reasoning. >>>>>>=20 >>>>>> I note that his example is using AES-CCM, and so not documented = in JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>>>>=20 >>>>> Valid point. I had missed that RFC 5084 handled the ICV = separately. >>>>>=20 >>>>>=20 >>>>>> I don't quite get your point on integrity protecting the wrapped = key causing the integrity value to change. For HMAC, GCM, and I think = CCM, changing the encryption key changes the tag value anyway (sort of = the point I thought). The only time it would stay the same would be if = you were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >>>>>=20 >>>>> The point is that you have to re-compute the ICV over the entire = header+content every time you wrap a new key. This is kind of a big = deal for the XMPP case. =20 >>>>>=20 >>>>> Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >>>>>=20 >>>>> So integrity protecting the headers has real costs in terms of = both scalability (state) and security. >>>>>=20 >>>>>=20 >>>>>> There are some interesting things Matt=92s spec is attempting = with using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>>>>=20 >>>>> My point is that we shouldn't need a whole new protocol for this. = CMS RecipientInfos do exactly what we want. (Er, what *Matt* wants.) = We should just be copying and pasting. >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I am happy to work with Matt to refine his ID. >>>>>>=20 >>>>>> I recommend others read it as well so we can understand if there = are any real issues. >>>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>> Hey John, >>>>>>>=20 >>>>>>> I think you're missing the bigger point here, which is: In order = to allow for multiple recipients, Matt had to break JWE. >>>>>>>=20 >>>>>>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>>>>=20 >>>>>>> --Richard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>>>>=20 >>>>>>>> Hi Matt, >>>>>>>>=20 >>>>>>>> Complements on updating the draft. >>>>>>>>=20 >>>>>>>> The issue I see is that you are attempting to distribute the = CMK out of band and use "none" as the alg. >>>>>>>>=20 >>>>>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>>>>=20 >>>>>>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>>>>>> =46rom a implementation point of view the symmetric cypher = always gets the CEK derived from the CMK in the message independent of = if it is using RSA or A128KW/A256KW. >>>>>>>>=20 >>>>>>>> That imposes some extra steps for people using symmetric keys = but encourages rotation of the CEK that would likely not happen = otherwise. >>>>>>>>=20 >>>>>>>> So in your spec I would expect you to distribute a shared = secret via keyreq for use in A256KW and be using that decrypt the CMK at = the receiver. >>>>>>>>=20 >>>>>>>> I also suspect that you intended to use A256GCM as the enc alg = and not A256CCM.=20 >>>>>>>>=20 >>>>>>>> I am not a XMPP expert so it will take me some time to go over = it in detail. I would like to understand the use case to be certain it = is properly supported. >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> John B. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>>>>>=20 >>>>>>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been = updated to the latest JOSE WG drafts. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - m&m >>>>>>>>>=20 >>>>>>>>> Matt Miller - >>>>>>>>> Cisco Systems, Inc. >>>>>>>>>=20 >>>>>>>>> Begin forwarded message: >>>>>>>>>=20 >>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>>>>>> Author(s) : Matthew Miller >>>>>>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>>>>>> Pages : 22 >>>>>>>>>> Date : 2012-06-21 >>>>>>>>>>=20 >>>>>>>>>> Abstract: >>>>>>>>>> This document defines a method of end-to-end object = encryption for >>>>>>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>>>>>=20 >>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>>>>>=20 >>>>>>>>>> A diff from previous version is available at: >>>>>>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> I-D-Announce mailing list >>>>>>>>>> I-D-Announce@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_561EDE44-4BAF-44EE-A408-D44963072712 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjIwNTg0N1owIwYJKoZIhvcNAQkEMRYEFORSrkfnMOKARsGTX6Xa84DZUSKLMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AKIyDS7yhKZ53ztgFvscs+Tv7oXCGc5SboteYQThacsCpAXUilLHlS8HWDOGeTMlffK0SB2GPFL0 iOmCDrkeiDnoInB8rp8Ionw8B59V6c8IyRV/H+nUL/EQJ0IYS8UT78ojtEi6kPUE/36yWMCcrbJO 3CYLaoOSV8Wx2tdurn28o8XgdpG4TzIml0HtF7LOwuv/kkbJ/GfNOyzUSyTckKWnaeH/aLzmdIcG 6xiw8QDAtszGrFqmNCnc1ZCeaaGaybicvcLSrL6be4HU1Y5FwFQh1jbsGT6wk63l/HobKOFJYwRw acxwI+UTSObr3T8I8aGzqJ3WASn87Np1cfclZ5UAAAAAAAA= --Apple-Mail=_561EDE44-4BAF-44EE-A408-D44963072712-- From ve7jtb@ve7jtb.com Tue Jun 26 14:00: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 C9FBB11E80DB for ; Tue, 26 Jun 2012 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nclE-wQzCa9C for ; Tue, 26 Jun 2012 14:00:12 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF211E80CC for ; Tue, 26 Jun 2012 14:00:11 -0700 (PDT) Received: by ghbg16 with SMTP id g16so412336ghb.31 for ; Tue, 26 Jun 2012 14:00:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=xaBrgDj32N446te2Q/axSv7HJs/amxlGVTMbYQjeo2A=; b=DWl4i5pBUzqKQninPLKLPCRwai+SGw6To7HtAECWOiV6B03o6BtmVt2WcKlM7OVRnV YUf5hhT6+wTYi/mw7A5ag+PISq3OZZ8v6rRQyu78nvGx7FMA4OysZ7Y+Pdl/PJyM7Vfw f9EMFWVPiM+yTZkTvmJl/BgyAEREv/9CkfjX6t+LiHGdRBuOYmf21R9fiJydr7xcJX9b hREhvcfa2q1gfRuqGbGxhyO40olGwGFBDNd+6z5TwfqlLXo23TeC/D60JbwtV6D7akry 4bx2zmrZqoDhyNVzBmbzK3NQUqBLqWPHikAGlmFZ7yre9++P7m/x1N3bOd86rRWSem6w iEBA== Received: by 10.101.23.4 with SMTP id a4mr5837292anj.13.1340744411049; Tue, 26 Jun 2012 14:00:11 -0700 (PDT) Received: from [192.168.1.213] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id a34sm142632294yhh.0.2012.06.26.14.00.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 14:00:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_F17FD3F5-8ECC-49B1-8035-AD718C2B7AC6"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 26 Jun 2012 16:58:55 -0400 Message-Id: <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmx8ZrcKGvg9vT1FWym+Tpza/R/L+hmSMTla3/qJoJH+/Rh0pLPhqfjG3jpvZBknWyp3Br9 Cc: "Richard L. Barnes" , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:00:16 -0000 --Apple-Mail=_F17FD3F5-8ECC-49B1-8035-AD718C2B7AC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes that is why we added the composite HMAC + AES-CBC. We can debate = if that is an algorithm or mandatory integrity with non AEAD algorithms, = but the effect of integrity protecting the header remains in both cases. John B. On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: > Not sure there was a WG decision and what that would mean if there = was, as there are many libraries out there that don't support the = encryption with integrity algorithms, so need to support alternative = means of things like key wrap that could have an integrity check. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of John Bradley > Sent: Tuesday, June 26, 2012 12:30 PM > To: Richard L. Barnes > Cc: Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > There was a WG decision to not allow encryption without integrity. = Jim and others call that sender verification. >=20 > Or on simple terms no AES-CBC without a mandatory MAC integrity. >=20 > The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. >=20 > We do have s JWT spec that covers the body for security tokens. The = idea was to separate that from signing and encryption so that signing = and encryption can be used for other objects. >=20 > John B. >=20 > On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >=20 >>> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >>> In those cases one can easily argue that the header should be = protected as much as in HMAC. >>=20 >> Can you clarify the scope of "we are mandating"? >>=20 >>=20 >>> There may well be signing_time or other elements that would go into = the header as well for JWE. >>=20 >> Why do these need to go into the header rather than the body? >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>> Regards >>> John B. >>>=20 >>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>=20 >>>> >>>>=20 >>>> Richard, >>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>> Behalf Of Richard L. Barnes >>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>> To: Nat Sakimura >>>>> Cc: Mike Jones; jose@ietf.org >>>>> Subject: Re: [jose] New Version Notification for=20 >>>>> draft-barnes-jose-jsms- 00.txt >>>>>=20 >>>>> Hi Nat, >>>>>=20 >>>>> I'm not sure what X.509 fiasco you're referring to. There was a=20= >>>>> recent >>>> MD5 >>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, = there=20 >>>>> have >>>> been >>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. =20 >>>>> As >>>> was >>>>> noted on the SAAG list, the real news here is that Microsoft = wasn't >>>> following >>>>> any of those recommendations. >>>>>=20 >>>>> JWS would have had the same problem as X.509. The attack did not=20= >>>>> modify the cryptographic parameters (anything that would have gone=20= >>>>> in the header), it would not have been thwarted by the integrity=20= >>>>> protection we're worrying about. >>>>>=20 >>>>> Actually, the header signing that JWS does makes it even nicer for=20= >>>>> the >>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20 >>>>> header >>>> value >>>>> is entirely static for a given signer, it's easy to use as a fixed = prefix. >>>> If JWS just >>>>> signed the content, then the application could include a something=20= >>>>> random up front to prevent such prefix-based attacks. >>>>>=20 >>>>=20 >>>> I don't believe that this is a true statement. If you had a prefix=20= >>>> or just signed what was given to you (i.e. no prefix), it would = make=20 >>>> no difference in terms of the attack for Flame. Flame could always=20= >>>> use a fixed prefix of its own design rather than using the fixed=20 >>>> header that is generated by having JWS sign the header information. >>>>=20 >>>>> It's tempting to say that we should just add randomness to the = JOSE >>>> format. >>>>> But the real lesson of the Flame/MD5 attacks is operational: If=20= >>>>> you're >>>> signing >>>>> something that somebody else gave you, make sure that you're not=20= >>>>> signing exactly what they gave you. Follow the recommendations of=20= >>>>> RFC 4270. In other contexts, there's no need of similar random=20 >>>>> elements; it just adds complexity. >>>>=20 >>>> This is definitely a true statement in all events and is something=20= >>>> that should be added to the Security Considerations section. >>>>=20 >>>> That being said, I think that there are valid reasons for wanting = to=20 >>>> protect the header information by some authentication processing. =20= >>>> PKIX certificates protect the signature algorithm information (by=20= >>>> copying the data into the to be signed block) and CMS has long=20 >>>> allowed for information to be included in the signed attributes = area=20 >>>> that identifies the algorithms used, the certificates used and so=20= >>>> forth. There are also other things that we might find to be=20 >>>> convenient to be placed in the header information that is current=20= >>>> not there (a signing time and embedded content type comes to mind)=20= >>>> that would be a product either of specific types of signatures or = becomes a common attribute to be placed there. >>>>=20 >>>> In terms of encryption operations, I remember in the past that I=20 >>>> have had either corrupted encrypted streams or corrupted IVs and = had=20 >>>> a successful decryption that later generated other problems when=20 >>>> trying to parse. This is less of an issue with AEAD algorithms as=20= >>>> they have a much stricter rule on when the stream decrypts = correctly. >>>>=20 >>>> Jim >>>>=20 >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> [1] >>>>> [2] >>>>>=20 >>>>>=20 >>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>=20 >>>>>> Especially after the X.509 fiasco, I strongly believe that having >>>> integrity >>>>> check over the metadata is a good thing. It is such a little = effort=20 >>>>> that >>>> gives us >>>>> much more protection down the road. In this sense, I fully agree=20= >>>>> with Ben here. We should have integrity protection over the = header. >>>>>>=20 >>>>>> Nat >>>>>>=20 >>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>> wrote: >>>>>> Two years ago when the developer community needing a = JSON-friendly >>>>> token format was designing the JSON Web Token (JWT), we explicitly=20= >>>>> asked security experts whether the header parameters should be=20 >>>>> integrity protected or not. Among them, Ben Laurie was one of the=20= >>>>> voices saying >>>> that >>>>> securing them was the right thing to do. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> He argued that if the parameters can be protected in a practical=20= >>>>>> manner, >>>>> then they should. Doing so provides an additional hurdle that=20 >>>>> attackers would have to surmount. For example, if they can try to=20= >>>>> substitute a >>>> weaker >>>>> authentication scheme, then they must figure out how to make it=20 >>>>> authenticate correctly despite some plaintext they can't control -=20= >>>>> the >>>> header >>>>> parameters. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Ben also took the position that paring security protocols down to=20= >>>>>> the >>>> least >>>>> you can get away with, given attacks you can think of, is not a=20 >>>>> good >>>> design >>>>> principle. If there is not a strong argument against including a=20= >>>>> feature >>>> that >>>>> may make it harder for attackers, then that feature should be = included. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I agree with him. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The decision to provide integrity protection for the headers is >>>> documented >>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> . What to sign (envelope.payload or just payload)? >>>>>>=20 >>>>>> Given that the envelope is extensible and therefore may contain >>>> security- >>>>> sensitive information, we reached a consensus (with input from Ben=20= >>>>> Laurie via IM) that the combination envelope.payload must be = signed. >>>>>>=20 >>>>>>=20 >>>>>> I believe that logic is as sound today as it was then. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>> community's >>>>> decision to provide integrity protection for the headers. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best=20 >>>>>> wishes, >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>> Behalf Of >>>>> John Bradley >>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>> To: Richard L.Barnes >>>>>> Cc: jose@ietf.org >>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>> draft-barnes-jose-jsms- >>>>> 00.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi Richard, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding=20= >>>>>> and not >>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>=20 >>>>>> There are possible hash truncation attacks by shortening SHA256 = to >>>> SHA224 >>>>> as an example (I know we preclude truncated hashes at the moment). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The bad feeling I get around this is that if there is a scenario=20= >>>>>> where >>>> the >>>>> attacker controls the plaintext to be signed and there is no = signer >>>> controlled >>>>> text contributed there are potential bad things that could happen=20= >>>>> down the road. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This bit us with x509 certs not that long ago (yes with MD5=20 >>>>>> admittedly) >>>>> where the attacker could use a certificate extension to include=20 >>>>> extra data >>>> and >>>>> cause a pre collided hash to be generated. >>>>>>=20 >>>>>> Having part of the signed data outside the control of an attacker=20= >>>>>> is a >>>> good >>>>> thing. (having a nonce or message ID in the envelope is possible=20= >>>>> though >>>> not >>>>> yet required in JWS.) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I am still of the opinion that putting the base64 encoded = envelope >>>> inside >>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>=20 >>>>>> Another structure to hold the attributes adds more complexity, = as=20 >>>>>> would >>>>> saying that they need to be inside the signed object. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I think part of this is that as one of the openID Connect authors=20= >>>>>> I look >>>> at this >>>>> as a necessary security token format, for OAuth and Connect. >>>>>>=20 >>>>>> For that simple processing with one signature is a high priority=20= >>>>>> for >>>> adoption. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =46rom a general signing/encrypting of documents point of view = you >>>>> legitimately have different priorities. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I know it is hard to prove a negative but It is also going to be >>>> difficult for me >>>>> to go back to security people at google Facebook and other places=20= >>>>> and explain how not integrity protecting the header could be = better=20 >>>>> than integrity protecting it. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> It seems that I would be reduced to arguing that this is no worse=20= >>>>>> than >>>> CMS >>>>> and that hasn't been proven insecure yet. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Allowing a possible attacker to control the hash output, and not >>>> integrity >>>>> protecting the additional data, seems like something I am bound to=20= >>>>> regret >>>> in >>>>> the future. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Hey John, >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Interesting points, but I don't think they actually apply here. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to downgrade attacks: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> The attack that RFC 5752 is concerned with is when an attacker=20= >>>>>>> strips >>>>> signatures from a signed message, so that the only ones left are=20= >>>>> ones he >>>> can >>>>> tamper with. So the integrity protection here is "horizontal"; it=20= >>>>> goes >>>> across >>>>> signatures. The integrity protection in JWS/JWE is "vertical" --=20= >>>>> it only >>>> protects >>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "brown bag" attacks: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> The root of this attack is ambiguity about what content is=20 >>>>>>> *signed* >>>>>>=20 >>>>>>> vs. what content is *used*. If an application doesn't verify=20 >>>>>>> that >>>>>>=20 >>>>>>> it's actually using the stuff that's signed, then it can be=20 >>>>>>> tricked >>>>>>=20 >>>>>>> into accepting something unsigned. (Cf. >>>>>>=20 >>>>>>> ) >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> However, I don't think any of the current proposals have that = problem. >>>>> In JWE/JWS, the signed content is right there between the dots, = and=20 >>>>> in >>>> JSMS, >>>>> it's in the "content" element. The current JSMS draft does allow=20= >>>>> detached signatures, but with a "voids your warranty" sticker on = it. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> In any case, these attacks have nothing to do with whether the >>>>> cryptographic parameters are integrity-protected with the content. = =20 >>>>> The example attacks in the IBM still work regardless -- the whole=20= >>>>> point of the attack is that the cryptographic processing is the=20 >>>>> same, only the >>>> (non-crypto) >>>>> matching of content is flawed. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "arbitrary attributes": >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> We can have that here, too, but you need canonicalization. And >>>> base64- >>>>> encoding is not not canonicalization -- it just waves its hands=20 >>>>> over the question of equivalence. In my opinion, we should keep=20= >>>>> the cryptographic object simple by disallowing attributes, and = push=20 >>>>> the attributes you would sign inside of the thing being signed. = If=20 >>>>> people really do want >>>> attributes, it >>>>> doesn't seem to me like JSON canonicalization is very hard. I can=20= >>>>> do it >>>> in 19 >>>>> lines of python: >>>>>>=20 >>>>>>> >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard too "meta-data in the body": >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> It seems to me like if we're trying to define a general format=20= >>>>>>> for >>>> applying >>>>> security protections, then we ought to keep out things that aren't >>>> strictly >>>>> security relevant. Those things can go in application-specific=20 >>>>> content >>>> types >>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "defense in depth" and selling this to government >>>>> agencies: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> CMS, via S/MIME, is in broad use across multiple federal = agencies=20 >>>>>>> and >>>>> large enterprises. JSMS is essentially a profile of CMS (see=20 >>>>> Section 7), >>>> and >>>>> has the same security properties. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Cheers, >>>>>>=20 >>>>>>> --Richard >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>> Hi Richard, >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Originally we only integrity protected the header for signing. =20= >>>>>>>> We >>>> added >>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>> encryption can >>>> also >>>>> be used for sender verification. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I understand the argument that it makes things simpler if we=20 >>>>>>>> don't >>>>> integrity protect the header information. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> However xmldsig, provides integrity over those elements to=20 >>>>>>>> prevent >>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> CMS may not typically provide that integrity protection but I=20= >>>>>>>> think >>>> Jim >>>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>>=20 >>>>>>>> Given they are on this list they can speak to their view on=20 >>>>>>>> integrity >>>> over >>>>> the crypto parameters. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>> Carlo/Brown >>>>> Bag attack that needs to be considered if we move to something = more=20 >>>>> like a detached signature. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> The other design consideration is that we wanted to be able to=20= >>>>>>>> sign >>>>> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>>>>=20 >>>>>>>> That prevented us from including meta-data in the body as we=20 >>>>>>>> didn't >>>>> want to touch it. That left us with the header to include = additional >>>> elements >>>>> in. >>>>>>=20 >>>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>> arbitrary >>>>> attributes not unlike the current JOSE spec. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Especially for something that will be used with JWT security=20 >>>>>>>> tokens I >>>> will >>>>> have a hard time making the argument to NIST and others that need=20= >>>>> to approve this format that not integrity protecting the header=20 >>>>> parameters is appropriate defence in depth, for something that=20 >>>>> might be replacing signed SAML assertions in some applications. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I do understand how not integrity protecting the header will=20 >>>>>>>> make >>>> some >>>>> things easier, however I can't agree that the benefit outweighs = the=20 >>>>> disadvantages. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Regards >>>>>>=20 >>>>>>>> John B. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>>> Hey Mike, >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Thanks for having some back-and-forth with me on this. I = think=20 >>>>>>>>> this >>>> is a >>>>> good discussion to have right now. I would like to discuss some >>>> high-level >>>>> points, and then I'll respond inline to your precise points. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 >>>>>>>>> define >>>> JSON- >>>>> based formats for integrity and confidentiality protections. JWE=20= >>>>> and JWS don't fit that requirement, so we should re-consider their=20= >>>>> adoption and >>>> call >>>>> for new candidates. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Major points: >>>>>>=20 >>>>>>>>> 1. JOSE is JSON >>>>>>=20 >>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>=20 >>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 1: JOSE is JSON >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> The JOSE WG charter calls out four deliverables, three of = which=20 >>>>>>>>> are >>>>> explicitly required to be JSON: >>>>>>=20 >>>>>>>>> -- "JSON-structured integrity protection" >>>>>>=20 >>>>>>>>> -- "JSON-structured encryption" >>>>>>=20 >>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>=20 >>>>>>>>> (The fourth is just a list of algorithms, which should be JSON=20= >>>>>>>>> as >>>>>>=20 >>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20 >>>>>>>>> suitable >>>>>>=20 >>>>>>>>> candidates to fulfill the working group's milestones. (At=20 >>>>>>>>> least in >>>>>>=20 >>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>=20 >>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>> especially >>>>>>=20 >>>>>>>>> the first two. (JWK is not as far off.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20 >>>>>>>>> drafts >>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>> cryptographic parameters within the integrity protection, they = have=20 >>>>> to have the headers included as base64-encoded strings. That=20 >>>>> obviously adds a lot of >>>> complexity >>>>> to encoding and decoding -- for example, you have to keep the=20 >>>>> encoded header around even after you've decoded it! -- and just = plain more octets. >>>>> The support for multiple recipients and multiple signatures is = both >>>> unweildy >>>>> (matching up parallel indices for headers and signatures) and=20 >>>>> inefficient (multiple integrity check values in encrypted = objects). >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom=20= >>>>>>>>> that >>>>> went into CMS, while making the syntax pure JSON and as simple as >>>> possible. >>>>> Multiple signatures and multiple recipients are supported with=20 >>>>> absolute minimum overhead. So I think it's worth consideration by=20= >>>>> the working >>>> group. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>> requires >>>>>>=20 >>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>=20 >>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>> included >>>>>>=20 >>>>>>>>> within the integrity protection. I'm not aware of any reason=20= >>>>>>>>> for >>>>>>=20 >>>>>>>>> including the cryptographic parameters in the integrity check, >>>>>>=20 >>>>>>>>> instead of only integrity-protecting the content itself. =20 >>>>>>>>> Indeed, if >>>>>>=20 >>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>> cryptographic >>>>>>=20 >>>>>>>>> parameters, it would be a pretty big deal, since neither CMS=20= >>>>>>>>> nor IKE >>>>>>=20 >>>>>>>>> nor provides this protection. (TLS does provide a signature=20= >>>>>>>>> over >>>>>>=20 >>>>>>>>> the algorithms, but only as a way to bind the public key to = the >>>>>>=20 >>>>>>>>> session.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Indeed CMS doesn't require canonicalization at all, except for >>>>> attributes that are included in the protected content (signedAttrs=20= >>>>> / authenticatedAttrs), which need to be DER-encoded. In JSMS, we=20= >>>>> don't allow those parameters, so there is no need for = canonicalization at all. >>>> All the >>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>> protected content. In that regard, JSMS is even simpler than = JWE/JWS. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>> derivatives >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I have absolutely no objection to defining a compact, URL-safe >>>> format. >>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20 >>>>> example >>>> from >>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> { >>>>>>=20 >>>>>>>>> "v":1, >>>>>>=20 >>>>>>>>> "t":"au", >>>>>>=20 >>>>>>>>> "a":"hs256", >>>>>>=20 >>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>=20 >>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>=20 >>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>=20 >>>>>>>>> } >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20 >>>>>>>>> only >>>>> use >>>>>>=20 >>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>>>>=20 >>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>> AuthenticatedData, >>>>>>=20 >>>>>>>>> we can emulate JWS by moving the content and MAC fields = outside >>>>> and >>>>>>=20 >>>>>>>>> dot-combining. That avoids double-base64url-encoding, and = only >>>>>>=20 >>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put = the=20 >>>>>>>>> code >>>>>>=20 >>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>> objective, >>>> but it >>>>> makes *much* more sense to derive that from a full-size, usable,=20= >>>>> JSON format than the other way around. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Responses to specific points inline below. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before=20= >>>>>>>>>> doing >>>> so, I'll >>>>> say that I'm writing in the spirit of trying to increase mutual >>>> understanding >>>>> and consensus, rather than taking the point of view that the = status=20 >>>>> quo is >>>> the >>>>> only reasonable outcome. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Not being JSON >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> This was by design, so that the results are URL-safe. This = is >>>> required, >>>>> for instance, for them to be used as OAuth Bearer Tokens. At the=20= >>>>> request >>>> of >>>>> the working group, closely related pure-JSON drafts were also = published. >>>>> See: >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json >>>>>>>>>> -seri >>>>>>=20 >>>>>>>>>> alization-01 and >>>>>>=20 >>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-jso >>>>>>>>>> n-ser >>>>>>=20 >>>>>>>>>> ialization-01 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Use them if you prefer if they better suit your use cases. =20= >>>>>>>>>> They >>>> could >>>>> be adopted as working group documents, if there's interest. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> See above. These are super-clunky, and the need to be the = main >>>>> focus of the WG, not an afterthought. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Not supporting multiple recipients >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> The JSON serialization drafts above do, again, in response to=20= >>>>>>>>>> use >>>>> cases presented by the working group. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> See above. Because of the unnecessary inclusion of the header=20= >>>>>>>>> in >>>> the >>>>> integrity check, this is far less efficient than it should be. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Functionally, these are very similar operations, at least = from=20 >>>>>>>>>> an >>>>> implementation perspective, so it's not clear that making a clear >>>> distinction >>>>> would help either developers or adoption in any practical way. =20 >>>>> They >>>> achieve >>>>> overlapping, but admittedly sometimes different goals. I believe=20= >>>>> that developers can be trusted to use the algorithms that achieve=20= >>>>> their applications' goals without making a hard distinction = between the two. >>>> But >>>>> I'd be interested in hearing your thoughts on why you believe a >>>> brighter-line >>>>> distinction might be useful or necessary. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> It's important if you want to do MACs with anything other than=20= >>>>>>>>> pre- >>>>> shared keys. If you want to do anything more advanced, you need = to=20 >>>>> have wrapped keys, in which case an object with a MAC starts to=20 >>>>> look a lot more like a JWE than a JWS. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>=20 >>>>>>>>>> establishment modalities >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> This seems like an area where the existing drafts could be=20 >>>>>>>>>> refined >>>> to >>>>> add descriptions for additional establishment modalities, possibly=20= >>>>> based upon your ideas and descriptions, should the working group=20= >>>>> decide to do >>>> so. >>>>> What additional modalities do you have use cases for that you=20 >>>>> believe are not achievable or straightforward with the existing=20 >>>>> drafts? The existing modalities supported are largely those that=20= >>>>> existing developers had told >>>> us >>>>> they needed and draw both from the precursor = draft-jones-json-web-*=20 >>>>> documents and draft-rescorla-jsms. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Bear in mind that the balance that the current drafts try to=20= >>>>>>>>>> strike >>>> is >>>>> keeping the Mandatory to Implement (MTI) feature footprint small=20= >>>>> enough that developers, including Web developers, are likely to=20 >>>>> adopt the specs, while still providing enough functionality to = make them generally useful. >>>> As >>>>> in any balance, it's often possible to shift things a bit and = still >>>> maintain the >>>>> balance, but I'd like people to keep the ubiquitous adoption goal >>>> front-and- >>>>> center when proposing additional functionality. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>=20 >>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>>>>=20 >>>>>>>>>> that!) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I agree that we need to find a reasonable MTI. The current=20 >>>>>>>>> JSMS >>>> draft >>>>> doesn't really specify which parts are MTI, beyond basic things=20 >>>>> like >>>> base64url >>>>> encoding and ignoring unknown fields. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> My main concern is that JWS and JWE don't really tell me which >>>> fields >>>>> need to be present for which use case. If I'm putting a MAC on a = JWS vs. >>>> a >>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>> Whereas in >>>> JSMS, >>>>> I think these things are much clearer due to the separation of the=20= >>>>> use >>>> cases >>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures=20= >>>>> and wrapped keys into sub-objects. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lack of clear typing of objects >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Most JSON documents aren't clearly typed; instead, developers=20= >>>>>>>>>> and >>>>> implementations understand from context what the meaning of each = field is. >>>>> XML is clearly typed, but developers are voting with their feet by=20= >>>>> moving >>>> to >>>>> JSON. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> What practical advantages resulting from overlaying a typing >>>>> infrastructure on JSON do you believe are worth the potential = costs=20 >>>>> of >>>> doing >>>>> so? BTW, I'm not opposed to having a JSON schema description of=20= >>>>> the JOSE JSON data structures like JSMS did in=20 >>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, but=20= >>>>> I'll remark that this an informative >>>> tool, not >>>>> a normative one. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I actualy don't have a hugely urgent requirement here either. =20= >>>>>>>>> It's >>>>> something that others in the WG had requested, which is trivial to=20= >>>>> add in JSMS, but not in JWE/JWS -- again because of the = unnecessary=20 >>>>> integrity protection of the header. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> An optional version field could be added if the working group >>>>>>=20 >>>>>>>>>> desires, however the last time the working group discussed = it,=20 >>>>>>>>>> they >>>>>>=20 >>>>>>>>>> decided not to do so. Rather, specs like this effectively=20 >>>>>>>>>> become >>>>>>=20 >>>>>>>>>> "versioned" when revised in a way that new fields are added. =20= >>>>>>>>>> If >>>>>>=20 >>>>>>>>>> you understand the new fields, you support that new version. =20= >>>>>>>>>> (Note >>>>>>=20 >>>>>>>>>> that this is independent of whether there is a version number >>>>>>=20 >>>>>>>>>> field, which according to some participants in the previous >>>>>>=20 >>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>=20 >>>>>>>>>> information.) >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> I'm not religious about not having a version number field, = but >>>> often >>>>> "less is more". >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Indeed, I'm not religious either. It just seems like a = general=20 >>>>>>>>> good >>>> idea >>>>> to state this directly as opposed to having parsers divine it = based=20 >>>>> on >>>> which >>>>> fields are present. To quote RFC 5652: >>>>>>=20 >>>>>>>>> " >>>>>>=20 >>>>>>>>> Each of the major data structures includes a version number as=20= >>>>>>>>> the >>>>>>=20 >>>>>>>>> first item in the data structure. The version numbers are=20 >>>>>>>>> intended >>>>>>=20 >>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20 >>>>>>>>> check >>>>> the >>>>>>=20 >>>>>>>>> version number prior to attempting a decode, and if a decode=20= >>>>>>>>> error >>>>>>=20 >>>>>>>>> occurs, then the version number is checked as part of the = error >>>>>>=20 >>>>>>>>> handling routine. This is a reasonable approach; it places=20 >>>>>>>>> error >>>>>>=20 >>>>>>>>> processing outside of the fast path. This approach is also >>>>>>=20 >>>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>>=20 >>>>>>>>> " >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Best, >>>>>>=20 >>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Best wishes, >>>>>>=20 >>>>>>>>>> -- Mike >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>=20 >>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>=20 >>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>=20 >>>>>>>>>> To: Mike Jones >>>>>>=20 >>>>>>>>>> Cc: jose@ietf.org >>>>>>=20 >>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>=20 >>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. =20= >>>>>>>>>> IMO, >>>> the >>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>=20 >>>>>>>>>> -- Not being JSON >>>>>>=20 >>>>>>>>>> -- Not supporting multiple recipients >>>>>>=20 >>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>=20 >>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>=20 >>>>>>>>>> establishment modalities >>>>>>=20 >>>>>>>>>> -- Lack of clear typing of objects >>>>>>=20 >>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20 >>>>>>>>>> would be >>>>> simple to adapt them to address these deficiencies. So I just did=20= >>>>> a >>>> re-write. >>>>> If you think they can be addressed within the current framework,=20= >>>>> please explain. I just found it simpler to start from whole = cloth. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Cheers, >>>>>>=20 >>>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Hi Richard, >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>>> documents, >>>>> I encourage you to ask about them on the list. The documents have=20= >>>>> significant history going back to mid-2010 when convergence=20 >>>>> discussions started among people with four different JSON signing = &=20 >>>>> encryption proposals. JWT and the current JOSE specs and=20 >>>>> implementations are the result. I realize that not all the JOSE=20= >>>>> participants were part of those discussions from the beginning=20 >>>>> (although many were) and so teasing out the rationale for specific=20= >>>>> decisions might help people better understand the choices made, = and=20 >>>>> hopefully thereby increase consensus behind the eventual working = group choices. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 >>>>>>>>>>> below, >>>> maybe we >>>>> can start a discussion on that basis. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Best wishes, >>>>>>=20 >>>>>>>>>>> -- Mike >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>=20 >>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On >>>>>>=20 >>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>=20 >>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>=20 >>>>>>>>>>> To: jose@ietf.org >>>>>>=20 >>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>=20 >>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Dear JOSE WG, >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>> thorough >>>>> review of the JW* specs, I was kind of puzzled by some of the=20 >>>>> design decisions. So I also went through and wrote an alternative=20= >>>>> format, this >>>> time >>>>> taking a more of a cue from CMS. A link to the document is below. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Summary of differences: >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>>>=20 >>>>>>>>>>> parameters are represented in JSON. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS allows for full algorithm agility in key agreement,=20= >>>>>>>>>>> while >>>> JWE >>>>>>=20 >>>>>>>>>>> only allows ECDH-ES. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>>=20 >>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>> WrappedKey >>>>>>=20 >>>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>>>=20 >>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o The signature and MAC functions of the JWS object are=20 >>>>>>>>>>> separated >>>>>>=20 >>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS parameters are not integrity-protected, as they are=20= >>>>>>>>>>> in JWE >>>>>>=20 >>>>>>>>>>> and JWS. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS,=20= >>>>>>>>>>> but >>>> could >>>>>>=20 >>>>>>>>>>> be added without significant change. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>>>=20 >>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>> implementation >>>> (based >>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>=20 >>>>>>>>>>> >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Comments are very welcome. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>=20 >>>>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Begin forwarded message: >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>=20 >>>>>>>>>>>> Subject: New Version Notification for >>>>>>=20 >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>=20 >>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has = been >>>>>>=20 >>>>>>>>>>>> successfully submitted by Richard Barnes and posted to the=20= >>>>>>>>>>>> IETF >>>>>>=20 >>>>>>>>>>>> repository. >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>=20 >>>>>>>>>>>> Revision: 00 >>>>>>=20 >>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>=20 >>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>=20 >>>>>>>>>>>> WG ID: Individual Submission >>>>>>=20 >>>>>>>>>>>> Number of pages: 25 >>>>>>=20 >>>>>>>>>>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>> jsms-00.txt >>>>>>=20 >>>>>>>>>>>> Status: >>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>=20 >>>>>>>>>>>> Htmlized: >>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> Abstract: >>>>>>=20 >>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>> cryptographically >>>>>>=20 >>>>>>>>>>>> secured messages. While the IETF has defined a number of >>>>> formats >>>>>>=20 >>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings=20= >>>>>>>>>>>> which >>>>>>=20 >>>>>>>>>>>> are not easy to use in modern applications. This document >>>>>>=20 >>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a=20= >>>>>>>>>>>> new >>>>>>=20 >>>>>>>>>>>> cryptographic message format which is based on JavaScript=20= >>>>>>>>>>>> Object >>>>>>=20 >>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>>> generate >>>>> and parse. >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> The IETF Secretariat >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 >=20 >=20 --Apple-Mail=_F17FD3F5-8ECC-49B1-8035-AD718C2B7AC6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjIwNTg1NVowIwYJKoZIhvcNAQkEMRYEFJsXGmLDQu9sPDLrLgDEPxPK8Jb7MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJwsrlIOW+Jmn5moEWfML066hfjl/mZSPnNG6JQoVyQaMHQisRkLx8PRMLcwsPC30i0X86/5RJVe qZ2dP8TUqP07wcVloaVkJBHM5zcEleI6ubnWvHyb7aoU0QMNk1uBLQCqIXpjk+mBOs4YLQPXkJmU iliTnDn++HPmkpifC46bVIukJnMrACZN0j4ZHLyERUmKt22EoHuQKxsdV8boFqdjwlzJ6ueawm7m kqS8LJVM8Qa6d1JG8jEILCzDO+eVPZnA85J8WBVgLtOG/Yo83NmO2ooncS1OvPKYCcPMnX/xEFVP AAHmk+3s5rrr5MAV7InnvNMb6P3VX9CGFp7bD/wAAAAAAAA= --Apple-Mail=_F17FD3F5-8ECC-49B1-8035-AD718C2B7AC6-- From tonynad@microsoft.com Tue Jun 26 14:04: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 ABD1A11E80E5 for ; Tue, 26 Jun 2012 14:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVKgfUNnZmn3 for ; Tue, 26 Jun 2012 14:04:17 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 003FC11E80E2 for ; Tue, 26 Jun 2012 14:04:15 -0700 (PDT) Received: from mail71-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 21:02:33 +0000 Received: from mail71-db3 (localhost [127.0.0.1]) by mail71-db3-R.bigfish.com (Postfix) with ESMTP id 803BE26015F for ; Tue, 26 Jun 2012 21:02:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zz98dI9371I936eI168aJ148cI542M1432I1418I41c5N4015Izz1202h1082kzz1033IL8275eh8275bh8275dh5eeeKf73b6ila1495iz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail71-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail71-db3 (localhost.localdomain [127.0.0.1]) by mail71-db3 (MessageSwitch) id 1340744550556778_9452; Tue, 26 Jun 2012 21:02:30 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.240]) by mail71-db3.bigfish.com (Postfix) with ESMTP id 85CBD2A0043 for ; Tue, 26 Jun 2012 21:02:30 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 21:02:30 +0000 Received: from CH1EHSOBE001.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 26 Jun 2012 21:03:54 +0000 Received: from mail137-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 21:01:26 +0000 Received: from mail137-ch1 (localhost [127.0.0.1]) by mail137-ch1-R.bigfish.com (Postfix) with ESMTP id E0A312C00BD for ; Tue, 26 Jun 2012 21:01:25 +0000 (UTC) Received: from mail137-ch1 (localhost.localdomain [127.0.0.1]) by mail137-ch1 (MessageSwitch) id 1340744483797303_15331; Tue, 26 Jun 2012 21:01:23 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail137-ch1.bigfish.com (Postfix) with ESMTP id B6358C0043; Tue, 26 Jun 2012 21:01:23 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 21:01:21 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0152.000; Tue, 26 Jun 2012 21:03:02 +0000 From: Anthony Nadalin To: John Bradley Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: AQHNU96/DZ1HoM6Ltk6I6tgeV6YnlJcNFizg Date: Tue, 26 Jun 2012 21:03:02 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> In-Reply-To: <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%BBN.COM$RO%2$TLS%6$FQDN%131.107.125.5$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: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "Richard L. Barnes" , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:04:19 -0000 AES-ECB is also a popular alternative -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Tuesday, June 26, 2012 1:59 PM To: Anthony Nadalin Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt Yes that is why we added the composite HMAC + AES-CBC. We can debate if t= hat is an algorithm or mandatory integrity with non AEAD algorithms, but th= e effect of integrity protecting the header remains in both cases. John B. On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: > Not sure there was a WG decision and what that would mean if there was, a= s there are many libraries out there that don't support the encryption with= integrity algorithms, so need to support alternative means of things like = key wrap that could have an integrity check. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of J= ohn Bradley > Sent: Tuesday, June 26, 2012 12:30 PM > To: Richard L. Barnes > Cc: Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-0= 0.txt >=20 > There was a WG decision to not allow encryption without integrity. Jim = and others call that sender verification. >=20 > Or on simple terms no AES-CBC without a mandatory MAC integrity. >=20 > The JWE/JWS specs don't control the body. That is intended to be arbitr= ary content. >=20 > We do have s JWT spec that covers the body for security tokens. The ide= a was to separate that from signing and encryption so that signing and encr= yption can be used for other objects. >=20 > John B. >=20 > On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >=20 >>> Now that we are mandating JWE sender verification people will be using = JWE with symmetric keys or key agreement. >>> In those cases one can easily argue that the header should be protected= as much as in HMAC. >>=20 >> Can you clarify the scope of "we are mandating"? >>=20 >>=20 >>> There may well be signing_time or other elements that would go into the= header as well for JWE. >>=20 >> Why do these need to go into the header rather than the body? >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>> Regards >>> John B. >>>=20 >>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>=20 >>>> >>>>=20 >>>> Richard, >>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>> Behalf Of Richard L. Barnes >>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>> To: Nat Sakimura >>>>> Cc: Mike Jones; jose@ietf.org >>>>> Subject: Re: [jose] New Version Notification for=20 >>>>> draft-barnes-jose-jsms- 00.txt >>>>>=20 >>>>> Hi Nat, >>>>>=20 >>>>> I'm not sure what X.509 fiasco you're referring to. There was a=20 >>>>> recent >>>> MD5 >>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, there=20 >>>>> have >>>> been >>>>> recommendations for preventing this attack in X.509 since 2005 [2]. = =20 >>>>> As >>>> was >>>>> noted on the SAAG list, the real news here is that Microsoft wasn't >>>> following >>>>> any of those recommendations. >>>>>=20 >>>>> JWS would have had the same problem as X.509. The attack did not=20 >>>>> modify the cryptographic parameters (anything that would have gone=20 >>>>> in the header), it would not have been thwarted by the integrity=20 >>>>> protection we're worrying about. >>>>>=20 >>>>> Actually, the header signing that JWS does makes it even nicer for=20 >>>>> the >>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20 >>>>> header >>>> value >>>>> is entirely static for a given signer, it's easy to use as a fixed pr= efix. >>>> If JWS just >>>>> signed the content, then the application could include a something=20 >>>>> random up front to prevent such prefix-based attacks. >>>>>=20 >>>>=20 >>>> I don't believe that this is a true statement. If you had a prefix=20 >>>> or just signed what was given to you (i.e. no prefix), it would make=20 >>>> no difference in terms of the attack for Flame. Flame could always=20 >>>> use a fixed prefix of its own design rather than using the fixed=20 >>>> header that is generated by having JWS sign the header information. >>>>=20 >>>>> It's tempting to say that we should just add randomness to the JOSE >>>> format. >>>>> But the real lesson of the Flame/MD5 attacks is operational: If=20 >>>>> you're >>>> signing >>>>> something that somebody else gave you, make sure that you're not=20 >>>>> signing exactly what they gave you. Follow the recommendations of=20 >>>>> RFC 4270. In other contexts, there's no need of similar random=20 >>>>> elements; it just adds complexity. >>>>=20 >>>> This is definitely a true statement in all events and is something=20 >>>> that should be added to the Security Considerations section. >>>>=20 >>>> That being said, I think that there are valid reasons for wanting to=20 >>>> protect the header information by some authentication processing. =20 >>>> PKIX certificates protect the signature algorithm information (by=20 >>>> copying the data into the to be signed block) and CMS has long=20 >>>> allowed for information to be included in the signed attributes area=20 >>>> that identifies the algorithms used, the certificates used and so=20 >>>> forth. There are also other things that we might find to be=20 >>>> convenient to be placed in the header information that is current=20 >>>> not there (a signing time and embedded content type comes to mind)=20 >>>> that would be a product either of specific types of signatures or beco= mes a common attribute to be placed there. >>>>=20 >>>> In terms of encryption operations, I remember in the past that I=20 >>>> have had either corrupted encrypted streams or corrupted IVs and had=20 >>>> a successful decryption that later generated other problems when=20 >>>> trying to parse. This is less of an issue with AEAD algorithms as=20 >>>> they have a much stricter rule on when the stream decrypts correctly. >>>>=20 >>>> Jim >>>>=20 >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> [1] >>>>> [2] >>>>>=20 >>>>>=20 >>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>=20 >>>>>> Especially after the X.509 fiasco, I strongly believe that having >>>> integrity >>>>> check over the metadata is a good thing. It is such a little effort=20 >>>>> that >>>> gives us >>>>> much more protection down the road. In this sense, I fully agree=20 >>>>> with Ben here. We should have integrity protection over the header. >>>>>>=20 >>>>>> Nat >>>>>>=20 >>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>> wrote: >>>>>> Two years ago when the developer community needing a JSON-friendly >>>>> token format was designing the JSON Web Token (JWT), we explicitly=20 >>>>> asked security experts whether the header parameters should be=20 >>>>> integrity protected or not. Among them, Ben Laurie was one of the=20 >>>>> voices saying >>>> that >>>>> securing them was the right thing to do. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> He argued that if the parameters can be protected in a practical=20 >>>>>> manner, >>>>> then they should. Doing so provides an additional hurdle that=20 >>>>> attackers would have to surmount. For example, if they can try to=20 >>>>> substitute a >>>> weaker >>>>> authentication scheme, then they must figure out how to make it=20 >>>>> authenticate correctly despite some plaintext they can't control -=20 >>>>> the >>>> header >>>>> parameters. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Ben also took the position that paring security protocols down to=20 >>>>>> the >>>> least >>>>> you can get away with, given attacks you can think of, is not a=20 >>>>> good >>>> design >>>>> principle. If there is not a strong argument against including a=20 >>>>> feature >>>> that >>>>> may make it harder for attackers, then that feature should be include= d. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I agree with him. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The decision to provide integrity protection for the headers is >>>> documented >>>>> in the session notes at http://self-issued.info/?p=3D361, which said: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> . What to sign (envelope.payload or just payload)? >>>>>>=20 >>>>>> Given that the envelope is extensible and therefore may contain >>>> security- >>>>> sensitive information, we reached a consensus (with input from Ben=20 >>>>> Laurie via IM) that the combination envelope.payload must be signed. >>>>>>=20 >>>>>>=20 >>>>>> I believe that logic is as sound today as it was then. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>> community's >>>>> decision to provide integrity protection for the headers. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best=20 >>>>>> wishes, >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>> Behalf Of >>>>> John Bradley >>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>> To: Richard L.Barnes >>>>>> Cc: jose@ietf.org >>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>> draft-barnes-jose-jsms- >>>>> 00.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi Richard, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding=20 >>>>>> and not >>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>=20 >>>>>> There are possible hash truncation attacks by shortening SHA256 to >>>> SHA224 >>>>> as an example (I know we preclude truncated hashes at the moment). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The bad feeling I get around this is that if there is a scenario=20 >>>>>> where >>>> the >>>>> attacker controls the plaintext to be signed and there is no signer >>>> controlled >>>>> text contributed there are potential bad things that could happen=20 >>>>> down the road. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This bit us with x509 certs not that long ago (yes with MD5=20 >>>>>> admittedly) >>>>> where the attacker could use a certificate extension to include=20 >>>>> extra data >>>> and >>>>> cause a pre collided hash to be generated. >>>>>>=20 >>>>>> Having part of the signed data outside the control of an attacker=20 >>>>>> is a >>>> good >>>>> thing. (having a nonce or message ID in the envelope is possible=20 >>>>> though >>>> not >>>>> yet required in JWS.) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I am still of the opinion that putting the base64 encoded envelope >>>> inside >>>>> the hash calculation is a valid way to allow additional attributes. >>>>>>=20 >>>>>> Another structure to hold the attributes adds more complexity, as=20 >>>>>> would >>>>> saying that they need to be inside the signed object. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I think part of this is that as one of the openID Connect authors=20 >>>>>> I look >>>> at this >>>>> as a necessary security token format, for OAuth and Connect. >>>>>>=20 >>>>>> For that simple processing with one signature is a high priority=20 >>>>>> for >>>> adoption. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From a general signing/encrypting of documents point of view you >>>>> legitimately have different priorities. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I know it is hard to prove a negative but It is also going to be >>>> difficult for me >>>>> to go back to security people at google Facebook and other places=20 >>>>> and explain how not integrity protecting the header could be better=20 >>>>> than integrity protecting it. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> It seems that I would be reduced to arguing that this is no worse=20 >>>>>> than >>>> CMS >>>>> and that hasn't been proven insecure yet. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Allowing a possible attacker to control the hash output, and not >>>> integrity >>>>> protecting the additional data, seems like something I am bound to=20 >>>>> regret >>>> in >>>>> the future. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Hey John, >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Interesting points, but I don't think they actually apply here. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to downgrade attacks: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> The attack that RFC 5752 is concerned with is when an attacker=20 >>>>>>> strips >>>>> signatures from a signed message, so that the only ones left are=20 >>>>> ones he >>>> can >>>>> tamper with. So the integrity protection here is "horizontal"; it=20 >>>>> goes >>>> across >>>>> signatures. The integrity protection in JWS/JWE is "vertical" --=20 >>>>> it only >>>> protects >>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "brown bag" attacks: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> The root of this attack is ambiguity about what content is=20 >>>>>>> *signed* >>>>>>=20 >>>>>>> vs. what content is *used*. If an application doesn't verify=20 >>>>>>> that >>>>>>=20 >>>>>>> it's actually using the stuff that's signed, then it can be=20 >>>>>>> tricked >>>>>>=20 >>>>>>> into accepting something unsigned. (Cf. >>>>>>=20 >>>>>>> ) >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> However, I don't think any of the current proposals have that probl= em. >>>>> In JWE/JWS, the signed content is right there between the dots, and=20 >>>>> in >>>> JSMS, >>>>> it's in the "content" element. The current JSMS draft does allow=20 >>>>> detached signatures, but with a "voids your warranty" sticker on it. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> In any case, these attacks have nothing to do with whether the >>>>> cryptographic parameters are integrity-protected with the content. =20 >>>>> The example attacks in the IBM still work regardless -- the whole=20 >>>>> point of the attack is that the cryptographic processing is the=20 >>>>> same, only the >>>> (non-crypto) >>>>> matching of content is flawed. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "arbitrary attributes": >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> We can have that here, too, but you need canonicalization. And >>>> base64- >>>>> encoding is not not canonicalization -- it just waves its hands=20 >>>>> over the question of equivalence. In my opinion, we should keep=20 >>>>> the cryptographic object simple by disallowing attributes, and push=20 >>>>> the attributes you would sign inside of the thing being signed. If=20 >>>>> people really do want >>>> attributes, it >>>>> doesn't seem to me like JSON canonicalization is very hard. I can=20 >>>>> do it >>>> in 19 >>>>> lines of python: >>>>>>=20 >>>>>>> >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard too "meta-data in the body": >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> It seems to me like if we're trying to define a general format=20 >>>>>>> for >>>> applying >>>>> security protections, then we ought to keep out things that aren't >>>> strictly >>>>> security relevant. Those things can go in application-specific=20 >>>>> content >>>> types >>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> With regard to "defense in depth" and selling this to government >>>>> agencies: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> CMS, via S/MIME, is in broad use across multiple federal agencies=20 >>>>>>> and >>>>> large enterprises. JSMS is essentially a profile of CMS (see=20 >>>>> Section 7), >>>> and >>>>> has the same security properties. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Cheers, >>>>>>=20 >>>>>>> --Richard >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>> Hi Richard, >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Originally we only integrity protected the header for signing. =20 >>>>>>>> We >>>> added >>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>> encryption can >>>> also >>>>> be used for sender verification. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I understand the argument that it makes things simpler if we=20 >>>>>>>> don't >>>>> integrity protect the header information. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> However xmldsig, provides integrity over those elements to=20 >>>>>>>> prevent >>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> CMS may not typically provide that integrity protection but I=20 >>>>>>>> think >>>> Jim >>>>> Schaad and Sean Terner created RFC5752 to address downgrade attacks. >>>>>>=20 >>>>>>>> Given they are on this list they can speak to their view on=20 >>>>>>>> integrity >>>> over >>>>> the crypto parameters. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>> Carlo/Brown >>>>> Bag attack that needs to be considered if we move to something more=20 >>>>> like a detached signature. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> The other design consideration is that we wanted to be able to=20 >>>>>>>> sign >>>>> arbitrary byte strings not just JSON. You could sign XML if you wan= ted. >>>>>>=20 >>>>>>>> That prevented us from including meta-data in the body as we=20 >>>>>>>> didn't >>>>> want to touch it. That left us with the header to include additiona= l >>>> elements >>>>> in. >>>>>>=20 >>>>>>>> Not integrity protecting those elements as well would be a problem= . >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>> arbitrary >>>>> attributes not unlike the current JOSE spec. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Especially for something that will be used with JWT security=20 >>>>>>>> tokens I >>>> will >>>>> have a hard time making the argument to NIST and others that need=20 >>>>> to approve this format that not integrity protecting the header=20 >>>>> parameters is appropriate defence in depth, for something that=20 >>>>> might be replacing signed SAML assertions in some applications. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> I do understand how not integrity protecting the header will=20 >>>>>>>> make >>>> some >>>>> things easier, however I can't agree that the benefit outweighs the=20 >>>>> disadvantages. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> Regards >>>>>>=20 >>>>>>>> John B. >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>>> Hey Mike, >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Thanks for having some back-and-forth with me on this. I think=20 >>>>>>>>> this >>>> is a >>>>> good discussion to have right now. I would like to discuss some >>>> high-level >>>>> points, and then I'll respond inline to your precise points. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 >>>>>>>>> define >>>> JSON- >>>>> based formats for integrity and confidentiality protections. JWE=20 >>>>> and JWS don't fit that requirement, so we should re-consider their=20 >>>>> adoption and >>>> call >>>>> for new candidates. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Major points: >>>>>>=20 >>>>>>>>> 1. JOSE is JSON >>>>>>=20 >>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>=20 >>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 1: JOSE is JSON >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> The JOSE WG charter calls out four deliverables, three of which=20 >>>>>>>>> are >>>>> explicitly required to be JSON: >>>>>>=20 >>>>>>>>> -- "JSON-structured integrity protection" >>>>>>=20 >>>>>>>>> -- "JSON-structured encryption" >>>>>>=20 >>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>=20 >>>>>>>>> (The fourth is just a list of algorithms, which should be JSON=20 >>>>>>>>> as >>>>>>=20 >>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20 >>>>>>>>> suitable >>>>>>=20 >>>>>>>>> candidates to fulfill the working group's milestones. (At=20 >>>>>>>>> least in >>>>>>=20 >>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>=20 >>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>> especially >>>>>>=20 >>>>>>>>> the first two. (JWK is not as far off.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20 >>>>>>>>> drafts >>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>> cryptographic parameters within the integrity protection, they have=20 >>>>> to have the headers included as base64-encoded strings. That=20 >>>>> obviously adds a lot of >>>> complexity >>>>> to encoding and decoding -- for example, you have to keep the=20 >>>>> encoded header around even after you've decoded it! -- and just plain= more octets. >>>>> The support for multiple recipients and multiple signatures is both >>>> unweildy >>>>> (matching up parallel indices for headers and signatures) and=20 >>>>> inefficient (multiple integrity check values in encrypted objects). >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom=20 >>>>>>>>> that >>>>> went into CMS, while making the syntax pure JSON and as simple as >>>> possible. >>>>> Multiple signatures and multiple recipients are supported with=20 >>>>> absolute minimum overhead. So I think it's worth consideration by=20 >>>>> the working >>>> group. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>> requires >>>>>>=20 >>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>=20 >>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>> included >>>>>>=20 >>>>>>>>> within the integrity protection. I'm not aware of any reason=20 >>>>>>>>> for >>>>>>=20 >>>>>>>>> including the cryptographic parameters in the integrity check, >>>>>>=20 >>>>>>>>> instead of only integrity-protecting the content itself. =20 >>>>>>>>> Indeed, if >>>>>>=20 >>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>> cryptographic >>>>>>=20 >>>>>>>>> parameters, it would be a pretty big deal, since neither CMS=20 >>>>>>>>> nor IKE >>>>>>=20 >>>>>>>>> nor provides this protection. (TLS does provide a signature=20 >>>>>>>>> over >>>>>>=20 >>>>>>>>> the algorithms, but only as a way to bind the public key to the >>>>>>=20 >>>>>>>>> session.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Indeed CMS doesn't require canonicalization at all, except for >>>>> attributes that are included in the protected content (signedAttrs=20 >>>>> / authenticatedAttrs), which need to be DER-encoded. In JSMS, we=20 >>>>> don't allow those parameters, so there is no need for canonicalizatio= n at all. >>>> All the >>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>> protected content. In that regard, JSMS is even simpler than JWE/JWS= . >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>> derivatives >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I have absolutely no objection to defining a compact, URL-safe >>>> format. >>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20 >>>>> example >>>> from >>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> { >>>>>>=20 >>>>>>>>> "v":1, >>>>>>=20 >>>>>>>>> "t":"au", >>>>>>=20 >>>>>>>>> "a":"hs256", >>>>>>=20 >>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>=20 >>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>=20 >>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>=20 >>>>>>>>> } >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20 >>>>>>>>> only >>>>> use >>>>>>=20 >>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step >>>>>>=20 >>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>> AuthenticatedData, >>>>>>=20 >>>>>>>>> we can emulate JWS by moving the content and MAC fields outside >>>>> and >>>>>>=20 >>>>>>>>> dot-combining. That avoids double-base64url-encoding, and only >>>>>>=20 >>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put the=20 >>>>>>>>> code >>>>>>=20 >>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>> objective, >>>> but it >>>>> makes *much* more sense to derive that from a full-size, usable,=20 >>>>> JSON format than the other way around. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Responses to specific points inline below. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before=20 >>>>>>>>>> doing >>>> so, I'll >>>>> say that I'm writing in the spirit of trying to increase mutual >>>> understanding >>>>> and consensus, rather than taking the point of view that the status=20 >>>>> quo is >>>> the >>>>> only reasonable outcome. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Not being JSON >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> This was by design, so that the results are URL-safe. This is >>>> required, >>>>> for instance, for them to be used as OAuth Bearer Tokens. At the=20 >>>>> request >>>> of >>>>> the working group, closely related pure-JSON drafts were also publish= ed. >>>>> See: >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json >>>>>>>>>> -seri >>>>>>=20 >>>>>>>>>> alization-01 and >>>>>>=20 >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-jso >>>>>>>>>> n-ser >>>>>>=20 >>>>>>>>>> ialization-01 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Use them if you prefer if they better suit your use cases. =20 >>>>>>>>>> They >>>> could >>>>> be adopted as working group documents, if there's interest. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> See above. These are super-clunky, and the need to be the main >>>>> focus of the WG, not an afterthought. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Not supporting multiple recipients >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> The JSON serialization drafts above do, again, in response to=20 >>>>>>>>>> use >>>>> cases presented by the working group. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> See above. Because of the unnecessary inclusion of the header=20 >>>>>>>>> in >>>> the >>>>> integrity check, this is far less efficient than it should be. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Functionally, these are very similar operations, at least from=20 >>>>>>>>>> an >>>>> implementation perspective, so it's not clear that making a clear >>>> distinction >>>>> would help either developers or adoption in any practical way. =20 >>>>> They >>>> achieve >>>>> overlapping, but admittedly sometimes different goals. I believe=20 >>>>> that developers can be trusted to use the algorithms that achieve=20 >>>>> their applications' goals without making a hard distinction between t= he two. >>>> But >>>>> I'd be interested in hearing your thoughts on why you believe a >>>> brighter-line >>>>> distinction might be useful or necessary. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> It's important if you want to do MACs with anything other than=20 >>>>>>>>> pre- >>>>> shared keys. If you want to do anything more advanced, you need to=20 >>>>> have wrapped keys, in which case an object with a MAC starts to=20 >>>>> look a lot more like a JWE than a JWS. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>=20 >>>>>>>>>> establishment modalities >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> This seems like an area where the existing drafts could be=20 >>>>>>>>>> refined >>>> to >>>>> add descriptions for additional establishment modalities, possibly=20 >>>>> based upon your ideas and descriptions, should the working group=20 >>>>> decide to do >>>> so. >>>>> What additional modalities do you have use cases for that you=20 >>>>> believe are not achievable or straightforward with the existing=20 >>>>> drafts? The existing modalities supported are largely those that=20 >>>>> existing developers had told >>>> us >>>>> they needed and draw both from the precursor draft-jones-json-web-*=20 >>>>> documents and draft-rescorla-jsms. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Bear in mind that the balance that the current drafts try to=20 >>>>>>>>>> strike >>>> is >>>>> keeping the Mandatory to Implement (MTI) feature footprint small=20 >>>>> enough that developers, including Web developers, are likely to=20 >>>>> adopt the specs, while still providing enough functionality to make t= hem generally useful. >>>> As >>>>> in any balance, it's often possible to shift things a bit and still >>>> maintain the >>>>> balance, but I'd like people to keep the ubiquitous adoption goal >>>> front-and- >>>>> center when proposing additional functionality. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>=20 >>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to understand >>>>>>=20 >>>>>>>>>> that!) >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I agree that we need to find a reasonable MTI. The current=20 >>>>>>>>> JSMS >>>> draft >>>>> doesn't really specify which parts are MTI, beyond basic things=20 >>>>> like >>>> base64url >>>>> encoding and ignoring unknown fields. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> My main concern is that JWS and JWE don't really tell me which >>>> fields >>>>> need to be present for which use case. If I'm putting a MAC on a JWS= vs. >>>> a >>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>> Whereas in >>>> JSMS, >>>>> I think these things are much clearer due to the separation of the=20 >>>>> use >>>> cases >>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures=20 >>>>> and wrapped keys into sub-objects. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lack of clear typing of objects >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Most JSON documents aren't clearly typed; instead, developers=20 >>>>>>>>>> and >>>>> implementations understand from context what the meaning of each fiel= d is. >>>>> XML is clearly typed, but developers are voting with their feet by=20 >>>>> moving >>>> to >>>>> JSON. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> What practical advantages resulting from overlaying a typing >>>>> infrastructure on JSON do you believe are worth the potential costs=20 >>>>> of >>>> doing >>>>> so? BTW, I'm not opposed to having a JSON schema description of=20 >>>>> the JOSE JSON data structures like JSMS did in=20 >>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, but=20 >>>>> I'll remark that this an informative >>>> tool, not >>>>> a normative one. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> I actualy don't have a hugely urgent requirement here either. =20 >>>>>>>>> It's >>>>> something that others in the WG had requested, which is trivial to=20 >>>>> add in JSMS, but not in JWE/JWS -- again because of the unnecessary=20 >>>>> integrity protection of the header. >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> An optional version field could be added if the working group >>>>>>=20 >>>>>>>>>> desires, however the last time the working group discussed it,=20 >>>>>>>>>> they >>>>>>=20 >>>>>>>>>> decided not to do so. Rather, specs like this effectively=20 >>>>>>>>>> become >>>>>>=20 >>>>>>>>>> "versioned" when revised in a way that new fields are added. =20 >>>>>>>>>> If >>>>>>=20 >>>>>>>>>> you understand the new fields, you support that new version. =20 >>>>>>>>>> (Note >>>>>>=20 >>>>>>>>>> that this is independent of whether there is a version number >>>>>>=20 >>>>>>>>>> field, which according to some participants in the previous >>>>>>=20 >>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>=20 >>>>>>>>>> information.) >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> I'm not religious about not having a version number field, but >>>> often >>>>> "less is more". >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Indeed, I'm not religious either. It just seems like a general=20 >>>>>>>>> good >>>> idea >>>>> to state this directly as opposed to having parsers divine it based=20 >>>>> on >>>> which >>>>> fields are present. To quote RFC 5652: >>>>>>=20 >>>>>>>>> " >>>>>>=20 >>>>>>>>> Each of the major data structures includes a version number as=20 >>>>>>>>> the >>>>>>=20 >>>>>>>>> first item in the data structure. The version numbers are=20 >>>>>>>>> intended >>>>>>=20 >>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20 >>>>>>>>> check >>>>> the >>>>>>=20 >>>>>>>>> version number prior to attempting a decode, and if a decode=20 >>>>>>>>> error >>>>>>=20 >>>>>>>>> occurs, then the version number is checked as part of the error >>>>>>=20 >>>>>>>>> handling routine. This is a reasonable approach; it places=20 >>>>>>>>> error >>>>>>=20 >>>>>>>>> processing outside of the fast path. This approach is also >>>>>>=20 >>>>>>>>> forgiving when an incorrect version number is used by the sender= . >>>>>>=20 >>>>>>>>> " >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> Best, >>>>>>=20 >>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Best wishes, >>>>>>=20 >>>>>>>>>> -- Mike >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>=20 >>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>=20 >>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>=20 >>>>>>>>>> To: Mike Jones >>>>>>=20 >>>>>>>>>> Cc: jose@ietf.org >>>>>>=20 >>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>=20 >>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. =20 >>>>>>>>>> IMO, >>>> the >>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>=20 >>>>>>>>>> -- Not being JSON >>>>>>=20 >>>>>>>>>> -- Not supporting multiple recipients >>>>>>=20 >>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>=20 >>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>=20 >>>>>>>>>> establishment modalities >>>>>>=20 >>>>>>>>>> -- Lack of clear typing of objects >>>>>>=20 >>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20 >>>>>>>>>> would be >>>>> simple to adapt them to address these deficiencies. So I just did=20 >>>>> a >>>> re-write. >>>>> If you think they can be addressed within the current framework,=20 >>>>> please explain. I just found it simpler to start from whole cloth. >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> Cheers, >>>>>>=20 >>>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Hi Richard, >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>>> documents, >>>>> I encourage you to ask about them on the list. The documents have=20 >>>>> significant history going back to mid-2010 when convergence=20 >>>>> discussions started among people with four different JSON signing &=20 >>>>> encryption proposals. JWT and the current JOSE specs and=20 >>>>> implementations are the result. I realize that not all the JOSE=20 >>>>> participants were part of those discussions from the beginning=20 >>>>> (although many were) and so teasing out the rationale for specific=20 >>>>> decisions might help people better understand the choices made, and=20 >>>>> hopefully thereby increase consensus behind the eventual working grou= p choices. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 >>>>>>>>>>> below, >>>> maybe we >>>>> can start a discussion on that basis. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Best wishes, >>>>>>=20 >>>>>>>>>>> -- Mike >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>=20 >>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>=20 >>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>=20 >>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>=20 >>>>>>>>>>> To: jose@ietf.org >>>>>>=20 >>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>=20 >>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Dear JOSE WG, >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>> thorough >>>>> review of the JW* specs, I was kind of puzzled by some of the=20 >>>>> design decisions. So I also went through and wrote an alternative=20 >>>>> format, this >>>> time >>>>> taking a more of a cue from CMS. A link to the document is below. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Summary of differences: >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header >>>>>>=20 >>>>>>>>>>> parameters are represented in JSON. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS allows for full algorithm agility in key agreement,=20 >>>>>>>>>>> while >>>> JWE >>>>>>=20 >>>>>>>>>>> only allows ECDH-ES. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>>=20 >>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>> WrappedKey >>>>>>=20 >>>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>>>=20 >>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o The signature and MAC functions of the JWS object are=20 >>>>>>>>>>> separated >>>>>>=20 >>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS parameters are not integrity-protected, as they are=20 >>>>>>>>>>> in JWE >>>>>>=20 >>>>>>>>>>> and JWS. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS,=20 >>>>>>>>>>> but >>>> could >>>>>>=20 >>>>>>>>>>> be added without significant change. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>>>=20 >>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>> implementation >>>> (based >>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>=20 >>>>>>>>>>> >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Comments are very welcome. >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>=20 >>>>>>>>>>> --Richard >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> Begin forwarded message: >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>=20 >>>>>>>>>>>> Subject: New Version Notification for >>>>>>=20 >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>=20 >>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>=20 >>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been >>>>>>=20 >>>>>>>>>>>> successfully submitted by Richard Barnes and posted to the=20 >>>>>>>>>>>> IETF >>>>>>=20 >>>>>>>>>>>> repository. >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>=20 >>>>>>>>>>>> Revision: 00 >>>>>>=20 >>>>>>>>>>>> Title: JavaScript Message Security Format >>>>>>=20 >>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>=20 >>>>>>>>>>>> WG ID: Individual Submission >>>>>>=20 >>>>>>>>>>>> Number of pages: 25 >>>>>>=20 >>>>>>>>>>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>> jsms-00.txt >>>>>>=20 >>>>>>>>>>>> Status: >>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>=20 >>>>>>>>>>>> Htmlized: >>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> Abstract: >>>>>>=20 >>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>> cryptographically >>>>>>=20 >>>>>>>>>>>> secured messages. While the IETF has defined a number of >>>>> formats >>>>>>=20 >>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings=20 >>>>>>>>>>>> which >>>>>>=20 >>>>>>>>>>>> are not easy to use in modern applications. This document >>>>>>=20 >>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a=20 >>>>>>>>>>>> new >>>>>>=20 >>>>>>>>>>>> cryptographic message format which is based on JavaScript=20 >>>>>>>>>>>> Object >>>>>>=20 >>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>>> generate >>>>> and parse. >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>> The IETF Secretariat >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>>=20 >>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>=20 >>>>>>>>> jose mailing list >>>>>>=20 >>>>>>>>> jose@ietf.org >>>>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 >=20 >=20 From ve7jtb@ve7jtb.com Tue Jun 26 14:07: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 B197421F851B for ; Tue, 26 Jun 2012 14:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCJQF9mKkMxZ for ; Tue, 26 Jun 2012 14:07:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8075B21F8503 for ; Tue, 26 Jun 2012 14:07:10 -0700 (PDT) Received: by yenq13 with SMTP id q13so401519yen.31 for ; Tue, 26 Jun 2012 14:07:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=zf0EgI01Duz+6o6DBBtl6ljUGeiO8PkGKfZrKUyI6l0=; b=plpK+jSZvwfvUlE/E2r85SR8UKaPR3/VgzABDZy/mzO74In1n7YdzAN0c1wlR6Dnme wSP3LZLHY3XeyZh8naaCCEBEN8ngqBEzYgYLVhb1+2bNlvvrR6vqUnsz2zs+dz/P8iwi SEHK/xN2l4zTd+RrY1Y2N9PQHhiuYmvPglBlKNbXQ5oKZPYnIYb8gMWFBdR8hURTTgeo 0fg9/GBBHCyWz/b/csk7MdCDK6lE+sIers9vhOT1BdsntRgYAGOuWHqTTOCuVwJ0B4Te vi4IwvSUgF3povZIi9GgJVdyN0gA59GVMF/CImJhs2Iadqd4g+iIxUwGQU0XxbSeKQFl F6sQ== Received: by 10.101.116.16 with SMTP id t16mr5930257anm.27.1340744829744; Tue, 26 Jun 2012 14:07:09 -0700 (PDT) Received: from [192.168.1.213] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id e5sm61348233ani.18.2012.06.26.14.07.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 14:07:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_57530A0E-7A49-411B-8245-1C6EA16B46F9"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 26 Jun 2012 17:07:02 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnjWxAi4CFhdRcb6CbB+xOcl+3vF4IdT8XvgAdTB0GIJrA1l7/c5t0Sh/bnP1geYJS6bcMo Cc: "Richard L. Barnes" , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:07:13 -0000 --Apple-Mail=_57530A0E-7A49-411B-8245-1C6EA16B46F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You should suggest adding that as a supported algorithm. We wanted to keep the core set down to a reasonable number to encourage = interoparability. AES-ECB + HMAC can be a option if the WG wants it. John B. On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote: > AES-ECB is also a popular alternative >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Tuesday, June 26, 2012 1:59 PM > To: Anthony Nadalin > Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > Yes that is why we added the composite HMAC + AES-CBC. We can debate = if that is an algorithm or mandatory integrity with non AEAD algorithms, = but the effect of integrity protecting the header remains in both cases. >=20 > John B. >=20 > On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >=20 >> Not sure there was a WG decision and what that would mean if there = was, as there are many libraries out there that don't support the = encryption with integrity algorithms, so need to support alternative = means of things like key wrap that could have an integrity check. >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of John Bradley >> Sent: Tuesday, June 26, 2012 12:30 PM >> To: Richard L. Barnes >> Cc: Jim Schaad; jose@ietf.org >> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >>=20 >> There was a WG decision to not allow encryption without integrity. = Jim and others call that sender verification. >>=20 >> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>=20 >> The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. >>=20 >> We do have s JWT spec that covers the body for security tokens. The = idea was to separate that from signing and encryption so that signing = and encryption can be used for other objects. >>=20 >> John B. >>=20 >> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>=20 >>>> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >>>> In those cases one can easily argue that the header should be = protected as much as in HMAC. >>>=20 >>> Can you clarify the scope of "we are mandating"? >>>=20 >>>=20 >>>> There may well be signing_time or other elements that would go into = the header as well for JWE. >>>=20 >>> Why do these need to go into the header rather than the body? >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>> Regards >>>> John B. >>>>=20 >>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>=20 >>>>> >>>>>=20 >>>>> Richard, >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>> Behalf Of Richard L. Barnes >>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>> To: Nat Sakimura >>>>>> Cc: Mike Jones; jose@ietf.org >>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>> draft-barnes-jose-jsms- 00.txt >>>>>>=20 >>>>>> Hi Nat, >>>>>>=20 >>>>>> I'm not sure what X.509 fiasco you're referring to. There was a=20= >>>>>> recent >>>>> MD5 >>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, = there=20 >>>>>> have >>>>> been >>>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. =20 >>>>>> As >>>>> was >>>>>> noted on the SAAG list, the real news here is that Microsoft = wasn't >>>>> following >>>>>> any of those recommendations. >>>>>>=20 >>>>>> JWS would have had the same problem as X.509. The attack did not=20= >>>>>> modify the cryptographic parameters (anything that would have = gone=20 >>>>>> in the header), it would not have been thwarted by the integrity=20= >>>>>> protection we're worrying about. >>>>>>=20 >>>>>> Actually, the header signing that JWS does makes it even nicer = for=20 >>>>>> the >>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20= >>>>>> header >>>>> value >>>>>> is entirely static for a given signer, it's easy to use as a = fixed prefix. >>>>> If JWS just >>>>>> signed the content, then the application could include a = something=20 >>>>>> random up front to prevent such prefix-based attacks. >>>>>>=20 >>>>>=20 >>>>> I don't believe that this is a true statement. If you had a = prefix=20 >>>>> or just signed what was given to you (i.e. no prefix), it would = make=20 >>>>> no difference in terms of the attack for Flame. Flame could = always=20 >>>>> use a fixed prefix of its own design rather than using the fixed=20= >>>>> header that is generated by having JWS sign the header = information. >>>>>=20 >>>>>> It's tempting to say that we should just add randomness to the = JOSE >>>>> format. >>>>>> But the real lesson of the Flame/MD5 attacks is operational: If=20= >>>>>> you're >>>>> signing >>>>>> something that somebody else gave you, make sure that you're not=20= >>>>>> signing exactly what they gave you. Follow the recommendations = of=20 >>>>>> RFC 4270. In other contexts, there's no need of similar random=20= >>>>>> elements; it just adds complexity. >>>>>=20 >>>>> This is definitely a true statement in all events and is something=20= >>>>> that should be added to the Security Considerations section. >>>>>=20 >>>>> That being said, I think that there are valid reasons for wanting = to=20 >>>>> protect the header information by some authentication processing. =20= >>>>> PKIX certificates protect the signature algorithm information (by=20= >>>>> copying the data into the to be signed block) and CMS has long=20 >>>>> allowed for information to be included in the signed attributes = area=20 >>>>> that identifies the algorithms used, the certificates used and so=20= >>>>> forth. There are also other things that we might find to be=20 >>>>> convenient to be placed in the header information that is current=20= >>>>> not there (a signing time and embedded content type comes to mind)=20= >>>>> that would be a product either of specific types of signatures or = becomes a common attribute to be placed there. >>>>>=20 >>>>> In terms of encryption operations, I remember in the past that I=20= >>>>> have had either corrupted encrypted streams or corrupted IVs and = had=20 >>>>> a successful decryption that later generated other problems when=20= >>>>> trying to parse. This is less of an issue with AEAD algorithms as=20= >>>>> they have a much stricter rule on when the stream decrypts = correctly. >>>>>=20 >>>>> Jim >>>>>=20 >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> [1] = >>>>>> [2] >>>>>>=20 >>>>>>=20 >>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>=20 >>>>>>> Especially after the X.509 fiasco, I strongly believe that = having >>>>> integrity >>>>>> check over the metadata is a good thing. It is such a little = effort=20 >>>>>> that >>>>> gives us >>>>>> much more protection down the road. In this sense, I fully agree=20= >>>>>> with Ben here. We should have integrity protection over the = header. >>>>>>>=20 >>>>>>> Nat >>>>>>>=20 >>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>> wrote: >>>>>>> Two years ago when the developer community needing a = JSON-friendly >>>>>> token format was designing the JSON Web Token (JWT), we = explicitly=20 >>>>>> asked security experts whether the header parameters should be=20 >>>>>> integrity protected or not. Among them, Ben Laurie was one of = the=20 >>>>>> voices saying >>>>> that >>>>>> securing them was the right thing to do. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> He argued that if the parameters can be protected in a practical=20= >>>>>>> manner, >>>>>> then they should. Doing so provides an additional hurdle that=20 >>>>>> attackers would have to surmount. For example, if they can try = to=20 >>>>>> substitute a >>>>> weaker >>>>>> authentication scheme, then they must figure out how to make it=20= >>>>>> authenticate correctly despite some plaintext they can't control = -=20 >>>>>> the >>>>> header >>>>>> parameters. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Ben also took the position that paring security protocols down = to=20 >>>>>>> the >>>>> least >>>>>> you can get away with, given attacks you can think of, is not a=20= >>>>>> good >>>>> design >>>>>> principle. If there is not a strong argument against including a=20= >>>>>> feature >>>>> that >>>>>> may make it harder for attackers, then that feature should be = included. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I agree with him. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The decision to provide integrity protection for the headers is >>>>> documented >>>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>=20 >>>>>>> Given that the envelope is extensible and therefore may contain >>>>> security- >>>>>> sensitive information, we reached a consensus (with input from = Ben=20 >>>>>> Laurie via IM) that the combination envelope.payload must be = signed. >>>>>>>=20 >>>>>>>=20 >>>>>>> I believe that logic is as sound today as it was then. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>>> community's >>>>>> decision to provide integrity protection for the headers. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Best=20 >>>>>>> wishes, >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>>> Behalf Of >>>>>> John Bradley >>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>> To: Richard L.Barnes >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>>> draft-barnes-jose-jsms- >>>>>> 00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Richard, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding=20= >>>>>>> and not >>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>=20 >>>>>>> There are possible hash truncation attacks by shortening SHA256 = to >>>>> SHA224 >>>>>> as an example (I know we preclude truncated hashes at the = moment). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The bad feeling I get around this is that if there is a scenario=20= >>>>>>> where >>>>> the >>>>>> attacker controls the plaintext to be signed and there is no = signer >>>>> controlled >>>>>> text contributed there are potential bad things that could happen=20= >>>>>> down the road. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> This bit us with x509 certs not that long ago (yes with MD5=20 >>>>>>> admittedly) >>>>>> where the attacker could use a certificate extension to include=20= >>>>>> extra data >>>>> and >>>>>> cause a pre collided hash to be generated. >>>>>>>=20 >>>>>>> Having part of the signed data outside the control of an = attacker=20 >>>>>>> is a >>>>> good >>>>>> thing. (having a nonce or message ID in the envelope is possible=20= >>>>>> though >>>>> not >>>>>> yet required in JWS.) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I am still of the opinion that putting the base64 encoded = envelope >>>>> inside >>>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>>=20 >>>>>>> Another structure to hold the attributes adds more complexity, = as=20 >>>>>>> would >>>>>> saying that they need to be inside the signed object. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I think part of this is that as one of the openID Connect = authors=20 >>>>>>> I look >>>>> at this >>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>=20 >>>>>>> For that simple processing with one signature is a high priority=20= >>>>>>> for >>>>> adoption. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =46rom a general signing/encrypting of documents point of view = you >>>>>> legitimately have different priorities. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I know it is hard to prove a negative but It is also going to be >>>>> difficult for me >>>>>> to go back to security people at google Facebook and other places=20= >>>>>> and explain how not integrity protecting the header could be = better=20 >>>>>> than integrity protecting it. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> It seems that I would be reduced to arguing that this is no = worse=20 >>>>>>> than >>>>> CMS >>>>>> and that hasn't been proven insecure yet. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Allowing a possible attacker to control the hash output, and not >>>>> integrity >>>>>> protecting the additional data, seems like something I am bound = to=20 >>>>>> regret >>>>> in >>>>>> the future. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Hey John, >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> Interesting points, but I don't think they actually apply here. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to downgrade attacks: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> The attack that RFC 5752 is concerned with is when an attacker=20= >>>>>>>> strips >>>>>> signatures from a signed message, so that the only ones left are=20= >>>>>> ones he >>>>> can >>>>>> tamper with. So the integrity protection here is "horizontal"; = it=20 >>>>>> goes >>>>> across >>>>>> signatures. The integrity protection in JWS/JWE is "vertical" --=20= >>>>>> it only >>>>> protects >>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to "brown bag" attacks: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> The root of this attack is ambiguity about what content is=20 >>>>>>>> *signed* >>>>>>>=20 >>>>>>>> vs. what content is *used*. If an application doesn't verify=20= >>>>>>>> that >>>>>>>=20 >>>>>>>> it's actually using the stuff that's signed, then it can be=20 >>>>>>>> tricked >>>>>>>=20 >>>>>>>> into accepting something unsigned. (Cf. >>>>>>>=20 >>>>>>>> ) >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> However, I don't think any of the current proposals have that = problem. >>>>>> In JWE/JWS, the signed content is right there between the dots, = and=20 >>>>>> in >>>>> JSMS, >>>>>> it's in the "content" element. The current JSMS draft does allow=20= >>>>>> detached signatures, but with a "voids your warranty" sticker on = it. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> In any case, these attacks have nothing to do with whether the >>>>>> cryptographic parameters are integrity-protected with the = content. =20 >>>>>> The example attacks in the IBM still work regardless -- the whole=20= >>>>>> point of the attack is that the cryptographic processing is the=20= >>>>>> same, only the >>>>> (non-crypto) >>>>>> matching of content is flawed. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to "arbitrary attributes": >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> We can have that here, too, but you need canonicalization. And >>>>> base64- >>>>>> encoding is not not canonicalization -- it just waves its hands=20= >>>>>> over the question of equivalence. In my opinion, we should keep=20= >>>>>> the cryptographic object simple by disallowing attributes, and = push=20 >>>>>> the attributes you would sign inside of the thing being signed. = If=20 >>>>>> people really do want >>>>> attributes, it >>>>>> doesn't seem to me like JSON canonicalization is very hard. I = can=20 >>>>>> do it >>>>> in 19 >>>>>> lines of python: >>>>>>>=20 >>>>>>>> >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard too "meta-data in the body": >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> It seems to me like if we're trying to define a general format=20= >>>>>>>> for >>>>> applying >>>>>> security protections, then we ought to keep out things that = aren't >>>>> strictly >>>>>> security relevant. Those things can go in application-specific=20= >>>>>> content >>>>> types >>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to "defense in depth" and selling this to = government >>>>>> agencies: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> CMS, via S/MIME, is in broad use across multiple federal = agencies=20 >>>>>>>> and >>>>>> large enterprises. JSMS is essentially a profile of CMS (see=20 >>>>>> Section 7), >>>>> and >>>>>> has the same security properties. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> Cheers, >>>>>>>=20 >>>>>>>> --Richard >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Hi Richard, >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Originally we only integrity protected the header for signing. = =20 >>>>>>>>> We >>>>> added >>>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>>> encryption can >>>>> also >>>>>> be used for sender verification. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I understand the argument that it makes things simpler if we=20= >>>>>>>>> don't >>>>>> integrity protect the header information. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> However xmldsig, provides integrity over those elements to=20 >>>>>>>>> prevent >>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> CMS may not typically provide that integrity protection but I=20= >>>>>>>>> think >>>>> Jim >>>>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>>>=20 >>>>>>>>> Given they are on this list they can speak to their view on=20 >>>>>>>>> integrity >>>>> over >>>>>> the crypto parameters. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>>> Carlo/Brown >>>>>> Bag attack that needs to be considered if we move to something = more=20 >>>>>> like a detached signature. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> The other design consideration is that we wanted to be able to=20= >>>>>>>>> sign >>>>>> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>>>>>=20 >>>>>>>>> That prevented us from including meta-data in the body as we=20= >>>>>>>>> didn't >>>>>> want to touch it. That left us with the header to include = additional >>>>> elements >>>>>> in. >>>>>>>=20 >>>>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>> arbitrary >>>>>> attributes not unlike the current JOSE spec. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Especially for something that will be used with JWT security=20= >>>>>>>>> tokens I >>>>> will >>>>>> have a hard time making the argument to NIST and others that need=20= >>>>>> to approve this format that not integrity protecting the header=20= >>>>>> parameters is appropriate defence in depth, for something that=20 >>>>>> might be replacing signed SAML assertions in some applications. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I do understand how not integrity protecting the header will=20= >>>>>>>>> make >>>>> some >>>>>> things easier, however I can't agree that the benefit outweighs = the=20 >>>>>> disadvantages. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Regards >>>>>>>=20 >>>>>>>>> John B. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Hey Mike, >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Thanks for having some back-and-forth with me on this. I = think=20 >>>>>>>>>> this >>>>> is a >>>>>> good discussion to have right now. I would like to discuss some >>>>> high-level >>>>>> points, and then I'll respond inline to your precise points. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 >>>>>>>>>> define >>>>> JSON- >>>>>> based formats for integrity and confidentiality protections. JWE=20= >>>>>> and JWS don't fit that requirement, so we should re-consider = their=20 >>>>>> adoption and >>>>> call >>>>>> for new candidates. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Major points: >>>>>>>=20 >>>>>>>>>> 1. JOSE is JSON >>>>>>>=20 >>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>=20 >>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Part 1: JOSE is JSON >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> The JOSE WG charter calls out four deliverables, three of = which=20 >>>>>>>>>> are >>>>>> explicitly required to be JSON: >>>>>>>=20 >>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>=20 >>>>>>>>>> -- "JSON-structured encryption" >>>>>>>=20 >>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>=20 >>>>>>>>>> (The fourth is just a list of algorithms, which should be = JSON=20 >>>>>>>>>> as >>>>>>>=20 >>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20= >>>>>>>>>> suitable >>>>>>>=20 >>>>>>>>>> candidates to fulfill the working group's milestones. (At=20 >>>>>>>>>> least in >>>>>>>=20 >>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>=20 >>>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>>> especially >>>>>>>=20 >>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20 >>>>>>>>>> drafts >>>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>>> cryptographic parameters within the integrity protection, they = have=20 >>>>>> to have the headers included as base64-encoded strings. That=20 >>>>>> obviously adds a lot of >>>>> complexity >>>>>> to encoding and decoding -- for example, you have to keep the=20 >>>>>> encoded header around even after you've decoded it! -- and just = plain more octets. >>>>>> The support for multiple recipients and multiple signatures is = both >>>>> unweildy >>>>>> (matching up parallel indices for headers and signatures) and=20 >>>>>> inefficient (multiple integrity check values in encrypted = objects). >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom=20= >>>>>>>>>> that >>>>>> went into CMS, while making the syntax pure JSON and as simple as >>>>> possible. >>>>>> Multiple signatures and multiple recipients are supported with=20 >>>>>> absolute minimum overhead. So I think it's worth consideration = by=20 >>>>>> the working >>>>> group. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>>> requires >>>>>>>=20 >>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>=20 >>>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>>> included >>>>>>>=20 >>>>>>>>>> within the integrity protection. I'm not aware of any reason=20= >>>>>>>>>> for >>>>>>>=20 >>>>>>>>>> including the cryptographic parameters in the integrity = check, >>>>>>>=20 >>>>>>>>>> instead of only integrity-protecting the content itself. =20 >>>>>>>>>> Indeed, if >>>>>>>=20 >>>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>>> cryptographic >>>>>>>=20 >>>>>>>>>> parameters, it would be a pretty big deal, since neither CMS=20= >>>>>>>>>> nor IKE >>>>>>>=20 >>>>>>>>>> nor provides this protection. (TLS does provide a signature=20= >>>>>>>>>> over >>>>>>>=20 >>>>>>>>>> the algorithms, but only as a way to bind the public key to = the >>>>>>>=20 >>>>>>>>>> session.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except = for >>>>>> attributes that are included in the protected content = (signedAttrs=20 >>>>>> / authenticatedAttrs), which need to be DER-encoded. In JSMS, we=20= >>>>>> don't allow those parameters, so there is no need for = canonicalization at all. >>>>> All the >>>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>>> protected content. In that regard, JSMS is even simpler than = JWE/JWS. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>>> derivatives >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I have absolutely no objection to defining a compact, = URL-safe >>>>> format. >>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20= >>>>>> example >>>>> from >>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> { >>>>>>>=20 >>>>>>>>>> "v":1, >>>>>>>=20 >>>>>>>>>> "t":"au", >>>>>>>=20 >>>>>>>>>> "a":"hs256", >>>>>>>=20 >>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>=20 >>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>=20 >>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>=20 >>>>>>>>>> } >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20= >>>>>>>>>> only >>>>>> use >>>>>>>=20 >>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a = step >>>>>>>=20 >>>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>>> AuthenticatedData, >>>>>>>=20 >>>>>>>>>> we can emulate JWS by moving the content and MAC fields = outside >>>>>> and >>>>>>>=20 >>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and = only >>>>>>>=20 >>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put = the=20 >>>>>>>>>> code >>>>>>>=20 >>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>>> objective, >>>>> but it >>>>>> makes *much* more sense to derive that from a full-size, usable,=20= >>>>>> JSON format than the other way around. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Responses to specific points inline below. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before=20= >>>>>>>>>>> doing >>>>> so, I'll >>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>> understanding >>>>>> and consensus, rather than taking the point of view that the = status=20 >>>>>> quo is >>>>> the >>>>>> only reasonable outcome. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Not being JSON >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> This was by design, so that the results are URL-safe. This = is >>>>> required, >>>>>> for instance, for them to be used as OAuth Bearer Tokens. At the=20= >>>>>> request >>>>> of >>>>>> the working group, closely related pure-JSON drafts were also = published. >>>>>> See: >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json >>>>>>>>>>> -seri >>>>>>>=20 >>>>>>>>>>> alization-01 and >>>>>>>=20 >>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-jso >>>>>>>>>>> n-ser >>>>>>>=20 >>>>>>>>>>> ialization-01 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Use them if you prefer if they better suit your use cases. =20= >>>>>>>>>>> They >>>>> could >>>>>> be adopted as working group documents, if there's interest. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> See above. These are super-clunky, and the need to be the = main >>>>>> focus of the WG, not an afterthought. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> The JSON serialization drafts above do, again, in response = to=20 >>>>>>>>>>> use >>>>>> cases presented by the working group. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> See above. Because of the unnecessary inclusion of the = header=20 >>>>>>>>>> in >>>>> the >>>>>> integrity check, this is far less efficient than it should be. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Functionally, these are very similar operations, at least = from=20 >>>>>>>>>>> an >>>>>> implementation perspective, so it's not clear that making a clear >>>>> distinction >>>>>> would help either developers or adoption in any practical way. =20= >>>>>> They >>>>> achieve >>>>>> overlapping, but admittedly sometimes different goals. I believe=20= >>>>>> that developers can be trusted to use the algorithms that achieve=20= >>>>>> their applications' goals without making a hard distinction = between the two. >>>>> But >>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>> brighter-line >>>>>> distinction might be useful or necessary. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> It's important if you want to do MACs with anything other = than=20 >>>>>>>>>> pre- >>>>>> shared keys. If you want to do anything more advanced, you need = to=20 >>>>>> have wrapped keys, in which case an object with a MAC starts to=20= >>>>>> look a lot more like a JWE than a JWS. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>=20 >>>>>>>>>>> establishment modalities >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> This seems like an area where the existing drafts could be=20= >>>>>>>>>>> refined >>>>> to >>>>>> add descriptions for additional establishment modalities, = possibly=20 >>>>>> based upon your ideas and descriptions, should the working group=20= >>>>>> decide to do >>>>> so. >>>>>> What additional modalities do you have use cases for that you=20 >>>>>> believe are not achievable or straightforward with the existing=20= >>>>>> drafts? The existing modalities supported are largely those that=20= >>>>>> existing developers had told >>>>> us >>>>>> they needed and draw both from the precursor = draft-jones-json-web-*=20 >>>>>> documents and draft-rescorla-jsms. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Bear in mind that the balance that the current drafts try to=20= >>>>>>>>>>> strike >>>>> is >>>>>> keeping the Mandatory to Implement (MTI) feature footprint small=20= >>>>>> enough that developers, including Web developers, are likely to=20= >>>>>> adopt the specs, while still providing enough functionality to = make them generally useful. >>>>> As >>>>>> in any balance, it's often possible to shift things a bit and = still >>>>> maintain the >>>>>> balance, but I'd like people to keep the ubiquitous adoption goal >>>>> front-and- >>>>>> center when proposing additional functionality. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>=20 >>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to = understand >>>>>>>=20 >>>>>>>>>>> that!) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I agree that we need to find a reasonable MTI. The current=20= >>>>>>>>>> JSMS >>>>> draft >>>>>> doesn't really specify which parts are MTI, beyond basic things=20= >>>>>> like >>>>> base64url >>>>>> encoding and ignoring unknown fields. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> My main concern is that JWS and JWE don't really tell me = which >>>>> fields >>>>>> need to be present for which use case. If I'm putting a MAC on a = JWS vs. >>>>> a >>>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>>> Whereas in >>>>> JSMS, >>>>>> I think these things are much clearer due to the separation of = the=20 >>>>>> use >>>>> cases >>>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures=20= >>>>>> and wrapped keys into sub-objects. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Most JSON documents aren't clearly typed; instead, = developers=20 >>>>>>>>>>> and >>>>>> implementations understand from context what the meaning of each = field is. >>>>>> XML is clearly typed, but developers are voting with their feet = by=20 >>>>>> moving >>>>> to >>>>>> JSON. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> What practical advantages resulting from overlaying a typing >>>>>> infrastructure on JSON do you believe are worth the potential = costs=20 >>>>>> of >>>>> doing >>>>>> so? BTW, I'm not opposed to having a JSON schema description of=20= >>>>>> the JOSE JSON data structures like JSMS did in=20 >>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, = but=20 >>>>>> I'll remark that this an informative >>>>> tool, not >>>>>> a normative one. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I actualy don't have a hugely urgent requirement here either. = =20 >>>>>>>>>> It's >>>>>> something that others in the WG had requested, which is trivial = to=20 >>>>>> add in JSMS, but not in JWE/JWS -- again because of the = unnecessary=20 >>>>>> integrity protection of the header. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> An optional version field could be added if the working = group >>>>>>>=20 >>>>>>>>>>> desires, however the last time the working group discussed = it,=20 >>>>>>>>>>> they >>>>>>>=20 >>>>>>>>>>> decided not to do so. Rather, specs like this effectively=20= >>>>>>>>>>> become >>>>>>>=20 >>>>>>>>>>> "versioned" when revised in a way that new fields are added. = =20 >>>>>>>>>>> If >>>>>>>=20 >>>>>>>>>>> you understand the new fields, you support that new version. = =20 >>>>>>>>>>> (Note >>>>>>>=20 >>>>>>>>>>> that this is independent of whether there is a version = number >>>>>>>=20 >>>>>>>>>>> field, which according to some participants in the previous >>>>>>>=20 >>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>=20 >>>>>>>>>>> information.) >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> I'm not religious about not having a version number field, = but >>>>> often >>>>>> "less is more". >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Indeed, I'm not religious either. It just seems like a = general=20 >>>>>>>>>> good >>>>> idea >>>>>> to state this directly as opposed to having parsers divine it = based=20 >>>>>> on >>>>> which >>>>>> fields are present. To quote RFC 5652: >>>>>>>=20 >>>>>>>>>> " >>>>>>>=20 >>>>>>>>>> Each of the major data structures includes a version number = as=20 >>>>>>>>>> the >>>>>>>=20 >>>>>>>>>> first item in the data structure. The version numbers are=20 >>>>>>>>>> intended >>>>>>>=20 >>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20 >>>>>>>>>> check >>>>>> the >>>>>>>=20 >>>>>>>>>> version number prior to attempting a decode, and if a decode=20= >>>>>>>>>> error >>>>>>>=20 >>>>>>>>>> occurs, then the version number is checked as part of the = error >>>>>>>=20 >>>>>>>>>> handling routine. This is a reasonable approach; it places=20= >>>>>>>>>> error >>>>>>>=20 >>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>=20 >>>>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>>>=20 >>>>>>>>>> " >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Best, >>>>>>>=20 >>>>>>>>>> --Richard >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Best wishes, >>>>>>>=20 >>>>>>>>>>> -- Mike >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>=20 >>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>=20 >>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>=20 >>>>>>>>>>> To: Mike Jones >>>>>>>=20 >>>>>>>>>>> Cc: jose@ietf.org >>>>>>>=20 >>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>=20 >>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. =20= >>>>>>>>>>> IMO, >>>>> the >>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>=20 >>>>>>>>>>> -- Not being JSON >>>>>>>=20 >>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>=20 >>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>=20 >>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>=20 >>>>>>>>>>> establishment modalities >>>>>>>=20 >>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>=20 >>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20= >>>>>>>>>>> would be >>>>>> simple to adapt them to address these deficiencies. So I just = did=20 >>>>>> a >>>>> re-write. >>>>>> If you think they can be addressed within the current framework,=20= >>>>>> please explain. I just found it simpler to start from whole = cloth. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>=20 >>>>>>>>>>> --Richard >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Hi Richard, >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>>>> documents, >>>>>> I encourage you to ask about them on the list. The documents = have=20 >>>>>> significant history going back to mid-2010 when convergence=20 >>>>>> discussions started among people with four different JSON signing = &=20 >>>>>> encryption proposals. JWT and the current JOSE specs and=20 >>>>>> implementations are the result. I realize that not all the JOSE=20= >>>>>> participants were part of those discussions from the beginning=20 >>>>>> (although many were) and so teasing out the rationale for = specific=20 >>>>>> decisions might help people better understand the choices made, = and=20 >>>>>> hopefully thereby increase consensus behind the eventual working = group choices. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 >>>>>>>>>>>> below, >>>>> maybe we >>>>>> can start a discussion on that basis. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Best wishes, >>>>>>>=20 >>>>>>>>>>>> -- Mike >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>=20 >>>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On >>>>>>>=20 >>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>=20 >>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>=20 >>>>>>>>>>>> To: jose@ietf.org >>>>>>>=20 >>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>=20 >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Dear JOSE WG, >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>>> thorough >>>>>> review of the JW* specs, I was kind of puzzled by some of the=20 >>>>>> design decisions. So I also went through and wrote an = alternative=20 >>>>>> format, this >>>>> time >>>>>> taking a more of a cue from CMS. A link to the document is = below. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Summary of differences: >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the = header >>>>>>>=20 >>>>>>>>>>>> parameters are represented in JSON. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS allows for full algorithm agility in key agreement,=20= >>>>>>>>>>>> while >>>>> JWE >>>>>>>=20 >>>>>>>>>>>> only allows ECDH-ES. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>>>=20 >>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>> WrappedKey >>>>>>>=20 >>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>>>>=20 >>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o The signature and MAC functions of the JWS object are=20 >>>>>>>>>>>> separated >>>>>>>=20 >>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they are=20= >>>>>>>>>>>> in JWE >>>>>>>=20 >>>>>>>>>>>> and JWS. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS,=20= >>>>>>>>>>>> but >>>>> could >>>>>>>=20 >>>>>>>>>>>> be added without significant change. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>>>>=20 >>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>>> implementation >>>>> (based >>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Comments are very welcome. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>=20 >>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>=20 >>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>=20 >>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has = been >>>>>>>=20 >>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to the=20= >>>>>>>>>>>>> IETF >>>>>>>=20 >>>>>>>>>>>>> repository. >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>=20 >>>>>>>>>>>>> Revision: 00 >>>>>>>=20 >>>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>>=20 >>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>=20 >>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>=20 >>>>>>>>>>>>> Number of pages: 25 >>>>>>>=20 >>>>>>>>>>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>> jsms-00.txt >>>>>>>=20 >>>>>>>>>>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>=20 >>>>>>>>>>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>=20 >>>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>>> cryptographically >>>>>>>=20 >>>>>>>>>>>>> secured messages. While the IETF has defined a number of >>>>>> formats >>>>>>>=20 >>>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings=20= >>>>>>>>>>>>> which >>>>>>>=20 >>>>>>>>>>>>> are not easy to use in modern applications. This document >>>>>>>=20 >>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a=20= >>>>>>>>>>>>> new >>>>>>>=20 >>>>>>>>>>>>> cryptographic message format which is based on JavaScript=20= >>>>>>>>>>>>> Object >>>>>>>=20 >>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>>>> generate >>>>>> and parse. >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_57530A0E-7A49-411B-8245-1C6EA16B46F9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjIxMDcwMlowIwYJKoZIhvcNAQkEMRYEFI3JtKCPgYh4nuSxf3PPc8zjHkfGMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJV8Mig168aLaE280XVoc6PbpDSIgWdOY3wB4SCoj/O/NTL/JMFFgqMyRBOn0gaBYHq4XII18A/K BM3Uhbw6f2rYsENwDRPoYJf9DvJk8jkWngeXTKFF3hVF/UbgO38yFU6UwagHqyLLVUH6Ub5e17VD Kqkpsvq7ww+SLLPMg9Zgbw8ZyATM5qJaG/Au4qAEW8Bv6CCC64oF8YtPl6vTt0ss+9r6rdIjN/tF xylGiN1UaOnHJzBjUX7VN96DQCjjvZCcXEmTaLKVfGMT1xwXMlEz9J9Ox3n8Spr0f7aCBmYzwqpi D1lEVmwCx0ex8rBSMlH7e6QbjAz3EQ5cnOinlcgAAAAAAAA= --Apple-Mail=_57530A0E-7A49-411B-8245-1C6EA16B46F9-- From rbarnes@bbn.com Tue Jun 26 14:13:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D2111E80E9 for ; Tue, 26 Jun 2012 14:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74aFzZfFgwxY for ; Tue, 26 Jun 2012 14:13:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C8BE121F8559 for ; Tue, 26 Jun 2012 14:13:37 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:60835) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sjd4C-00071Q-DU; Tue, 26 Jun 2012 17:12:56 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <6821E712-0D0D-419B-9E15-789DE54798A9@ve7jtb.com> Date: Tue, 26 Jun 2012 17:13:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <019D2416-9DC2-43F4-A9E5-A2214195AA71@bbn.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> <2A8A4F3B-CD0D-48C5-8A65-49A2E8C4D096@bbn.com> <6821E712-0D0D-419B-9E15-789DE54798A9@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Tue, 26 Jun 2012 21:13:39 -0000 You still haven't answered my question: Does Matt's document, as is, = compromise the security of JWE? On Jun 26, 2012, at 4:58 PM, John Bradley wrote: > I would prefer to let Matt update his spec before further dragging him = into this. >=20 > I have always been for having multiple recipients, I raised the issue = with JWE before the JOSE work group. >=20 > I just want to do that without overly complicating the simple case. >=20 > The question is how to do it. I and others prefer maintaining the = integrity protection over both the header and content. =20 > I prefer to find a way to have both integrity and multiple recipients. As I've noted previously, you can have integrity and multiple = recipients, but it costs you something: -- Efficiency:=20 -- You have to re-process the entire message body for every = recipient, not just the key -- The message has to carry separate base64url-encoded headers for = each recipient -- The recipient has to decode each header to figure out which is = his -- Scalability:=20 -- If you want to be able to add a recipient later, you have to = cache the whole message -- Security:=20 -- If you want to be able to add a recipient, you have to cache the = message in plaintext -- Prefixing the signed body with a header creates vulnerabilities = to prefix-based attacks Some of these get better if you use canonicalization instead of = base64url-encoding, but given that nobody has yet articulated a clear = benefit, I'm not sure why it's worth the trouble. > As I stated Jim's proposal has some good ideas and doesn't require = scrapping integrity. >=20 > I appreciate that you are approaching this from the CMS perspective, = though the correct thing to do in CMS with integrity protecting = attributes in CMS seems to also have multiple opinions. I'm happy to support header integrity as an *optional* mechanism. = (Indeed, there's no way you can prevent someone from, say, copying = headers in the body to integrity-protect them.) I just don't think it = should be *mandatory*. If you want to mandate it for JWT, that's fine. = But it shouldn't be required in the general-purpose format. =20 --Richard > Regards > John B. >=20 > On 2012-06-26, at 3:30 PM, Richard L. Barnes wrote: >=20 >>>> Alternatively, you could provide a whole JSMS EncryptedData object = on the first shot, with WrappedKeys for keys you know. Then, if a = recipient doesn't find a WrappedKey for himself, he can for it, = and you can just respond with the WrappedKey. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>> That is what I was trying to get at. The existing spec supports = sending the wrapped content key with a keyid. >>>=20 >>> You send that with every message, if the recipient doesn't have the = necessary key it requests it. >>>=20 >>> The receiver retrieves the key and unwraps the CMK. There is = nothing in the current spec that stops that from working. >>>=20 >>> The message and integrity are based on the wrapped key. That is = the decision the WG took a while ago. >>>=20 >>> Having multiple recipients each with a different symmetric or = asymmetric key used to wrap the CMK is slightly different problem. >>=20 >> Obviously, JWE key wrapping works for single recipients. I don't = contest that. Multiple recipients is the problem. =20 >>=20 >> Unless you want to support multiple recipients, there's no point to = Matt's scheme. It's tempting to think that it addresses the case where = the sender doesn't know the single recipient's key in advance, but in = that case, it would be much simpler just to have the sender request the = key at the start. So the whole point of Matt's document is to support = multiple recipients, at the cryptographic layer, even if not at the XMPP = layer (a given JID might have multiple keys, e.g., per device). >>=20 >> Anyway, you skipped the important question in my mail: Do you think = that Matt's scheme compromises the security of the JWE? >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>> Jim's proposal for having multiple recipients in the header has = potential, I don't support everything in it but it contributes some = useful ideas to support multiple recipient and signature use cases. >>>=20 >>> John B. >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 25, 2012, at 7:02 PM, John Bradley wrote: >>>>=20 >>>>> Richard, >>>>>=20 >>>>> There was some other back and for with Matt. >>>>>=20 >>>>> He is only encrypting to one recipient at a time. >>>>>=20 >>>>> Not that encrypting the CMK to multiple recipients is not valid, = that is just not how the protocol works. >>>>>=20 >>>>> The message is encrypted once and whatever endpoint gets it calls = back to the sender to get the key. >>>>>=20 >>>>> The issue as I understand it is that the sender doesn't know the = public key for the recipient before it sends the message. >>>>>=20 >>>>> I am happy to work on Matts issues, but I think they are separate = from the point you are making on integrity protecting the header. >>>>>=20 >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>>> Having read Matt's spec, he is not breaking JWE to send to = multiple recipients. As the spec says: >>>>>>> "This document specifies an approach for encrypting = communications between two entities which each might have multiple = end-points" >>>>>>=20 >>>>>> He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >>>>>>=20 >>>>>> Compare JSMS and the WrappedKey structure, or CMS and = RecipientInfo. >>>>>> = >>>>>> >>>>>>=20 >>>>>>=20 >>>>>>> I should also point out that the messages are transported in = XML, and as such, the addition of a JSON wrapper for the JWE probably is = not useful as it would need escaping anyway. By not sending the CMK as = part of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>>>>>=20 >>>>>>> There are two somewhat separate uses for JWE in the spec: one = for encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>>>>>=20 >>>>>>> For the transmission of the messages, I can't see any reason to = not use the JWE spec as currently written. It certainly supports the = use case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>>>>>=20 >>>>>>> Currently the message on the wire looks like: >>>>>>>=20 >>>>>>> >>>>>> from=3D'juliet@capulet.lit/balcony' >>>>>>> id=3D'fJZd9WFIIwNjFctT' >>>>>>> to=3D'romeo@montegue.lit/garden' >>>>>>> type=3D'chat'> >>>>>>> >>>>>> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>>>>>
>>>>>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>>>>>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>>>>>> NpemUiOiIxNiJ9 >>>>>>>
>>>>>>> >>>>>>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>>>>>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>>>>>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>>>>>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>>>>>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>>>>>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>>>>>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>>>>>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>>>>>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>>>>>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>>>>>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>>>>>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>>>>>> eCGP >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>=20 >>>>>>> I would have sent header and data as one element using the = normal JWE dot separated format, but I need to talk to Matt to = understand his reasoning. >>>>>>>=20 >>>>>>> I note that his example is using AES-CCM, and so not documented = in JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>>>>>=20 >>>>>> Valid point. I had missed that RFC 5084 handled the ICV = separately. >>>>>>=20 >>>>>>=20 >>>>>>> I don't quite get your point on integrity protecting the wrapped = key causing the integrity value to change. For HMAC, GCM, and I think = CCM, changing the encryption key changes the tag value anyway (sort of = the point I thought). The only time it would stay the same would be if = you were just using a MAC over the body and that is a touch useless for = integrity protection. Perhaps I am missing the point, but as far as I = know even without protecting the header, the tag value is different for = every key (and nonce/IV). >>>>>>=20 >>>>>> The point is that you have to re-compute the ICV over the entire = header+content every time you wrap a new key. This is kind of a big = deal for the XMPP case. =20 >>>>>>=20 >>>>>> Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >>>>>>=20 >>>>>> So integrity protecting the headers has real costs in terms of = both scalability (state) and security. >>>>>>=20 >>>>>>=20 >>>>>>> There are some interesting things Matt=92s spec is attempting = with using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>>>>>=20 >>>>>> My point is that we shouldn't need a whole new protocol for this. = CMS RecipientInfos do exactly what we want. (Er, what *Matt* wants.) = We should just be copying and pasting. >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> I am happy to work with Matt to refine his ID. >>>>>>>=20 >>>>>>> I recommend others read it as well so we can understand if there = are any real issues. >>>>>>>=20 >>>>>>> Regards >>>>>>> John B. >>>>>>>=20 >>>>>>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>>>>>=20 >>>>>>>> Hey John, >>>>>>>>=20 >>>>>>>> I think you're missing the bigger point here, which is: In = order to allow for multiple recipients, Matt had to break JWE. >>>>>>>>=20 >>>>>>>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>>>>>=20 >>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>>>>>=20 >>>>>>>>> Hi Matt, >>>>>>>>>=20 >>>>>>>>> Complements on updating the draft. >>>>>>>>>=20 >>>>>>>>> The issue I see is that you are attempting to distribute the = CMK out of band and use "none" as the alg. >>>>>>>>>=20 >>>>>>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>>>>>=20 >>>>>>>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>>>>>>> =46rom a implementation point of view the symmetric cypher = always gets the CEK derived from the CMK in the message independent of = if it is using RSA or A128KW/A256KW. >>>>>>>>>=20 >>>>>>>>> That imposes some extra steps for people using symmetric keys = but encourages rotation of the CEK that would likely not happen = otherwise. >>>>>>>>>=20 >>>>>>>>> So in your spec I would expect you to distribute a shared = secret via keyreq for use in A256KW and be using that decrypt the CMK at = the receiver. >>>>>>>>>=20 >>>>>>>>> I also suspect that you intended to use A256GCM as the enc alg = and not A256CCM.=20 >>>>>>>>>=20 >>>>>>>>> I am not a XMPP expert so it will take me some time to go over = it in detail. I would like to understand the use case to be certain it = is properly supported. >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>>>>>>=20 >>>>>>>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been = updated to the latest JOSE WG drafts. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - m&m >>>>>>>>>>=20 >>>>>>>>>> Matt Miller - >>>>>>>>>> Cisco Systems, Inc. >>>>>>>>>>=20 >>>>>>>>>> Begin forwarded message: >>>>>>>>>>=20 >>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>>>>>>> Author(s) : Matthew Miller >>>>>>>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>>>>>>> Pages : 22 >>>>>>>>>>> Date : 2012-06-21 >>>>>>>>>>>=20 >>>>>>>>>>> Abstract: >>>>>>>>>>> This document defines a method of end-to-end object = encryption for >>>>>>>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>>>>>>=20 >>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>>>>>>=20 >>>>>>>>>>> A diff from previous version is available at: >>>>>>>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> I-D-Announce mailing list >>>>>>>>>>> I-D-Announce@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> jose mailing list >>>>>>>>>> jose@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From mamille2@cisco.com Tue Jun 26 14:17: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 B1CB811E809C for ; Tue, 26 Jun 2012 14:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7eFqPdt24lH for ; Tue, 26 Jun 2012 14:17:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3FF11E809B for ; Tue, 26 Jun 2012 14:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=21945; q=dns/txt; s=iport; t=1340745471; x=1341955071; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=DClPzuUv0QEflZUrqwT7VcwNaa3IefcIQZ2UZd4fV8g=; b=gUcgardLL3qWZ8H2UG0Tlaeu9QO2TJ3hRFWd9gNPCSLMs5F7Ks3VBOik M2uoNcXxzf49jKy6hA5H0eKLaqyEl42ikv0HPmOR66JwThsWSbk985PNK 9+qqOtvH6K7NrW/s2KTbBG2qX2Wmo+fP24nC/JQ/gR7l27+UpQ8mAdjhC o=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHEm6k+rRDoH/2dsb2JhbAA8CLY2gQeCGAEBAQMBAQEBDwFUBAMLBQsLEQMBAgEuAiUfCQgGARIJGYdkBAELmRGgTos3FgSFEGADiEqFfYM9gy6BEoREhTCDF4Fmgn6BNwcC X-IronPort-AV: E=Sophos;i="4.77,480,1336348800"; d="sig'?p7s'?scan'208";a="47691326" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 26 Jun 2012 21:17:50 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5QLHnRV011519; Tue, 26 Jun 2012 21:17:50 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--486453212" From: Matt Miller In-Reply-To: <019D2416-9DC2-43F4-A9E5-A2214195AA71@bbn.com> Date: Tue, 26 Jun 2012 15:18:03 -0600 Message-Id: <0B5510F8-F690-463D-91AB-75FFAB5A4104@cisco.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> <2A8A4F3B-CD0D-48C5-8A65-49A2E8C4D096@bbn.com> <6821E712-0D0D-419B-9E15-789DE54798A9@ve7jtb.com> <019D2416-9DC2-43F4-A9E5-A2214195AA71@bbn.com> To: "Richard L. Barnes" , John Bradley Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Tue, 26 Jun 2012 21:17:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--486453212 Content-Type: multipart/signed; boundary=Apple-Mail-3--486453236; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-3--486453236 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 /me ignores thread until next update is submitted - m&m Matt Miller - Cisco Systems, Inc. On Jun 26, 2012, at 15:13, Richard L. Barnes wrote: > You still haven't answered my question: Does Matt's document, as is, = compromise the security of JWE? >=20 >=20 > On Jun 26, 2012, at 4:58 PM, John Bradley wrote: >=20 >> I would prefer to let Matt update his spec before further dragging = him into this. >>=20 >> I have always been for having multiple recipients, I raised the = issue with JWE before the JOSE work group. >>=20 >> I just want to do that without overly complicating the simple case. >>=20 >> The question is how to do it. I and others prefer maintaining the = integrity protection over both the header and content. =20 >> I prefer to find a way to have both integrity and multiple = recipients. >=20 > As I've noted previously, you can have integrity and multiple = recipients, but it costs you something: > -- Efficiency:=20 > -- You have to re-process the entire message body for every = recipient, not just the key > -- The message has to carry separate base64url-encoded headers for = each recipient > -- The recipient has to decode each header to figure out which is = his > -- Scalability:=20 > -- If you want to be able to add a recipient later, you have to = cache the whole message > -- Security:=20 > -- If you want to be able to add a recipient, you have to cache the = message in plaintext > -- Prefixing the signed body with a header creates vulnerabilities = to prefix-based attacks >=20 > Some of these get better if you use canonicalization instead of = base64url-encoding, but given that nobody has yet articulated a clear = benefit, I'm not sure why it's worth the trouble. >=20 >=20 >> As I stated Jim's proposal has some good ideas and doesn't require = scrapping integrity. >>=20 >> I appreciate that you are approaching this from the CMS perspective, = though the correct thing to do in CMS with integrity protecting = attributes in CMS seems to also have multiple opinions. >=20 > I'm happy to support header integrity as an *optional* mechanism. = (Indeed, there's no way you can prevent someone from, say, copying = headers in the body to integrity-protect them.) I just don't think it = should be *mandatory*. If you want to mandate it for JWT, that's fine. = But it shouldn't be required in the general-purpose format. =20 >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >> Regards >> John B. >>=20 >> On 2012-06-26, at 3:30 PM, Richard L. Barnes wrote: >>=20 >>>>> Alternatively, you could provide a whole JSMS EncryptedData object = on the first shot, with WrappedKeys for keys you know. Then, if a = recipient doesn't find a WrappedKey for himself, he can for it, = and you can just respond with the WrappedKey. >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>> That is what I was trying to get at. The existing spec supports = sending the wrapped content key with a keyid. >>>>=20 >>>> You send that with every message, if the recipient doesn't have = the necessary key it requests it. >>>>=20 >>>> The receiver retrieves the key and unwraps the CMK. There is = nothing in the current spec that stops that from working. >>>>=20 >>>> The message and integrity are based on the wrapped key. That is = the decision the WG took a while ago. >>>>=20 >>>> Having multiple recipients each with a different symmetric or = asymmetric key used to wrap the CMK is slightly different problem. >>>=20 >>> Obviously, JWE key wrapping works for single recipients. I don't = contest that. Multiple recipients is the problem. =20 >>>=20 >>> Unless you want to support multiple recipients, there's no point to = Matt's scheme. It's tempting to think that it addresses the case where = the sender doesn't know the single recipient's key in advance, but in = that case, it would be much simpler just to have the sender request the = key at the start. So the whole point of Matt's document is to support = multiple recipients, at the cryptographic layer, even if not at the XMPP = layer (a given JID might have multiple keys, e.g., per device). >>>=20 >>> Anyway, you skipped the important question in my mail: Do you think = that Matt's scheme compromises the security of the JWE? >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Jim's proposal for having multiple recipients in the header has = potential, I don't support everything in it but it contributes some = useful ideas to support multiple recipient and signature use cases. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jun 25, 2012, at 7:02 PM, John Bradley wrote: >>>>>=20 >>>>>> Richard, >>>>>>=20 >>>>>> There was some other back and for with Matt. >>>>>>=20 >>>>>> He is only encrypting to one recipient at a time. >>>>>>=20 >>>>>> Not that encrypting the CMK to multiple recipients is not valid, = that is just not how the protocol works. >>>>>>=20 >>>>>> The message is encrypted once and whatever endpoint gets it calls = back to the sender to get the key. >>>>>>=20 >>>>>> The issue as I understand it is that the sender doesn't know the = public key for the recipient before it sends the message. >>>>>>=20 >>>>>> I am happy to work on Matts issues, but I think they are separate = from the point you are making on integrity protecting the header. >>>>>>=20 >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >>>>>>=20 >>>>>>>> Having read Matt's spec, he is not breaking JWE to send to = multiple recipients. As the spec says: >>>>>>>> "This document specifies an approach for encrypting = communications between two entities which each might have multiple = end-points" >>>>>>>=20 >>>>>>> He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >>>>>>>=20 >>>>>>> Compare JSMS and the WrappedKey structure, or CMS and = RecipientInfo. >>>>>>> = >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>> I should also point out that the messages are transported in = XML, and as such, the addition of a JSON wrapper for the JWE probably is = not useful as it would need escaping anyway. By not sending the CMK as = part of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>>>>>>=20 >>>>>>>> There are two somewhat separate uses for JWE in the spec: one = for encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>>>>>>=20 >>>>>>>> For the transmission of the messages, I can't see any reason to = not use the JWE spec as currently written. It certainly supports the = use case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>>>>>>=20 >>>>>>>> Currently the message on the wire looks like: >>>>>>>>=20 >>>>>>>> >>>>>>> from=3D'juliet@capulet.lit/balcony' >>>>>>>> id=3D'fJZd9WFIIwNjFctT' >>>>>>>> to=3D'romeo@montegue.lit/garden' >>>>>>>> type=3D'chat'> >>>>>>>> >>>>>>> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>>>>>>
>>>>>>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>>>>>>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>>>>>>> NpemUiOiIxNiJ9 >>>>>>>>
>>>>>>>> >>>>>>>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>>>>>>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>>>>>>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>>>>>>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>>>>>>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>>>>>>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>>>>>>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>>>>>>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>>>>>>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>>>>>>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>>>>>>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>>>>>>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>>>>>>> eCGP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>> I would have sent header and data as one element using the = normal JWE dot separated format, but I need to talk to Matt to = understand his reasoning. >>>>>>>>=20 >>>>>>>> I note that his example is using AES-CCM, and so not documented = in JWA. That isn't a big deal if we want to add it. CCM supports extra = authenticated data and outputs an authentication tag like GCM. In CMS = RFC 5084, the tag seems to be carried separately from the encrypted data = and in RFC 3610, the tag is concatenated to the encrypted data. If we = want to support CCM, then we need to pick one of the ways to transport = the tag info. Either would work. We would just need to define that = the integrity element contains a zero byte string as Matt has, if we = want to concatenate the integrity tag value after the ciphertext. >>>>>>>=20 >>>>>>> Valid point. I had missed that RFC 5084 handled the ICV = separately. >>>>>>>=20 >>>>>>>=20 >>>>>>>> I don't quite get your point on integrity protecting the = wrapped key causing the integrity value to change. For HMAC, GCM, and = I think CCM, changing the encryption key changes the tag value anyway = (sort of the point I thought). The only time it would stay the same = would be if you were just using a MAC over the body and that is a touch = useless for integrity protection. Perhaps I am missing the point, but = as far as I know even without protecting the header, the tag value is = different for every key (and nonce/IV). >>>>>>>=20 >>>>>>> The point is that you have to re-compute the ICV over the entire = header+content every time you wrap a new key. This is kind of a big = deal for the XMPP case. =20 >>>>>>>=20 >>>>>>> Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >>>>>>>=20 >>>>>>> So integrity protecting the headers has real costs in terms of = both scalability (state) and security. >>>>>>>=20 >>>>>>>=20 >>>>>>>> There are some interesting things Matt=92s spec is attempting = with using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>>>>>>=20 >>>>>>> My point is that we shouldn't need a whole new protocol for = this. CMS RecipientInfos do exactly what we want. (Er, what *Matt* = wants.) We should just be copying and pasting. >>>>>>>=20 >>>>>>> --Richard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I am happy to work with Matt to refine his ID. >>>>>>>>=20 >>>>>>>> I recommend others read it as well so we can understand if = there are any real issues. >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>>>>>>=20 >>>>>>>>> Hey John, >>>>>>>>>=20 >>>>>>>>> I think you're missing the bigger point here, which is: In = order to allow for multiple recipients, Matt had to break JWE. >>>>>>>>>=20 >>>>>>>>> This is yet another reason to abandon integrity protection for = cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>>>>>>=20 >>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Matt, >>>>>>>>>>=20 >>>>>>>>>> Complements on updating the draft. >>>>>>>>>>=20 >>>>>>>>>> The issue I see is that you are attempting to distribute the = CMK out of band and use "none" as the alg. >>>>>>>>>>=20 >>>>>>>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>>>>>>=20 >>>>>>>>>> Based on JSMS and mandatory integrity we adopted having a CMK = always included in the message to allow for rotation. =20 >>>>>>>>>> =46rom a implementation point of view the symmetric cypher = always gets the CEK derived from the CMK in the message independent of = if it is using RSA or A128KW/A256KW. >>>>>>>>>>=20 >>>>>>>>>> That imposes some extra steps for people using symmetric keys = but encourages rotation of the CEK that would likely not happen = otherwise. >>>>>>>>>>=20 >>>>>>>>>> So in your spec I would expect you to distribute a shared = secret via keyreq for use in A256KW and be using that decrypt the CMK at = the receiver. >>>>>>>>>>=20 >>>>>>>>>> I also suspect that you intended to use A256GCM as the enc = alg and not A256CCM.=20 >>>>>>>>>>=20 >>>>>>>>>> I am not a XMPP expert so it will take me some time to go = over it in detail. I would like to understand the use case to be = certain it is properly supported. >>>>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>>> John B. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>>>>>>>=20 >>>>>>>>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been = updated to the latest JOSE WG drafts. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> - m&m >>>>>>>>>>>=20 >>>>>>>>>>> Matt Miller - >>>>>>>>>>> Cisco Systems, Inc. >>>>>>>>>>>=20 >>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>=20 >>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>>>>>>>> Author(s) : Matthew Miller >>>>>>>>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>>>>>>>> Pages : 22 >>>>>>>>>>>> Date : 2012-06-21 >>>>>>>>>>>>=20 >>>>>>>>>>>> Abstract: >>>>>>>>>>>> This document defines a method of end-to-end object = encryption for >>>>>>>>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>>>>>>>=20 >>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>>>>>>>=20 >>>>>>>>>>>> A diff from previous version is available at: >>>>>>>>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01= >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> I-D-Announce mailing list >>>>>>>>>>>> I-D-Announce@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jose mailing list >>>>>>>>>>> jose@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> jose mailing list >>>>>>>>>> jose@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-3--486453236 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyNjIxMTgw M1owIwYJKoZIhvcNAQkEMRYEFKuGh8B6q1Kk0E4ss4KLQB/bP95PMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAvMRPDwkarqWYiM2msmZA2YXQUN2W8+s3uMk0hCv5zhFzgWuJoCUdSB9Vb 0KvN6Vxl/6BqCbDmxOBUWQ5OrNuk3FYh6wWn+j7nsj5knFZYIfg31hwEt5Z53ZfgRTTPqZdwk2Jf PeYPoxuqpxc6W9k8zUVyGwdkBBQczmreh4hToUuQtdSKn1Z73Lt7/mHoAKbDFYhAfPotjmjjPLbD k+OQdKq+TuKCN/t0GW5V13yxGbvnkpmzVpyUqMYqCbE3HihWO3URYBbnpYRZuGfDQ2xNloznEOn3 iL1IFsq7lP1ZYaF/O28CfZqNEYhZViHgb3kXyaeBzaIGCtxi5DE8L1PCAAAAAAAA --Apple-Mail-3--486453236-- --Apple-Mail-4--486453212 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP6icLAAoJEJq6Ou0cgrSPn9kH/RqT1EfgKvGv1KirQ9gJqNul S/xLzrhilGklwXyuqhYxcNchysbA31trNZTzhNSCyyOWplcW8JU1F58tx+EAOzMi i3Mf+7aZtitiQA4HUzqoJ5IbE0VKod4IQMpKMHdpL7vNoHSVNyFeIbVgHn1UaJlW soRFHVqoxNwPqEpxcNPjgXwn636zhvyWcct9yDsknpFGQlvmnIGx3aXOqwtKhFIZ 1iI0LBuqi+kkn4ql3mVNzzf7P6oKOwx+N503mIq4myLqUNqr4jazRf9hRXN9fyY0 Y/BN9tmvJq810k68A06rSNsZLyhYkBA6qSDJIAjWjl8hffkaUwhyw3trLOr+u88= =E8GV -----END PGP SIGNATURE----- --Apple-Mail-4--486453212-- From rbarnes@bbn.com Tue Jun 26 14:20: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 A87FA11E809B for ; Tue, 26 Jun 2012 14:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6DeoM+qfySU for ; Tue, 26 Jun 2012 14:20:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB1011E8093 for ; Tue, 26 Jun 2012 14:20:19 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:60907) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjdBI-0008Em-Tg; Tue, 26 Jun 2012 17:20:17 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 26 Jun 2012 17:20:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Anthony Nadalin , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:20:22 -0000 Why would you ever want to use ECB mode? If you want something fast and = parallelizable, CTR mode is a lot better. We had discussed Dave McGrew's draft as a mechanism for specifying = general AEAD algorithms: --Richard On Jun 26, 2012, at 5:07 PM, John Bradley wrote: > You should suggest adding that as a supported algorithm. >=20 > We wanted to keep the core set down to a reasonable number to = encourage interoparability. >=20 > AES-ECB + HMAC can be a option if the WG wants it. >=20 > John B. > On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote: >=20 >> AES-ECB is also a popular alternative >>=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 >> Sent: Tuesday, June 26, 2012 1:59 PM >> To: Anthony Nadalin >> Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org >> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >>=20 >> Yes that is why we added the composite HMAC + AES-CBC. We can = debate if that is an algorithm or mandatory integrity with non AEAD = algorithms, but the effect of integrity protecting the header remains in = both cases. >>=20 >> John B. >>=20 >> On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >>=20 >>> Not sure there was a WG decision and what that would mean if there = was, as there are many libraries out there that don't support the = encryption with integrity algorithms, so need to support alternative = means of things like key wrap that could have an integrity check. >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of John Bradley >>> Sent: Tuesday, June 26, 2012 12:30 PM >>> To: Richard L. Barnes >>> Cc: Jim Schaad; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >>>=20 >>> There was a WG decision to not allow encryption without integrity. = Jim and others call that sender verification. >>>=20 >>> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>>=20 >>> The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. >>>=20 >>> We do have s JWT spec that covers the body for security tokens. = The idea was to separate that from signing and encryption so that = signing and encryption can be used for other objects. >>>=20 >>> John B. >>>=20 >>> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>>=20 >>>>> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >>>>> In those cases one can easily argue that the header should be = protected as much as in HMAC. >>>>=20 >>>> Can you clarify the scope of "we are mandating"? >>>>=20 >>>>=20 >>>>> There may well be signing_time or other elements that would go = into the header as well for JWE. >>>>=20 >>>> Why do these need to go into the header rather than the body? >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Regards >>>>> John B. >>>>>=20 >>>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>>=20 >>>>>> >>>>>>=20 >>>>>> Richard, >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>>> Behalf Of Richard L. Barnes >>>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>>> To: Nat Sakimura >>>>>>> Cc: Mike Jones; jose@ietf.org >>>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>>> draft-barnes-jose-jsms- 00.txt >>>>>>>=20 >>>>>>> Hi Nat, >>>>>>>=20 >>>>>>> I'm not sure what X.509 fiasco you're referring to. There was a=20= >>>>>>> recent >>>>>> MD5 >>>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, = there=20 >>>>>>> have >>>>>> been >>>>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. =20 >>>>>>> As >>>>>> was >>>>>>> noted on the SAAG list, the real news here is that Microsoft = wasn't >>>>>> following >>>>>>> any of those recommendations. >>>>>>>=20 >>>>>>> JWS would have had the same problem as X.509. The attack did = not=20 >>>>>>> modify the cryptographic parameters (anything that would have = gone=20 >>>>>>> in the header), it would not have been thwarted by the integrity=20= >>>>>>> protection we're worrying about. >>>>>>>=20 >>>>>>> Actually, the header signing that JWS does makes it even nicer = for=20 >>>>>>> the >>>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20= >>>>>>> header >>>>>> value >>>>>>> is entirely static for a given signer, it's easy to use as a = fixed prefix. >>>>>> If JWS just >>>>>>> signed the content, then the application could include a = something=20 >>>>>>> random up front to prevent such prefix-based attacks. >>>>>>>=20 >>>>>>=20 >>>>>> I don't believe that this is a true statement. If you had a = prefix=20 >>>>>> or just signed what was given to you (i.e. no prefix), it would = make=20 >>>>>> no difference in terms of the attack for Flame. Flame could = always=20 >>>>>> use a fixed prefix of its own design rather than using the fixed=20= >>>>>> header that is generated by having JWS sign the header = information. >>>>>>=20 >>>>>>> It's tempting to say that we should just add randomness to the = JOSE >>>>>> format. >>>>>>> But the real lesson of the Flame/MD5 attacks is operational: If=20= >>>>>>> you're >>>>>> signing >>>>>>> something that somebody else gave you, make sure that you're not=20= >>>>>>> signing exactly what they gave you. Follow the recommendations = of=20 >>>>>>> RFC 4270. In other contexts, there's no need of similar random=20= >>>>>>> elements; it just adds complexity. >>>>>>=20 >>>>>> This is definitely a true statement in all events and is = something=20 >>>>>> that should be added to the Security Considerations section. >>>>>>=20 >>>>>> That being said, I think that there are valid reasons for wanting = to=20 >>>>>> protect the header information by some authentication processing. = =20 >>>>>> PKIX certificates protect the signature algorithm information (by=20= >>>>>> copying the data into the to be signed block) and CMS has long=20 >>>>>> allowed for information to be included in the signed attributes = area=20 >>>>>> that identifies the algorithms used, the certificates used and so=20= >>>>>> forth. There are also other things that we might find to be=20 >>>>>> convenient to be placed in the header information that is current=20= >>>>>> not there (a signing time and embedded content type comes to = mind)=20 >>>>>> that would be a product either of specific types of signatures or = becomes a common attribute to be placed there. >>>>>>=20 >>>>>> In terms of encryption operations, I remember in the past that I=20= >>>>>> have had either corrupted encrypted streams or corrupted IVs and = had=20 >>>>>> a successful decryption that later generated other problems when=20= >>>>>> trying to parse. This is less of an issue with AEAD algorithms = as=20 >>>>>> they have a much stricter rule on when the stream decrypts = correctly. >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>>>=20 >>>>>>> --Richard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> [1] = >>>>>>> [2] >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>>=20 >>>>>>>> Especially after the X.509 fiasco, I strongly believe that = having >>>>>> integrity >>>>>>> check over the metadata is a good thing. It is such a little = effort=20 >>>>>>> that >>>>>> gives us >>>>>>> much more protection down the road. In this sense, I fully agree=20= >>>>>>> with Ben here. We should have integrity protection over the = header. >>>>>>>>=20 >>>>>>>> Nat >>>>>>>>=20 >>>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>>> wrote: >>>>>>>> Two years ago when the developer community needing a = JSON-friendly >>>>>>> token format was designing the JSON Web Token (JWT), we = explicitly=20 >>>>>>> asked security experts whether the header parameters should be=20= >>>>>>> integrity protected or not. Among them, Ben Laurie was one of = the=20 >>>>>>> voices saying >>>>>> that >>>>>>> securing them was the right thing to do. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> He argued that if the parameters can be protected in a = practical=20 >>>>>>>> manner, >>>>>>> then they should. Doing so provides an additional hurdle that=20= >>>>>>> attackers would have to surmount. For example, if they can try = to=20 >>>>>>> substitute a >>>>>> weaker >>>>>>> authentication scheme, then they must figure out how to make it=20= >>>>>>> authenticate correctly despite some plaintext they can't control = -=20 >>>>>>> the >>>>>> header >>>>>>> parameters. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Ben also took the position that paring security protocols down = to=20 >>>>>>>> the >>>>>> least >>>>>>> you can get away with, given attacks you can think of, is not a=20= >>>>>>> good >>>>>> design >>>>>>> principle. If there is not a strong argument against including = a=20 >>>>>>> feature >>>>>> that >>>>>>> may make it harder for attackers, then that feature should be = included. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I agree with him. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The decision to provide integrity protection for the headers is >>>>>> documented >>>>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>>=20 >>>>>>>> Given that the envelope is extensible and therefore may contain >>>>>> security- >>>>>>> sensitive information, we reached a consensus (with input from = Ben=20 >>>>>>> Laurie via IM) that the combination envelope.payload must be = signed. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I believe that logic is as sound today as it was then. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>>>> community's >>>>>>> decision to provide integrity protection for the headers. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best=20 >>>>>>>> wishes, >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20= >>>>>>>> Behalf Of >>>>>>> John Bradley >>>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>>> To: Richard L.Barnes >>>>>>>> Cc: jose@ietf.org >>>>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>>>> draft-barnes-jose-jsms- >>>>>>> 00.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi Richard, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding=20= >>>>>>>> and not >>>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>>=20 >>>>>>>> There are possible hash truncation attacks by shortening SHA256 = to >>>>>> SHA224 >>>>>>> as an example (I know we preclude truncated hashes at the = moment). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The bad feeling I get around this is that if there is a = scenario=20 >>>>>>>> where >>>>>> the >>>>>>> attacker controls the plaintext to be signed and there is no = signer >>>>>> controlled >>>>>>> text contributed there are potential bad things that could = happen=20 >>>>>>> down the road. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This bit us with x509 certs not that long ago (yes with MD5=20 >>>>>>>> admittedly) >>>>>>> where the attacker could use a certificate extension to include=20= >>>>>>> extra data >>>>>> and >>>>>>> cause a pre collided hash to be generated. >>>>>>>>=20 >>>>>>>> Having part of the signed data outside the control of an = attacker=20 >>>>>>>> is a >>>>>> good >>>>>>> thing. (having a nonce or message ID in the envelope is = possible=20 >>>>>>> though >>>>>> not >>>>>>> yet required in JWS.) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I am still of the opinion that putting the base64 encoded = envelope >>>>>> inside >>>>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>>>=20 >>>>>>>> Another structure to hold the attributes adds more complexity, = as=20 >>>>>>>> would >>>>>>> saying that they need to be inside the signed object. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I think part of this is that as one of the openID Connect = authors=20 >>>>>>>> I look >>>>>> at this >>>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>>=20 >>>>>>>> For that simple processing with one signature is a high = priority=20 >>>>>>>> for >>>>>> adoption. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =46rom a general signing/encrypting of documents point of view = you >>>>>>> legitimately have different priorities. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I know it is hard to prove a negative but It is also going to = be >>>>>> difficult for me >>>>>>> to go back to security people at google Facebook and other = places=20 >>>>>>> and explain how not integrity protecting the header could be = better=20 >>>>>>> than integrity protecting it. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> It seems that I would be reduced to arguing that this is no = worse=20 >>>>>>>> than >>>>>> CMS >>>>>>> and that hasn't been proven insecure yet. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Allowing a possible attacker to control the hash output, and = not >>>>>> integrity >>>>>>> protecting the additional data, seems like something I am bound = to=20 >>>>>>> regret >>>>>> in >>>>>>> the future. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Hey John, >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Interesting points, but I don't think they actually apply = here. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to downgrade attacks: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> The attack that RFC 5752 is concerned with is when an attacker=20= >>>>>>>>> strips >>>>>>> signatures from a signed message, so that the only ones left are=20= >>>>>>> ones he >>>>>> can >>>>>>> tamper with. So the integrity protection here is "horizontal"; = it=20 >>>>>>> goes >>>>>> across >>>>>>> signatures. The integrity protection in JWS/JWE is "vertical" = --=20 >>>>>>> it only >>>>>> protects >>>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to "brown bag" attacks: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> The root of this attack is ambiguity about what content is=20 >>>>>>>>> *signed* >>>>>>>>=20 >>>>>>>>> vs. what content is *used*. If an application doesn't verify=20= >>>>>>>>> that >>>>>>>>=20 >>>>>>>>> it's actually using the stuff that's signed, then it can be=20 >>>>>>>>> tricked >>>>>>>>=20 >>>>>>>>> into accepting something unsigned. (Cf. >>>>>>>>=20 >>>>>>>>> ) >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> However, I don't think any of the current proposals have that = problem. >>>>>>> In JWE/JWS, the signed content is right there between the dots, = and=20 >>>>>>> in >>>>>> JSMS, >>>>>>> it's in the "content" element. The current JSMS draft does = allow=20 >>>>>>> detached signatures, but with a "voids your warranty" sticker on = it. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> In any case, these attacks have nothing to do with whether the >>>>>>> cryptographic parameters are integrity-protected with the = content. =20 >>>>>>> The example attacks in the IBM still work regardless -- the = whole=20 >>>>>>> point of the attack is that the cryptographic processing is the=20= >>>>>>> same, only the >>>>>> (non-crypto) >>>>>>> matching of content is flawed. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to "arbitrary attributes": >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> We can have that here, too, but you need canonicalization. = And >>>>>> base64- >>>>>>> encoding is not not canonicalization -- it just waves its hands=20= >>>>>>> over the question of equivalence. In my opinion, we should keep=20= >>>>>>> the cryptographic object simple by disallowing attributes, and = push=20 >>>>>>> the attributes you would sign inside of the thing being signed. = If=20 >>>>>>> people really do want >>>>>> attributes, it >>>>>>> doesn't seem to me like JSON canonicalization is very hard. I = can=20 >>>>>>> do it >>>>>> in 19 >>>>>>> lines of python: >>>>>>>>=20 >>>>>>>>> >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard too "meta-data in the body": >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> It seems to me like if we're trying to define a general format=20= >>>>>>>>> for >>>>>> applying >>>>>>> security protections, then we ought to keep out things that = aren't >>>>>> strictly >>>>>>> security relevant. Those things can go in application-specific=20= >>>>>>> content >>>>>> types >>>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to "defense in depth" and selling this to = government >>>>>>> agencies: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> CMS, via S/MIME, is in broad use across multiple federal = agencies=20 >>>>>>>>> and >>>>>>> large enterprises. JSMS is essentially a profile of CMS (see=20 >>>>>>> Section 7), >>>>>> and >>>>>>> has the same security properties. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Hi Richard, >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Originally we only integrity protected the header for = signing. =20 >>>>>>>>>> We >>>>>> added >>>>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>>>> encryption can >>>>>> also >>>>>>> be used for sender verification. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I understand the argument that it makes things simpler if we=20= >>>>>>>>>> don't >>>>>>> integrity protect the header information. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> However xmldsig, provides integrity over those elements to=20= >>>>>>>>>> prevent >>>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> CMS may not typically provide that integrity protection but I=20= >>>>>>>>>> think >>>>>> Jim >>>>>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>>>>=20 >>>>>>>>>> Given they are on this list they can speak to their view on=20= >>>>>>>>>> integrity >>>>>> over >>>>>>> the crypto parameters. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>>>> Carlo/Brown >>>>>>> Bag attack that needs to be considered if we move to something = more=20 >>>>>>> like a detached signature. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> The other design consideration is that we wanted to be able = to=20 >>>>>>>>>> sign >>>>>>> arbitrary byte strings not just JSON. You could sign XML if = you wanted. >>>>>>>>=20 >>>>>>>>>> That prevented us from including meta-data in the body as we=20= >>>>>>>>>> didn't >>>>>>> want to touch it. That left us with the header to include = additional >>>>>> elements >>>>>>> in. >>>>>>>>=20 >>>>>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>>> arbitrary >>>>>>> attributes not unlike the current JOSE spec. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Especially for something that will be used with JWT security=20= >>>>>>>>>> tokens I >>>>>> will >>>>>>> have a hard time making the argument to NIST and others that = need=20 >>>>>>> to approve this format that not integrity protecting the header=20= >>>>>>> parameters is appropriate defence in depth, for something that=20= >>>>>>> might be replacing signed SAML assertions in some applications. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I do understand how not integrity protecting the header will=20= >>>>>>>>>> make >>>>>> some >>>>>>> things easier, however I can't agree that the benefit outweighs = the=20 >>>>>>> disadvantages. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>=20 >>>>>>>>>> John B. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Hey Mike, >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Thanks for having some back-and-forth with me on this. I = think=20 >>>>>>>>>>> this >>>>>> is a >>>>>>> good discussion to have right now. I would like to discuss some >>>>>> high-level >>>>>>> points, and then I'll respond inline to your precise points. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 >>>>>>>>>>> define >>>>>> JSON- >>>>>>> based formats for integrity and confidentiality protections. = JWE=20 >>>>>>> and JWS don't fit that requirement, so we should re-consider = their=20 >>>>>>> adoption and >>>>>> call >>>>>>> for new candidates. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Major points: >>>>>>>>=20 >>>>>>>>>>> 1. JOSE is JSON >>>>>>>>=20 >>>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>>=20 >>>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Part 1: JOSE is JSON >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> The JOSE WG charter calls out four deliverables, three of = which=20 >>>>>>>>>>> are >>>>>>> explicitly required to be JSON: >>>>>>>>=20 >>>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>>=20 >>>>>>>>>>> -- "JSON-structured encryption" >>>>>>>>=20 >>>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>>=20 >>>>>>>>>>> (The fourth is just a list of algorithms, which should be = JSON=20 >>>>>>>>>>> as >>>>>>>>=20 >>>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20= >>>>>>>>>>> suitable >>>>>>>>=20 >>>>>>>>>>> candidates to fulfill the working group's milestones. (At=20= >>>>>>>>>>> least in >>>>>>>>=20 >>>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>>=20 >>>>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>>>> especially >>>>>>>>=20 >>>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20= >>>>>>>>>>> drafts >>>>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>>>> cryptographic parameters within the integrity protection, they = have=20 >>>>>>> to have the headers included as base64-encoded strings. That=20 >>>>>>> obviously adds a lot of >>>>>> complexity >>>>>>> to encoding and decoding -- for example, you have to keep the=20 >>>>>>> encoded header around even after you've decoded it! -- and just = plain more octets. >>>>>>> The support for multiple recipients and multiple signatures is = both >>>>>> unweildy >>>>>>> (matching up parallel indices for headers and signatures) and=20 >>>>>>> inefficient (multiple integrity check values in encrypted = objects). >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic = wisdom=20 >>>>>>>>>>> that >>>>>>> went into CMS, while making the syntax pure JSON and as simple = as >>>>>> possible. >>>>>>> Multiple signatures and multiple recipients are supported with=20= >>>>>>> absolute minimum overhead. So I think it's worth consideration = by=20 >>>>>>> the working >>>>>> group. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>>>> requires >>>>>>>>=20 >>>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>>=20 >>>>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>>>> included >>>>>>>>=20 >>>>>>>>>>> within the integrity protection. I'm not aware of any = reason=20 >>>>>>>>>>> for >>>>>>>>=20 >>>>>>>>>>> including the cryptographic parameters in the integrity = check, >>>>>>>>=20 >>>>>>>>>>> instead of only integrity-protecting the content itself. =20 >>>>>>>>>>> Indeed, if >>>>>>>>=20 >>>>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>>>> cryptographic >>>>>>>>=20 >>>>>>>>>>> parameters, it would be a pretty big deal, since neither CMS=20= >>>>>>>>>>> nor IKE >>>>>>>>=20 >>>>>>>>>>> nor provides this protection. (TLS does provide a signature=20= >>>>>>>>>>> over >>>>>>>>=20 >>>>>>>>>>> the algorithms, but only as a way to bind the public key to = the >>>>>>>>=20 >>>>>>>>>>> session.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except = for >>>>>>> attributes that are included in the protected content = (signedAttrs=20 >>>>>>> / authenticatedAttrs), which need to be DER-encoded. In JSMS, = we=20 >>>>>>> don't allow those parameters, so there is no need for = canonicalization at all. >>>>>> All the >>>>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>>>> protected content. In that regard, JSMS is even simpler than = JWE/JWS. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>>>> derivatives >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I have absolutely no objection to defining a compact, = URL-safe >>>>>> format. >>>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20= >>>>>>> example >>>>>> from >>>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> { >>>>>>>>=20 >>>>>>>>>>> "v":1, >>>>>>>>=20 >>>>>>>>>>> "t":"au", >>>>>>>>=20 >>>>>>>>>>> "a":"hs256", >>>>>>>>=20 >>>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>>=20 >>>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>>=20 >>>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>>=20 >>>>>>>>>>> } >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20= >>>>>>>>>>> only >>>>>>> use >>>>>>>>=20 >>>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a = step >>>>>>>>=20 >>>>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>>>> AuthenticatedData, >>>>>>>>=20 >>>>>>>>>>> we can emulate JWS by moving the content and MAC fields = outside >>>>>>> and >>>>>>>>=20 >>>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and = only >>>>>>>>=20 >>>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put = the=20 >>>>>>>>>>> code >>>>>>>>=20 >>>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>>>> objective, >>>>>> but it >>>>>>> makes *much* more sense to derive that from a full-size, usable,=20= >>>>>>> JSON format than the other way around. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Responses to specific points inline below. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before=20= >>>>>>>>>>>> doing >>>>>> so, I'll >>>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>>> understanding >>>>>>> and consensus, rather than taking the point of view that the = status=20 >>>>>>> quo is >>>>>> the >>>>>>> only reasonable outcome. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Not being JSON >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> This was by design, so that the results are URL-safe. This = is >>>>>> required, >>>>>>> for instance, for them to be used as OAuth Bearer Tokens. At = the=20 >>>>>>> request >>>>>> of >>>>>>> the working group, closely related pure-JSON drafts were also = published. >>>>>>> See: >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json >>>>>>>>>>>> -seri >>>>>>>>=20 >>>>>>>>>>>> alization-01 and >>>>>>>>=20 >>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-jso >>>>>>>>>>>> n-ser >>>>>>>>=20 >>>>>>>>>>>> ialization-01 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Use them if you prefer if they better suit your use cases. =20= >>>>>>>>>>>> They >>>>>> could >>>>>>> be adopted as working group documents, if there's interest. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> See above. These are super-clunky, and the need to be the = main >>>>>>> focus of the WG, not an afterthought. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> The JSON serialization drafts above do, again, in response = to=20 >>>>>>>>>>>> use >>>>>>> cases presented by the working group. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> See above. Because of the unnecessary inclusion of the = header=20 >>>>>>>>>>> in >>>>>> the >>>>>>> integrity check, this is far less efficient than it should be. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Functionally, these are very similar operations, at least = from=20 >>>>>>>>>>>> an >>>>>>> implementation perspective, so it's not clear that making a = clear >>>>>> distinction >>>>>>> would help either developers or adoption in any practical way. =20= >>>>>>> They >>>>>> achieve >>>>>>> overlapping, but admittedly sometimes different goals. I = believe=20 >>>>>>> that developers can be trusted to use the algorithms that = achieve=20 >>>>>>> their applications' goals without making a hard distinction = between the two. >>>>>> But >>>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>>> brighter-line >>>>>>> distinction might be useful or necessary. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> It's important if you want to do MACs with anything other = than=20 >>>>>>>>>>> pre- >>>>>>> shared keys. If you want to do anything more advanced, you need = to=20 >>>>>>> have wrapped keys, in which case an object with a MAC starts to=20= >>>>>>> look a lot more like a JWE than a JWS. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>=20 >>>>>>>>>>>> establishment modalities >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> This seems like an area where the existing drafts could be=20= >>>>>>>>>>>> refined >>>>>> to >>>>>>> add descriptions for additional establishment modalities, = possibly=20 >>>>>>> based upon your ideas and descriptions, should the working group=20= >>>>>>> decide to do >>>>>> so. >>>>>>> What additional modalities do you have use cases for that you=20 >>>>>>> believe are not achievable or straightforward with the existing=20= >>>>>>> drafts? The existing modalities supported are largely those = that=20 >>>>>>> existing developers had told >>>>>> us >>>>>>> they needed and draw both from the precursor = draft-jones-json-web-*=20 >>>>>>> documents and draft-rescorla-jsms. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Bear in mind that the balance that the current drafts try = to=20 >>>>>>>>>>>> strike >>>>>> is >>>>>>> keeping the Mandatory to Implement (MTI) feature footprint small=20= >>>>>>> enough that developers, including Web developers, are likely to=20= >>>>>>> adopt the specs, while still providing enough functionality to = make them generally useful. >>>>>> As >>>>>>> in any balance, it's often possible to shift things a bit and = still >>>>>> maintain the >>>>>>> balance, but I'd like people to keep the ubiquitous adoption = goal >>>>>> front-and- >>>>>>> center when proposing additional functionality. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>>=20 >>>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to = understand >>>>>>>>=20 >>>>>>>>>>>> that!) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I agree that we need to find a reasonable MTI. The current=20= >>>>>>>>>>> JSMS >>>>>> draft >>>>>>> doesn't really specify which parts are MTI, beyond basic things=20= >>>>>>> like >>>>>> base64url >>>>>>> encoding and ignoring unknown fields. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> My main concern is that JWS and JWE don't really tell me = which >>>>>> fields >>>>>>> need to be present for which use case. If I'm putting a MAC on = a JWS vs. >>>>>> a >>>>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>>>> Whereas in >>>>>> JSMS, >>>>>>> I think these things are much clearer due to the separation of = the=20 >>>>>>> use >>>>>> cases >>>>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures=20= >>>>>>> and wrapped keys into sub-objects. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Most JSON documents aren't clearly typed; instead, = developers=20 >>>>>>>>>>>> and >>>>>>> implementations understand from context what the meaning of each = field is. >>>>>>> XML is clearly typed, but developers are voting with their feet = by=20 >>>>>>> moving >>>>>> to >>>>>>> JSON. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> What practical advantages resulting from overlaying a = typing >>>>>>> infrastructure on JSON do you believe are worth the potential = costs=20 >>>>>>> of >>>>>> doing >>>>>>> so? BTW, I'm not opposed to having a JSON schema description of=20= >>>>>>> the JOSE JSON data structures like JSMS did in=20 >>>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, = but=20 >>>>>>> I'll remark that this an informative >>>>>> tool, not >>>>>>> a normative one. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I actualy don't have a hugely urgent requirement here = either. =20 >>>>>>>>>>> It's >>>>>>> something that others in the WG had requested, which is trivial = to=20 >>>>>>> add in JSMS, but not in JWE/JWS -- again because of the = unnecessary=20 >>>>>>> integrity protection of the header. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> An optional version field could be added if the working = group >>>>>>>>=20 >>>>>>>>>>>> desires, however the last time the working group discussed = it,=20 >>>>>>>>>>>> they >>>>>>>>=20 >>>>>>>>>>>> decided not to do so. Rather, specs like this effectively=20= >>>>>>>>>>>> become >>>>>>>>=20 >>>>>>>>>>>> "versioned" when revised in a way that new fields are = added. =20 >>>>>>>>>>>> If >>>>>>>>=20 >>>>>>>>>>>> you understand the new fields, you support that new = version. =20 >>>>>>>>>>>> (Note >>>>>>>>=20 >>>>>>>>>>>> that this is independent of whether there is a version = number >>>>>>>>=20 >>>>>>>>>>>> field, which according to some participants in the previous >>>>>>>>=20 >>>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>>=20 >>>>>>>>>>>> information.) >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> I'm not religious about not having a version number field, = but >>>>>> often >>>>>>> "less is more". >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Indeed, I'm not religious either. It just seems like a = general=20 >>>>>>>>>>> good >>>>>> idea >>>>>>> to state this directly as opposed to having parsers divine it = based=20 >>>>>>> on >>>>>> which >>>>>>> fields are present. To quote RFC 5652: >>>>>>>>=20 >>>>>>>>>>> " >>>>>>>>=20 >>>>>>>>>>> Each of the major data structures includes a version number = as=20 >>>>>>>>>>> the >>>>>>>>=20 >>>>>>>>>>> first item in the data structure. The version numbers are=20= >>>>>>>>>>> intended >>>>>>>>=20 >>>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20= >>>>>>>>>>> check >>>>>>> the >>>>>>>>=20 >>>>>>>>>>> version number prior to attempting a decode, and if a decode=20= >>>>>>>>>>> error >>>>>>>>=20 >>>>>>>>>>> occurs, then the version number is checked as part of the = error >>>>>>>>=20 >>>>>>>>>>> handling routine. This is a reasonable approach; it places=20= >>>>>>>>>>> error >>>>>>>>=20 >>>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>>=20 >>>>>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>>>>=20 >>>>>>>>>>> " >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Best, >>>>>>>>=20 >>>>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Best wishes, >>>>>>>>=20 >>>>>>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>=20 >>>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>>=20 >>>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>>=20 >>>>>>>>>>>> To: Mike Jones >>>>>>>>=20 >>>>>>>>>>>> Cc: jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>>=20 >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. =20= >>>>>>>>>>>> IMO, >>>>>> the >>>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>>=20 >>>>>>>>>>>> -- Not being JSON >>>>>>>>=20 >>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>=20 >>>>>>>>>>>> establishment modalities >>>>>>>>=20 >>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>=20 >>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20= >>>>>>>>>>>> would be >>>>>>> simple to adapt them to address these deficiencies. So I just = did=20 >>>>>>> a >>>>>> re-write. >>>>>>> If you think they can be addressed within the current framework,=20= >>>>>>> please explain. I just found it simpler to start from whole = cloth. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Hi Richard, >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>>>>> documents, >>>>>>> I encourage you to ask about them on the list. The documents = have=20 >>>>>>> significant history going back to mid-2010 when convergence=20 >>>>>>> discussions started among people with four different JSON = signing &=20 >>>>>>> encryption proposals. JWT and the current JOSE specs and=20 >>>>>>> implementations are the result. I realize that not all the JOSE=20= >>>>>>> participants were part of those discussions from the beginning=20= >>>>>>> (although many were) and so teasing out the rationale for = specific=20 >>>>>>> decisions might help people better understand the choices made, = and=20 >>>>>>> hopefully thereby increase consensus behind the eventual working = group choices. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 >>>>>>>>>>>>> below, >>>>>> maybe we >>>>>>> can start a discussion on that basis. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Best wishes, >>>>>>>>=20 >>>>>>>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>=20 >>>>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On >>>>>>>>=20 >>>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>>=20 >>>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>>=20 >>>>>>>>>>>>> To: jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Dear JOSE WG, >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>>>> thorough >>>>>>> review of the JW* specs, I was kind of puzzled by some of the=20 >>>>>>> design decisions. So I also went through and wrote an = alternative=20 >>>>>>> format, this >>>>>> time >>>>>>> taking a more of a cue from CMS. A link to the document is = below. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Summary of differences: >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the = header >>>>>>>>=20 >>>>>>>>>>>>> parameters are represented in JSON. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS allows for full algorithm agility in key = agreement,=20 >>>>>>>>>>>>> while >>>>>> JWE >>>>>>>>=20 >>>>>>>>>>>>> only allows ECDH-ES. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>>>>=20 >>>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>>> WrappedKey >>>>>>>>=20 >>>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires = re- >>>>>>>>=20 >>>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o The signature and MAC functions of the JWS object are=20= >>>>>>>>>>>>> separated >>>>>>>>=20 >>>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they = are=20 >>>>>>>>>>>>> in JWE >>>>>>>>=20 >>>>>>>>>>>>> and JWS. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS,=20= >>>>>>>>>>>>> but >>>>>> could >>>>>>>>=20 >>>>>>>>>>>>> be added without significant change. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown = header >>>>>>>>=20 >>>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>>>> implementation >>>>>> (based >>>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>>=20 >>>>>>>>>>>>> >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Comments are very welcome. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Begin forwarded message: >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>=20 >>>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>>=20 >>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>>=20 >>>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has = been >>>>>>>>=20 >>>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to = the=20 >>>>>>>>>>>>>> IETF >>>>>>>>=20 >>>>>>>>>>>>>> repository. >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>>=20 >>>>>>>>>>>>>> Revision: 00 >>>>>>>>=20 >>>>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>>>=20 >>>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>>=20 >>>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>>=20 >>>>>>>>>>>>>> Number of pages: 25 >>>>>>>>=20 >>>>>>>>>>>>>> URL: >>>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>>> jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>>> Status: >>>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>>=20 >>>>>>>>>>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> Abstract: >>>>>>>>=20 >>>>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>>>> cryptographically >>>>>>>>=20 >>>>>>>>>>>>>> secured messages. While the IETF has defined a number of >>>>>>> formats >>>>>>>>=20 >>>>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings=20= >>>>>>>>>>>>>> which >>>>>>>>=20 >>>>>>>>>>>>>> are not easy to use in modern applications. This = document >>>>>>>>=20 >>>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), = a=20 >>>>>>>>>>>>>> new >>>>>>>>=20 >>>>>>>>>>>>>> cryptographic message format which is based on JavaScript=20= >>>>>>>>>>>>>> Object >>>>>>>>=20 >>>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>>>>> generate >>>>>>> and parse. >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> The IETF Secretariat >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>> Chairman, OpenID Foundation >>>>>>>> http://nat.sakimura.org/ >>>>>>>> @_nat_en >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From tonynad@microsoft.com Tue Jun 26 14:24: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 1310B11E8095 for ; Tue, 26 Jun 2012 14:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGiCrKM1UGi4 for ; Tue, 26 Jun 2012 14:24:38 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 669CA11E808A for ; Tue, 26 Jun 2012 14:24:37 -0700 (PDT) Received: from mail39-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 21:22:55 +0000 Received: from mail39-am1 (localhost [127.0.0.1]) by mail39-am1-R.bigfish.com (Postfix) with ESMTP id 2720B8054B for ; Tue, 26 Jun 2012 21:22:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zz98dI9371I936eI168aJ148cI542M1432I1418I41c5N4015Izz1202h1082kzz1033IL8275eh8275bh8275dh5eeeKf73b6ila1495iz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail39-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1 (MessageSwitch) id 134074577332944_13970; Tue, 26 Jun 2012 21:22:53 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.243]) by mail39-am1.bigfish.com (Postfix) with ESMTP id 05ACF22004B for ; Tue, 26 Jun 2012 21:22:53 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 21:22:52 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 26 Jun 2012 21:24:08 +0000 Received: from mail75-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Tue, 26 Jun 2012 21:22:10 +0000 Received: from mail75-va3 (localhost [127.0.0.1]) by mail75-va3-R.bigfish.com (Postfix) with ESMTP id 5FD5D2C01B7 for ; Tue, 26 Jun 2012 21:22:10 +0000 (UTC) Received: from mail75-va3 (localhost.localdomain [127.0.0.1]) by mail75-va3 (MessageSwitch) id 134074572718257_20494; Tue, 26 Jun 2012 21:22:07 +0000 (UTC) Received: from VA3EHSMHS037.bigfish.com (unknown [10.7.14.242]) by mail75-va3.bigfish.com (Postfix) with ESMTP id EA38538023F; Tue, 26 Jun 2012 21:22:06 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS037.bigfish.com (10.7.99.47) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 21:22:07 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0152.000; Tue, 26 Jun 2012 21:23:48 +0000 From: Anthony Nadalin To: "Richard L. Barnes" , John Bradley Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: AQHNU9/BpUIQ1yqrBUKIlgeMojwvspcNGzYAgAAARJA= Date: Tue, 26 Jun 2012 21:23:47 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> In-Reply-To: <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%BBN.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$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: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:24:41 -0000 Because it's in most libraries and it works well for key wrap and it's in a= lot of products. That's fine to discuss (and did not say it was not discus= sed) but I don't recall reaching a consensus on that point yet. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Tuesday, June 26, 2012 2:20 PM To: John Bradley Cc: Anthony Nadalin; Jim Schaad; jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt Why would you ever want to use ECB mode? If you want something fast and pa= rallelizable, CTR mode is a lot better. We had discussed Dave McGrew's draft as a mechanism for specifying general = AEAD algorithms: --Richard On Jun 26, 2012, at 5:07 PM, John Bradley wrote: > You should suggest adding that as a supported algorithm. >=20 > We wanted to keep the core set down to a reasonable number to encourage i= nteroparability. >=20 > AES-ECB + HMAC can be a option if the WG wants it. >=20 > John B. > On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote: >=20 >> AES-ECB is also a popular alternative >>=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Tuesday, June 26, 2012 1:59 PM >> To: Anthony Nadalin >> Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org >> Subject: Re: [jose] New Version Notification for=20 >> draft-barnes-jose-jsms-00.txt >>=20 >> Yes that is why we added the composite HMAC + AES-CBC. We can debate i= f that is an algorithm or mandatory integrity with non AEAD algorithms, but= the effect of integrity protecting the header remains in both cases. >>=20 >> John B. >>=20 >> On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >>=20 >>> Not sure there was a WG decision and what that would mean if there was,= as there are many libraries out there that don't support the encryption wi= th integrity algorithms, so need to support alternative means of things lik= e key wrap that could have an integrity check. >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >>> Of John Bradley >>> Sent: Tuesday, June 26, 2012 12:30 PM >>> To: Richard L. Barnes >>> Cc: Jim Schaad; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for=20 >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> There was a WG decision to not allow encryption without integrity. Ji= m and others call that sender verification. >>>=20 >>> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>>=20 >>> The JWE/JWS specs don't control the body. That is intended to be arbi= trary content. >>>=20 >>> We do have s JWT spec that covers the body for security tokens. The i= dea was to separate that from signing and encryption so that signing and en= cryption can be used for other objects. >>>=20 >>> John B. >>>=20 >>> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>>=20 >>>>> Now that we are mandating JWE sender verification people will be usin= g JWE with symmetric keys or key agreement. >>>>> In those cases one can easily argue that the header should be protect= ed as much as in HMAC. >>>>=20 >>>> Can you clarify the scope of "we are mandating"? >>>>=20 >>>>=20 >>>>> There may well be signing_time or other elements that would go into t= he header as well for JWE. >>>>=20 >>>> Why do these need to go into the header rather than the body? >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Regards >>>>> John B. >>>>>=20 >>>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>>=20 >>>>>> >>>>>>=20 >>>>>> Richard, >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>>> Behalf Of Richard L. Barnes >>>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>>> To: Nat Sakimura >>>>>>> Cc: Mike Jones; jose@ietf.org >>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>> draft-barnes-jose-jsms- 00.txt >>>>>>>=20 >>>>>>> Hi Nat, >>>>>>>=20 >>>>>>> I'm not sure what X.509 fiasco you're referring to. There was a=20 >>>>>>> recent >>>>>> MD5 >>>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact,=20 >>>>>>> there have >>>>>> been >>>>>>> recommendations for preventing this attack in X.509 since 2005 [2].= =20 >>>>>>> As >>>>>> was >>>>>>> noted on the SAAG list, the real news here is that Microsoft=20 >>>>>>> wasn't >>>>>> following >>>>>>> any of those recommendations. >>>>>>>=20 >>>>>>> JWS would have had the same problem as X.509. The attack did=20 >>>>>>> not modify the cryptographic parameters (anything that would=20 >>>>>>> have gone in the header), it would not have been thwarted by the=20 >>>>>>> integrity protection we're worrying about. >>>>>>>=20 >>>>>>> Actually, the header signing that JWS does makes it even nicer=20 >>>>>>> for the >>>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20 >>>>>>> header >>>>>> value >>>>>>> is entirely static for a given signer, it's easy to use as a fixed = prefix. >>>>>> If JWS just >>>>>>> signed the content, then the application could include a=20 >>>>>>> something random up front to prevent such prefix-based attacks. >>>>>>>=20 >>>>>>=20 >>>>>> I don't believe that this is a true statement. If you had a=20 >>>>>> prefix or just signed what was given to you (i.e. no prefix), it=20 >>>>>> would make no difference in terms of the attack for Flame. Flame=20 >>>>>> could always use a fixed prefix of its own design rather than=20 >>>>>> using the fixed header that is generated by having JWS sign the head= er information. >>>>>>=20 >>>>>>> It's tempting to say that we should just add randomness to the=20 >>>>>>> JOSE >>>>>> format. >>>>>>> But the real lesson of the Flame/MD5 attacks is operational: If=20 >>>>>>> you're >>>>>> signing >>>>>>> something that somebody else gave you, make sure that you're not=20 >>>>>>> signing exactly what they gave you. Follow the recommendations=20 >>>>>>> of RFC 4270. In other contexts, there's no need of similar=20 >>>>>>> random elements; it just adds complexity. >>>>>>=20 >>>>>> This is definitely a true statement in all events and is=20 >>>>>> something that should be added to the Security Considerations sectio= n. >>>>>>=20 >>>>>> That being said, I think that there are valid reasons for wanting=20 >>>>>> to protect the header information by some authentication processing. >>>>>> PKIX certificates protect the signature algorithm information (by=20 >>>>>> copying the data into the to be signed block) and CMS has long=20 >>>>>> allowed for information to be included in the signed attributes=20 >>>>>> area that identifies the algorithms used, the certificates used=20 >>>>>> and so forth. There are also other things that we might find to=20 >>>>>> be convenient to be placed in the header information that is=20 >>>>>> current not there (a signing time and embedded content type comes=20 >>>>>> to mind) that would be a product either of specific types of signatu= res or becomes a common attribute to be placed there. >>>>>>=20 >>>>>> In terms of encryption operations, I remember in the past that I=20 >>>>>> have had either corrupted encrypted streams or corrupted IVs and=20 >>>>>> had a successful decryption that later generated other problems=20 >>>>>> when trying to parse. This is less of an issue with AEAD=20 >>>>>> algorithms as they have a much stricter rule on when the stream decr= ypts correctly. >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>>>=20 >>>>>>> --Richard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> [1]=20 >>>>>>> >>>>>>> [2] >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>>=20 >>>>>>>> Especially after the X.509 fiasco, I strongly believe that=20 >>>>>>>> having >>>>>> integrity >>>>>>> check over the metadata is a good thing. It is such a little=20 >>>>>>> effort that >>>>>> gives us >>>>>>> much more protection down the road. In this sense, I fully agree=20 >>>>>>> with Ben here. We should have integrity protection over the header. >>>>>>>>=20 >>>>>>>> Nat >>>>>>>>=20 >>>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>>> wrote: >>>>>>>> Two years ago when the developer community needing a=20 >>>>>>>> JSON-friendly >>>>>>> token format was designing the JSON Web Token (JWT), we=20 >>>>>>> explicitly asked security experts whether the header parameters=20 >>>>>>> should be integrity protected or not. Among them, Ben Laurie=20 >>>>>>> was one of the voices saying >>>>>> that >>>>>>> securing them was the right thing to do. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> He argued that if the parameters can be protected in a=20 >>>>>>>> practical manner, >>>>>>> then they should. Doing so provides an additional hurdle that=20 >>>>>>> attackers would have to surmount. For example, if they can try=20 >>>>>>> to substitute a >>>>>> weaker >>>>>>> authentication scheme, then they must figure out how to make it=20 >>>>>>> authenticate correctly despite some plaintext they can't control=20 >>>>>>> - the >>>>>> header >>>>>>> parameters. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Ben also took the position that paring security protocols down=20 >>>>>>>> to the >>>>>> least >>>>>>> you can get away with, given attacks you can think of, is not a=20 >>>>>>> good >>>>>> design >>>>>>> principle. If there is not a strong argument against including=20 >>>>>>> a feature >>>>>> that >>>>>>> may make it harder for attackers, then that feature should be inclu= ded. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I agree with him. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The decision to provide integrity protection for the headers is >>>>>> documented >>>>>>> in the session notes at http://self-issued.info/?p=3D361, which sai= d: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>>=20 >>>>>>>> Given that the envelope is extensible and therefore may contain >>>>>> security- >>>>>>> sensitive information, we reached a consensus (with input from=20 >>>>>>> Ben Laurie via IM) that the combination envelope.payload must be si= gned. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I believe that logic is as sound today as it was then. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>>>> community's >>>>>>> decision to provide integrity protection for the headers. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best=20 >>>>>>>> wishes, >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>>>> Behalf Of >>>>>>> John Bradley >>>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>>> To: Richard L.Barnes >>>>>>>> Cc: jose@ietf.org >>>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>>> draft-barnes-jose-jsms- >>>>>>> 00.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi Richard, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding=20 >>>>>>>> and not >>>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>>=20 >>>>>>>> There are possible hash truncation attacks by shortening SHA256=20 >>>>>>>> to >>>>>> SHA224 >>>>>>> as an example (I know we preclude truncated hashes at the moment). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The bad feeling I get around this is that if there is a=20 >>>>>>>> scenario where >>>>>> the >>>>>>> attacker controls the plaintext to be signed and there is no=20 >>>>>>> signer >>>>>> controlled >>>>>>> text contributed there are potential bad things that could=20 >>>>>>> happen down the road. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This bit us with x509 certs not that long ago (yes with MD5 >>>>>>>> admittedly) >>>>>>> where the attacker could use a certificate extension to include=20 >>>>>>> extra data >>>>>> and >>>>>>> cause a pre collided hash to be generated. >>>>>>>>=20 >>>>>>>> Having part of the signed data outside the control of an=20 >>>>>>>> attacker is a >>>>>> good >>>>>>> thing. (having a nonce or message ID in the envelope is=20 >>>>>>> possible though >>>>>> not >>>>>>> yet required in JWS.) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I am still of the opinion that putting the base64 encoded=20 >>>>>>>> envelope >>>>>> inside >>>>>>> the hash calculation is a valid way to allow additional attributes. >>>>>>>>=20 >>>>>>>> Another structure to hold the attributes adds more complexity, =20 >>>>>>>> as would >>>>>>> saying that they need to be inside the signed object. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I think part of this is that as one of the openID Connect=20 >>>>>>>> authors I look >>>>>> at this >>>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>>=20 >>>>>>>> For that simple processing with one signature is a high=20 >>>>>>>> priority for >>>>>> adoption. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> From a general signing/encrypting of documents point of view=20 >>>>>>>> you >>>>>>> legitimately have different priorities. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I know it is hard to prove a negative but It is also going to=20 >>>>>>>> be >>>>>> difficult for me >>>>>>> to go back to security people at google Facebook and other=20 >>>>>>> places and explain how not integrity protecting the header could=20 >>>>>>> be better than integrity protecting it. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> It seems that I would be reduced to arguing that this is no=20 >>>>>>>> worse than >>>>>> CMS >>>>>>> and that hasn't been proven insecure yet. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Allowing a possible attacker to control the hash output, and=20 >>>>>>>> not >>>>>> integrity >>>>>>> protecting the additional data, seems like something I am bound=20 >>>>>>> to regret >>>>>> in >>>>>>> the future. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Hey John, >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Interesting points, but I don't think they actually apply here. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to downgrade attacks: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> The attack that RFC 5752 is concerned with is when an attacker=20 >>>>>>>>> strips >>>>>>> signatures from a signed message, so that the only ones left are=20 >>>>>>> ones he >>>>>> can >>>>>>> tamper with. So the integrity protection here is "horizontal";=20 >>>>>>> it goes >>>>>> across >>>>>>> signatures. The integrity protection in JWS/JWE is "vertical"=20 >>>>>>> -- it only >>>>>> protects >>>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to "brown bag" attacks: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> The root of this attack is ambiguity about what content is >>>>>>>>> *signed* >>>>>>>>=20 >>>>>>>>> vs. what content is *used*. If an application doesn't verify=20 >>>>>>>>> that >>>>>>>>=20 >>>>>>>>> it's actually using the stuff that's signed, then it can be=20 >>>>>>>>> tricked >>>>>>>>=20 >>>>>>>>> into accepting something unsigned. (Cf. >>>>>>>>=20 >>>>>>>>> ) >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> However, I don't think any of the current proposals have that pro= blem. >>>>>>> In JWE/JWS, the signed content is right there between the dots,=20 >>>>>>> and in >>>>>> JSMS, >>>>>>> it's in the "content" element. The current JSMS draft does=20 >>>>>>> allow detached signatures, but with a "voids your warranty" sticker= on it. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> In any case, these attacks have nothing to do with whether the >>>>>>> cryptographic parameters are integrity-protected with the content. = =20 >>>>>>> The example attacks in the IBM still work regardless -- the=20 >>>>>>> whole point of the attack is that the cryptographic processing=20 >>>>>>> is the same, only the >>>>>> (non-crypto) >>>>>>> matching of content is flawed. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to "arbitrary attributes": >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> We can have that here, too, but you need canonicalization. =20 >>>>>>>>> And >>>>>> base64- >>>>>>> encoding is not not canonicalization -- it just waves its hands=20 >>>>>>> over the question of equivalence. In my opinion, we should keep=20 >>>>>>> the cryptographic object simple by disallowing attributes, and=20 >>>>>>> push the attributes you would sign inside of the thing being=20 >>>>>>> signed. If people really do want >>>>>> attributes, it >>>>>>> doesn't seem to me like JSON canonicalization is very hard. I=20 >>>>>>> can do it >>>>>> in 19 >>>>>>> lines of python: >>>>>>>>=20 >>>>>>>>> >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard too "meta-data in the body": >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> It seems to me like if we're trying to define a general format=20 >>>>>>>>> for >>>>>> applying >>>>>>> security protections, then we ought to keep out things that=20 >>>>>>> aren't >>>>>> strictly >>>>>>> security relevant. Those things can go in application-specific=20 >>>>>>> content >>>>>> types >>>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> With regard to "defense in depth" and selling this to=20 >>>>>>>>> government >>>>>>> agencies: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> CMS, via S/MIME, is in broad use across multiple federal=20 >>>>>>>>> agencies and >>>>>>> large enterprises. JSMS is essentially a profile of CMS (see=20 >>>>>>> Section 7), >>>>>> and >>>>>>> has the same security properties. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Hi Richard, >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Originally we only integrity protected the header for signing. = =20 >>>>>>>>>> We >>>>>> added >>>>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>>>> encryption can >>>>>> also >>>>>>> be used for sender verification. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I understand the argument that it makes things simpler if we=20 >>>>>>>>>> don't >>>>>>> integrity protect the header information. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> However xmldsig, provides integrity over those elements to=20 >>>>>>>>>> prevent >>>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> CMS may not typically provide that integrity protection but I=20 >>>>>>>>>> think >>>>>> Jim >>>>>>> Schaad and Sean Terner created RFC5752 to address downgrade attacks= . >>>>>>>>=20 >>>>>>>>>> Given they are on this list they can speak to their view on=20 >>>>>>>>>> integrity >>>>>> over >>>>>>> the crypto parameters. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>>>> Carlo/Brown >>>>>>> Bag attack that needs to be considered if we move to something=20 >>>>>>> more like a detached signature. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> The other design consideration is that we wanted to be able=20 >>>>>>>>>> to sign >>>>>>> arbitrary byte strings not just JSON. You could sign XML if you w= anted. >>>>>>>>=20 >>>>>>>>>> That prevented us from including meta-data in the body as we=20 >>>>>>>>>> didn't >>>>>>> want to touch it. That left us with the header to include additio= nal >>>>>> elements >>>>>>> in. >>>>>>>>=20 >>>>>>>>>> Not integrity protecting those elements as well would be a probl= em. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>>> arbitrary >>>>>>> attributes not unlike the current JOSE spec. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Especially for something that will be used with JWT security=20 >>>>>>>>>> tokens I >>>>>> will >>>>>>> have a hard time making the argument to NIST and others that=20 >>>>>>> need to approve this format that not integrity protecting the=20 >>>>>>> header parameters is appropriate defence in depth, for something=20 >>>>>>> that might be replacing signed SAML assertions in some applications= . >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> I do understand how not integrity protecting the header will=20 >>>>>>>>>> make >>>>>> some >>>>>>> things easier, however I can't agree that the benefit outweighs=20 >>>>>>> the disadvantages. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>=20 >>>>>>>>>> John B. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Hey Mike, >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Thanks for having some back-and-forth with me on this. I=20 >>>>>>>>>>> think this >>>>>> is a >>>>>>> good discussion to have right now. I would like to discuss some >>>>>> high-level >>>>>>> points, and then I'll respond inline to your precise points. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 >>>>>>>>>>> define >>>>>> JSON- >>>>>>> based formats for integrity and confidentiality protections. =20 >>>>>>> JWE and JWS don't fit that requirement, so we should re-consider=20 >>>>>>> their adoption and >>>>>> call >>>>>>> for new candidates. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Major points: >>>>>>>>=20 >>>>>>>>>>> 1. JOSE is JSON >>>>>>>>=20 >>>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>>=20 >>>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Part 1: JOSE is JSON >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> The JOSE WG charter calls out four deliverables, three of=20 >>>>>>>>>>> which are >>>>>>> explicitly required to be JSON: >>>>>>>>=20 >>>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>>=20 >>>>>>>>>>> -- "JSON-structured encryption" >>>>>>>>=20 >>>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>>=20 >>>>>>>>>>> (The fourth is just a list of algorithms, which should be=20 >>>>>>>>>>> JSON as >>>>>>>>=20 >>>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20 >>>>>>>>>>> suitable >>>>>>>>=20 >>>>>>>>>>> candidates to fulfill the working group's milestones. (At=20 >>>>>>>>>>> least in >>>>>>>>=20 >>>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>>=20 >>>>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>>>> especially >>>>>>>>=20 >>>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20 >>>>>>>>>>> drafts >>>>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>>>> cryptographic parameters within the integrity protection, they=20 >>>>>>> have to have the headers included as base64-encoded strings. =20 >>>>>>> That obviously adds a lot of >>>>>> complexity >>>>>>> to encoding and decoding -- for example, you have to keep the=20 >>>>>>> encoded header around even after you've decoded it! -- and just pla= in more octets. >>>>>>> The support for multiple recipients and multiple signatures is=20 >>>>>>> both >>>>>> unweildy >>>>>>> (matching up parallel indices for headers and signatures) and=20 >>>>>>> inefficient (multiple integrity check values in encrypted objects). >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic=20 >>>>>>>>>>> wisdom that >>>>>>> went into CMS, while making the syntax pure JSON and as simple=20 >>>>>>> as >>>>>> possible. >>>>>>> Multiple signatures and multiple recipients are supported with=20 >>>>>>> absolute minimum overhead. So I think it's worth consideration=20 >>>>>>> by the working >>>>>> group. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>>>> requires >>>>>>>>=20 >>>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>>=20 >>>>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>>>> included >>>>>>>>=20 >>>>>>>>>>> within the integrity protection. I'm not aware of any=20 >>>>>>>>>>> reason for >>>>>>>>=20 >>>>>>>>>>> including the cryptographic parameters in the integrity=20 >>>>>>>>>>> check, >>>>>>>>=20 >>>>>>>>>>> instead of only integrity-protecting the content itself. =20 >>>>>>>>>>> Indeed, if >>>>>>>>=20 >>>>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>>>> cryptographic >>>>>>>>=20 >>>>>>>>>>> parameters, it would be a pretty big deal, since neither CMS=20 >>>>>>>>>>> nor IKE >>>>>>>>=20 >>>>>>>>>>> nor provides this protection. (TLS does provide a signature=20 >>>>>>>>>>> over >>>>>>>>=20 >>>>>>>>>>> the algorithms, but only as a way to bind the public key to=20 >>>>>>>>>>> the >>>>>>>>=20 >>>>>>>>>>> session.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except=20 >>>>>>>>>>> for >>>>>>> attributes that are included in the protected content=20 >>>>>>> (signedAttrs / authenticatedAttrs), which need to be=20 >>>>>>> DER-encoded. In JSMS, we don't allow those parameters, so there is= no need for canonicalization at all. >>>>>> All the >>>>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>>>> protected content. In that regard, JSMS is even simpler than JWE/J= WS. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>>>> derivatives >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I have absolutely no objection to defining a compact,=20 >>>>>>>>>>> URL-safe >>>>>> format. >>>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20 >>>>>>> example >>>>>> from >>>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> { >>>>>>>>=20 >>>>>>>>>>> "v":1, >>>>>>>>=20 >>>>>>>>>>> "t":"au", >>>>>>>>=20 >>>>>>>>>>> "a":"hs256", >>>>>>>>=20 >>>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>>=20 >>>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>>=20 >>>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>>=20 >>>>>>>>>>> } >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20 >>>>>>>>>>> only >>>>>>> use >>>>>>>>=20 >>>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a=20 >>>>>>>>>>> step >>>>>>>>=20 >>>>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>>>> AuthenticatedData, >>>>>>>>=20 >>>>>>>>>>> we can emulate JWS by moving the content and MAC fields=20 >>>>>>>>>>> outside >>>>>>> and >>>>>>>>=20 >>>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and=20 >>>>>>>>>>> only >>>>>>>>=20 >>>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put=20 >>>>>>>>>>> the code >>>>>>>>=20 >>>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>>>> objective, >>>>>> but it >>>>>>> makes *much* more sense to derive that from a full-size, usable,=20 >>>>>>> JSON format than the other way around. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Responses to specific points inline below. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before=20 >>>>>>>>>>>> doing >>>>>> so, I'll >>>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>>> understanding >>>>>>> and consensus, rather than taking the point of view that the=20 >>>>>>> status quo is >>>>>> the >>>>>>> only reasonable outcome. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Not being JSON >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> This was by design, so that the results are URL-safe. This=20 >>>>>>>>>>>> is >>>>>> required, >>>>>>> for instance, for them to be used as OAuth Bearer Tokens. At=20 >>>>>>> the request >>>>>> of >>>>>>> the working group, closely related pure-JSON drafts were also publi= shed. >>>>>>> See: >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-j >>>>>>>>>>>> son >>>>>>>>>>>> -seri >>>>>>>>=20 >>>>>>>>>>>> alization-01 and >>>>>>>>=20 >>>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption- >>>>>>>>>>>> jso >>>>>>>>>>>> n-ser >>>>>>>>=20 >>>>>>>>>>>> ialization-01 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Use them if you prefer if they better suit your use cases. =20 >>>>>>>>>>>> They >>>>>> could >>>>>>> be adopted as working group documents, if there's interest. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> See above. These are super-clunky, and the need to be the=20 >>>>>>>>>>> main >>>>>>> focus of the WG, not an afterthought. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> The JSON serialization drafts above do, again, in response=20 >>>>>>>>>>>> to use >>>>>>> cases presented by the working group. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> See above. Because of the unnecessary inclusion of the=20 >>>>>>>>>>> header in >>>>>> the >>>>>>> integrity check, this is far less efficient than it should be. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Functionally, these are very similar operations, at least=20 >>>>>>>>>>>> from an >>>>>>> implementation perspective, so it's not clear that making a=20 >>>>>>> clear >>>>>> distinction >>>>>>> would help either developers or adoption in any practical way. =20 >>>>>>> They >>>>>> achieve >>>>>>> overlapping, but admittedly sometimes different goals. I=20 >>>>>>> believe that developers can be trusted to use the algorithms=20 >>>>>>> that achieve their applications' goals without making a hard distin= ction between the two. >>>>>> But >>>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>>> brighter-line >>>>>>> distinction might be useful or necessary. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> It's important if you want to do MACs with anything other=20 >>>>>>>>>>> than >>>>>>>>>>> pre- >>>>>>> shared keys. If you want to do anything more advanced, you need=20 >>>>>>> to have wrapped keys, in which case an object with a MAC starts=20 >>>>>>> to look a lot more like a JWE than a JWS. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>=20 >>>>>>>>>>>> establishment modalities >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> This seems like an area where the existing drafts could be=20 >>>>>>>>>>>> refined >>>>>> to >>>>>>> add descriptions for additional establishment modalities,=20 >>>>>>> possibly based upon your ideas and descriptions, should the=20 >>>>>>> working group decide to do >>>>>> so. >>>>>>> What additional modalities do you have use cases for that you=20 >>>>>>> believe are not achievable or straightforward with the existing=20 >>>>>>> drafts? The existing modalities supported are largely those=20 >>>>>>> that existing developers had told >>>>>> us >>>>>>> they needed and draw both from the precursor=20 >>>>>>> draft-jones-json-web-* documents and draft-rescorla-jsms. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Bear in mind that the balance that the current drafts try=20 >>>>>>>>>>>> to strike >>>>>> is >>>>>>> keeping the Mandatory to Implement (MTI) feature footprint small=20 >>>>>>> enough that developers, including Web developers, are likely to=20 >>>>>>> adopt the specs, while still providing enough functionality to make= them generally useful. >>>>>> As >>>>>>> in any balance, it's often possible to shift things a bit and=20 >>>>>>> still >>>>>> maintain the >>>>>>> balance, but I'd like people to keep the ubiquitous adoption=20 >>>>>>> goal >>>>>> front-and- >>>>>>> center when proposing additional functionality. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>>=20 >>>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to=20 >>>>>>>>>>>> understand >>>>>>>>=20 >>>>>>>>>>>> that!) >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I agree that we need to find a reasonable MTI. The current=20 >>>>>>>>>>> JSMS >>>>>> draft >>>>>>> doesn't really specify which parts are MTI, beyond basic things=20 >>>>>>> like >>>>>> base64url >>>>>>> encoding and ignoring unknown fields. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> My main concern is that JWS and JWE don't really tell me=20 >>>>>>>>>>> which >>>>>> fields >>>>>>> need to be present for which use case. If I'm putting a MAC on a J= WS vs. >>>>>> a >>>>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>>>> Whereas in >>>>>> JSMS, >>>>>>> I think these things are much clearer due to the separation of=20 >>>>>>> the use >>>>>> cases >>>>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures=20 >>>>>>> and wrapped keys into sub-objects. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Most JSON documents aren't clearly typed; instead,=20 >>>>>>>>>>>> developers and >>>>>>> implementations understand from context what the meaning of each fi= eld is. >>>>>>> XML is clearly typed, but developers are voting with their feet=20 >>>>>>> by moving >>>>>> to >>>>>>> JSON. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> What practical advantages resulting from overlaying a=20 >>>>>>>>>>>> typing >>>>>>> infrastructure on JSON do you believe are worth the potential=20 >>>>>>> costs of >>>>>> doing >>>>>>> so? BTW, I'm not opposed to having a JSON schema description of=20 >>>>>>> the JOSE JSON data structures like JSMS did in >>>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A,=20 >>>>>>> but I'll remark that this an informative >>>>>> tool, not >>>>>>> a normative one. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> I actualy don't have a hugely urgent requirement here either. = =20 >>>>>>>>>>> It's >>>>>>> something that others in the WG had requested, which is trivial=20 >>>>>>> to add in JSMS, but not in JWE/JWS -- again because of the=20 >>>>>>> unnecessary integrity protection of the header. >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> An optional version field could be added if the working=20 >>>>>>>>>>>> group >>>>>>>>=20 >>>>>>>>>>>> desires, however the last time the working group discussed=20 >>>>>>>>>>>> it, they >>>>>>>>=20 >>>>>>>>>>>> decided not to do so. Rather, specs like this effectively=20 >>>>>>>>>>>> become >>>>>>>>=20 >>>>>>>>>>>> "versioned" when revised in a way that new fields are added. = =20 >>>>>>>>>>>> If >>>>>>>>=20 >>>>>>>>>>>> you understand the new fields, you support that new version. = =20 >>>>>>>>>>>> (Note >>>>>>>>=20 >>>>>>>>>>>> that this is independent of whether there is a version=20 >>>>>>>>>>>> number >>>>>>>>=20 >>>>>>>>>>>> field, which according to some participants in the previous >>>>>>>>=20 >>>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>>=20 >>>>>>>>>>>> information.) >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> I'm not religious about not having a version number field,=20 >>>>>>>>>>>> but >>>>>> often >>>>>>> "less is more". >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Indeed, I'm not religious either. It just seems like a=20 >>>>>>>>>>> general good >>>>>> idea >>>>>>> to state this directly as opposed to having parsers divine it=20 >>>>>>> based on >>>>>> which >>>>>>> fields are present. To quote RFC 5652: >>>>>>>>=20 >>>>>>>>>>> " >>>>>>>>=20 >>>>>>>>>>> Each of the major data structures includes a version number=20 >>>>>>>>>>> as the >>>>>>>>=20 >>>>>>>>>>> first item in the data structure. The version numbers are=20 >>>>>>>>>>> intended >>>>>>>>=20 >>>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20 >>>>>>>>>>> check >>>>>>> the >>>>>>>>=20 >>>>>>>>>>> version number prior to attempting a decode, and if a decode=20 >>>>>>>>>>> error >>>>>>>>=20 >>>>>>>>>>> occurs, then the version number is checked as part of the=20 >>>>>>>>>>> error >>>>>>>>=20 >>>>>>>>>>> handling routine. This is a reasonable approach; it places=20 >>>>>>>>>>> error >>>>>>>>=20 >>>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>>=20 >>>>>>>>>>> forgiving when an incorrect version number is used by the send= er. >>>>>>>>=20 >>>>>>>>>>> " >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> Best, >>>>>>>>=20 >>>>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Best wishes, >>>>>>>>=20 >>>>>>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>=20 >>>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>>=20 >>>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>>=20 >>>>>>>>>>>> To: Mike Jones >>>>>>>>=20 >>>>>>>>>>>> Cc: jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>>=20 >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. =20 >>>>>>>>>>>> IMO, >>>>>> the >>>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>>=20 >>>>>>>>>>>> -- Not being JSON >>>>>>>>=20 >>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>=20 >>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>=20 >>>>>>>>>>>> establishment modalities >>>>>>>>=20 >>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>=20 >>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20 >>>>>>>>>>>> would be >>>>>>> simple to adapt them to address these deficiencies. So I just=20 >>>>>>> did a >>>>>> re-write. >>>>>>> If you think they can be addressed within the current framework,=20 >>>>>>> please explain. I just found it simpler to start from whole cloth. >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Hi Richard, >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>>>>> documents, >>>>>>> I encourage you to ask about them on the list. The documents=20 >>>>>>> have significant history going back to mid-2010 when convergence=20 >>>>>>> discussions started among people with four different JSON=20 >>>>>>> signing & encryption proposals. JWT and the current JOSE specs=20 >>>>>>> and implementations are the result. I realize that not all the=20 >>>>>>> JOSE participants were part of those discussions from the=20 >>>>>>> beginning (although many were) and so teasing out the rationale=20 >>>>>>> for specific decisions might help people better understand the=20 >>>>>>> choices made, and hopefully thereby increase consensus behind the e= ventual working group choices. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 >>>>>>>>>>>>> below, >>>>>> maybe we >>>>>>> can start a discussion on that basis. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Best wishes, >>>>>>>>=20 >>>>>>>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>=20 >>>>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org]=20 >>>>>>>>>>>>> On >>>>>>>>=20 >>>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>>=20 >>>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>>=20 >>>>>>>>>>>>> To: jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Dear JOSE WG, >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>>>> thorough >>>>>>> review of the JW* specs, I was kind of puzzled by some of the=20 >>>>>>> design decisions. So I also went through and wrote an=20 >>>>>>> alternative format, this >>>>>> time >>>>>>> taking a more of a cue from CMS. A link to the document is below. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Summary of differences: >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the=20 >>>>>>>>>>>>> header >>>>>>>>=20 >>>>>>>>>>>>> parameters are represented in JSON. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS allows for full algorithm agility in key=20 >>>>>>>>>>>>> agreement, while >>>>>> JWE >>>>>>>>=20 >>>>>>>>>>>>> only allows ECDH-ES. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>>>>=20 >>>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>>> WrappedKey >>>>>>>>=20 >>>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires=20 >>>>>>>>>>>>> re- >>>>>>>>=20 >>>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o The signature and MAC functions of the JWS object are=20 >>>>>>>>>>>>> separated >>>>>>>>=20 >>>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they=20 >>>>>>>>>>>>> are in JWE >>>>>>>>=20 >>>>>>>>>>>>> and JWS. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS,=20 >>>>>>>>>>>>> but >>>>>> could >>>>>>>>=20 >>>>>>>>>>>>> be added without significant change. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown=20 >>>>>>>>>>>>> header >>>>>>>>=20 >>>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>>>> implementation >>>>>> (based >>>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>>=20 >>>>>>>>>>>>> >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Comments are very welcome. >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> Begin forwarded message: >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>=20 >>>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>>=20 >>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>>=20 >>>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has=20 >>>>>>>>>>>>>> been >>>>>>>>=20 >>>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to=20 >>>>>>>>>>>>>> the IETF >>>>>>>>=20 >>>>>>>>>>>>>> repository. >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>>=20 >>>>>>>>>>>>>> Revision: 00 >>>>>>>>=20 >>>>>>>>>>>>>> Title: JavaScript Message Security Forma= t >>>>>>>>=20 >>>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>>=20 >>>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>>=20 >>>>>>>>>>>>>> Number of pages: 25 >>>>>>>>=20 >>>>>>>>>>>>>> URL: >>>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>>> jsms-00.txt >>>>>>>>=20 >>>>>>>>>>>>>> Status: >>>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>>=20 >>>>>>>>>>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> Abstract: >>>>>>>>=20 >>>>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>>>> cryptographically >>>>>>>>=20 >>>>>>>>>>>>>> secured messages. While the IETF has defined a number of >>>>>>> formats >>>>>>>>=20 >>>>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings=20 >>>>>>>>>>>>>> which >>>>>>>>=20 >>>>>>>>>>>>>> are not easy to use in modern applications. This=20 >>>>>>>>>>>>>> document >>>>>>>>=20 >>>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS),=20 >>>>>>>>>>>>>> a new >>>>>>>>=20 >>>>>>>>>>>>>> cryptographic message format which is based on JavaScript=20 >>>>>>>>>>>>>> Object >>>>>>>>=20 >>>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>>>>> generate >>>>>>> and parse. >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>> The IETF Secretariat >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>> Chairman, OpenID Foundation >>>>>>>> http://nat.sakimura.org/ >>>>>>>> @_nat_en >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>=20 >>>=20 >>>=20 >>=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 ve7jtb@ve7jtb.com Tue Jun 26 14:29: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 A927E21F859F for ; Tue, 26 Jun 2012 14:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvvkkhdmK3-A for ; Tue, 26 Jun 2012 14:29:11 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95221F8599 for ; Tue, 26 Jun 2012 14:29:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so421615ggn.31 for ; Tue, 26 Jun 2012 14:29:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=igDElvwdAcszhmd9PtWEzyK1iBfdFZqnw2WQGXRB6Nc=; b=nToKn//Nn6lpUqk4VxG7Q3vbC1vCgOGAuIjsKDjAy6r8TEHGOcGwhGc6gORsF0ZBUf 5FbnDuNzbEMKSUlpRA/PDiIA09vprj3DHTpCtQA0T39jn7WBha+frvMZyVW83nNd8Lzw 8n80RUHcV0Cv7qX6RU44Xe37dApKDSAesZcBCReXyXEX8l3axnBOOJMlHiNGhpwjmczu 6VhFR5sWfYM1+4ccH13wsuzxPtJXPgQ2xM3vczXy8g6J1TtxRlyvc7sJS9xW+L1tf2sz nyXwTwwHg2GxlZQyzIy6B6JezRkCEYcJPEAUynu/JWfAFl6V9qCSCAeInWubpXdCDqcP nSOA== Received: by 10.236.46.132 with SMTP id r4mr19562183yhb.29.1340746150877; Tue, 26 Jun 2012 14:29:10 -0700 (PDT) Received: from [192.168.1.213] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id q32sm61417698anh.21.2012.06.26.14.29.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 14:29:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_3E72C5F9-9CAF-4867-A91F-032522DC9393"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> Date: Tue, 26 Jun 2012 17:29:03 -0400 Message-Id: <095E0335-89CC-4FDE-9B27-0A339CCC0B95@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl8PlbYcLHmtywKattSJd9ZS+tVM0tHlBSqwZPSLTb9UxqVwfR5kgorCI7Y3pgAIZCfME1m Cc: Anthony Nadalin , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:29:14 -0000 --Apple-Mail=_3E72C5F9-9CAF-4867-A91F-032522DC9393 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not proposing adding any algorithms. =20 If people want additional algorithms in JWA then they should propose = them. My point was simply that in light of the problems with AES-CBC the WG = decided that all non AEAD algorithms include the HMAC integrity = protection we have defined in JWE. That integrity protection makes use of the CMK and a key derivation = algorithm to generate a CEK and CIK. If someone for reasons I don't personally care about wanted ECB they = could propose that in the same way we now have AES-CBC defined. We are not precluding non AEAD block cyphers only mandating integrity be = used with them. We currently have a HMAC-SHA256 + AES-CBC mechanism, others are not = precluded, just not specified in the JWA at the moment. Regards John B. On 2012-06-26, at 5:20 PM, Richard L. Barnes wrote: > Why would you ever want to use ECB mode? If you want something fast = and parallelizable, CTR mode is a lot better. >=20 > We had discussed Dave McGrew's draft as a mechanism for specifying = general AEAD algorithms: > >=20 > --Richard >=20 >=20 >=20 >=20 > On Jun 26, 2012, at 5:07 PM, John Bradley wrote: >=20 >> You should suggest adding that as a supported algorithm. >>=20 >> We wanted to keep the core set down to a reasonable number to = encourage interoparability. >>=20 >> AES-ECB + HMAC can be a option if the WG wants it. >>=20 >> John B. >> On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote: >>=20 >>> AES-ECB is also a popular alternative >>>=20 >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 >>> Sent: Tuesday, June 26, 2012 1:59 PM >>> To: Anthony Nadalin >>> Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >>>=20 >>> Yes that is why we added the composite HMAC + AES-CBC. We can = debate if that is an algorithm or mandatory integrity with non AEAD = algorithms, but the effect of integrity protecting the header remains in = both cases. >>>=20 >>> John B. >>>=20 >>> On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >>>=20 >>>> Not sure there was a WG decision and what that would mean if there = was, as there are many libraries out there that don't support the = encryption with integrity algorithms, so need to support alternative = means of things like key wrap that could have an integrity check. >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of John Bradley >>>> Sent: Tuesday, June 26, 2012 12:30 PM >>>> To: Richard L. Barnes >>>> Cc: Jim Schaad; jose@ietf.org >>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >>>>=20 >>>> There was a WG decision to not allow encryption without integrity. = Jim and others call that sender verification. >>>>=20 >>>> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>>>=20 >>>> The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. >>>>=20 >>>> We do have s JWT spec that covers the body for security tokens. = The idea was to separate that from signing and encryption so that = signing and encryption can be used for other objects. >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>>>=20 >>>>>> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >>>>>> In those cases one can easily argue that the header should be = protected as much as in HMAC. >>>>>=20 >>>>> Can you clarify the scope of "we are mandating"? >>>>>=20 >>>>>=20 >>>>>> There may well be signing_time or other elements that would go = into the header as well for JWE. >>>>>=20 >>>>> Why do these need to go into the header rather than the body? >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> Richard, >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20= >>>>>>>> Behalf Of Richard L. Barnes >>>>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>>>> To: Nat Sakimura >>>>>>>> Cc: Mike Jones; jose@ietf.org >>>>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>>>> draft-barnes-jose-jsms- 00.txt >>>>>>>>=20 >>>>>>>> Hi Nat, >>>>>>>>=20 >>>>>>>> I'm not sure what X.509 fiasco you're referring to. There was = a=20 >>>>>>>> recent >>>>>>> MD5 >>>>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, = there=20 >>>>>>>> have >>>>>>> been >>>>>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. =20 >>>>>>>> As >>>>>>> was >>>>>>>> noted on the SAAG list, the real news here is that Microsoft = wasn't >>>>>>> following >>>>>>>> any of those recommendations. >>>>>>>>=20 >>>>>>>> JWS would have had the same problem as X.509. The attack did = not=20 >>>>>>>> modify the cryptographic parameters (anything that would have = gone=20 >>>>>>>> in the header), it would not have been thwarted by the = integrity=20 >>>>>>>> protection we're worrying about. >>>>>>>>=20 >>>>>>>> Actually, the header signing that JWS does makes it even nicer = for=20 >>>>>>>> the >>>>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20= >>>>>>>> header >>>>>>> value >>>>>>>> is entirely static for a given signer, it's easy to use as a = fixed prefix. >>>>>>> If JWS just >>>>>>>> signed the content, then the application could include a = something=20 >>>>>>>> random up front to prevent such prefix-based attacks. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I don't believe that this is a true statement. If you had a = prefix=20 >>>>>>> or just signed what was given to you (i.e. no prefix), it would = make=20 >>>>>>> no difference in terms of the attack for Flame. Flame could = always=20 >>>>>>> use a fixed prefix of its own design rather than using the fixed=20= >>>>>>> header that is generated by having JWS sign the header = information. >>>>>>>=20 >>>>>>>> It's tempting to say that we should just add randomness to the = JOSE >>>>>>> format. >>>>>>>> But the real lesson of the Flame/MD5 attacks is operational: = If=20 >>>>>>>> you're >>>>>>> signing >>>>>>>> something that somebody else gave you, make sure that you're = not=20 >>>>>>>> signing exactly what they gave you. Follow the recommendations = of=20 >>>>>>>> RFC 4270. In other contexts, there's no need of similar random=20= >>>>>>>> elements; it just adds complexity. >>>>>>>=20 >>>>>>> This is definitely a true statement in all events and is = something=20 >>>>>>> that should be added to the Security Considerations section. >>>>>>>=20 >>>>>>> That being said, I think that there are valid reasons for = wanting to=20 >>>>>>> protect the header information by some authentication = processing. =20 >>>>>>> PKIX certificates protect the signature algorithm information = (by=20 >>>>>>> copying the data into the to be signed block) and CMS has long=20= >>>>>>> allowed for information to be included in the signed attributes = area=20 >>>>>>> that identifies the algorithms used, the certificates used and = so=20 >>>>>>> forth. There are also other things that we might find to be=20 >>>>>>> convenient to be placed in the header information that is = current=20 >>>>>>> not there (a signing time and embedded content type comes to = mind)=20 >>>>>>> that would be a product either of specific types of signatures = or becomes a common attribute to be placed there. >>>>>>>=20 >>>>>>> In terms of encryption operations, I remember in the past that I=20= >>>>>>> have had either corrupted encrypted streams or corrupted IVs and = had=20 >>>>>>> a successful decryption that later generated other problems when=20= >>>>>>> trying to parse. This is less of an issue with AEAD algorithms = as=20 >>>>>>> they have a much stricter rule on when the stream decrypts = correctly. >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>>=20 >>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> [1] = >>>>>>>> [2] >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>>>=20 >>>>>>>>> Especially after the X.509 fiasco, I strongly believe that = having >>>>>>> integrity >>>>>>>> check over the metadata is a good thing. It is such a little = effort=20 >>>>>>>> that >>>>>>> gives us >>>>>>>> much more protection down the road. In this sense, I fully = agree=20 >>>>>>>> with Ben here. We should have integrity protection over the = header. >>>>>>>>>=20 >>>>>>>>> Nat >>>>>>>>>=20 >>>>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>>>> wrote: >>>>>>>>> Two years ago when the developer community needing a = JSON-friendly >>>>>>>> token format was designing the JSON Web Token (JWT), we = explicitly=20 >>>>>>>> asked security experts whether the header parameters should be=20= >>>>>>>> integrity protected or not. Among them, Ben Laurie was one of = the=20 >>>>>>>> voices saying >>>>>>> that >>>>>>>> securing them was the right thing to do. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> He argued that if the parameters can be protected in a = practical=20 >>>>>>>>> manner, >>>>>>>> then they should. Doing so provides an additional hurdle that=20= >>>>>>>> attackers would have to surmount. For example, if they can try = to=20 >>>>>>>> substitute a >>>>>>> weaker >>>>>>>> authentication scheme, then they must figure out how to make it=20= >>>>>>>> authenticate correctly despite some plaintext they can't = control -=20 >>>>>>>> the >>>>>>> header >>>>>>>> parameters. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Ben also took the position that paring security protocols down = to=20 >>>>>>>>> the >>>>>>> least >>>>>>>> you can get away with, given attacks you can think of, is not a=20= >>>>>>>> good >>>>>>> design >>>>>>>> principle. If there is not a strong argument against including = a=20 >>>>>>>> feature >>>>>>> that >>>>>>>> may make it harder for attackers, then that feature should be = included. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I agree with him. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The decision to provide integrity protection for the headers = is >>>>>>> documented >>>>>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>>>=20 >>>>>>>>> Given that the envelope is extensible and therefore may = contain >>>>>>> security- >>>>>>>> sensitive information, we reached a consensus (with input from = Ben=20 >>>>>>>> Laurie via IM) that the combination envelope.payload must be = signed. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I believe that logic is as sound today as it was then. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>>>>> community's >>>>>>>> decision to provide integrity protection for the headers. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best=20 >>>>>>>>> wishes, >>>>>>>>>=20 >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20= >>>>>>>>> Behalf Of >>>>>>>> John Bradley >>>>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>>>> To: Richard L.Barnes >>>>>>>>> Cc: jose@ietf.org >>>>>>>>> Subject: Re: [jose] New Version Notification for=20 >>>>>>>>> draft-barnes-jose-jsms- >>>>>>>> 00.txt >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> While for PKCS 1.5 the hash algorithm is baked into the = padding=20 >>>>>>>>> and not >>>>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>>>=20 >>>>>>>>> There are possible hash truncation attacks by shortening = SHA256 to >>>>>>> SHA224 >>>>>>>> as an example (I know we preclude truncated hashes at the = moment). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The bad feeling I get around this is that if there is a = scenario=20 >>>>>>>>> where >>>>>>> the >>>>>>>> attacker controls the plaintext to be signed and there is no = signer >>>>>>> controlled >>>>>>>> text contributed there are potential bad things that could = happen=20 >>>>>>>> down the road. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This bit us with x509 certs not that long ago (yes with MD5=20 >>>>>>>>> admittedly) >>>>>>>> where the attacker could use a certificate extension to include=20= >>>>>>>> extra data >>>>>>> and >>>>>>>> cause a pre collided hash to be generated. >>>>>>>>>=20 >>>>>>>>> Having part of the signed data outside the control of an = attacker=20 >>>>>>>>> is a >>>>>>> good >>>>>>>> thing. (having a nonce or message ID in the envelope is = possible=20 >>>>>>>> though >>>>>>> not >>>>>>>> yet required in JWS.) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am still of the opinion that putting the base64 encoded = envelope >>>>>>> inside >>>>>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>>>>=20 >>>>>>>>> Another structure to hold the attributes adds more complexity, = as=20 >>>>>>>>> would >>>>>>>> saying that they need to be inside the signed object. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I think part of this is that as one of the openID Connect = authors=20 >>>>>>>>> I look >>>>>>> at this >>>>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>>>=20 >>>>>>>>> For that simple processing with one signature is a high = priority=20 >>>>>>>>> for >>>>>>> adoption. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =46rom a general signing/encrypting of documents point of view = you >>>>>>>> legitimately have different priorities. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I know it is hard to prove a negative but It is also going to = be >>>>>>> difficult for me >>>>>>>> to go back to security people at google Facebook and other = places=20 >>>>>>>> and explain how not integrity protecting the header could be = better=20 >>>>>>>> than integrity protecting it. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It seems that I would be reduced to arguing that this is no = worse=20 >>>>>>>>> than >>>>>>> CMS >>>>>>>> and that hasn't been proven insecure yet. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Allowing a possible attacker to control the hash output, and = not >>>>>>> integrity >>>>>>>> protecting the additional data, seems like something I am bound = to=20 >>>>>>>> regret >>>>>>> in >>>>>>>> the future. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Hey John, >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Interesting points, but I don't think they actually apply = here. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to downgrade attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The attack that RFC 5752 is concerned with is when an = attacker=20 >>>>>>>>>> strips >>>>>>>> signatures from a signed message, so that the only ones left = are=20 >>>>>>>> ones he >>>>>>> can >>>>>>>> tamper with. So the integrity protection here is "horizontal"; = it=20 >>>>>>>> goes >>>>>>> across >>>>>>>> signatures. The integrity protection in JWS/JWE is "vertical" = --=20 >>>>>>>> it only >>>>>>> protects >>>>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "brown bag" attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The root of this attack is ambiguity about what content is=20 >>>>>>>>>> *signed* >>>>>>>>>=20 >>>>>>>>>> vs. what content is *used*. If an application doesn't verify=20= >>>>>>>>>> that >>>>>>>>>=20 >>>>>>>>>> it's actually using the stuff that's signed, then it can be=20= >>>>>>>>>> tricked >>>>>>>>>=20 >>>>>>>>>> into accepting something unsigned. (Cf. >>>>>>>>>=20 >>>>>>>>>> ) >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> However, I don't think any of the current proposals have that = problem. >>>>>>>> In JWE/JWS, the signed content is right there between the dots, = and=20 >>>>>>>> in >>>>>>> JSMS, >>>>>>>> it's in the "content" element. The current JSMS draft does = allow=20 >>>>>>>> detached signatures, but with a "voids your warranty" sticker = on it. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> In any case, these attacks have nothing to do with whether = the >>>>>>>> cryptographic parameters are integrity-protected with the = content. =20 >>>>>>>> The example attacks in the IBM still work regardless -- the = whole=20 >>>>>>>> point of the attack is that the cryptographic processing is the=20= >>>>>>>> same, only the >>>>>>> (non-crypto) >>>>>>>> matching of content is flawed. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "arbitrary attributes": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> We can have that here, too, but you need canonicalization. = And >>>>>>> base64- >>>>>>>> encoding is not not canonicalization -- it just waves its hands=20= >>>>>>>> over the question of equivalence. In my opinion, we should = keep=20 >>>>>>>> the cryptographic object simple by disallowing attributes, and = push=20 >>>>>>>> the attributes you would sign inside of the thing being signed. = If=20 >>>>>>>> people really do want >>>>>>> attributes, it >>>>>>>> doesn't seem to me like JSON canonicalization is very hard. I = can=20 >>>>>>>> do it >>>>>>> in 19 >>>>>>>> lines of python: >>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard too "meta-data in the body": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> It seems to me like if we're trying to define a general = format=20 >>>>>>>>>> for >>>>>>> applying >>>>>>>> security protections, then we ought to keep out things that = aren't >>>>>>> strictly >>>>>>>> security relevant. Those things can go in application-specific=20= >>>>>>>> content >>>>>>> types >>>>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "defense in depth" and selling this to = government >>>>>>>> agencies: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> CMS, via S/MIME, is in broad use across multiple federal = agencies=20 >>>>>>>>>> and >>>>>>>> large enterprises. JSMS is essentially a profile of CMS (see=20= >>>>>>>> Section 7), >>>>>>> and >>>>>>>> has the same security properties. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Originally we only integrity protected the header for = signing. =20 >>>>>>>>>>> We >>>>>>> added >>>>>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>>>>> encryption can >>>>>>> also >>>>>>>> be used for sender verification. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I understand the argument that it makes things simpler if we=20= >>>>>>>>>>> don't >>>>>>>> integrity protect the header information. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> However xmldsig, provides integrity over those elements to=20= >>>>>>>>>>> prevent >>>>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> CMS may not typically provide that integrity protection but = I=20 >>>>>>>>>>> think >>>>>>> Jim >>>>>>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>>>>>=20 >>>>>>>>>>> Given they are on this list they can speak to their view on=20= >>>>>>>>>>> integrity >>>>>>> over >>>>>>>> the crypto parameters. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>>>>> Carlo/Brown >>>>>>>> Bag attack that needs to be considered if we move to something = more=20 >>>>>>>> like a detached signature. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> The other design consideration is that we wanted to be able = to=20 >>>>>>>>>>> sign >>>>>>>> arbitrary byte strings not just JSON. You could sign XML if = you wanted. >>>>>>>>>=20 >>>>>>>>>>> That prevented us from including meta-data in the body as we=20= >>>>>>>>>>> didn't >>>>>>>> want to touch it. That left us with the header to include = additional >>>>>>> elements >>>>>>>> in. >>>>>>>>>=20 >>>>>>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>>>> arbitrary >>>>>>>> attributes not unlike the current JOSE spec. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Especially for something that will be used with JWT security=20= >>>>>>>>>>> tokens I >>>>>>> will >>>>>>>> have a hard time making the argument to NIST and others that = need=20 >>>>>>>> to approve this format that not integrity protecting the header=20= >>>>>>>> parameters is appropriate defence in depth, for something that=20= >>>>>>>> might be replacing signed SAML assertions in some applications. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I do understand how not integrity protecting the header will=20= >>>>>>>>>>> make >>>>>>> some >>>>>>>> things easier, however I can't agree that the benefit outweighs = the=20 >>>>>>>> disadvantages. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Hey Mike, >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Thanks for having some back-and-forth with me on this. I = think=20 >>>>>>>>>>>> this >>>>>>> is a >>>>>>>> good discussion to have right now. I would like to discuss = some >>>>>>> high-level >>>>>>>> points, and then I'll respond inline to your precise points. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20= >>>>>>>>>>>> define >>>>>>> JSON- >>>>>>>> based formats for integrity and confidentiality protections. = JWE=20 >>>>>>>> and JWS don't fit that requirement, so we should re-consider = their=20 >>>>>>>> adoption and >>>>>>> call >>>>>>>> for new candidates. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Major points: >>>>>>>>>=20 >>>>>>>>>>>> 1. JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>>>=20 >>>>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 1: JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> The JOSE WG charter calls out four deliverables, three of = which=20 >>>>>>>>>>>> are >>>>>>>> explicitly required to be JSON: >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured encryption" >>>>>>>>>=20 >>>>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>>>=20 >>>>>>>>>>>> (The fourth is just a list of algorithms, which should be = JSON=20 >>>>>>>>>>>> as >>>>>>>>>=20 >>>>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20= >>>>>>>>>>>> suitable >>>>>>>>>=20 >>>>>>>>>>>> candidates to fulfill the working group's milestones. (At=20= >>>>>>>>>>>> least in >>>>>>>>>=20 >>>>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>>>=20 >>>>>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>>>>> especially >>>>>>>>>=20 >>>>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20= >>>>>>>>>>>> drafts >>>>>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>>>>> cryptographic parameters within the integrity protection, they = have=20 >>>>>>>> to have the headers included as base64-encoded strings. That=20= >>>>>>>> obviously adds a lot of >>>>>>> complexity >>>>>>>> to encoding and decoding -- for example, you have to keep the=20= >>>>>>>> encoded header around even after you've decoded it! -- and just = plain more octets. >>>>>>>> The support for multiple recipients and multiple signatures is = both >>>>>>> unweildy >>>>>>>> (matching up parallel indices for headers and signatures) and=20= >>>>>>>> inefficient (multiple integrity check values in encrypted = objects). >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic = wisdom=20 >>>>>>>>>>>> that >>>>>>>> went into CMS, while making the syntax pure JSON and as simple = as >>>>>>> possible. >>>>>>>> Multiple signatures and multiple recipients are supported with=20= >>>>>>>> absolute minimum overhead. So I think it's worth consideration = by=20 >>>>>>>> the working >>>>>>> group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>>>>> requires >>>>>>>>>=20 >>>>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>>>=20 >>>>>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>>>>> included >>>>>>>>>=20 >>>>>>>>>>>> within the integrity protection. I'm not aware of any = reason=20 >>>>>>>>>>>> for >>>>>>>>>=20 >>>>>>>>>>>> including the cryptographic parameters in the integrity = check, >>>>>>>>>=20 >>>>>>>>>>>> instead of only integrity-protecting the content itself. =20= >>>>>>>>>>>> Indeed, if >>>>>>>>>=20 >>>>>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>>>>> cryptographic >>>>>>>>>=20 >>>>>>>>>>>> parameters, it would be a pretty big deal, since neither = CMS=20 >>>>>>>>>>>> nor IKE >>>>>>>>>=20 >>>>>>>>>>>> nor provides this protection. (TLS does provide a = signature=20 >>>>>>>>>>>> over >>>>>>>>>=20 >>>>>>>>>>>> the algorithms, but only as a way to bind the public key to = the >>>>>>>>>=20 >>>>>>>>>>>> session.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except = for >>>>>>>> attributes that are included in the protected content = (signedAttrs=20 >>>>>>>> / authenticatedAttrs), which need to be DER-encoded. In JSMS, = we=20 >>>>>>>> don't allow those parameters, so there is no need for = canonicalization at all. >>>>>>> All the >>>>>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>>>>> protected content. In that regard, JSMS is even simpler than = JWE/JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>>>>> derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I have absolutely no objection to defining a compact, = URL-safe >>>>>>> format. >>>>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20= >>>>>>>> example >>>>>>> from >>>>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> { >>>>>>>>>=20 >>>>>>>>>>>> "v":1, >>>>>>>>>=20 >>>>>>>>>>>> "t":"au", >>>>>>>>>=20 >>>>>>>>>>>> "a":"hs256", >>>>>>>>>=20 >>>>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>>>=20 >>>>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>>>=20 >>>>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>>>=20 >>>>>>>>>>>> } >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20= >>>>>>>>>>>> only >>>>>>>> use >>>>>>>>>=20 >>>>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a = step >>>>>>>>>=20 >>>>>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>>>>> AuthenticatedData, >>>>>>>>>=20 >>>>>>>>>>>> we can emulate JWS by moving the content and MAC fields = outside >>>>>>>> and >>>>>>>>>=20 >>>>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and = only >>>>>>>>>=20 >>>>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put = the=20 >>>>>>>>>>>> code >>>>>>>>>=20 >>>>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>>>>> objective, >>>>>>> but it >>>>>>>> makes *much* more sense to derive that from a full-size, = usable,=20 >>>>>>>> JSON format than the other way around. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Responses to specific points inline below. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. = Before=20 >>>>>>>>>>>>> doing >>>>>>> so, I'll >>>>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>>>> understanding >>>>>>>> and consensus, rather than taking the point of view that the = status=20 >>>>>>>> quo is >>>>>>> the >>>>>>>> only reasonable outcome. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This was by design, so that the results are URL-safe. = This is >>>>>>> required, >>>>>>>> for instance, for them to be used as OAuth Bearer Tokens. At = the=20 >>>>>>>> request >>>>>>> of >>>>>>>> the working group, closely related pure-JSON drafts were also = published. >>>>>>>> See: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json >>>>>>>>>>>>> -seri >>>>>>>>>=20 >>>>>>>>>>>>> alization-01 and >>>>>>>>>=20 >>>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption-jso >>>>>>>>>>>>> n-ser >>>>>>>>>=20 >>>>>>>>>>>>> ialization-01 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Use them if you prefer if they better suit your use cases. = =20 >>>>>>>>>>>>> They >>>>>>> could >>>>>>>> be adopted as working group documents, if there's interest. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. These are super-clunky, and the need to be the = main >>>>>>>> focus of the WG, not an afterthought. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> The JSON serialization drafts above do, again, in response = to=20 >>>>>>>>>>>>> use >>>>>>>> cases presented by the working group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. Because of the unnecessary inclusion of the = header=20 >>>>>>>>>>>> in >>>>>>> the >>>>>>>> integrity check, this is far less efficient than it should be. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Functionally, these are very similar operations, at least = from=20 >>>>>>>>>>>>> an >>>>>>>> implementation perspective, so it's not clear that making a = clear >>>>>>> distinction >>>>>>>> would help either developers or adoption in any practical way. =20= >>>>>>>> They >>>>>>> achieve >>>>>>>> overlapping, but admittedly sometimes different goals. I = believe=20 >>>>>>>> that developers can be trusted to use the algorithms that = achieve=20 >>>>>>>> their applications' goals without making a hard distinction = between the two. >>>>>>> But >>>>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>>>> brighter-line >>>>>>>> distinction might be useful or necessary. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> It's important if you want to do MACs with anything other = than=20 >>>>>>>>>>>> pre- >>>>>>>> shared keys. If you want to do anything more advanced, you = need to=20 >>>>>>>> have wrapped keys, in which case an object with a MAC starts to=20= >>>>>>>> look a lot more like a JWE than a JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This seems like an area where the existing drafts could be=20= >>>>>>>>>>>>> refined >>>>>>> to >>>>>>>> add descriptions for additional establishment modalities, = possibly=20 >>>>>>>> based upon your ideas and descriptions, should the working = group=20 >>>>>>>> decide to do >>>>>>> so. >>>>>>>> What additional modalities do you have use cases for that you=20= >>>>>>>> believe are not achievable or straightforward with the existing=20= >>>>>>>> drafts? The existing modalities supported are largely those = that=20 >>>>>>>> existing developers had told >>>>>>> us >>>>>>>> they needed and draw both from the precursor = draft-jones-json-web-*=20 >>>>>>>> documents and draft-rescorla-jsms. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Bear in mind that the balance that the current drafts try = to=20 >>>>>>>>>>>>> strike >>>>>>> is >>>>>>>> keeping the Mandatory to Implement (MTI) feature footprint = small=20 >>>>>>>> enough that developers, including Web developers, are likely to=20= >>>>>>>> adopt the specs, while still providing enough functionality to = make them generally useful. >>>>>>> As >>>>>>>> in any balance, it's often possible to shift things a bit and = still >>>>>>> maintain the >>>>>>>> balance, but I'd like people to keep the ubiquitous adoption = goal >>>>>>> front-and- >>>>>>>> center when proposing additional functionality. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>>>=20 >>>>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to = understand >>>>>>>>>=20 >>>>>>>>>>>>> that!) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I agree that we need to find a reasonable MTI. The current=20= >>>>>>>>>>>> JSMS >>>>>>> draft >>>>>>>> doesn't really specify which parts are MTI, beyond basic things=20= >>>>>>>> like >>>>>>> base64url >>>>>>>> encoding and ignoring unknown fields. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> My main concern is that JWS and JWE don't really tell me = which >>>>>>> fields >>>>>>>> need to be present for which use case. If I'm putting a MAC on = a JWS vs. >>>>>>> a >>>>>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>>>>> Whereas in >>>>>>> JSMS, >>>>>>>> I think these things are much clearer due to the separation of = the=20 >>>>>>>> use >>>>>>> cases >>>>>>>> (Signed/Authenticated/Encrypted) and the isolation of = signatures=20 >>>>>>>> and wrapped keys into sub-objects. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Most JSON documents aren't clearly typed; instead, = developers=20 >>>>>>>>>>>>> and >>>>>>>> implementations understand from context what the meaning of = each field is. >>>>>>>> XML is clearly typed, but developers are voting with their feet = by=20 >>>>>>>> moving >>>>>>> to >>>>>>>> JSON. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> What practical advantages resulting from overlaying a = typing >>>>>>>> infrastructure on JSON do you believe are worth the potential = costs=20 >>>>>>>> of >>>>>>> doing >>>>>>>> so? BTW, I'm not opposed to having a JSON schema description = of=20 >>>>>>>> the JOSE JSON data structures like JSMS did in=20 >>>>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, = but=20 >>>>>>>> I'll remark that this an informative >>>>>>> tool, not >>>>>>>> a normative one. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I actualy don't have a hugely urgent requirement here = either. =20 >>>>>>>>>>>> It's >>>>>>>> something that others in the WG had requested, which is trivial = to=20 >>>>>>>> add in JSMS, but not in JWE/JWS -- again because of the = unnecessary=20 >>>>>>>> integrity protection of the header. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> An optional version field could be added if the working = group >>>>>>>>>=20 >>>>>>>>>>>>> desires, however the last time the working group discussed = it,=20 >>>>>>>>>>>>> they >>>>>>>>>=20 >>>>>>>>>>>>> decided not to do so. Rather, specs like this effectively=20= >>>>>>>>>>>>> become >>>>>>>>>=20 >>>>>>>>>>>>> "versioned" when revised in a way that new fields are = added. =20 >>>>>>>>>>>>> If >>>>>>>>>=20 >>>>>>>>>>>>> you understand the new fields, you support that new = version. =20 >>>>>>>>>>>>> (Note >>>>>>>>>=20 >>>>>>>>>>>>> that this is independent of whether there is a version = number >>>>>>>>>=20 >>>>>>>>>>>>> field, which according to some participants in the = previous >>>>>>>>>=20 >>>>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>>>=20 >>>>>>>>>>>>> information.) >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> I'm not religious about not having a version number field, = but >>>>>>> often >>>>>>>> "less is more". >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed, I'm not religious either. It just seems like a = general=20 >>>>>>>>>>>> good >>>>>>> idea >>>>>>>> to state this directly as opposed to having parsers divine it = based=20 >>>>>>>> on >>>>>>> which >>>>>>>> fields are present. To quote RFC 5652: >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>> Each of the major data structures includes a version number = as=20 >>>>>>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> first item in the data structure. The version numbers are=20= >>>>>>>>>>>> intended >>>>>>>>>=20 >>>>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20= >>>>>>>>>>>> check >>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> version number prior to attempting a decode, and if a = decode=20 >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> occurs, then the version number is checked as part of the = error >>>>>>>>>=20 >>>>>>>>>>>> handling routine. This is a reasonable approach; it places=20= >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>>>=20 >>>>>>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Best, >>>>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>>>=20 >>>>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>>>=20 >>>>>>>>>>>>> To: Mike Jones >>>>>>>>>=20 >>>>>>>>>>>>> Cc: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. = =20 >>>>>>>>>>>>> IMO, >>>>>>> the >>>>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20= >>>>>>>>>>>>> would be >>>>>>>> simple to adapt them to address these deficiencies. So I just = did=20 >>>>>>>> a >>>>>>> re-write. >>>>>>>> If you think they can be addressed within the current = framework,=20 >>>>>>>> please explain. I just found it simpler to start from whole = cloth. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If you're puzzled by specific design decisions in the = JOSE >>>>>>> documents, >>>>>>>> I encourage you to ask about them on the list. The documents = have=20 >>>>>>>> significant history going back to mid-2010 when convergence=20 >>>>>>>> discussions started among people with four different JSON = signing &=20 >>>>>>>> encryption proposals. JWT and the current JOSE specs and=20 >>>>>>>> implementations are the result. I realize that not all the = JOSE=20 >>>>>>>> participants were part of those discussions from the beginning=20= >>>>>>>> (although many were) and so teasing out the rationale for = specific=20 >>>>>>>> decisions might help people better understand the choices made, = and=20 >>>>>>>> hopefully thereby increase consensus behind the eventual = working group choices. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20= >>>>>>>>>>>>>> below, >>>>>>> maybe we >>>>>>>> can start a discussion on that basis. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>>> From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On >>>>>>>>>=20 >>>>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>>>=20 >>>>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>>>=20 >>>>>>>>>>>>>> To: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Dear JOSE WG, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>>>>> thorough >>>>>>>> review of the JW* specs, I was kind of puzzled by some of the=20= >>>>>>>> design decisions. So I also went through and wrote an = alternative=20 >>>>>>>> format, this >>>>>>> time >>>>>>>> taking a more of a cue from CMS. A link to the document is = below. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Summary of differences: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the = header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters are represented in JSON. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS allows for full algorithm agility in key = agreement,=20 >>>>>>>>>>>>>> while >>>>>>> JWE >>>>>>>>>=20 >>>>>>>>>>>>>> only allows ECDH-ES. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData = and >>>>>>>>>=20 >>>>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>>>> WrappedKey >>>>>>>>>=20 >>>>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires = re- >>>>>>>>>=20 >>>>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The signature and MAC functions of the JWS object are=20= >>>>>>>>>>>>>> separated >>>>>>>>>=20 >>>>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they = are=20 >>>>>>>>>>>>>> in JWE >>>>>>>>>=20 >>>>>>>>>>>>>> and JWS. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in = JSMS,=20 >>>>>>>>>>>>>> but >>>>>>> could >>>>>>>>>=20 >>>>>>>>>>>>>> be added without significant change. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown = header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>>>>> implementation >>>>>>> (based >>>>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>>>=20 >>>>>>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Comments are very welcome. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>>>=20 >>>>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has = been >>>>>>>>>=20 >>>>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to = the=20 >>>>>>>>>>>>>>> IETF >>>>>>>>>=20 >>>>>>>>>>>>>>> repository. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Revision: 00 >>>>>>>>>=20 >>>>>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>>>>=20 >>>>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>>>=20 >>>>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>>>=20 >>>>>>>>>>>>>>> Number of pages: 25 >>>>>>>>>=20 >>>>>>>>>>>>>>> URL: >>>>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>>>> jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Status: >>>>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Abstract: >>>>>>>>>=20 >>>>>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>>>>> cryptographically >>>>>>>>>=20 >>>>>>>>>>>>>>> secured messages. While the IETF has defined a number = of >>>>>>>> formats >>>>>>>>>=20 >>>>>>>>>>>>>>> for such messages (e.g. CMS) those formats use = encodings=20 >>>>>>>>>>>>>>> which >>>>>>>>>=20 >>>>>>>>>>>>>>> are not easy to use in modern applications. This = document >>>>>>>>>=20 >>>>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), = a=20 >>>>>>>>>>>>>>> new >>>>>>>>>=20 >>>>>>>>>>>>>>> cryptographic message format which is based on = JavaScript=20 >>>>>>>>>>>>>>> Object >>>>>>>>>=20 >>>>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications = to >>>>>>> generate >>>>>>>> and parse. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_3E72C5F9-9CAF-4867-A91F-032522DC9393 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjIxMjkwNFowIwYJKoZIhvcNAQkEMRYEFKCIxoO2JERhQsUbZnyeArbXJ8EWMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ALDHqjhcqigvTs59fbRcsnQB896ylV2lNAQwftw1PkmBLVl3gx6cNj1o05GNL+0Z/uzVnfwQKrFX CLznxiHFMobm0szbKPmw/C+wC71QHBgPYqxvy6vbst/g3+eGseg6j8DAJop2pcGhMpd/wbtOR3sO Dd0ksKwIcyfK4oSEEroByEC+dcyGPif/PKRl0fhVLSwbGezbxe12Xnb8J6I7dpKSVRUz2B+SXiqA iQjkTfQudObx2JvknOuWitkfgKZVdJkdPKZulVk3fOVzJER55xaPn3hUzvNOwA/hZ4cZGDFivaq3 u+UfwXBtdH0UihzoXFUFfdoYVApM2lylCsmMC0UAAAAAAAA= --Apple-Mail=_3E72C5F9-9CAF-4867-A91F-032522DC9393-- From rbarnes@bbn.com Tue Jun 26 14:34: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 C744E21F85C0 for ; Tue, 26 Jun 2012 14:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id julFou0WclmV for ; Tue, 26 Jun 2012 14:34:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BA32F21F85BD for ; Tue, 26 Jun 2012 14:34:54 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:60994) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjdPM-0008Qb-8E; Tue, 26 Jun 2012 17:34:48 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 26 Jun 2012 17:34:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) Cc: John Bradley , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:34:59 -0000 Not to rat-hole on ECB, but: I would be interested to hear about libraries that support ECB, but not = other modes. Key wrap does not use ECB. It uses AES as a primitive, mixing in = entropy over multiple rounds. On Jun 26, 2012, at 5:23 PM, Anthony Nadalin wrote: > Because it's in most libraries and it works well for key wrap and it's = in a lot of products. That's fine to discuss (and did not say it was not = discussed) but I don't recall reaching a consensus on that point yet. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L. Barnes > Sent: Tuesday, June 26, 2012 2:20 PM > To: John Bradley > Cc: Anthony Nadalin; Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > Why would you ever want to use ECB mode? If you want something fast = and parallelizable, CTR mode is a lot better. >=20 > We had discussed Dave McGrew's draft as a mechanism for specifying = general AEAD algorithms: > >=20 > --Richard >=20 >=20 >=20 >=20 > On Jun 26, 2012, at 5:07 PM, John Bradley wrote: >=20 >> You should suggest adding that as a supported algorithm. >>=20 >> We wanted to keep the core set down to a reasonable number to = encourage interoparability. >>=20 >> AES-ECB + HMAC can be a option if the WG wants it. >>=20 >> John B. >> On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote: >>=20 >>> AES-ECB is also a popular alternative >>>=20 >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Tuesday, June 26, 2012 1:59 PM >>> To: Anthony Nadalin >>> Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for=20 >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> Yes that is why we added the composite HMAC + AES-CBC. We can = debate if that is an algorithm or mandatory integrity with non AEAD = algorithms, but the effect of integrity protecting the header remains in = both cases. >>>=20 >>> John B. >>>=20 >>> On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >>>=20 >>>> Not sure there was a WG decision and what that would mean if there = was, as there are many libraries out there that don't support the = encryption with integrity algorithms, so need to support alternative = means of things like key wrap that could have an integrity check. >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf=20 >>>> Of John Bradley >>>> Sent: Tuesday, June 26, 2012 12:30 PM >>>> To: Richard L. Barnes >>>> Cc: Jim Schaad; jose@ietf.org >>>> Subject: Re: [jose] New Version Notification for=20 >>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>> There was a WG decision to not allow encryption without integrity. = Jim and others call that sender verification. >>>>=20 >>>> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>>>=20 >>>> The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. >>>>=20 >>>> We do have s JWT spec that covers the body for security tokens. = The idea was to separate that from signing and encryption so that = signing and encryption can be used for other objects. >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>>>=20 >>>>>> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >>>>>> In those cases one can easily argue that the header should be = protected as much as in HMAC. >>>>>=20 >>>>> Can you clarify the scope of "we are mandating"? >>>>>=20 >>>>>=20 >>>>>> There may well be signing_time or other elements that would go = into the header as well for JWE. >>>>>=20 >>>>> Why do these need to go into the header rather than the body? >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> Richard, >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20= >>>>>>>> Behalf Of Richard L. Barnes >>>>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>>>> To: Nat Sakimura >>>>>>>> Cc: Mike Jones; jose@ietf.org >>>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>>> draft-barnes-jose-jsms- 00.txt >>>>>>>>=20 >>>>>>>> Hi Nat, >>>>>>>>=20 >>>>>>>> I'm not sure what X.509 fiasco you're referring to. There was = a=20 >>>>>>>> recent >>>>>>> MD5 >>>>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact,=20= >>>>>>>> there have >>>>>>> been >>>>>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. =20 >>>>>>>> As >>>>>>> was >>>>>>>> noted on the SAAG list, the real news here is that Microsoft=20 >>>>>>>> wasn't >>>>>>> following >>>>>>>> any of those recommendations. >>>>>>>>=20 >>>>>>>> JWS would have had the same problem as X.509. The attack did=20= >>>>>>>> not modify the cryptographic parameters (anything that would=20 >>>>>>>> have gone in the header), it would not have been thwarted by = the=20 >>>>>>>> integrity protection we're worrying about. >>>>>>>>=20 >>>>>>>> Actually, the header signing that JWS does makes it even nicer=20= >>>>>>>> for the >>>>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20= >>>>>>>> header >>>>>>> value >>>>>>>> is entirely static for a given signer, it's easy to use as a = fixed prefix. >>>>>>> If JWS just >>>>>>>> signed the content, then the application could include a=20 >>>>>>>> something random up front to prevent such prefix-based attacks. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I don't believe that this is a true statement. If you had a=20 >>>>>>> prefix or just signed what was given to you (i.e. no prefix), it=20= >>>>>>> would make no difference in terms of the attack for Flame. = Flame=20 >>>>>>> could always use a fixed prefix of its own design rather than=20 >>>>>>> using the fixed header that is generated by having JWS sign the = header information. >>>>>>>=20 >>>>>>>> It's tempting to say that we should just add randomness to the=20= >>>>>>>> JOSE >>>>>>> format. >>>>>>>> But the real lesson of the Flame/MD5 attacks is operational: = If=20 >>>>>>>> you're >>>>>>> signing >>>>>>>> something that somebody else gave you, make sure that you're = not=20 >>>>>>>> signing exactly what they gave you. Follow the recommendations=20= >>>>>>>> of RFC 4270. In other contexts, there's no need of similar=20 >>>>>>>> random elements; it just adds complexity. >>>>>>>=20 >>>>>>> This is definitely a true statement in all events and is=20 >>>>>>> something that should be added to the Security Considerations = section. >>>>>>>=20 >>>>>>> That being said, I think that there are valid reasons for = wanting=20 >>>>>>> to protect the header information by some authentication = processing. >>>>>>> PKIX certificates protect the signature algorithm information = (by=20 >>>>>>> copying the data into the to be signed block) and CMS has long=20= >>>>>>> allowed for information to be included in the signed attributes=20= >>>>>>> area that identifies the algorithms used, the certificates used=20= >>>>>>> and so forth. There are also other things that we might find to=20= >>>>>>> be convenient to be placed in the header information that is=20 >>>>>>> current not there (a signing time and embedded content type = comes=20 >>>>>>> to mind) that would be a product either of specific types of = signatures or becomes a common attribute to be placed there. >>>>>>>=20 >>>>>>> In terms of encryption operations, I remember in the past that I=20= >>>>>>> have had either corrupted encrypted streams or corrupted IVs and=20= >>>>>>> had a successful decryption that later generated other problems=20= >>>>>>> when trying to parse. This is less of an issue with AEAD=20 >>>>>>> algorithms as they have a much stricter rule on when the stream = decrypts correctly. >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>>=20 >>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> [1]=20 >>>>>>>> >>>>>>>> [2] >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>>>=20 >>>>>>>>> Especially after the X.509 fiasco, I strongly believe that=20 >>>>>>>>> having >>>>>>> integrity >>>>>>>> check over the metadata is a good thing. It is such a little=20 >>>>>>>> effort that >>>>>>> gives us >>>>>>>> much more protection down the road. In this sense, I fully = agree=20 >>>>>>>> with Ben here. We should have integrity protection over the = header. >>>>>>>>>=20 >>>>>>>>> Nat >>>>>>>>>=20 >>>>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>>>> wrote: >>>>>>>>> Two years ago when the developer community needing a=20 >>>>>>>>> JSON-friendly >>>>>>>> token format was designing the JSON Web Token (JWT), we=20 >>>>>>>> explicitly asked security experts whether the header parameters=20= >>>>>>>> should be integrity protected or not. Among them, Ben Laurie=20= >>>>>>>> was one of the voices saying >>>>>>> that >>>>>>>> securing them was the right thing to do. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> He argued that if the parameters can be protected in a=20 >>>>>>>>> practical manner, >>>>>>>> then they should. Doing so provides an additional hurdle that=20= >>>>>>>> attackers would have to surmount. For example, if they can try=20= >>>>>>>> to substitute a >>>>>>> weaker >>>>>>>> authentication scheme, then they must figure out how to make it=20= >>>>>>>> authenticate correctly despite some plaintext they can't = control=20 >>>>>>>> - the >>>>>>> header >>>>>>>> parameters. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Ben also took the position that paring security protocols down=20= >>>>>>>>> to the >>>>>>> least >>>>>>>> you can get away with, given attacks you can think of, is not a=20= >>>>>>>> good >>>>>>> design >>>>>>>> principle. If there is not a strong argument against including=20= >>>>>>>> a feature >>>>>>> that >>>>>>>> may make it harder for attackers, then that feature should be = included. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I agree with him. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The decision to provide integrity protection for the headers = is >>>>>>> documented >>>>>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>>>=20 >>>>>>>>> Given that the envelope is extensible and therefore may = contain >>>>>>> security- >>>>>>>> sensitive information, we reached a consensus (with input from=20= >>>>>>>> Ben Laurie via IM) that the combination envelope.payload must = be signed. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I believe that logic is as sound today as it was then. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>>>>> community's >>>>>>>> decision to provide integrity protection for the headers. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best=20 >>>>>>>>> wishes, >>>>>>>>>=20 >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20= >>>>>>>>> Behalf Of >>>>>>>> John Bradley >>>>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>>>> To: Richard L.Barnes >>>>>>>>> Cc: jose@ietf.org >>>>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>>>> draft-barnes-jose-jsms- >>>>>>>> 00.txt >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> While for PKCS 1.5 the hash algorithm is baked into the = padding=20 >>>>>>>>> and not >>>>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>>>=20 >>>>>>>>> There are possible hash truncation attacks by shortening = SHA256=20 >>>>>>>>> to >>>>>>> SHA224 >>>>>>>> as an example (I know we preclude truncated hashes at the = moment). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The bad feeling I get around this is that if there is a=20 >>>>>>>>> scenario where >>>>>>> the >>>>>>>> attacker controls the plaintext to be signed and there is no=20 >>>>>>>> signer >>>>>>> controlled >>>>>>>> text contributed there are potential bad things that could=20 >>>>>>>> happen down the road. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This bit us with x509 certs not that long ago (yes with MD5 >>>>>>>>> admittedly) >>>>>>>> where the attacker could use a certificate extension to include=20= >>>>>>>> extra data >>>>>>> and >>>>>>>> cause a pre collided hash to be generated. >>>>>>>>>=20 >>>>>>>>> Having part of the signed data outside the control of an=20 >>>>>>>>> attacker is a >>>>>>> good >>>>>>>> thing. (having a nonce or message ID in the envelope is=20 >>>>>>>> possible though >>>>>>> not >>>>>>>> yet required in JWS.) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am still of the opinion that putting the base64 encoded=20 >>>>>>>>> envelope >>>>>>> inside >>>>>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>>>>=20 >>>>>>>>> Another structure to hold the attributes adds more complexity, = =20 >>>>>>>>> as would >>>>>>>> saying that they need to be inside the signed object. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I think part of this is that as one of the openID Connect=20 >>>>>>>>> authors I look >>>>>>> at this >>>>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>>>=20 >>>>>>>>> For that simple processing with one signature is a high=20 >>>>>>>>> priority for >>>>>>> adoption. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =46rom a general signing/encrypting of documents point of view=20= >>>>>>>>> you >>>>>>>> legitimately have different priorities. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I know it is hard to prove a negative but It is also going to=20= >>>>>>>>> be >>>>>>> difficult for me >>>>>>>> to go back to security people at google Facebook and other=20 >>>>>>>> places and explain how not integrity protecting the header = could=20 >>>>>>>> be better than integrity protecting it. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It seems that I would be reduced to arguing that this is no=20 >>>>>>>>> worse than >>>>>>> CMS >>>>>>>> and that hasn't been proven insecure yet. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Allowing a possible attacker to control the hash output, and=20= >>>>>>>>> not >>>>>>> integrity >>>>>>>> protecting the additional data, seems like something I am bound=20= >>>>>>>> to regret >>>>>>> in >>>>>>>> the future. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Hey John, >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Interesting points, but I don't think they actually apply = here. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to downgrade attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The attack that RFC 5752 is concerned with is when an = attacker=20 >>>>>>>>>> strips >>>>>>>> signatures from a signed message, so that the only ones left = are=20 >>>>>>>> ones he >>>>>>> can >>>>>>>> tamper with. So the integrity protection here is "horizontal";=20= >>>>>>>> it goes >>>>>>> across >>>>>>>> signatures. The integrity protection in JWS/JWE is "vertical"=20= >>>>>>>> -- it only >>>>>>> protects >>>>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "brown bag" attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The root of this attack is ambiguity about what content is >>>>>>>>>> *signed* >>>>>>>>>=20 >>>>>>>>>> vs. what content is *used*. If an application doesn't verify=20= >>>>>>>>>> that >>>>>>>>>=20 >>>>>>>>>> it's actually using the stuff that's signed, then it can be=20= >>>>>>>>>> tricked >>>>>>>>>=20 >>>>>>>>>> into accepting something unsigned. (Cf. >>>>>>>>>=20 >>>>>>>>>> ) >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> However, I don't think any of the current proposals have that = problem. >>>>>>>> In JWE/JWS, the signed content is right there between the dots,=20= >>>>>>>> and in >>>>>>> JSMS, >>>>>>>> it's in the "content" element. The current JSMS draft does=20 >>>>>>>> allow detached signatures, but with a "voids your warranty" = sticker on it. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> In any case, these attacks have nothing to do with whether = the >>>>>>>> cryptographic parameters are integrity-protected with the = content. =20 >>>>>>>> The example attacks in the IBM still work regardless -- the=20 >>>>>>>> whole point of the attack is that the cryptographic processing=20= >>>>>>>> is the same, only the >>>>>>> (non-crypto) >>>>>>>> matching of content is flawed. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "arbitrary attributes": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> We can have that here, too, but you need canonicalization. =20= >>>>>>>>>> And >>>>>>> base64- >>>>>>>> encoding is not not canonicalization -- it just waves its hands=20= >>>>>>>> over the question of equivalence. In my opinion, we should = keep=20 >>>>>>>> the cryptographic object simple by disallowing attributes, and=20= >>>>>>>> push the attributes you would sign inside of the thing being=20 >>>>>>>> signed. If people really do want >>>>>>> attributes, it >>>>>>>> doesn't seem to me like JSON canonicalization is very hard. I=20= >>>>>>>> can do it >>>>>>> in 19 >>>>>>>> lines of python: >>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard too "meta-data in the body": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> It seems to me like if we're trying to define a general = format=20 >>>>>>>>>> for >>>>>>> applying >>>>>>>> security protections, then we ought to keep out things that=20 >>>>>>>> aren't >>>>>>> strictly >>>>>>>> security relevant. Those things can go in application-specific=20= >>>>>>>> content >>>>>>> types >>>>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "defense in depth" and selling this to=20 >>>>>>>>>> government >>>>>>>> agencies: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> CMS, via S/MIME, is in broad use across multiple federal=20 >>>>>>>>>> agencies and >>>>>>>> large enterprises. JSMS is essentially a profile of CMS (see=20= >>>>>>>> Section 7), >>>>>>> and >>>>>>>> has the same security properties. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Originally we only integrity protected the header for = signing. =20 >>>>>>>>>>> We >>>>>>> added >>>>>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>>>>> encryption can >>>>>>> also >>>>>>>> be used for sender verification. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I understand the argument that it makes things simpler if we=20= >>>>>>>>>>> don't >>>>>>>> integrity protect the header information. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> However xmldsig, provides integrity over those elements to=20= >>>>>>>>>>> prevent >>>>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> CMS may not typically provide that integrity protection but = I=20 >>>>>>>>>>> think >>>>>>> Jim >>>>>>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>>>>>=20 >>>>>>>>>>> Given they are on this list they can speak to their view on=20= >>>>>>>>>>> integrity >>>>>>> over >>>>>>>> the crypto parameters. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>>>>> Carlo/Brown >>>>>>>> Bag attack that needs to be considered if we move to something=20= >>>>>>>> more like a detached signature. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> The other design consideration is that we wanted to be able=20= >>>>>>>>>>> to sign >>>>>>>> arbitrary byte strings not just JSON. You could sign XML if = you wanted. >>>>>>>>>=20 >>>>>>>>>>> That prevented us from including meta-data in the body as we=20= >>>>>>>>>>> didn't >>>>>>>> want to touch it. That left us with the header to include = additional >>>>>>> elements >>>>>>>> in. >>>>>>>>>=20 >>>>>>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>>>> arbitrary >>>>>>>> attributes not unlike the current JOSE spec. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Especially for something that will be used with JWT security=20= >>>>>>>>>>> tokens I >>>>>>> will >>>>>>>> have a hard time making the argument to NIST and others that=20 >>>>>>>> need to approve this format that not integrity protecting the=20= >>>>>>>> header parameters is appropriate defence in depth, for = something=20 >>>>>>>> that might be replacing signed SAML assertions in some = applications. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I do understand how not integrity protecting the header will=20= >>>>>>>>>>> make >>>>>>> some >>>>>>>> things easier, however I can't agree that the benefit outweighs=20= >>>>>>>> the disadvantages. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Hey Mike, >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Thanks for having some back-and-forth with me on this. I=20= >>>>>>>>>>>> think this >>>>>>> is a >>>>>>>> good discussion to have right now. I would like to discuss = some >>>>>>> high-level >>>>>>>> points, and then I'll respond inline to your precise points. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20= >>>>>>>>>>>> define >>>>>>> JSON- >>>>>>>> based formats for integrity and confidentiality protections. =20= >>>>>>>> JWE and JWS don't fit that requirement, so we should = re-consider=20 >>>>>>>> their adoption and >>>>>>> call >>>>>>>> for new candidates. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Major points: >>>>>>>>>=20 >>>>>>>>>>>> 1. JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>>>=20 >>>>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 1: JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> The JOSE WG charter calls out four deliverables, three of=20= >>>>>>>>>>>> which are >>>>>>>> explicitly required to be JSON: >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured encryption" >>>>>>>>>=20 >>>>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>>>=20 >>>>>>>>>>>> (The fourth is just a list of algorithms, which should be=20= >>>>>>>>>>>> JSON as >>>>>>>>>=20 >>>>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20= >>>>>>>>>>>> suitable >>>>>>>>>=20 >>>>>>>>>>>> candidates to fulfill the working group's milestones. (At=20= >>>>>>>>>>>> least in >>>>>>>>>=20 >>>>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>>>=20 >>>>>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>>>>> especially >>>>>>>>>=20 >>>>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20= >>>>>>>>>>>> drafts >>>>>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>>>>> cryptographic parameters within the integrity protection, they=20= >>>>>>>> have to have the headers included as base64-encoded strings. =20= >>>>>>>> That obviously adds a lot of >>>>>>> complexity >>>>>>>> to encoding and decoding -- for example, you have to keep the=20= >>>>>>>> encoded header around even after you've decoded it! -- and just = plain more octets. >>>>>>>> The support for multiple recipients and multiple signatures is=20= >>>>>>>> both >>>>>>> unweildy >>>>>>>> (matching up parallel indices for headers and signatures) and=20= >>>>>>>> inefficient (multiple integrity check values in encrypted = objects). >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic=20 >>>>>>>>>>>> wisdom that >>>>>>>> went into CMS, while making the syntax pure JSON and as simple=20= >>>>>>>> as >>>>>>> possible. >>>>>>>> Multiple signatures and multiple recipients are supported with=20= >>>>>>>> absolute minimum overhead. So I think it's worth consideration=20= >>>>>>>> by the working >>>>>>> group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>>>>> requires >>>>>>>>>=20 >>>>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>>>=20 >>>>>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>>>>> included >>>>>>>>>=20 >>>>>>>>>>>> within the integrity protection. I'm not aware of any=20 >>>>>>>>>>>> reason for >>>>>>>>>=20 >>>>>>>>>>>> including the cryptographic parameters in the integrity=20 >>>>>>>>>>>> check, >>>>>>>>>=20 >>>>>>>>>>>> instead of only integrity-protecting the content itself. =20= >>>>>>>>>>>> Indeed, if >>>>>>>>>=20 >>>>>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>>>>> cryptographic >>>>>>>>>=20 >>>>>>>>>>>> parameters, it would be a pretty big deal, since neither = CMS=20 >>>>>>>>>>>> nor IKE >>>>>>>>>=20 >>>>>>>>>>>> nor provides this protection. (TLS does provide a = signature=20 >>>>>>>>>>>> over >>>>>>>>>=20 >>>>>>>>>>>> the algorithms, but only as a way to bind the public key to=20= >>>>>>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> session.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except=20= >>>>>>>>>>>> for >>>>>>>> attributes that are included in the protected content=20 >>>>>>>> (signedAttrs / authenticatedAttrs), which need to be=20 >>>>>>>> DER-encoded. In JSMS, we don't allow those parameters, so = there is no need for canonicalization at all. >>>>>>> All the >>>>>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>>>>> protected content. In that regard, JSMS is even simpler than = JWE/JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>>>>> derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I have absolutely no objection to defining a compact,=20 >>>>>>>>>>>> URL-safe >>>>>>> format. >>>>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20= >>>>>>>> example >>>>>>> from >>>>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> { >>>>>>>>>=20 >>>>>>>>>>>> "v":1, >>>>>>>>>=20 >>>>>>>>>>>> "t":"au", >>>>>>>>>=20 >>>>>>>>>>>> "a":"hs256", >>>>>>>>>=20 >>>>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>>>=20 >>>>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>>>=20 >>>>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>>>=20 >>>>>>>>>>>> } >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20= >>>>>>>>>>>> only >>>>>>>> use >>>>>>>>>=20 >>>>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a=20= >>>>>>>>>>>> step >>>>>>>>>=20 >>>>>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>>>>> AuthenticatedData, >>>>>>>>>=20 >>>>>>>>>>>> we can emulate JWS by moving the content and MAC fields=20 >>>>>>>>>>>> outside >>>>>>>> and >>>>>>>>>=20 >>>>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and=20= >>>>>>>>>>>> only >>>>>>>>>=20 >>>>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put=20= >>>>>>>>>>>> the code >>>>>>>>>=20 >>>>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>>>>> objective, >>>>>>> but it >>>>>>>> makes *much* more sense to derive that from a full-size, = usable,=20 >>>>>>>> JSON format than the other way around. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Responses to specific points inline below. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. = Before=20 >>>>>>>>>>>>> doing >>>>>>> so, I'll >>>>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>>>> understanding >>>>>>>> and consensus, rather than taking the point of view that the=20 >>>>>>>> status quo is >>>>>>> the >>>>>>>> only reasonable outcome. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This was by design, so that the results are URL-safe. = This=20 >>>>>>>>>>>>> is >>>>>>> required, >>>>>>>> for instance, for them to be used as OAuth Bearer Tokens. At=20= >>>>>>>> the request >>>>>>> of >>>>>>>> the working group, closely related pure-JSON drafts were also = published. >>>>>>>> See: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-j >>>>>>>>>>>>> son >>>>>>>>>>>>> -seri >>>>>>>>>=20 >>>>>>>>>>>>> alization-01 and >>>>>>>>>=20 >>>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption- >>>>>>>>>>>>> jso >>>>>>>>>>>>> n-ser >>>>>>>>>=20 >>>>>>>>>>>>> ialization-01 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Use them if you prefer if they better suit your use cases. = =20 >>>>>>>>>>>>> They >>>>>>> could >>>>>>>> be adopted as working group documents, if there's interest. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. These are super-clunky, and the need to be the=20= >>>>>>>>>>>> main >>>>>>>> focus of the WG, not an afterthought. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> The JSON serialization drafts above do, again, in response=20= >>>>>>>>>>>>> to use >>>>>>>> cases presented by the working group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. Because of the unnecessary inclusion of the=20 >>>>>>>>>>>> header in >>>>>>> the >>>>>>>> integrity check, this is far less efficient than it should be. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Functionally, these are very similar operations, at least=20= >>>>>>>>>>>>> from an >>>>>>>> implementation perspective, so it's not clear that making a=20 >>>>>>>> clear >>>>>>> distinction >>>>>>>> would help either developers or adoption in any practical way. =20= >>>>>>>> They >>>>>>> achieve >>>>>>>> overlapping, but admittedly sometimes different goals. I=20 >>>>>>>> believe that developers can be trusted to use the algorithms=20 >>>>>>>> that achieve their applications' goals without making a hard = distinction between the two. >>>>>>> But >>>>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>>>> brighter-line >>>>>>>> distinction might be useful or necessary. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> It's important if you want to do MACs with anything other=20= >>>>>>>>>>>> than >>>>>>>>>>>> pre- >>>>>>>> shared keys. If you want to do anything more advanced, you = need=20 >>>>>>>> to have wrapped keys, in which case an object with a MAC starts=20= >>>>>>>> to look a lot more like a JWE than a JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This seems like an area where the existing drafts could be=20= >>>>>>>>>>>>> refined >>>>>>> to >>>>>>>> add descriptions for additional establishment modalities,=20 >>>>>>>> possibly based upon your ideas and descriptions, should the=20 >>>>>>>> working group decide to do >>>>>>> so. >>>>>>>> What additional modalities do you have use cases for that you=20= >>>>>>>> believe are not achievable or straightforward with the existing=20= >>>>>>>> drafts? The existing modalities supported are largely those=20 >>>>>>>> that existing developers had told >>>>>>> us >>>>>>>> they needed and draw both from the precursor=20 >>>>>>>> draft-jones-json-web-* documents and draft-rescorla-jsms. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Bear in mind that the balance that the current drafts try=20= >>>>>>>>>>>>> to strike >>>>>>> is >>>>>>>> keeping the Mandatory to Implement (MTI) feature footprint = small=20 >>>>>>>> enough that developers, including Web developers, are likely to=20= >>>>>>>> adopt the specs, while still providing enough functionality to = make them generally useful. >>>>>>> As >>>>>>>> in any balance, it's often possible to shift things a bit and=20= >>>>>>>> still >>>>>>> maintain the >>>>>>>> balance, but I'd like people to keep the ubiquitous adoption=20 >>>>>>>> goal >>>>>>> front-and- >>>>>>>> center when proposing additional functionality. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>>>=20 >>>>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to=20 >>>>>>>>>>>>> understand >>>>>>>>>=20 >>>>>>>>>>>>> that!) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I agree that we need to find a reasonable MTI. The current=20= >>>>>>>>>>>> JSMS >>>>>>> draft >>>>>>>> doesn't really specify which parts are MTI, beyond basic things=20= >>>>>>>> like >>>>>>> base64url >>>>>>>> encoding and ignoring unknown fields. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> My main concern is that JWS and JWE don't really tell me=20 >>>>>>>>>>>> which >>>>>>> fields >>>>>>>> need to be present for which use case. If I'm putting a MAC on = a JWS vs. >>>>>>> a >>>>>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>>>>> Whereas in >>>>>>> JSMS, >>>>>>>> I think these things are much clearer due to the separation of=20= >>>>>>>> the use >>>>>>> cases >>>>>>>> (Signed/Authenticated/Encrypted) and the isolation of = signatures=20 >>>>>>>> and wrapped keys into sub-objects. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Most JSON documents aren't clearly typed; instead,=20 >>>>>>>>>>>>> developers and >>>>>>>> implementations understand from context what the meaning of = each field is. >>>>>>>> XML is clearly typed, but developers are voting with their feet=20= >>>>>>>> by moving >>>>>>> to >>>>>>>> JSON. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> What practical advantages resulting from overlaying a=20 >>>>>>>>>>>>> typing >>>>>>>> infrastructure on JSON do you believe are worth the potential=20= >>>>>>>> costs of >>>>>>> doing >>>>>>>> so? BTW, I'm not opposed to having a JSON schema description = of=20 >>>>>>>> the JOSE JSON data structures like JSMS did in >>>>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A,=20= >>>>>>>> but I'll remark that this an informative >>>>>>> tool, not >>>>>>>> a normative one. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I actualy don't have a hugely urgent requirement here = either. =20 >>>>>>>>>>>> It's >>>>>>>> something that others in the WG had requested, which is trivial=20= >>>>>>>> to add in JSMS, but not in JWE/JWS -- again because of the=20 >>>>>>>> unnecessary integrity protection of the header. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> An optional version field could be added if the working=20 >>>>>>>>>>>>> group >>>>>>>>>=20 >>>>>>>>>>>>> desires, however the last time the working group discussed=20= >>>>>>>>>>>>> it, they >>>>>>>>>=20 >>>>>>>>>>>>> decided not to do so. Rather, specs like this effectively=20= >>>>>>>>>>>>> become >>>>>>>>>=20 >>>>>>>>>>>>> "versioned" when revised in a way that new fields are = added. =20 >>>>>>>>>>>>> If >>>>>>>>>=20 >>>>>>>>>>>>> you understand the new fields, you support that new = version. =20 >>>>>>>>>>>>> (Note >>>>>>>>>=20 >>>>>>>>>>>>> that this is independent of whether there is a version=20 >>>>>>>>>>>>> number >>>>>>>>>=20 >>>>>>>>>>>>> field, which according to some participants in the = previous >>>>>>>>>=20 >>>>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>>>=20 >>>>>>>>>>>>> information.) >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> I'm not religious about not having a version number field,=20= >>>>>>>>>>>>> but >>>>>>> often >>>>>>>> "less is more". >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed, I'm not religious either. It just seems like a=20 >>>>>>>>>>>> general good >>>>>>> idea >>>>>>>> to state this directly as opposed to having parsers divine it=20= >>>>>>>> based on >>>>>>> which >>>>>>>> fields are present. To quote RFC 5652: >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>> Each of the major data structures includes a version number=20= >>>>>>>>>>>> as the >>>>>>>>>=20 >>>>>>>>>>>> first item in the data structure. The version numbers are=20= >>>>>>>>>>>> intended >>>>>>>>>=20 >>>>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20= >>>>>>>>>>>> check >>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> version number prior to attempting a decode, and if a = decode=20 >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> occurs, then the version number is checked as part of the=20= >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> handling routine. This is a reasonable approach; it places=20= >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>>>=20 >>>>>>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Best, >>>>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>>>=20 >>>>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>>>=20 >>>>>>>>>>>>> To: Mike Jones >>>>>>>>>=20 >>>>>>>>>>>>> Cc: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. = =20 >>>>>>>>>>>>> IMO, >>>>>>> the >>>>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20= >>>>>>>>>>>>> would be >>>>>>>> simple to adapt them to address these deficiencies. So I just=20= >>>>>>>> did a >>>>>>> re-write. >>>>>>>> If you think they can be addressed within the current = framework,=20 >>>>>>>> please explain. I just found it simpler to start from whole = cloth. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If you're puzzled by specific design decisions in the = JOSE >>>>>>> documents, >>>>>>>> I encourage you to ask about them on the list. The documents=20= >>>>>>>> have significant history going back to mid-2010 when = convergence=20 >>>>>>>> discussions started among people with four different JSON=20 >>>>>>>> signing & encryption proposals. JWT and the current JOSE specs=20= >>>>>>>> and implementations are the result. I realize that not all the=20= >>>>>>>> JOSE participants were part of those discussions from the=20 >>>>>>>> beginning (although many were) and so teasing out the rationale=20= >>>>>>>> for specific decisions might help people better understand the=20= >>>>>>>> choices made, and hopefully thereby increase consensus behind = the eventual working group choices. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20= >>>>>>>>>>>>>> below, >>>>>>> maybe we >>>>>>>> can start a discussion on that basis. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>>> From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org]=20 >>>>>>>>>>>>>> On >>>>>>>>>=20 >>>>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>>>=20 >>>>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>>>=20 >>>>>>>>>>>>>> To: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Dear JOSE WG, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>>>>> thorough >>>>>>>> review of the JW* specs, I was kind of puzzled by some of the=20= >>>>>>>> design decisions. So I also went through and wrote an=20 >>>>>>>> alternative format, this >>>>>>> time >>>>>>>> taking a more of a cue from CMS. A link to the document is = below. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Summary of differences: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the=20 >>>>>>>>>>>>>> header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters are represented in JSON. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS allows for full algorithm agility in key=20 >>>>>>>>>>>>>> agreement, while >>>>>>> JWE >>>>>>>>>=20 >>>>>>>>>>>>>> only allows ECDH-ES. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData = and >>>>>>>>>=20 >>>>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>>>> WrappedKey >>>>>>>>>=20 >>>>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires=20= >>>>>>>>>>>>>> re- >>>>>>>>>=20 >>>>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The signature and MAC functions of the JWS object are=20= >>>>>>>>>>>>>> separated >>>>>>>>>=20 >>>>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they=20= >>>>>>>>>>>>>> are in JWE >>>>>>>>>=20 >>>>>>>>>>>>>> and JWS. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in = JSMS,=20 >>>>>>>>>>>>>> but >>>>>>> could >>>>>>>>>=20 >>>>>>>>>>>>>> be added without significant change. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown=20 >>>>>>>>>>>>>> header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>>>>> implementation >>>>>>> (based >>>>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>>>=20 >>>>>>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Comments are very welcome. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>>>=20 >>>>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has=20= >>>>>>>>>>>>>>> been >>>>>>>>>=20 >>>>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to=20= >>>>>>>>>>>>>>> the IETF >>>>>>>>>=20 >>>>>>>>>>>>>>> repository. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Revision: 00 >>>>>>>>>=20 >>>>>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>>>>=20 >>>>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>>>=20 >>>>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>>>=20 >>>>>>>>>>>>>>> Number of pages: 25 >>>>>>>>>=20 >>>>>>>>>>>>>>> URL: >>>>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>>>> jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Status: >>>>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Abstract: >>>>>>>>>=20 >>>>>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>>>>> cryptographically >>>>>>>>>=20 >>>>>>>>>>>>>>> secured messages. While the IETF has defined a number = of >>>>>>>> formats >>>>>>>>>=20 >>>>>>>>>>>>>>> for such messages (e.g. CMS) those formats use = encodings=20 >>>>>>>>>>>>>>> which >>>>>>>>>=20 >>>>>>>>>>>>>>> are not easy to use in modern applications. This=20 >>>>>>>>>>>>>>> document >>>>>>>>>=20 >>>>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS),=20= >>>>>>>>>>>>>>> a new >>>>>>>>>=20 >>>>>>>>>>>>>>> cryptographic message format which is based on = JavaScript=20 >>>>>>>>>>>>>>> Object >>>>>>>>>=20 >>>>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications = to >>>>>>> generate >>>>>>>> and parse. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Tue Jun 26 14:35: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 30ECD11E8098 for ; Tue, 26 Jun 2012 14:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTKaLnV0hYjI for ; Tue, 26 Jun 2012 14:35:27 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id A8CD221F85C0 for ; Tue, 26 Jun 2012 14:35:26 -0700 (PDT) Received: by yhp26 with SMTP id 26so620174yhp.26 for ; Tue, 26 Jun 2012 14:35:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=uX5sMrl+ySdTwPx8Fjhwbzi5X1KpNda0tuTIrD+kdcs=; b=HMfgKx+m/yn55gBC5BOicXcEvd7XU7z+kEcxzSJANIDp8JFJxcXriE5Qs+LdgMjYvh 8OfepCXZaYNT369pwEA19YD2ob+XY8i+djuFxu4NNWNdewzkDh54qK+FQIEtgFWnsHmX I17mHJdblHVVac54Ss8yhBlRtJNUfuVv2gySRpHYqueLt1aixhwM9URDyAk9X9/EhhqT SpEi2/gTPObIjT0K2nuGMDkug3JkXcscUxcBJuLc/IIHDoRDywFm54k/ee4uG5QByyEp roAphhK3+/4AsZl0zT7oqaC+NtpfdrzEv+jKfaoSzYF8Xb0JDFVRNqUX3Oqwkx6LJXpu PJPA== Received: by 10.236.189.104 with SMTP id b68mr19814030yhn.70.1340746526138; Tue, 26 Jun 2012 14:35:26 -0700 (PDT) Received: from [192.168.1.213] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id l49sm142793119yhj.8.2012.06.26.14.35.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 14:35:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_411F78D9-AF27-4E7B-8142-26BF7E2732D9"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 26 Jun 2012 17:35:14 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnX5eDuBCoyuJWUWaauNmIR0h9XZX3OUScSr3GgfgQp7oqAyLsmxANpa4iNjEbO2rDjpNnb Cc: "Richard L. Barnes" , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:35:30 -0000 --Apple-Mail=_411F78D9-AF27-4E7B-8142-26BF7E2732D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The integrity check is not required for Key Wrap. =20 At the moment AES128KW and AES256KW are what is specified in JWA. =20 Again if people want to extend the KW algs there is nothing to stop them = making proposals. Oh look it's 5:30 and I have to wash my hair. I look forward to rejoining the debate tomorrow:) Regards John B. On 2012-06-26, at 5:23 PM, Anthony Nadalin wrote: > Because it's in most libraries and it works well for key wrap and it's = in a lot of products. That's fine to discuss (and did not say it was not = discussed) but I don't recall reaching a consensus on that point yet. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L. Barnes > Sent: Tuesday, June 26, 2012 2:20 PM > To: John Bradley > Cc: Anthony Nadalin; Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > Why would you ever want to use ECB mode? If you want something fast = and parallelizable, CTR mode is a lot better. >=20 > We had discussed Dave McGrew's draft as a mechanism for specifying = general AEAD algorithms: > >=20 > --Richard >=20 >=20 >=20 >=20 > On Jun 26, 2012, at 5:07 PM, John Bradley wrote: >=20 >> You should suggest adding that as a supported algorithm. >>=20 >> We wanted to keep the core set down to a reasonable number to = encourage interoparability. >>=20 >> AES-ECB + HMAC can be a option if the WG wants it. >>=20 >> John B. >> On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote: >>=20 >>> AES-ECB is also a popular alternative >>>=20 >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Tuesday, June 26, 2012 1:59 PM >>> To: Anthony Nadalin >>> Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for=20 >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> Yes that is why we added the composite HMAC + AES-CBC. We can = debate if that is an algorithm or mandatory integrity with non AEAD = algorithms, but the effect of integrity protecting the header remains in = both cases. >>>=20 >>> John B. >>>=20 >>> On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >>>=20 >>>> Not sure there was a WG decision and what that would mean if there = was, as there are many libraries out there that don't support the = encryption with integrity algorithms, so need to support alternative = means of things like key wrap that could have an integrity check. >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf=20 >>>> Of John Bradley >>>> Sent: Tuesday, June 26, 2012 12:30 PM >>>> To: Richard L. Barnes >>>> Cc: Jim Schaad; jose@ietf.org >>>> Subject: Re: [jose] New Version Notification for=20 >>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>> There was a WG decision to not allow encryption without integrity. = Jim and others call that sender verification. >>>>=20 >>>> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>>>=20 >>>> The JWE/JWS specs don't control the body. That is intended to be = arbitrary content. >>>>=20 >>>> We do have s JWT spec that covers the body for security tokens. = The idea was to separate that from signing and encryption so that = signing and encryption can be used for other objects. >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>>>=20 >>>>>> Now that we are mandating JWE sender verification people will be = using JWE with symmetric keys or key agreement. >>>>>> In those cases one can easily argue that the header should be = protected as much as in HMAC. >>>>>=20 >>>>> Can you clarify the scope of "we are mandating"? >>>>>=20 >>>>>=20 >>>>>> There may well be signing_time or other elements that would go = into the header as well for JWE. >>>>>=20 >>>>> Why do these need to go into the header rather than the body? >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> Richard, >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20= >>>>>>>> Behalf Of Richard L. Barnes >>>>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>>>> To: Nat Sakimura >>>>>>>> Cc: Mike Jones; jose@ietf.org >>>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>>> draft-barnes-jose-jsms- 00.txt >>>>>>>>=20 >>>>>>>> Hi Nat, >>>>>>>>=20 >>>>>>>> I'm not sure what X.509 fiasco you're referring to. There was = a=20 >>>>>>>> recent >>>>>>> MD5 >>>>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact,=20= >>>>>>>> there have >>>>>>> been >>>>>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. =20 >>>>>>>> As >>>>>>> was >>>>>>>> noted on the SAAG list, the real news here is that Microsoft=20 >>>>>>>> wasn't >>>>>>> following >>>>>>>> any of those recommendations. >>>>>>>>=20 >>>>>>>> JWS would have had the same problem as X.509. The attack did=20= >>>>>>>> not modify the cryptographic parameters (anything that would=20 >>>>>>>> have gone in the header), it would not have been thwarted by = the=20 >>>>>>>> integrity protection we're worrying about. >>>>>>>>=20 >>>>>>>> Actually, the header signing that JWS does makes it even nicer=20= >>>>>>>> for the >>>>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20= >>>>>>>> header >>>>>>> value >>>>>>>> is entirely static for a given signer, it's easy to use as a = fixed prefix. >>>>>>> If JWS just >>>>>>>> signed the content, then the application could include a=20 >>>>>>>> something random up front to prevent such prefix-based attacks. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I don't believe that this is a true statement. If you had a=20 >>>>>>> prefix or just signed what was given to you (i.e. no prefix), it=20= >>>>>>> would make no difference in terms of the attack for Flame. = Flame=20 >>>>>>> could always use a fixed prefix of its own design rather than=20 >>>>>>> using the fixed header that is generated by having JWS sign the = header information. >>>>>>>=20 >>>>>>>> It's tempting to say that we should just add randomness to the=20= >>>>>>>> JOSE >>>>>>> format. >>>>>>>> But the real lesson of the Flame/MD5 attacks is operational: = If=20 >>>>>>>> you're >>>>>>> signing >>>>>>>> something that somebody else gave you, make sure that you're = not=20 >>>>>>>> signing exactly what they gave you. Follow the recommendations=20= >>>>>>>> of RFC 4270. In other contexts, there's no need of similar=20 >>>>>>>> random elements; it just adds complexity. >>>>>>>=20 >>>>>>> This is definitely a true statement in all events and is=20 >>>>>>> something that should be added to the Security Considerations = section. >>>>>>>=20 >>>>>>> That being said, I think that there are valid reasons for = wanting=20 >>>>>>> to protect the header information by some authentication = processing. >>>>>>> PKIX certificates protect the signature algorithm information = (by=20 >>>>>>> copying the data into the to be signed block) and CMS has long=20= >>>>>>> allowed for information to be included in the signed attributes=20= >>>>>>> area that identifies the algorithms used, the certificates used=20= >>>>>>> and so forth. There are also other things that we might find to=20= >>>>>>> be convenient to be placed in the header information that is=20 >>>>>>> current not there (a signing time and embedded content type = comes=20 >>>>>>> to mind) that would be a product either of specific types of = signatures or becomes a common attribute to be placed there. >>>>>>>=20 >>>>>>> In terms of encryption operations, I remember in the past that I=20= >>>>>>> have had either corrupted encrypted streams or corrupted IVs and=20= >>>>>>> had a successful decryption that later generated other problems=20= >>>>>>> when trying to parse. This is less of an issue with AEAD=20 >>>>>>> algorithms as they have a much stricter rule on when the stream = decrypts correctly. >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>>=20 >>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> [1]=20 >>>>>>>> >>>>>>>> [2] >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>>>=20 >>>>>>>>> Especially after the X.509 fiasco, I strongly believe that=20 >>>>>>>>> having >>>>>>> integrity >>>>>>>> check over the metadata is a good thing. It is such a little=20 >>>>>>>> effort that >>>>>>> gives us >>>>>>>> much more protection down the road. In this sense, I fully = agree=20 >>>>>>>> with Ben here. We should have integrity protection over the = header. >>>>>>>>>=20 >>>>>>>>> Nat >>>>>>>>>=20 >>>>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>>>> wrote: >>>>>>>>> Two years ago when the developer community needing a=20 >>>>>>>>> JSON-friendly >>>>>>>> token format was designing the JSON Web Token (JWT), we=20 >>>>>>>> explicitly asked security experts whether the header parameters=20= >>>>>>>> should be integrity protected or not. Among them, Ben Laurie=20= >>>>>>>> was one of the voices saying >>>>>>> that >>>>>>>> securing them was the right thing to do. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> He argued that if the parameters can be protected in a=20 >>>>>>>>> practical manner, >>>>>>>> then they should. Doing so provides an additional hurdle that=20= >>>>>>>> attackers would have to surmount. For example, if they can try=20= >>>>>>>> to substitute a >>>>>>> weaker >>>>>>>> authentication scheme, then they must figure out how to make it=20= >>>>>>>> authenticate correctly despite some plaintext they can't = control=20 >>>>>>>> - the >>>>>>> header >>>>>>>> parameters. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Ben also took the position that paring security protocols down=20= >>>>>>>>> to the >>>>>>> least >>>>>>>> you can get away with, given attacks you can think of, is not a=20= >>>>>>>> good >>>>>>> design >>>>>>>> principle. If there is not a strong argument against including=20= >>>>>>>> a feature >>>>>>> that >>>>>>>> may make it harder for attackers, then that feature should be = included. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I agree with him. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The decision to provide integrity protection for the headers = is >>>>>>> documented >>>>>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>>>=20 >>>>>>>>> Given that the envelope is extensible and therefore may = contain >>>>>>> security- >>>>>>>> sensitive information, we reached a consensus (with input from=20= >>>>>>>> Ben Laurie via IM) that the combination envelope.payload must = be signed. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I believe that logic is as sound today as it was then. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>>>>> community's >>>>>>>> decision to provide integrity protection for the headers. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best=20 >>>>>>>>> wishes, >>>>>>>>>=20 >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20= >>>>>>>>> Behalf Of >>>>>>>> John Bradley >>>>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>>>> To: Richard L.Barnes >>>>>>>>> Cc: jose@ietf.org >>>>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>>>> draft-barnes-jose-jsms- >>>>>>>> 00.txt >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> While for PKCS 1.5 the hash algorithm is baked into the = padding=20 >>>>>>>>> and not >>>>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>>>=20 >>>>>>>>> There are possible hash truncation attacks by shortening = SHA256=20 >>>>>>>>> to >>>>>>> SHA224 >>>>>>>> as an example (I know we preclude truncated hashes at the = moment). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The bad feeling I get around this is that if there is a=20 >>>>>>>>> scenario where >>>>>>> the >>>>>>>> attacker controls the plaintext to be signed and there is no=20 >>>>>>>> signer >>>>>>> controlled >>>>>>>> text contributed there are potential bad things that could=20 >>>>>>>> happen down the road. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This bit us with x509 certs not that long ago (yes with MD5 >>>>>>>>> admittedly) >>>>>>>> where the attacker could use a certificate extension to include=20= >>>>>>>> extra data >>>>>>> and >>>>>>>> cause a pre collided hash to be generated. >>>>>>>>>=20 >>>>>>>>> Having part of the signed data outside the control of an=20 >>>>>>>>> attacker is a >>>>>>> good >>>>>>>> thing. (having a nonce or message ID in the envelope is=20 >>>>>>>> possible though >>>>>>> not >>>>>>>> yet required in JWS.) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am still of the opinion that putting the base64 encoded=20 >>>>>>>>> envelope >>>>>>> inside >>>>>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>>>>=20 >>>>>>>>> Another structure to hold the attributes adds more complexity, = =20 >>>>>>>>> as would >>>>>>>> saying that they need to be inside the signed object. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I think part of this is that as one of the openID Connect=20 >>>>>>>>> authors I look >>>>>>> at this >>>>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>>>=20 >>>>>>>>> For that simple processing with one signature is a high=20 >>>>>>>>> priority for >>>>>>> adoption. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =46rom a general signing/encrypting of documents point of view=20= >>>>>>>>> you >>>>>>>> legitimately have different priorities. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I know it is hard to prove a negative but It is also going to=20= >>>>>>>>> be >>>>>>> difficult for me >>>>>>>> to go back to security people at google Facebook and other=20 >>>>>>>> places and explain how not integrity protecting the header = could=20 >>>>>>>> be better than integrity protecting it. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It seems that I would be reduced to arguing that this is no=20 >>>>>>>>> worse than >>>>>>> CMS >>>>>>>> and that hasn't been proven insecure yet. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Allowing a possible attacker to control the hash output, and=20= >>>>>>>>> not >>>>>>> integrity >>>>>>>> protecting the additional data, seems like something I am bound=20= >>>>>>>> to regret >>>>>>> in >>>>>>>> the future. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Hey John, >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Interesting points, but I don't think they actually apply = here. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to downgrade attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The attack that RFC 5752 is concerned with is when an = attacker=20 >>>>>>>>>> strips >>>>>>>> signatures from a signed message, so that the only ones left = are=20 >>>>>>>> ones he >>>>>>> can >>>>>>>> tamper with. So the integrity protection here is "horizontal";=20= >>>>>>>> it goes >>>>>>> across >>>>>>>> signatures. The integrity protection in JWS/JWE is "vertical"=20= >>>>>>>> -- it only >>>>>>> protects >>>>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "brown bag" attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The root of this attack is ambiguity about what content is >>>>>>>>>> *signed* >>>>>>>>>=20 >>>>>>>>>> vs. what content is *used*. If an application doesn't verify=20= >>>>>>>>>> that >>>>>>>>>=20 >>>>>>>>>> it's actually using the stuff that's signed, then it can be=20= >>>>>>>>>> tricked >>>>>>>>>=20 >>>>>>>>>> into accepting something unsigned. (Cf. >>>>>>>>>=20 >>>>>>>>>> ) >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> However, I don't think any of the current proposals have that = problem. >>>>>>>> In JWE/JWS, the signed content is right there between the dots,=20= >>>>>>>> and in >>>>>>> JSMS, >>>>>>>> it's in the "content" element. The current JSMS draft does=20 >>>>>>>> allow detached signatures, but with a "voids your warranty" = sticker on it. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> In any case, these attacks have nothing to do with whether = the >>>>>>>> cryptographic parameters are integrity-protected with the = content. =20 >>>>>>>> The example attacks in the IBM still work regardless -- the=20 >>>>>>>> whole point of the attack is that the cryptographic processing=20= >>>>>>>> is the same, only the >>>>>>> (non-crypto) >>>>>>>> matching of content is flawed. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "arbitrary attributes": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> We can have that here, too, but you need canonicalization. =20= >>>>>>>>>> And >>>>>>> base64- >>>>>>>> encoding is not not canonicalization -- it just waves its hands=20= >>>>>>>> over the question of equivalence. In my opinion, we should = keep=20 >>>>>>>> the cryptographic object simple by disallowing attributes, and=20= >>>>>>>> push the attributes you would sign inside of the thing being=20 >>>>>>>> signed. If people really do want >>>>>>> attributes, it >>>>>>>> doesn't seem to me like JSON canonicalization is very hard. I=20= >>>>>>>> can do it >>>>>>> in 19 >>>>>>>> lines of python: >>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard too "meta-data in the body": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> It seems to me like if we're trying to define a general = format=20 >>>>>>>>>> for >>>>>>> applying >>>>>>>> security protections, then we ought to keep out things that=20 >>>>>>>> aren't >>>>>>> strictly >>>>>>>> security relevant. Those things can go in application-specific=20= >>>>>>>> content >>>>>>> types >>>>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "defense in depth" and selling this to=20 >>>>>>>>>> government >>>>>>>> agencies: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> CMS, via S/MIME, is in broad use across multiple federal=20 >>>>>>>>>> agencies and >>>>>>>> large enterprises. JSMS is essentially a profile of CMS (see=20= >>>>>>>> Section 7), >>>>>>> and >>>>>>>> has the same security properties. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Originally we only integrity protected the header for = signing. =20 >>>>>>>>>>> We >>>>>>> added >>>>>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>>>>> encryption can >>>>>>> also >>>>>>>> be used for sender verification. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I understand the argument that it makes things simpler if we=20= >>>>>>>>>>> don't >>>>>>>> integrity protect the header information. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> However xmldsig, provides integrity over those elements to=20= >>>>>>>>>>> prevent >>>>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> CMS may not typically provide that integrity protection but = I=20 >>>>>>>>>>> think >>>>>>> Jim >>>>>>>> Schaad and Sean Terner created RFC5752 to address downgrade = attacks. >>>>>>>>>=20 >>>>>>>>>>> Given they are on this list they can speak to their view on=20= >>>>>>>>>>> integrity >>>>>>> over >>>>>>>> the crypto parameters. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>>>>> Carlo/Brown >>>>>>>> Bag attack that needs to be considered if we move to something=20= >>>>>>>> more like a detached signature. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> The other design consideration is that we wanted to be able=20= >>>>>>>>>>> to sign >>>>>>>> arbitrary byte strings not just JSON. You could sign XML if = you wanted. >>>>>>>>>=20 >>>>>>>>>>> That prevented us from including meta-data in the body as we=20= >>>>>>>>>>> didn't >>>>>>>> want to touch it. That left us with the header to include = additional >>>>>>> elements >>>>>>>> in. >>>>>>>>>=20 >>>>>>>>>>> Not integrity protecting those elements as well would be a = problem. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>>>> arbitrary >>>>>>>> attributes not unlike the current JOSE spec. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Especially for something that will be used with JWT security=20= >>>>>>>>>>> tokens I >>>>>>> will >>>>>>>> have a hard time making the argument to NIST and others that=20 >>>>>>>> need to approve this format that not integrity protecting the=20= >>>>>>>> header parameters is appropriate defence in depth, for = something=20 >>>>>>>> that might be replacing signed SAML assertions in some = applications. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I do understand how not integrity protecting the header will=20= >>>>>>>>>>> make >>>>>>> some >>>>>>>> things easier, however I can't agree that the benefit outweighs=20= >>>>>>>> the disadvantages. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Hey Mike, >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Thanks for having some back-and-forth with me on this. I=20= >>>>>>>>>>>> think this >>>>>>> is a >>>>>>>> good discussion to have right now. I would like to discuss = some >>>>>>> high-level >>>>>>>> points, and then I'll respond inline to your precise points. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20= >>>>>>>>>>>> define >>>>>>> JSON- >>>>>>>> based formats for integrity and confidentiality protections. =20= >>>>>>>> JWE and JWS don't fit that requirement, so we should = re-consider=20 >>>>>>>> their adoption and >>>>>>> call >>>>>>>> for new candidates. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Major points: >>>>>>>>>=20 >>>>>>>>>>>> 1. JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>>>=20 >>>>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 1: JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> The JOSE WG charter calls out four deliverables, three of=20= >>>>>>>>>>>> which are >>>>>>>> explicitly required to be JSON: >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured encryption" >>>>>>>>>=20 >>>>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>>>=20 >>>>>>>>>>>> (The fourth is just a list of algorithms, which should be=20= >>>>>>>>>>>> JSON as >>>>>>>>>=20 >>>>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20= >>>>>>>>>>>> suitable >>>>>>>>>=20 >>>>>>>>>>>> candidates to fulfill the working group's milestones. (At=20= >>>>>>>>>>>> least in >>>>>>>>>=20 >>>>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>>>=20 >>>>>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>>>>> especially >>>>>>>>>=20 >>>>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20= >>>>>>>>>>>> drafts >>>>>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>>>>> cryptographic parameters within the integrity protection, they=20= >>>>>>>> have to have the headers included as base64-encoded strings. =20= >>>>>>>> That obviously adds a lot of >>>>>>> complexity >>>>>>>> to encoding and decoding -- for example, you have to keep the=20= >>>>>>>> encoded header around even after you've decoded it! -- and just = plain more octets. >>>>>>>> The support for multiple recipients and multiple signatures is=20= >>>>>>>> both >>>>>>> unweildy >>>>>>>> (matching up parallel indices for headers and signatures) and=20= >>>>>>>> inefficient (multiple integrity check values in encrypted = objects). >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic=20 >>>>>>>>>>>> wisdom that >>>>>>>> went into CMS, while making the syntax pure JSON and as simple=20= >>>>>>>> as >>>>>>> possible. >>>>>>>> Multiple signatures and multiple recipients are supported with=20= >>>>>>>> absolute minimum overhead. So I think it's worth consideration=20= >>>>>>>> by the working >>>>>>> group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>>>>> requires >>>>>>>>>=20 >>>>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>>>=20 >>>>>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>>>>> included >>>>>>>>>=20 >>>>>>>>>>>> within the integrity protection. I'm not aware of any=20 >>>>>>>>>>>> reason for >>>>>>>>>=20 >>>>>>>>>>>> including the cryptographic parameters in the integrity=20 >>>>>>>>>>>> check, >>>>>>>>>=20 >>>>>>>>>>>> instead of only integrity-protecting the content itself. =20= >>>>>>>>>>>> Indeed, if >>>>>>>>>=20 >>>>>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>>>>> cryptographic >>>>>>>>>=20 >>>>>>>>>>>> parameters, it would be a pretty big deal, since neither = CMS=20 >>>>>>>>>>>> nor IKE >>>>>>>>>=20 >>>>>>>>>>>> nor provides this protection. (TLS does provide a = signature=20 >>>>>>>>>>>> over >>>>>>>>>=20 >>>>>>>>>>>> the algorithms, but only as a way to bind the public key to=20= >>>>>>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> session.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except=20= >>>>>>>>>>>> for >>>>>>>> attributes that are included in the protected content=20 >>>>>>>> (signedAttrs / authenticatedAttrs), which need to be=20 >>>>>>>> DER-encoded. In JSMS, we don't allow those parameters, so = there is no need for canonicalization at all. >>>>>>> All the >>>>>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>>>>> protected content. In that regard, JSMS is even simpler than = JWE/JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>>>>> derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I have absolutely no objection to defining a compact,=20 >>>>>>>>>>>> URL-safe >>>>>>> format. >>>>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20= >>>>>>>> example >>>>>>> from >>>>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> { >>>>>>>>>=20 >>>>>>>>>>>> "v":1, >>>>>>>>>=20 >>>>>>>>>>>> "t":"au", >>>>>>>>>=20 >>>>>>>>>>>> "a":"hs256", >>>>>>>>>=20 >>>>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>>>=20 >>>>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>>>=20 >>>>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>>>=20 >>>>>>>>>>>> } >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20= >>>>>>>>>>>> only >>>>>>>> use >>>>>>>>>=20 >>>>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a=20= >>>>>>>>>>>> step >>>>>>>>>=20 >>>>>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>>>>> AuthenticatedData, >>>>>>>>>=20 >>>>>>>>>>>> we can emulate JWS by moving the content and MAC fields=20 >>>>>>>>>>>> outside >>>>>>>> and >>>>>>>>>=20 >>>>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and=20= >>>>>>>>>>>> only >>>>>>>>>=20 >>>>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put=20= >>>>>>>>>>>> the code >>>>>>>>>=20 >>>>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>>>>> objective, >>>>>>> but it >>>>>>>> makes *much* more sense to derive that from a full-size, = usable,=20 >>>>>>>> JSON format than the other way around. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Responses to specific points inline below. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. = Before=20 >>>>>>>>>>>>> doing >>>>>>> so, I'll >>>>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>>>> understanding >>>>>>>> and consensus, rather than taking the point of view that the=20 >>>>>>>> status quo is >>>>>>> the >>>>>>>> only reasonable outcome. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This was by design, so that the results are URL-safe. = This=20 >>>>>>>>>>>>> is >>>>>>> required, >>>>>>>> for instance, for them to be used as OAuth Bearer Tokens. At=20= >>>>>>>> the request >>>>>>> of >>>>>>>> the working group, closely related pure-JSON drafts were also = published. >>>>>>>> See: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-j >>>>>>>>>>>>> son >>>>>>>>>>>>> -seri >>>>>>>>>=20 >>>>>>>>>>>>> alization-01 and >>>>>>>>>=20 >>>>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-encryption- >>>>>>>>>>>>> jso >>>>>>>>>>>>> n-ser >>>>>>>>>=20 >>>>>>>>>>>>> ialization-01 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Use them if you prefer if they better suit your use cases. = =20 >>>>>>>>>>>>> They >>>>>>> could >>>>>>>> be adopted as working group documents, if there's interest. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. These are super-clunky, and the need to be the=20= >>>>>>>>>>>> main >>>>>>>> focus of the WG, not an afterthought. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> The JSON serialization drafts above do, again, in response=20= >>>>>>>>>>>>> to use >>>>>>>> cases presented by the working group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. Because of the unnecessary inclusion of the=20 >>>>>>>>>>>> header in >>>>>>> the >>>>>>>> integrity check, this is far less efficient than it should be. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Functionally, these are very similar operations, at least=20= >>>>>>>>>>>>> from an >>>>>>>> implementation perspective, so it's not clear that making a=20 >>>>>>>> clear >>>>>>> distinction >>>>>>>> would help either developers or adoption in any practical way. =20= >>>>>>>> They >>>>>>> achieve >>>>>>>> overlapping, but admittedly sometimes different goals. I=20 >>>>>>>> believe that developers can be trusted to use the algorithms=20 >>>>>>>> that achieve their applications' goals without making a hard = distinction between the two. >>>>>>> But >>>>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>>>> brighter-line >>>>>>>> distinction might be useful or necessary. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> It's important if you want to do MACs with anything other=20= >>>>>>>>>>>> than >>>>>>>>>>>> pre- >>>>>>>> shared keys. If you want to do anything more advanced, you = need=20 >>>>>>>> to have wrapped keys, in which case an object with a MAC starts=20= >>>>>>>> to look a lot more like a JWE than a JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This seems like an area where the existing drafts could be=20= >>>>>>>>>>>>> refined >>>>>>> to >>>>>>>> add descriptions for additional establishment modalities,=20 >>>>>>>> possibly based upon your ideas and descriptions, should the=20 >>>>>>>> working group decide to do >>>>>>> so. >>>>>>>> What additional modalities do you have use cases for that you=20= >>>>>>>> believe are not achievable or straightforward with the existing=20= >>>>>>>> drafts? The existing modalities supported are largely those=20 >>>>>>>> that existing developers had told >>>>>>> us >>>>>>>> they needed and draw both from the precursor=20 >>>>>>>> draft-jones-json-web-* documents and draft-rescorla-jsms. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Bear in mind that the balance that the current drafts try=20= >>>>>>>>>>>>> to strike >>>>>>> is >>>>>>>> keeping the Mandatory to Implement (MTI) feature footprint = small=20 >>>>>>>> enough that developers, including Web developers, are likely to=20= >>>>>>>> adopt the specs, while still providing enough functionality to = make them generally useful. >>>>>>> As >>>>>>>> in any balance, it's often possible to shift things a bit and=20= >>>>>>>> still >>>>>>> maintain the >>>>>>>> balance, but I'd like people to keep the ubiquitous adoption=20 >>>>>>>> goal >>>>>>> front-and- >>>>>>>> center when proposing additional functionality. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>>>=20 >>>>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to=20 >>>>>>>>>>>>> understand >>>>>>>>>=20 >>>>>>>>>>>>> that!) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I agree that we need to find a reasonable MTI. The current=20= >>>>>>>>>>>> JSMS >>>>>>> draft >>>>>>>> doesn't really specify which parts are MTI, beyond basic things=20= >>>>>>>> like >>>>>>> base64url >>>>>>>> encoding and ignoring unknown fields. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> My main concern is that JWS and JWE don't really tell me=20 >>>>>>>>>>>> which >>>>>>> fields >>>>>>>> need to be present for which use case. If I'm putting a MAC on = a JWS vs. >>>>>>> a >>>>>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>>>>> Whereas in >>>>>>> JSMS, >>>>>>>> I think these things are much clearer due to the separation of=20= >>>>>>>> the use >>>>>>> cases >>>>>>>> (Signed/Authenticated/Encrypted) and the isolation of = signatures=20 >>>>>>>> and wrapped keys into sub-objects. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Most JSON documents aren't clearly typed; instead,=20 >>>>>>>>>>>>> developers and >>>>>>>> implementations understand from context what the meaning of = each field is. >>>>>>>> XML is clearly typed, but developers are voting with their feet=20= >>>>>>>> by moving >>>>>>> to >>>>>>>> JSON. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> What practical advantages resulting from overlaying a=20 >>>>>>>>>>>>> typing >>>>>>>> infrastructure on JSON do you believe are worth the potential=20= >>>>>>>> costs of >>>>>>> doing >>>>>>>> so? BTW, I'm not opposed to having a JSON schema description = of=20 >>>>>>>> the JOSE JSON data structures like JSMS did in >>>>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A,=20= >>>>>>>> but I'll remark that this an informative >>>>>>> tool, not >>>>>>>> a normative one. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I actualy don't have a hugely urgent requirement here = either. =20 >>>>>>>>>>>> It's >>>>>>>> something that others in the WG had requested, which is trivial=20= >>>>>>>> to add in JSMS, but not in JWE/JWS -- again because of the=20 >>>>>>>> unnecessary integrity protection of the header. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> An optional version field could be added if the working=20 >>>>>>>>>>>>> group >>>>>>>>>=20 >>>>>>>>>>>>> desires, however the last time the working group discussed=20= >>>>>>>>>>>>> it, they >>>>>>>>>=20 >>>>>>>>>>>>> decided not to do so. Rather, specs like this effectively=20= >>>>>>>>>>>>> become >>>>>>>>>=20 >>>>>>>>>>>>> "versioned" when revised in a way that new fields are = added. =20 >>>>>>>>>>>>> If >>>>>>>>>=20 >>>>>>>>>>>>> you understand the new fields, you support that new = version. =20 >>>>>>>>>>>>> (Note >>>>>>>>>=20 >>>>>>>>>>>>> that this is independent of whether there is a version=20 >>>>>>>>>>>>> number >>>>>>>>>=20 >>>>>>>>>>>>> field, which according to some participants in the = previous >>>>>>>>>=20 >>>>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>>>=20 >>>>>>>>>>>>> information.) >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> I'm not religious about not having a version number field,=20= >>>>>>>>>>>>> but >>>>>>> often >>>>>>>> "less is more". >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed, I'm not religious either. It just seems like a=20 >>>>>>>>>>>> general good >>>>>>> idea >>>>>>>> to state this directly as opposed to having parsers divine it=20= >>>>>>>> based on >>>>>>> which >>>>>>>> fields are present. To quote RFC 5652: >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>> Each of the major data structures includes a version number=20= >>>>>>>>>>>> as the >>>>>>>>>=20 >>>>>>>>>>>> first item in the data structure. The version numbers are=20= >>>>>>>>>>>> intended >>>>>>>>>=20 >>>>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20= >>>>>>>>>>>> check >>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> version number prior to attempting a decode, and if a = decode=20 >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> occurs, then the version number is checked as part of the=20= >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> handling routine. This is a reasonable approach; it places=20= >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>>>=20 >>>>>>>>>>>> forgiving when an incorrect version number is used by the = sender. >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Best, >>>>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>>>=20 >>>>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>>>=20 >>>>>>>>>>>>> To: Mike Jones >>>>>>>>>=20 >>>>>>>>>>>>> Cc: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. = =20 >>>>>>>>>>>>> IMO, >>>>>>> the >>>>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20= >>>>>>>>>>>>> would be >>>>>>>> simple to adapt them to address these deficiencies. So I just=20= >>>>>>>> did a >>>>>>> re-write. >>>>>>>> If you think they can be addressed within the current = framework,=20 >>>>>>>> please explain. I just found it simpler to start from whole = cloth. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If you're puzzled by specific design decisions in the = JOSE >>>>>>> documents, >>>>>>>> I encourage you to ask about them on the list. The documents=20= >>>>>>>> have significant history going back to mid-2010 when = convergence=20 >>>>>>>> discussions started among people with four different JSON=20 >>>>>>>> signing & encryption proposals. JWT and the current JOSE specs=20= >>>>>>>> and implementations are the result. I realize that not all the=20= >>>>>>>> JOSE participants were part of those discussions from the=20 >>>>>>>> beginning (although many were) and so teasing out the rationale=20= >>>>>>>> for specific decisions might help people better understand the=20= >>>>>>>> choices made, and hopefully thereby increase consensus behind = the eventual working group choices. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20= >>>>>>>>>>>>>> below, >>>>>>> maybe we >>>>>>>> can start a discussion on that basis. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>>> From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org]=20 >>>>>>>>>>>>>> On >>>>>>>>>=20 >>>>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>>>=20 >>>>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>>>=20 >>>>>>>>>>>>>> To: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Dear JOSE WG, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>>>>> thorough >>>>>>>> review of the JW* specs, I was kind of puzzled by some of the=20= >>>>>>>> design decisions. So I also went through and wrote an=20 >>>>>>>> alternative format, this >>>>>>> time >>>>>>>> taking a more of a cue from CMS. A link to the document is = below. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Summary of differences: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the=20 >>>>>>>>>>>>>> header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters are represented in JSON. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS allows for full algorithm agility in key=20 >>>>>>>>>>>>>> agreement, while >>>>>>> JWE >>>>>>>>>=20 >>>>>>>>>>>>>> only allows ECDH-ES. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData = and >>>>>>>>>=20 >>>>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>>>> WrappedKey >>>>>>>>>=20 >>>>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires=20= >>>>>>>>>>>>>> re- >>>>>>>>>=20 >>>>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The signature and MAC functions of the JWS object are=20= >>>>>>>>>>>>>> separated >>>>>>>>>=20 >>>>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they=20= >>>>>>>>>>>>>> are in JWE >>>>>>>>>=20 >>>>>>>>>>>>>> and JWS. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in = JSMS,=20 >>>>>>>>>>>>>> but >>>>>>> could >>>>>>>>>=20 >>>>>>>>>>>>>> be added without significant change. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown=20 >>>>>>>>>>>>>> header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>>>>> implementation >>>>>>> (based >>>>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>>>=20 >>>>>>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Comments are very welcome. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>>>=20 >>>>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has=20= >>>>>>>>>>>>>>> been >>>>>>>>>=20 >>>>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to=20= >>>>>>>>>>>>>>> the IETF >>>>>>>>>=20 >>>>>>>>>>>>>>> repository. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Revision: 00 >>>>>>>>>=20 >>>>>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>>>>=20 >>>>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>>>=20 >>>>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>>>=20 >>>>>>>>>>>>>>> Number of pages: 25 >>>>>>>>>=20 >>>>>>>>>>>>>>> URL: >>>>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>>>> jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Status: >>>>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Abstract: >>>>>>>>>=20 >>>>>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>>>>> cryptographically >>>>>>>>>=20 >>>>>>>>>>>>>>> secured messages. While the IETF has defined a number = of >>>>>>>> formats >>>>>>>>>=20 >>>>>>>>>>>>>>> for such messages (e.g. CMS) those formats use = encodings=20 >>>>>>>>>>>>>>> which >>>>>>>>>=20 >>>>>>>>>>>>>>> are not easy to use in modern applications. This=20 >>>>>>>>>>>>>>> document >>>>>>>>>=20 >>>>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS),=20= >>>>>>>>>>>>>>> a new >>>>>>>>>=20 >>>>>>>>>>>>>>> cryptographic message format which is based on = JavaScript=20 >>>>>>>>>>>>>>> Object >>>>>>>>>=20 >>>>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications = to >>>>>>> generate >>>>>>>> and parse. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_411F78D9-AF27-4E7B-8142-26BF7E2732D9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjIxMzUxNFowIwYJKoZIhvcNAQkEMRYEFIjbITzG/0hT9LDBX0Z2FGXdlN4EMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFAiBcEhu4R9lhD9PLjnn8HYTBKHY37nFEpGI8yaAcPMTovKxepEHRrnm9os6+Dikxks0RnxG3+W y7dFQtxnF8CGA57PAdv6CbNuisRf0gs+iCJHvMtVvBp838BL8p8FRAYlJ6t76b5lcKO0gpXiBudS ZLxXnUzm2iyAopF2W1Kd7f5u25VR2JcH/QuC/blmWBZYgoKx1PNQPthwXK4s1xtprbd+1naYhVCw XTegjoBOsQ08hjo+kn40VVDmk+/5Jnh3tCsi9fHYdyjLeAMaiu1M2n8DcZzyMP7n+TeBeyNrgc2N p/PJWhXlD99VR3+JiWVSmi1HZcIpw6psjGfcwwgAAAAAAAA= --Apple-Mail=_411F78D9-AF27-4E7B-8142-26BF7E2732D9-- From Michael.Jones@microsoft.com Tue Jun 26 15:04: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 2F5FC11E809F for ; Tue, 26 Jun 2012 15:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.822 X-Spam-Level: X-Spam-Status: No, score=-3.822 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRSDlrCMskE5 for ; Tue, 26 Jun 2012 15:04:10 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 32B0F11E8097 for ; Tue, 26 Jun 2012 15:04:09 -0700 (PDT) Received: from mail263-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 22:02:27 +0000 Received: from mail263-va3 (localhost [127.0.0.1]) by mail263-va3-R.bigfish.com (Postfix) with ESMTP id 6BE763C005B; Tue, 26 Jun 2012 22:02:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail263-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=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail263-va3 (localhost.localdomain [127.0.0.1]) by mail263-va3 (MessageSwitch) id 1340748145134081_23933; Tue, 26 Jun 2012 22:02:25 +0000 (UTC) Received: from VA3EHSMHS042.bigfish.com (unknown [10.7.14.243]) by mail263-va3.bigfish.com (Postfix) with ESMTP id 1592E640042; Tue, 26 Jun 2012 22:02:25 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS042.bigfish.com (10.7.99.52) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 22:02:24 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Tue, 26 Jun 2012 22:03:26 +0000 From: Mike Jones To: "Richard L. Barnes" , Brian Campbell Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: Ac1T54J3Hq2uD/biTxyDhHQtQaL+4Q== Date: Tue, 26 Jun 2012 22:03:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366569B1D@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: John Bradley , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:04:11 -0000 http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializatio= n-01 is an existence proof that it's not hard to sign the parameters and ha= ve multiple signatures. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Tuesday, June 26, 2012 10:46 AM To: Brian Campbell Cc: John Bradley; jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt I agree with that goal! I disagree that JWS is a good solution. =20 It is true that JWS provides a relatively simple mechanism for a single sig= nature, but: 1. It could be simpler (see below) 2. JWS header protection is useless for the single-signature case, and make= s the multiple-signature/recipient case harder --Richard On Jun 26, 2012, at 12:16 PM, Brian Campbell wrote: > I wasn't suggesting that integrity-protecting the header itself makes=20 > things simpler. Rather that a desirable goal is for support of a=20 > relatively simple model utilizing a single signature over the whole=20 > message. And that we already have that in JWS. >=20 > On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes wrot= e: >>=20 >> On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: >>=20 >>>>> I think part of this is that as one of the openID Connect authors I l= ook at this as a necessary security token format, for OAuth and Connect. >>>>> For that simple processing with one signature is a high priority for = adoption. >>>>=20 >>>> +1. >>>>=20 >>>> A simple JSON friendly model supporting a single signature over the=20 >>>> entire message (including headers) is an important case for=20 >>>> adoption (and security). JWS provides that now and there are=20 >>>> already numerous interoperable JWS implementations available or in the= works. >>>=20 >>> I'm not sure how people think that integrity-protecting the header make= s things *simpler*, especially since it adds a whole new decoding step and = makes the parsing more complicated. >>>=20 >>> Pseudocode without integrity protection (assuming JSMS format, but JWS = could be made to look similar): >>> function verify(json) { >>> jose =3D JSON.parse(json); >>> // Check algorithm values >>> return Crypto.SignatureAlgorithm.verify(jose.content,=20 >>> jose.keys[0].signature, jose.keys[0].key); } >>>=20 >>> Pseudocode with integrity protection (assuming JWS format): >>> function verify(jws) { >>> (txtHeader, content, signature) =3D jws.split("\."); >>> protectedBody =3D header + "." + content >>> jsonHeader =3D base64url.decode(txtHeader); >>> header =3D JSON.parse(jsonHeader); >>> return Crypto.SignatureAlgorithm.verify(content, signature,=20 >>> header.jwk); } >>>=20 >>=20 >> Err, sorry, that should read: >> protectedBody =3D txtHeader + "." + content; and >> return Crypto.SignatureAlgorithm.verify(protectedBody, signature,=20 >> header.jwk); >>=20 >> See how hard it is to get right? :) >>=20 >> --Richard > _______________________________________________ > 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 rbarnes@bbn.com Tue Jun 26 15:21: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 7394B11E809F for ; Tue, 26 Jun 2012 15:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.238 X-Spam-Level: X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stn4-r716eHq for ; Tue, 26 Jun 2012 15:21:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEC311E8097 for ; Tue, 26 Jun 2012 15:21:16 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:61492) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sje8H-0008xt-2C; Tue, 26 Jun 2012 18:21:13 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366569B1D@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 26 Jun 2012 18:21:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <57BD4255-754D-4B6D-A194-587243FF17F3@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366569B1D@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: John Bradley , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:21:18 -0000 Sure, multiple signature is easier than multiple recipients. But I = wouldn't call it simple. I have to base64url-decode each header to = figure out which one to use (but keep around the encoded version, so I = can verify the signature), keep track of the corresponding signature = value, and reconstruct the signed body -- all before I can do the actual = signature verification. OTOH, without integrity-protection, you can just have the signature = beside all the other parameters, in plain JSON, so that you can just = grab stuff and go. =46rom : verify: function(object) { var jsms =3D JSON.parse(object); if (!_JOSE_Support.isSignedData(jsms)) { throw "Invalid SignedData object"; } // Figure out which signatures are valid var validPublicKeys =3D []; var sigs =3D jsms.signatures; for (var i=3D0; i = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 is an existence proof that it's not hard to sign the parameters = and have multiple signatures. >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L. Barnes > Sent: Tuesday, June 26, 2012 10:46 AM > To: Brian Campbell > Cc: John Bradley; jose@ietf.org > Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >=20 > I agree with that goal! I disagree that JWS is a good solution. =20 >=20 > It is true that JWS provides a relatively simple mechanism for a = single signature, but: > 1. It could be simpler (see below) > 2. JWS header protection is useless for the single-signature case, and = makes the multiple-signature/recipient case harder >=20 > --Richard >=20 >=20 >=20 > On Jun 26, 2012, at 12:16 PM, Brian Campbell wrote: >=20 >> I wasn't suggesting that integrity-protecting the header itself makes=20= >> things simpler. Rather that a desirable goal is for support of a=20 >> relatively simple model utilizing a single signature over the whole=20= >> message. And that we already have that in JWS. >>=20 >> On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes = wrote: >>>=20 >>> On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: >>>=20 >>>>>> I think part of this is that as one of the openID Connect authors = I look at this as a necessary security token format, for OAuth and = Connect. >>>>>> For that simple processing with one signature is a high priority = for adoption. >>>>>=20 >>>>> +1. >>>>>=20 >>>>> A simple JSON friendly model supporting a single signature over = the=20 >>>>> entire message (including headers) is an important case for=20 >>>>> adoption (and security). JWS provides that now and there are=20 >>>>> already numerous interoperable JWS implementations available or in = the works. >>>>=20 >>>> I'm not sure how people think that integrity-protecting the header = makes things *simpler*, especially since it adds a whole new decoding = step and makes the parsing more complicated. >>>>=20 >>>> Pseudocode without integrity protection (assuming JSMS format, but = JWS could be made to look similar): >>>> function verify(json) { >>>> jose =3D JSON.parse(json); >>>> // Check algorithm values >>>> return Crypto.SignatureAlgorithm.verify(jose.content,=20 >>>> jose.keys[0].signature, jose.keys[0].key); } >>>>=20 >>>> Pseudocode with integrity protection (assuming JWS format): >>>> function verify(jws) { >>>> (txtHeader, content, signature) =3D jws.split("\."); >>>> protectedBody =3D header + "." + content >>>> jsonHeader =3D base64url.decode(txtHeader); >>>> header =3D JSON.parse(jsonHeader); >>>> return Crypto.SignatureAlgorithm.verify(content, signature,=20 >>>> header.jwk); } >>>>=20 >>>=20 >>> Err, sorry, that should read: >>> protectedBody =3D txtHeader + "." + content; and >>> return Crypto.SignatureAlgorithm.verify(protectedBody, signature,=20= >>> header.jwk); >>>=20 >>> See how hard it is to get right? :) >>>=20 >>> --Richard >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Tue Jun 26 15:24: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 C855D11E80DE for ; Tue, 26 Jun 2012 15:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2JVtOcctonO for ; Tue, 26 Jun 2012 15:24:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A573B11E80D7 for ; Tue, 26 Jun 2012 15:24:00 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:61493) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjeAI-0007Us-Fh; Tue, 26 Jun 2012 18:23:18 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <57BD4255-754D-4B6D-A194-587243FF17F3@bbn.com> Date: Tue, 26 Jun 2012 18:23:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366569B1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <57BD4255-754D-4B6D-A194-587243FF17F3@bbn.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: John Bradley , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:24:01 -0000 > Sure, multiple signature is easier than multiple recipients. But I = wouldn't call it simple. I have to base64url-decode each header to = figure out which one to use (but keep around the encoded version, so I = can verify the signature), keep track of the corresponding signature = value, and reconstruct the signed body -- all before I can do the actual = signature verification. >=20 > OTOH, without integrity-protection, you can just have the signature = beside all the other parameters, in plain JSON, so that you can just = grab stuff and go. Addendum: This assumes that you're doing the base64-encoding thing to = allow integrity protection. If we do canonicalization, this issue goes = away. But then we have to do canonicalization. > =46rom : >=20 > verify: function(object) { > var jsms =3D JSON.parse(object); > if (!_JOSE_Support.isSignedData(jsms)) { > throw "Invalid SignedData object"; > } >=20 > // Figure out which signatures are valid > var validPublicKeys =3D []; > var sigs =3D jsms.signatures; > for (var i=3D0; i var result =3D _JOSE_Crypto.verify_pkcs1_sha256( > sigs[i].key.n, sigs[i].key.e, jsms.content, = sigs[i].signature) > if (result =3D "True") { > validPublicKeys.push(sigs[i].key); > } > } >=20 > return validPublicKeys; > } >=20 >=20 >=20 >=20 > On Jun 26, 2012, at 6:03 PM, Mike Jones wrote: >=20 >> = http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 is an existence proof that it's not hard to sign the parameters = and have multiple signatures. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L. Barnes >> Sent: Tuesday, June 26, 2012 10:46 AM >> To: Brian Campbell >> Cc: John Bradley; jose@ietf.org >> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms-00.txt >>=20 >> I agree with that goal! I disagree that JWS is a good solution. =20 >>=20 >> It is true that JWS provides a relatively simple mechanism for a = single signature, but: >> 1. It could be simpler (see below) >> 2. JWS header protection is useless for the single-signature case, = and makes the multiple-signature/recipient case harder >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Jun 26, 2012, at 12:16 PM, Brian Campbell wrote: >>=20 >>> I wasn't suggesting that integrity-protecting the header itself = makes=20 >>> things simpler. Rather that a desirable goal is for support of a=20 >>> relatively simple model utilizing a single signature over the whole=20= >>> message. And that we already have that in JWS. >>>=20 >>> On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes = wrote: >>>>=20 >>>> On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: >>>>=20 >>>>>>> I think part of this is that as one of the openID Connect = authors I look at this as a necessary security token format, for OAuth = and Connect. >>>>>>> For that simple processing with one signature is a high priority = for adoption. >>>>>>=20 >>>>>> +1. >>>>>>=20 >>>>>> A simple JSON friendly model supporting a single signature over = the=20 >>>>>> entire message (including headers) is an important case for=20 >>>>>> adoption (and security). JWS provides that now and there are=20 >>>>>> already numerous interoperable JWS implementations available or = in the works. >>>>>=20 >>>>> I'm not sure how people think that integrity-protecting the header = makes things *simpler*, especially since it adds a whole new decoding = step and makes the parsing more complicated. >>>>>=20 >>>>> Pseudocode without integrity protection (assuming JSMS format, but = JWS could be made to look similar): >>>>> function verify(json) { >>>>> jose =3D JSON.parse(json); >>>>> // Check algorithm values >>>>> return Crypto.SignatureAlgorithm.verify(jose.content,=20 >>>>> jose.keys[0].signature, jose.keys[0].key); } >>>>>=20 >>>>> Pseudocode with integrity protection (assuming JWS format): >>>>> function verify(jws) { >>>>> (txtHeader, content, signature) =3D jws.split("\."); >>>>> protectedBody =3D header + "." + content >>>>> jsonHeader =3D base64url.decode(txtHeader); >>>>> header =3D JSON.parse(jsonHeader); >>>>> return Crypto.SignatureAlgorithm.verify(content, signature,=20 >>>>> header.jwk); } >>>>>=20 >>>>=20 >>>> Err, sorry, that should read: >>>> protectedBody =3D txtHeader + "." + content; and >>>> return Crypto.SignatureAlgorithm.verify(protectedBody, signature,=20= >>>> header.jwk); >>>>=20 >>>> See how hard it is to get right? :) >>>>=20 >>>> --Richard >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Tue Jun 26 15:37: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 0EFD611E808E for ; Tue, 26 Jun 2012 15:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w9d6aUKFwqZ for ; Tue, 26 Jun 2012 15:37:06 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 230FB11E8087 for ; Tue, 26 Jun 2012 15:37:06 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 8EB392CA30; Tue, 26 Jun 2012 15:37:05 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" , "'Richard L. Barnes'" References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> In-Reply-To: <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> Date: Tue, 26 Jun 2012 15:35:49 -0700 Message-ID: <00e401cd53ec$09b979f0$1d2c6dd0$@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: AQD47QI5KEiTUDL2CmgL/J0d6D+eqAIQ+tNPAngGm3sBp8FZzQCi2RReAsTTS8kCA+Ah35hZGznw Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:37:09 -0000 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Tuesday, June 26, 2012 12:30 PM > To: Richard L. Barnes > Cc: Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms- > 00.txt > > There was a WG decision to not allow encryption without integrity. Jim and > others call that sender verification. Jim would not call that sender verification. Jim would call that integrity protection on the transmitted content. There is no concept of data origination with any type of AE algorithm. > > Or on simple terms no AES-CBC without a mandatory MAC integrity. > > The JWE/JWS specs don't control the body. That is intended to be arbitrary > content. > > We do have s JWT spec that covers the body for security tokens. The idea > was to separate that from signing and encryption so that signing and > encryption can be used for other objects. > > John B. > > On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: > > >> Now that we are mandating JWE sender verification people will be using > JWE with symmetric keys or key agreement. > >> In those cases one can easily argue that the header should be protected > as much as in HMAC. > > > > Can you clarify the scope of "we are mandating"? > > > > > >> There may well be signing_time or other elements that would go into the > header as well for JWE. > > > > Why do these need to go into the header rather than the body? > > > > --Richard > > > > > > > > > >> Regards > >> John B. > >> > >> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: > >> > >>> > >>> > >>> Richard, > >>> > >>>> -----Original Message----- > >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > Behalf Of > >>>> Richard L. Barnes > >>>> Sent: Monday, June 25, 2012 2:35 PM > >>>> To: Nat Sakimura > >>>> Cc: Mike Jones; jose@ietf.org > >>>> Subject: Re: [jose] New Version Notification for draft-barnes-jose- > jsms- > >>>> 00.txt > >>>> > >>>> Hi Nat, > >>>> > >>>> I'm not sure what X.509 fiasco you're referring to. There was a recent > >>> MD5 > >>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, there have > >>> been > >>>> recommendations for preventing this attack in X.509 since 2005 [2]. As > >>> was > >>>> noted on the SAAG list, the real news here is that Microsoft wasn't > >>> following > >>>> any of those recommendations. > >>>> > >>>> JWS would have had the same problem as X.509. The attack did not > modify > >>>> the cryptographic parameters (anything that would have gone in the > >>>> header), it would not have been thwarted by the integrity protection > we're > >>>> worrying about. > >>>> > >>>> Actually, the header signing that JWS does makes it even nicer for the > >>>> attacker: Flame used a "chosen prefix" attack, so since the JWS header > >>> value > >>>> is entirely static for a given signer, it's easy to use as a fixed prefix. > >>> If JWS just > >>>> signed the content, then the application could include a something > random > >>>> up front to prevent such prefix-based attacks. > >>>> > >>> > >>> I don't believe that this is a true statement. If you had a prefix or just > >>> signed what was given to you (i.e. no prefix), it would make no > difference > >>> in terms of the attack for Flame. Flame could always use a fixed prefix of > >>> its own design rather than using the fixed header that is generated by > >>> having JWS sign the header information. > >>> > >>>> It's tempting to say that we should just add randomness to the JOSE > >>> format. > >>>> But the real lesson of the Flame/MD5 attacks is operational: If you're > >>> signing > >>>> something that somebody else gave you, make sure that you're not > signing > >>>> exactly what they gave you. Follow the recommendations of RFC 4270. > In > >>>> other contexts, there's no need of similar random elements; it just > adds > >>>> complexity. > >>> > >>> This is definitely a true statement in all events and is something that > >>> should be added to the Security Considerations section. > >>> > >>> That being said, I think that there are valid reasons for wanting to protect > >>> the header information by some authentication processing. PKIX > certificates > >>> protect the signature algorithm information (by copying the data into the > to > >>> be signed block) and CMS has long allowed for information to be > included in > >>> the signed attributes area that identifies the algorithms used, the > >>> certificates used and so forth. There are also other things that we might > >>> find to be convenient to be placed in the header information that is > current > >>> not there (a signing time and embedded content type comes to mind) > that > >>> would be a product either of specific types of signatures or becomes a > >>> common attribute to be placed there. > >>> > >>> In terms of encryption operations, I remember in the past that I have > had > >>> either corrupted encrypted streams or corrupted IVs and had a > successful > >>> decryption that later generated other problems when trying to parse. > This > >>> is less of an issue with AEAD algorithms as they have a much stricter rule > >>> on when the stream decrypts correctly. > >>> > >>> Jim > >>> > >>>> > >>>> --Richard > >>>> > >>>> > >>>> > >>>> [1] > >>>> [2] > >>>> > >>>> > >>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: > >>>> > >>>>> Especially after the X.509 fiasco, I strongly believe that having > >>> integrity > >>>> check over the metadata is a good thing. It is such a little effort that > >>> gives us > >>>> much more protection down the road. In this sense, I fully agree with > Ben > >>>> here. We should have integrity protection over the header. > >>>>> > >>>>> Nat > >>>>> > >>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones > >>>> wrote: > >>>>> Two years ago when the developer community needing a JSON- > friendly > >>>> token format was designing the JSON Web Token (JWT), we explicitly > asked > >>>> security experts whether the header parameters should be integrity > >>>> protected or not. Among them, Ben Laurie was one of the voices > saying > >>> that > >>>> securing them was the right thing to do. > >>>>> > >>>>> > >>>>> > >>>>> He argued that if the parameters can be protected in a practical > manner, > >>>> then they should. Doing so provides an additional hurdle that attackers > >>>> would have to surmount. For example, if they can try to substitute a > >>> weaker > >>>> authentication scheme, then they must figure out how to make it > >>>> authenticate correctly despite some plaintext they can't control - the > >>> header > >>>> parameters. > >>>>> > >>>>> > >>>>> > >>>>> Ben also took the position that paring security protocols down to the > >>> least > >>>> you can get away with, given attacks you can think of, is not a good > >>> design > >>>> principle. If there is not a strong argument against including a feature > >>> that > >>>> may make it harder for attackers, then that feature should be included. > >>>>> > >>>>> > >>>>> > >>>>> I agree with him. > >>>>> > >>>>> > >>>>> > >>>>> The decision to provide integrity protection for the headers is > >>> documented > >>>> in the session notes at http://self-issued.info/?p=361, which said: > >>>>> > >>>>> > >>>>> > >>>>> . What to sign (envelope.payload or just payload)? > >>>>> > >>>>> Given that the envelope is extensible and therefore may contain > >>> security- > >>>> sensitive information, we reached a consensus (with input from Ben > Laurie > >>>> via IM) that the combination envelope.payload must be signed. > >>>>> > >>>>> > >>>>> I believe that logic is as sound today as it was then. > >>>>> > >>>>> > >>>>> > >>>>> For all these reasons, I therefore personally stand by the community's > >>>> decision to provide integrity protection for the headers. > >>>>> > >>>>> > >>>>> > >>>>> Best wishes, > >>>>> > >>>>> -- Mike > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > Behalf Of > >>>> John Bradley > >>>>> Sent: Wednesday, June 20, 2012 3:57 PM > >>>>> To: Richard L.Barnes > >>>>> Cc: jose@ietf.org > >>>>> Subject: Re: [jose] New Version Notification for draft-barnes-jose- > jsms- > >>>> 00.txt > >>>>> > >>>>> > >>>>> > >>>>> Hi Richard, > >>>>> > >>>>> > >>>>> > >>>>> While for PKCS 1.5 the hash algorithm is baked into the padding and > not > >>>> susceptible to modification with ECDH or RSA-PSS it is not. > >>>>> > >>>>> There are possible hash truncation attacks by shortening SHA256 to > >>> SHA224 > >>>> as an example (I know we preclude truncated hashes at the moment). > >>>>> > >>>>> > >>>>> > >>>>> The bad feeling I get around this is that if there is a scenario where > >>> the > >>>> attacker controls the plaintext to be signed and there is no signer > >>> controlled > >>>> text contributed there are potential bad things that could happen > down the > >>>> road. > >>>>> > >>>>> > >>>>> > >>>>> This bit us with x509 certs not that long ago (yes with MD5 admittedly) > >>>> where the attacker could use a certificate extension to include extra > data > >>> and > >>>> cause a pre collided hash to be generated. > >>>>> > >>>>> Having part of the signed data outside the control of an attacker is a > >>> good > >>>> thing. (having a nonce or message ID in the envelope is possible > though > >>> not > >>>> yet required in JWS.) > >>>>> > >>>>> > >>>>> > >>>>> I am still of the opinion that putting the base64 encoded envelope > >>> inside > >>>> the hash calculation is a valid way to allow additional attributes. > >>>>> > >>>>> Another structure to hold the attributes adds more complexity, as > would > >>>> saying that they need to be inside the signed object. > >>>>> > >>>>> > >>>>> > >>>>> I think part of this is that as one of the openID Connect authors I look > >>> at this > >>>> as a necessary security token format, for OAuth and Connect. > >>>>> > >>>>> For that simple processing with one signature is a high priority for > >>> adoption. > >>>>> > >>>>> > >>>>> > >>>>> From a general signing/encrypting of documents point of view you > >>>> legitimately have different priorities. > >>>>> > >>>>> > >>>>> > >>>>> I know it is hard to prove a negative but It is also going to be > >>> difficult for me > >>>> to go back to security people at google Facebook and other places and > >>>> explain how not integrity protecting the header could be better than > >>>> integrity protecting it. > >>>>> > >>>>> > >>>>> > >>>>> It seems that I would be reduced to arguing that this is no worse than > >>> CMS > >>>> and that hasn't been proven insecure yet. > >>>>> > >>>>> > >>>>> > >>>>> Allowing a possible attacker to control the hash output, and not > >>> integrity > >>>> protecting the additional data, seems like something I am bound to > regret > >>> in > >>>> the future. > >>>>> > >>>>> > >>>>> > >>>>> Regards > >>>>> > >>>>> John B. > >>>>> > >>>>> > >>>>> > >>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Hey John, > >>>>> > >>>>>> > >>>>> > >>>>>> Interesting points, but I don't think they actually apply here. > >>>>> > >>>>>> > >>>>> > >>>>>> With regard to downgrade attacks: > >>>>> > >>>>>> > >>>>> > >>>>>> The attack that RFC 5752 is concerned with is when an attacker strips > >>>> signatures from a signed message, so that the only ones left are ones > he > >>> can > >>>> tamper with. So the integrity protection here is "horizontal"; it goes > >>> across > >>>> signatures. The integrity protection in JWS/JWE is "vertical" -- it only > >>> protects > >>>> one signer's parameters -- so it is, so to speak, orthogonal. > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> With regard to "brown bag" attacks: > >>>>> > >>>>>> > >>>>> > >>>>>> The root of this attack is ambiguity about what content is *signed* > >>>>> > >>>>>> vs. what content is *used*. If an application doesn't verify that > >>>>> > >>>>>> it's actually using the stuff that's signed, then it can be tricked > >>>>> > >>>>>> into accepting something unsigned. (Cf. > >>>>> > >>>>>> ) > >>>>> > >>>>>> > >>>>> > >>>>>> However, I don't think any of the current proposals have that > problem. > >>>> In JWE/JWS, the signed content is right there between the dots, and in > >>> JSMS, > >>>> it's in the "content" element. The current JSMS draft does allow > detached > >>>> signatures, but with a "voids your warranty" sticker on it. > >>>>> > >>>>>> > >>>>> > >>>>>> In any case, these attacks have nothing to do with whether the > >>>> cryptographic parameters are integrity-protected with the content. > The > >>>> example attacks in the IBM still work regardless -- the whole point of > the > >>>> attack is that the cryptographic processing is the same, only the > >>> (non-crypto) > >>>> matching of content is flawed. > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> With regard to "arbitrary attributes": > >>>>> > >>>>>> > >>>>> > >>>>>> We can have that here, too, but you need canonicalization. And > >>> base64- > >>>> encoding is not not canonicalization -- it just waves its hands over the > >>>> question of equivalence. In my opinion, we should keep the > cryptographic > >>>> object simple by disallowing attributes, and push the attributes you > would > >>>> sign inside of the thing being signed. If people really do want > >>> attributes, it > >>>> doesn't seem to me like JSON canonicalization is very hard. I can do it > >>> in 19 > >>>> lines of python: > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> With regard too "meta-data in the body": > >>>>> > >>>>>> > >>>>> > >>>>>> It seems to me like if we're trying to define a general format for > >>> applying > >>>> security protections, then we ought to keep out things that aren't > >>> strictly > >>>> security relevant. Those things can go in application-specific content > >>> types > >>>> (e.g., SAML) without polluting the general purpose header. > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> With regard to "defense in depth" and selling this to government > >>>> agencies: > >>>>> > >>>>>> > >>>>> > >>>>>> CMS, via S/MIME, is in broad use across multiple federal agencies > and > >>>> large enterprises. JSMS is essentially a profile of CMS (see Section 7), > >>> and > >>>> has the same security properties. > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> Cheers, > >>>>> > >>>>>> --Richard > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: > >>>>> > >>>>>> > >>>>> > >>>>>>> Hi Richard, > >>>>> > >>>>>>> > >>>>> > >>>>>>> Originally we only integrity protected the header for signing. We > >>> added > >>>> the integrity protection to encryption as part of AEAD, as encryption > can > >>> also > >>>> be used for sender verification. > >>>>> > >>>>>>> > >>>>> > >>>>>>> I understand the argument that it makes things simpler if we don't > >>>> integrity protect the header information. > >>>>> > >>>>>>> > >>>>> > >>>>>>> However xmldsig, provides integrity over those elements to > prevent > >>>> possible downgrade attacks by manipulating the algorithms. > >>>>> > >>>>>>> > >>>>> > >>>>>>> CMS may not typically provide that integrity protection but I think > >>> Jim > >>>> Schaad and Sean Terner created RFC5752 to address downgrade > attacks. > >>>>> > >>>>>>> Given they are on this list they can speak to their view on integrity > >>> over > >>>> the crypto parameters. > >>>>> > >>>>>>> > >>>>> > >>>>>>> I also recall when working on InfoCards there was a Monte > Carlo/Brown > >>>> Bag attack that needs to be considered if we move to something more > like a > >>>> detached signature. > >>>>> > >>>>>>> > >>>>> > >>>>>>> The other design consideration is that we wanted to be able to sign > >>>> arbitrary byte strings not just JSON. You could sign XML if you wanted. > >>>>> > >>>>>>> That prevented us from including meta-data in the body as we > didn't > >>>> want to touch it. That left us with the header to include additional > >>> elements > >>>> in. > >>>>> > >>>>>>> Not integrity protecting those elements as well would be a > problem. > >>>>> > >>>>>>> > >>>>> > >>>>>>> I am not a CMS expert but I believe it allows for signing of > >>> arbitrary > >>>> attributes not unlike the current JOSE spec. > >>>>> > >>>>>>> > >>>>> > >>>>>>> Especially for something that will be used with JWT security tokens I > >>> will > >>>> have a hard time making the argument to NIST and others that need to > >>>> approve this format that not integrity protecting the header > parameters is > >>>> appropriate defence in depth, for something that might be replacing > signed > >>>> SAML assertions in some applications. > >>>>> > >>>>>>> > >>>>> > >>>>>>> I do understand how not integrity protecting the header will make > >>> some > >>>> things easier, however I can't agree that the benefit outweighs the > >>>> disadvantages. > >>>>> > >>>>>>> > >>>>> > >>>>>>> Regards > >>>>> > >>>>>>> John B. > >>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>> > >>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: > >>>>> > >>>>>>> > >>>>> > >>>>>>>> Hey Mike, > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Thanks for having some back-and-forth with me on this. I think > this > >>> is a > >>>> good discussion to have right now. I would like to discuss some > >>> high-level > >>>> points, and then I'll respond inline to your precise points. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to define > >>> JSON- > >>>> based formats for integrity and confidentiality protections. JWE and > JWS > >>>> don't fit that requirement, so we should re-consider their adoption and > >>> call > >>>> for new candidates. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Major points: > >>>>> > >>>>>>>> 1. JOSE is JSON > >>>>> > >>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and > >>>>> > >>>>>>>> URL-safeness are still OK, as derivatives > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Part 1: JOSE is JSON > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> The JOSE WG charter calls out four deliverables, three of which > are > >>>> explicitly required to be JSON: > >>>>> > >>>>>>>> -- "JSON-structured integrity protection" > >>>>> > >>>>>>>> -- "JSON-structured encryption" > >>>>> > >>>>>>>> -- "public keys as JSON-structured objects" > >>>>> > >>>>>>>> (The fourth is just a list of algorithms, which should be JSON as > >>>>> > >>>>>>>> well, just as RFC 3370 is ASN.1.) > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> In light of these requirements, JWE and JWS are clearly not > suitable > >>>>> > >>>>>>>> candidates to fulfill the working group's milestones. (At least in > >>>>> > >>>>>>>> their current form.) So ISTM that we need to step back and > >>>>> > >>>>>>>> re-evaluate alternatives for the three above milestones, > especially > >>>>> > >>>>>>>> the first two. (JWK is not as far off.) > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> As JSON-based mechanisms, though, the "JSON serialization" > drafts > >>>> are pretty half-hearted. Because JWS and JWE include the > cryptographic > >>>> parameters within the integrity protection, they have to have the > headers > >>>> included as base64-encoded strings. That obviously adds a lot of > >>> complexity > >>>> to encoding and decoding -- for example, you have to keep the > encoded > >>>> header around even after you've decoded it! -- and just plain more > octets. > >>>> The support for multiple recipients and multiple signatures is both > >>> unweildy > >>>> (matching up parallel indices for headers and signatures) and inefficient > >>>> (multiple integrity check values in encrypted objects). > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom > that > >>>> went into CMS, while making the syntax pure JSON and as simple as > >>> possible. > >>>> Multiple signatures and multiple recipients are supported with absolute > >>>> minimum overhead. So I think it's worth consideration by the working > >>> group. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Part 2: JSON !=> canonicalization > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> I would like to dispel the myth that a JSON-based format requires > >>>>> > >>>>>>>> canonicalization. In JWE/JWS, the JSON header requires > >>>>> > >>>>>>>> "canonicalization" (via base64url encoding) because it's included > >>>>> > >>>>>>>> within the integrity protection. I'm not aware of any reason for > >>>>> > >>>>>>>> including the cryptographic parameters in the integrity check, > >>>>> > >>>>>>>> instead of only integrity-protecting the content itself. Indeed, if > >>>>> > >>>>>>>> there were an attack based on non-integrity-protected > cryptographic > >>>>> > >>>>>>>> parameters, it would be a pretty big deal, since neither CMS nor > IKE > >>>>> > >>>>>>>> nor provides this protection. (TLS does provide a signature over > >>>>> > >>>>>>>> the algorithms, but only as a way to bind the public key to the > >>>>> > >>>>>>>> session.) > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Indeed CMS doesn't require canonicalization at all, except for > >>>> attributes that are included in the protected content (signedAttrs / > >>>> authenticatedAttrs), which need to be DER-encoded. In JSMS, we > don't > >>>> allow those parameters, so there is no need for canonicalization at all. > >>> All the > >>>> "canonicalization" that's needed is to base64url-encode the protected > >>>> content. In that regard, JSMS is even simpler than JWE/JWS. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Part 3: Compactness and URL-safeness are still OK, as derivatives > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> I have absolutely no objection to defining a compact, URL-safe > >>> format. > >>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the example > >>> from > >>>> Section 3.1 of the JWS spec, we get the following JSMS object: > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> { > >>>>> > >>>>>>>> "v":1, > >>>>> > >>>>>>>> "t":"au", > >>>>> > >>>>>>>> "a":"hs256", > >>>>> > >>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", > >>>>> > >>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", > >>>>> > >>>>>>>> "ki":"rSIilRk8Ego" > >>>>> > >>>>>>>> } > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> If we remove the decorative spaces and base64url-encode, we > only > >>>> use > >>>>> > >>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step > >>>>> > >>>>>>>> further and define an explicit compact format for > AuthenticatedData, > >>>>> > >>>>>>>> we can emulate JWS by moving the content and MAC fields > outside > >>>> and > >>>>> > >>>>>>>> dot-combining. That avoids double-base64url-encoding, and only > >>>>> > >>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put the > code > >>>>> > >>>>>>>> to generate these in the Github project linked earlier.) > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> So it's fine to have a compact, URL-safe format for an objective, > >>> but it > >>>> makes *much* more sense to derive that from a full-size, usable, JSON > >>>> format than the other way around. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Responses to specific points inline below. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before doing > >>> so, I'll > >>>> say that I'm writing in the spirit of trying to increase mutual > >>> understanding > >>>> and consensus, rather than taking the point of view that the status quo > is > >>> the > >>>> only reasonable outcome. > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> -- Not being JSON > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> This was by design, so that the results are URL-safe. This is > >>> required, > >>>> for instance, for them to be used as OAuth Bearer Tokens. At the > request > >>> of > >>>> the working group, closely related pure-JSON drafts were also > published. > >>>> See: > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-json- > seri > >>>>> > >>>>>>>>> alization-01 and > >>>>> > >>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption- > json-ser > >>>>> > >>>>>>>>> ialization-01 > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Use them if you prefer if they better suit your use cases. They > >>> could > >>>> be adopted as working group documents, if there's interest. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> See above. These are super-clunky, and the need to be the main > >>>> focus of the WG, not an afterthought. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>>> -- Not supporting multiple recipients > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> The JSON serialization drafts above do, again, in response to use > >>>> cases presented by the working group. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> See above. Because of the unnecessary inclusion of the header in > >>> the > >>>> integrity check, this is far less efficient than it should be. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>>> -- Lacking clear distinctions between signing and MAC > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Functionally, these are very similar operations, at least from an > >>>> implementation perspective, so it's not clear that making a clear > >>> distinction > >>>> would help either developers or adoption in any practical way. They > >>> achieve > >>>> overlapping, but admittedly sometimes different goals. I believe that > >>>> developers can be trusted to use the algorithms that achieve their > >>>> applications' goals without making a hard distinction between the two. > >>> But > >>>> I'd be interested in hearing your thoughts on why you believe a > >>> brighter-line > >>>> distinction might be useful or necessary. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> It's important if you want to do MACs with anything other than > pre- > >>>> shared keys. If you want to do anything more advanced, you need to > have > >>>> wrapped keys, in which case an object with a MAC starts to look a lot > more > >>>> like a JWE than a JWS. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>>> -- Lacking clear processing instructions for different key > >>>>> > >>>>>>>>> establishment modalities > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> This seems like an area where the existing drafts could be > refined > >>> to > >>>> add descriptions for additional establishment modalities, possibly > based > >>>> upon your ideas and descriptions, should the working group decide to > do > >>> so. > >>>> What additional modalities do you have use cases for that you believe > are > >>>> not achievable or straightforward with the existing drafts? The existing > >>>> modalities supported are largely those that existing developers had > told > >>> us > >>>> they needed and draw both from the precursor draft-jones-json-web- > * > >>>> documents and draft-rescorla-jsms. > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Bear in mind that the balance that the current drafts try to strike > >>> is > >>>> keeping the Mandatory to Implement (MTI) feature footprint small > enough > >>>> that developers, including Web developers, are likely to adopt the > specs, > >>>> while still providing enough functionality to make them generally > useful. > >>> As > >>>> in any balance, it's often possible to shift things a bit and still > >>> maintain the > >>>> balance, but I'd like people to keep the ubiquitous adoption goal > >>> front-and- > >>>> center when proposing additional functionality. > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Ubiquitous deployment and usefulness trump theoretical > >>>>> > >>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to > understand > >>>>> > >>>>>>>>> that!) > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> I agree that we need to find a reasonable MTI. The current JSMS > >>> draft > >>>> doesn't really specify which parts are MTI, beyond basic things like > >>> base64url > >>>> encoding and ignoring unknown fields. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> My main concern is that JWS and JWE don't really tell me which > >>> fields > >>>> need to be present for which use case. If I'm putting a MAC on a JWS > vs. > >>> a > >>>> signature, do I need "jwk" or "jku" fields to be populated? Whereas in > >>> JSMS, > >>>> I think these things are much clearer due to the separation of the use > >>> cases > >>>> (Signed/Authenticated/Encrypted) and the isolation of signatures and > >>>> wrapped keys into sub-objects. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>>> -- Lack of clear typing of objects > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Most JSON documents aren't clearly typed; instead, developers > and > >>>> implementations understand from context what the meaning of each > field is. > >>>> XML is clearly typed, but developers are voting with their feet by > moving > >>> to > >>>> JSON. > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> What practical advantages resulting from overlaying a typing > >>>> infrastructure on JSON do you believe are worth the potential costs of > >>> doing > >>>> so? BTW, I'm not opposed to having a JSON schema description of the > JOSE > >>>> JSON data structures like JSMS did in http://tools.ietf.org/html/draft- > >>>> rescorla-jsms-00#appendix-A, but I'll remark that this an informative > >>> tool, not > >>>> a normative one. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> I actualy don't have a hugely urgent requirement here either. It's > >>>> something that others in the WG had requested, which is trivial to add > in > >>>> JSMS, but not in JWE/JWS -- again because of the unnecessary integrity > >>>> protection of the header. > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>>> -- Lack of versioning for future extensibility > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> An optional version field could be added if the working group > >>>>> > >>>>>>>>> desires, however the last time the working group discussed it, > they > >>>>> > >>>>>>>>> decided not to do so. Rather, specs like this effectively become > >>>>> > >>>>>>>>> "versioned" when revised in a way that new fields are added. If > >>>>> > >>>>>>>>> you understand the new fields, you support that new version. > (Note > >>>>> > >>>>>>>>> that this is independent of whether there is a version number > >>>>> > >>>>>>>>> field, which according to some participants in the previous > >>>>> > >>>>>>>>> discussion, they regarded as therefore being redundant > >>>>> > >>>>>>>>> information.) > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> I'm not religious about not having a version number field, but > >>> often > >>>> "less is more". > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Indeed, I'm not religious either. It just seems like a general good > >>> idea > >>>> to state this directly as opposed to having parsers divine it based on > >>> which > >>>> fields are present. To quote RFC 5652: > >>>>> > >>>>>>>> " > >>>>> > >>>>>>>> Each of the major data structures includes a version number as > the > >>>>> > >>>>>>>> first item in the data structure. The version numbers are intended > >>>>> > >>>>>>>> to avoid ASN.1 decode errors. Some implementations do not > check > >>>> the > >>>>> > >>>>>>>> version number prior to attempting a decode, and if a decode > error > >>>>> > >>>>>>>> occurs, then the version number is checked as part of the error > >>>>> > >>>>>>>> handling routine. This is a reasonable approach; it places error > >>>>> > >>>>>>>> processing outside of the fast path. This approach is also > >>>>> > >>>>>>>> forgiving when an incorrect version number is used by the > sender. > >>>>> > >>>>>>>> " > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> Best, > >>>>> > >>>>>>>> --Richard > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Best wishes, > >>>>> > >>>>>>>>> -- Mike > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> -----Original Message----- > >>>>> > >>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] > >>>>> > >>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM > >>>>> > >>>>>>>>> To: Mike Jones > >>>>> > >>>>>>>>> Cc: jose@ietf.org > >>>>> > >>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for > >>>>> > >>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. > IMO, > >>> the > >>>> current JW* specs are deficient in several ways, e.g.: > >>>>> > >>>>>>>>> -- Not being JSON > >>>>> > >>>>>>>>> -- Not supporting multiple recipients > >>>>> > >>>>>>>>> -- Lacking clear distinctions between signing and MAC > >>>>> > >>>>>>>>> -- Lacking clear processing instructions for different key > >>>>> > >>>>>>>>> establishment modalities > >>>>> > >>>>>>>>> -- Lack of clear typing of objects > >>>>> > >>>>>>>>> -- Lack of versioning for future extensibility > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Looking at the current specs, it didn't seem to me that it would > be > >>>> simple to adapt them to address these deficiencies. So I just did a > >>> re-write. > >>>> If you think they can be addressed within the current framework, > please > >>>> explain. I just found it simpler to start from whole cloth. > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> Cheers, > >>>>> > >>>>>>>>> --Richard > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>>> Hi Richard, > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> If you're puzzled by specific design decisions in the JOSE > >>> documents, > >>>> I encourage you to ask about them on the list. The documents have > >>>> significant history going back to mid-2010 when convergence > discussions > >>>> started among people with four different JSON signing & encryption > >>>> proposals. JWT and the current JOSE specs and implementations are > the > >>>> result. I realize that not all the JOSE participants were part of those > >>>> discussions from the beginning (although many were) and so teasing > out the > >>>> rationale for specific decisions might help people better understand > the > >>>> choices made, and hopefully thereby increase consensus behind the > >>>> eventual working group choices. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> If the list that you're puzzled by is the bulleted list below, > >>> maybe we > >>>> can start a discussion on that basis. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> Best wishes, > >>>>> > >>>>>>>>>> -- Mike > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> -----Original Message----- > >>>>> > >>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] > On > >>>>> > >>>>>>>>>> Behalf Of Richard L. Barnes > >>>>> > >>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM > >>>>> > >>>>>>>>>> To: jose@ietf.org > >>>>> > >>>>>>>>>> Subject: [jose] Fwd: New Version Notification for > >>>>> > >>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> Dear JOSE WG, > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> Like Mr. Manger, once I finally got around to doing a thorough > >>>> review of the JW* specs, I was kind of puzzled by some of the design > >>>> decisions. So I also went through and wrote an alternative format, this > >>> time > >>>> taking a more of a cue from CMS. A link to the document is below. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> Summary of differences: > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the header > >>>>> > >>>>>>>>>> parameters are represented in JSON. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> o JSMS allows for full algorithm agility in key agreement, while > >>> JWE > >>>>> > >>>>>>>>>> only allows ECDH-ES. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and > >>>>> > >>>>>>>>>> AuthenticatedData objects via the inclusion of multiple > >>>> WrappedKey > >>>>> > >>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- > >>>>> > >>>>>>>>>> encryption of the entire object for each recipient. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> o The signature and MAC functions of the JWS object are > separated > >>>>> > >>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> o JSMS parameters are not integrity-protected, as they are in > JWE > >>>>> > >>>>>>>>>> and JWS. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, but > >>> could > >>>>> > >>>>>>>>>> be added without significant change. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header > >>>>> > >>>>>>>>>> parameters, in order to facilitate extensibility. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> I've also thrown together an initial JavaScript implementation > >>> (based > >>>> on NodeJS for some python crypto glue), which is on github: > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> Comments are very welcome. > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> Thanks, > >>>>> > >>>>>>>>>> --Richard > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> Begin forwarded message: > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>>> From: internet-drafts@ietf.org > >>>>> > >>>>>>>>>>> Subject: New Version Notification for > >>>>> > >>>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>> > >>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT > >>>>> > >>>>>>>>>>> To: rbarnes@bbn.com > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has been > >>>>> > >>>>>>>>>>> successfully submitted by Richard Barnes and posted to the > IETF > >>>>> > >>>>>>>>>>> repository. > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> Filename: draft-barnes-jose-jsms > >>>>> > >>>>>>>>>>> Revision: 00 > >>>>> > >>>>>>>>>>> Title: JavaScript Message Security Format > >>>>> > >>>>>>>>>>> Creation date: 2012-06-15 > >>>>> > >>>>>>>>>>> WG ID: Individual Submission > >>>>> > >>>>>>>>>>> Number of pages: 25 > >>>>> > >>>>>>>>>>> URL: > >>> http://www.ietf.org/internet-drafts/draft-barnes-jose- > >>>> jsms-00.txt > >>>>> > >>>>>>>>>>> Status: > >>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > >>>>> > >>>>>>>>>>> Htmlized: > >>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> Abstract: > >>>>> > >>>>>>>>>>> Many applications require the ability to send cryptographically > >>>>> > >>>>>>>>>>> secured messages. While the IETF has defined a number of > >>>> formats > >>>>> > >>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings > which > >>>>> > >>>>>>>>>>> are not easy to use in modern applications. This document > >>>>> > >>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a > new > >>>>> > >>>>>>>>>>> cryptographic message format which is based on JavaScript > Object > >>>>> > >>>>>>>>>>> Notation (JSON) and thus is easy for many applications to > >>> generate > >>>> and parse. > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> > >>>>> > >>>>>>>>>>> The IETF Secretariat > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> _______________________________________________ > >>>>> > >>>>>>>>>> jose mailing list > >>>>> > >>>>>>>>>> jose@ietf.org > >>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> > >>>>> > >>>>>>>>>> _______________________________________________ > >>>>> > >>>>>>>>>> jose mailing list > >>>>> > >>>>>>>>>> jose@ietf.org > >>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> > >>>>> > >>>>>>>>> _______________________________________________ > >>>>> > >>>>>>>>> jose mailing list > >>>>> > >>>>>>>>> jose@ietf.org > >>>>> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>> > >>>>>>>> > >>>>> > >>>>>>>> _______________________________________________ > >>>>> > >>>>>>>> jose mailing list > >>>>> > >>>>>>>> jose@ietf.org > >>>>> > >>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>> > >>>>>>> > >>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> jose mailing list > >>>>> jose@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Nat Sakimura (=nat) > >>>>> Chairman, OpenID Foundation > >>>>> http://nat.sakimura.org/ > >>>>> @_nat_en > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > > From tonynad@microsoft.com Tue Jun 26 15:39: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 8B12021F84DD for ; Tue, 26 Jun 2012 15:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1x+g88Z2k1O for ; Tue, 26 Jun 2012 15:39:04 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33611E80A6 for ; Tue, 26 Jun 2012 15:39:01 -0700 (PDT) Received: from mail226-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 22:37:19 +0000 Received: from mail226-tx2 (localhost [127.0.0.1]) by mail226-tx2-R.bigfish.com (Postfix) with ESMTP id E41628020F for ; Tue, 26 Jun 2012 22:37:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zz98dI9371I936eI168aJ148cI542M1432I1418I41c5N4015Izz1202h1082kzz1033IL8275eh8275bh8275dh5eeeKf73b6ila1495iz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail226-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail226-tx2 (localhost.localdomain [127.0.0.1]) by mail226-tx2 (MessageSwitch) id 134075023688369_17695; Tue, 26 Jun 2012 22:37:16 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.248]) by mail226-tx2.bigfish.com (Postfix) with ESMTP id 1357510006D for ; Tue, 26 Jun 2012 22:37:16 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 22:37:14 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 26 Jun 2012 22:38:55 +0000 Received: from mail56-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 22:34:41 +0000 Received: from mail56-am1 (localhost [127.0.0.1]) by mail56-am1-R.bigfish.com (Postfix) with ESMTP id 5C5C64E00EF for ; Tue, 26 Jun 2012 22:34:41 +0000 (UTC) Received: from mail56-am1 (localhost.localdomain [127.0.0.1]) by mail56-am1 (MessageSwitch) id 1340750077908902_3184; Tue, 26 Jun 2012 22:34:37 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.234]) by mail56-am1.bigfish.com (Postfix) with ESMTP id D1A504C004C; Tue, 26 Jun 2012 22:34:37 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 22:34:38 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0152.000; Tue, 26 Jun 2012 22:36:10 +0000 From: Anthony Nadalin To: "Richard L. Barnes" Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: AQHNU+OgL7XbE3wc70St/ao3U/Jq9JcNH/Ag Date: Tue, 26 Jun 2012 22:36:09 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> <89204661-AB9C-4E99-B4A2-1A08B5AF2971@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%BBN.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$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: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: John Bradley , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:39:07 -0000 Key wrap can be done with AES in ECB mode. I did not say there are librarie= s that support ECB and no other modes, just answered the question you asked= . -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Tuesday, June 26, 2012 2:35 PM To: Anthony Nadalin Cc: John Bradley; Jim Schaad; jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt Not to rat-hole on ECB, but: I would be interested to hear about libraries that support ECB, but not oth= er modes. Key wrap does not use ECB. It uses AES as a primitive, mixing in entropy o= ver multiple rounds. On Jun 26, 2012, at 5:23 PM, Anthony Nadalin wrote: > Because it's in most libraries and it works well for key wrap and it's in= a lot of products. That's fine to discuss (and did not say it was not disc= ussed) but I don't recall reaching a consensus on that point yet. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Richard L. Barnes > Sent: Tuesday, June 26, 2012 2:20 PM > To: John Bradley > Cc: Anthony Nadalin; Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for=20 > draft-barnes-jose-jsms-00.txt >=20 > Why would you ever want to use ECB mode? If you want something fast and = parallelizable, CTR mode is a lot better. >=20 > We had discussed Dave McGrew's draft as a mechanism for specifying genera= l AEAD algorithms: > >=20 > --Richard >=20 >=20 >=20 >=20 > On Jun 26, 2012, at 5:07 PM, John Bradley wrote: >=20 >> You should suggest adding that as a supported algorithm. >>=20 >> We wanted to keep the core set down to a reasonable number to encourage = interoparability. >>=20 >> AES-ECB + HMAC can be a option if the WG wants it. >>=20 >> John B. >> On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote: >>=20 >>> AES-ECB is also a popular alternative >>>=20 >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Tuesday, June 26, 2012 1:59 PM >>> To: Anthony Nadalin >>> Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for=20 >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> Yes that is why we added the composite HMAC + AES-CBC. We can debate = if that is an algorithm or mandatory integrity with non AEAD algorithms, bu= t the effect of integrity protecting the header remains in both cases. >>>=20 >>> John B. >>>=20 >>> On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >>>=20 >>>> Not sure there was a WG decision and what that would mean if there was= , as there are many libraries out there that don't support the encryption w= ith integrity algorithms, so need to support alternative means of things li= ke key wrap that could have an integrity check. >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>> Behalf Of John Bradley >>>> Sent: Tuesday, June 26, 2012 12:30 PM >>>> To: Richard L. Barnes >>>> Cc: Jim Schaad; jose@ietf.org >>>> Subject: Re: [jose] New Version Notification for=20 >>>> draft-barnes-jose-jsms-00.txt >>>>=20 >>>> There was a WG decision to not allow encryption without integrity. J= im and others call that sender verification. >>>>=20 >>>> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>>>=20 >>>> The JWE/JWS specs don't control the body. That is intended to be arb= itrary content. >>>>=20 >>>> We do have s JWT spec that covers the body for security tokens. The = idea was to separate that from signing and encryption so that signing and e= ncryption can be used for other objects. >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>>>=20 >>>>>> Now that we are mandating JWE sender verification people will be usi= ng JWE with symmetric keys or key agreement. >>>>>> In those cases one can easily argue that the header should be protec= ted as much as in HMAC. >>>>>=20 >>>>> Can you clarify the scope of "we are mandating"? >>>>>=20 >>>>>=20 >>>>>> There may well be signing_time or other elements that would go into = the header as well for JWE. >>>>>=20 >>>>> Why do these need to go into the header rather than the body? >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> Richard, >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Richard L. Barnes >>>>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>>>> To: Nat Sakimura >>>>>>>> Cc: Mike Jones; jose@ietf.org >>>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>>> draft-barnes-jose-jsms- 00.txt >>>>>>>>=20 >>>>>>>> Hi Nat, >>>>>>>>=20 >>>>>>>> I'm not sure what X.509 fiasco you're referring to. There was=20 >>>>>>>> a recent >>>>>>> MD5 >>>>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact,=20 >>>>>>>> there have >>>>>>> been >>>>>>>> recommendations for preventing this attack in X.509 since 2005 [2]= . =20 >>>>>>>> As >>>>>>> was >>>>>>>> noted on the SAAG list, the real news here is that Microsoft=20 >>>>>>>> wasn't >>>>>>> following >>>>>>>> any of those recommendations. >>>>>>>>=20 >>>>>>>> JWS would have had the same problem as X.509. The attack did=20 >>>>>>>> not modify the cryptographic parameters (anything that would=20 >>>>>>>> have gone in the header), it would not have been thwarted by=20 >>>>>>>> the integrity protection we're worrying about. >>>>>>>>=20 >>>>>>>> Actually, the header signing that JWS does makes it even nicer=20 >>>>>>>> for the >>>>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20 >>>>>>>> header >>>>>>> value >>>>>>>> is entirely static for a given signer, it's easy to use as a fixed= prefix. >>>>>>> If JWS just >>>>>>>> signed the content, then the application could include a=20 >>>>>>>> something random up front to prevent such prefix-based attacks. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I don't believe that this is a true statement. If you had a=20 >>>>>>> prefix or just signed what was given to you (i.e. no prefix), it=20 >>>>>>> would make no difference in terms of the attack for Flame. =20 >>>>>>> Flame could always use a fixed prefix of its own design rather=20 >>>>>>> than using the fixed header that is generated by having JWS sign th= e header information. >>>>>>>=20 >>>>>>>> It's tempting to say that we should just add randomness to the=20 >>>>>>>> JOSE >>>>>>> format. >>>>>>>> But the real lesson of the Flame/MD5 attacks is operational: =20 >>>>>>>> If you're >>>>>>> signing >>>>>>>> something that somebody else gave you, make sure that you're=20 >>>>>>>> not signing exactly what they gave you. Follow the=20 >>>>>>>> recommendations of RFC 4270. In other contexts, there's no=20 >>>>>>>> need of similar random elements; it just adds complexity. >>>>>>>=20 >>>>>>> This is definitely a true statement in all events and is=20 >>>>>>> something that should be added to the Security Considerations secti= on. >>>>>>>=20 >>>>>>> That being said, I think that there are valid reasons for=20 >>>>>>> wanting to protect the header information by some authentication pr= ocessing. >>>>>>> PKIX certificates protect the signature algorithm information=20 >>>>>>> (by copying the data into the to be signed block) and CMS has=20 >>>>>>> long allowed for information to be included in the signed=20 >>>>>>> attributes area that identifies the algorithms used, the=20 >>>>>>> certificates used and so forth. There are also other things=20 >>>>>>> that we might find to be convenient to be placed in the header=20 >>>>>>> information that is current not there (a signing time and=20 >>>>>>> embedded content type comes to mind) that would be a product either= of specific types of signatures or becomes a common attribute to be placed= there. >>>>>>>=20 >>>>>>> In terms of encryption operations, I remember in the past that I=20 >>>>>>> have had either corrupted encrypted streams or corrupted IVs and=20 >>>>>>> had a successful decryption that later generated other problems=20 >>>>>>> when trying to parse. This is less of an issue with AEAD=20 >>>>>>> algorithms as they have a much stricter rule on when the stream dec= rypts correctly. >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>>=20 >>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> [1] >>>>>>>> >>>>>>>> [2] >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>>>=20 >>>>>>>>> Especially after the X.509 fiasco, I strongly believe that=20 >>>>>>>>> having >>>>>>> integrity >>>>>>>> check over the metadata is a good thing. It is such a little=20 >>>>>>>> effort that >>>>>>> gives us >>>>>>>> much more protection down the road. In this sense, I fully=20 >>>>>>>> agree with Ben here. We should have integrity protection over the = header. >>>>>>>>>=20 >>>>>>>>> Nat >>>>>>>>>=20 >>>>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>>>> wrote: >>>>>>>>> Two years ago when the developer community needing a=20 >>>>>>>>> JSON-friendly >>>>>>>> token format was designing the JSON Web Token (JWT), we=20 >>>>>>>> explicitly asked security experts whether the header parameters=20 >>>>>>>> should be integrity protected or not. Among them, Ben Laurie=20 >>>>>>>> was one of the voices saying >>>>>>> that >>>>>>>> securing them was the right thing to do. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> He argued that if the parameters can be protected in a=20 >>>>>>>>> practical manner, >>>>>>>> then they should. Doing so provides an additional hurdle that=20 >>>>>>>> attackers would have to surmount. For example, if they can try=20 >>>>>>>> to substitute a >>>>>>> weaker >>>>>>>> authentication scheme, then they must figure out how to make it=20 >>>>>>>> authenticate correctly despite some plaintext they can't=20 >>>>>>>> control >>>>>>>> - the >>>>>>> header >>>>>>>> parameters. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Ben also took the position that paring security protocols down=20 >>>>>>>>> to the >>>>>>> least >>>>>>>> you can get away with, given attacks you can think of, is not a=20 >>>>>>>> good >>>>>>> design >>>>>>>> principle. If there is not a strong argument against including=20 >>>>>>>> a feature >>>>>>> that >>>>>>>> may make it harder for attackers, then that feature should be incl= uded. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I agree with him. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The decision to provide integrity protection for the headers=20 >>>>>>>>> is >>>>>>> documented >>>>>>>> in the session notes at http://self-issued.info/?p=3D361, which sa= id: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>>>=20 >>>>>>>>> Given that the envelope is extensible and therefore may=20 >>>>>>>>> contain >>>>>>> security- >>>>>>>> sensitive information, we reached a consensus (with input from=20 >>>>>>>> Ben Laurie via IM) that the combination envelope.payload must be s= igned. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I believe that logic is as sound today as it was then. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For all these reasons, I therefore personally stand by the=20 >>>>>>>>> community's >>>>>>>> decision to provide integrity protection for the headers. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best=20 >>>>>>>>> wishes, >>>>>>>>>=20 >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of >>>>>>>> John Bradley >>>>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>>>> To: Richard L.Barnes >>>>>>>>> Cc: jose@ietf.org >>>>>>>>> Subject: Re: [jose] New Version Notification for >>>>>>>>> draft-barnes-jose-jsms- >>>>>>>> 00.txt >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> While for PKCS 1.5 the hash algorithm is baked into the=20 >>>>>>>>> padding and not >>>>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>>>=20 >>>>>>>>> There are possible hash truncation attacks by shortening=20 >>>>>>>>> SHA256 to >>>>>>> SHA224 >>>>>>>> as an example (I know we preclude truncated hashes at the moment). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The bad feeling I get around this is that if there is a=20 >>>>>>>>> scenario where >>>>>>> the >>>>>>>> attacker controls the plaintext to be signed and there is no=20 >>>>>>>> signer >>>>>>> controlled >>>>>>>> text contributed there are potential bad things that could=20 >>>>>>>> happen down the road. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This bit us with x509 certs not that long ago (yes with MD5 >>>>>>>>> admittedly) >>>>>>>> where the attacker could use a certificate extension to include=20 >>>>>>>> extra data >>>>>>> and >>>>>>>> cause a pre collided hash to be generated. >>>>>>>>>=20 >>>>>>>>> Having part of the signed data outside the control of an=20 >>>>>>>>> attacker is a >>>>>>> good >>>>>>>> thing. (having a nonce or message ID in the envelope is=20 >>>>>>>> possible though >>>>>>> not >>>>>>>> yet required in JWS.) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am still of the opinion that putting the base64 encoded=20 >>>>>>>>> envelope >>>>>>> inside >>>>>>>> the hash calculation is a valid way to allow additional attributes= . >>>>>>>>>=20 >>>>>>>>> Another structure to hold the attributes adds more complexity,=20 >>>>>>>>> as would >>>>>>>> saying that they need to be inside the signed object. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I think part of this is that as one of the openID Connect=20 >>>>>>>>> authors I look >>>>>>> at this >>>>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>>>=20 >>>>>>>>> For that simple processing with one signature is a high=20 >>>>>>>>> priority for >>>>>>> adoption. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> From a general signing/encrypting of documents point of view=20 >>>>>>>>> you >>>>>>>> legitimately have different priorities. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I know it is hard to prove a negative but It is also going to=20 >>>>>>>>> be >>>>>>> difficult for me >>>>>>>> to go back to security people at google Facebook and other=20 >>>>>>>> places and explain how not integrity protecting the header=20 >>>>>>>> could be better than integrity protecting it. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It seems that I would be reduced to arguing that this is no=20 >>>>>>>>> worse than >>>>>>> CMS >>>>>>>> and that hasn't been proven insecure yet. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Allowing a possible attacker to control the hash output, and=20 >>>>>>>>> not >>>>>>> integrity >>>>>>>> protecting the additional data, seems like something I am bound=20 >>>>>>>> to regret >>>>>>> in >>>>>>>> the future. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Hey John, >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Interesting points, but I don't think they actually apply here. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to downgrade attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The attack that RFC 5752 is concerned with is when an=20 >>>>>>>>>> attacker strips >>>>>>>> signatures from a signed message, so that the only ones left=20 >>>>>>>> are ones he >>>>>>> can >>>>>>>> tamper with. So the integrity protection here is "horizontal";=20 >>>>>>>> it goes >>>>>>> across >>>>>>>> signatures. The integrity protection in JWS/JWE is "vertical"=20 >>>>>>>> -- it only >>>>>>> protects >>>>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "brown bag" attacks: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> The root of this attack is ambiguity about what content is >>>>>>>>>> *signed* >>>>>>>>>=20 >>>>>>>>>> vs. what content is *used*. If an application doesn't verify=20 >>>>>>>>>> that >>>>>>>>>=20 >>>>>>>>>> it's actually using the stuff that's signed, then it can be=20 >>>>>>>>>> tricked >>>>>>>>>=20 >>>>>>>>>> into accepting something unsigned. (Cf. >>>>>>>>>=20 >>>>>>>>>> ) >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> However, I don't think any of the current proposals have that pr= oblem. >>>>>>>> In JWE/JWS, the signed content is right there between the dots,=20 >>>>>>>> and in >>>>>>> JSMS, >>>>>>>> it's in the "content" element. The current JSMS draft does=20 >>>>>>>> allow detached signatures, but with a "voids your warranty" sticke= r on it. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> In any case, these attacks have nothing to do with whether=20 >>>>>>>>>> the >>>>>>>> cryptographic parameters are integrity-protected with the content.= =20 >>>>>>>> The example attacks in the IBM still work regardless -- the=20 >>>>>>>> whole point of the attack is that the cryptographic processing=20 >>>>>>>> is the same, only the >>>>>>> (non-crypto) >>>>>>>> matching of content is flawed. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "arbitrary attributes": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> We can have that here, too, but you need canonicalization. =20 >>>>>>>>>> And >>>>>>> base64- >>>>>>>> encoding is not not canonicalization -- it just waves its hands=20 >>>>>>>> over the question of equivalence. In my opinion, we should=20 >>>>>>>> keep the cryptographic object simple by disallowing attributes,=20 >>>>>>>> and push the attributes you would sign inside of the thing=20 >>>>>>>> being signed. If people really do want >>>>>>> attributes, it >>>>>>>> doesn't seem to me like JSON canonicalization is very hard. I=20 >>>>>>>> can do it >>>>>>> in 19 >>>>>>>> lines of python: >>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard too "meta-data in the body": >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> It seems to me like if we're trying to define a general=20 >>>>>>>>>> format for >>>>>>> applying >>>>>>>> security protections, then we ought to keep out things that=20 >>>>>>>> aren't >>>>>>> strictly >>>>>>>> security relevant. Those things can go in application-specific=20 >>>>>>>> content >>>>>>> types >>>>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> With regard to "defense in depth" and selling this to=20 >>>>>>>>>> government >>>>>>>> agencies: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> CMS, via S/MIME, is in broad use across multiple federal=20 >>>>>>>>>> agencies and >>>>>>>> large enterprises. JSMS is essentially a profile of CMS (see=20 >>>>>>>> Section 7), >>>>>>> and >>>>>>>> has the same security properties. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Originally we only integrity protected the header for signing. = =20 >>>>>>>>>>> We >>>>>>> added >>>>>>>> the integrity protection to encryption as part of AEAD, as=20 >>>>>>>> encryption can >>>>>>> also >>>>>>>> be used for sender verification. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I understand the argument that it makes things simpler if we=20 >>>>>>>>>>> don't >>>>>>>> integrity protect the header information. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> However xmldsig, provides integrity over those elements to=20 >>>>>>>>>>> prevent >>>>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> CMS may not typically provide that integrity protection but=20 >>>>>>>>>>> I think >>>>>>> Jim >>>>>>>> Schaad and Sean Terner created RFC5752 to address downgrade attack= s. >>>>>>>>>=20 >>>>>>>>>>> Given they are on this list they can speak to their view on=20 >>>>>>>>>>> integrity >>>>>>> over >>>>>>>> the crypto parameters. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I also recall when working on InfoCards there was a Monte=20 >>>>>>>>>>> Carlo/Brown >>>>>>>> Bag attack that needs to be considered if we move to something=20 >>>>>>>> more like a detached signature. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> The other design consideration is that we wanted to be able=20 >>>>>>>>>>> to sign >>>>>>>> arbitrary byte strings not just JSON. You could sign XML if you = wanted. >>>>>>>>>=20 >>>>>>>>>>> That prevented us from including meta-data in the body as we=20 >>>>>>>>>>> didn't >>>>>>>> want to touch it. That left us with the header to include additi= onal >>>>>>> elements >>>>>>>> in. >>>>>>>>>=20 >>>>>>>>>>> Not integrity protecting those elements as well would be a prob= lem. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>>>> arbitrary >>>>>>>> attributes not unlike the current JOSE spec. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Especially for something that will be used with JWT security=20 >>>>>>>>>>> tokens I >>>>>>> will >>>>>>>> have a hard time making the argument to NIST and others that=20 >>>>>>>> need to approve this format that not integrity protecting the=20 >>>>>>>> header parameters is appropriate defence in depth, for=20 >>>>>>>> something that might be replacing signed SAML assertions in some a= pplications. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> I do understand how not integrity protecting the header will=20 >>>>>>>>>>> make >>>>>>> some >>>>>>>> things easier, however I can't agree that the benefit outweighs=20 >>>>>>>> the disadvantages. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> Regards >>>>>>>>>=20 >>>>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Hey Mike, >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Thanks for having some back-and-forth with me on this. I=20 >>>>>>>>>>>> think this >>>>>>> is a >>>>>>>> good discussion to have right now. I would like to discuss=20 >>>>>>>> some >>>>>>> high-level >>>>>>>> points, and then I'll respond inline to your precise points. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 >>>>>>>>>>>> define >>>>>>> JSON- >>>>>>>> based formats for integrity and confidentiality protections. =20 >>>>>>>> JWE and JWS don't fit that requirement, so we should=20 >>>>>>>> re-consider their adoption and >>>>>>> call >>>>>>>> for new candidates. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Major points: >>>>>>>>>=20 >>>>>>>>>>>> 1. JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>>>=20 >>>>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 1: JOSE is JSON >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> The JOSE WG charter calls out four deliverables, three of=20 >>>>>>>>>>>> which are >>>>>>>> explicitly required to be JSON: >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>>>=20 >>>>>>>>>>>> -- "JSON-structured encryption" >>>>>>>>>=20 >>>>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>>>=20 >>>>>>>>>>>> (The fourth is just a list of algorithms, which should be=20 >>>>>>>>>>>> JSON as >>>>>>>>>=20 >>>>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20 >>>>>>>>>>>> suitable >>>>>>>>>=20 >>>>>>>>>>>> candidates to fulfill the working group's milestones. (At=20 >>>>>>>>>>>> least in >>>>>>>>>=20 >>>>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>>>=20 >>>>>>>>>>>> re-evaluate alternatives for the three above milestones,=20 >>>>>>>>>>>> especially >>>>>>>>>=20 >>>>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization"=20 >>>>>>>>>>>> drafts >>>>>>>> are pretty half-hearted. Because JWS and JWE include the=20 >>>>>>>> cryptographic parameters within the integrity protection, they=20 >>>>>>>> have to have the headers included as base64-encoded strings. >>>>>>>> That obviously adds a lot of >>>>>>> complexity >>>>>>>> to encoding and decoding -- for example, you have to keep the=20 >>>>>>>> encoded header around even after you've decoded it! -- and just pl= ain more octets. >>>>>>>> The support for multiple recipients and multiple signatures is=20 >>>>>>>> both >>>>>>> unweildy >>>>>>>> (matching up parallel indices for headers and signatures) and=20 >>>>>>>> inefficient (multiple integrity check values in encrypted objects)= . >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic=20 >>>>>>>>>>>> wisdom that >>>>>>>> went into CMS, while making the syntax pure JSON and as simple=20 >>>>>>>> as >>>>>>> possible. >>>>>>>> Multiple signatures and multiple recipients are supported with=20 >>>>>>>> absolute minimum overhead. So I think it's worth consideration=20 >>>>>>>> by the working >>>>>>> group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I would like to dispel the myth that a JSON-based format=20 >>>>>>>>>>>> requires >>>>>>>>>=20 >>>>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>>>=20 >>>>>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 >>>>>>>>>>>> included >>>>>>>>>=20 >>>>>>>>>>>> within the integrity protection. I'm not aware of any=20 >>>>>>>>>>>> reason for >>>>>>>>>=20 >>>>>>>>>>>> including the cryptographic parameters in the integrity=20 >>>>>>>>>>>> check, >>>>>>>>>=20 >>>>>>>>>>>> instead of only integrity-protecting the content itself. =20 >>>>>>>>>>>> Indeed, if >>>>>>>>>=20 >>>>>>>>>>>> there were an attack based on non-integrity-protected=20 >>>>>>>>>>>> cryptographic >>>>>>>>>=20 >>>>>>>>>>>> parameters, it would be a pretty big deal, since neither=20 >>>>>>>>>>>> CMS nor IKE >>>>>>>>>=20 >>>>>>>>>>>> nor provides this protection. (TLS does provide a=20 >>>>>>>>>>>> signature over >>>>>>>>>=20 >>>>>>>>>>>> the algorithms, but only as a way to bind the public key to=20 >>>>>>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> session.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except=20 >>>>>>>>>>>> for >>>>>>>> attributes that are included in the protected content=20 >>>>>>>> (signedAttrs / authenticatedAttrs), which need to be=20 >>>>>>>> DER-encoded. In JSMS, we don't allow those parameters, so there i= s no need for canonicalization at all. >>>>>>> All the >>>>>>>> "canonicalization" that's needed is to base64url-encode the=20 >>>>>>>> protected content. In that regard, JSMS is even simpler than JWE/= JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 >>>>>>>>>>>> derivatives >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I have absolutely no objection to defining a compact,=20 >>>>>>>>>>>> URL-safe >>>>>>> format. >>>>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20 >>>>>>>> example >>>>>>> from >>>>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> { >>>>>>>>>=20 >>>>>>>>>>>> "v":1, >>>>>>>>>=20 >>>>>>>>>>>> "t":"au", >>>>>>>>>=20 >>>>>>>>>>>> "a":"hs256", >>>>>>>>>=20 >>>>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>>>=20 >>>>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>>>=20 >>>>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>>>=20 >>>>>>>>>>>> } >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20 >>>>>>>>>>>> only >>>>>>>> use >>>>>>>>>=20 >>>>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a=20 >>>>>>>>>>>> step >>>>>>>>>=20 >>>>>>>>>>>> further and define an explicit compact format for=20 >>>>>>>>>>>> AuthenticatedData, >>>>>>>>>=20 >>>>>>>>>>>> we can emulate JWS by moving the content and MAC fields=20 >>>>>>>>>>>> outside >>>>>>>> and >>>>>>>>>=20 >>>>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and=20 >>>>>>>>>>>> only >>>>>>>>>=20 >>>>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put=20 >>>>>>>>>>>> the code >>>>>>>>>=20 >>>>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 >>>>>>>>>>>> objective, >>>>>>> but it >>>>>>>> makes *much* more sense to derive that from a full-size,=20 >>>>>>>> usable, JSON format than the other way around. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Responses to specific points inline below. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. =20 >>>>>>>>>>>>> Before doing >>>>>>> so, I'll >>>>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>>>> understanding >>>>>>>> and consensus, rather than taking the point of view that the=20 >>>>>>>> status quo is >>>>>>> the >>>>>>>> only reasonable outcome. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This was by design, so that the results are URL-safe. =20 >>>>>>>>>>>>> This is >>>>>>> required, >>>>>>>> for instance, for them to be used as OAuth Bearer Tokens. At=20 >>>>>>>> the request >>>>>>> of >>>>>>>> the working group, closely related pure-JSON drafts were also publ= ished. >>>>>>>> See: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature- >>>>>>>>>>>>> j >>>>>>>>>>>>> son >>>>>>>>>>>>> -seri >>>>>>>>>=20 >>>>>>>>>>>>> alization-01 and >>>>>>>>>=20 >>>>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption >>>>>>>>>>>>> - >>>>>>>>>>>>> jso >>>>>>>>>>>>> n-ser >>>>>>>>>=20 >>>>>>>>>>>>> ialization-01 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Use them if you prefer if they better suit your use cases. =20 >>>>>>>>>>>>> They >>>>>>> could >>>>>>>> be adopted as working group documents, if there's interest. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. These are super-clunky, and the need to be the=20 >>>>>>>>>>>> main >>>>>>>> focus of the WG, not an afterthought. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> The JSON serialization drafts above do, again, in response=20 >>>>>>>>>>>>> to use >>>>>>>> cases presented by the working group. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> See above. Because of the unnecessary inclusion of the=20 >>>>>>>>>>>> header in >>>>>>> the >>>>>>>> integrity check, this is far less efficient than it should be. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Functionally, these are very similar operations, at least=20 >>>>>>>>>>>>> from an >>>>>>>> implementation perspective, so it's not clear that making a=20 >>>>>>>> clear >>>>>>> distinction >>>>>>>> would help either developers or adoption in any practical way. =20 >>>>>>>> They >>>>>>> achieve >>>>>>>> overlapping, but admittedly sometimes different goals. I=20 >>>>>>>> believe that developers can be trusted to use the algorithms=20 >>>>>>>> that achieve their applications' goals without making a hard disti= nction between the two. >>>>>>> But >>>>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>>>> brighter-line >>>>>>>> distinction might be useful or necessary. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> It's important if you want to do MACs with anything other=20 >>>>>>>>>>>> than >>>>>>>>>>>> pre- >>>>>>>> shared keys. If you want to do anything more advanced, you=20 >>>>>>>> need to have wrapped keys, in which case an object with a MAC=20 >>>>>>>> starts to look a lot more like a JWE than a JWS. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> This seems like an area where the existing drafts could be=20 >>>>>>>>>>>>> refined >>>>>>> to >>>>>>>> add descriptions for additional establishment modalities,=20 >>>>>>>> possibly based upon your ideas and descriptions, should the=20 >>>>>>>> working group decide to do >>>>>>> so. >>>>>>>> What additional modalities do you have use cases for that you=20 >>>>>>>> believe are not achievable or straightforward with the existing=20 >>>>>>>> drafts? The existing modalities supported are largely those=20 >>>>>>>> that existing developers had told >>>>>>> us >>>>>>>> they needed and draw both from the precursor >>>>>>>> draft-jones-json-web-* documents and draft-rescorla-jsms. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Bear in mind that the balance that the current drafts try=20 >>>>>>>>>>>>> to strike >>>>>>> is >>>>>>>> keeping the Mandatory to Implement (MTI) feature footprint=20 >>>>>>>> small enough that developers, including Web developers, are=20 >>>>>>>> likely to adopt the specs, while still providing enough functional= ity to make them generally useful. >>>>>>> As >>>>>>>> in any balance, it's often possible to shift things a bit and=20 >>>>>>>> still >>>>>>> maintain the >>>>>>>> balance, but I'd like people to keep the ubiquitous adoption=20 >>>>>>>> goal >>>>>>> front-and- >>>>>>>> center when proposing additional functionality. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>>>=20 >>>>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to=20 >>>>>>>>>>>>> understand >>>>>>>>>=20 >>>>>>>>>>>>> that!) >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I agree that we need to find a reasonable MTI. The current=20 >>>>>>>>>>>> JSMS >>>>>>> draft >>>>>>>> doesn't really specify which parts are MTI, beyond basic things=20 >>>>>>>> like >>>>>>> base64url >>>>>>>> encoding and ignoring unknown fields. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> My main concern is that JWS and JWE don't really tell me=20 >>>>>>>>>>>> which >>>>>>> fields >>>>>>>> need to be present for which use case. If I'm putting a MAC on a = JWS vs. >>>>>>> a >>>>>>>> signature, do I need "jwk" or "jku" fields to be populated? =20 >>>>>>>> Whereas in >>>>>>> JSMS, >>>>>>>> I think these things are much clearer due to the separation of=20 >>>>>>>> the use >>>>>>> cases >>>>>>>> (Signed/Authenticated/Encrypted) and the isolation of=20 >>>>>>>> signatures and wrapped keys into sub-objects. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Most JSON documents aren't clearly typed; instead,=20 >>>>>>>>>>>>> developers and >>>>>>>> implementations understand from context what the meaning of each f= ield is. >>>>>>>> XML is clearly typed, but developers are voting with their feet=20 >>>>>>>> by moving >>>>>>> to >>>>>>>> JSON. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> What practical advantages resulting from overlaying a=20 >>>>>>>>>>>>> typing >>>>>>>> infrastructure on JSON do you believe are worth the potential=20 >>>>>>>> costs of >>>>>>> doing >>>>>>>> so? BTW, I'm not opposed to having a JSON schema description=20 >>>>>>>> of the JOSE JSON data structures like JSMS did in >>>>>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A,=20 >>>>>>>> but I'll remark that this an informative >>>>>>> tool, not >>>>>>>> a normative one. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> I actualy don't have a hugely urgent requirement here either. = =20 >>>>>>>>>>>> It's >>>>>>>> something that others in the WG had requested, which is trivial=20 >>>>>>>> to add in JSMS, but not in JWE/JWS -- again because of the=20 >>>>>>>> unnecessary integrity protection of the header. >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> An optional version field could be added if the working=20 >>>>>>>>>>>>> group >>>>>>>>>=20 >>>>>>>>>>>>> desires, however the last time the working group discussed=20 >>>>>>>>>>>>> it, they >>>>>>>>>=20 >>>>>>>>>>>>> decided not to do so. Rather, specs like this effectively=20 >>>>>>>>>>>>> become >>>>>>>>>=20 >>>>>>>>>>>>> "versioned" when revised in a way that new fields are added. = =20 >>>>>>>>>>>>> If >>>>>>>>>=20 >>>>>>>>>>>>> you understand the new fields, you support that new version. = =20 >>>>>>>>>>>>> (Note >>>>>>>>>=20 >>>>>>>>>>>>> that this is independent of whether there is a version=20 >>>>>>>>>>>>> number >>>>>>>>>=20 >>>>>>>>>>>>> field, which according to some participants in the=20 >>>>>>>>>>>>> previous >>>>>>>>>=20 >>>>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>>>=20 >>>>>>>>>>>>> information.) >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> I'm not religious about not having a version number field,=20 >>>>>>>>>>>>> but >>>>>>> often >>>>>>>> "less is more". >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Indeed, I'm not religious either. It just seems like a=20 >>>>>>>>>>>> general good >>>>>>> idea >>>>>>>> to state this directly as opposed to having parsers divine it=20 >>>>>>>> based on >>>>>>> which >>>>>>>> fields are present. To quote RFC 5652: >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>> Each of the major data structures includes a version number=20 >>>>>>>>>>>> as the >>>>>>>>>=20 >>>>>>>>>>>> first item in the data structure. The version numbers are=20 >>>>>>>>>>>> intended >>>>>>>>>=20 >>>>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20 >>>>>>>>>>>> check >>>>>>>> the >>>>>>>>>=20 >>>>>>>>>>>> version number prior to attempting a decode, and if a=20 >>>>>>>>>>>> decode error >>>>>>>>>=20 >>>>>>>>>>>> occurs, then the version number is checked as part of the=20 >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> handling routine. This is a reasonable approach; it places=20 >>>>>>>>>>>> error >>>>>>>>>=20 >>>>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>>>=20 >>>>>>>>>>>> forgiving when an incorrect version number is used by the sen= der. >>>>>>>>>=20 >>>>>>>>>>>> " >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> Best, >>>>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>>>=20 >>>>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>>>=20 >>>>>>>>>>>>> To: Mike Jones >>>>>>>>>=20 >>>>>>>>>>>>> Cc: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. =20 >>>>>>>>>>>>> IMO, >>>>>>> the >>>>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>>>=20 >>>>>>>>>>>>> -- Not being JSON >>>>>>>>>=20 >>>>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>>>=20 >>>>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>>>=20 >>>>>>>>>>>>> establishment modalities >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>>>=20 >>>>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20 >>>>>>>>>>>>> would be >>>>>>>> simple to adapt them to address these deficiencies. So I just=20 >>>>>>>> did a >>>>>>> re-write. >>>>>>>> If you think they can be addressed within the current=20 >>>>>>>> framework, please explain. I just found it simpler to start from = whole cloth. >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Hi Richard, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If you're puzzled by specific design decisions in the=20 >>>>>>>>>>>>>> JOSE >>>>>>> documents, >>>>>>>> I encourage you to ask about them on the list. The documents=20 >>>>>>>> have significant history going back to mid-2010 when=20 >>>>>>>> convergence discussions started among people with four=20 >>>>>>>> different JSON signing & encryption proposals. JWT and the=20 >>>>>>>> current JOSE specs and implementations are the result. I=20 >>>>>>>> realize that not all the JOSE participants were part of those=20 >>>>>>>> discussions from the beginning (although many were) and so=20 >>>>>>>> teasing out the rationale for specific decisions might help=20 >>>>>>>> people better understand the choices made, and hopefully thereby i= ncrease consensus behind the eventual working group choices. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 >>>>>>>>>>>>>> below, >>>>>>> maybe we >>>>>>>> can start a discussion on that basis. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Best wishes, >>>>>>>>>=20 >>>>>>>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>=20 >>>>>>>>>>>>>> From: jose-bounces@ietf.org=20 >>>>>>>>>>>>>> [mailto:jose-bounces@ietf.org] On >>>>>>>>>=20 >>>>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>>>=20 >>>>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>>>=20 >>>>>>>>>>>>>> To: jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Dear JOSE WG, >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 >>>>>>>>>>>>>> thorough >>>>>>>> review of the JW* specs, I was kind of puzzled by some of the=20 >>>>>>>> design decisions. So I also went through and wrote an=20 >>>>>>>> alternative format, this >>>>>>> time >>>>>>>> taking a more of a cue from CMS. A link to the document is below. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Summary of differences: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the=20 >>>>>>>>>>>>>> header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters are represented in JSON. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS allows for full algorithm agility in key=20 >>>>>>>>>>>>>> agreement, while >>>>>>> JWE >>>>>>>>>=20 >>>>>>>>>>>>>> only allows ECDH-ES. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData=20 >>>>>>>>>>>>>> and >>>>>>>>>=20 >>>>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>>>> WrappedKey >>>>>>>>>=20 >>>>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires >>>>>>>>>>>>>> re- >>>>>>>>>=20 >>>>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The signature and MAC functions of the JWS object are=20 >>>>>>>>>>>>>> separated >>>>>>>>>=20 >>>>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they=20 >>>>>>>>>>>>>> are in JWE >>>>>>>>>=20 >>>>>>>>>>>>>> and JWS. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in=20 >>>>>>>>>>>>>> JSMS, but >>>>>>> could >>>>>>>>>=20 >>>>>>>>>>>>>> be added without significant change. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown=20 >>>>>>>>>>>>>> header >>>>>>>>>=20 >>>>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> I've also thrown together an initial JavaScript=20 >>>>>>>>>>>>>> implementation >>>>>>> (based >>>>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>>>=20 >>>>>>>>>>>>>> >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Comments are very welcome. >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>>>>>>> --Richard >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>>>=20 >>>>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>>>=20 >>>>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has=20 >>>>>>>>>>>>>>> been >>>>>>>>>=20 >>>>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to=20 >>>>>>>>>>>>>>> the IETF >>>>>>>>>=20 >>>>>>>>>>>>>>> repository. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Revision: 00 >>>>>>>>>=20 >>>>>>>>>>>>>>> Title: JavaScript Message Security Form= at >>>>>>>>>=20 >>>>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>>>=20 >>>>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>>>=20 >>>>>>>>>>>>>>> Number of pages: 25 >>>>>>>>>=20 >>>>>>>>>>>>>>> URL: >>>>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>>>> jsms-00.txt >>>>>>>>>=20 >>>>>>>>>>>>>>> Status: >>>>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>>>=20 >>>>>>>>>>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> Abstract: >>>>>>>>>=20 >>>>>>>>>>>>>>> Many applications require the ability to send=20 >>>>>>>>>>>>>>> cryptographically >>>>>>>>>=20 >>>>>>>>>>>>>>> secured messages. While the IETF has defined a number=20 >>>>>>>>>>>>>>> of >>>>>>>> formats >>>>>>>>>=20 >>>>>>>>>>>>>>> for such messages (e.g. CMS) those formats use=20 >>>>>>>>>>>>>>> encodings which >>>>>>>>>=20 >>>>>>>>>>>>>>> are not easy to use in modern applications. This=20 >>>>>>>>>>>>>>> document >>>>>>>>>=20 >>>>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS),=20 >>>>>>>>>>>>>>> a new >>>>>>>>>=20 >>>>>>>>>>>>>>> cryptographic message format which is based on=20 >>>>>>>>>>>>>>> JavaScript Object >>>>>>>>>=20 >>>>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications=20 >>>>>>>>>>>>>>> to >>>>>>> generate >>>>>>>> and parse. >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=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 ietf@augustcellars.com Tue Jun 26 15:41: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 96AEC21F8523 for ; Tue, 26 Jun 2012 15:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mssZdvAodMeP for ; Tue, 26 Jun 2012 15:40:58 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5A821F84FB for ; Tue, 26 Jun 2012 15:40:58 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0A3C72CA27; Tue, 26 Jun 2012 15:40:57 -0700 (PDT) From: "Jim Schaad" To: "'Anthony Nadalin'" , "'John Bradley'" References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> In-Reply-To: Date: Tue, 26 Jun 2012 15:39:42 -0700 Message-ID: <00e901cd53ec$944e5040$bceaf0c0$@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: AQD47QI5KEiTUDL2CmgL/J0d6D+eqAIQ+tNPAngGm3sBp8FZzQCi2RReAsTTS8kCA+Ah3wIRhjecAmDdmpcCBEKiu5glZ05w Content-Language: en-us Cc: "'Richard L. Barnes'" , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:41:01 -0000 Under what circumstances would people use ECB? > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Tuesday, June 26, 2012 2:03 PM > To: John Bradley > Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org > Subject: RE: [jose] New Version Notification for draft-barnes-jose-jsms- > 00.txt > > AES-ECB is also a popular alternative > > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Tuesday, June 26, 2012 1:59 PM > To: Anthony Nadalin > Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms- > 00.txt > > Yes that is why we added the composite HMAC + AES-CBC. We can debate if > that is an algorithm or mandatory integrity with non AEAD algorithms, but the > effect of integrity protecting the header remains in both cases. > > John B. > > On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: > > > Not sure there was a WG decision and what that would mean if there was, > as there are many libraries out there that don't support the encryption with > integrity algorithms, so need to support alternative means of things like key > wrap that could have an integrity check. > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of John Bradley > > Sent: Tuesday, June 26, 2012 12:30 PM > > To: Richard L. Barnes > > Cc: Jim Schaad; jose@ietf.org > > Subject: Re: [jose] New Version Notification for > > draft-barnes-jose-jsms-00.txt > > > > There was a WG decision to not allow encryption without integrity. Jim > and others call that sender verification. > > > > Or on simple terms no AES-CBC without a mandatory MAC integrity. > > > > The JWE/JWS specs don't control the body. That is intended to be arbitrary > content. > > > > We do have s JWT spec that covers the body for security tokens. The idea > was to separate that from signing and encryption so that signing and > encryption can be used for other objects. > > > > John B. > > > > On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: > > > >>> Now that we are mandating JWE sender verification people will be using > JWE with symmetric keys or key agreement. > >>> In those cases one can easily argue that the header should be protected > as much as in HMAC. > >> > >> Can you clarify the scope of "we are mandating"? > >> > >> > >>> There may well be signing_time or other elements that would go into > the header as well for JWE. > >> > >> Why do these need to go into the header rather than the body? > >> > >> --Richard > >> > >> > >> > >> > >>> Regards > >>> John B. > >>> > >>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: > >>> > >>>> > >>>> > >>>> Richard, > >>>> > >>>>> -----Original Message----- > >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > >>>>> Behalf Of Richard L. Barnes > >>>>> Sent: Monday, June 25, 2012 2:35 PM > >>>>> To: Nat Sakimura > >>>>> Cc: Mike Jones; jose@ietf.org > >>>>> Subject: Re: [jose] New Version Notification for > >>>>> draft-barnes-jose-jsms- 00.txt > >>>>> > >>>>> Hi Nat, > >>>>> > >>>>> I'm not sure what X.509 fiasco you're referring to. There was a > >>>>> recent > >>>> MD5 > >>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, > >>>>> there have > >>>> been > >>>>> recommendations for preventing this attack in X.509 since 2005 [2]. > >>>>> As > >>>> was > >>>>> noted on the SAAG list, the real news here is that Microsoft > >>>>> wasn't > >>>> following > >>>>> any of those recommendations. > >>>>> > >>>>> JWS would have had the same problem as X.509. The attack did not > >>>>> modify the cryptographic parameters (anything that would have gone > >>>>> in the header), it would not have been thwarted by the integrity > >>>>> protection we're worrying about. > >>>>> > >>>>> Actually, the header signing that JWS does makes it even nicer for > >>>>> the > >>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS > >>>>> header > >>>> value > >>>>> is entirely static for a given signer, it's easy to use as a fixed prefix. > >>>> If JWS just > >>>>> signed the content, then the application could include a something > >>>>> random up front to prevent such prefix-based attacks. > >>>>> > >>>> > >>>> I don't believe that this is a true statement. If you had a prefix > >>>> or just signed what was given to you (i.e. no prefix), it would > >>>> make no difference in terms of the attack for Flame. Flame could > >>>> always use a fixed prefix of its own design rather than using the > >>>> fixed header that is generated by having JWS sign the header > information. > >>>> > >>>>> It's tempting to say that we should just add randomness to the > >>>>> JOSE > >>>> format. > >>>>> But the real lesson of the Flame/MD5 attacks is operational: If > >>>>> you're > >>>> signing > >>>>> something that somebody else gave you, make sure that you're not > >>>>> signing exactly what they gave you. Follow the recommendations of > >>>>> RFC 4270. In other contexts, there's no need of similar random > >>>>> elements; it just adds complexity. > >>>> > >>>> This is definitely a true statement in all events and is something > >>>> that should be added to the Security Considerations section. > >>>> > >>>> That being said, I think that there are valid reasons for wanting > >>>> to protect the header information by some authentication processing. > >>>> PKIX certificates protect the signature algorithm information (by > >>>> copying the data into the to be signed block) and CMS has long > >>>> allowed for information to be included in the signed attributes > >>>> area that identifies the algorithms used, the certificates used and > >>>> so forth. There are also other things that we might find to be > >>>> convenient to be placed in the header information that is current > >>>> not there (a signing time and embedded content type comes to mind) > >>>> that would be a product either of specific types of signatures or > becomes a common attribute to be placed there. > >>>> > >>>> In terms of encryption operations, I remember in the past that I > >>>> have had either corrupted encrypted streams or corrupted IVs and > >>>> had a successful decryption that later generated other problems > >>>> when trying to parse. This is less of an issue with AEAD > >>>> algorithms as they have a much stricter rule on when the stream > decrypts correctly. > >>>> > >>>> Jim > >>>> > >>>>> > >>>>> --Richard > >>>>> > >>>>> > >>>>> > >>>>> [1] > >>>>> [2] > >>>>> > >>>>> > >>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: > >>>>> > >>>>>> Especially after the X.509 fiasco, I strongly believe that having > >>>> integrity > >>>>> check over the metadata is a good thing. It is such a little > >>>>> effort that > >>>> gives us > >>>>> much more protection down the road. In this sense, I fully agree > >>>>> with Ben here. We should have integrity protection over the header. > >>>>>> > >>>>>> Nat > >>>>>> > >>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones > >>>>> wrote: > >>>>>> Two years ago when the developer community needing a > >>>>>> JSON-friendly > >>>>> token format was designing the JSON Web Token (JWT), we explicitly > >>>>> asked security experts whether the header parameters should be > >>>>> integrity protected or not. Among them, Ben Laurie was one of the > >>>>> voices saying > >>>> that > >>>>> securing them was the right thing to do. > >>>>>> > >>>>>> > >>>>>> > >>>>>> He argued that if the parameters can be protected in a practical > >>>>>> manner, > >>>>> then they should. Doing so provides an additional hurdle that > >>>>> attackers would have to surmount. For example, if they can try to > >>>>> substitute a > >>>> weaker > >>>>> authentication scheme, then they must figure out how to make it > >>>>> authenticate correctly despite some plaintext they can't control - > >>>>> the > >>>> header > >>>>> parameters. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Ben also took the position that paring security protocols down to > >>>>>> the > >>>> least > >>>>> you can get away with, given attacks you can think of, is not a > >>>>> good > >>>> design > >>>>> principle. If there is not a strong argument against including a > >>>>> feature > >>>> that > >>>>> may make it harder for attackers, then that feature should be > included. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree with him. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The decision to provide integrity protection for the headers is > >>>> documented > >>>>> in the session notes at http://self-issued.info/?p=361, which said: > >>>>>> > >>>>>> > >>>>>> > >>>>>> . What to sign (envelope.payload or just payload)? > >>>>>> > >>>>>> Given that the envelope is extensible and therefore may contain > >>>> security- > >>>>> sensitive information, we reached a consensus (with input from Ben > >>>>> Laurie via IM) that the combination envelope.payload must be signed. > >>>>>> > >>>>>> > >>>>>> I believe that logic is as sound today as it was then. > >>>>>> > >>>>>> > >>>>>> > >>>>>> For all these reasons, I therefore personally stand by the > >>>>>> community's > >>>>> decision to provide integrity protection for the headers. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Best > >>>>>> wishes, > >>>>>> > >>>>>> -- Mike > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > >>>>>> Behalf Of > >>>>> John Bradley > >>>>>> Sent: Wednesday, June 20, 2012 3:57 PM > >>>>>> To: Richard L.Barnes > >>>>>> Cc: jose@ietf.org > >>>>>> Subject: Re: [jose] New Version Notification for > >>>>>> draft-barnes-jose-jsms- > >>>>> 00.txt > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi Richard, > >>>>>> > >>>>>> > >>>>>> > >>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding > >>>>>> and not > >>>>> susceptible to modification with ECDH or RSA-PSS it is not. > >>>>>> > >>>>>> There are possible hash truncation attacks by shortening SHA256 > >>>>>> to > >>>> SHA224 > >>>>> as an example (I know we preclude truncated hashes at the > moment). > >>>>>> > >>>>>> > >>>>>> > >>>>>> The bad feeling I get around this is that if there is a scenario > >>>>>> where > >>>> the > >>>>> attacker controls the plaintext to be signed and there is no > >>>>> signer > >>>> controlled > >>>>> text contributed there are potential bad things that could happen > >>>>> down the road. > >>>>>> > >>>>>> > >>>>>> > >>>>>> This bit us with x509 certs not that long ago (yes with MD5 > >>>>>> admittedly) > >>>>> where the attacker could use a certificate extension to include > >>>>> extra data > >>>> and > >>>>> cause a pre collided hash to be generated. > >>>>>> > >>>>>> Having part of the signed data outside the control of an attacker > >>>>>> is a > >>>> good > >>>>> thing. (having a nonce or message ID in the envelope is possible > >>>>> though > >>>> not > >>>>> yet required in JWS.) > >>>>>> > >>>>>> > >>>>>> > >>>>>> I am still of the opinion that putting the base64 encoded > >>>>>> envelope > >>>> inside > >>>>> the hash calculation is a valid way to allow additional attributes. > >>>>>> > >>>>>> Another structure to hold the attributes adds more complexity, > >>>>>> as would > >>>>> saying that they need to be inside the signed object. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I think part of this is that as one of the openID Connect authors > >>>>>> I look > >>>> at this > >>>>> as a necessary security token format, for OAuth and Connect. > >>>>>> > >>>>>> For that simple processing with one signature is a high priority > >>>>>> for > >>>> adoption. > >>>>>> > >>>>>> > >>>>>> > >>>>>> From a general signing/encrypting of documents point of view you > >>>>> legitimately have different priorities. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I know it is hard to prove a negative but It is also going to be > >>>> difficult for me > >>>>> to go back to security people at google Facebook and other places > >>>>> and explain how not integrity protecting the header could be > >>>>> better than integrity protecting it. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It seems that I would be reduced to arguing that this is no worse > >>>>>> than > >>>> CMS > >>>>> and that hasn't been proven insecure yet. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Allowing a possible attacker to control the hash output, and not > >>>> integrity > >>>>> protecting the additional data, seems like something I am bound to > >>>>> regret > >>>> in > >>>>> the future. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> John B. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hey John, > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> Interesting points, but I don't think they actually apply here. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to downgrade attacks: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> The attack that RFC 5752 is concerned with is when an attacker > >>>>>>> strips > >>>>> signatures from a signed message, so that the only ones left are > >>>>> ones he > >>>> can > >>>>> tamper with. So the integrity protection here is "horizontal"; it > >>>>> goes > >>>> across > >>>>> signatures. The integrity protection in JWS/JWE is "vertical" -- > >>>>> it only > >>>> protects > >>>>> one signer's parameters -- so it is, so to speak, orthogonal. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to "brown bag" attacks: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> The root of this attack is ambiguity about what content is > >>>>>>> *signed* > >>>>>> > >>>>>>> vs. what content is *used*. If an application doesn't verify > >>>>>>> that > >>>>>> > >>>>>>> it's actually using the stuff that's signed, then it can be > >>>>>>> tricked > >>>>>> > >>>>>>> into accepting something unsigned. (Cf. > >>>>>> > >>>>>>> ) > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> However, I don't think any of the current proposals have that > problem. > >>>>> In JWE/JWS, the signed content is right there between the dots, > >>>>> and in > >>>> JSMS, > >>>>> it's in the "content" element. The current JSMS draft does allow > >>>>> detached signatures, but with a "voids your warranty" sticker on it. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> In any case, these attacks have nothing to do with whether the > >>>>> cryptographic parameters are integrity-protected with the content. > >>>>> The example attacks in the IBM still work regardless -- the whole > >>>>> point of the attack is that the cryptographic processing is the > >>>>> same, only the > >>>> (non-crypto) > >>>>> matching of content is flawed. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to "arbitrary attributes": > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> We can have that here, too, but you need canonicalization. And > >>>> base64- > >>>>> encoding is not not canonicalization -- it just waves its hands > >>>>> over the question of equivalence. In my opinion, we should keep > >>>>> the cryptographic object simple by disallowing attributes, and > >>>>> push the attributes you would sign inside of the thing being > >>>>> signed. If people really do want > >>>> attributes, it > >>>>> doesn't seem to me like JSON canonicalization is very hard. I can > >>>>> do it > >>>> in 19 > >>>>> lines of python: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard too "meta-data in the body": > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> It seems to me like if we're trying to define a general format > >>>>>>> for > >>>> applying > >>>>> security protections, then we ought to keep out things that aren't > >>>> strictly > >>>>> security relevant. Those things can go in application-specific > >>>>> content > >>>> types > >>>>> (e.g., SAML) without polluting the general purpose header. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to "defense in depth" and selling this to government > >>>>> agencies: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> CMS, via S/MIME, is in broad use across multiple federal > >>>>>>> agencies and > >>>>> large enterprises. JSMS is essentially a profile of CMS (see > >>>>> Section 7), > >>>> and > >>>>> has the same security properties. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> Cheers, > >>>>>> > >>>>>>> --Richard > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>>> Hi Richard, > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> Originally we only integrity protected the header for signing. > >>>>>>>> We > >>>> added > >>>>> the integrity protection to encryption as part of AEAD, as > >>>>> encryption can > >>>> also > >>>>> be used for sender verification. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I understand the argument that it makes things simpler if we > >>>>>>>> don't > >>>>> integrity protect the header information. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> However xmldsig, provides integrity over those elements to > >>>>>>>> prevent > >>>>> possible downgrade attacks by manipulating the algorithms. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> CMS may not typically provide that integrity protection but I > >>>>>>>> think > >>>> Jim > >>>>> Schaad and Sean Terner created RFC5752 to address downgrade > attacks. > >>>>>> > >>>>>>>> Given they are on this list they can speak to their view on > >>>>>>>> integrity > >>>> over > >>>>> the crypto parameters. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I also recall when working on InfoCards there was a Monte > >>>>>>>> Carlo/Brown > >>>>> Bag attack that needs to be considered if we move to something > >>>>> more like a detached signature. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> The other design consideration is that we wanted to be able to > >>>>>>>> sign > >>>>> arbitrary byte strings not just JSON. You could sign XML if you > wanted. > >>>>>> > >>>>>>>> That prevented us from including meta-data in the body as we > >>>>>>>> didn't > >>>>> want to touch it. That left us with the header to include additional > >>>> elements > >>>>> in. > >>>>>> > >>>>>>>> Not integrity protecting those elements as well would be a > problem. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I am not a CMS expert but I believe it allows for signing of > >>>> arbitrary > >>>>> attributes not unlike the current JOSE spec. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> Especially for something that will be used with JWT security > >>>>>>>> tokens I > >>>> will > >>>>> have a hard time making the argument to NIST and others that need > >>>>> to approve this format that not integrity protecting the header > >>>>> parameters is appropriate defence in depth, for something that > >>>>> might be replacing signed SAML assertions in some applications. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I do understand how not integrity protecting the header will > >>>>>>>> make > >>>> some > >>>>> things easier, however I can't agree that the benefit outweighs > >>>>> the disadvantages. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> Regards > >>>>>> > >>>>>>>> John B. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>>> Hey Mike, > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Thanks for having some back-and-forth with me on this. I > >>>>>>>>> think this > >>>> is a > >>>>> good discussion to have right now. I would like to discuss some > >>>> high-level > >>>>> points, and then I'll respond inline to your precise points. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to > >>>>>>>>> define > >>>> JSON- > >>>>> based formats for integrity and confidentiality protections. JWE > >>>>> and JWS don't fit that requirement, so we should re-consider their > >>>>> adoption and > >>>> call > >>>>> for new candidates. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Major points: > >>>>>> > >>>>>>>>> 1. JOSE is JSON > >>>>>> > >>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and > >>>>>> > >>>>>>>>> URL-safeness are still OK, as derivatives > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Part 1: JOSE is JSON > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> The JOSE WG charter calls out four deliverables, three of > >>>>>>>>> which are > >>>>> explicitly required to be JSON: > >>>>>> > >>>>>>>>> -- "JSON-structured integrity protection" > >>>>>> > >>>>>>>>> -- "JSON-structured encryption" > >>>>>> > >>>>>>>>> -- "public keys as JSON-structured objects" > >>>>>> > >>>>>>>>> (The fourth is just a list of algorithms, which should be JSON > >>>>>>>>> as > >>>>>> > >>>>>>>>> well, just as RFC 3370 is ASN.1.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> In light of these requirements, JWE and JWS are clearly not > >>>>>>>>> suitable > >>>>>> > >>>>>>>>> candidates to fulfill the working group's milestones. (At > >>>>>>>>> least in > >>>>>> > >>>>>>>>> their current form.) So ISTM that we need to step back and > >>>>>> > >>>>>>>>> re-evaluate alternatives for the three above milestones, > >>>>>>>>> especially > >>>>>> > >>>>>>>>> the first two. (JWK is not as far off.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization" > >>>>>>>>> drafts > >>>>> are pretty half-hearted. Because JWS and JWE include the > >>>>> cryptographic parameters within the integrity protection, they > >>>>> have to have the headers included as base64-encoded strings. That > >>>>> obviously adds a lot of > >>>> complexity > >>>>> to encoding and decoding -- for example, you have to keep the > >>>>> encoded header around even after you've decoded it! -- and just > plain more octets. > >>>>> The support for multiple recipients and multiple signatures is > >>>>> both > >>>> unweildy > >>>>> (matching up parallel indices for headers and signatures) and > >>>>> inefficient (multiple integrity check values in encrypted objects). > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom > >>>>>>>>> that > >>>>> went into CMS, while making the syntax pure JSON and as simple as > >>>> possible. > >>>>> Multiple signatures and multiple recipients are supported with > >>>>> absolute minimum overhead. So I think it's worth consideration by > >>>>> the working > >>>> group. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Part 2: JSON !=> canonicalization > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I would like to dispel the myth that a JSON-based format > >>>>>>>>> requires > >>>>>> > >>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires > >>>>>> > >>>>>>>>> "canonicalization" (via base64url encoding) because it's > >>>>>>>>> included > >>>>>> > >>>>>>>>> within the integrity protection. I'm not aware of any reason > >>>>>>>>> for > >>>>>> > >>>>>>>>> including the cryptographic parameters in the integrity check, > >>>>>> > >>>>>>>>> instead of only integrity-protecting the content itself. > >>>>>>>>> Indeed, if > >>>>>> > >>>>>>>>> there were an attack based on non-integrity-protected > >>>>>>>>> cryptographic > >>>>>> > >>>>>>>>> parameters, it would be a pretty big deal, since neither CMS > >>>>>>>>> nor IKE > >>>>>> > >>>>>>>>> nor provides this protection. (TLS does provide a signature > >>>>>>>>> over > >>>>>> > >>>>>>>>> the algorithms, but only as a way to bind the public key to > >>>>>>>>> the > >>>>>> > >>>>>>>>> session.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Indeed CMS doesn't require canonicalization at all, except for > >>>>> attributes that are included in the protected content (signedAttrs > >>>>> / authenticatedAttrs), which need to be DER-encoded. In JSMS, we > >>>>> don't allow those parameters, so there is no need for canonicalization > at all. > >>>> All the > >>>>> "canonicalization" that's needed is to base64url-encode the > >>>>> protected content. In that regard, JSMS is even simpler than > JWE/JWS. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as > >>>>>>>>> derivatives > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I have absolutely no objection to defining a compact, URL-safe > >>>> format. > >>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the > >>>>> example > >>>> from > >>>>> Section 3.1 of the JWS spec, we get the following JSMS object: > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> { > >>>>>> > >>>>>>>>> "v":1, > >>>>>> > >>>>>>>>> "t":"au", > >>>>>> > >>>>>>>>> "a":"hs256", > >>>>>> > >>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", > >>>>>> > >>>>>>>>> "mac":"pwM0gJNMLFxn8G1- > juQFLrJtMEOR8_FeKIH3wIM_OAo", > >>>>>> > >>>>>>>>> "ki":"rSIilRk8Ego" > >>>>>> > >>>>>>>>> } > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> If we remove the decorative spaces and base64url-encode, we > >>>>>>>>> only > >>>>> use > >>>>>> > >>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a step > >>>>>> > >>>>>>>>> further and define an explicit compact format for > >>>>>>>>> AuthenticatedData, > >>>>>> > >>>>>>>>> we can emulate JWS by moving the content and MAC fields > >>>>>>>>> outside > >>>>> and > >>>>>> > >>>>>>>>> dot-combining. That avoids double-base64url-encoding, and > >>>>>>>>> only > >>>>>> > >>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put > >>>>>>>>> the code > >>>>>> > >>>>>>>>> to generate these in the Github project linked earlier.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> So it's fine to have a compact, URL-safe format for an > >>>>>>>>> objective, > >>>> but it > >>>>> makes *much* more sense to derive that from a full-size, usable, > >>>>> JSON format than the other way around. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Responses to specific points inline below. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before > >>>>>>>>>> doing > >>>> so, I'll > >>>>> say that I'm writing in the spirit of trying to increase mutual > >>>> understanding > >>>>> and consensus, rather than taking the point of view that the > >>>>> status quo is > >>>> the > >>>>> only reasonable outcome. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> -- Not being JSON > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> This was by design, so that the results are URL-safe. This > >>>>>>>>>> is > >>>> required, > >>>>> for instance, for them to be used as OAuth Bearer Tokens. At the > >>>>> request > >>>> of > >>>>> the working group, closely related pure-JSON drafts were also > published. > >>>>> See: > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-jso > >>>>>>>>>> n > >>>>>>>>>> -seri > >>>>>> > >>>>>>>>>> alization-01 and > >>>>>> > >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-js > >>>>>>>>>> o > >>>>>>>>>> n-ser > >>>>>> > >>>>>>>>>> ialization-01 > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Use them if you prefer if they better suit your use cases. > >>>>>>>>>> They > >>>> could > >>>>> be adopted as working group documents, if there's interest. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> See above. These are super-clunky, and the need to be the > >>>>>>>>> main > >>>>> focus of the WG, not an afterthought. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Not supporting multiple recipients > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> The JSON serialization drafts above do, again, in response to > >>>>>>>>>> use > >>>>> cases presented by the working group. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> See above. Because of the unnecessary inclusion of the header > >>>>>>>>> in > >>>> the > >>>>> integrity check, this is far less efficient than it should be. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lacking clear distinctions between signing and MAC > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Functionally, these are very similar operations, at least > >>>>>>>>>> from an > >>>>> implementation perspective, so it's not clear that making a clear > >>>> distinction > >>>>> would help either developers or adoption in any practical way. > >>>>> They > >>>> achieve > >>>>> overlapping, but admittedly sometimes different goals. I believe > >>>>> that developers can be trusted to use the algorithms that achieve > >>>>> their applications' goals without making a hard distinction between > the two. > >>>> But > >>>>> I'd be interested in hearing your thoughts on why you believe a > >>>> brighter-line > >>>>> distinction might be useful or necessary. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> It's important if you want to do MACs with anything other than > >>>>>>>>> pre- > >>>>> shared keys. If you want to do anything more advanced, you need > >>>>> to have wrapped keys, in which case an object with a MAC starts to > >>>>> look a lot more like a JWE than a JWS. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lacking clear processing instructions for different key > >>>>>> > >>>>>>>>>> establishment modalities > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> This seems like an area where the existing drafts could be > >>>>>>>>>> refined > >>>> to > >>>>> add descriptions for additional establishment modalities, possibly > >>>>> based upon your ideas and descriptions, should the working group > >>>>> decide to do > >>>> so. > >>>>> What additional modalities do you have use cases for that you > >>>>> believe are not achievable or straightforward with the existing > >>>>> drafts? The existing modalities supported are largely those that > >>>>> existing developers had told > >>>> us > >>>>> they needed and draw both from the precursor > >>>>> draft-jones-json-web-* documents and draft-rescorla-jsms. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Bear in mind that the balance that the current drafts try to > >>>>>>>>>> strike > >>>> is > >>>>> keeping the Mandatory to Implement (MTI) feature footprint small > >>>>> enough that developers, including Web developers, are likely to > >>>>> adopt the specs, while still providing enough functionality to make > them generally useful. > >>>> As > >>>>> in any balance, it's often possible to shift things a bit and > >>>>> still > >>>> maintain the > >>>>> balance, but I'd like people to keep the ubiquitous adoption goal > >>>> front-and- > >>>>> center when proposing additional functionality. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical > >>>>>> > >>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to > understand > >>>>>> > >>>>>>>>>> that!) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I agree that we need to find a reasonable MTI. The current > >>>>>>>>> JSMS > >>>> draft > >>>>> doesn't really specify which parts are MTI, beyond basic things > >>>>> like > >>>> base64url > >>>>> encoding and ignoring unknown fields. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> My main concern is that JWS and JWE don't really tell me which > >>>> fields > >>>>> need to be present for which use case. If I'm putting a MAC on a JWS > vs. > >>>> a > >>>>> signature, do I need "jwk" or "jku" fields to be populated? > >>>>> Whereas in > >>>> JSMS, > >>>>> I think these things are much clearer due to the separation of the > >>>>> use > >>>> cases > >>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures > >>>>> and wrapped keys into sub-objects. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lack of clear typing of objects > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Most JSON documents aren't clearly typed; instead, developers > >>>>>>>>>> and > >>>>> implementations understand from context what the meaning of each > field is. > >>>>> XML is clearly typed, but developers are voting with their feet by > >>>>> moving > >>>> to > >>>>> JSON. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> What practical advantages resulting from overlaying a typing > >>>>> infrastructure on JSON do you believe are worth the potential > >>>>> costs of > >>>> doing > >>>>> so? BTW, I'm not opposed to having a JSON schema description of > >>>>> the JOSE JSON data structures like JSMS did in > >>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A, but > >>>>> I'll remark that this an informative > >>>> tool, not > >>>>> a normative one. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I actualy don't have a hugely urgent requirement here either. > >>>>>>>>> It's > >>>>> something that others in the WG had requested, which is trivial to > >>>>> add in JSMS, but not in JWE/JWS -- again because of the > >>>>> unnecessary integrity protection of the header. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lack of versioning for future extensibility > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> An optional version field could be added if the working group > >>>>>> > >>>>>>>>>> desires, however the last time the working group discussed > >>>>>>>>>> it, they > >>>>>> > >>>>>>>>>> decided not to do so. Rather, specs like this effectively > >>>>>>>>>> become > >>>>>> > >>>>>>>>>> "versioned" when revised in a way that new fields are added. > >>>>>>>>>> If > >>>>>> > >>>>>>>>>> you understand the new fields, you support that new version. > >>>>>>>>>> (Note > >>>>>> > >>>>>>>>>> that this is independent of whether there is a version number > >>>>>> > >>>>>>>>>> field, which according to some participants in the previous > >>>>>> > >>>>>>>>>> discussion, they regarded as therefore being redundant > >>>>>> > >>>>>>>>>> information.) > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> I'm not religious about not having a version number field, > >>>>>>>>>> but > >>>> often > >>>>> "less is more". > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Indeed, I'm not religious either. It just seems like a > >>>>>>>>> general good > >>>> idea > >>>>> to state this directly as opposed to having parsers divine it > >>>>> based on > >>>> which > >>>>> fields are present. To quote RFC 5652: > >>>>>> > >>>>>>>>> " > >>>>>> > >>>>>>>>> Each of the major data structures includes a version number as > >>>>>>>>> the > >>>>>> > >>>>>>>>> first item in the data structure. The version numbers are > >>>>>>>>> intended > >>>>>> > >>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not > >>>>>>>>> check > >>>>> the > >>>>>> > >>>>>>>>> version number prior to attempting a decode, and if a decode > >>>>>>>>> error > >>>>>> > >>>>>>>>> occurs, then the version number is checked as part of the > >>>>>>>>> error > >>>>>> > >>>>>>>>> handling routine. This is a reasonable approach; it places > >>>>>>>>> error > >>>>>> > >>>>>>>>> processing outside of the fast path. This approach is also > >>>>>> > >>>>>>>>> forgiving when an incorrect version number is used by the > sender. > >>>>>> > >>>>>>>>> " > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Best, > >>>>>> > >>>>>>>>> --Richard > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Best wishes, > >>>>>> > >>>>>>>>>> -- Mike > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>> > >>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] > >>>>>> > >>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM > >>>>>> > >>>>>>>>>> To: Mike Jones > >>>>>> > >>>>>>>>>> Cc: jose@ietf.org > >>>>>> > >>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for > >>>>>> > >>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. > >>>>>>>>>> IMO, > >>>> the > >>>>> current JW* specs are deficient in several ways, e.g.: > >>>>>> > >>>>>>>>>> -- Not being JSON > >>>>>> > >>>>>>>>>> -- Not supporting multiple recipients > >>>>>> > >>>>>>>>>> -- Lacking clear distinctions between signing and MAC > >>>>>> > >>>>>>>>>> -- Lacking clear processing instructions for different key > >>>>>> > >>>>>>>>>> establishment modalities > >>>>>> > >>>>>>>>>> -- Lack of clear typing of objects > >>>>>> > >>>>>>>>>> -- Lack of versioning for future extensibility > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Looking at the current specs, it didn't seem to me that it > >>>>>>>>>> would be > >>>>> simple to adapt them to address these deficiencies. So I just did > >>>>> a > >>>> re-write. > >>>>> If you think they can be addressed within the current framework, > >>>>> please explain. I just found it simpler to start from whole cloth. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Cheers, > >>>>>> > >>>>>>>>>> --Richard > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>>> Hi Richard, > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE > >>>> documents, > >>>>> I encourage you to ask about them on the list. The documents have > >>>>> significant history going back to mid-2010 when convergence > >>>>> discussions started among people with four different JSON signing > >>>>> & encryption proposals. JWT and the current JOSE specs and > >>>>> implementations are the result. I realize that not all the JOSE > >>>>> participants were part of those discussions from the beginning > >>>>> (although many were) and so teasing out the rationale for specific > >>>>> decisions might help people better understand the choices made, > >>>>> and hopefully thereby increase consensus behind the eventual > working group choices. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> If the list that you're puzzled by is the bulleted list > >>>>>>>>>>> below, > >>>> maybe we > >>>>> can start a discussion on that basis. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Best wishes, > >>>>>> > >>>>>>>>>>> -- Mike > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>> > >>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] > >>>>>>>>>>> On > >>>>>> > >>>>>>>>>>> Behalf Of Richard L. Barnes > >>>>>> > >>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM > >>>>>> > >>>>>>>>>>> To: jose@ietf.org > >>>>>> > >>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for > >>>>>> > >>>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Dear JOSE WG, > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a > >>>>>>>>>>> thorough > >>>>> review of the JW* specs, I was kind of puzzled by some of the > >>>>> design decisions. So I also went through and wrote an alternative > >>>>> format, this > >>>> time > >>>>> taking a more of a cue from CMS. A link to the document is below. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Summary of differences: > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the > header > >>>>>> > >>>>>>>>>>> parameters are represented in JSON. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS allows for full algorithm agility in key agreement, > >>>>>>>>>>> while > >>>> JWE > >>>>>> > >>>>>>>>>>> only allows ECDH-ES. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and > >>>>>> > >>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple > >>>>> WrappedKey > >>>>>> > >>>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- > >>>>>> > >>>>>>>>>>> encryption of the entire object for each recipient. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o The signature and MAC functions of the JWS object are > >>>>>>>>>>> separated > >>>>>> > >>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS parameters are not integrity-protected, as they are > >>>>>>>>>>> in JWE > >>>>>> > >>>>>>>>>>> and JWS. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, > >>>>>>>>>>> but > >>>> could > >>>>>> > >>>>>>>>>>> be added without significant change. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown > header > >>>>>> > >>>>>>>>>>> parameters, in order to facilitate extensibility. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> I've also thrown together an initial JavaScript > >>>>>>>>>>> implementation > >>>> (based > >>>>> on NodeJS for some python crypto glue), which is on github: > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Comments are very welcome. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Thanks, > >>>>>> > >>>>>>>>>>> --Richard > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Begin forwarded message: > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> From: internet-drafts@ietf.org > >>>>>> > >>>>>>>>>>>> Subject: New Version Notification for > >>>>>> > >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>>> > >>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT > >>>>>> > >>>>>>>>>>>> To: rbarnes@bbn.com > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has > >>>>>>>>>>>> been > >>>>>> > >>>>>>>>>>>> successfully submitted by Richard Barnes and posted to the > >>>>>>>>>>>> IETF > >>>>>> > >>>>>>>>>>>> repository. > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> Filename: draft-barnes-jose-jsms > >>>>>> > >>>>>>>>>>>> Revision: 00 > >>>>>> > >>>>>>>>>>>> Title: JavaScript Message Security Format > >>>>>> > >>>>>>>>>>>> Creation date: 2012-06-15 > >>>>>> > >>>>>>>>>>>> WG ID: Individual Submission > >>>>>> > >>>>>>>>>>>> Number of pages: 25 > >>>>>> > >>>>>>>>>>>> URL: > >>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- > >>>>> jsms-00.txt > >>>>>> > >>>>>>>>>>>> Status: > >>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > >>>>>> > >>>>>>>>>>>> Htmlized: > >>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> Abstract: > >>>>>> > >>>>>>>>>>>> Many applications require the ability to send > >>>>>>>>>>>> cryptographically > >>>>>> > >>>>>>>>>>>> secured messages. While the IETF has defined a number of > >>>>> formats > >>>>>> > >>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings > >>>>>>>>>>>> which > >>>>>> > >>>>>>>>>>>> are not easy to use in modern applications. This document > >>>>>> > >>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a > >>>>>>>>>>>> new > >>>>>> > >>>>>>>>>>>> cryptographic message format which is based on JavaScript > >>>>>>>>>>>> Object > >>>>>> > >>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to > >>>> generate > >>>>> and parse. > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> The IETF Secretariat > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> jose mailing list > >>>>>> jose@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nat Sakimura (=nat) > >>>>>> Chairman, OpenID Foundation > >>>>>> http://nat.sakimura.org/ > >>>>>> @_nat_en > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >> > > > > > > > From tonynad@microsoft.com Tue Jun 26 15:43: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 6837C21F853B for ; Tue, 26 Jun 2012 15:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c473PmYImKjL for ; Tue, 26 Jun 2012 15:43:47 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72521F8516 for ; Tue, 26 Jun 2012 15:43:47 -0700 (PDT) Received: from mail175-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 22:42:05 +0000 Received: from mail175-co1 (localhost [127.0.0.1]) by mail175-co1-R.bigfish.com (Postfix) with ESMTP id C6B4FAC0105 for ; Tue, 26 Jun 2012 22:42:04 +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: -19 X-BigFish: VS-19(zz98dI9371I936eI168aJ148cI542M1432I1418I41c5N4015Izz1202h1082kzz1033IL8275eh8275bh8275dh5eeeKf73b6ila1495iz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail175-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; 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 Received: from mail175-co1 (localhost.localdomain [127.0.0.1]) by mail175-co1 (MessageSwitch) id 1340750522857219_1329; Tue, 26 Jun 2012 22:42:02 +0000 (UTC) Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.251]) by mail175-co1.bigfish.com (Postfix) with ESMTP id CF738280044 for ; Tue, 26 Jun 2012 22:42:02 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 22:42:02 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 26 Jun 2012 22:43:43 +0000 Received: from mail145-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 22:42:00 +0000 Received: from mail145-va3 (localhost [127.0.0.1]) by mail145-va3-R.bigfish.com (Postfix) with ESMTP id 1A64848026E for ; Tue, 26 Jun 2012 22:42:00 +0000 (UTC) Received: from mail145-va3 (localhost.localdomain [127.0.0.1]) by mail145-va3 (MessageSwitch) id 1340750516375015_31344; Tue, 26 Jun 2012 22:41:56 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.247]) by mail145-va3.bigfish.com (Postfix) with ESMTP id 562762C0094; Tue, 26 Jun 2012 22:41:56 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 22:41:54 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0164.004; Tue, 26 Jun 2012 22:43:34 +0000 From: Anthony Nadalin To: Jim Schaad , 'John Bradley' Thread-Topic: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt Thread-Index: AQHNU+zdnbVDjIKLnEGk4H6pIKPfX5cNMgtw Date: Tue, 26 Jun 2012 22:43:33 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <43B1BD79-7847-45DF-A92A-C9DDC25F762A@ve7jtb.com> <00e901cd53ec$944e5040$bceaf0c0$@augustcellars.com> In-Reply-To: <00e901cd53ec$944e5040$bceaf0c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] 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%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%BBN.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-OriginatorOrg: microsoft.com Cc: "'Richard L. Barnes'" , "jose@ietf.org" Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:43:50 -0000 Used all the time as its quicker than CBC mocde very simple if I have just = 1 block of data=20 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Tuesday, June 26, 2012 3:40 PM To: Anthony Nadalin; 'John Bradley' Cc: 'Richard L. Barnes'; jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.= txt Under what circumstances would people use ECB? =20 > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Tuesday, June 26, 2012 2:03 PM > To: John Bradley > Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org > Subject: RE: [jose] New Version Notification for=20 > draft-barnes-jose-jsms- 00.txt >=20 > AES-ECB is also a popular alternative >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Tuesday, June 26, 2012 1:59 PM > To: Anthony Nadalin > Cc: Richard L. Barnes; Jim Schaad; jose@ietf.org > Subject: Re: [jose] New Version Notification for=20 > draft-barnes-jose-jsms- 00.txt >=20 > Yes that is why we added the composite HMAC + AES-CBC. We can debate if > that is an algorithm or mandatory integrity with non AEAD algorithms,=20 > but the > effect of integrity protecting the header remains in both cases. >=20 > John B. >=20 > On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote: >=20 > > Not sure there was a WG decision and what that would mean if there=20 > > was, > as there are many libraries out there that don't support the=20 > encryption with > integrity algorithms, so need to support alternative means of things=20 > like key > wrap that could have an integrity check. > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > > Of John Bradley > > Sent: Tuesday, June 26, 2012 12:30 PM > > To: Richard L. Barnes > > Cc: Jim Schaad; jose@ietf.org > > Subject: Re: [jose] New Version Notification for=20 > > draft-barnes-jose-jsms-00.txt > > > > There was a WG decision to not allow encryption without integrity. Ji= m > and others call that sender verification. > > > > Or on simple terms no AES-CBC without a mandatory MAC integrity. > > > > The JWE/JWS specs don't control the body. That is intended to be arbitrary > content. > > > > We do have s JWT spec that covers the body for security tokens. The idea > was to separate that from signing and encryption so that signing and=20 > encryption can be used for other objects. > > > > John B. > > > > On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: > > > >>> Now that we are mandating JWE sender verification people will be=20 > >>> using > JWE with symmetric keys or key agreement. > >>> In those cases one can easily argue that the header should be protected > as much as in HMAC. > >> > >> Can you clarify the scope of "we are mandating"? > >> > >> > >>> There may well be signing_time or other elements that would go=20 > >>> into > the header as well for JWE. > >> > >> Why do these need to go into the header rather than the body? > >> > >> --Richard > >> > >> > >> > >> > >>> Regards > >>> John B. > >>> > >>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: > >>> > >>>> > >>>> > >>>> Richard, > >>>> > >>>>> -----Original Message----- > >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 > >>>>> Behalf Of Richard L. Barnes > >>>>> Sent: Monday, June 25, 2012 2:35 PM > >>>>> To: Nat Sakimura > >>>>> Cc: Mike Jones; jose@ietf.org > >>>>> Subject: Re: [jose] New Version Notification for > >>>>> draft-barnes-jose-jsms- 00.txt > >>>>> > >>>>> Hi Nat, > >>>>> > >>>>> I'm not sure what X.509 fiasco you're referring to. There was a=20 > >>>>> recent > >>>> MD5 > >>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact,=20 > >>>>> there have > >>>> been > >>>>> recommendations for preventing this attack in X.509 since 2005 [2]. > >>>>> As > >>>> was > >>>>> noted on the SAAG list, the real news here is that Microsoft=20 > >>>>> wasn't > >>>> following > >>>>> any of those recommendations. > >>>>> > >>>>> JWS would have had the same problem as X.509. The attack did=20 > >>>>> not modify the cryptographic parameters (anything that would=20 > >>>>> have gone in the header), it would not have been thwarted by the=20 > >>>>> integrity protection we're worrying about. > >>>>> > >>>>> Actually, the header signing that JWS does makes it even nicer=20 > >>>>> for the > >>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS=20 > >>>>> header > >>>> value > >>>>> is entirely static for a given signer, it's easy to use as a=20 > >>>>> fixed prefix. > >>>> If JWS just > >>>>> signed the content, then the application could include a=20 > >>>>> something random up front to prevent such prefix-based attacks. > >>>>> > >>>> > >>>> I don't believe that this is a true statement. If you had a=20 > >>>> prefix or just signed what was given to you (i.e. no prefix), it=20 > >>>> would make no difference in terms of the attack for Flame. Flame=20 > >>>> could always use a fixed prefix of its own design rather than=20 > >>>> using the fixed header that is generated by having JWS sign the=20 > >>>> header > information. > >>>> > >>>>> It's tempting to say that we should just add randomness to the=20 > >>>>> JOSE > >>>> format. > >>>>> But the real lesson of the Flame/MD5 attacks is operational: If=20 > >>>>> you're > >>>> signing > >>>>> something that somebody else gave you, make sure that you're not=20 > >>>>> signing exactly what they gave you. Follow the recommendations=20 > >>>>> of RFC 4270. In other contexts, there's no need of similar=20 > >>>>> random elements; it just adds complexity. > >>>> > >>>> This is definitely a true statement in all events and is=20 > >>>> something that should be added to the Security Considerations sectio= n. > >>>> > >>>> That being said, I think that there are valid reasons for wanting=20 > >>>> to protect the header information by some authentication processing. > >>>> PKIX certificates protect the signature algorithm information (by=20 > >>>> copying the data into the to be signed block) and CMS has long=20 > >>>> allowed for information to be included in the signed attributes=20 > >>>> area that identifies the algorithms used, the certificates used=20 > >>>> and so forth. There are also other things that we might find to=20 > >>>> be convenient to be placed in the header information that is=20 > >>>> current not there (a signing time and embedded content type comes=20 > >>>> to mind) that would be a product either of specific types of=20 > >>>> signatures or > becomes a common attribute to be placed there. > >>>> > >>>> In terms of encryption operations, I remember in the past that I=20 > >>>> have had either corrupted encrypted streams or corrupted IVs and=20 > >>>> had a successful decryption that later generated other problems=20 > >>>> when trying to parse. This is less of an issue with AEAD=20 > >>>> algorithms as they have a much stricter rule on when the stream > decrypts correctly. > >>>> > >>>> Jim > >>>> > >>>>> > >>>>> --Richard > >>>>> > >>>>> > >>>>> > >>>>> [1]=20 > >>>>> > >>>>> [2] > >>>>> > >>>>> > >>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: > >>>>> > >>>>>> Especially after the X.509 fiasco, I strongly believe that=20 > >>>>>> having > >>>> integrity > >>>>> check over the metadata is a good thing. It is such a little=20 > >>>>> effort that > >>>> gives us > >>>>> much more protection down the road. In this sense, I fully agree=20 > >>>>> with Ben here. We should have integrity protection over the header. > >>>>>> > >>>>>> Nat > >>>>>> > >>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones > >>>>> wrote: > >>>>>> Two years ago when the developer community needing a=20 > >>>>>> JSON-friendly > >>>>> token format was designing the JSON Web Token (JWT), we=20 > >>>>> explicitly asked security experts whether the header parameters=20 > >>>>> should be integrity protected or not. Among them, Ben Laurie=20 > >>>>> was one of the voices saying > >>>> that > >>>>> securing them was the right thing to do. > >>>>>> > >>>>>> > >>>>>> > >>>>>> He argued that if the parameters can be protected in a=20 > >>>>>> practical manner, > >>>>> then they should. Doing so provides an additional hurdle that=20 > >>>>> attackers would have to surmount. For example, if they can try=20 > >>>>> to substitute a > >>>> weaker > >>>>> authentication scheme, then they must figure out how to make it=20 > >>>>> authenticate correctly despite some plaintext they can't control=20 > >>>>> - the > >>>> header > >>>>> parameters. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Ben also took the position that paring security protocols down=20 > >>>>>> to the > >>>> least > >>>>> you can get away with, given attacks you can think of, is not a=20 > >>>>> good > >>>> design > >>>>> principle. If there is not a strong argument against including=20 > >>>>> a feature > >>>> that > >>>>> may make it harder for attackers, then that feature should be > included. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree with him. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The decision to provide integrity protection for the headers is > >>>> documented > >>>>> in the session notes at http://self-issued.info/?p=3D361, which sai= d: > >>>>>> > >>>>>> > >>>>>> > >>>>>> . What to sign (envelope.payload or just payload)? > >>>>>> > >>>>>> Given that the envelope is extensible and therefore may contain > >>>> security- > >>>>> sensitive information, we reached a consensus (with input from=20 > >>>>> Ben Laurie via IM) that the combination envelope.payload must be si= gned. > >>>>>> > >>>>>> > >>>>>> I believe that logic is as sound today as it was then. > >>>>>> > >>>>>> > >>>>>> > >>>>>> For all these reasons, I therefore personally stand by the=20 > >>>>>> community's > >>>>> decision to provide integrity protection for the headers. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Best=20 > >>>>>> wishes, > >>>>>> > >>>>>> -- Mike > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 > >>>>>> Behalf Of > >>>>> John Bradley > >>>>>> Sent: Wednesday, June 20, 2012 3:57 PM > >>>>>> To: Richard L.Barnes > >>>>>> Cc: jose@ietf.org > >>>>>> Subject: Re: [jose] New Version Notification for > >>>>>> draft-barnes-jose-jsms- > >>>>> 00.txt > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi Richard, > >>>>>> > >>>>>> > >>>>>> > >>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding=20 > >>>>>> and not > >>>>> susceptible to modification with ECDH or RSA-PSS it is not. > >>>>>> > >>>>>> There are possible hash truncation attacks by shortening SHA256=20 > >>>>>> to > >>>> SHA224 > >>>>> as an example (I know we preclude truncated hashes at the > moment). > >>>>>> > >>>>>> > >>>>>> > >>>>>> The bad feeling I get around this is that if there is a=20 > >>>>>> scenario where > >>>> the > >>>>> attacker controls the plaintext to be signed and there is no=20 > >>>>> signer > >>>> controlled > >>>>> text contributed there are potential bad things that could=20 > >>>>> happen down the road. > >>>>>> > >>>>>> > >>>>>> > >>>>>> This bit us with x509 certs not that long ago (yes with MD5 > >>>>>> admittedly) > >>>>> where the attacker could use a certificate extension to include=20 > >>>>> extra data > >>>> and > >>>>> cause a pre collided hash to be generated. > >>>>>> > >>>>>> Having part of the signed data outside the control of an=20 > >>>>>> attacker is a > >>>> good > >>>>> thing. (having a nonce or message ID in the envelope is=20 > >>>>> possible though > >>>> not > >>>>> yet required in JWS.) > >>>>>> > >>>>>> > >>>>>> > >>>>>> I am still of the opinion that putting the base64 encoded=20 > >>>>>> envelope > >>>> inside > >>>>> the hash calculation is a valid way to allow additional attributes. > >>>>>> > >>>>>> Another structure to hold the attributes adds more complexity,=20 > >>>>>> as would > >>>>> saying that they need to be inside the signed object. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I think part of this is that as one of the openID Connect=20 > >>>>>> authors I look > >>>> at this > >>>>> as a necessary security token format, for OAuth and Connect. > >>>>>> > >>>>>> For that simple processing with one signature is a high=20 > >>>>>> priority for > >>>> adoption. > >>>>>> > >>>>>> > >>>>>> > >>>>>> From a general signing/encrypting of documents point of view=20 > >>>>>> you > >>>>> legitimately have different priorities. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I know it is hard to prove a negative but It is also going to=20 > >>>>>> be > >>>> difficult for me > >>>>> to go back to security people at google Facebook and other=20 > >>>>> places and explain how not integrity protecting the header could=20 > >>>>> be better than integrity protecting it. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It seems that I would be reduced to arguing that this is no=20 > >>>>>> worse than > >>>> CMS > >>>>> and that hasn't been proven insecure yet. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Allowing a possible attacker to control the hash output, and=20 > >>>>>> not > >>>> integrity > >>>>> protecting the additional data, seems like something I am bound=20 > >>>>> to regret > >>>> in > >>>>> the future. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> John B. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hey John, > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> Interesting points, but I don't think they actually apply here. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to downgrade attacks: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> The attack that RFC 5752 is concerned with is when an attacker=20 > >>>>>>> strips > >>>>> signatures from a signed message, so that the only ones left are=20 > >>>>> ones he > >>>> can > >>>>> tamper with. So the integrity protection here is "horizontal";=20 > >>>>> it goes > >>>> across > >>>>> signatures. The integrity protection in JWS/JWE is "vertical"=20 > >>>>> -- it only > >>>> protects > >>>>> one signer's parameters -- so it is, so to speak, orthogonal. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to "brown bag" attacks: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> The root of this attack is ambiguity about what content is > >>>>>>> *signed* > >>>>>> > >>>>>>> vs. what content is *used*. If an application doesn't verify=20 > >>>>>>> that > >>>>>> > >>>>>>> it's actually using the stuff that's signed, then it can be=20 > >>>>>>> tricked > >>>>>> > >>>>>>> into accepting something unsigned. (Cf. > >>>>>> > >>>>>>> ) > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> However, I don't think any of the current proposals have that > problem. > >>>>> In JWE/JWS, the signed content is right there between the dots,=20 > >>>>> and in > >>>> JSMS, > >>>>> it's in the "content" element. The current JSMS draft does=20 > >>>>> allow detached signatures, but with a "voids your warranty" sticker= on it. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> In any case, these attacks have nothing to do with whether the > >>>>> cryptographic parameters are integrity-protected with the content. > >>>>> The example attacks in the IBM still work regardless -- the=20 > >>>>> whole point of the attack is that the cryptographic processing=20 > >>>>> is the same, only the > >>>> (non-crypto) > >>>>> matching of content is flawed. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to "arbitrary attributes": > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> We can have that here, too, but you need canonicalization. =20 > >>>>>>> And > >>>> base64- > >>>>> encoding is not not canonicalization -- it just waves its hands=20 > >>>>> over the question of equivalence. In my opinion, we should keep=20 > >>>>> the cryptographic object simple by disallowing attributes, and=20 > >>>>> push the attributes you would sign inside of the thing being=20 > >>>>> signed. If people really do want > >>>> attributes, it > >>>>> doesn't seem to me like JSON canonicalization is very hard. I=20 > >>>>> can do it > >>>> in 19 > >>>>> lines of python: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard too "meta-data in the body": > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> It seems to me like if we're trying to define a general format=20 > >>>>>>> for > >>>> applying > >>>>> security protections, then we ought to keep out things that=20 > >>>>> aren't > >>>> strictly > >>>>> security relevant. Those things can go in application-specific=20 > >>>>> content > >>>> types > >>>>> (e.g., SAML) without polluting the general purpose header. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> With regard to "defense in depth" and selling this to=20 > >>>>>>> government > >>>>> agencies: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> CMS, via S/MIME, is in broad use across multiple federal=20 > >>>>>>> agencies and > >>>>> large enterprises. JSMS is essentially a profile of CMS (see=20 > >>>>> Section 7), > >>>> and > >>>>> has the same security properties. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> Cheers, > >>>>>> > >>>>>>> --Richard > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>>> Hi Richard, > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> Originally we only integrity protected the header for signing. > >>>>>>>> We > >>>> added > >>>>> the integrity protection to encryption as part of AEAD, as=20 > >>>>> encryption can > >>>> also > >>>>> be used for sender verification. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I understand the argument that it makes things simpler if we=20 > >>>>>>>> don't > >>>>> integrity protect the header information. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> However xmldsig, provides integrity over those elements to=20 > >>>>>>>> prevent > >>>>> possible downgrade attacks by manipulating the algorithms. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> CMS may not typically provide that integrity protection but I=20 > >>>>>>>> think > >>>> Jim > >>>>> Schaad and Sean Terner created RFC5752 to address downgrade > attacks. > >>>>>> > >>>>>>>> Given they are on this list they can speak to their view on=20 > >>>>>>>> integrity > >>>> over > >>>>> the crypto parameters. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I also recall when working on InfoCards there was a Monte=20 > >>>>>>>> Carlo/Brown > >>>>> Bag attack that needs to be considered if we move to something=20 > >>>>> more like a detached signature. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> The other design consideration is that we wanted to be able=20 > >>>>>>>> to sign > >>>>> arbitrary byte strings not just JSON. You could sign XML if you > wanted. > >>>>>> > >>>>>>>> That prevented us from including meta-data in the body as we=20 > >>>>>>>> didn't > >>>>> want to touch it. That left us with the header to include additional > >>>> elements > >>>>> in. > >>>>>> > >>>>>>>> Not integrity protecting those elements as well would be a > problem. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I am not a CMS expert but I believe it allows for signing of > >>>> arbitrary > >>>>> attributes not unlike the current JOSE spec. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> Especially for something that will be used with JWT security=20 > >>>>>>>> tokens I > >>>> will > >>>>> have a hard time making the argument to NIST and others that=20 > >>>>> need to approve this format that not integrity protecting the=20 > >>>>> header parameters is appropriate defence in depth, for something=20 > >>>>> that might be replacing signed SAML assertions in some applications= . > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> I do understand how not integrity protecting the header will=20 > >>>>>>>> make > >>>> some > >>>>> things easier, however I can't agree that the benefit outweighs=20 > >>>>> the disadvantages. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> Regards > >>>>>> > >>>>>>>> John B. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>>> Hey Mike, > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Thanks for having some back-and-forth with me on this. I=20 > >>>>>>>>> think this > >>>> is a > >>>>> good discussion to have right now. I would like to discuss some > >>>> high-level > >>>>> points, and then I'll respond inline to your precise points. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to=20 > >>>>>>>>> define > >>>> JSON- > >>>>> based formats for integrity and confidentiality protections. =20 > >>>>> JWE and JWS don't fit that requirement, so we should re-consider=20 > >>>>> their adoption and > >>>> call > >>>>> for new candidates. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Major points: > >>>>>> > >>>>>>>>> 1. JOSE is JSON > >>>>>> > >>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and > >>>>>> > >>>>>>>>> URL-safeness are still OK, as derivatives > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Part 1: JOSE is JSON > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> The JOSE WG charter calls out four deliverables, three of=20 > >>>>>>>>> which are > >>>>> explicitly required to be JSON: > >>>>>> > >>>>>>>>> -- "JSON-structured integrity protection" > >>>>>> > >>>>>>>>> -- "JSON-structured encryption" > >>>>>> > >>>>>>>>> -- "public keys as JSON-structured objects" > >>>>>> > >>>>>>>>> (The fourth is just a list of algorithms, which should be=20 > >>>>>>>>> JSON as > >>>>>> > >>>>>>>>> well, just as RFC 3370 is ASN.1.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> In light of these requirements, JWE and JWS are clearly not=20 > >>>>>>>>> suitable > >>>>>> > >>>>>>>>> candidates to fulfill the working group's milestones. (At=20 > >>>>>>>>> least in > >>>>>> > >>>>>>>>> their current form.) So ISTM that we need to step back and > >>>>>> > >>>>>>>>> re-evaluate alternatives for the three above milestones,=20 > >>>>>>>>> especially > >>>>>> > >>>>>>>>> the first two. (JWK is not as far off.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization" > >>>>>>>>> drafts > >>>>> are pretty half-hearted. Because JWS and JWE include the=20 > >>>>> cryptographic parameters within the integrity protection, they=20 > >>>>> have to have the headers included as base64-encoded strings. =20 > >>>>> That obviously adds a lot of > >>>> complexity > >>>>> to encoding and decoding -- for example, you have to keep the=20 > >>>>> encoded header around even after you've decoded it! -- and just > plain more octets. > >>>>> The support for multiple recipients and multiple signatures is=20 > >>>>> both > >>>> unweildy > >>>>> (matching up parallel indices for headers and signatures) and=20 > >>>>> inefficient (multiple integrity check values in encrypted objects). > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> By contrast, JSMS takes advantage of the cryptographic=20 > >>>>>>>>> wisdom that > >>>>> went into CMS, while making the syntax pure JSON and as simple=20 > >>>>> as > >>>> possible. > >>>>> Multiple signatures and multiple recipients are supported with=20 > >>>>> absolute minimum overhead. So I think it's worth consideration=20 > >>>>> by the working > >>>> group. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Part 2: JSON !=3D> canonicalization > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I would like to dispel the myth that a JSON-based format=20 > >>>>>>>>> requires > >>>>>> > >>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires > >>>>>> > >>>>>>>>> "canonicalization" (via base64url encoding) because it's=20 > >>>>>>>>> included > >>>>>> > >>>>>>>>> within the integrity protection. I'm not aware of any=20 > >>>>>>>>> reason for > >>>>>> > >>>>>>>>> including the cryptographic parameters in the integrity=20 > >>>>>>>>> check, > >>>>>> > >>>>>>>>> instead of only integrity-protecting the content itself. > >>>>>>>>> Indeed, if > >>>>>> > >>>>>>>>> there were an attack based on non-integrity-protected=20 > >>>>>>>>> cryptographic > >>>>>> > >>>>>>>>> parameters, it would be a pretty big deal, since neither CMS=20 > >>>>>>>>> nor IKE > >>>>>> > >>>>>>>>> nor provides this protection. (TLS does provide a signature=20 > >>>>>>>>> over > >>>>>> > >>>>>>>>> the algorithms, but only as a way to bind the public key to=20 > >>>>>>>>> the > >>>>>> > >>>>>>>>> session.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Indeed CMS doesn't require canonicalization at all, except=20 > >>>>>>>>> for > >>>>> attributes that are included in the protected content=20 > >>>>> (signedAttrs / authenticatedAttrs), which need to be=20 > >>>>> DER-encoded. In JSMS, we don't allow those parameters, so there=20 > >>>>> is no need for canonicalization > at all. > >>>> All the > >>>>> "canonicalization" that's needed is to base64url-encode the=20 > >>>>> protected content. In that regard, JSMS is even simpler than > JWE/JWS. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as=20 > >>>>>>>>> derivatives > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I have absolutely no objection to defining a compact,=20 > >>>>>>>>> URL-safe > >>>> format. > >>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the=20 > >>>>> example > >>>> from > >>>>> Section 3.1 of the JWS spec, we get the following JSMS object: > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> { > >>>>>> > >>>>>>>>> "v":1, > >>>>>> > >>>>>>>>> "t":"au", > >>>>>> > >>>>>>>>> "a":"hs256", > >>>>>> > >>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", > >>>>>> > >>>>>>>>> "mac":"pwM0gJNMLFxn8G1- > juQFLrJtMEOR8_FeKIH3wIM_OAo", > >>>>>> > >>>>>>>>> "ki":"rSIilRk8Ego" > >>>>>> > >>>>>>>>> } > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> If we remove the decorative spaces and base64url-encode, we=20 > >>>>>>>>> only > >>>>> use > >>>>>> > >>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a=20 > >>>>>>>>> step > >>>>>> > >>>>>>>>> further and define an explicit compact format for=20 > >>>>>>>>> AuthenticatedData, > >>>>>> > >>>>>>>>> we can emulate JWS by moving the content and MAC fields=20 > >>>>>>>>> outside > >>>>> and > >>>>>> > >>>>>>>>> dot-combining. That avoids double-base64url-encoding, and=20 > >>>>>>>>> only > >>>>>> > >>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put=20 > >>>>>>>>> the code > >>>>>> > >>>>>>>>> to generate these in the Github project linked earlier.) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> So it's fine to have a compact, URL-safe format for an=20 > >>>>>>>>> objective, > >>>> but it > >>>>> makes *much* more sense to derive that from a full-size, usable,=20 > >>>>> JSON format than the other way around. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Responses to specific points inline below. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before=20 > >>>>>>>>>> doing > >>>> so, I'll > >>>>> say that I'm writing in the spirit of trying to increase mutual > >>>> understanding > >>>>> and consensus, rather than taking the point of view that the=20 > >>>>> status quo is > >>>> the > >>>>> only reasonable outcome. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> -- Not being JSON > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> This was by design, so that the results are URL-safe. This=20 > >>>>>>>>>> is > >>>> required, > >>>>> for instance, for them to be used as OAuth Bearer Tokens. At=20 > >>>>> the request > >>>> of > >>>>> the working group, closely related pure-JSON drafts were also > published. > >>>>> See: > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-signature-j > >>>>>>>>>> so > >>>>>>>>>> n > >>>>>>>>>> -seri > >>>>>> > >>>>>>>>>> alization-01 and > >>>>>> > >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption- > >>>>>>>>>> js > >>>>>>>>>> o > >>>>>>>>>> n-ser > >>>>>> > >>>>>>>>>> ialization-01 > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Use them if you prefer if they better suit your use cases. > >>>>>>>>>> They > >>>> could > >>>>> be adopted as working group documents, if there's interest. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> See above. These are super-clunky, and the need to be the=20 > >>>>>>>>> main > >>>>> focus of the WG, not an afterthought. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Not supporting multiple recipients > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> The JSON serialization drafts above do, again, in response=20 > >>>>>>>>>> to use > >>>>> cases presented by the working group. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> See above. Because of the unnecessary inclusion of the=20 > >>>>>>>>> header in > >>>> the > >>>>> integrity check, this is far less efficient than it should be. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lacking clear distinctions between signing and MAC > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Functionally, these are very similar operations, at least=20 > >>>>>>>>>> from an > >>>>> implementation perspective, so it's not clear that making a=20 > >>>>> clear > >>>> distinction > >>>>> would help either developers or adoption in any practical way. > >>>>> They > >>>> achieve > >>>>> overlapping, but admittedly sometimes different goals. I=20 > >>>>> believe that developers can be trusted to use the algorithms=20 > >>>>> that achieve their applications' goals without making a hard=20 > >>>>> distinction between > the two. > >>>> But > >>>>> I'd be interested in hearing your thoughts on why you believe a > >>>> brighter-line > >>>>> distinction might be useful or necessary. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> It's important if you want to do MACs with anything other=20 > >>>>>>>>> than > >>>>>>>>> pre- > >>>>> shared keys. If you want to do anything more advanced, you need=20 > >>>>> to have wrapped keys, in which case an object with a MAC starts=20 > >>>>> to look a lot more like a JWE than a JWS. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lacking clear processing instructions for different key > >>>>>> > >>>>>>>>>> establishment modalities > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> This seems like an area where the existing drafts could be=20 > >>>>>>>>>> refined > >>>> to > >>>>> add descriptions for additional establishment modalities,=20 > >>>>> possibly based upon your ideas and descriptions, should the=20 > >>>>> working group decide to do > >>>> so. > >>>>> What additional modalities do you have use cases for that you=20 > >>>>> believe are not achievable or straightforward with the existing=20 > >>>>> drafts? The existing modalities supported are largely those=20 > >>>>> that existing developers had told > >>>> us > >>>>> they needed and draw both from the precursor > >>>>> draft-jones-json-web-* documents and draft-rescorla-jsms. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Bear in mind that the balance that the current drafts try=20 > >>>>>>>>>> to strike > >>>> is > >>>>> keeping the Mandatory to Implement (MTI) feature footprint small=20 > >>>>> enough that developers, including Web developers, are likely to=20 > >>>>> adopt the specs, while still providing enough functionality to=20 > >>>>> make > them generally useful. > >>>> As > >>>>> in any balance, it's often possible to shift things a bit and=20 > >>>>> still > >>>> maintain the > >>>>> balance, but I'd like people to keep the ubiquitous adoption=20 > >>>>> goal > >>>> front-and- > >>>>> center when proposing additional functionality. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical > >>>>>> > >>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to > understand > >>>>>> > >>>>>>>>>> that!) > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I agree that we need to find a reasonable MTI. The current=20 > >>>>>>>>> JSMS > >>>> draft > >>>>> doesn't really specify which parts are MTI, beyond basic things=20 > >>>>> like > >>>> base64url > >>>>> encoding and ignoring unknown fields. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> My main concern is that JWS and JWE don't really tell me=20 > >>>>>>>>> which > >>>> fields > >>>>> need to be present for which use case. If I'm putting a MAC on=20 > >>>>> a JWS > vs. > >>>> a > >>>>> signature, do I need "jwk" or "jku" fields to be populated? > >>>>> Whereas in > >>>> JSMS, > >>>>> I think these things are much clearer due to the separation of=20 > >>>>> the use > >>>> cases > >>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures=20 > >>>>> and wrapped keys into sub-objects. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lack of clear typing of objects > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Most JSON documents aren't clearly typed; instead,=20 > >>>>>>>>>> developers and > >>>>> implementations understand from context what the meaning of each > field is. > >>>>> XML is clearly typed, but developers are voting with their feet=20 > >>>>> by moving > >>>> to > >>>>> JSON. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> What practical advantages resulting from overlaying a=20 > >>>>>>>>>> typing > >>>>> infrastructure on JSON do you believe are worth the potential=20 > >>>>> costs of > >>>> doing > >>>>> so? BTW, I'm not opposed to having a JSON schema description of=20 > >>>>> the JOSE JSON data structures like JSMS did in > >>>>> http://tools.ietf.org/html/draft- rescorla-jsms-00#appendix-A,=20 > >>>>> but I'll remark that this an informative > >>>> tool, not > >>>>> a normative one. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> I actualy don't have a hugely urgent requirement here either. > >>>>>>>>> It's > >>>>> something that others in the WG had requested, which is trivial=20 > >>>>> to add in JSMS, but not in JWE/JWS -- again because of the=20 > >>>>> unnecessary integrity protection of the header. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> -- Lack of versioning for future extensibility > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> An optional version field could be added if the working=20 > >>>>>>>>>> group > >>>>>> > >>>>>>>>>> desires, however the last time the working group discussed=20 > >>>>>>>>>> it, they > >>>>>> > >>>>>>>>>> decided not to do so. Rather, specs like this effectively=20 > >>>>>>>>>> become > >>>>>> > >>>>>>>>>> "versioned" when revised in a way that new fields are added. > >>>>>>>>>> If > >>>>>> > >>>>>>>>>> you understand the new fields, you support that new version. > >>>>>>>>>> (Note > >>>>>> > >>>>>>>>>> that this is independent of whether there is a version=20 > >>>>>>>>>> number > >>>>>> > >>>>>>>>>> field, which according to some participants in the previous > >>>>>> > >>>>>>>>>> discussion, they regarded as therefore being redundant > >>>>>> > >>>>>>>>>> information.) > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> I'm not religious about not having a version number field,=20 > >>>>>>>>>> but > >>>> often > >>>>> "less is more". > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Indeed, I'm not religious either. It just seems like a=20 > >>>>>>>>> general good > >>>> idea > >>>>> to state this directly as opposed to having parsers divine it=20 > >>>>> based on > >>>> which > >>>>> fields are present. To quote RFC 5652: > >>>>>> > >>>>>>>>> " > >>>>>> > >>>>>>>>> Each of the major data structures includes a version number=20 > >>>>>>>>> as the > >>>>>> > >>>>>>>>> first item in the data structure. The version numbers are=20 > >>>>>>>>> intended > >>>>>> > >>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not=20 > >>>>>>>>> check > >>>>> the > >>>>>> > >>>>>>>>> version number prior to attempting a decode, and if a decode=20 > >>>>>>>>> error > >>>>>> > >>>>>>>>> occurs, then the version number is checked as part of the=20 > >>>>>>>>> error > >>>>>> > >>>>>>>>> handling routine. This is a reasonable approach; it places=20 > >>>>>>>>> error > >>>>>> > >>>>>>>>> processing outside of the fast path. This approach is also > >>>>>> > >>>>>>>>> forgiving when an incorrect version number is used by the > sender. > >>>>>> > >>>>>>>>> " > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> Best, > >>>>>> > >>>>>>>>> --Richard > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Best wishes, > >>>>>> > >>>>>>>>>> -- Mike > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>> > >>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] > >>>>>> > >>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM > >>>>>> > >>>>>>>>>> To: Mike Jones > >>>>>> > >>>>>>>>>> Cc: jose@ietf.org > >>>>>> > >>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for > >>>>>> > >>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. > >>>>>>>>>> IMO, > >>>> the > >>>>> current JW* specs are deficient in several ways, e.g.: > >>>>>> > >>>>>>>>>> -- Not being JSON > >>>>>> > >>>>>>>>>> -- Not supporting multiple recipients > >>>>>> > >>>>>>>>>> -- Lacking clear distinctions between signing and MAC > >>>>>> > >>>>>>>>>> -- Lacking clear processing instructions for different key > >>>>>> > >>>>>>>>>> establishment modalities > >>>>>> > >>>>>>>>>> -- Lack of clear typing of objects > >>>>>> > >>>>>>>>>> -- Lack of versioning for future extensibility > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Looking at the current specs, it didn't seem to me that it=20 > >>>>>>>>>> would be > >>>>> simple to adapt them to address these deficiencies. So I just=20 > >>>>> did a > >>>> re-write. > >>>>> If you think they can be addressed within the current framework,=20 > >>>>> please explain. I just found it simpler to start from whole cloth. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Cheers, > >>>>>> > >>>>>>>>>> --Richard > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>>> Hi Richard, > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE > >>>> documents, > >>>>> I encourage you to ask about them on the list. The documents=20 > >>>>> have significant history going back to mid-2010 when convergence=20 > >>>>> discussions started among people with four different JSON=20 > >>>>> signing & encryption proposals. JWT and the current JOSE specs=20 > >>>>> and implementations are the result. I realize that not all the=20 > >>>>> JOSE participants were part of those discussions from the=20 > >>>>> beginning (although many were) and so teasing out the rationale=20 > >>>>> for specific decisions might help people better understand the=20 > >>>>> choices made, and hopefully thereby increase consensus behind=20 > >>>>> the eventual > working group choices. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> If the list that you're puzzled by is the bulleted list=20 > >>>>>>>>>>> below, > >>>> maybe we > >>>>> can start a discussion on that basis. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Best wishes, > >>>>>> > >>>>>>>>>>> -- Mike > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>> > >>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org]=20 > >>>>>>>>>>> On > >>>>>> > >>>>>>>>>>> Behalf Of Richard L. Barnes > >>>>>> > >>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM > >>>>>> > >>>>>>>>>>> To: jose@ietf.org > >>>>>> > >>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for > >>>>>> > >>>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Dear JOSE WG, > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a=20 > >>>>>>>>>>> thorough > >>>>> review of the JW* specs, I was kind of puzzled by some of the=20 > >>>>> design decisions. So I also went through and wrote an=20 > >>>>> alternative format, this > >>>> time > >>>>> taking a more of a cue from CMS. A link to the document is below. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Summary of differences: > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the > header > >>>>>> > >>>>>>>>>>> parameters are represented in JSON. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS allows for full algorithm agility in key=20 > >>>>>>>>>>> agreement, while > >>>> JWE > >>>>>> > >>>>>>>>>>> only allows ECDH-ES. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and > >>>>>> > >>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple > >>>>> WrappedKey > >>>>>> > >>>>>>>>>>> objects. Sending a JWE to multiple recipients requires=20 > >>>>>>>>>>> re- > >>>>>> > >>>>>>>>>>> encryption of the entire object for each recipient. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o The signature and MAC functions of the JWS object are=20 > >>>>>>>>>>> separated > >>>>>> > >>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS parameters are not integrity-protected, as they=20 > >>>>>>>>>>> are in JWE > >>>>>> > >>>>>>>>>>> and JWS. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS,=20 > >>>>>>>>>>> but > >>>> could > >>>>>> > >>>>>>>>>>> be added without significant change. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown > header > >>>>>> > >>>>>>>>>>> parameters, in order to facilitate extensibility. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> I've also thrown together an initial JavaScript=20 > >>>>>>>>>>> implementation > >>>> (based > >>>>> on NodeJS for some python crypto glue), which is on github: > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Comments are very welcome. > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Thanks, > >>>>>> > >>>>>>>>>>> --Richard > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> Begin forwarded message: > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> From: internet-drafts@ietf.org > >>>>>> > >>>>>>>>>>>> Subject: New Version Notification for > >>>>>> > >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt > >>>>>> > >>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT > >>>>>> > >>>>>>>>>>>> To: rbarnes@bbn.com > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has=20 > >>>>>>>>>>>> been > >>>>>> > >>>>>>>>>>>> successfully submitted by Richard Barnes and posted to=20 > >>>>>>>>>>>> the IETF > >>>>>> > >>>>>>>>>>>> repository. > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> Filename: draft-barnes-jose-jsms > >>>>>> > >>>>>>>>>>>> Revision: 00 > >>>>>> > >>>>>>>>>>>> Title: JavaScript Message Security Forma= t > >>>>>> > >>>>>>>>>>>> Creation date: 2012-06-15 > >>>>>> > >>>>>>>>>>>> WG ID: Individual Submission > >>>>>> > >>>>>>>>>>>> Number of pages: 25 > >>>>>> > >>>>>>>>>>>> URL: > >>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- > >>>>> jsms-00.txt > >>>>>> > >>>>>>>>>>>> Status: > >>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms > >>>>>> > >>>>>>>>>>>> Htmlized: > >>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> Abstract: > >>>>>> > >>>>>>>>>>>> Many applications require the ability to send=20 > >>>>>>>>>>>> cryptographically > >>>>>> > >>>>>>>>>>>> secured messages. While the IETF has defined a number of > >>>>> formats > >>>>>> > >>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings=20 > >>>>>>>>>>>> which > >>>>>> > >>>>>>>>>>>> are not easy to use in modern applications. This=20 > >>>>>>>>>>>> document > >>>>>> > >>>>>>>>>>>> describes the JavaScript Message Security format (JSMS),=20 > >>>>>>>>>>>> a new > >>>>>> > >>>>>>>>>>>> cryptographic message format which is based on JavaScript=20 > >>>>>>>>>>>> Object > >>>>>> > >>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to > >>>> generate > >>>>> and parse. > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>> The IETF Secretariat > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>> jose mailing list > >>>>>> > >>>>>>>>> jose@ietf.org > >>>>>> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> jose mailing list > >>>>>> jose@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nat Sakimura (=3Dnat) > >>>>>> Chairman, OpenID Foundation > >>>>>> http://nat.sakimura.org/ > >>>>>> @_nat_en > >>>>>> > >>>>>> _______________________________________________ > >>>>>> jose mailing list > >>>>>> jose@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/jose > >>>>> > >>>>> _______________________________________________ > >>>>> jose mailing list > >>>>> jose@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/jose > >>>> > >>>> _______________________________________________ > >>>> jose mailing list > >>>> jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > > > > > > >=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Tue Jun 26 15:48: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 0D20521F8541 for ; Tue, 26 Jun 2012 15:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNwk9UyLvemu for ; Tue, 26 Jun 2012 15:48:50 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 114BF21F8540 for ; Tue, 26 Jun 2012 15:48:50 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B354738F1A; Tue, 26 Jun 2012 15:48:49 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" , "'Mike Jones'" References: <4E1F6AAD24975D4BA5B168042967394366569B1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <57BD4255-754D-4B6D-A194-587243FF17F3@bbn.com> In-Reply-To: <57BD4255-754D-4B6D-A194-587243FF17F3@bbn.com> Date: Tue, 26 Jun 2012 15:47:33 -0700 Message-ID: <00f601cd53ed$ad6eb280$084c1780$@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: AQHc1C9jZYBSr/kVHweqCOWz9dpmpAKDY/+TltoXRUA= Content-Language: en-us Cc: 'John Bradley' , 'Brian Campbell' , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:48:51 -0000 Note that with my proposal this is somewhat easier. Also given that we are dealing with garbage collection systems it is likely that this data has not yet disappeared from memory anyway as long as it is referenced. The header information is not going to be megabytes in size and all of that processing on the headers can be done before you hash and decode the body. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Tuesday, June 26, 2012 3:21 PM > To: Mike Jones > Cc: John Bradley; Brian Campbell; jose@ietf.org > Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms- > 00.txt > > Sure, multiple signature is easier than multiple recipients. But I wouldn't call > it simple. I have to base64url-decode each header to figure out which one to > use (but keep around the encoded version, so I can verify the signature), > keep track of the corresponding signature value, and reconstruct the signed > body -- all before I can do the actual signature verification. > > OTOH, without integrity-protection, you can just have the signature beside > all the other parameters, in plain JSON, so that you can just grab stuff and go. > > From : > > verify: function(object) { > var jsms = JSON.parse(object); > if (!_JOSE_Support.isSignedData(jsms)) { > throw "Invalid SignedData object"; > } > > // Figure out which signatures are valid > var validPublicKeys = []; > var sigs = jsms.signatures; > for (var i=0; i var result = _JOSE_Crypto.verify_pkcs1_sha256( > sigs[i].key.n, sigs[i].key.e, jsms.content, sigs[i].signature) > if (result = "True") { > validPublicKeys.push(sigs[i].key); > } > } > > return validPublicKeys; > } > > > > > On Jun 26, 2012, at 6:03 PM, Mike Jones wrote: > > > http://tools.ietf.org/html/draft-jones-json-web-signature-json- > serialization-01 is an existence proof that it's not hard to sign the parameters > and have multiple signatures. > > > > -- Mike > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of Richard L. Barnes > > Sent: Tuesday, June 26, 2012 10:46 AM > > To: Brian Campbell > > Cc: John Bradley; jose@ietf.org > > Subject: Re: [jose] New Version Notification for > > draft-barnes-jose-jsms-00.txt > > > > I agree with that goal! I disagree that JWS is a good solution. > > > > It is true that JWS provides a relatively simple mechanism for a single > signature, but: > > 1. It could be simpler (see below) > > 2. JWS header protection is useless for the single-signature case, and > > makes the multiple-signature/recipient case harder > > > > --Richard > > > > > > > > On Jun 26, 2012, at 12:16 PM, Brian Campbell wrote: > > > >> I wasn't suggesting that integrity-protecting the header itself makes > >> things simpler. Rather that a desirable goal is for support of a > >> relatively simple model utilizing a single signature over the whole > >> message. And that we already have that in JWS. > >> > >> On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes > wrote: > >>> > >>> On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: > >>> > >>>>>> I think part of this is that as one of the openID Connect authors I look > at this as a necessary security token format, for OAuth and Connect. > >>>>>> For that simple processing with one signature is a high priority for > adoption. > >>>>> > >>>>> +1. > >>>>> > >>>>> A simple JSON friendly model supporting a single signature over > >>>>> the entire message (including headers) is an important case for > >>>>> adoption (and security). JWS provides that now and there are > >>>>> already numerous interoperable JWS implementations available or in > the works. > >>>> > >>>> I'm not sure how people think that integrity-protecting the header > makes things *simpler*, especially since it adds a whole new decoding step > and makes the parsing more complicated. > >>>> > >>>> Pseudocode without integrity protection (assuming JSMS format, but > JWS could be made to look similar): > >>>> function verify(json) { > >>>> jose = JSON.parse(json); > >>>> // Check algorithm values > >>>> return Crypto.SignatureAlgorithm.verify(jose.content, > >>>> jose.keys[0].signature, jose.keys[0].key); } > >>>> > >>>> Pseudocode with integrity protection (assuming JWS format): > >>>> function verify(jws) { > >>>> (txtHeader, content, signature) = jws.split("\."); > >>>> protectedBody = header + "." + content > >>>> jsonHeader = base64url.decode(txtHeader); > >>>> header = JSON.parse(jsonHeader); > >>>> return Crypto.SignatureAlgorithm.verify(content, signature, > >>>> header.jwk); } > >>>> > >>> > >>> Err, sorry, that should read: > >>> protectedBody = txtHeader + "." + content; and > >>> return Crypto.SignatureAlgorithm.verify(protectedBody, signature, > >>> header.jwk); > >>> > >>> See how hard it is to get right? :) > >>> > >>> --Richard > >> _______________________________________________ > >> 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 From ve7jtb@ve7jtb.com Tue Jun 26 15:51:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D734521F8546 for ; Tue, 26 Jun 2012 15:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCz8yJ5eMN4P for ; Tue, 26 Jun 2012 15:51:03 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90E6A21F8540 for ; Tue, 26 Jun 2012 15:51:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so495477ghb.31 for ; Tue, 26 Jun 2012 15:51:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=NjnJ/DS5JK/n/KupDED+VAY2oegmtkFFJQ3geXG+P38=; b=f1vDh6IAfnkDdf32UwnwXshRQRVc3v8Og/IcklYSFNhtRW9/IpHjt6B1wZOnCArbGG IDnQRDENAEoTEhbG4/0uGIsO5vX2k5HmFn29MFHzjY5BY4P2TV5xHspq3B21sJZPipgK uHuhvEEqwp/gc0bwV821CoO0B8ok0H9hx5tU0DK38ZucvGaKyArv3VSGHJyQOmlA9c7O LvMa+qjvDvekhJPs+n9ciBUlxGeQsI5QI20nDOffTOxeRbNtW8lt47WtCuwME2cslIdS P2kvY/KZM6slXtxkmG4Vw2+HNSTpMXKX5Gp/2hPSiXQ7HidJ/+i5sryT3rjOrEKW1/EN FxBQ== Received: by 10.236.77.74 with SMTP id c50mr19957215yhe.112.1340751062930; Tue, 26 Jun 2012 15:51:02 -0700 (PDT) Received: from [192.168.1.213] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id z9sm143174422yhl.6.2012.06.26.15.50.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 15:51:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_3D7BC36E-CBD6-41D0-8907-071424EA45A9"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <00e401cd53ec$09b979f0$1d2c6dd0$@augustcellars.com> Date: Tue, 26 Jun 2012 18:50:54 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <00e401cd53ec$09b979f0$1d2c6dd0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkzGto6pJGTeJYPDSO5Elee19C2pL+0wcF7MYvUPvcrjKL42z2vZWV6h7HHV66VtIF2/0DD Cc: "'Richard L. Barnes'" , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:51:08 -0000 --Apple-Mail=_3D7BC36E-CBD6-41D0-8907-071424EA45A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry, I meant Authenticated Encryption from your earlier email to the = list. >=20 > The AEAD algorithm class is called Authenticated encryption with = additional > data. This is the term for the art. Note that this does not imply = sender > origination which is the additional service one wants signatures for. = There > is a debate if you get sender origination even with static-static key > agreement. I was not trying to imply identification of the sender. Though debate or not, people use HMAC with symmetric keys to infer = sender, I suspect that they will do the same with AEAD or CBC+HMAC. That argues for equivalent integrity protection of the header in = encryption as signing, to my mind. Sorry I got the term wrong. John B. On 2012-06-26, at 6:35 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Tuesday, June 26, 2012 12:30 PM >> To: Richard L. Barnes >> Cc: Jim Schaad; jose@ietf.org >> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >> 00.txt >>=20 >> There was a WG decision to not allow encryption without integrity. = Jim > and >> others call that sender verification. >=20 > Jim would not call that sender verification. Jim would call that = integrity > protection on the transmitted content. There is no concept of data > origination with any type of AE algorithm. >=20 >=20 >>=20 >> Or on simple terms no AES-CBC without a mandatory MAC integrity. >>=20 >> The JWE/JWS specs don't control the body. That is intended to be > arbitrary >> content. >>=20 >> We do have s JWT spec that covers the body for security tokens. The = idea >> was to separate that from signing and encryption so that signing and >> encryption can be used for other objects. >>=20 >> John B. >>=20 >> On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote: >>=20 >>>> Now that we are mandating JWE sender verification people will be = using >> JWE with symmetric keys or key agreement. >>>> In those cases one can easily argue that the header should be = protected >> as much as in HMAC. >>>=20 >>> Can you clarify the scope of "we are mandating"? >>>=20 >>>=20 >>>> There may well be signing_time or other elements that would go into = the >> header as well for JWE. >>>=20 >>> Why do these need to go into the header rather than the body? >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>> Regards >>>> John B. >>>>=20 >>>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote: >>>>=20 >>>>> >>>>>=20 >>>>> Richard, >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >> Behalf Of >>>>>> Richard L. Barnes >>>>>> Sent: Monday, June 25, 2012 2:35 PM >>>>>> To: Nat Sakimura >>>>>> Cc: Mike Jones; jose@ietf.org >>>>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose- >> jsms- >>>>>> 00.txt >>>>>>=20 >>>>>> Hi Nat, >>>>>>=20 >>>>>> I'm not sure what X.509 fiasco you're referring to. There was a > recent >>>>> MD5 >>>>>> fiasco [1], but that's an attack on MD5, not X.509. In fact, = there > have >>>>> been >>>>>> recommendations for preventing this attack in X.509 since 2005 = [2]. > As >>>>> was >>>>>> noted on the SAAG list, the real news here is that Microsoft = wasn't >>>>> following >>>>>> any of those recommendations. >>>>>>=20 >>>>>> JWS would have had the same problem as X.509. The attack did not >> modify >>>>>> the cryptographic parameters (anything that would have gone in = the >>>>>> header), it would not have been thwarted by the integrity = protection >> we're >>>>>> worrying about. >>>>>>=20 >>>>>> Actually, the header signing that JWS does makes it even nicer = for > the >>>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS > header >>>>> value >>>>>> is entirely static for a given signer, it's easy to use as a = fixed > prefix. >>>>> If JWS just >>>>>> signed the content, then the application could include a = something >> random >>>>>> up front to prevent such prefix-based attacks. >>>>>>=20 >>>>>=20 >>>>> I don't believe that this is a true statement. If you had a = prefix or > just >>>>> signed what was given to you (i.e. no prefix), it would make no >> difference >>>>> in terms of the attack for Flame. Flame could always use a fixed > prefix of >>>>> its own design rather than using the fixed header that is = generated by >>>>> having JWS sign the header information. >>>>>=20 >>>>>> It's tempting to say that we should just add randomness to the = JOSE >>>>> format. >>>>>> But the real lesson of the Flame/MD5 attacks is operational: If > you're >>>>> signing >>>>>> something that somebody else gave you, make sure that you're not >> signing >>>>>> exactly what they gave you. Follow the recommendations of RFC = 4270. >> In >>>>>> other contexts, there's no need of similar random elements; it = just >> adds >>>>>> complexity. >>>>>=20 >>>>> This is definitely a true statement in all events and is something > that >>>>> should be added to the Security Considerations section. >>>>>=20 >>>>> That being said, I think that there are valid reasons for wanting = to > protect >>>>> the header information by some authentication processing. PKIX >> certificates >>>>> protect the signature algorithm information (by copying the data = into > the >> to >>>>> be signed block) and CMS has long allowed for information to be >> included in >>>>> the signed attributes area that identifies the algorithms used, = the >>>>> certificates used and so forth. There are also other things that = we > might >>>>> find to be convenient to be placed in the header information that = is >> current >>>>> not there (a signing time and embedded content type comes to mind) >> that >>>>> would be a product either of specific types of signatures or = becomes a >>>>> common attribute to be placed there. >>>>>=20 >>>>> In terms of encryption operations, I remember in the past that I = have >> had >>>>> either corrupted encrypted streams or corrupted IVs and had a >> successful >>>>> decryption that later generated other problems when trying to = parse. >> This >>>>> is less of an issue with AEAD algorithms as they have a much = stricter > rule >>>>> on when the stream decrypts correctly. >>>>>=20 >>>>> Jim >>>>>=20 >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> [1] = >>>>>> [2] >>>>>>=20 >>>>>>=20 >>>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote: >>>>>>=20 >>>>>>> Especially after the X.509 fiasco, I strongly believe that = having >>>>> integrity >>>>>> check over the metadata is a good thing. It is such a little = effort > that >>>>> gives us >>>>>> much more protection down the road. In this sense, I fully agree = with >> Ben >>>>>> here. We should have integrity protection over the header. >>>>>>>=20 >>>>>>> Nat >>>>>>>=20 >>>>>>> On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones >>>>>> wrote: >>>>>>> Two years ago when the developer community needing a JSON- >> friendly >>>>>> token format was designing the JSON Web Token (JWT), we = explicitly >> asked >>>>>> security experts whether the header parameters should be = integrity >>>>>> protected or not. Among them, Ben Laurie was one of the voices >> saying >>>>> that >>>>>> securing them was the right thing to do. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> He argued that if the parameters can be protected in a practical >> manner, >>>>>> then they should. Doing so provides an additional hurdle that > attackers >>>>>> would have to surmount. For example, if they can try to = substitute a >>>>> weaker >>>>>> authentication scheme, then they must figure out how to make it >>>>>> authenticate correctly despite some plaintext they can't control = - > the >>>>> header >>>>>> parameters. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Ben also took the position that paring security protocols down = to > the >>>>> least >>>>>> you can get away with, given attacks you can think of, is not a = good >>>>> design >>>>>> principle. If there is not a strong argument against including a > feature >>>>> that >>>>>> may make it harder for attackers, then that feature should be > included. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I agree with him. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The decision to provide integrity protection for the headers is >>>>> documented >>>>>> in the session notes at http://self-issued.info/?p=3D361, which = said: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> . What to sign (envelope.payload or just payload)? >>>>>>>=20 >>>>>>> Given that the envelope is extensible and therefore may contain >>>>> security- >>>>>> sensitive information, we reached a consensus (with input from = Ben >> Laurie >>>>>> via IM) that the combination envelope.payload must be signed. >>>>>>>=20 >>>>>>>=20 >>>>>>> I believe that logic is as sound today as it was then. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> For all these reasons, I therefore personally stand by the > community's >>>>>> decision to provide integrity protection for the headers. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Best > wishes, >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >> Behalf Of >>>>>> John Bradley >>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM >>>>>>> To: Richard L.Barnes >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] New Version Notification for = draft-barnes-jose- >> jsms- >>>>>> 00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Richard, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> While for PKCS 1.5 the hash algorithm is baked into the padding = and >> not >>>>>> susceptible to modification with ECDH or RSA-PSS it is not. >>>>>>>=20 >>>>>>> There are possible hash truncation attacks by shortening SHA256 = to >>>>> SHA224 >>>>>> as an example (I know we preclude truncated hashes at the = moment). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The bad feeling I get around this is that if there is a scenario > where >>>>> the >>>>>> attacker controls the plaintext to be signed and there is no = signer >>>>> controlled >>>>>> text contributed there are potential bad things that could happen >> down the >>>>>> road. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> This bit us with x509 certs not that long ago (yes with MD5 > admittedly) >>>>>> where the attacker could use a certificate extension to include = extra >> data >>>>> and >>>>>> cause a pre collided hash to be generated. >>>>>>>=20 >>>>>>> Having part of the signed data outside the control of an = attacker is > a >>>>> good >>>>>> thing. (having a nonce or message ID in the envelope is possible >> though >>>>> not >>>>>> yet required in JWS.) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I am still of the opinion that putting the base64 encoded = envelope >>>>> inside >>>>>> the hash calculation is a valid way to allow additional = attributes. >>>>>>>=20 >>>>>>> Another structure to hold the attributes adds more complexity, = as >> would >>>>>> saying that they need to be inside the signed object. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I think part of this is that as one of the openID Connect = authors I > look >>>>> at this >>>>>> as a necessary security token format, for OAuth and Connect. >>>>>>>=20 >>>>>>> For that simple processing with one signature is a high priority = for >>>>> adoption. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =46rom a general signing/encrypting of documents point of view = you >>>>>> legitimately have different priorities. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I know it is hard to prove a negative but It is also going to be >>>>> difficult for me >>>>>> to go back to security people at google Facebook and other places = and >>>>>> explain how not integrity protecting the header could be better = than >>>>>> integrity protecting it. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> It seems that I would be reduced to arguing that this is no = worse > than >>>>> CMS >>>>>> and that hasn't been proven insecure yet. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Allowing a possible attacker to control the hash output, and not >>>>> integrity >>>>>> protecting the additional data, seems like something I am bound = to >> regret >>>>> in >>>>>> the future. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Hey John, >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> Interesting points, but I don't think they actually apply here. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to downgrade attacks: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> The attack that RFC 5752 is concerned with is when an attacker > strips >>>>>> signatures from a signed message, so that the only ones left are = ones >> he >>>>> can >>>>>> tamper with. So the integrity protection here is "horizontal"; = it > goes >>>>> across >>>>>> signatures. The integrity protection in JWS/JWE is "vertical" -- = it > only >>>>> protects >>>>>> one signer's parameters -- so it is, so to speak, orthogonal. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to "brown bag" attacks: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> The root of this attack is ambiguity about what content is = *signed* >>>>>>>=20 >>>>>>>> vs. what content is *used*. If an application doesn't verify = that >>>>>>>=20 >>>>>>>> it's actually using the stuff that's signed, then it can be = tricked >>>>>>>=20 >>>>>>>> into accepting something unsigned. (Cf. >>>>>>>=20 >>>>>>>> ) >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> However, I don't think any of the current proposals have that >> problem. >>>>>> In JWE/JWS, the signed content is right there between the dots, = and > in >>>>> JSMS, >>>>>> it's in the "content" element. The current JSMS draft does allow >> detached >>>>>> signatures, but with a "voids your warranty" sticker on it. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> In any case, these attacks have nothing to do with whether the >>>>>> cryptographic parameters are integrity-protected with the = content. >> The >>>>>> example attacks in the IBM still work regardless -- the whole = point > of >> the >>>>>> attack is that the cryptographic processing is the same, only the >>>>> (non-crypto) >>>>>> matching of content is flawed. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to "arbitrary attributes": >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> We can have that here, too, but you need canonicalization. And >>>>> base64- >>>>>> encoding is not not canonicalization -- it just waves its hands = over > the >>>>>> question of equivalence. In my opinion, we should keep the >> cryptographic >>>>>> object simple by disallowing attributes, and push the attributes = you >> would >>>>>> sign inside of the thing being signed. If people really do want >>>>> attributes, it >>>>>> doesn't seem to me like JSON canonicalization is very hard. I = can do > it >>>>> in 19 >>>>>> lines of python: >>>>>>>=20 >>>>>>>> >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard too "meta-data in the body": >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> It seems to me like if we're trying to define a general format = for >>>>> applying >>>>>> security protections, then we ought to keep out things that = aren't >>>>> strictly >>>>>> security relevant. Those things can go in application-specific > content >>>>> types >>>>>> (e.g., SAML) without polluting the general purpose header. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> With regard to "defense in depth" and selling this to = government >>>>>> agencies: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> CMS, via S/MIME, is in broad use across multiple federal = agencies >> and >>>>>> large enterprises. JSMS is essentially a profile of CMS (see = Section > 7), >>>>> and >>>>>> has the same security properties. >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> Cheers, >>>>>>>=20 >>>>>>>> --Richard >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> On Jun 19, 2012, at 5:10 PM, John Bradley wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Hi Richard, >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Originally we only integrity protected the header for signing. = We >>>>> added >>>>>> the integrity protection to encryption as part of AEAD, as = encryption >> can >>>>> also >>>>>> be used for sender verification. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I understand the argument that it makes things simpler if we = don't >>>>>> integrity protect the header information. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> However xmldsig, provides integrity over those elements to >> prevent >>>>>> possible downgrade attacks by manipulating the algorithms. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> CMS may not typically provide that integrity protection but I > think >>>>> Jim >>>>>> Schaad and Sean Terner created RFC5752 to address downgrade >> attacks. >>>>>>>=20 >>>>>>>>> Given they are on this list they can speak to their view on > integrity >>>>> over >>>>>> the crypto parameters. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I also recall when working on InfoCards there was a Monte >> Carlo/Brown >>>>>> Bag attack that needs to be considered if we move to something = more >> like a >>>>>> detached signature. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> The other design consideration is that we wanted to be able to > sign >>>>>> arbitrary byte strings not just JSON. You could sign XML if you > wanted. >>>>>>>=20 >>>>>>>>> That prevented us from including meta-data in the body as we >> didn't >>>>>> want to touch it. That left us with the header to include > additional >>>>> elements >>>>>> in. >>>>>>>=20 >>>>>>>>> Not integrity protecting those elements as well would be a >> problem. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I am not a CMS expert but I believe it allows for signing of >>>>> arbitrary >>>>>> attributes not unlike the current JOSE spec. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Especially for something that will be used with JWT security > tokens I >>>>> will >>>>>> have a hard time making the argument to NIST and others that need = to >>>>>> approve this format that not integrity protecting the header >> parameters is >>>>>> appropriate defence in depth, for something that might be = replacing >> signed >>>>>> SAML assertions in some applications. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> I do understand how not integrity protecting the header will = make >>>>> some >>>>>> things easier, however I can't agree that the benefit outweighs = the >>>>>> disadvantages. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> Regards >>>>>>>=20 >>>>>>>>> John B. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote: >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Hey Mike, >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Thanks for having some back-and-forth with me on this. I = think >> this >>>>> is a >>>>>> good discussion to have right now. I would like to discuss some >>>>> high-level >>>>>> points, and then I'll respond inline to your precise points. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> tl;dr: In order to meet its deliverables, the WG needs to = define >>>>> JSON- >>>>>> based formats for integrity and confidentiality protections. JWE = and >> JWS >>>>>> don't fit that requirement, so we should re-consider their = adoption > and >>>>> call >>>>>> for new candidates. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Major points: >>>>>>>=20 >>>>>>>>>> 1. JOSE is JSON >>>>>>>=20 >>>>>>>>>> 2. JSON does not imply canonicalization 3. Compactness and >>>>>>>=20 >>>>>>>>>> URL-safeness are still OK, as derivatives >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Part 1: JOSE is JSON >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> The JOSE WG charter calls out four deliverables, three of = which >> are >>>>>> explicitly required to be JSON: >>>>>>>=20 >>>>>>>>>> -- "JSON-structured integrity protection" >>>>>>>=20 >>>>>>>>>> -- "JSON-structured encryption" >>>>>>>=20 >>>>>>>>>> -- "public keys as JSON-structured objects" >>>>>>>=20 >>>>>>>>>> (The fourth is just a list of algorithms, which should be = JSON as >>>>>>>=20 >>>>>>>>>> well, just as RFC 3370 is ASN.1.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> In light of these requirements, JWE and JWS are clearly not >> suitable >>>>>>>=20 >>>>>>>>>> candidates to fulfill the working group's milestones. (At = least > in >>>>>>>=20 >>>>>>>>>> their current form.) So ISTM that we need to step back and >>>>>>>=20 >>>>>>>>>> re-evaluate alternatives for the three above milestones, >> especially >>>>>>>=20 >>>>>>>>>> the first two. (JWK is not as far off.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> As JSON-based mechanisms, though, the "JSON serialization" >> drafts >>>>>> are pretty half-hearted. Because JWS and JWE include the >> cryptographic >>>>>> parameters within the integrity protection, they have to have the >> headers >>>>>> included as base64-encoded strings. That obviously adds a lot of >>>>> complexity >>>>>> to encoding and decoding -- for example, you have to keep the >> encoded >>>>>> header around even after you've decoded it! -- and just plain = more >> octets. >>>>>> The support for multiple recipients and multiple signatures is = both >>>>> unweildy >>>>>> (matching up parallel indices for headers and signatures) and > inefficient >>>>>> (multiple integrity check values in encrypted objects). >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> By contrast, JSMS takes advantage of the cryptographic wisdom >> that >>>>>> went into CMS, while making the syntax pure JSON and as simple as >>>>> possible. >>>>>> Multiple signatures and multiple recipients are supported with > absolute >>>>>> minimum overhead. So I think it's worth consideration by the = working >>>>> group. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Part 2: JSON !=3D> canonicalization >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I would like to dispel the myth that a JSON-based format = requires >>>>>>>=20 >>>>>>>>>> canonicalization. In JWE/JWS, the JSON header requires >>>>>>>=20 >>>>>>>>>> "canonicalization" (via base64url encoding) because it's = included >>>>>>>=20 >>>>>>>>>> within the integrity protection. I'm not aware of any reason = for >>>>>>>=20 >>>>>>>>>> including the cryptographic parameters in the integrity = check, >>>>>>>=20 >>>>>>>>>> instead of only integrity-protecting the content itself. = Indeed, > if >>>>>>>=20 >>>>>>>>>> there were an attack based on non-integrity-protected >> cryptographic >>>>>>>=20 >>>>>>>>>> parameters, it would be a pretty big deal, since neither CMS = nor >> IKE >>>>>>>=20 >>>>>>>>>> nor provides this protection. (TLS does provide a signature = over >>>>>>>=20 >>>>>>>>>> the algorithms, but only as a way to bind the public key to = the >>>>>>>=20 >>>>>>>>>> session.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Indeed CMS doesn't require canonicalization at all, except = for >>>>>> attributes that are included in the protected content = (signedAttrs / >>>>>> authenticatedAttrs), which need to be DER-encoded. In JSMS, we >> don't >>>>>> allow those parameters, so there is no need for canonicalization = at > all. >>>>> All the >>>>>> "canonicalization" that's needed is to base64url-encode the = protected >>>>>> content. In that regard, JSMS is even simpler than JWE/JWS. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Part 3: Compactness and URL-safeness are still OK, as = derivatives >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I have absolutely no objection to defining a compact, = URL-safe >>>>> format. >>>>>> Indeed, I did so in the JSMS draft, in Section 5. Encoding the > example >>>>> from >>>>>> Section 3.1 of the JWS spec, we get the following JSMS object: >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> { >>>>>>>=20 >>>>>>>>>> "v":1, >>>>>>>=20 >>>>>>>>>> "t":"au", >>>>>>>=20 >>>>>>>>>> "a":"hs256", >>>>>>>=20 >>>>>>>>>> "c":"eyJpc3MiOiJqb2...0cnVlfQ", >>>>>>>=20 >>>>>>>>>> "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo", >>>>>>>=20 >>>>>>>>>> "ki":"rSIilRk8Ego" >>>>>>>=20 >>>>>>>>>> } >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> If we remove the decorative spaces and base64url-encode, we >> only >>>>>> use >>>>>>>=20 >>>>>>>>>> 88 octets more than JWS (267 vs. 179). If we take this a = step >>>>>>>=20 >>>>>>>>>> further and define an explicit compact format for >> AuthenticatedData, >>>>>>>=20 >>>>>>>>>> we can emulate JWS by moving the content and MAC fields >> outside >>>>>> and >>>>>>>=20 >>>>>>>>>> dot-combining. That avoids double-base64url-encoding, and = only >>>>>>>=20 >>>>>>>>>> takes up 11 more octets than a JWS (190 vs 179). (I've put = the >> code >>>>>>>=20 >>>>>>>>>> to generate these in the Github project linked earlier.) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> So it's fine to have a compact, URL-safe format for an = objective, >>>>> but it >>>>>> makes *much* more sense to derive that from a full-size, usable, = JSON >>>>>> format than the other way around. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Responses to specific points inline below. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Fair enough. I'll briefly respond to each in turn. Before > doing >>>>> so, I'll >>>>>> say that I'm writing in the spirit of trying to increase mutual >>>>> understanding >>>>>> and consensus, rather than taking the point of view that the = status > quo >> is >>>>> the >>>>>> only reasonable outcome. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Not being JSON >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> This was by design, so that the results are URL-safe. This = is >>>>> required, >>>>>> for instance, for them to be used as OAuth Bearer Tokens. At the >> request >>>>> of >>>>>> the working group, closely related pure-JSON drafts were also >> published. >>>>>> See: >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> = http://tools.ietf.org/html/draft-jones-json-web-signature-json- >> seri >>>>>>>=20 >>>>>>>>>>> alization-01 and >>>>>>>=20 >>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption- >> json-ser >>>>>>>=20 >>>>>>>>>>> ialization-01 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Use them if you prefer if they better suit your use cases. = They >>>>> could >>>>>> be adopted as working group documents, if there's interest. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> See above. These are super-clunky, and the need to be the = main >>>>>> focus of the WG, not an afterthought. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> The JSON serialization drafts above do, again, in response = to > use >>>>>> cases presented by the working group. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> See above. Because of the unnecessary inclusion of the = header in >>>>> the >>>>>> integrity check, this is far less efficient than it should be. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Functionally, these are very similar operations, at least = from > an >>>>>> implementation perspective, so it's not clear that making a clear >>>>> distinction >>>>>> would help either developers or adoption in any practical way. = They >>>>> achieve >>>>>> overlapping, but admittedly sometimes different goals. I believe > that >>>>>> developers can be trusted to use the algorithms that achieve = their >>>>>> applications' goals without making a hard distinction between the > two. >>>>> But >>>>>> I'd be interested in hearing your thoughts on why you believe a >>>>> brighter-line >>>>>> distinction might be useful or necessary. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> It's important if you want to do MACs with anything other = than >> pre- >>>>>> shared keys. If you want to do anything more advanced, you need = to >> have >>>>>> wrapped keys, in which case an object with a MAC starts to look a = lot >> more >>>>>> like a JWE than a JWS. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>=20 >>>>>>>>>>> establishment modalities >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> This seems like an area where the existing drafts could be >> refined >>>>> to >>>>>> add descriptions for additional establishment modalities, = possibly >> based >>>>>> upon your ideas and descriptions, should the working group decide = to >> do >>>>> so. >>>>>> What additional modalities do you have use cases for that you = believe >> are >>>>>> not achievable or straightforward with the existing drafts? The > existing >>>>>> modalities supported are largely those that existing developers = had >> told >>>>> us >>>>>> they needed and draw both from the precursor = draft-jones-json-web- >> * >>>>>> documents and draft-rescorla-jsms. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Bear in mind that the balance that the current drafts try to > strike >>>>> is >>>>>> keeping the Mandatory to Implement (MTI) feature footprint small >> enough >>>>>> that developers, including Web developers, are likely to adopt = the >> specs, >>>>>> while still providing enough functionality to make them generally >> useful. >>>>> As >>>>>> in any balance, it's often possible to shift things a bit and = still >>>>> maintain the >>>>>> balance, but I'd like people to keep the ubiquitous adoption goal >>>>> front-and- >>>>>> center when proposing additional functionality. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Ubiquitous deployment and usefulness trump theoretical >>>>>>>=20 >>>>>>>>>>> completeness. (Just look at XMLDSIG and XMLENC to >> understand >>>>>>>=20 >>>>>>>>>>> that!) >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I agree that we need to find a reasonable MTI. The current = JSMS >>>>> draft >>>>>> doesn't really specify which parts are MTI, beyond basic things = like >>>>> base64url >>>>>> encoding and ignoring unknown fields. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> My main concern is that JWS and JWE don't really tell me = which >>>>> fields >>>>>> need to be present for which use case. If I'm putting a MAC on a = JWS >> vs. >>>>> a >>>>>> signature, do I need "jwk" or "jku" fields to be populated? = Whereas > in >>>>> JSMS, >>>>>> I think these things are much clearer due to the separation of = the > use >>>>> cases >>>>>> (Signed/Authenticated/Encrypted) and the isolation of signatures = and >>>>>> wrapped keys into sub-objects. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Most JSON documents aren't clearly typed; instead, = developers >> and >>>>>> implementations understand from context what the meaning of each >> field is. >>>>>> XML is clearly typed, but developers are voting with their feet = by >> moving >>>>> to >>>>>> JSON. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> What practical advantages resulting from overlaying a typing >>>>>> infrastructure on JSON do you believe are worth the potential = costs > of >>>>> doing >>>>>> so? BTW, I'm not opposed to having a JSON schema description of = the >> JOSE >>>>>> JSON data structures like JSMS did in > http://tools.ietf.org/html/draft- >>>>>> rescorla-jsms-00#appendix-A, but I'll remark that this an = informative >>>>> tool, not >>>>>> a normative one. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> I actualy don't have a hugely urgent requirement here either. > It's >>>>>> something that others in the WG had requested, which is trivial = to > add >> in >>>>>> JSMS, but not in JWE/JWS -- again because of the unnecessary > integrity >>>>>> protection of the header. >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> An optional version field could be added if the working = group >>>>>>>=20 >>>>>>>>>>> desires, however the last time the working group discussed = it, >> they >>>>>>>=20 >>>>>>>>>>> decided not to do so. Rather, specs like this effectively > become >>>>>>>=20 >>>>>>>>>>> "versioned" when revised in a way that new fields are added. = If >>>>>>>=20 >>>>>>>>>>> you understand the new fields, you support that new version. >> (Note >>>>>>>=20 >>>>>>>>>>> that this is independent of whether there is a version = number >>>>>>>=20 >>>>>>>>>>> field, which according to some participants in the previous >>>>>>>=20 >>>>>>>>>>> discussion, they regarded as therefore being redundant >>>>>>>=20 >>>>>>>>>>> information.) >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> I'm not religious about not having a version number field, = but >>>>> often >>>>>> "less is more". >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Indeed, I'm not religious either. It just seems like a = general > good >>>>> idea >>>>>> to state this directly as opposed to having parsers divine it = based > on >>>>> which >>>>>> fields are present. To quote RFC 5652: >>>>>>>=20 >>>>>>>>>> " >>>>>>>=20 >>>>>>>>>> Each of the major data structures includes a version number = as >> the >>>>>>>=20 >>>>>>>>>> first item in the data structure. The version numbers are > intended >>>>>>>=20 >>>>>>>>>> to avoid ASN.1 decode errors. Some implementations do not >> check >>>>>> the >>>>>>>=20 >>>>>>>>>> version number prior to attempting a decode, and if a decode >> error >>>>>>>=20 >>>>>>>>>> occurs, then the version number is checked as part of the = error >>>>>>>=20 >>>>>>>>>> handling routine. This is a reasonable approach; it places = error >>>>>>>=20 >>>>>>>>>> processing outside of the fast path. This approach is also >>>>>>>=20 >>>>>>>>>> forgiving when an incorrect version number is used by the >> sender. >>>>>>>=20 >>>>>>>>>> " >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> Best, >>>>>>>=20 >>>>>>>>>> --Richard >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Best wishes, >>>>>>>=20 >>>>>>>>>>> -- Mike >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>=20 >>>>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>=20 >>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM >>>>>>>=20 >>>>>>>>>>> To: Mike Jones >>>>>>>=20 >>>>>>>>>>> Cc: jose@ietf.org >>>>>>>=20 >>>>>>>>>>> Subject: Re: [jose] Fwd: New Version Notification for >>>>>>>=20 >>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Ok, so maybe I should have phrased my lead-in differently. >> IMO, >>>>> the >>>>>> current JW* specs are deficient in several ways, e.g.: >>>>>>>=20 >>>>>>>>>>> -- Not being JSON >>>>>>>=20 >>>>>>>>>>> -- Not supporting multiple recipients >>>>>>>=20 >>>>>>>>>>> -- Lacking clear distinctions between signing and MAC >>>>>>>=20 >>>>>>>>>>> -- Lacking clear processing instructions for different key >>>>>>>=20 >>>>>>>>>>> establishment modalities >>>>>>>=20 >>>>>>>>>>> -- Lack of clear typing of objects >>>>>>>=20 >>>>>>>>>>> -- Lack of versioning for future extensibility >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Looking at the current specs, it didn't seem to me that it = would >> be >>>>>> simple to adapt them to address these deficiencies. So I just = did a >>>>> re-write. >>>>>> If you think they can be addressed within the current framework, >> please >>>>>> explain. I just found it simpler to start from whole cloth. >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>=20 >>>>>>>>>>> --Richard >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote: >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Hi Richard, >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> If you're puzzled by specific design decisions in the JOSE >>>>> documents, >>>>>> I encourage you to ask about them on the list. The documents = have >>>>>> significant history going back to mid-2010 when convergence >> discussions >>>>>> started among people with four different JSON signing & = encryption >>>>>> proposals. JWT and the current JOSE specs and implementations = are >> the >>>>>> result. I realize that not all the JOSE participants were part = of > those >>>>>> discussions from the beginning (although many were) and so = teasing >> out the >>>>>> rationale for specific decisions might help people better = understand >> the >>>>>> choices made, and hopefully thereby increase consensus behind the >>>>>> eventual working group choices. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> If the list that you're puzzled by is the bulleted list = below, >>>>> maybe we >>>>>> can start a discussion on that basis. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Best wishes, >>>>>>>=20 >>>>>>>>>>>> -- Mike >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>=20 >>>>>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] >> On >>>>>>>=20 >>>>>>>>>>>> Behalf Of Richard L. Barnes >>>>>>>=20 >>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM >>>>>>>=20 >>>>>>>>>>>> To: jose@ietf.org >>>>>>>=20 >>>>>>>>>>>> Subject: [jose] Fwd: New Version Notification for >>>>>>>=20 >>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Dear JOSE WG, >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Like Mr. Manger, once I finally got around to doing a = thorough >>>>>> review of the JW* specs, I was kind of puzzled by some of the = design >>>>>> decisions. So I also went through and wrote an alternative = format, > this >>>>> time >>>>>> taking a more of a cue from CMS. A link to the document is = below. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Summary of differences: >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS is pure JSON, whereas in JWE and JWS only the = header >>>>>>>=20 >>>>>>>>>>>> parameters are represented in JSON. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS allows for full algorithm agility in key agreement, > while >>>>> JWE >>>>>>>=20 >>>>>>>>>>>> only allows ECDH-ES. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS supports multiple recipients for EncryptedData and >>>>>>>=20 >>>>>>>>>>>> AuthenticatedData objects via the inclusion of multiple >>>>>> WrappedKey >>>>>>>=20 >>>>>>>>>>>> objects. Sending a JWE to multiple recipients requires re- >>>>>>>=20 >>>>>>>>>>>> encryption of the entire object for each recipient. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o The signature and MAC functions of the JWS object are >> separated >>>>>>>=20 >>>>>>>>>>>> into SignedData and AuthenticatedData JSMS objects. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS parameters are not integrity-protected, as they are = in >> JWE >>>>>>>=20 >>>>>>>>>>>> and JWS. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o The "typ" and "zip" parameters are not defined in JSMS, = but >>>>> could >>>>>>>=20 >>>>>>>>>>>> be added without significant change. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> o JSMS requires that recipients MUST ignore unknown header >>>>>>>=20 >>>>>>>>>>>> parameters, in order to facilitate extensibility. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> I've also thrown together an initial JavaScript = implementation >>>>> (based >>>>>> on NodeJS for some python crypto glue), which is on github: >>>>>>>=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Comments are very welcome. >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>=20 >>>>>>>>>>>> --Richard >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>=20 >>>>>>>>>>>>> Subject: New Version Notification for >>>>>>>=20 >>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt >>>>>>>=20 >>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT >>>>>>>=20 >>>>>>>>>>>>> To: rbarnes@bbn.com >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> A new version of I-D, draft-barnes-jose-jsms-00.txt has = been >>>>>>>=20 >>>>>>>>>>>>> successfully submitted by Richard Barnes and posted to the >> IETF >>>>>>>=20 >>>>>>>>>>>>> repository. >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> Filename: draft-barnes-jose-jsms >>>>>>>=20 >>>>>>>>>>>>> Revision: 00 >>>>>>>=20 >>>>>>>>>>>>> Title: JavaScript Message Security = Format >>>>>>>=20 >>>>>>>>>>>>> Creation date: 2012-06-15 >>>>>>>=20 >>>>>>>>>>>>> WG ID: Individual Submission >>>>>>>=20 >>>>>>>>>>>>> Number of pages: 25 >>>>>>>=20 >>>>>>>>>>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-barnes-jose- >>>>>> jsms-00.txt >>>>>>>=20 >>>>>>>>>>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms >>>>>>>=20 >>>>>>>>>>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-barnes-jose-jsms-00 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>=20 >>>>>>>>>>>>> Many applications require the ability to send > cryptographically >>>>>>>=20 >>>>>>>>>>>>> secured messages. While the IETF has defined a number of >>>>>> formats >>>>>>>=20 >>>>>>>>>>>>> for such messages (e.g. CMS) those formats use encodings >> which >>>>>>>=20 >>>>>>>>>>>>> are not easy to use in modern applications. This document >>>>>>>=20 >>>>>>>>>>>>> describes the JavaScript Message Security format (JSMS), a >> new >>>>>>>=20 >>>>>>>>>>>>> cryptographic message format which is based on JavaScript >> Object >>>>>>>=20 >>>>>>>>>>>>> Notation (JSON) and thus is easy for many applications to >>>>> generate >>>>>> and parse. >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>=20 >>>>>>>>>> jose mailing list >>>>>>>=20 >>>>>>>>>> jose@ietf.org >>>>>>>=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >=20 >=20 --Apple-Mail=_3D7BC36E-CBD6-41D0-8907-071424EA45A9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjIyNTA1NVowIwYJKoZIhvcNAQkEMRYEFJYxKWvRGbOeUV3Z3i7s8LMD3mj9MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACwKklgh1jD/4BuUiVbxt7g5LQnJC1OdIGXOczoSrlW8Mrvud32a5VUvJUjpR+PcPPQev3uDZ97D bsT3cNvqNSfOB79BHbThBJ6sFv9OXdwTG+rDW+fuCCZa47CCmyT8gFHmk/ZfytDgnhidjmNchrEz C9upZD99P0GMH9ObFUTWBBap7BnEslMG26osuuBgbOGSup8wyLRp5mnTSKRYfi4k9bl7C4Uh7kpv NhnpwzICDExVnB22pHTHRGNg26wtybsOdtzaaJUKHEoTrzSMH34/DCwmazMZ+jP4pUBAt+cr9ZYV 38ynm7Ghzfaqy8bYfRccUYxCIWojg2CQVPIKkUwAAAAAAAA= --Apple-Mail=_3D7BC36E-CBD6-41D0-8907-071424EA45A9-- From Michael.Jones@microsoft.com Tue Jun 26 17:31: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 1DD0B11E80BC for ; Tue, 26 Jun 2012 17:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.016 X-Spam-Level: X-Spam-Status: No, score=-4.016 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUJIMxnUA-uC for ; Tue, 26 Jun 2012 17:31:45 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7BADD21F84EA for ; Tue, 26 Jun 2012 17:31:45 -0700 (PDT) Received: from mail274-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 00:30:03 +0000 Received: from mail274-tx2 (localhost [127.0.0.1]) by mail274-tx2-R.bigfish.com (Postfix) with ESMTP id ECFDF3401B3 for ; Wed, 27 Jun 2012 00:30:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zzc85fhzz1202hzz1033IL8275bh30d1K8275dh5eeeKz2fh2a8h668h839hd25hf0ah34h) Received-SPF: pass (mail274-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=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail274-tx2 (localhost.localdomain [127.0.0.1]) by mail274-tx2 (MessageSwitch) id 1340756972376478_28200; Wed, 27 Jun 2012 00:29:32 +0000 (UTC) Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.239]) by mail274-tx2.bigfish.com (Postfix) with ESMTP id 50850740046 for ; Wed, 27 Jun 2012 00:29:32 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 00:29:31 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Wed, 27 Jun 2012 00:31:03 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JWE Key Derivation computation examples Thread-Index: Ac1T/B9bRFMErYd4T4G/V/1fH9FutQ== Date: Wed, 27 Jun 2012 00:31:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366569F10@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] JWE Key Derivation computation examples 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, 27 Jun 2012 00:31:48 -0000 --_004_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear working group members, For the next round of the JOSE JWE spec, I'm adding example encryption comp= utations to aid implementers. Two example key derivation computations are = included below, in case you'd like to compare your implementations against = these. These values have already been verified by three independent implem= entations. EXAMPLE 1: 256-bit Content Master Key (CMK) 128-bit derived Content Encryption Key (CEK) 256-bit derived Content Integrity Key (CIK) EXAMPLE 2: 512-bit Content Master Key (CMK) 256-bit derived Content Encryption Key (CEK) 512-bit derived Content Integrity Key (CIK) The relevant section of the JWE spec is http://tools.ietf.org/html/draft-ie= tf-jose-json-web-encryption-02#section-7. The Concat KDF is defined in Sec= tion 5.8.1 of http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_= Revision1_Mar08-2007.pdf. Enjoy, -- Mike CMK1 [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207] Round 1 hash input [0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110] Round 1 hash output [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, 50, 69= , 11, 237, 202, 71, 10, 96, 59, 199, 140, 88, 126, 147, 146, 113, 222, 41] CEK1 [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, 50, 69= ] Round 1 hash input [0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207, 73, 110, 116, 101, 103, 114, 105, 116, 121] Round 1 hash output [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, 122, 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, 159] CIK1 [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, 122, 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, 159] CMK2 [148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 45, 156, 249, 7, 225, 168] Round 1 hash input [0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 45, 156, 249, 7, 225, 168, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110] Round 1 hash output [137, 5, 92, 9, 17, 47, 17, 86, 253, 235, 34, 247, 121, 78, 11, 144, 10, 172, 38, 247, 108, 243, 201, 237, 95, 80, 49, 150, 116, 240, 159, 64] CEK2 [137, 5, 92, 9, 17, 47, 17, 86, 253, 235, 34, 247, 121, 78, 11, 144, 10, 172, 38, 247, 108, 243, 201, 237, 95, 80, 49, 150, 116, 240, 159, 64] Round 1 hash input [0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 45, 156, 249, 7, 225, 168, 73, 110, 116, 101, 103, 114, 105, 116, 121] Round 1 hash output [11, 179, 132, 177, 171, 24, 126, 19, 113, 1, 200, 102, 100, 74, 88, 149, 31, 41, 71, 57, 51, 179, 106, 242, 113, 211, 56, 56, 37, 198, 57, 17] Round 2 hash input [0, 0, 0, 2, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 45, 156, 249, 7, 225, 168, 73, 110, 116, 101, 103, 114, 105, 116, 121] Round 2 hash output [149, 209, 221, 113, 40, 191, 95, 252, 142, 254, 141, 230, 39, 113, 139, 84= , 44, 156, 247, 47, 223, 101, 229, 180, 82, 231, 38, 96, 170, 119, 236, 81] CIK2 [11, 179, 132, 177, 171, 24, 126, 19, 113, 1, 200, 102, 100, 74, 88, 149, 31, 41, 71, 57, 51, 179, 106, 242, 113, 211, 56, 56, 37, 198, 57, 17, 149, 209, 221, 113, 40, 191, 95, 252, 142, 254, 141, 230, 39, 113, 139, 84, 44, 156, 247, 47, 223, 101, 229, 180, 82, 231, 38, 96, 170, 119, 236, 81] --_000_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear working group members,

 

For the next round of the JOSE JWE spec, I’m a= dding example encryption computations to aid implementers.  Two exampl= e key derivation computations are included below, in case you’d like = to compare your implementations against these.  These values have already been verified by three independent implementations.

 

EXAMPLE 1:

        &nbs= p;       256-bit Content Master Key (CMK)

        &nbs= p;       128-bit derived Content Encryption K= ey (CEK)

        &nbs= p;       256-bit derived Content Integrity Ke= y (CIK)

EXAMPLE 2:

        &nbs= p;       512-bit Content Master Key (CMK)

        &nbs= p;       256-bit derived Content Encryption K= ey (CEK)

        &nbs= p;       512-bit derived Content Integrity Ke= y (CIK)

 

The relevant section of the JWE spec is http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02#section-7= .  The Concat KDF is defined in Section 5.8.1 of http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar0= 8-2007.pdf.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Enjoy,

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

 

CMK1

[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 2= 50, 63, 170, 106, 206,

107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 24= 0, 143, 156, 44, 207]

Round 1 hash input

[0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11,= 100, 157, 250,

63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 2= 19, 200, 177, 0, 240,

143, 156, 44, 207, 69, 110, 99, 114, 121, 112, 116, = 105, 111, 110]

Round 1 hash output

[249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166= , 130, 195, 184, 50, 69,

11, 237, 202, 71, 10, 96, 59, 199, 140, 88, 126, 147= , 146, 113, 222, 41]

CEK1

[249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166= , 130, 195, 184, 50, 69]

Round 1 hash input

[0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11,= 100, 157, 250,

63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 2= 19, 200, 177, 0, 240,

143, 156, 44, 207, 73, 110, 116, 101, 103, 114, 105,= 116, 121]

Round 1 hash output

[218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, = 20, 3, 158, 111, 122,

182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246,= 115, 177, 225, 159]

CIK1

[218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, = 20, 3, 158, 111, 122,

182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246,= 115, 177, 225, 159]

 

CMK2

[148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, = 193, 61, 34, 239, 226,

109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, = 176, 68, 119, 13, 34,

49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 138,= 67, 23, 153, 83,

81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 45, 156= , 249, 7, 225, 168]

Round 1 hash input

[0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 15= 0, 149, 89, 193,

61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 2= 35, 106, 204, 49, 176,

68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 10= 4, 129, 137, 138,

67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130,= 35, 124, 45, 156,

249, 7, 225, 168, 69, 110, 99, 114, 121, 112, 116, 1= 05, 111, 110]

Round 1 hash output

[137, 5, 92, 9, 17, 47, 17, 86, 253, 235, 34, 247, 1= 21, 78, 11, 144,

10, 172, 38, 247, 108, 243, 201, 237, 95, 80, 49, 15= 0, 116, 240, 159, 64]

CEK2

[137, 5, 92, 9, 17, 47, 17, 86, 253, 235, 34, 247, 1= 21, 78, 11, 144,

10, 172, 38, 247, 108, 243, 201, 237, 95, 80, 49, 15= 0, 116, 240, 159, 64]

Round 1 hash input

[0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 15= 0, 149, 89, 193,

61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 2= 35, 106, 204, 49, 176,

68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 10= 4, 129, 137, 138,

67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130,= 35, 124, 45, 156,

249, 7, 225, 168, 73, 110, 116, 101, 103, 114, 105, = 116, 121]

Round 1 hash output

[11, 179, 132, 177, 171, 24, 126, 19, 113, 1, 200, 1= 02, 100, 74, 88, 149,

31, 41, 71, 57, 51, 179, 106, 242, 113, 211, 56, 56,= 37, 198, 57, 17]

Round 2 hash input

[0, 0, 0, 2, 148, 116, 199, 126, 2, 117, 233, 76, 15= 0, 149, 89, 193,

61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 2= 35, 106, 204, 49, 176,

68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 10= 4, 129, 137, 138,

67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130,= 35, 124, 45, 156,

249, 7, 225, 168, 73, 110, 116, 101, 103, 114, 105, = 116, 121]

Round 2 hash output

[149, 209, 221, 113, 40, 191, 95, 252, 142, 254, 141= , 230, 39, 113, 139, 84,

44, 156, 247, 47, 223, 101, 229, 180, 82, 231, 38, 9= 6, 170, 119, 236, 81]

CIK2

[11, 179, 132, 177, 171, 24, 126, 19, 113, 1, 200, 1= 02, 100, 74, 88, 149,

31, 41, 71, 57, 51, 179, 106, 242, 113, 211, 56, 56,= 37, 198, 57, 17,

149, 209, 221, 113, 40, 191, 95, 252, 142, 254, 141,= 230, 39, 113, 139, 84,

44, 156, 247, 47, 223, 101, 229, 180, 82, 231, 38, 9= 6, 170, 119, 236, 81]

 

--_000_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_ Content-Type: application/octet-stream; name="KeyDerivation.log" Content-Description: KeyDerivation.log Content-Disposition: attachment; filename="KeyDerivation.log"; size=3614; creation-date="Mon, 25 Jun 2012 22:24:14 GMT"; modification-date="Mon, 25 Jun 2012 22:23:09 GMT" Content-Transfer-Encoding: base64 Q01LMQ0KWzQsIDIxMSwgMzEsIDE5NywgODQsIDE1NywgMjUyLCAyNTQsIDExLCAxMDAsIDE1Nywg MjUwLCA2MywgMTcwLCAxMDYsIDIwNiwNCiAxMDcsIDEyNCwgMjEyLCA0NSwgMTExLCAxMDcsIDks IDIxOSwgMjAwLCAxNzcsIDAsIDI0MCwgMTQzLCAxNTYsIDQ0LCAyMDddDQpSb3VuZCAxIGhhc2gg aW5wdXQNClswLCAwLCAwLCAxLCA0LCAyMTEsIDMxLCAxOTcsIDg0LCAxNTcsIDI1MiwgMjU0LCAx MSwgMTAwLCAxNTcsIDI1MCwNCiA2MywgMTcwLCAxMDYsIDIwNiwgMTA3LCAxMjQsIDIxMiwgNDUs IDExMSwgMTA3LCA5LCAyMTksIDIwMCwgMTc3LCAwLCAyNDAsDQogMTQzLCAxNTYsIDQ0LCAyMDcs IDY5LCAxMTAsIDk5LCAxMTQsIDEyMSwgMTEyLCAxMTYsIDEwNSwgMTExLCAxMTBdDQpSb3VuZCAx IGhhc2ggb3V0cHV0DQpbMjQ5LCAyNTUsIDg3LCAyMTgsIDIyNCwgMjIzLCAyMjEsIDUzLCAyMDQs IDEyMSwgMTY2LCAxMzAsIDE5NSwgMTg0LCA1MCwgNjksDQogMTEsIDIzNywgMjAyLCA3MSwgMTAs IDk2LCA1OSwgMTk5LCAxNDAsIDg4LCAxMjYsIDE0NywgMTQ2LCAxMTMsIDIyMiwgNDFdDQpDRUsx DQpbMjQ5LCAyNTUsIDg3LCAyMTgsIDIyNCwgMjIzLCAyMjEsIDUzLCAyMDQsIDEyMSwgMTY2LCAx MzAsIDE5NSwgMTg0LCA1MCwgNjldDQpSb3VuZCAxIGhhc2ggaW5wdXQNClswLCAwLCAwLCAxLCA0 LCAyMTEsIDMxLCAxOTcsIDg0LCAxNTcsIDI1MiwgMjU0LCAxMSwgMTAwLCAxNTcsIDI1MCwNCiA2 MywgMTcwLCAxMDYsIDIwNiwgMTA3LCAxMjQsIDIxMiwgNDUsIDExMSwgMTA3LCA5LCAyMTksIDIw MCwgMTc3LCAwLCAyNDAsDQogMTQzLCAxNTYsIDQ0LCAyMDcsIDczLCAxMTAsIDExNiwgMTAxLCAx MDMsIDExNCwgMTA1LCAxMTYsIDEyMV0NClJvdW5kIDEgaGFzaCBvdXRwdXQNClsyMTgsIDIwOSwg MTMwLCA1MCwgMTY5LCA0NSwgNzAsIDIxNCwgMjksIDE4NywgMTIzLCAyMCwgMywgMTU4LCAxMTEs IDEyMiwNCiAxODIsIDk0LCA1NywgMTMzLCAyNDUsIDc2LCA5NywgNDQsIDE5MywgODAsIDgxLCAy NDYsIDExNSwgMTc3LCAyMjUsIDE1OV0NCkNJSzENClsyMTgsIDIwOSwgMTMwLCA1MCwgMTY5LCA0 NSwgNzAsIDIxNCwgMjksIDE4NywgMTIzLCAyMCwgMywgMTU4LCAxMTEsIDEyMiwNCiAxODIsIDk0 LCA1NywgMTMzLCAyNDUsIDc2LCA5NywgNDQsIDE5MywgODAsIDgxLCAyNDYsIDExNSwgMTc3LCAy MjUsIDE1OV0NCg0KQ01LMg0KWzE0OCwgMTE2LCAxOTksIDEyNiwgMiwgMTE3LCAyMzMsIDc2LCAx NTAsIDE0OSwgODksIDE5MywgNjEsIDM0LCAyMzksIDIyNiwNCiAxMDksIDcxLCA1OSwgMTYwLCAx OTIsIDE0MCwgMTUwLCAyMzUsIDEwNiwgMjA0LCA0OSwgMTc2LCA2OCwgMTE5LCAxMywgMzQsDQog NDksIDE5LCA0MSwgNjksIDUsIDIwLCAyNTIsIDE0NSwgMTA0LCAxMjksIDEzNywgMTM4LCA2Nywg MjMsIDE1MywgODMsDQogODEsIDIzNCwgODIsIDI0NywgNDgsIDIxMSwgNDEsIDEzMCwgMzUsIDEy NCwgNDUsIDE1NiwgMjQ5LCA3LCAyMjUsIDE2OF0NClJvdW5kIDEgaGFzaCBpbnB1dA0KWzAsIDAs IDAsIDEsIDE0OCwgMTE2LCAxOTksIDEyNiwgMiwgMTE3LCAyMzMsIDc2LCAxNTAsIDE0OSwgODks IDE5MywNCiA2MSwgMzQsIDIzOSwgMjI2LCAxMDksIDcxLCA1OSwgMTYwLCAxOTIsIDE0MCwgMTUw LCAyMzUsIDEwNiwgMjA0LCA0OSwgMTc2LA0KIDY4LCAxMTksIDEzLCAzNCwgNDksIDE5LCA0MSwg NjksIDUsIDIwLCAyNTIsIDE0NSwgMTA0LCAxMjksIDEzNywgMTM4LA0KIDY3LCAyMywgMTUzLCA4 MywgODEsIDIzNCwgODIsIDI0NywgNDgsIDIxMSwgNDEsIDEzMCwgMzUsIDEyNCwgNDUsIDE1NiwN CiAyNDksIDcsIDIyNSwgMTY4LCA2OSwgMTEwLCA5OSwgMTE0LCAxMjEsIDExMiwgMTE2LCAxMDUs IDExMSwgMTEwXQ0KUm91bmQgMSBoYXNoIG91dHB1dA0KWzEzNywgNSwgOTIsIDksIDE3LCA0Nywg MTcsIDg2LCAyNTMsIDIzNSwgMzQsIDI0NywgMTIxLCA3OCwgMTEsIDE0NCwNCiAxMCwgMTcyLCAz OCwgMjQ3LCAxMDgsIDI0MywgMjAxLCAyMzcsIDk1LCA4MCwgNDksIDE1MCwgMTE2LCAyNDAsIDE1 OSwgNjRdDQpDRUsyDQpbMTM3LCA1LCA5MiwgOSwgMTcsIDQ3LCAxNywgODYsIDI1MywgMjM1LCAz NCwgMjQ3LCAxMjEsIDc4LCAxMSwgMTQ0LA0KIDEwLCAxNzIsIDM4LCAyNDcsIDEwOCwgMjQzLCAy MDEsIDIzNywgOTUsIDgwLCA0OSwgMTUwLCAxMTYsIDI0MCwgMTU5LCA2NF0NClJvdW5kIDEgaGFz aCBpbnB1dA0KWzAsIDAsIDAsIDEsIDE0OCwgMTE2LCAxOTksIDEyNiwgMiwgMTE3LCAyMzMsIDc2 LCAxNTAsIDE0OSwgODksIDE5MywNCiA2MSwgMzQsIDIzOSwgMjI2LCAxMDksIDcxLCA1OSwgMTYw LCAxOTIsIDE0MCwgMTUwLCAyMzUsIDEwNiwgMjA0LCA0OSwgMTc2LA0KIDY4LCAxMTksIDEzLCAz NCwgNDksIDE5LCA0MSwgNjksIDUsIDIwLCAyNTIsIDE0NSwgMTA0LCAxMjksIDEzNywgMTM4LA0K IDY3LCAyMywgMTUzLCA4MywgODEsIDIzNCwgODIsIDI0NywgNDgsIDIxMSwgNDEsIDEzMCwgMzUs IDEyNCwgNDUsIDE1NiwNCiAyNDksIDcsIDIyNSwgMTY4LCA3MywgMTEwLCAxMTYsIDEwMSwgMTAz LCAxMTQsIDEwNSwgMTE2LCAxMjFdDQpSb3VuZCAxIGhhc2ggb3V0cHV0DQpbMTEsIDE3OSwgMTMy LCAxNzcsIDE3MSwgMjQsIDEyNiwgMTksIDExMywgMSwgMjAwLCAxMDIsIDEwMCwgNzQsIDg4LCAx NDksDQogMzEsIDQxLCA3MSwgNTcsIDUxLCAxNzksIDEwNiwgMjQyLCAxMTMsIDIxMSwgNTYsIDU2 LCAzNywgMTk4LCA1NywgMTddDQpSb3VuZCAyIGhhc2ggaW5wdXQNClswLCAwLCAwLCAyLCAxNDgs IDExNiwgMTk5LCAxMjYsIDIsIDExNywgMjMzLCA3NiwgMTUwLCAxNDksIDg5LCAxOTMsDQogNjEs IDM0LCAyMzksIDIyNiwgMTA5LCA3MSwgNTksIDE2MCwgMTkyLCAxNDAsIDE1MCwgMjM1LCAxMDYs IDIwNCwgNDksIDE3NiwNCiA2OCwgMTE5LCAxMywgMzQsIDQ5LCAxOSwgNDEsIDY5LCA1LCAyMCwg MjUyLCAxNDUsIDEwNCwgMTI5LCAxMzcsIDEzOCwNCiA2NywgMjMsIDE1MywgODMsIDgxLCAyMzQs IDgyLCAyNDcsIDQ4LCAyMTEsIDQxLCAxMzAsIDM1LCAxMjQsIDQ1LCAxNTYsDQogMjQ5LCA3LCAy MjUsIDE2OCwgNzMsIDExMCwgMTE2LCAxMDEsIDEwMywgMTE0LCAxMDUsIDExNiwgMTIxXQ0KUm91 bmQgMiBoYXNoIG91dHB1dA0KWzE0OSwgMjA5LCAyMjEsIDExMywgNDAsIDE5MSwgOTUsIDI1Miwg MTQyLCAyNTQsIDE0MSwgMjMwLCAzOSwgMTEzLCAxMzksIDg0LA0KIDQ0LCAxNTYsIDI0NywgNDcs IDIyMywgMTAxLCAyMjksIDE4MCwgODIsIDIzMSwgMzgsIDk2LCAxNzAsIDExOSwgMjM2LCA4MV0N CkNJSzINClsxMSwgMTc5LCAxMzIsIDE3NywgMTcxLCAyNCwgMTI2LCAxOSwgMTEzLCAxLCAyMDAs IDEwMiwgMTAwLCA3NCwgODgsIDE0OSwNCiAzMSwgNDEsIDcxLCA1NywgNTEsIDE3OSwgMTA2LCAy NDIsIDExMywgMjExLCA1NiwgNTYsIDM3LCAxOTgsIDU3LCAxNywNCiAxNDksIDIwOSwgMjIxLCAx MTMsIDQwLCAxOTEsIDk1LCAyNTIsIDE0MiwgMjU0LCAxNDEsIDIzMCwgMzksIDExMywgMTM5LCA4 NCwNCiA0NCwgMTU2LCAyNDcsIDQ3LCAyMjMsIDEwMSwgMjI5LCAxODAsIDgyLCAyMzEsIDM4LCA5 NiwgMTcwLCAxMTksIDIzNiwgODFdDQo= --_004_4E1F6AAD24975D4BA5B168042967394366569F10TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Jun 26 17:33: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 6D7FC11E80C1 for ; Tue, 26 Jun 2012 17:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BExYhUMDTe2 for ; Tue, 26 Jun 2012 17:33:17 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id A108011E80C0 for ; Tue, 26 Jun 2012 17:33:16 -0700 (PDT) Received: from mail111-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 00:31:34 +0000 Received: from mail111-am1 (localhost [127.0.0.1]) by mail111-am1-R.bigfish.com (Postfix) with ESMTP id 85962340081 for ; Wed, 27 Jun 2012 00:31:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VS-6(zz936eIc85fhzz1202hzz8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah34h) Received-SPF: pass (mail111-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail111-am1 (localhost.localdomain [127.0.0.1]) by mail111-am1 (MessageSwitch) id 1340757091573376_2931; Wed, 27 Jun 2012 00:31:31 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.236]) by mail111-am1.bigfish.com (Postfix) with ESMTP id 89B19A0048 for ; Wed, 27 Jun 2012 00:31:31 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 00:31:28 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Wed, 27 Jun 2012 00:32:59 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Complete JWE computation example Thread-Index: Ac1T/GRGQNrJnE+VSraU0uTeYqzhVg== Date: Wed, 27 Jun 2012 00:32:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Complete JWE computation example 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, 27 Jun 2012 00:33:22 -0000 --_004_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear working group members, For the next round of the JOSE JWE spec, I'm adding example encryption comp= utations to aid implementers. An example JWE computation is included below= , in case you'd like to compare your implementations against these. These = values have already been verified by two independent implementations. This example uses the header values: {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3R= oZQ"} As such, there are actually several different things that this example veri= fies: - RSA encryption of the CMK - Deriving the CEK and CIK from the CMK (in this case, using the same val= ues as EXAMPLE 1 from my Key Derivation message) - AES-CBC encryption of the plaintext - Calculation of the integrity value Note that because RSA PKCS #1-1.5 padding uses random values, the encrypted= CMK value will not be repeatable, although all resulting values will be de= cryptable to retrieve the original CMK value. All relevant values should be present below. For the RSA key parameters, t= he field names used are the ones from the .NET RSAParameters structure docu= mented at http://msdn.microsoft.com/en-us/library/system.security.cryptogra= phy.rsaparameters_members(v=3Dvs.71). Enjoy, -- Mike CMK [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207] CEK [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, 50, 69= ] CIK [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, 122, 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, 159] IV [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101] Plaintext [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109, 101, 32, 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 109, 101, 110, 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 104, 101, 32, 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, 99, 111, 117, 110, 116, 114, 121, 46] Header {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZQ"= } Header Bytes [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34, 44, 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34, 105, 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, 115, 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125] Encoded Header eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WTh= EQ3REYUdsc2JHbGpiM1JvWlEifQ BEGIN RSA KEY PARAMETERS Exponent [1, 0, 1] Modulus [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12, 224, 19, 226, 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108, 185, 234, 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, 6, 224, 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144, 215, 110, 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, 124, 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, 113, 9, 33, 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194, 192, 183, 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, 253, 206, 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, 136, 138, 11, 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 172, 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, 72, 99, 97, 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224, 178, 163, 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, 127, 68, 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, 213, 86, 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 89, 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239, 71] D (private key exponent) [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 181, 221, 156, 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16, 165, 48, 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, 56, 97, 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, 67, 180, 167, 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, 41, 83, 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, 45, 148, 58, 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119, 61, 26, 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, 99, 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80, 171, 167, 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 152, 71, 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, 91, 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 127, 84, 171, 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, 186, 222, 27, 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 224, 81, 100, 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202, 151, 107, 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, 130, 89] The remaining RSA key parameters are included for completeness, but should = not be needed DP [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, 112, 188, 112, 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 196, 152, 132, 1= 10, 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, 226, 34, 196, 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 113, 195, 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254, 251, 112, 231= , 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77, 104, 196, 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, 144, 100, 2, 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 33, 156, 43] DQ [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, 207, 219, 180, 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 192, 124, 130, 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123, 33, 92, 119, 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 169, 208, 156, 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, 251, 152, 142, 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8, 117, 176, 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78, 241, 125, 153= , 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169, 234, 165] InverseQ [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, 61, 66, 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94, 35, 86, 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 77, 23, 37, 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37, 115, 156, 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 227, 216, 168, 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111, 31, 117, 81, 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204, 190, 89, 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, 52, 52, 218] P [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 183, 131, 3, 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20, 186, 78, 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 247, 95, 33, 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1, 78, 60, 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211, 167, 206, 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 210, 216, 44, 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, 221, 51, 108, 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, 189, 230, 195] Q [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, 155, 213, 73, 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, 146, 203, 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 85, 251, 134, 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 213, 16, 94, 30= , 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240, 214, 50, 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118, 221, 146, 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, 206, 242, 113, 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, 53, 45] END RSA KEY PARAMETERS Encrypted Key [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, 244, 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, 188, 215, 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 28, 149, 16, 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, 58, 206, 201, 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 170, 7, 36, 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193, 119, 202, 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170, 204, 73, 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 147, 2, 37, 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59, 41, 115, 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254, 166, 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, 134, 64, 189, 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 213, 85, 253, 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, 178, 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58, 102, 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, 181, 138, 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, 251] Encoded Encrypted Key IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_CxW= VrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rMSU= vVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3LNl= JUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmak= iPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w Ciphertext [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, 146, 217, 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, 207, 239, 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142, 7, 69, 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59, 180, 107, 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 223, 147] Encoded Ciphertext _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7U= HvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M Secured Input eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WTh= EQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq= 847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56Sy= AwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClV= yYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7= NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w._Z_d= jlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7UHvP8= PEDu0a0sA2a_-CI0w2YQQ2QQe35M Secured Input Bytes [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53, 48, 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 74, 112, 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 82, 69, 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 74, 118, 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 50, 104, 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 104, 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 118, 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 95, 71, 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 67, 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, 97, 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 66, 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 83, 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 53, 100, 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118, 86, 121, 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 84, 65, 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101, 80, 95, 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89, 70, 67, 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, 89, 102, 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71, 81, 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101, 102, 107, 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 108, 70, 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 102, 117, 88, 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78, 73, 79, 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122, 48, 111, 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79, 73, 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, 95, 90, 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, 114, 101, 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 85, 106, 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99, 70, 78, 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, 70, 76, 106, 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69, 68, 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50, 89, 81, 81, 50, 81, 81, 101, 51, 53, 77] Integrity Value [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, 102, 136, 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, 15, 73] Encoded Integrity Value c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k JWE eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WTh= EQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq= 847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56Sy= AwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClV= yYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7= NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w._Z_d= jlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7UHvP8= PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k --_000_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear working group members,

 

For the next round of the JOSE JWE spec, I’m a= dding example encryption computations to aid implementers.  An example= JWE computation is included below, in case you’d like to compare you= r implementations against these.  These values have already been verified by two independent implementations.

 

This example uses the header values:

    {"alg":"RSA1_5&quo= t;,"enc":"A128CBC","int":"HS256",&q= uot;iv":"AxY8DCtDaGlsbGljb3RoZQ"}

 

As such, there are actually several different things= that this example verifies:

  - RSA encryption of the CMK

  - Deriving the CEK and CIK from the CMK (in t= his case, using the same values as EXAMPLE 1 from my Key Derivation message= )

  - AES-CBC encryption of the plaintext

  - Calculation of the integrity value

 

Note that because RSA PKCS #1-1.5 padding uses rando= m values, the encrypted CMK value will not be repeatable, although all resu= lting values will be decryptable to retrieve the original CMK value.

 

All relevant values should be present below.  F= or the RSA key parameters, the field names used are the ones from the .NET = RSAParameters structure documented at http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsapar= ameters_members(v=3Dvs.71).

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Enjoy,

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

 

CMK

[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 2= 50, 63, 170, 106, 206,

107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 24= 0, 143, 156, 44, 207]

CEK

[249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166= , 130, 195, 184, 50, 69]

CIK

[218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, = 20, 3, 158, 111, 122,

182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246,= 115, 177, 225, 159]

IV

[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99,= 111, 116, 104, 101]

Plaintext

[78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, = 116, 105, 109, 101, 32,

102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, = 100, 32, 109, 101, 110,

32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 3= 2, 116, 104, 101, 32,

97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, = 114, 32, 99, 111, 117,

110, 116, 114, 121, 46]

Header

{"alg":"RSA1_5","enc":= "A128CBC","int":"HS256","iv":"= AxY8DCtDaGlsbGljb3RoZQ"}

Header Bytes

[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, = 95, 53, 34, 44,

34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66= , 67, 34, 44,

34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 3= 4, 44, 34, 105,

118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 9= 7, 71, 108, 115,

98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125]<= o:p>

Encoded Header

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50Ijoi= SFMyNTYiLCJpdiI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ

BEGIN RSA KEY PARAMETERS

Exponent

[1, 0, 1]

Modulus

[177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107,= 242, 12, 224, 19, 226,

198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161= , 97, 108, 185, 234,

226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 8= 5, 51, 123, 6, 224,

4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, = 220, 144, 215, 110,

130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 21= 4, 17, 179, 28, 124,

151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, = 73, 211, 113, 9, 33,

178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147= , 70, 194, 192, 183,

160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73,= 145, 50, 253, 206,

32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 2= 20, 108, 136, 138, 11,

192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, = 239, 146, 3, 172,

96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, = 92, 112, 72, 99, 97,

26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153,= 47, 224, 178, 163,

77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89,= 46, 225, 127, 68,

146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85,= 55, 75, 213, 86,

194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153= , 53, 7, 48, 89,

35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3= , 13, 239, 71]

D (private key exponent)

[84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 1= 54, 36, 181, 221, 156,

211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 12= 2, 4, 16, 165, 48,

76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173= , 78, 61, 56, 97,

252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 2= 52, 120, 67, 180, 167,

3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 1= 60, 200, 41, 83,

164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198,= 48, 211, 45, 148, 58,

23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154,= 80, 119, 61, 26,

193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 6= 6, 6, 163, 100, 99,

219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 6= 9, 1, 80, 171, 167,

20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, = 87, 6, 152, 71,

156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 8= 4, 163, 249, 91,

215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135= , 105, 127, 84, 171,

181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 2= 45, 219, 186, 222, 27,

240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, = 74, 65, 224, 81, 100,

85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11= , 23, 202, 151, 107,

54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182= , 204, 93, 130, 89]

The remaining RSA key parameters are included for co= mpleteness, but should not be needed

DP

[195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 1= 78, 147, 112, 188, 112,

204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101= , 152, 196, 152, 132, 110,

4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, = 120, 44, 226, 34, 196,

22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 4= 7, 139, 113, 195,

210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, = 160, 254, 251, 112, 231,

82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39= , 118, 77, 104, 196,

229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, = 220, 92, 144, 100, 2,

46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 22= 2, 145, 33, 156, 43]

DQ

[163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35,= 75, 42, 207, 219, 180,

247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 1= 19, 98, 192, 124, 130,

21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127,= 176, 123, 33, 92, 119,

167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 20= 3, 111, 169, 208, 156,

188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, = 146, 17, 251, 152, 142,

225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 12= 2, 132, 8, 117, 176,

208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31,= 245, 78, 241, 125, 153,

112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, = 201, 169, 234, 165]

InverseQ

[120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80,= 71, 12, 61, 66,

42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9= , 203, 94, 35, 86,

130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 2= 13, 36, 77, 23, 37,

33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234= , 168, 37, 115, 156,

86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 1= 20, 84, 227, 216, 168,

170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192,= 197, 111, 31, 117, 81,

69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121,= 82, 204, 190, 89,

21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, = 77, 241, 52, 52, 218]

P

[246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 1= 0, 177, 183, 131, 3,

10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19= , 33, 20, 186, 78,

36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 20= 0, 164, 247, 95, 33,

116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 19= 9, 56, 1, 78, 60,

159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, = 118, 211, 167, 206,

215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165= , 186, 210, 216, 44,

213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, = 18, 223, 221, 51, 108,

92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 1= 29, 176, 189, 230, 195]

Q

[184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, = 72, 179, 155, 213, 73,

79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, = 95, 236, 146, 203,

111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, = 32, 97, 85, 251, 134,

226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 14= 3, 116, 213, 16, 94, 30,

142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 13= 3, 5, 240, 214, 50,

0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, = 139, 118, 221, 146,

15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 2= 30, 166, 206, 242, 113,

158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, = 105, 34, 53, 45]

END RSA KEY PARAMETERS

Encrypted Key

[32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4,= 15, 193, 6, 244,

51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 15= 2, 41, 244, 188, 215,

174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, = 116, 152, 28, 149, 16,

94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, = 54, 194, 58, 206, 201,

164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40= , 119, 170, 7, 36,

225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32= , 48, 193, 119, 202,

41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, = 239, 170, 204, 73,

75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 24= 4, 117, 147, 2, 37,

207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0= , 166, 59, 41, 115,

217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4= , 87, 254, 166,

227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, = 78, 193, 134, 64, 189,

168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 5= 5, 189, 213, 85, 253,

135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123= , 54, 39, 9, 178,

231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 1= 3, 227, 72, 58, 102,

164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239= , 150, 248, 181, 138,

251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 1= 97, 2, 153, 251]

Encoded Encrypted Key

IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl= 6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXf= KKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCb= jKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJs= ufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w

Ciphertext

[253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162= , 173, 229, 146, 217,

183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 1= 41, 11, 221, 207, 239,

207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160= , 96, 142, 7, 69,

46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15= , 16, 59, 180, 107,

75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217,= 4, 30, 223, 147]

Encoded Ciphertext

_Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkO= ulegD6BgjgdFLjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M

Secured Input

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50Ijoi= SFMyNTYiLCJpdiI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6= hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45B= fKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7= hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefk= je91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1= zYlOIiIKBjsExQKZ-w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOuleg= D6BgjgdFLjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M

Secured Input Bytes

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83= , 85, 48, 69, 120,

88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105,= 79, 105, 74, 66,

77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 9= 7, 87, 53, 48,

73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105,= 76, 67, 74, 112,

100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, = 81, 51, 82, 69,

89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, = 77, 49, 74, 118,

87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, = 49, 55, 50, 104,

83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68,= 77, 54, 104,

73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67,= 110, 48, 118,

78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54,= 113, 119, 95, 71,

72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55= , 83, 95, 67,

120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121= , 97, 81, 99, 97,

53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72= , 101, 113, 66,

121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, = 75, 53, 54, 83,

121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118= , 107, 81, 53, 100,

119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83,= 85, 118, 86, 121,

110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, = 72, 87, 84, 65,

105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49= , 70, 101, 80, 95,

81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86,= 121, 89, 70, 67,

98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, = 117, 78, 89, 102,

79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 11= 5, 71, 71, 81,

76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, = 100, 101, 102, 107,

106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, = 48, 56, 108, 70,

115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115= , 117, 102, 117, 88,

120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68,= 101, 78, 73, 79,

109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84,= 83, 122, 48, 111,

117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89= , 108, 79, 73,

105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, = 119, 46, 95, 90,

95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, = 75, 105, 114, 101,

87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, = 71, 50, 85, 106,

70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100= , 85, 99, 70, 78,

107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 1= 03, 100, 70, 76, 106,

101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56= , 80, 69, 68,

117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48= , 119, 50, 89,

81, 81, 50, 81, 81, 101, 51, 53, 77]

Integrity Value

[115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 23= 0, 241, 147, 102, 136,

232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 11= 9, 184, 186, 15, 73]

Encoded Integrity Value

c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k

JWE

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50Ijoi= SFMyNTYiLCJpdiI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6= hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45B= fKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7= hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefk= je91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1= zYlOIiIKBjsExQKZ-w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOuleg= D6BgjgdFLjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOi= nMciFFypOFpvid7i6D0k

 

--_000_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_ Content-Type: application/octet-stream; name="JWE.log" Content-Description: JWE.log Content-Disposition: attachment; filename="JWE.log"; size=12954; creation-date="Tue, 26 Jun 2012 01:33:19 GMT"; modification-date="Tue, 26 Jun 2012 02:19:48 GMT" Content-Transfer-Encoding: base64 Q01LDQpbNCwgMjExLCAzMSwgMTk3LCA4NCwgMTU3LCAyNTIsIDI1NCwgMTEsIDEwMCwgMTU3LCAy NTAsIDYzLCAxNzAsIDEwNiwgMjA2LA0KIDEwNywgMTI0LCAyMTIsIDQ1LCAxMTEsIDEwNywgOSwg MjE5LCAyMDAsIDE3NywgMCwgMjQwLCAxNDMsIDE1NiwgNDQsIDIwN10NCkNFSw0KWzI0OSwgMjU1 LCA4NywgMjE4LCAyMjQsIDIyMywgMjIxLCA1MywgMjA0LCAxMjEsIDE2NiwgMTMwLCAxOTUsIDE4 NCwgNTAsIDY5XQ0KQ0lLDQpbMjE4LCAyMDksIDEzMCwgNTAsIDE2OSwgNDUsIDcwLCAyMTQsIDI5 LCAxODcsIDEyMywgMjAsIDMsIDE1OCwgMTExLCAxMjIsDQogMTgyLCA5NCwgNTcsIDEzMywgMjQ1 LCA3NiwgOTcsIDQ0LCAxOTMsIDgwLCA4MSwgMjQ2LCAxMTUsIDE3NywgMjI1LCAxNTldDQpJVg0K WzMsIDIyLCA2MCwgMTIsIDQzLCA2NywgMTA0LCAxMDUsIDEwOCwgMTA4LCAxMDUsIDk5LCAxMTEs IDExNiwgMTA0LCAxMDFdDQpQbGFpbnRleHQNCls3OCwgMTExLCAxMTksIDMyLCAxMDUsIDExNSwg MzIsIDExNiwgMTA0LCAxMDEsIDMyLCAxMTYsIDEwNSwgMTA5LCAxMDEsIDMyLA0KIDEwMiwgMTEx LCAxMTQsIDMyLCA5NywgMTA4LCAxMDgsIDMyLCAxMDMsIDExMSwgMTExLCAxMDAsIDMyLCAxMDks IDEwMSwgMTEwLA0KIDMyLCAxMTYsIDExMSwgMzIsIDk5LCAxMTEsIDEwOSwgMTAxLCAzMiwgMTE2 LCAxMTEsIDMyLCAxMTYsIDEwNCwgMTAxLCAzMiwNCiA5NywgMTA1LCAxMDAsIDMyLCAxMTEsIDEw MiwgMzIsIDExNiwgMTA0LCAxMDEsIDEwNSwgMTE0LCAzMiwgOTksIDExMSwgMTE3LA0KIDExMCwg MTE2LCAxMTQsIDEyMSwgNDZdDQpIZWFkZXINCnsiYWxnIjoiUlNBMV81IiwiZW5jIjoiQTEyOENC QyIsImludCI6IkhTMjU2IiwiaXYiOiJBeFk4REN0RGFHbHNiR2xqYjNSb1pRIn0NCkhlYWRlciBC eXRlcw0KWzEyMywgMzQsIDk3LCAxMDgsIDEwMywgMzQsIDU4LCAzNCwgODIsIDgzLCA2NSwgNDks IDk1LCA1MywgMzQsIDQ0LA0KIDM0LCAxMDEsIDExMCwgOTksIDM0LCA1OCwgMzQsIDY1LCA0OSwg NTAsIDU2LCA2NywgNjYsIDY3LCAzNCwgNDQsDQogMzQsIDEwNSwgMTEwLCAxMTYsIDM0LCA1OCwg MzQsIDcyLCA4MywgNTAsIDUzLCA1NCwgMzQsIDQ0LCAzNCwgMTA1LA0KIDExOCwgMzQsIDU4LCAz NCwgNjUsIDEyMCwgODksIDU2LCA2OCwgNjcsIDExNiwgNjgsIDk3LCA3MSwgMTA4LCAxMTUsDQog OTgsIDcxLCAxMDgsIDEwNiwgOTgsIDUxLCA4MiwgMTExLCA5MCwgODEsIDM0LCAxMjVdDQpFbmNv ZGVkIEhlYWRlcg0KZXlKaGJHY2lPaUpTVTBFeFh6VWlMQ0psYm1NaU9pSkJNVEk0UTBKRElpd2lh VzUwSWpvaVNGTXlOVFlpTENKcGRpSTZJa0Y0V1RoRVEzUkVZVWRzYzJKSGJHcGlNMUp2V2xFaWZR DQpCRUdJTiBSU0EgS0VZIFBBUkFNRVRFUlMNCkV4cG9uZW50DQpbMSwgMCwgMV0NCk1vZHVsdXMN ClsxNzcsIDExOSwgMzMsIDEzLCAxNjQsIDMwLCAxMDgsIDEyMSwgMjA3LCAxMzYsIDEwNywgMjQy LCAxMiwgMjI0LCAxOSwgMjI2LA0KIDE5OCwgMTM0LCAxNywgNzEsIDE3MywgNzUsIDQyLCA2MSwg NDgsIDE2MiwgMjA2LCAxNjEsIDk3LCAxMDgsIDE4NSwgMjM0LA0KIDIyNiwgMjE5LCAxMTgsIDIw NiwgMTE4LCA1LCAxNjksIDIyNCwgNjAsIDE4MSwgOTAsIDg1LCA1MSwgMTIzLCA2LCAyMjQsDQog NCwgMTIyLCAyOSwgMjMwLCAxNTEsIDEyLCAyNDQsIDEyNywgMTIxLCAyNSwgNCwgODUsIDIyMCwg MTQ0LCAyMTUsIDExMCwNCiAxMzAsIDE3LCA2OCwgMjI4LCAxMjksIDEzOCwgNywgMTMwLCAyMzEs IDQwLCAyMTIsIDIxNCwgMTcsIDE3OSwgMjgsIDEyNCwNCiAxNTEsIDE3OCwgMjA3LCAyMCwgMTQs IDE1NCwgMjIyLCAxMTMsIDE3NiwgMjQsIDE5OCwgNzMsIDIxMSwgMTEzLCA5LCAzMywNCiAxNzgs IDgwLCAxMywgMjUsIDIxLCAyNSwgMTUzLCAyMTIsIDIwNiwgNjcsIDE1NCwgMTQ3LCA3MCwgMTk0 LCAxOTIsIDE4MywNCiAxNjAsIDgzLCA5OCwgMjM2LCAxNzUsIDg1LCAyMywgOTcsIDc1LCAxOTks IDE3NywgNzMsIDE0NSwgNTAsIDI1MywgMjA2LA0KIDMyLCAxNzksIDI1NCwgMjM2LCAxOTAsIDgy LCA3MywgNjcsIDEyOSwgMjUzLCAyNTIsIDIyMCwgMTA4LCAxMzYsIDEzOCwgMTEsDQogMTkyLCAx LCAzNiwgMjM5LCAyMjgsIDU1LCA4MSwgMTEzLCAxNywgMjUsIDE0MCwgNjMsIDIzOSwgMTQ2LCAz LCAxNzIsDQogOTYsIDYwLCAyMjcsIDIzMywgNjQsIDI1NSwgMjI0LCAxNzMsIDIyNSwgMjI4LCAy MjksIDkyLCAxMTIsIDcyLCA5OSwgOTcsDQogMjYsIDg3LCAxODcsIDEyMywgNDYsIDUwLCA5MCwg MjAyLCAxMTcsIDczLCAxMCwgMTUzLCA0NywgMjI0LCAxNzgsIDE2MywNCiA3NywgNDgsIDQ2LCAx NTQsIDMzLCAxNDgsIDM0LCAyMjgsIDMzLCAxNzIsIDIxNiwgODksIDQ2LCAyMjUsIDEyNywgNjgs DQogMTQ2LCAyMzQsIDMwLCAxNDcsIDU0LCAxNDYsIDUsIDEzMywgNDUsIDc4LCAyNTQsIDg1LCA1 NSwgNzUsIDIxMywgODYsDQogMTk0LCAyMTgsIDIxNSwgMTYzLCAxODksIDE5NCwgNTQsIDYsIDgz LCAzNiwgMTgsIDE1MywgNTMsIDcsIDQ4LCA4OSwNCiAzNSwgNjYsIDE0NCwgNywgNjUsIDE1NCwg MTMsIDk3LCA3NSwgNTUsIDIzMCwgMTMyLCAzLCAxMywgMjM5LCA3MV0NCkQgKHByaXZhdGUga2V5 IGV4cG9uZW50KQ0KWzg0LCA4MCwgMTUwLCA1OCwgMTY1LCAyMzUsIDI0MiwgMTIzLCAyMTcsIDU1 LCAzOCwgMTU0LCAzNiwgMTgxLCAyMjEsIDE1NiwNCiAyMTEsIDIxNSwgMTAwLCAxNjQsIDkwLCA4 OCwgNDAsIDIyOCwgODMsIDE0OCwgNTQsIDEyMiwgNCwgMTYsIDE2NSwgNDgsDQogNzYsIDE5NCwg MjYsIDEwNywgNTEsIDUzLCAxNzksIDE2NSwgMzEsIDE4LCAxOTgsIDE3MywgNzgsIDYxLCA1Niwg OTcsDQogMjUyLCAxNTgsIDE0MCwgODAsIDYzLCAyNSwgMjIzLCAxNTYsIDM2LCAyMDMsIDIxNCwg MjUyLCAxMjAsIDY3LCAxODAsIDE2NywNCiAzLCA4MiwgMjQzLCAyNSwgOTcsIDIxNCwgODMsIDEz MywgNjksIDE2LCAxMDQsIDU0LCAxNjAsIDIwMCwgNDEsIDgzLA0KIDE2NCwgMTg3LCA3MCwgMTUz LCAxMTEsIDIzNCwgMjQyLCAxNTgsIDE3NSwgMjgsIDE5OCwgNDgsIDIxMSwgNDUsIDE0OCwgNTgs DQogMjMsIDYyLCAyMjcsIDc0LCA1MiwgMTE3LCA0MiwgOTAsIDQxLCAyNDksIDEzMCwgMTU0LCA4 MCwgMTE5LCA2MSwgMjYsDQogMTkzLCA0MCwgMTI1LCAxMCwgMTUyLCAxNzQsIDIyNywgMjI1LCAy MDUsIDMyLCA2MiwgNjYsIDYsIDE2MywgMTAwLCA5OSwNCiAyMTksIDE5LCAyNTMsIDI1LCAxMDUs IDgwLCAyMDEsIDI5LCAyNTIsIDE1NywgMjM3LCA2OSwgMSwgODAsIDE3MSwgMTY3LA0KIDIwLCAx OTYsIDE1NiwgMTA5LCAyNDksIDg4LCAwLCAzLCAxNTIsIDM4LCAxNjUsIDcyLCA4NywgNiwgMTUy LCA3MSwNCiAxNTYsIDIxNCwgMTYsIDcxLCAzMCwgODIsIDUxLCAxMDMsIDc2LCAyMTgsIDYzLCA5 LCA4NCwgMTYzLCAyNDksIDkxLA0KIDIxNSwgNDQsIDIzOCwgODUsIDEwMSwgMjQwLCAxNDgsIDEs IDgyLCAyMjQsIDkxLCAxMzUsIDEwNSwgMTI3LCA4NCwgMTcxLA0KIDE4MSwgMTUyLCAyMTAsIDE4 MywgMTI2LCAyNCwgNDYsIDE5NiwgOTAsIDE3MywgMzgsIDI0NSwgMjE5LCAxODYsIDIyMiwgMjcs DQogMjQwLCAyMTIsIDE5NCwgMTUsIDY2LCAxMzUsIDIyNiwgMTc4LCAxOTAsIDUyLCAyNDUsIDc0 LCA2NSwgMjI0LCA4MSwgMTAwLA0KIDg1LCAyNSwgMjA0LCAxNjUsIDIwMywgMTg3LCAxNzUsIDg0 LCAxMDAsIDgyLCAxNSwgMTEsIDIzLCAyMDIsIDE1MSwgMTA3LA0KIDU0LCA0MSwgMjA3LCAzLCAx MzYsIDIyOSwgMTM0LCAxMzEsIDkzLCAxMzksIDUwLCAxODIsIDIwNCwgOTMsIDEzMCwgODldDQpU aGUgcmVtYWluaW5nIFJTQSBrZXkgcGFyYW1ldGVycyBhcmUgaW5jbHVkZWQgZm9yIGNvbXBsZXRl bmVzcywgYnV0IHNob3VsZCBub3QgYmUgbmVlZGVkDQpEUA0KWzE5NSwgNzMsIDI1LCAxMDksIDk0 LCAxODMsIDExMywgODQsIDExMSwgODUsIDEyNiwgMTc4LCAxNDcsIDExMiwgMTg4LCAxMTIsDQog MjA0LCAxMDQsIDIxOCwgMTYwLCAxNDAsIDIyNSwgMTQzLCAzOSwgMTc4LCAxNzMsIDEwMSwgMTUy LCAxOTYsIDE1MiwgMTMyLCAxMTAsDQogNCwgMTEyLCAxOTAsIDEzMywgODksIDE4MSwgMjQ5LCAx MzUsIDIyMCwgMTc0LCAxOTAsIDEyMCwgNDQsIDIyNiwgMzQsIDE5NiwNCiAyMiwgNzgsIDE1OCwg MCwgMTg2LCAyMCwgNzUsIDEzOSwgMjAwLCA4OCwgNzYsIDI4LCA0NywgMTM5LCAxMTMsIDE5NSwN CiAyMTAsIDIzNiwgODgsIDEyNywgMjQzLCA0MCwgMTQzLCAxNjEsIDE5NCwgMTMyLCA5NCwgMTYw LCAyNTQsIDI1MSwgMTEyLCAyMzEsDQogODIsIDQ3LCAxMjgsIDIxLCAxMTQsIDE4MiwgMTM1LCAx MDcsIDksIDEwMCwgMTY3LCAzOSwgMTE4LCA3NywgMTA0LCAxOTYsDQogMjI5LCAyMzUsIDIyNCwg MTEwLCAyMSwgMTczLCA1OSwgMjUsIDIxNywgMTIxLCAyMzcsIDIyMCwgOTIsIDE0NCwgMTAwLCAy LA0KIDQ2LCAxODQsIDM0LCA3OCwgMTYzLCAxMDMsIDIyLCAyMzksIDE0NywgMjI4LCA4MSwgMjIy LCAxNDUsIDMzLCAxNTYsIDQzXQ0KRFENClsxNjMsIDI1NSwgMjEsIDIxNSwgMTMyLCAxNTgsIDIw NSwgMjAxLCAxNCwgMjMyLCAzNSwgNzUsIDQyLCAyMDcsIDIxOSwgMTgwLA0KIDI0NywgNjksIDEz NiwgMjM5LCAxMjcsIDE0NCwgNDUsIDY3LCAxNzgsIDIyOSwgMTksIDExOSwgOTgsIDE5MiwgMTI0 LCAxMzAsDQogMjEsIDEyMCwgMTk4LCAxMjMsIDE0MiwgMTI1LCA3MCwgMTg2LCAyMDcsIDE5Nywg MTI3LCAxNzYsIDEyMywgMzMsIDkyLCAxMTksDQogMTY3LCAxNDYsIDE3NCwgNCwgOTksIDE0OSwg MjMsIDE5NCwgMjU0LCAxNzAsIDM5LCAyMDMsIDExMSwgMTY5LCAyMDgsIDE1NiwNCiAxODgsIDE3 MiwgMTI4LCAxMTIsIDIyNSwgMjE1LCAxMjUsIDE0MSwgMTQsIDQyLCAyNSwgMTQ2LCAxNywgMjUx LCAxNTIsIDE0MiwNCiAyMjUsIDYwLCAxMTEsIDE0MywgOTYsIDc5LCAyMzIsIDExNiwgMTAsIDc0 LCAxMTgsIDEyMiwgMTMyLCA4LCAxMTcsIDE3NiwNCiAyMDgsIDE1OSwgMTMzLCAyMDgsIDE0OSwg MTY3LCA4MSwgMjIyLCAxMzEsIDIxNiwgMzEsIDI0NSwgNzgsIDI0MSwgMTI1LCAxNTMsDQogMTEy LCA1NCwgNjcsIDMxLCAxNjIsIDI1LCAxMzcsIDI1MiwgNTcsIDg1LCAxMTcsIDYsIDIwMSwgMTY5 LCAyMzQsIDE2NV0NCkludmVyc2VRDQpbMTIwLCAyMTYsIDEwNCwgMjMxLCAzNiwgNjUsIDE2LCAy OCwgOTcsIDI0LCAyNywgODAsIDcxLCAxMiwgNjEsIDY2LA0KIDQyLCAyMTcsIDE3NiwgMzAsIDE4 NiwgNzgsIDE4MywgMTk3LCA2OSwgMjI1LCAxOTEsIDksIDIwMywgOTQsIDM1LCA4NiwNCiAxMzAs IDE1NywgMjI4LCAyNDQsIDE2LCAxNzcsIDE2MSwgOTgsIDg0LCAxMDEsIDEwLCAyMTMsIDM2LCA3 NywgMjMsIDM3LA0KIDMzLCAyNTEsIDEzMiwgNjIsIDk5LCAxMDgsIDUyLCA1MSwgMjE5LCA0Niwg MTMwLCAyMzQsIDE2OCwgMzcsIDExNSwgMTU2LA0KIDg2LCAyMzksIDExNiwgMzAsIDI0MSwgMjQ5 LCA1NywgMTI2LCAxNTUsIDczLCAxMjcsIDEyMCwgODQsIDIyNywgMjE2LCAxNjgsDQogMTcwLCAx OTIsIDEwNiwgMTMyLCAyNDQsIDI0NiwgNjUsIDI0NiwgMTE1LCA4MywgMTkyLCAxOTcsIDExMSwg MzEsIDExNywgODEsDQogNjksIDM0LCAyMTQsIDAsIDQzLCAyMDcsIDE1NywgNDAsIDE3NiwgNjMs IDE5NSwgMTIxLCA4MiwgMjA0LCAxOTAsIDg5LA0KIDIxLCAyMTAsIDI0OSwgOTQsIDIxMSwgMTEw LCAxNTYsIDcyLCAxMzQsIDI0NywgMTY5LCA3NywgMjQxLCA1MiwgNTIsIDIxOF0NClANClsyNDYs IDYsIDU0LCAxOTUsIDE2MiwgNTgsIDc1LCAxNjIsIDI0NCwgMTQyLCAyMjUsIDEwLCAxNzcsIDE4 MywgMTMxLCAzLA0KIDEwLCA5MywgMjQ1LCA5OSwgMzEsIDEzMCwgMTYxLCAxMDQsIDEyMCwgMTUs IDExMSwgMTksIDMzLCAyMCwgMTg2LCA3OCwNCiAzNiwgNDcsIDAsIDc0LCAxMTQsIDEzNSwgMTgx LCAxOTksIDEyOSwgMTk4LCAyMzUsIDIwMCwgMTY0LCAyNDcsIDk1LCAzMywNCiAxMTYsIDUyLCAx MzIsIDI0NiwgMjQwLCAyMDgsIDczLCAxOTksIDAsIDIyMywgMjEsIDE5OSwgNTYsIDEsIDc4LCA2 MCwNCiAxNTksIDE3LCAyNDQsIDcxLCAxMzYsIDEsIDE4MCwgMjI2LCAyMTMsIDkyLCAxLCA5OCwg MTE4LCAyMTEsIDE2NywgMjA2LA0KIDIxNSwgMjUxLCAyMywgMTUsIDkwLCA4MSwgMTUsIDE0Niwg MTgzLCAxMDQsIDgwLCAxNjUsIDE4NiwgMjEwLCAyMTYsIDQ0LA0KIDIxMywgMTYzLCA5MywgMjUy LCAyMTcsIDIyMCwgMjQ0LCAxNzcsIDIxLCA4NCwgMjQzLCAxOCwgMjIzLCAyMjEsIDUxLCAxMDgs DQogOTIsIDEwOSwgMjQxLCA1MSwgMTI3LCAxMTAsIDM4LCAxMjksIDEyOSwgMjMzLCA3NywgMTI5 LCAxNzYsIDE4OSwgMjMwLCAxOTVdDQpRDQpbMTg0LCAxNjksIDY2LCA0MiwgMjQyLCAxNzUsIDI1 MywgMTQ2LCA3NiwgODUsIDE5OSwgNzIsIDE3OSwgMTU1LCAyMTMsIDczLA0KIDc5LCAyNTAsIDEx MiwgMjUxLCA4OCwgMzUsIDg5LCA5OSwgOTEsIDQzLCA2OCwgMTk3LCA5NSwgMjM2LCAxNDYsIDIw MywNCiAxMTEsIDY5LCAzNSwgOTgsIDI0NiwgMTkwLCAxODYsIDE0MSwgMjE1LCAxMjUsIDI1MSwg MzIsIDk3LCA4NSwgMjUxLCAxMzQsDQogMjI2LCAyMDAsIDEwOCwgMTY3LCAxMDQsIDI1MSwgMTcy LCAxMDUsIDIwMCwgMTM4LCAxNDMsIDExNiwgMjEzLCAxNiwgOTQsIDMwLA0KIDE0MiwgMTQ3LCA2 MCwgMTY1LCAxNDksIDg3LCA0MSwgMTUsIDE4NywgODgsIDE1MiwgMTMzLCA1LCAyNDAsIDIxNCwg NTAsDQogMCwgNSwgMjUyLCA2MiwgNDksIDkxLCAxMywgMjUxLCAxMTgsIDIwOCwgMjM5LCAxNjUs IDEzOSwgMTE4LCAyMjEsIDE0NiwNCiAxNSwgMjcsIDcsIDE3OSwgMTg2LCAxODcsIDIwNCwgMjUy LCAxNDgsIDIwMCwgMTE3LCAyMzAsIDE2NiwgMjA2LCAyNDIsIDExMywNCiAxNTgsIDkyLCAyMzks IDEwOCwgNiwgMTQ1LCA3NiwgMTMsIDU4LCA1NCwgMzAsIDE1MCwgMTA1LCAzNCwgNTMsIDQ1XQ0K RU5EIFJTQSBLRVkgUEFSQU1FVEVSUw0KRW5jcnlwdGVkIEtleQ0KWzMyLCAyNDIsIDYzLCAyMDcs IDk0LCAyNDYsIDEzMywgMzcsIDEzNSwgNDgsIDg4LCA0LCAxNSwgMTkzLCA2LCAyNDQsDQogNTEs IDU4LCAxMzIsIDEzMywgMjEyLCAyNTUsIDE2MywgOTAsIDU5LCA4MCwgMjAwLCAxNTIsIDQxLCAy NDQsIDE4OCwgMjE1LA0KIDE3NCwgMTYwLCAyNiwgMTg4LCAyMjcsIDE4MCwgMTY1LCAyMzQsIDE3 MiwgNjMsIDI0LCAxMTYsIDE1MiwgMjgsIDE0OSwgMTYsDQogOTQsIDIxMywgMjAxLCAxNzEsIDE4 MCwgMTkxLCAxMSwgMjEsIDE0OSwgMTcyLCAxNDMsIDU0LCAxOTQsIDU4LCAyMDYsIDIwMSwNCiAx NjQsIDI4LCAxMDcsIDE1NSwgNzUsIDEwMSwgMjIsIDkyLCAyMjcsIDE0NCwgOTUsIDQwLCAxMTks IDE3MCwgNywgMzYsDQogMjI1LCA0MCwgMTQxLCAxODYsIDIxMywgNywgMTc1LCAxNiwgMTc0LCAx MjIsIDc1LCAzMiwgNDgsIDE5MywgMTE5LCAyMDIsDQogNDEsIDE1MiwgMjEwLCAxOTAsIDY4LCA1 NywgMTE5LCA0LCAxOTcsIDc0LCA3LCAyNDIsIDIzOSwgMTcwLCAyMDQsIDczLA0KIDc1LCAyMTMs IDIwMiwgMTEzLCAyMTYsIDE4LCAyMywgNjYsIDEwNiwgMjA4LCA2OSwgMjQ0LCAxMTcsIDE0Nywg MiwgMzcsDQogMjA3LCAxOTksIDE4NCwgOTYsIDEwMiwgNDQsIDcwLCAyMTIsIDg3LCAxNDMsIDI1 MywgMCwgMTY2LCA1OSwgNDEsIDExNSwNCiAyMTcsIDgwLCAxNjUsIDg3LCAzOCwgNSwgOSwgMTg0 LCAyMDIsIDY4LCA2NywgMTc2LCA0LCA4NywgMjU0LCAxNjYsDQogMjI3LCA4OCwgMTI0LCAyMzgs IDI0OSwgNzUsIDExNCwgMjA1LCAxNDgsIDE0OSwgNDUsIDc4LCAxOTMsIDEzNCwgNjQsIDE4OSwN CiAxNjgsIDc2LCAxNzAsIDc2LCAxNzYsIDcyLCAxNDgsIDc3LCAyMTUsIDE1OSwgMTQ2LCA1NSwg MTg5LCAyMTMsIDg1LCAyNTMsDQogMTM1LCAyMDAsIDU5LCAyNDcsIDc5LCAzNywgMjIsIDIwMCwg MzIsIDExMCwgNTMsIDEyMywgNTQsIDM5LCA5LCAxNzgsDQogMjMxLCAyMzgsIDk1LCAyNSwgMjEx LCAxNDMsIDg3LCAyMjAsIDg4LCAxMzgsIDIwOSwgMTMsIDIyNywgNzIsIDU4LCAxMDIsDQogMTY0 LCAxMzYsIDI0MSwgMTQsIDE0LCA0NSwgMzIsIDc3LCA0NCwgMjQ0LCAxNjIsIDIzOSwgMTUwLCAy NDgsIDE4MSwgMTM4LA0KIDI1MSwgMTE2LCAyNDUsIDIwNSwgMTM3LCA3OCwgMzQsIDM0LCAxMCwg NiwgNTksIDQsIDE5NywgMiwgMTUzLCAyNTFdDQpFbmNvZGVkIEVuY3J5cHRlZCBLZXkNCklQSV96 MTcyaFNXSE1GZ0VEOEVHOURNNmhJWFVfNk5hTzFESW1DbjB2TmV1b0JxODQ3U2w2cXdfR0hTWUhK VVFYdFhKcTdTX0N4V1ZySTgyd2pyT3lhUWNhNXRMWlJaYzQ1QmZLSGVxQnlUaEtJMjYxUWV2RUs1 NlN5QXd3WGZLS1pqU3ZrUTVkd1RGU2dmeTc2ck1TVXZWeW5IWUVoZENhdEJGOUhXVEFpWFB4N2hn Wml4RzFGZVBfUUNtT3lsejJWQ2xWeVlGQ2JqS1JFT3dCRmYtcHVOWWZPNzVTM0xObEpVdFRzR0dR TDJvVEtwTXNFaVVUZGVma2plOTFWWDloOGc3OTA4bEZzZ2dialY3TmljSnN1ZnVYeG5UajFmY1dJ clJEZU5JT21ha2lQRU9EaTBnVFN6MG91LVctTFdLLTNUMXpZbE9JaUlLQmpzRXhRS1otdw0KQ2lw aGVydGV4dA0KWzI1MywgMTU5LCAyMjEsIDE0MiwgODIsIDQwLCAxMSwgMTMxLCAzLCA3MiwgMzQs IDE2MiwgMTczLCAyMjksIDE0NiwgMjE3LA0KIDE4MywgMTczLCAxMzksIDEzMiwgNTgsIDEzNywg MzMsIDE4MiwgODIsIDQ5LCAxMTAsIDE0MSwgMTEsIDIyMSwgMjA3LCAyMzksDQogMjA3LCA2NSwg MjEzLCAyOCwgMjAsIDIxNywgMTQsIDE4NiwgODcsIDE2MCwgMTUsIDE2MCwgOTYsIDE0MiwgNywg NjksDQogNDYsIDU1LCAxMjksIDIyNCwgMTEzLCAyMDYsIDU5LCAxODEsIDcsIDE4OCwgMjU1LCAx NSwgMTYsIDU5LCAxODAsIDEwNywNCiA3NSwgMCwgMjE3LCAxNzUsIDI1NCwgOCwgMTQxLCA0OCwg MjE3LCAxMzIsIDE2LCAyMTcsIDQsIDMwLCAyMjMsIDE0N10NCkVuY29kZWQgQ2lwaGVydGV4dA0K X1pfZGpsSW9DNE1EU0NLaXJlV1MyYmV0aTRRNmlTRzJVakZ1alF2ZHotX1BRZFVjRk5rT3VsZWdE NkJnamdkRkxqZUI0SEhPTzdVSHZQOFBFRHUwYTBzQTJhXy1DSTB3MllRUTJRUWUzNU0NClNlY3Vy ZWQgSW5wdXQNCmV5SmhiR2NpT2lKU1UwRXhYelVpTENKbGJtTWlPaUpCTVRJNFEwSkRJaXdpYVc1 MElqb2lTRk15TlRZaUxDSnBkaUk2SWtGNFdUaEVRM1JFWVVkc2MySkhiR3BpTTFKdldsRWlmUS5J UElfejE3MmhTV0hNRmdFRDhFRzlETTZoSVhVXzZOYU8xREltQ24wdk5ldW9CcTg0N1NsNnF3X0dI U1lISlVRWHRYSnE3U19DeFdWckk4Mndqck95YVFjYTV0TFpSWmM0NUJmS0hlcUJ5VGhLSTI2MVFl dkVLNTZTeUF3d1hmS0taalN2a1E1ZHdURlNnZnk3NnJNU1V2VnluSFlFaGRDYXRCRjlIV1RBaVhQ eDdoZ1ppeEcxRmVQX1FDbU95bHoyVkNsVnlZRkNiaktSRU93QkZmLXB1TllmTzc1UzNMTmxKVXRU c0dHUUwyb1RLcE1zRWlVVGRlZmtqZTkxVlg5aDhnNzkwOGxGc2dnYmpWN05pY0pzdWZ1WHhuVGox ZmNXSXJSRGVOSU9tYWtpUEVPRGkwZ1RTejBvdS1XLUxXSy0zVDF6WWxPSWlJS0Jqc0V4UUtaLXcu X1pfZGpsSW9DNE1EU0NLaXJlV1MyYmV0aTRRNmlTRzJVakZ1alF2ZHotX1BRZFVjRk5rT3VsZWdE NkJnamdkRkxqZUI0SEhPTzdVSHZQOFBFRHUwYTBzQTJhXy1DSTB3MllRUTJRUWUzNU0NClNlY3Vy ZWQgSW5wdXQgQnl0ZXMNClsxMDEsIDEyMSwgNzQsIDEwNCwgOTgsIDcxLCA5OSwgMTA1LCA3OSwg MTA1LCA3NCwgODMsIDg1LCA0OCwgNjksIDEyMCwNCiA4OCwgMTIyLCA4NSwgMTA1LCA3NiwgNjcs IDc0LCAxMDgsIDk4LCAxMDksIDc3LCAxMDUsIDc5LCAxMDUsIDc0LCA2NiwNCiA3NywgODQsIDcz LCA1MiwgODEsIDQ4LCA3NCwgNjgsIDczLCAxMDUsIDExOSwgMTA1LCA5NywgODcsIDUzLCA0OCwN CiA3MywgMTA2LCAxMTEsIDEwNSwgODMsIDcwLCA3NywgMTIxLCA3OCwgODQsIDg5LCAxMDUsIDc2 LCA2NywgNzQsIDExMiwNCiAxMDAsIDEwNSwgNzMsIDU0LCA3MywgMTA3LCA3MCwgNTIsIDg3LCA4 NCwgMTA0LCA2OSwgODEsIDUxLCA4MiwgNjksDQogODksIDg1LCAxMDAsIDExNSwgOTksIDUwLCA3 NCwgNzIsIDk4LCA3MSwgMTEyLCAxMDUsIDc3LCA0OSwgNzQsIDExOCwNCiA4NywgMTA4LCA2OSwg MTA1LCAxMDIsIDgxLCA0NiwgNzMsIDgwLCA3MywgOTUsIDEyMiwgNDksIDU1LCA1MCwgMTA0LA0K IDgzLCA4NywgNzIsIDc3LCA3MCwgMTAzLCA2OSwgNjgsIDU2LCA2OSwgNzEsIDU3LCA2OCwgNzcs IDU0LCAxMDQsDQogNzMsIDg4LCA4NSwgOTUsIDU0LCA3OCwgOTcsIDc5LCA0OSwgNjgsIDczLCAx MDksIDY3LCAxMTAsIDQ4LCAxMTgsDQogNzgsIDEwMSwgMTE3LCAxMTEsIDY2LCAxMTMsIDU2LCA1 MiwgNTUsIDgzLCAxMDgsIDU0LCAxMTMsIDExOSwgOTUsIDcxLA0KIDcyLCA4MywgODksIDcyLCA3 NCwgODUsIDgxLCA4OCwgMTE2LCA4OCwgNzQsIDExMywgNTUsIDgzLCA5NSwgNjcsDQogMTIwLCA4 NywgODYsIDExNCwgNzMsIDU2LCA1MCwgMTE5LCAxMDYsIDExNCwgNzksIDEyMSwgOTcsIDgxLCA5 OSwgOTcsDQogNTMsIDExNiwgNzYsIDkwLCA4MiwgOTAsIDk5LCA1MiwgNTMsIDY2LCAxMDIsIDc1 LCA3MiwgMTAxLCAxMTMsIDY2LA0KIDEyMSwgODQsIDEwNCwgNzUsIDczLCA1MCwgNTQsIDQ5LCA4 MSwgMTAxLCAxMTgsIDY5LCA3NSwgNTMsIDU0LCA4MywNCiAxMjEsIDY1LCAxMTksIDExOSwgODgs IDEwMiwgNzUsIDc1LCA5MCwgMTA2LCA4MywgMTE4LCAxMDcsIDgxLCA1MywgMTAwLA0KIDExOSwg ODQsIDcwLCA4MywgMTAzLCAxMDIsIDEyMSwgNTUsIDU0LCAxMTQsIDc3LCA4MywgODUsIDExOCwg ODYsIDEyMSwNCiAxMTAsIDcyLCA4OSwgNjksIDEwNCwgMTAwLCA2NywgOTcsIDExNiwgNjYsIDcw LCA1NywgNzIsIDg3LCA4NCwgNjUsDQogMTA1LCA4OCwgODAsIDEyMCwgNTUsIDEwNCwgMTAzLCA5 MCwgMTA1LCAxMjAsIDcxLCA0OSwgNzAsIDEwMSwgODAsIDk1LA0KIDgxLCA2NywgMTA5LCA3OSwg MTIxLCAxMDgsIDEyMiwgNTAsIDg2LCA2NywgMTA4LCA4NiwgMTIxLCA4OSwgNzAsIDY3LA0KIDk4 LCAxMDYsIDc1LCA4MiwgNjksIDc5LCAxMTksIDY2LCA3MCwgMTAyLCA0NSwgMTEyLCAxMTcsIDc4 LCA4OSwgMTAyLA0KIDc5LCA1NSwgNTMsIDgzLCA1MSwgNzYsIDc4LCAxMDgsIDc0LCA4NSwgMTE2 LCA4NCwgMTE1LCA3MSwgNzEsIDgxLA0KIDc2LCA1MCwgMTExLCA4NCwgNzUsIDExMiwgNzcsIDEx NSwgNjksIDEwNSwgODUsIDg0LCAxMDAsIDEwMSwgMTAyLCAxMDcsDQogMTA2LCAxMDEsIDU3LCA0 OSwgODYsIDg4LCA1NywgMTA0LCA1NiwgMTAzLCA1NSwgNTcsIDQ4LCA1NiwgMTA4LCA3MCwNCiAx MTUsIDEwMywgMTAzLCA5OCwgMTA2LCA4NiwgNTUsIDc4LCAxMDUsIDk5LCA3NCwgMTE1LCAxMTcs IDEwMiwgMTE3LCA4OCwNCiAxMjAsIDExMCwgODQsIDEwNiwgNDksIDEwMiwgOTksIDg3LCA3Mywg MTE0LCA4MiwgNjgsIDEwMSwgNzgsIDczLCA3OSwNCiAxMDksIDk3LCAxMDcsIDEwNSwgODAsIDY5 LCA3OSwgNjgsIDEwNSwgNDgsIDEwMywgODQsIDgzLCAxMjIsIDQ4LCAxMTEsDQogMTE3LCA0NSwg ODcsIDQ1LCA3NiwgODcsIDc1LCA0NSwgNTEsIDg0LCA0OSwgMTIyLCA4OSwgMTA4LCA3OSwgNzMs DQogMTA1LCA3MywgNzUsIDY2LCAxMDYsIDExNSwgNjksIDEyMCwgODEsIDc1LCA5MCwgNDUsIDEx OSwgNDYsIDk1LCA5MCwNCiA5NSwgMTAwLCAxMDYsIDEwOCwgNzMsIDExMSwgNjcsIDUyLCA3Nywg NjgsIDgzLCA2NywgNzUsIDEwNSwgMTE0LCAxMDEsDQogODcsIDgzLCA1MCwgOTgsIDEwMSwgMTE2 LCAxMDUsIDUyLCA4MSwgNTQsIDEwNSwgODMsIDcxLCA1MCwgODUsIDEwNiwNCiA3MCwgMTE3LCAx MDYsIDgxLCAxMTgsIDEwMCwgMTIyLCA0NSwgOTUsIDgwLCA4MSwgMTAwLCA4NSwgOTksIDcwLCA3 OCwNCiAxMDcsIDc5LCAxMTcsIDEwOCwgMTAxLCAxMDMsIDY4LCA1NCwgNjYsIDEwMywgMTA2LCAx MDMsIDEwMCwgNzAsIDc2LCAxMDYsDQogMTAxLCA2NiwgNTIsIDcyLCA3MiwgNzksIDc5LCA1NSwg ODUsIDcyLCAxMTgsIDgwLCA1NiwgODAsIDY5LCA2OCwNCiAxMTcsIDQ4LCA5NywgNDgsIDExNSwg NjUsIDUwLCA5NywgOTUsIDQ1LCA2NywgNzMsIDQ4LCAxMTksIDUwLCA4OSwNCiA4MSwgODEsIDUw LCA4MSwgODEsIDEwMSwgNTEsIDUzLCA3N10NCkludGVncml0eSBWYWx1ZQ0KWzExNSwgMTQxLCAx MDAsIDIyNSwgNjIsIDMwLCAyLCAwLCAxMzAsIDE4MywgMTczLCAyMzAsIDI0MSwgMTQ3LCAxMDIs IDEzNiwNCiAyMzIsIDE2NywgNDksIDIwMCwgMTMzLCAyMywgNDIsIDc4LCAyMiwgMTU1LCAyMjYs IDExOSwgMTg0LCAxODYsIDE1LCA3M10NCkVuY29kZWQgSW50ZWdyaXR5IFZhbHVlDQpjNDFrNFQ0 ZUFnQ0N0NjNtOFpObWlPaW5NY2lGRnlwT0ZwdmlkN2k2RDBrDQpKV0UNCmV5SmhiR2NpT2lKU1Uw RXhYelVpTENKbGJtTWlPaUpCTVRJNFEwSkRJaXdpYVc1MElqb2lTRk15TlRZaUxDSnBkaUk2SWtG NFdUaEVRM1JFWVVkc2MySkhiR3BpTTFKdldsRWlmUS5JUElfejE3MmhTV0hNRmdFRDhFRzlETTZo SVhVXzZOYU8xREltQ24wdk5ldW9CcTg0N1NsNnF3X0dIU1lISlVRWHRYSnE3U19DeFdWckk4Mndq ck95YVFjYTV0TFpSWmM0NUJmS0hlcUJ5VGhLSTI2MVFldkVLNTZTeUF3d1hmS0taalN2a1E1ZHdU RlNnZnk3NnJNU1V2VnluSFlFaGRDYXRCRjlIV1RBaVhQeDdoZ1ppeEcxRmVQX1FDbU95bHoyVkNs VnlZRkNiaktSRU93QkZmLXB1TllmTzc1UzNMTmxKVXRUc0dHUUwyb1RLcE1zRWlVVGRlZmtqZTkx Vlg5aDhnNzkwOGxGc2dnYmpWN05pY0pzdWZ1WHhuVGoxZmNXSXJSRGVOSU9tYWtpUEVPRGkwZ1RT ejBvdS1XLUxXSy0zVDF6WWxPSWlJS0Jqc0V4UUtaLXcuX1pfZGpsSW9DNE1EU0NLaXJlV1MyYmV0 aTRRNmlTRzJVakZ1alF2ZHotX1BRZFVjRk5rT3VsZWdENkJnamdkRkxqZUI0SEhPTzdVSHZQOFBF RHUwYTBzQTJhXy1DSTB3MllRUTJRUWUzNU0uYzQxazRUNGVBZ0NDdDYzbThaTm1pT2luTWNpRkZ5 cE9GcHZpZDdpNkQwaw0K --_004_4E1F6AAD24975D4BA5B168042967394366569F40TK5EX14MBXC283r_-- From mamille2@cisco.com Tue Jun 26 17:46: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 BCD7111E80F5 for ; Tue, 26 Jun 2012 17:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU8wt3-l2qM9 for ; Tue, 26 Jun 2012 17:46:32 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7D11E808D for ; Tue, 26 Jun 2012 17:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=11300; q=dns/txt; s=iport; t=1340757992; x=1341967592; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=G8V26zwO+p+tClaPClWQfIjdSdKlwIoKHDsvS9uahQQ=; b=kAOD1m9sokVTP4mhf9OmMUAlw0nFsAjZw5T6jtriCDBPmtQSFoBUVmsu y19SKCC/6d8wvrKmDGgBCSsc7CTEK66WKacTeaqpLtwkYg2AhJamt5I0N kXAMu1jQpQU8GFSeCRsxZm2KKFGdsm4Ue3a6eBKolMYxlmDycCxBAcv/6 E=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOtW6k+rRDoH/2dsb2JhbABFtjeBB4IYAQEBAwEBAQEPAVsJAgUHBAsOAwQBAQEnBwIlHwkIBhMbB4dkBAyZJaA5izeFKmADiEqFfYZrgRKNC4Fmgn4 X-IronPort-AV: E=Sophos;i="4.77,481,1336348800"; d="sig'?p7s'?scan'208";a="50283425" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Jun 2012 00:46:32 +0000 Received: from sjc-vpn6-1633.cisco.com (sjc-vpn6-1633.cisco.com [10.21.126.97]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5R0kVDL006401; Wed, 27 Jun 2012 00:46:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--473945742" From: Matt Miller In-Reply-To: <00f601cd53ed$ad6eb280$084c1780$@augustcellars.com> Date: Tue, 26 Jun 2012 18:46:30 -0600 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366569B1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <57BD4255-754D-4B6D-A194-587243FF17F3@bbn.com> <00f601cd53ed$ad6eb280$084c1780$@augustcellars.com> To: Jim Schaad Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: 'John Bradley' , "'Richard L. Barnes'" , 'Mike Jones' , 'Brian Campbell' , jose@ietf.org Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 00:46:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--473945742 Content-Type: multipart/signed; boundary=Apple-Mail-1--473945744; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-1--473945744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 26, 2012, at 16:47, Jim Schaad wrote: > >=20 > Note that with my proposal this is somewhat easier. Also given that = we are > dealing with garbage collection systems it is likely that this data = has not > yet disappeared from memory anyway as long as it is referenced. The = header > information is not going to be megabytes in size and all of that = processing > on the headers can be done before you hash and decode the body. >=20 The simplicity of JSON means its appeal is well beyond JavaScript; = assuming there is always a garbage collector is not valid in my opinion. However, I also don't think keeping an extra reference to = base64url-encoded data is prohibitively expensive. It might be = (slightly) more error-prone on the implementor, but again I do not think = is it prohibitively so. - m&m Matt Miller - Cisco Systems, Inc. /me continues goes back to ignoring that other thread (-: > Jim >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Richard L. Barnes >> Sent: Tuesday, June 26, 2012 3:21 PM >> To: Mike Jones >> Cc: John Bradley; Brian Campbell; jose@ietf.org >> Subject: Re: [jose] New Version Notification for = draft-barnes-jose-jsms- >> 00.txt >>=20 >> Sure, multiple signature is easier than multiple recipients. But I > wouldn't call >> it simple. I have to base64url-decode each header to figure out = which one > to >> use (but keep around the encoded version, so I can verify the = signature), >> keep track of the corresponding signature value, and reconstruct the > signed >> body -- all before I can do the actual signature verification. >>=20 >> OTOH, without integrity-protection, you can just have the signature = beside >> all the other parameters, in plain JSON, so that you can just grab = stuff > and go. >>=20 >> =46rom : >>=20 >> verify: function(object) { >> var jsms =3D JSON.parse(object); >> if (!_JOSE_Support.isSignedData(jsms)) { >> throw "Invalid SignedData object"; >> } >>=20 >> // Figure out which signatures are valid >> var validPublicKeys =3D []; >> var sigs =3D jsms.signatures; >> for (var i=3D0; i> var result =3D _JOSE_Crypto.verify_pkcs1_sha256( >> sigs[i].key.n, sigs[i].key.e, jsms.content, > sigs[i].signature) >> if (result =3D "True") { >> validPublicKeys.push(sigs[i].key); >> } >> } >>=20 >> return validPublicKeys; >> } >>=20 >>=20 >>=20 >>=20 >> On Jun 26, 2012, at 6:03 PM, Mike Jones wrote: >>=20 >>> http://tools.ietf.org/html/draft-jones-json-web-signature-json- >> serialization-01 is an existence proof that it's not hard to sign the > parameters >> and have multiple signatures. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>> Of Richard L. Barnes >>> Sent: Tuesday, June 26, 2012 10:46 AM >>> To: Brian Campbell >>> Cc: John Bradley; jose@ietf.org >>> Subject: Re: [jose] New Version Notification for >>> draft-barnes-jose-jsms-00.txt >>>=20 >>> I agree with that goal! I disagree that JWS is a good solution. >>>=20 >>> It is true that JWS provides a relatively simple mechanism for a = single >> signature, but: >>> 1. It could be simpler (see below) >>> 2. JWS header protection is useless for the single-signature case, = and >>> makes the multiple-signature/recipient case harder >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Jun 26, 2012, at 12:16 PM, Brian Campbell wrote: >>>=20 >>>> I wasn't suggesting that integrity-protecting the header itself = makes >>>> things simpler. Rather that a desirable goal is for support of a >>>> relatively simple model utilizing a single signature over the whole >>>> message. And that we already have that in JWS. >>>>=20 >>>> On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes = >> wrote: >>>>>=20 >>>>> On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>>>> I think part of this is that as one of the openID Connect = authors I > look >> at this as a necessary security token format, for OAuth and Connect. >>>>>>>> For that simple processing with one signature is a high = priority > for >> adoption. >>>>>>>=20 >>>>>>> +1. >>>>>>>=20 >>>>>>> A simple JSON friendly model supporting a single signature over >>>>>>> the entire message (including headers) is an important case for >>>>>>> adoption (and security). JWS provides that now and there are >>>>>>> already numerous interoperable JWS implementations available or = in >> the works. >>>>>>=20 >>>>>> I'm not sure how people think that integrity-protecting the = header >> makes things *simpler*, especially since it adds a whole new decoding = step >> and makes the parsing more complicated. >>>>>>=20 >>>>>> Pseudocode without integrity protection (assuming JSMS format, = but >> JWS could be made to look similar): >>>>>> function verify(json) { >>>>>> jose =3D JSON.parse(json); >>>>>> // Check algorithm values >>>>>> return Crypto.SignatureAlgorithm.verify(jose.content, >>>>>> jose.keys[0].signature, jose.keys[0].key); } >>>>>>=20 >>>>>> Pseudocode with integrity protection (assuming JWS format): >>>>>> function verify(jws) { >>>>>> (txtHeader, content, signature) =3D jws.split("\."); >>>>>> protectedBody =3D header + "." + content >>>>>> jsonHeader =3D base64url.decode(txtHeader); >>>>>> header =3D JSON.parse(jsonHeader); >>>>>> return Crypto.SignatureAlgorithm.verify(content, signature, >>>>>> header.jwk); } >>>>>>=20 >>>>>=20 >>>>> Err, sorry, that should read: >>>>> protectedBody =3D txtHeader + "." + content; and >>>>> return Crypto.SignatureAlgorithm.verify(protectedBody, signature, >>>>> header.jwk); >>>>>=20 >>>>> See how hard it is to get right? :) >>>>>=20 >>>>> --Richard >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-1--473945744 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyNzAwNDYz MVowIwYJKoZIhvcNAQkEMRYEFBgMej/44lS8O7+Z6Vs4f0UoYqYbMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQC65RGN7eqckVx+l1rrWmHMQJdMC8XGkdhokOjeXgZZOxsEQa+7YA2gAehU n5lOE00cmR/Oofu181S0eHElmsiSwALi0LCLCsGuV6rBrgHcY3WsogLQKO8mLAD6wC7dKfIgEsiI x0tA6yd3a4OGMypxa+I9cwiK3AE6+MBjMsz75UjlZH+pkKaST6SFHKmSO8cjuJ8D/985rhmcYCCB cXJ3nxCa9cse3pSNBl9vkk7xtzg79QHOzKmLbYtQindMkeMCWyd5IVDyYNEBuw03AvUxAbnNUtSG r/maQ5GyCBVJADYjuN0t8EOPxZUkC3v+IBXhQ/sSJjp7PTZZehUj6u7vAAAAAAAA --Apple-Mail-1--473945744-- --Apple-Mail-2--473945742 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP6lfnAAoJEJq6Ou0cgrSP/P0IAM1lcLFB1eiacQ7ShsmFv58u eGI8w3CtlLyr6BFOtCLtir7ebiWuKjMb/BUb8av1IaHvHvvB5cJmDF8BlqCGt/Do XWWM9yty3yB2N0YC4D+XX0Pq2qgaENg1b17m+WrBcp1fiuy+lW+lbRfvpnVb7wa1 fAYMFrQjafFb/zNwuiuM+/nBFDcKZRjXf4/vBwZM8Nt2qvL5Q9MqotLXdnG5FGEO VONZCy5JzrUT1LiV4SoD+Z2R29ZUpsBGJOWZ4a+l1Ffq57bkYNuTZhUSOT0SotQi +GnByDvB09tK01GyNgnVg6tFNBiOHewY03TRSNA8jq2TuCnHHcQCkyUtJdJDKgE= =LekW -----END PGP SIGNATURE----- --Apple-Mail-2--473945742-- From James.H.Manger@team.telstra.com Tue Jun 26 19:18:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A1D11E80F3 for ; Tue, 26 Jun 2012 19:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as8HyPvEZL9I for ; Tue, 26 Jun 2012 19:18:21 -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 9766F11E80EF for ; Tue, 26 Jun 2012 19:18:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,481,1336312800"; d="scan'208";a="79744433" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 12:18:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6754"; a="81456010" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcavi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 12:18:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 27 Jun 2012 12:18:18 +1000 From: "Manger, James H" To: "Richard L. Barnes" Date: Wed, 27 Jun 2012 12:18:17 +1000 Thread-Topic: protected attributes Thread-Index: Ac1T0poYUHV/gjjpTk6SDSOaTh8D7gAM8mDg Message-ID: <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> In-Reply-To: <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.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 Cc: "jose@ietf.org" Subject: [jose] protected attributes 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, 27 Jun 2012 02:18:21 -0000 UmljaGFyZCBCYXJuZXMgd3JvdGUgKGluIHRoZSB0aHJlYWQgIlJlOiBbam9zZV0gTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcglkcmFmdC1iYXJuZXMtam9zZS1qc21zLTAwLnR4dCIpOg0KPiBZ b3UgY2FuIGhhdmUgc29tZXRoaW5nIGxpa2UgSldUIHNwZWNpZnkgYQ0KPiBib2R5IGZvcm1hdCB0 aGF0IGhhcyB0aGUgcHJvdGVjdGVkIHBhcmFtZXRlcnMsIHNvIHdoeSBkb2VzIEpXUy9KV0UgbmVl ZA0KPiBpbnRlZ3JpdHktcHJvdGVjdGVkIGF0dHJpYnV0ZXM/DQoNCg0KT25lIGF0dHJpYnV0ZSBp cyB3aGV0aGVyIG9yIG5vdCB0aGUgY29udGVudCBvZiB0aGlzIEpXUy9KV0UgaXMgYW5vdGhlciBK V1MvSldFLiBUaGlzIGF0dHJpYnV0ZSBpcyBtb3JlIGEgcGFydCBvZiB0aGUgSldTL0pXRSBwcm9j ZXNzaW5nIHRoYW4gbWV0YWRhdGEgZm9yIHRoZSBjb250ZW50Lg0KDQpGb3IgaW5zdGFuY2UsIGlm IGEgc2VuZGVyIHNpZ25zLXRoZW4tZW5jcnlwdHMgY29udGVudCBpdCB3b3VsZCBiZSBnb29kIGlm IGFuIGF0dGFja2VyIGNhbm5vdCBjaGFuZ2UgaXQgdG8gYXBwZWFyIHRvIGJlIGp1c3QgZW5jcnlw dGVkIGNvbnRlbnQuDQoNCklzIGl0IHRvbyB1bmxpa2VseSB0aGF0IGEgcmVjZWl2aW5nIGFwcCB3 aWxsIG1pc3Rha2UgYSBKV1MgZm9yIHRoZSBjb250ZW50IGl0IGV4cGVjdGVkPyBJZiBhbiBhcHAg ZXhwZWN0ZWQgYSBKU09OIG9iamVjdCBhcyB0aGUgY29udGVudCAoZWcgYXMgcGVyIEpXVCkgYnV0 IGdvdCBhIEpXUywgaXMgaXQgY29uY2VpdmFibGUgdGhhdCBpdCBjb3VsZCBtaXN0YWtlIHRoZSBK V1MgaGVhZGVyIGZvciB0aGUgSldUPw0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From ve7jtb@ve7jtb.com Wed Jun 27 10:15:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB52E11E8108 for ; Wed, 27 Jun 2012 10:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yxD+BZb8OqA for ; Wed, 27 Jun 2012 10:15:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50411E80FA for ; Wed, 27 Jun 2012 10:15:50 -0700 (PDT) Received: by yenq13 with SMTP id q13so1245590yen.31 for ; Wed, 27 Jun 2012 10:15:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SFBqfA/OXIsk3OS1PeERkfl/hANEX0XitFy/uCAGVgc=; b=YXlXIpB1y/2s2reLoB+//TnCVz69g+lpQEkyNjyZqDN/9w1LUX8w2sX1cV0937iXCI cbz4UsQyv9I4vR7IpLh0XbDzBufNQ2j78ahH9CefV/Ljwkdv315JzwQp4ucvqDiUEGcK LaVbDqsdWyaCWDLmxSjarnJyjjPUoOr5/wk++3oprJUTEIFlBccXxcGMMaT/dBssVRfQ LeLDlhHGQz41h/lX0+nun4kZGF1VEo+knTifv6ped8SaoIkXiwOhJA7PVKmx3S9oSVu9 EytoSLQ93siPGk3T6iSSwaKjvlb56vakKZS6QN5sADdTo0kkRoe+ZXTpAy6jvpasATGT Ohkw== Received: by 10.236.181.199 with SMTP id l47mr23572746yhm.85.1340817349548; Wed, 27 Jun 2012 10:15:49 -0700 (PDT) Received: from [192.168.1.213] (190-20-41-237.baf.movistar.cl. [190.20.41.237]) by mx.google.com with ESMTPS id f68sm80257536yhh.22.2012.06.27.10.15.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 10:15:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_307E00E2-2214-40BD-8A85-704B861D6814"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <7CFB9DEF-2DC8-4281-B136-2980C48478C9@bbn.com> Date: Wed, 27 Jun 2012 13:15:39 -0400 Message-Id: <1314251A-FA9B-4603-8174-AAAF8EC080C5@ve7jtb.com> References: <20120622130024.28609.34390.idtracker@ietfa.amsl.com> <19782DF6-5C13-4C9A-90D1-896192079345@cisco.com> <815ADED0-B219-4A8B-81DB-4AA26AF3FF94@ve7jtb.com> <5B756C5A-6A04-4170-A5F8-E280D2047697@ve7jtb.com> <52EB70BE-3FC3-474B-A39F-AF5717669DA5@bbn.com> <4D6646FD-8387-46D7-BF8E-93D8D665E825@ve7jtb.com> <21024B94-9C43-4704-9D68-53BEE84D92F5@ve7jtb.com> <2A8A4F3B-CD0D-48C5-8A65-49A2E8C4D096@bbn.com> <6821E712-0D0D-419B-9E15-789DE54798A9@ve7jtb.com> <019D2416-9DC2-43F4-A9E5-A2214195AA71@bbn.com> <7CFB9DEF-2DC8-4281-B136-2980C48478C9@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkIB8o5xSosij0M9qO7SB6Xvdw4Fb5RpaxvvIrAA+K7c7LNFE1XssmEdGuSEZVtsqAkXD5Q Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-miller-xmpp-e2e-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: Wed, 27 Jun 2012 17:15:52 -0000 --Apple-Mail=_307E00E2-2214-40BD-8A85-704B861D6814 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Richard, Matt's spec used some elements from JWE but violated the JWE spec in = several ways. =20 It is a early draft so I am not criticizing it, as a draft it served a = purpose in generating comments. We have both made suggestions on how it could be improved. =20 Security is quite often not a binary issue, any algorithm can be = compromised given enough time. The question is how much time and effort t is required by an attacker. Integrity protection of the header arguably raises the bar for an = attacker in many situations (perhaps not all). Matt could have easily integrity protected the header by including it in = the Additional Authenticated Data (AAD) for AES-CCM. The integrity protection over the header would not have compromised = anything else in the spec as far as I can see. Regards John B. On 2012-06-27, at 7:21 AM, Richard L. Barnes wrote: >> You still haven't answered my question: Does Matt's document, as is, = compromise the security of JWE? >=20 > I'll stop bothering you on list after this round, but this really is = the crucial question. >=20 > If you think that header protection is a required security mechanism, = then Matt's document is insecure. >=20 > If you think Matt's document is secure, then header protection should = not be required. >=20 > --Richard >=20 >=20 >=20 >=20 >>=20 >>=20 >> On Jun 26, 2012, at 4:58 PM, John Bradley wrote: >>=20 >>> I would prefer to let Matt update his spec before further dragging = him into this. >>>=20 >>> I have always been for having multiple recipients, I raised the = issue with JWE before the JOSE work group. >>>=20 >>> I just want to do that without overly complicating the simple case. >>>=20 >>> The question is how to do it. I and others prefer maintaining the = integrity protection over both the header and content. =20 >>> I prefer to find a way to have both integrity and multiple = recipients. >>=20 >> As I've noted previously, you can have integrity and multiple = recipients, but it costs you something: >> -- Efficiency:=20 >> -- You have to re-process the entire message body for every = recipient, not just the key >> -- The message has to carry separate base64url-encoded headers for = each recipient >> -- The recipient has to decode each header to figure out which is = his >> -- Scalability:=20 >> -- If you want to be able to add a recipient later, you have to = cache the whole message >> -- Security:=20 >> -- If you want to be able to add a recipient, you have to cache the = message in plaintext >> -- Prefixing the signed body with a header creates vulnerabilities = to prefix-based attacks >>=20 >> Some of these get better if you use canonicalization instead of = base64url-encoding, but given that nobody has yet articulated a clear = benefit, I'm not sure why it's worth the trouble. >>=20 >>=20 >>> As I stated Jim's proposal has some good ideas and doesn't require = scrapping integrity. >>>=20 >>> I appreciate that you are approaching this from the CMS perspective, = though the correct thing to do in CMS with integrity protecting = attributes in CMS seems to also have multiple opinions. >>=20 >> I'm happy to support header integrity as an *optional* mechanism. = (Indeed, there's no way you can prevent someone from, say, copying = headers in the body to integrity-protect them.) I just don't think it = should be *mandatory*. If you want to mandate it for JWT, that's fine. = But it shouldn't be required in the general-purpose format. =20 >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>> Regards >>> John B. >>>=20 >>> On 2012-06-26, at 3:30 PM, Richard L. Barnes wrote: >>>=20 >>>>>> Alternatively, you could provide a whole JSMS EncryptedData = object on the first shot, with WrappedKeys for keys you know. Then, if = a recipient doesn't find a WrappedKey for himself, he can for = it, and you can just respond with the WrappedKey. >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>> That is what I was trying to get at. The existing spec supports = sending the wrapped content key with a keyid. >>>>>=20 >>>>> You send that with every message, if the recipient doesn't have = the necessary key it requests it. >>>>>=20 >>>>> The receiver retrieves the key and unwraps the CMK. There is = nothing in the current spec that stops that from working. >>>>>=20 >>>>> The message and integrity are based on the wrapped key. That is = the decision the WG took a while ago. >>>>>=20 >>>>> Having multiple recipients each with a different symmetric or = asymmetric key used to wrap the CMK is slightly different problem. >>>>=20 >>>> Obviously, JWE key wrapping works for single recipients. I don't = contest that. Multiple recipients is the problem. =20 >>>>=20 >>>> Unless you want to support multiple recipients, there's no point to = Matt's scheme. It's tempting to think that it addresses the case where = the sender doesn't know the single recipient's key in advance, but in = that case, it would be much simpler just to have the sender request the = key at the start. So the whole point of Matt's document is to support = multiple recipients, at the cryptographic layer, even if not at the XMPP = layer (a given JID might have multiple keys, e.g., per device). >>>>=20 >>>> Anyway, you skipped the important question in my mail: Do you think = that Matt's scheme compromises the security of the JWE? >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Jim's proposal for having multiple recipients in the header has = potential, I don't support everything in it but it contributes some = useful ideas to support multiple recipient and signature use cases. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 25, 2012, at 7:02 PM, John Bradley wrote: >>>>>>=20 >>>>>>> Richard, >>>>>>>=20 >>>>>>> There was some other back and for with Matt. >>>>>>>=20 >>>>>>> He is only encrypting to one recipient at a time. >>>>>>>=20 >>>>>>> Not that encrypting the CMK to multiple recipients is not valid, = that is just not how the protocol works. >>>>>>>=20 >>>>>>> The message is encrypted once and whatever endpoint gets it = calls back to the sender to get the key. >>>>>>>=20 >>>>>>> The issue as I understand it is that the sender doesn't know the = public key for the recipient before it sends the message. >>>>>>>=20 >>>>>>> I am happy to work on Matts issues, but I think they are = separate from the point you are making on integrity protecting the = header. >>>>>>>=20 >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>> On 2012-06-25, at 6:12 PM, Richard L. Barnes wrote: >>>>>>>=20 >>>>>>>>> Having read Matt's spec, he is not breaking JWE to send to = multiple recipients. As the spec says: >>>>>>>>> "This document specifies an approach for encrypting = communications between two entities which each might have multiple = end-points" >>>>>>>>=20 >>>>>>>> He isn't a JWE-provided facility for addressing to multiple = recipients; he had to roll his own. He shouldn't have to; the JOSE = format should support that. >>>>>>>>=20 >>>>>>>> Compare JSMS and the WrappedKey structure, or CMS and = RecipientInfo. >>>>>>>> = >>>>>>>> >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> I should also point out that the messages are transported in = XML, and as such, the addition of a JSON wrapper for the JWE probably is = not useful as it would need escaping anyway. By not sending the CMK as = part of the message, you get a small reduction in message size, but you = increase the number of separate key transport messages required. In = any event it has nothing to do with integrity protecting the header. >>>>>>>>>=20 >>>>>>>>> There are two somewhat separate uses for JWE in the spec: one = for encrypting the messages themselves using symmetric keys, and another = using asymmetric keys for requesting symmetric keys. >>>>>>>>>=20 >>>>>>>>> For the transmission of the messages, I can't see any reason = to not use the JWE spec as currently written. It certainly supports = the use case without modification. Matt's creative use of "none" as the = algorithm is not required and likely only requires a short conversation = to sort out. >>>>>>>>>=20 >>>>>>>>> Currently the message on the wire looks like: >>>>>>>>>=20 >>>>>>>>> >>>>>>>> from=3D'juliet@capulet.lit/balcony' >>>>>>>>> id=3D'fJZd9WFIIwNjFctT' >>>>>>>>> to=3D'romeo@montegue.lit/garden' >>>>>>>>> type=3D'chat'> >>>>>>>>> >>>>>>>> id=3D'835c92a8-94cd-4e96-b3f3-b2e75a438f92'> >>>>>>>>>
>>>>>>>>> eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS >>>>>>>>> HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX >>>>>>>>> NpemUiOiIxNiJ9 >>>>>>>>>
>>>>>>>>> >>>>>>>>> 7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO >>>>>>>>> 9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41 >>>>>>>>> wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME >>>>>>>>> KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk >>>>>>>>> RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0 >>>>>>>>> 1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O >>>>>>>>> LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg >>>>>>>>> g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti >>>>>>>>> JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7 >>>>>>>>> TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD >>>>>>>>> MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g >>>>>>>>> E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo- >>>>>>>>> eCGP >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> I would have sent header and data as one element using the = normal JWE dot separated format, but I need to talk to Matt to = understand his reasoning. >>>>>>>>>=20 >>>>>>>>> I note that his example is using AES-CCM, and so not = documented in JWA. That isn't a big deal if we want to add it. CCM = supports extra authenticated data and outputs an authentication tag like = GCM. In CMS RFC 5084, the tag seems to be carried separately from the = encrypted data and in RFC 3610, the tag is concatenated to the encrypted = data. If we want to support CCM, then we need to pick one of the ways = to transport the tag info. Either would work. We would just need to = define that the integrity element contains a zero byte string as Matt = has, if we want to concatenate the integrity tag value after the = ciphertext. >>>>>>>>=20 >>>>>>>> Valid point. I had missed that RFC 5084 handled the ICV = separately. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> I don't quite get your point on integrity protecting the = wrapped key causing the integrity value to change. For HMAC, GCM, and = I think CCM, changing the encryption key changes the tag value anyway = (sort of the point I thought). The only time it would stay the same = would be if you were just using a MAC over the body and that is a touch = useless for integrity protection. Perhaps I am missing the point, but = as far as I know even without protecting the header, the tag value is = different for every key (and nonce/IV). >>>>>>>>=20 >>>>>>>> The point is that you have to re-compute the ICV over the = entire header+content every time you wrap a new key. This is kind of a = big deal for the XMPP case. =20 >>>>>>>>=20 >>>>>>>> Imagine I send a long message in Matt's system: With integrity = protection on the parameters, the XMPP entity doing the wrapping has to = cache the entire header and message (alongside the CMK), and reprocess = the whole thing when somebody asks for a key. Without it, all I need = cache is the message ID and CMK, and just re-wrap the CMK when someone = asks. For big messages, we're talking orders of magnitude more state. = And in addition, it has to cache the message in *plaintext*, which = creates serious operational security risks. >>>>>>>>=20 >>>>>>>> So integrity protecting the headers has real costs in terms of = both scalability (state) and security. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> There are some interesting things Matt=92s spec is attempting = with using asymmetrically encrypted/signed JWE/JWS as a key transport = protocol. I need to go through that more closely. >>>>>>>>=20 >>>>>>>> My point is that we shouldn't need a whole new protocol for = this. CMS RecipientInfos do exactly what we want. (Er, what *Matt* = wants.) We should just be copying and pasting. >>>>>>>>=20 >>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am happy to work with Matt to refine his ID. >>>>>>>>>=20 >>>>>>>>> I recommend others read it as well so we can understand if = there are any real issues. >>>>>>>>>=20 >>>>>>>>> Regards >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>> On 2012-06-22, at 3:34 PM, Richard L. Barnes wrote: >>>>>>>>>=20 >>>>>>>>>> Hey John, >>>>>>>>>>=20 >>>>>>>>>> I think you're missing the bigger point here, which is: In = order to allow for multiple recipients, Matt had to break JWE. >>>>>>>>>>=20 >>>>>>>>>> This is yet another reason to abandon integrity protection = for cryptographic parameters. Namely, it makes allowing for multiple = recipients much harder than it needs to be. If you integrity-protect = the wrapped key, then you need to change the integrity value whenever = you wrap the key for a new recipient. In addition to increasing = overhead in computing and communicating objects for multiple recipients, = now you've locked yourself out of algorithms that don't have a separate = integrity check value, such as AES-CCM. >>>>>>>>>>=20 >>>>>>>>>> --Richard >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Jun 22, 2012, at 12:12 PM, John Bradley wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Matt, >>>>>>>>>>>=20 >>>>>>>>>>> Complements on updating the draft. >>>>>>>>>>>=20 >>>>>>>>>>> The issue I see is that you are attempting to distribute the = CMK out of band and use "none" as the alg. >>>>>>>>>>>=20 >>>>>>>>>>> There has been a fair amount of discussion on this. In some = earlier JWE drafts before mandatory integrity you could directly = encrypt/decrypt with the out of band shared secret. >>>>>>>>>>>=20 >>>>>>>>>>> Based on JSMS and mandatory integrity we adopted having a = CMK always included in the message to allow for rotation. =20 >>>>>>>>>>> =46rom a implementation point of view the symmetric cypher = always gets the CEK derived from the CMK in the message independent of = if it is using RSA or A128KW/A256KW. >>>>>>>>>>>=20 >>>>>>>>>>> That imposes some extra steps for people using symmetric = keys but encourages rotation of the CEK that would likely not happen = otherwise. >>>>>>>>>>>=20 >>>>>>>>>>> So in your spec I would expect you to distribute a shared = secret via keyreq for use in A256KW and be using that decrypt the CMK at = the receiver. >>>>>>>>>>>=20 >>>>>>>>>>> I also suspect that you intended to use A256GCM as the enc = alg and not A256CCM.=20 >>>>>>>>>>>=20 >>>>>>>>>>> I am not a XMPP expert so it will take me some time to go = over it in detail. I would like to understand the use case to be = certain it is properly supported. >>>>>>>>>>>=20 >>>>>>>>>>> Regards >>>>>>>>>>> John B. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2012-06-22, at 9:20 AM, Matt Miller wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> FYI, a proposal for XMPP E2E, using JOSE. This has been = updated to the latest JOSE WG drafts. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> - m&m >>>>>>>>>>>>=20 >>>>>>>>>>>> Matt Miller - >>>>>>>>>>>> Cisco Systems, Inc. >>>>>>>>>>>>=20 >>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>=20 >>>>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>>>>> Date: June 22, 2012 07:00:24 MDT >>>>>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>>>>> Subject: I-D Action: draft-miller-xmpp-e2e-01.txt >>>>>>>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) >>>>>>>>>>>>> Author(s) : Matthew Miller >>>>>>>>>>>>> Filename : draft-miller-xmpp-e2e-01.txt >>>>>>>>>>>>> Pages : 22 >>>>>>>>>>>>> Date : 2012-06-21 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>>>>>>> This document defines a method of end-to-end object = encryption for >>>>>>>>>>>>> the Extensible Messaging and Presence Protocol (XMPP). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >>>>>>>>>>>>>=20 >>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-01 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A diff from previous version is available at: >>>>>>>>>>>>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-01 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> I-D-Announce mailing list >>>>>>>>>>>>> I-D-Announce@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>> Internet-Draft directories: = http://www.ietf.org/shadow.html >>>>>>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jose mailing list >>>>>>>>>>>> jose@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jose mailing list >>>>>>>>>>> jose@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_307E00E2-2214-40BD-8A85-704B861D6814 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NzE3MTU0MFowIwYJKoZIhvcNAQkEMRYEFEpFtWyoHYBpGqhctUIs300iiFYBMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AEU+M4XweYj63mJAWK+0BL3Gj2v9MwXE5lO90LCqdlLZ5iIz/f4hX1B27EWWVJRBk+pP3jsE6xmx oxq/BnwyLP7aijkVq7KQn4BDo6mVOV300hfXN057foDMVXOr4HgBWETicfrGH4hlagM+fyJcRNG8 /ijQ+A7uNZZT+hq9xkqEVNQTrqEKhM8B0b5CpN8HO+Shy3ZS0m6IdEZOj7xMQDrm7W0QTbRFGIY2 BzAl0mUDNzuJXcsR6SC+nc0w+gMoCjZEEOU/xKxrueDyazjnJWovjdGjkXs/YcyXFFsYj1xECBJJ L/vJHzqVJyGKxEfdUbio15oSwtsWdl5YJ8c/4iEAAAAAAAA= --Apple-Mail=_307E00E2-2214-40BD-8A85-704B861D6814-- From rbarnes@bbn.com Wed Jun 27 18:40: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 A496711E8165 for ; Wed, 27 Jun 2012 18:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.854 X-Spam-Level: X-Spam-Status: No, score=-105.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsEP2dfQ6lqK for ; Wed, 27 Jun 2012 18:40:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 133EE11E8155 for ; Wed, 27 Jun 2012 18:40:43 -0700 (PDT) Received: from [128.89.253.234] (port=63163) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sk3ir-0001Vh-Pe; Wed, 27 Jun 2012 21:40:41 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 27 Jun 2012 21:40:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7915E1F6-0C3D-4131-A4F6-93AE6C4D6717@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Complete JWE computation example 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, 28 Jun 2012 01:40:44 -0000 This is really a comment against the JWE spec, but I'll go ahead and = mention it here: How is the recipient of this object supposed to know that public key to = use to verify the object? On Jun 26, 2012, at 8:32 PM, Mike Jones wrote: > Dear working group members, > =20 > For the next round of the JOSE JWE spec, I=92m adding example = encryption computations to aid implementers. An example JWE computation = is included below, in case you=92d like to compare your implementations = against these. These values have already been verified by two = independent implementations. > =20 > This example uses the header values: > = {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZQ= "} > =20 > As such, there are actually several different things that this example = verifies: > - RSA encryption of the CMK > - Deriving the CEK and CIK from the CMK (in this case, using the = same values as EXAMPLE 1 from my Key Derivation message) > - AES-CBC encryption of the plaintext > - Calculation of the integrity value > =20 > Note that because RSA PKCS #1-1.5 padding uses random values, the = encrypted CMK value will not be repeatable, although all resulting = values will be decryptable to retrieve the original CMK value. > =20 > All relevant values should be present below. For the RSA key = parameters, the field names used are the ones from the .NET = RSAParameters structure documented = athttp://msdn.microsoft.com/en-us/library/system.security.cryptography.rsa= parameters_members(v=3Dvs.71). > =20 > Enjoy, > -- = Mike > =20 > CMK > [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, = 206, > 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, = 207] > CEK > [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, = 50, 69] > CIK > [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, = 122, > 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, = 159] > IV > [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, = 101] > Plaintext > [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109, = 101, 32, > 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 109, 101, = 110, > 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 104, 101, = 32, > 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, 99, 111, = 117, > 110, 116, 114, 121, 46] > Header > = {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZQ= "} > Header Bytes > [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 34, 44, > 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34, 44, > 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34, 105, > 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, 115, > 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125] > Encoded Header > = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ > BEGIN RSA KEY PARAMETERS > Exponent > [1, 0, 1] > Modulus > [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12, 224, 19, = 226, > 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108, 185, = 234, > 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, 6, = 224, > 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144, 215, = 110, > 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, = 124, > 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, 113, 9, = 33, > 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194, 192, = 183, > 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, 253, = 206, > 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, 136, 138, = 11, > 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 172, > 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, 72, 99, = 97, > 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224, 178, = 163, > 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, 127, 68, > 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, 213, 86, > 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 89, > 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239, 71] > D (private key exponent) > [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 181, 221, = 156, > 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16, 165, 48, > 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, 56, 97, > 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, 67, 180, = 167, > 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, 41, 83, > 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, 45, 148, = 58, > 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119, 61, 26, > 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, = 99, > 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80, 171, = 167, > 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 152, 71, > 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, 91, > 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 127, 84, = 171, > 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, 186, 222, = 27, > 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 224, 81, = 100, > 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202, 151, = 107, > 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, 130, = 89] > The remaining RSA key parameters are included for completeness, but = should not be needed > DP > [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, 112, 188, = 112, > 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 196, 152, = 132, 110, > 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, 226, 34, = 196, > 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 113, 195, > 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254, 251, = 112, 231, > 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77, 104, = 196, > 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, 144, 100, = 2, > 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 33, 156, = 43] > DQ > [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, 207, 219, = 180, > 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 192, 124, = 130, > 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123, 33, 92, = 119, > 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 169, 208, = 156, > 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, 251, 152, = 142, > 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8, 117, = 176, > 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78, 241, = 125, 153, > 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169, 234, = 165] > InverseQ > [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, 61, 66, > 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94, 35, 86, > 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 77, 23, = 37, > 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37, 115, = 156, > 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 227, 216, = 168, > 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111, 31, = 117, 81, > 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204, 190, 89, > 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, 52, 52, = 218] > P > [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 183, 131, = 3, > 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20, 186, 78, > 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 247, 95, = 33, > 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1, 78, 60, > 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211, 167, = 206, > 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 210, 216, = 44, > 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, 221, 51, = 108, > 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, 189, 230, = 195] > Q > [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, 155, 213, = 73, > 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, 146, 203, > 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 85, 251, = 134, > 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 213, 16, = 94, 30, > 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240, 214, = 50, > 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118, 221, = 146, > 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, 206, 242, = 113, > 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, 53, 45] > END RSA KEY PARAMETERS > Encrypted Key > [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, 244, > 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, 188, = 215, > 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 28, 149, = 16, > 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, 58, 206, = 201, > 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 170, 7, 36, > 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193, 119, = 202, > 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170, 204, 73, > 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 147, 2, = 37, > 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59, 41, = 115, > 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254, 166, > 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, 134, 64, = 189, > 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 213, 85, = 253, > 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, 178, > 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58, = 102, > 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, 181, = 138, > 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, 251] > Encoded Encrypted Key > = IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_Cx= WVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rM= SUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3= LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNI= OmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w > Ciphertext > [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, 146, = 217, > 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, 207, = 239, > 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142, 7, 69, > 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59, 180, = 107, > 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 223, 147] > Encoded Ciphertext > = _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7= UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > Secured Input > = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK5= 6SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2= VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsg= gbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-= w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHO= O7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > Secured Input Bytes > [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 120, > 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, > 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53, 48, > 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 74, 112, > 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 82, 69, > 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 74, 118, > 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 50, 104, > 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 104, > 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 118, > 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 95, 71, > 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 67, > 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, 97, > 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 66, > 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 83, > 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 53, = 100, > 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118, 86, 121, > 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 84, 65, > 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101, 80, 95, > 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89, 70, 67, > 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, 89, 102, > 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71, 81, > 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101, 102, = 107, > 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 108, 70, > 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 102, 117, = 88, > 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78, 73, 79, > 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122, 48, 111, > 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79, 73, > 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, 95, 90, > 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, 114, 101, > 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 85, 106, > 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99, 70, 78, > 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, 70, 76, = 106, > 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69, 68, > 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50, 89, > 81, 81, 50, 81, 81, 101, 51, 53, 77] > Integrity Value > [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, 102, = 136, > 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, 15, = 73] > Encoded Integrity Value > c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k > JWE > = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK5= 6SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2= VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsg= gbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-= w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHO= O7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7= i6D0k > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Wed Jun 27 18:41: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 56E4A11E8168 for ; Wed, 27 Jun 2012 18:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqyziRldyz6E for ; Wed, 27 Jun 2012 18:41:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 877F611E8165 for ; Wed, 27 Jun 2012 18:41:43 -0700 (PDT) Received: from [128.89.253.234] (port=63164) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sk3jq-0001Wl-TR; Wed, 27 Jun 2012 21:41:43 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Richard L. Barnes In-Reply-To: <7915E1F6-0C3D-4131-A4F6-93AE6C4D6717@bbn.com> Date: Wed, 27 Jun 2012 21:41:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> <7915E1F6-0C3D-4131-A4F6-93AE6C4D6717@bbn.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Complete JWE computation example 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, 28 Jun 2012 01:41:45 -0000 > This is really a comment against the JWE spec, but I'll go ahead and = mention it here: >=20 > How is the recipient of this object supposed to know that public key = to use to verify the object? s/public key/private key/ s/verify/decrypt/ Sorry, was thinking JWS. Same comment applies to JWS, though, IIRC. --Richard >=20 >=20 >=20 > On Jun 26, 2012, at 8:32 PM, Mike Jones wrote: >=20 >> Dear working group members, >>=20 >> For the next round of the JOSE JWE spec, I=92m adding example = encryption computations to aid implementers. An example JWE computation = is included below, in case you=92d like to compare your implementations = against these. These values have already been verified by two = independent implementations. >>=20 >> This example uses the header values: >> = {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZQ= "} >>=20 >> As such, there are actually several different things that this = example verifies: >> - RSA encryption of the CMK >> - Deriving the CEK and CIK from the CMK (in this case, using the = same values as EXAMPLE 1 from my Key Derivation message) >> - AES-CBC encryption of the plaintext >> - Calculation of the integrity value >>=20 >> Note that because RSA PKCS #1-1.5 padding uses random values, the = encrypted CMK value will not be repeatable, although all resulting = values will be decryptable to retrieve the original CMK value. >>=20 >> All relevant values should be present below. For the RSA key = parameters, the field names used are the ones from the .NET = RSAParameters structure documented = athttp://msdn.microsoft.com/en-us/library/system.security.cryptography.rsa= parameters_members(v=3Dvs.71). >>=20 >> Enjoy, >> -- = Mike >>=20 >> CMK >> [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, = 206, >> 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, = 207] >> CEK >> [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, = 50, 69] >> CIK >> [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, = 122, >> 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, = 159] >> IV >> [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, = 101] >> Plaintext >> [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109, = 101, 32, >> 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 109, = 101, 110, >> 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 104, 101, = 32, >> 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, 99, 111, = 117, >> 110, 116, 114, 121, 46] >> Header >> = {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZQ= "} >> Header Bytes >> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 34, 44, >> 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34, 44, >> 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34, 105, >> 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, 115, >> 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125] >> Encoded Header >> = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ >> BEGIN RSA KEY PARAMETERS >> Exponent >> [1, 0, 1] >> Modulus >> [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12, 224, = 19, 226, >> 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108, 185, = 234, >> 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, 6, = 224, >> 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144, 215, = 110, >> 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, = 124, >> 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, 113, 9, = 33, >> 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194, 192, = 183, >> 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, 253, = 206, >> 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, 136, = 138, 11, >> 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 172, >> 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, 72, 99, = 97, >> 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224, 178, = 163, >> 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, 127, = 68, >> 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, 213, 86, >> 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 89, >> 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239, 71] >> D (private key exponent) >> [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 181, 221, = 156, >> 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16, 165, = 48, >> 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, 56, 97, >> 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, 67, 180, = 167, >> 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, 41, 83, >> 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, 45, = 148, 58, >> 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119, 61, 26, >> 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, = 99, >> 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80, 171, = 167, >> 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 152, 71, >> 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, 91, >> 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 127, 84, = 171, >> 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, 186, = 222, 27, >> 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 224, 81, = 100, >> 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202, 151, = 107, >> 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, 130, = 89] >> The remaining RSA key parameters are included for completeness, but = should not be needed >> DP >> [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, 112, = 188, 112, >> 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 196, 152, = 132, 110, >> 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, 226, 34, = 196, >> 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 113, 195, >> 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254, 251, = 112, 231, >> 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77, 104, = 196, >> 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, 144, = 100, 2, >> 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 33, 156, = 43] >> DQ >> [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, 207, = 219, 180, >> 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 192, 124, = 130, >> 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123, 33, = 92, 119, >> 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 169, 208, = 156, >> 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, 251, = 152, 142, >> 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8, 117, = 176, >> 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78, 241, = 125, 153, >> 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169, 234, = 165] >> InverseQ >> [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, 61, 66, >> 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94, 35, = 86, >> 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 77, 23, = 37, >> 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37, 115, = 156, >> 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 227, 216, = 168, >> 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111, 31, = 117, 81, >> 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204, 190, = 89, >> 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, 52, 52, = 218] >> P >> [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 183, 131, = 3, >> 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20, 186, = 78, >> 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 247, 95, = 33, >> 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1, 78, 60, >> 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211, 167, = 206, >> 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 210, 216, = 44, >> 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, 221, 51, = 108, >> 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, 189, = 230, 195] >> Q >> [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, 155, = 213, 73, >> 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, 146, = 203, >> 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 85, 251, = 134, >> 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 213, 16, = 94, 30, >> 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240, 214, = 50, >> 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118, 221, = 146, >> 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, 206, = 242, 113, >> 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, 53, 45] >> END RSA KEY PARAMETERS >> Encrypted Key >> [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, 244, >> 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, 188, = 215, >> 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 28, = 149, 16, >> 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, 58, 206, = 201, >> 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 170, 7, = 36, >> 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193, 119, = 202, >> 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170, 204, = 73, >> 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 147, 2, = 37, >> 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59, 41, = 115, >> 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254, 166, >> 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, 134, 64, = 189, >> 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 213, 85, = 253, >> 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, 178, >> 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58, = 102, >> 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, 181, = 138, >> 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, 251] >> Encoded Encrypted Key >> = IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_Cx= WVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rM= SUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3= LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNI= OmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w >> Ciphertext >> [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, 146, = 217, >> 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, 207, = 239, >> 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142, 7, 69, >> 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59, 180, = 107, >> 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 223, 147] >> Encoded Ciphertext >> = _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7= UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M >> Secured Input >> = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK5= 6SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2= VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsg= gbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-= w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHO= O7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M >> Secured Input Bytes >> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, = 120, >> 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, >> 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53, 48, >> 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 74, 112, >> 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 82, 69, >> 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 74, 118, >> 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 50, 104, >> 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 104, >> 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 118, >> 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 95, = 71, >> 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 67, >> 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, 97, >> 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 66, >> 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 83, >> 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 53, = 100, >> 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118, 86, = 121, >> 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 84, 65, >> 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101, 80, = 95, >> 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89, 70, 67, >> 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, 89, 102, >> 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71, 81, >> 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101, 102, = 107, >> 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 108, 70, >> 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 102, 117, = 88, >> 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78, 73, 79, >> 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122, 48, = 111, >> 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79, 73, >> 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, 95, 90, >> 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, 114, = 101, >> 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 85, 106, >> 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99, 70, 78, >> 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, 70, 76, = 106, >> 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69, 68, >> 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50, 89, >> 81, 81, 50, 81, 81, 101, 51, 53, 77] >> Integrity Value >> [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, 102, = 136, >> 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, 15, = 73] >> Encoded Integrity Value >> c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k >> JWE >> = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK5= 6SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2= VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsg= gbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-= w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHO= O7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7= i6D0k >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From breno@google.com Wed Jun 27 18:56: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 CC38021F8683 for ; Wed, 27 Jun 2012 18:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.094 X-Spam-Level: X-Spam-Status: No, score=-101.094 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FR_TEST_BASE64_BAD=3.189, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwADaseHb43g for ; Wed, 27 Jun 2012 18:56:02 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 705AF21F867B for ; Wed, 27 Jun 2012 18:56:02 -0700 (PDT) Received: by qabj34 with SMTP id j34so1347658qab.4 for ; Wed, 27 Jun 2012 18:56:02 -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=8abPYRorPOpDmr20Ox+vjoV7KCUGPb5HeAulu+/FpLs=; b=Hu3gNhP38gtx3KUR9rd+XDBGFexhxdKGz8YMoFJCltJuc1ETHyobWRZ/4U2lmCXsBs kqmzPth6Fmmyqqp8HKIFFgoyn6k0P4NNkVggvIbhIH5EF6tQcoqcaDX8kkP8CNT5WhOB Fh4pp/+vNJuJPjlq3Od/bmfVOuOovNZfI/8wV5yGh0G7mozEQ+08a7UbtX3HYh/0Od3D U2l6RTLYKwNuT+Vtdy10PbidqKBZS4WTiklCMwB6XxzLl7horxFUF+Gb0H6myymNblbB rGcsiz27YU0jMq6Prcv1iyHcJOJ35O9LNT+obfqwjtioVZmzSpFx30x5ZoeMJxlXJChT xSnA== 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=8abPYRorPOpDmr20Ox+vjoV7KCUGPb5HeAulu+/FpLs=; b=WqIQJGgoI1mRVhojlROu/tPEHZK/lqavoY7cr9ujcdkQKV4W2aO08UXNp2eQ8uqU7M x18HTvRUrEjv35GI6HPci5chR7UtCxwbPYKKhx8cbdWTZ3SM52JfYSQBPuxJOzF4TKlh uLyG+cQHAqZmzl5WtUnyYHhmQIzNEWfe804Xr/eisvvtqzpKy7tXO3x6QMiB/doS4+Uv ZJ++iFn4kQMBHWfUD0xDm1tSuN1wHuZVJU3FqY+L38tEdyxzC7GXz40Zz/53xCLsd7a2 pj4dFcc8VJLwg74QG2X0F8x2TTM7Qq8G7pckDJkaKNJl0mAQhhcBxoLojsy2ye4wvYgA zodg== Received: by 10.224.188.197 with SMTP id db5mr707762qab.13.1340848561628; Wed, 27 Jun 2012 18:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.188.197 with SMTP id db5mr707742qab.13.1340848561344; Wed, 27 Jun 2012 18:56:01 -0700 (PDT) Received: by 10.229.197.102 with HTTP; Wed, 27 Jun 2012 18:56:01 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> <7915E1F6-0C3D-4131-A4F6-93AE6C4D6717@bbn.com> Date: Wed, 27 Jun 2012 18:56:01 -0700 Message-ID: From: Breno de Medeiros To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=20cf303640df324f4204c37ea2fa X-System-Of-Record: true X-Gm-Message-State: ALoCoQlxoW1G8PyxYjFDPp0mVxrsj16xRXlP1+mearIH3xrdPwzcr1IfjkfM+hrcEa9ir0EY5G3IgMxmL56Wnv/wGlCfYfmXyPrfIhoecnqBHlUxjjAKfzHxT+jNzu60BvTrbd/hDdT+xZaY9mgQ4mvWhe64FhtE6N+SBB2hJf/JpnjCL7/6b4Q= Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Complete JWE computation example 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, 28 Jun 2012 01:56:04 -0000 --20cf303640df324f4204c37ea2fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The recipient will use the issuer information to decide what keys and means to retrieve them are acceptable in the application security context. The actual keys may be supplied by URL, for instance, in the envelope. On Wed, Jun 27, 2012 at 6:41 PM, Richard L. Barnes wrote: > > This is really a comment against the JWE spec, but I'll go ahead and > mention it here: > > > > How is the recipient of this object supposed to know that public key to > use to verify the object? > > s/public key/private key/ > s/verify/decrypt/ > > Sorry, was thinking JWS. Same comment applies to JWS, though, IIRC. > > --Richard > > > > > > > > > > > > On Jun 26, 2012, at 8:32 PM, Mike Jones wrote: > > > >> Dear working group members, > >> > >> For the next round of the JOSE JWE spec, I=92m adding example encrypti= on > computations to aid implementers. An example JWE computation is included > below, in case you=92d like to compare your implementations against these= . > These values have already been verified by two independent implementatio= ns. > >> > >> This example uses the header values: > >> > {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3Ro= ZQ"} > >> > >> As such, there are actually several different things that this example > verifies: > >> - RSA encryption of the CMK > >> - Deriving the CEK and CIK from the CMK (in this case, using the same > values as EXAMPLE 1 from my Key Derivation message) > >> - AES-CBC encryption of the plaintext > >> - Calculation of the integrity value > >> > >> Note that because RSA PKCS #1-1.5 padding uses random values, the > encrypted CMK value will not be repeatable, although all resulting values > will be decryptable to retrieve the original CMK value. > >> > >> All relevant values should be present below. For the RSA key > parameters, the field names used are the ones from the .NET RSAParameters > structure documented athttp:// > msdn.microsoft.com/en-us/library/system.security.cryptography.rsaparamete= rs_members(v=3Dvs.71) > . > >> > >> Enjoy, > >> -- Mike > >> > >> CMK > >> [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, > 206, > >> 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, > 207] > >> CEK > >> [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, > 50, 69] > >> CIK > >> [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, > 122, > >> 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, 15= 9] > >> IV > >> [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 10= 1] > >> Plaintext > >> [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109, 101= , > 32, > >> 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 109, 101, > 110, > >> 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 104, 101, > 32, > >> 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, 99, 111, > 117, > >> 110, 116, 114, 121, 46] > >> Header > >> > {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZ= Q"} > >> Header Bytes > >> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 34, 44, > >> 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34, 44, > >> 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34, 105, > >> 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, 115, > >> 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125] > >> Encoded Header > >> > eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4W= ThEQ3REYUdsc2JHbGpiM1JvWlEifQ > >> BEGIN RSA KEY PARAMETERS > >> Exponent > >> [1, 0, 1] > >> Modulus > >> [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12, 224, 19, > 226, > >> 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108, 185, 23= 4, > >> 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, 6, 224= , > >> 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144, 215, 110= , > >> 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, 12= 4, > >> 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, 113, 9, 3= 3, > >> 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194, 192, 18= 3, > >> 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, 253, 206= , > >> 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, 136, 138, > 11, > >> 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 172, > >> 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, 72, 99, 9= 7, > >> 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224, 178, 163= , > >> 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, 127, 68, > >> 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, 213, 86, > >> 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 89, > >> 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239, 71] > >> D (private key exponent) > >> [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 181, 221, > 156, > >> 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16, 165, 48, > >> 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, 56, 97, > >> 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, 67, 180, > 167, > >> 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, 41, 83, > >> 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, 45, 148, > 58, > >> 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119, 61, 26, > >> 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, 99= , > >> 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80, 171, 167= , > >> 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 152, 71, > >> 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, 91, > >> 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 127, 84, 17= 1, > >> 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, 186, 222, > 27, > >> 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 224, 81, > 100, > >> 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202, 151, 10= 7, > >> 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, 130, 89= ] > >> The remaining RSA key parameters are included for completeness, but > should not be needed > >> DP > >> [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, 112, 188, > 112, > >> 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 196, 152, > 132, 110, > >> 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, 226, 34, > 196, > >> 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 113, 195, > >> 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254, 251, 112= , > 231, > >> 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77, 104, 19= 6, > >> 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, 144, 100, > 2, > >> 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 33, 156, 4= 3] > >> DQ > >> [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, 207, 219, > 180, > >> 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 192, 124, > 130, > >> 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123, 33, 92, > 119, > >> 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 169, 208, > 156, > >> 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, 251, 152, > 142, > >> 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8, 117, 17= 6, > >> 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78, 241, 125= , > 153, > >> 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169, 234, 165= ] > >> InverseQ > >> [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, 61, 66, > >> 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94, 35, 86, > >> 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 77, 23, 37= , > >> 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37, 115, 15= 6, > >> 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 227, 216, > 168, > >> 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111, 31, 117= , > 81, > >> 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204, 190, 89, > >> 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, 52, 52, > 218] > >> P > >> [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 183, 131, = 3, > >> 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20, 186, 78, > >> 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 247, 95, 3= 3, > >> 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1, 78, 60, > >> 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211, 167, 206= , > >> 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 210, 216, 4= 4, > >> 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, 221, 51, > 108, > >> 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, 189, 230, > 195] > >> Q > >> [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, 155, 213, > 73, > >> 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, 146, 203, > >> 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 85, 251, > 134, > >> 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 213, 16, > 94, 30, > >> 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240, 214, 50= , > >> 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118, 221, 146= , > >> 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, 206, 242, > 113, > >> 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, 53, 45] > >> END RSA KEY PARAMETERS > >> Encrypted Key > >> [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, 244, > >> 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, 188, > 215, > >> 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 28, 149, > 16, > >> 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, 58, 206, > 201, > >> 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 170, 7, 36, > >> 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193, 119, 20= 2, > >> 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170, 204, 73, > >> 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 147, 2, 37= , > >> 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59, 41, 115= , > >> 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254, 166, > >> 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, 134, 64, > 189, > >> 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 213, 85, > 253, > >> 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, 178, > >> 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58, 10= 2, > >> 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, 181, > 138, > >> 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, 251] > >> Encoded Encrypted Key > >> > IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_C= xWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rM= SUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3L= NlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOm= akiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w > >> Ciphertext > >> [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, 146, > 217, > >> 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, 207, > 239, > >> 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142, 7, 69, > >> 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59, 180, 107= , > >> 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 223, 147] > >> Encoded Ciphertext > >> > _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO= 7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > >> Secured Input > >> > eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4W= ThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56= SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VC= lVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbj= V7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w._Z= _djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7UHv= P8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > >> Secured Input Bytes > >> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 120, > >> 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, > >> 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53, 48, > >> 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 74, 112, > >> 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 82, 69, > >> 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 74, 118, > >> 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 50, 104, > >> 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 104, > >> 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 118, > >> 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 95, 71, > >> 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 67, > >> 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, 97, > >> 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 66, > >> 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 83, > >> 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 53, 100= , > >> 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118, 86, 121, > >> 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 84, 65, > >> 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101, 80, 95, > >> 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89, 70, 67, > >> 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, 89, 102, > >> 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71, 81, > >> 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101, 102, 107= , > >> 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 108, 70, > >> 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 102, 117, 8= 8, > >> 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78, 73, 79, > >> 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122, 48, 111, > >> 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79, 73, > >> 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, 95, 90, > >> 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, 114, 101, > >> 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 85, 106, > >> 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99, 70, 78, > >> 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, 70, 76, > 106, > >> 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69, 68, > >> 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50, 89, > >> 81, 81, 50, 81, 81, 101, 51, 53, 77] > >> Integrity Value > >> [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, 102, > 136, > >> 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, 15, 7= 3] > >> Encoded Integrity Value > >> c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k > >> JWE > >> > eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4W= ThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56= SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VC= lVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbj= V7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w._Z= _djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7UHv= P8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k > >> > >> _______________________________________________ > >> 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 --Breno --20cf303640df324f4204c37ea2fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The recipient will use the issuer information to decide what keys and means= to retrieve them are acceptable in the application security context. The a= ctual keys may be supplied by URL, for instance, in the envelope.


On Wed, Jun 27, 2012 at 6:41 PM, Richard= L. Barnes <rbarnes@bbn.com> wrote:
> This is really a comment against the JWE spec, but I= 'll go ahead and mention it here:
>
> How is the recipient of this object supposed to know that public key t= o use to verify the object?

s/public key/private key/
s/verify/decrypt/

Sorry, was thinking JWS. =A0Same comment applies to JWS, though, IIRC.

--Richard




>
>
>
> On Jun 26, 2012, at 8:32 PM, Mike Jones wrote:
>
>> Dear working group members,
>>
>> For the next round of the JOSE JWE spec, I=92m adding example encr= yption computations to aid implementers. =A0An example JWE computation is i= ncluded below, in case you=92d like to compare your implementations against= these. =A0These values have already been verified by two independent imple= mentations.
>>
>> This example uses the header values:
>> =A0 =A0{"alg":"RSA1_5","enc":"A= 128CBC","int":"HS256","iv":"AxY8DCt= DaGlsbGljb3RoZQ"}
>>
>> As such, there are actually several different things that this exa= mple verifies:
>> =A0- RSA encryption of the CMK
>> =A0- Deriving the CEK and CIK from the CMK (in this case, using th= e same values as EXAMPLE 1 from my Key Derivation message)
>> =A0- AES-CBC encryption of the plaintext
>> =A0- Calculation of the integrity value
>>
>> Note that because RSA PKCS #1-1.5 padding uses random values, the = encrypted CMK value will not be repeatable, although all resulting values w= ill be decryptable to retrieve the original CMK value.
>>
>> All relevant values should be present below. =A0For the RSA key pa= rameters, the field names used are the ones from the .NET RSAParameters str= ucture documented athttp://msdn.microsoft.com/en-us/library/system.security.cryptography.rsap= arameters_members(v=3Dvs.71).
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Enjoy,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =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
>>
>> CMK
>> [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 1= 06, 206,
>> 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 4= 4, 207]
>> CEK
>> [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 18= 4, 50, 69]
>> CIK
>> [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 11= 1, 122,
>> 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225= , 159]
>> IV
>> [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104= , 101]
>> Plaintext
>> [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109,= 101, 32,
>> 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 109, = 101, 110,
>> 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 104, 1= 01, 32,
>> 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, 99, 1= 11, 117,
>> 110, 116, 114, 121, 46]
>> Header
>> {"alg":"RSA1_5","enc":"A128CBC&= quot;,"int":"HS256","iv":"AxY8DCtDaGlsbG= ljb3RoZQ"}
>> Header Bytes
>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 34, 44= ,
>> 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34, 44,<= br> >> 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34, 105= ,
>> 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, 11= 5,
>> 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125]
>> Encoded Header
>> eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdi= I6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ
>> BEGIN RSA KEY PARAMETERS
>> Exponent
>> [1, 0, 1]
>> Modulus
>> [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12, 224,= 19, 226,
>> 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108, 185= , 234,
>> 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, 6,= 224,
>> 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144, 215,= 110,
>> 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 179, 28= , 124,
>> 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, 113, = 9, 33,
>> 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194, 192= , 183,
>> 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, 253,= 206,
>> 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, 136, = 138, 11,
>> 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 1= 72,
>> 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, 72, 9= 9, 97,
>> 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224, 178,= 163,
>> 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, 127,= 68,
>> 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, 213, = 86,
>> 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 8= 9,
>> 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239, 71]=
>> D (private key exponent)
>> [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 181, 2= 21, 156,
>> 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16, 165,= 48,
>> 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, 56, = 97,
>> 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, 67, 1= 80, 167,
>> 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, 41, 8= 3,
>> 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, 45, = 148, 58,
>> 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119, 61, = 26,
>> 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100= , 99,
>> 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80, 171,= 167,
>> 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 152, 71= ,
>> 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, 9= 1,
>> 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 127, 84= , 171,
>> 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, 186, = 222, 27,
>> 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 224, 8= 1, 100,
>> 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202, 151= , 107,
>> 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, 130= , 89]
>> The remaining RSA key parameters are included for completeness, bu= t should not be needed
>> DP
>> [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, 112, = 188, 112,
>> 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 196, 15= 2, 132, 110,
>> 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, 226, = 34, 196,
>> 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 113, 1= 95,
>> 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254, 251,= 112, 231,
>> 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77, 104= , 196,
>> 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, 144, = 100, 2,
>> 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 33, 15= 6, 43]
>> DQ
>> [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, 207, = 219, 180,
>> 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 192, 1= 24, 130,
>> 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123, 33,= 92, 119,
>> 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 169, 2= 08, 156,
>> 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, 251, = 152, 142,
>> 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8, 117= , 176,
>> 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78, 241,= 125, 153,
>> 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169, 234,= 165]
>> InverseQ
>> [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, 61, 6= 6,
>> 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94, 35,= 86,
>> 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 77, 23= , 37,
>> 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37, 115= , 156,
>> 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 227, 2= 16, 168,
>> 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111, 31,= 117, 81,
>> 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204, 190,= 89,
>> 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, 52, 5= 2, 218]
>> P
>> [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 183, 1= 31, 3,
>> 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20, 186,= 78,
>> 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 247, 9= 5, 33,
>> 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1, 78, = 60,
>> 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211, 167,= 206,
>> 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 210, 21= 6, 44,
>> 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, 221, = 51, 108,
>> 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, 189, = 230, 195]
>> Q
>> [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, 155, = 213, 73,
>> 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, 146, = 203,
>> 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 85, 25= 1, 134,
>> 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 213, 1= 6, 94, 30,
>> 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240, 214= , 50,
>> 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118, 221,= 146,
>> 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, 206, = 242, 113,
>> 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, 53, 4= 5]
>> END RSA KEY PARAMETERS
>> Encrypted Key
>> [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, 2= 44,
>> 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, 18= 8, 215,
>> 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 28, = 149, 16,
>> 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, 58, 2= 06, 201,
>> 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 170, 7,= 36,
>> 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193, 119= , 202,
>> 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170, 204,= 73,
>> 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 147, 2= , 37,
>> 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59, 41,= 115,
>> 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254, 166= ,
>> 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, 134, = 64, 189,
>> 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 213, 8= 5, 253,
>> 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, 1= 78,
>> 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58= , 102,
>> 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, 18= 1, 138,
>> 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, 25= 1]
>> Encoded Encrypted Key
>> IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXt= XJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFS= gfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNY= fO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIr= RDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w
>> Ciphertext
>> [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, 14= 6, 217,
>> 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, 2= 07, 239,
>> 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142, 7, = 69,
>> 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59, 180,= 107,
>> 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 223, 1= 47]
>> Encoded Ciphertext
>> _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLj= eB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M
>> Secured Input
>> eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdi= I6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImC= n0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261= QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCm= Oylz2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908= lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQ= KZ-w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4H= HOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M
>> Secured Input Bytes
>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, = 120,
>> 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, = 66,
>> 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53, 48,=
>> 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 74, 1= 12,
>> 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 82, 69= ,
>> 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 74, 11= 8,
>> 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 50, 10= 4,
>> 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 104,<= br> >> 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 118,=
>> 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 95,= 71,
>> 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 67,<= br> >> 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, = 97,
>> 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 66= ,
>> 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 83= ,
>> 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 53,= 100,
>> 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118, 86, = 121,
>> 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 84, 65= ,
>> 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101, 80,= 95,
>> 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89, 70, = 67,
>> 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, 89, 1= 02,
>> 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71, 81,=
>> 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101, 102,= 107,
>> 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 108, 7= 0,
>> 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 102, 11= 7, 88,
>> 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78, 73, = 79,
>> 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122, 48, = 111,
>> 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79, 73,=
>> 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, 95, 9= 0,
>> 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, 114, = 101,
>> 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 85, 10= 6,
>> 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99, 70, = 78,
>> 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, 70, 7= 6, 106,
>> 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69, 68,<= br> >> 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50, 89,=
>> 81, 81, 50, 81, 81, 101, 51, 53, 77]
>> Integrity Value
>> [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, 1= 02, 136,
>> 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, 1= 5, 73]
>> Encoded Integrity Value
>> c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k
>> JWE
>> eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdi= I6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImC= n0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261= QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCm= Oylz2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908= lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQ= KZ-w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4H= HOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid= 7i6D0k
>>
>> <JWE.log>_______________________________________________
>> 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



--
= --Breno
--20cf303640df324f4204c37ea2fa-- From rbarnes@bbn.com Wed Jun 27 19:16: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 9D00A11E8194 for ; Wed, 27 Jun 2012 19:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TemAI9FglqJX for ; Wed, 27 Jun 2012 19:16:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 177B211E8192 for ; Wed, 27 Jun 2012 19:16:43 -0700 (PDT) Received: from [128.89.253.234] (port=63303) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sk4Hh-0001iW-P8; Wed, 27 Jun 2012 22:16:41 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Wed, 27 Jun 2012 22:16:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> <7915E1F6-0C3D-4131-A4F6-93AE6C4D6717@bbn.com> To: Breno de Medeiros X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Complete JWE computation example 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, 28 Jun 2012 02:16:45 -0000 Am I missing where the issuer information is in the example message? Or = is the example incomplete? Or do you expect this information to be = entirely out of band? On Jun 27, 2012, at 9:56 PM, Breno de Medeiros wrote: > The recipient will use the issuer information to decide what keys and = means to retrieve them are acceptable in the application security = context. The actual keys may be supplied by URL, for instance, in the = envelope. >=20 >=20 > On Wed, Jun 27, 2012 at 6:41 PM, Richard L. Barnes = wrote: > > This is really a comment against the JWE spec, but I'll go ahead and = mention it here: > > > > How is the recipient of this object supposed to know that public key = to use to verify the object? >=20 > s/public key/private key/ > s/verify/decrypt/ >=20 > Sorry, was thinking JWS. Same comment applies to JWS, though, IIRC. >=20 > --Richard >=20 >=20 >=20 >=20 > > > > > > > > On Jun 26, 2012, at 8:32 PM, Mike Jones wrote: > > > >> Dear working group members, > >> > >> For the next round of the JOSE JWE spec, I=92m adding example = encryption computations to aid implementers. An example JWE computation = is included below, in case you=92d like to compare your implementations = against these. These values have already been verified by two = independent implementations. > >> > >> This example uses the header values: > >> = {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZQ= "} > >> > >> As such, there are actually several different things that this = example verifies: > >> - RSA encryption of the CMK > >> - Deriving the CEK and CIK from the CMK (in this case, using the = same values as EXAMPLE 1 from my Key Derivation message) > >> - AES-CBC encryption of the plaintext > >> - Calculation of the integrity value > >> > >> Note that because RSA PKCS #1-1.5 padding uses random values, the = encrypted CMK value will not be repeatable, although all resulting = values will be decryptable to retrieve the original CMK value. > >> > >> All relevant values should be present below. For the RSA key = parameters, the field names used are the ones from the .NET = RSAParameters structure documented = athttp://msdn.microsoft.com/en-us/library/system.security.cryptography.rsa= parameters_members(v=3Dvs.71). > >> > >> = Enjoy, > >> -- = Mike > >> > >> CMK > >> [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, = 106, 206, > >> 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, = 44, 207] > >> CEK > >> [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, = 184, 50, 69] > >> CIK > >> [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, = 111, 122, > >> 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, = 159] > >> IV > >> [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, = 101] > >> Plaintext > >> [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109, = 101, 32, > >> 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 109, = 101, 110, > >> 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 104, = 101, 32, > >> 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, 99, = 111, 117, > >> 110, 116, 114, 121, 46] > >> Header > >> = {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZQ= "} > >> Header Bytes > >> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 34, 44, > >> 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34, 44, > >> 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34, 105, > >> 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, = 115, > >> 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125] > >> Encoded Header > >> = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ > >> BEGIN RSA KEY PARAMETERS > >> Exponent > >> [1, 0, 1] > >> Modulus > >> [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12, 224, = 19, 226, > >> 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108, 185, = 234, > >> 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, 6, = 224, > >> 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144, 215, = 110, > >> 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, = 124, > >> 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, 113, = 9, 33, > >> 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194, 192, = 183, > >> 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, 253, = 206, > >> 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, 136, = 138, 11, > >> 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, = 172, > >> 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, 72, = 99, 97, > >> 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224, 178, = 163, > >> 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, 127, = 68, > >> 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, 213, = 86, > >> 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, = 89, > >> 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239, 71] > >> D (private key exponent) > >> [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 181, = 221, 156, > >> 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16, 165, = 48, > >> 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, 56, = 97, > >> 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, 67, = 180, 167, > >> 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, 41, = 83, > >> 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, 45, = 148, 58, > >> 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119, 61, = 26, > >> 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, = 99, > >> 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80, 171, = 167, > >> 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 152, 71, > >> 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, = 91, > >> 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 127, 84, = 171, > >> 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, 186, = 222, 27, > >> 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 224, = 81, 100, > >> 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202, 151, = 107, > >> 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, 130, = 89] > >> The remaining RSA key parameters are included for completeness, but = should not be needed > >> DP > >> [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, 112, = 188, 112, > >> 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 196, = 152, 132, 110, > >> 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, 226, = 34, 196, > >> 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 113, = 195, > >> 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254, 251, = 112, 231, > >> 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77, 104, = 196, > >> 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, 144, = 100, 2, > >> 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 33, = 156, 43] > >> DQ > >> [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, 207, = 219, 180, > >> 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 192, = 124, 130, > >> 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123, 33, = 92, 119, > >> 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 169, = 208, 156, > >> 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, 251, = 152, 142, > >> 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8, 117, = 176, > >> 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78, 241, = 125, 153, > >> 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169, 234, = 165] > >> InverseQ > >> [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, 61, = 66, > >> 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94, 35, = 86, > >> 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 77, 23, = 37, > >> 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37, 115, = 156, > >> 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 227, = 216, 168, > >> 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111, 31, = 117, 81, > >> 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204, 190, = 89, > >> 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, 52, = 52, 218] > >> P > >> [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 183, = 131, 3, > >> 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20, 186, = 78, > >> 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 247, = 95, 33, > >> 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1, 78, = 60, > >> 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211, 167, = 206, > >> 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 210, = 216, 44, > >> 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, 221, = 51, 108, > >> 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, 189, = 230, 195] > >> Q > >> [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, 155, = 213, 73, > >> 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, 146, = 203, > >> 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 85, = 251, 134, > >> 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 213, = 16, 94, 30, > >> 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240, 214, = 50, > >> 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118, 221, = 146, > >> 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, 206, = 242, 113, > >> 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, 53, = 45] > >> END RSA KEY PARAMETERS > >> Encrypted Key > >> [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, = 244, > >> 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, = 188, 215, > >> 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 28, = 149, 16, > >> 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, 58, = 206, 201, > >> 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 170, 7, = 36, > >> 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193, 119, = 202, > >> 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170, 204, = 73, > >> 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 147, 2, = 37, > >> 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59, 41, = 115, > >> 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254, 166, > >> 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, 134, = 64, 189, > >> 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 213, = 85, 253, > >> 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, = 178, > >> 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58, = 102, > >> 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, = 181, 138, > >> 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, = 251] > >> Encoded Encrypted Key > >> = IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_Cx= WVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rM= SUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3= LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNI= OmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w > >> Ciphertext > >> [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, = 146, 217, > >> 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, = 207, 239, > >> 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142, 7, = 69, > >> 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59, 180, = 107, > >> 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 223, = 147] > >> Encoded Ciphertext > >> = _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7= UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > >> Secured Input > >> = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK5= 6SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2= VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsg= gbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-= w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHO= O7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > >> Secured Input Bytes > >> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, = 120, > >> 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, = 66, > >> 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53, 48, > >> 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 74, = 112, > >> 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 82, 69, > >> 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 74, = 118, > >> 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 50, = 104, > >> 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 104, > >> 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 118, > >> 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 95, = 71, > >> 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 67, > >> 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, = 97, > >> 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 66, > >> 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 83, > >> 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 53, = 100, > >> 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118, 86, = 121, > >> 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 84, 65, > >> 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101, 80, = 95, > >> 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89, 70, = 67, > >> 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, 89, = 102, > >> 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71, 81, > >> 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101, 102, = 107, > >> 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 108, = 70, > >> 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 102, = 117, 88, > >> 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78, 73, = 79, > >> 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122, 48, = 111, > >> 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79, 73, > >> 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, 95, = 90, > >> 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, 114, = 101, > >> 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 85, = 106, > >> 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99, 70, = 78, > >> 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, 70, = 76, 106, > >> 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69, 68, > >> 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50, 89, > >> 81, 81, 50, 81, 81, 101, 51, 53, 77] > >> Integrity Value > >> [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, = 102, 136, > >> 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, = 15, 73] > >> Encoded Integrity Value > >> c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k > >> JWE > >> = eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4WT= hEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK5= 6SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2= VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsg= gbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-= w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHO= O7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7= i6D0k > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > --=20 > --Breno > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Wed Jun 27 19:19: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 BD67611E8187 for ; Wed, 27 Jun 2012 19:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySljoT80XA26 for ; Wed, 27 Jun 2012 19:19:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4633811E8171 for ; Wed, 27 Jun 2012 18:49:41 -0700 (PDT) Received: from [128.89.253.234] (port=63210) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sk3rV-0001Zi-DE; Wed, 27 Jun 2012 21:49:37 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 27 Jun 2012 21:49:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] protected attributes 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, 28 Jun 2012 02:19:15 -0000 On Jun 26, 2012, at 10:18 PM, Manger, James H wrote: > Richard Barnes wrote (in the thread "Re: [jose] New Version = Notification for draft-barnes-jose-jsms-00.txt"): >> You can have something like JWT specify a >> body format that has the protected parameters, so why does JWS/JWE = need >> integrity-protected attributes? >=20 >=20 > One attribute is whether or not the content of this JWS/JWE is another = JWS/JWE. This attribute is more a part of the JWS/JWE processing than = metadata for the content. >=20 > For instance, if a sender signs-then-encrypts content it would be good = if an attacker cannot change it to appear to be just encrypted content. Can you describe what attack this would prevent? =20 Again noting precedent: If you look at S/MIME, for example, the = Content-Type of the MIME body is inside of the CMS EnvelopedData = structure, so the presence of SignedData on the inside would not be = observable. > Is it too unlikely that a receiving app will mistake a JWS for the = content it expected? If an app expected a JSON object as the content (eg = as per JWT) but got a JWS, is it conceivable that it could mistake the = JWS header for the JWT? In general, applications that use JOSE are going to need to specify what = the protected content must be. I think that if the above question = arises, then the application protocol is underspecified. --Richard= From breno@google.com Wed Jun 27 19:36:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4D611E812B for ; Wed, 27 Jun 2012 19:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.833 X-Spam-Level: X-Spam-Status: No, score=-100.833 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FR_TEST_BASE64_BAD=3.189, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVSauJQzvQQz for ; Wed, 27 Jun 2012 19:36:36 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id C9F5E11E80B8 for ; Wed, 27 Jun 2012 19:36:35 -0700 (PDT) Received: by qabj34 with SMTP id j34so1363803qab.4 for ; Wed, 27 Jun 2012 19:36:35 -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=IsUHg4AzMI1TLJHFsVlcSicTOaGsg6u4y/C3YaG40gM=; b=c6dYM6QycoSfUCNpzgyPYYj7b3tQBlB7z8Nr9aihwcLhJ9oj0qIeu7UFnOsKZWxgJH Ckv3Y/4gQcmNMH6ciofeHVbW6oulCC0R5XTK1k63pz/X1WHz/bj8B0DMQg2Qt5SD/f0b 4JE4D9rlsWSO4mjOp8XedrHA8ynikchTDMmSUVMe/nnR60vdN5eL1QAbVPmA1YmCd9aE 8xn226mAUbLThh0xR5gAAQaYwxwpm9n4AbaxpYBvQya+yZxQLG4b59KE30RnxaJ5QlLS vb4fFN1P0xgD7WmtNuN0nbcEkXvT0XlEbODbyEe0SGforAa/PwmMvF5rD1fnPopCPPQq BRzA== 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=IsUHg4AzMI1TLJHFsVlcSicTOaGsg6u4y/C3YaG40gM=; b=gUTBznoyEMZOLPt5MJKB+N8DtCnmuDu3GJ+FogL7x0qownhiCkP9su6zGzWN7yo9b0 PNqWAVPxlO3MMMbVRDggrIxv+5zy9hvHFervBdM88swQndgpivp+1/HXbkCL6DyKD8Oo vY2h1ocNbWJRwEhQB1TyP4MUlW5nfe+Wp10fEZEQzJjo/D44RLuo4SR0izm8YoxY00eF Topl8glYfQdbnShCh84w83aHwF82Y2DZBamhNDNU/AR3lSqxx5CGK6L51lfAZcFET4yH LfKAzuIiUyXMMs0PLm+ms/HsWgQglPvgIsCUxPRMTRiq5X5xfAuRLA6r7hekOtFD0B3q Iebw== Received: by 10.229.135.73 with SMTP id m9mr44800qct.130.1340850994880; Wed, 27 Jun 2012 19:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.73 with SMTP id m9mr44786qct.130.1340850994463; Wed, 27 Jun 2012 19:36:34 -0700 (PDT) Received: by 10.229.197.102 with HTTP; Wed, 27 Jun 2012 19:36:34 -0700 (PDT) Received: by 10.229.197.102 with HTTP; Wed, 27 Jun 2012 19:36:34 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> <7915E1F6-0C3D-4131-A4F6-93AE6C4D6717@bbn.com> Date: Wed, 27 Jun 2012 19:36:34 -0700 Message-ID: From: Breno de Medeiros To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=485b3918a9c838c44f04c37f338c X-System-Of-Record: true X-Gm-Message-State: ALoCoQnXCVUCAt/AOYXKH50DoolgLPoHEMI/lUHx0FWX3+m0PT1H7XgXQJfXkTEInHqrJi94Eoq9y5yEQB+j0IvVU5U7HEp+AXcwvVXX4KZegf3Syeiba6sbKYeBXlMVsCdgsJB3sCvU8/VMS6tDJj9SHVHJ1JlUJ7kZMcR0BGihdrPAIIIDxkY= Cc: Michael Jones , "jose@ietf.org" Subject: Re: [jose] Complete JWE computation example 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, 28 Jun 2012 02:36:38 -0000 --485b3918a9c838c44f04c37f338c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In this particular example it is OOB. In general JWE is not a trust framework spec (neither needs to be) so trust is OOB but key identification metadata can be transported via tokens. On Jun 27, 2012 7:16 PM, "Richard L. Barnes" wrote: > Am I missing where the issuer information is in the example message? Or > is the example incomplete? Or do you expect this information to be > entirely out of band? > > > > On Jun 27, 2012, at 9:56 PM, Breno de Medeiros wrote: > > > The recipient will use the issuer information to decide what keys and > means to retrieve them are acceptable in the application security context= . > The actual keys may be supplied by URL, for instance, in the envelope. > > > > > > On Wed, Jun 27, 2012 at 6:41 PM, Richard L. Barnes > wrote: > > > This is really a comment against the JWE spec, but I'll go ahead and > mention it here: > > > > > > How is the recipient of this object supposed to know that public key > to use to verify the object? > > > > s/public key/private key/ > > s/verify/decrypt/ > > > > Sorry, was thinking JWS. Same comment applies to JWS, though, IIRC. > > > > --Richard > > > > > > > > > > > > > > > > > > > > On Jun 26, 2012, at 8:32 PM, Mike Jones wrote: > > > > > >> Dear working group members, > > >> > > >> For the next round of the JOSE JWE spec, I=92m adding example > encryption computations to aid implementers. An example JWE computation = is > included below, in case you=92d like to compare your implementations agai= nst > these. These values have already been verified by two independent > implementations. > > >> > > >> This example uses the header values: > > >> > {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3Ro= ZQ"} > > >> > > >> As such, there are actually several different things that this > example verifies: > > >> - RSA encryption of the CMK > > >> - Deriving the CEK and CIK from the CMK (in this case, using the > same values as EXAMPLE 1 from my Key Derivation message) > > >> - AES-CBC encryption of the plaintext > > >> - Calculation of the integrity value > > >> > > >> Note that because RSA PKCS #1-1.5 padding uses random values, the > encrypted CMK value will not be repeatable, although all resulting values > will be decryptable to retrieve the original CMK value. > > >> > > >> All relevant values should be present below. For the RSA key > parameters, the field names used are the ones from the .NET RSAParameters > structure documented athttp:// > msdn.microsoft.com/en-us/library/system.security.cryptography.rsaparamete= rs_members(v=3Dvs.71) > . > > >> > > >> Enjoy, > > >> -- Mi= ke > > >> > > >> CMK > > >> [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106= , > 206, > > >> 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, > 207] > > >> CEK > > >> [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, > 50, 69] > > >> CIK > > >> [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, > 122, > > >> 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 225, > 159] > > >> IV > > >> [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, > 101] > > >> Plaintext > > >> [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109, > 101, 32, > > >> 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 109, > 101, 110, > > >> 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 104, 101= , > 32, > > >> 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, 99, 111= , > 117, > > >> 110, 116, 114, 121, 46] > > >> Header > > >> > {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGlsbGljb3RoZ= Q"} > > >> Header Bytes > > >> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 34, 44, > > >> 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34, 44, > > >> 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34, 105, > > >> 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, 115, > > >> 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125] > > >> Encoded Header > > >> > eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4W= ThEQ3REYUdsc2JHbGpiM1JvWlEifQ > > >> BEGIN RSA KEY PARAMETERS > > >> Exponent > > >> [1, 0, 1] > > >> Modulus > > >> [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12, 224, > 19, 226, > > >> 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108, 185, > 234, > > >> 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, 6, > 224, > > >> 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144, 215, > 110, > > >> 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, > 124, > > >> 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, 113, 9, > 33, > > >> 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194, 192, > 183, > > >> 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, 253, > 206, > > >> 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, 136, > 138, 11, > > >> 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 172= , > > >> 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, 72, 99, > 97, > > >> 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224, 178, > 163, > > >> 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, 127, 6= 8, > > >> 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, 213, 86= , > > >> 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 89, > > >> 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239, 71] > > >> D (private key exponent) > > >> [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 181, 221= , > 156, > > >> 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16, 165, 4= 8, > > >> 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, 56, 97= , > > >> 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, 67, 180= , > 167, > > >> 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, 41, 83, > > >> 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, 45, > 148, 58, > > >> 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119, 61, 26= , > > >> 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, > 99, > > >> 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80, 171, > 167, > > >> 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 152, 71, > > >> 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, 91, > > >> 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 127, 84, > 171, > > >> 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, 186, > 222, 27, > > >> 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 224, 81, > 100, > > >> 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202, 151, > 107, > > >> 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, 130, > 89] > > >> The remaining RSA key parameters are included for completeness, but > should not be needed > > >> DP > > >> [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, 112, > 188, 112, > > >> 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 196, 152, > 132, 110, > > >> 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, 226, 34= , > 196, > > >> 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 113, 195= , > > >> 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254, 251, > 112, 231, > > >> 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77, 104, > 196, > > >> 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, 144, > 100, 2, > > >> 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 33, 156, > 43] > > >> DQ > > >> [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, 207, > 219, 180, > > >> 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 192, 124= , > 130, > > >> 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123, 33, > 92, 119, > > >> 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 169, 208= , > 156, > > >> 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, 251, > 152, 142, > > >> 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8, 117, > 176, > > >> 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78, 241, > 125, 153, > > >> 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169, 234, > 165] > > >> InverseQ > > >> [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, 61, 66, > > >> 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94, 35, 8= 6, > > >> 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 77, 23, > 37, > > >> 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37, 115, > 156, > > >> 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 227, 216= , > 168, > > >> 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111, 31, > 117, 81, > > >> 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204, 190, 8= 9, > > >> 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, 52, 52, > 218] > > >> P > > >> [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 183, 131= , > 3, > > >> 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20, 186, 7= 8, > > >> 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 247, 95, > 33, > > >> 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1, 78, 60= , > > >> 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211, 167, > 206, > > >> 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 210, 216, > 44, > > >> 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, 221, 51= , > 108, > > >> 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, 189, > 230, 195] > > >> Q > > >> [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, 155, > 213, 73, > > >> 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, 146, 20= 3, > > >> 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 85, 251, > 134, > > >> 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 213, 16, > 94, 30, > > >> 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240, 214, > 50, > > >> 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118, 221, > 146, > > >> 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, 206, > 242, 113, > > >> 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, 53, 45] > > >> END RSA KEY PARAMETERS > > >> Encrypted Key > > >> [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, 244= , > > >> 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, 188, > 215, > > >> 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 28, > 149, 16, > > >> 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, 58, 206= , > 201, > > >> 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 170, 7, 3= 6, > > >> 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193, 119, > 202, > > >> 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170, 204, 7= 3, > > >> 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 147, 2, > 37, > > >> 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59, 41, > 115, > > >> 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254, 166, > > >> 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, 134, 64= , > 189, > > >> 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 213, 85, > 253, > > >> 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, 178= , > > >> 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58, > 102, > > >> 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, 181, > 138, > > >> 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, 251] > > >> Encoded Encrypted Key > > >> > IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_C= xWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rM= SUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3L= NlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOm= akiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w > > >> Ciphertext > > >> [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, 146, > 217, > > >> 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, 207= , > 239, > > >> 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142, 7, 69= , > > >> 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59, 180, > 107, > > >> 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 223, 147= ] > > >> Encoded Ciphertext > > >> > _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO= 7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > > >> Secured Input > > >> > eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4W= ThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56= SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VC= lVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbj= V7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w._Z= _djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7UHv= P8PEDu0a0sA2a_-CI0w2YQQ2QQe35M > > >> Secured Input Bytes > > >> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 12= 0, > > >> 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66= , > > >> 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53, 48, > > >> 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 74, 112= , > > >> 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 82, 69, > > >> 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 74, 118, > > >> 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 50, 104, > > >> 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 104, > > >> 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 118, > > >> 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 95, 7= 1, > > >> 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 67, > > >> 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, 97= , > > >> 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 66, > > >> 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 83, > > >> 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 53, > 100, > > >> 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118, 86, 12= 1, > > >> 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 84, 65, > > >> 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101, 80, 9= 5, > > >> 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89, 70, 67= , > > >> 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, 89, 102= , > > >> 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71, 81, > > >> 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101, 102, > 107, > > >> 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 108, 70, > > >> 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 102, 117, > 88, > > >> 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78, 73, 79= , > > >> 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122, 48, 11= 1, > > >> 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79, 73, > > >> 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, 95, 90, > > >> 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, 114, 10= 1, > > >> 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 85, 106, > > >> 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99, 70, 78= , > > >> 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, 70, 76, > 106, > > >> 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69, 68, > > >> 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50, 89, > > >> 81, 81, 50, 81, 81, 101, 51, 53, 77] > > >> Integrity Value > > >> [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, 102= , > 136, > > >> 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, 15, > 73] > > >> Encoded Integrity Value > > >> c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k > > >> JWE > > >> > eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJpdiI6IkF4W= ThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuo= Bq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56= SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VC= lVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbj= V7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w._Z= _djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFLjeB4HHOO7UHv= P8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > -- > > --Breno > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > --485b3918a9c838c44f04c37f338c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

In this particular example it is OOB. In general JWE is not a trust fram= ework spec (neither needs to be) so trust is OOB but key identification met= adata can be transported via tokens.

On Jun 27, 2012 7:16 PM, "Richard L. Barnes= " <rbarnes@bbn.com> wrote= :
Am I missing where the issuer information is in the example message? =A0Or = is the example incomplete? =A0Or do you expect this information to be entir= ely out of band?



On Jun 27, 2012, at 9:56 PM, Breno de Medeiros wrote:

> The recipient will use the issuer information to decide what keys and = means to retrieve them are acceptable in the application security context. = The actual keys may be supplied by URL, for instance, in the envelope.
>
>
> On Wed, Jun 27, 2012 at 6:41 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> > This is really a comment against the JWE spec, but I'll go ah= ead and mention it here:
> >
> > How is the recipient of this object supposed to know that public = key to use to verify the object?
>
> s/public key/private key/
> s/verify/decrypt/
>
> Sorry, was thinking JWS. =A0Same comment applies to JWS, though, IIRC.=
>
> --Richard
>
>
>
>
> >
> >
> >
> > On Jun 26, 2012, at 8:32 PM, Mike Jones wrote:
> >
> >> Dear working group members,
> >>
> >> For the next round of the JOSE JWE spec, I=92m adding example= encryption computations to aid implementers. =A0An example JWE computation= is included below, in case you=92d like to compare your implementations ag= ainst these. =A0These values have already been verified by two independent = implementations.
> >>
> >> This example uses the header values:
> >> =A0 =A0{"alg":"RSA1_5","enc":&q= uot;A128CBC","int":"HS256","iv":"Ax= Y8DCtDaGlsbGljb3RoZQ"}
> >>
> >> As such, there are actually several different things that thi= s example verifies:
> >> =A0- RSA encryption of the CMK
> >> =A0- Deriving the CEK and CIK from the CMK (in this case, usi= ng the same values as EXAMPLE 1 from my Key Derivation message)
> >> =A0- AES-CBC encryption of the plaintext
> >> =A0- Calculation of the integrity value
> >>
> >> Note that because RSA PKCS #1-1.5 padding uses random values,= the encrypted CMK value will not be repeatable, although all resulting val= ues will be decryptable to retrieve the original CMK value.
> >>
> >> All relevant values should be present below. =A0For the RSA k= ey parameters, the field names used are the ones from the .NET RSAParameter= s structure documented athttp://msdn.microsoft.com/en-us/library/system.security.cryptography= .rsaparameters_members(v=3Dvs.71).
> >>
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Enjoy,
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =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<= br> > >>
> >> CMK
> >> [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 1= 70, 106, 206,
> >> 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 1= 56, 44, 207]
> >> CEK
> >> [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 19= 5, 184, 50, 69]
> >> CIK
> >> [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 15= 8, 111, 122,
> >> 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177= , 225, 159]
> >> IV
> >> [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116= , 104, 101]
> >> Plaintext
> >> [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105,= 109, 101, 32,
> >> 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, = 109, 101, 110,
> >> 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 116, 1= 04, 101, 32,
> >> 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 105, 114, 32, = 99, 111, 117,
> >> 110, 116, 114, 121, 46]
> >> Header
> >> {"alg":"RSA1_5","enc":"A12= 8CBC","int":"HS256","iv":"AxY8DCtDa= GlsbGljb3RoZQ"}
> >> Header Bytes
> >> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 49, 95, 53, 3= 4, 44,
> >> 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 66, 67, 34,= 44,
> >> 34, 105, 110, 116, 34, 58, 34, 72, 83, 50, 53, 54, 34, 44, 34= , 105,
> >> 118, 34, 58, 34, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 10= 8, 115,
> >> 98, 71, 108, 106, 98, 51, 82, 111, 90, 81, 34, 125]
> >> Encoded Header
> >> eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiL= CJpdiI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ
> >> BEGIN RSA KEY PARAMETERS
> >> Exponent
> >> [1, 0, 1]
> >> Modulus
> >> [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, 242, 12,= 224, 19, 226,
> >> 198, 134, 17, 71, 173, 75, 42, 61, 48, 162, 206, 161, 97, 108= , 185, 234,
> >> 226, 219, 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 12= 3, 6, 224,
> >> 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, 4, 85, 220, 144,= 215, 110,
> >> 130, 17, 68, 228, 129, 138, 7, 130, 231, 40, 212, 214, 17, 17= 9, 28, 124,
> >> 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, 73, 211, = 113, 9, 33,
> >> 178, 80, 13, 25, 21, 25, 153, 212, 206, 67, 154, 147, 70, 194= , 192, 183,
> >> 160, 83, 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50,= 253, 206,
> >> 32, 179, 254, 236, 190, 82, 73, 67, 129, 253, 252, 220, 108, = 136, 138, 11,
> >> 192, 1, 36, 239, 228, 55, 81, 113, 17, 25, 140, 63, 239, 146,= 3, 172,
> >> 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, 92, 112, = 72, 99, 97,
> >> 26, 87, 187, 123, 46, 50, 90, 202, 117, 73, 10, 153, 47, 224,= 178, 163,
> >> 77, 48, 46, 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225,= 127, 68,
> >> 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, 254, 85, 55, 75, = 213, 86,
> >> 194, 218, 215, 163, 189, 194, 54, 6, 83, 36, 18, 153, 53, 7, = 48, 89,
> >> 35, 66, 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, 239= , 71]
> >> D (private key exponent)
> >> [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, 154, 36, 1= 81, 221, 156,
> >> 211, 215, 100, 164, 90, 88, 40, 228, 83, 148, 54, 122, 4, 16,= 165, 48,
> >> 76, 194, 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61,= 56, 97,
> >> 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, 214, 252, 120, = 67, 180, 167,
> >> 3, 82, 243, 25, 97, 214, 83, 133, 69, 16, 104, 54, 160, 200, = 41, 83,
> >> 164, 187, 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211,= 45, 148, 58,
> >> 23, 62, 227, 74, 52, 117, 42, 90, 41, 249, 130, 154, 80, 119,= 61, 26,
> >> 193, 40, 125, 10, 152, 174, 227, 225, 205, 32, 62, 66, 6, 163= , 100, 99,
> >> 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, 69, 1, 80,= 171, 167,
> >> 20, 196, 156, 109, 249, 88, 0, 3, 152, 38, 165, 72, 87, 6, 15= 2, 71,
> >> 156, 214, 16, 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 2= 49, 91,
> >> 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, 135, 105, 12= 7, 84, 171,
> >> 181, 152, 210, 183, 126, 24, 46, 196, 90, 173, 38, 245, 219, = 186, 222, 27,
> >> 240, 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, 65, 2= 24, 81, 100,
> >> 85, 25, 204, 165, 203, 187, 175, 84, 100, 82, 15, 11, 23, 202= , 151, 107,
> >> 54, 41, 207, 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93= , 130, 89]
> >> The remaining RSA key parameters are included for completenes= s, but should not be needed
> >> DP
> >> [195, 73, 25, 109, 94, 183, 113, 84, 111, 85, 126, 178, 147, = 112, 188, 112,
> >> 204, 104, 218, 160, 140, 225, 143, 39, 178, 173, 101, 152, 19= 6, 152, 132, 110,
> >> 4, 112, 190, 133, 89, 181, 249, 135, 220, 174, 190, 120, 44, = 226, 34, 196,
> >> 22, 78, 158, 0, 186, 20, 75, 139, 200, 88, 76, 28, 47, 139, 1= 13, 195,
> >> 210, 236, 88, 127, 243, 40, 143, 161, 194, 132, 94, 160, 254,= 251, 112, 231,
> >> 82, 47, 128, 21, 114, 182, 135, 107, 9, 100, 167, 39, 118, 77= , 104, 196,
> >> 229, 235, 224, 110, 21, 173, 59, 25, 217, 121, 237, 220, 92, = 144, 100, 2,
> >> 46, 184, 34, 78, 163, 103, 22, 239, 147, 228, 81, 222, 145, 3= 3, 156, 43]
> >> DQ
> >> [163, 255, 21, 215, 132, 158, 205, 201, 14, 232, 35, 75, 42, = 207, 219, 180,
> >> 247, 69, 136, 239, 127, 144, 45, 67, 178, 229, 19, 119, 98, 1= 92, 124, 130,
> >> 21, 120, 198, 123, 142, 125, 70, 186, 207, 197, 127, 176, 123= , 33, 92, 119,
> >> 167, 146, 174, 4, 99, 149, 23, 194, 254, 170, 39, 203, 111, 1= 69, 208, 156,
> >> 188, 172, 128, 112, 225, 215, 125, 141, 14, 42, 25, 146, 17, = 251, 152, 142,
> >> 225, 60, 111, 143, 96, 79, 232, 116, 10, 74, 118, 122, 132, 8= , 117, 176,
> >> 208, 159, 133, 208, 149, 167, 81, 222, 131, 216, 31, 245, 78,= 241, 125, 153,
> >> 112, 54, 67, 31, 162, 25, 137, 252, 57, 85, 117, 6, 201, 169,= 234, 165]
> >> InverseQ
> >> [120, 216, 104, 231, 36, 65, 16, 28, 97, 24, 27, 80, 71, 12, = 61, 66,
> >> 42, 217, 176, 30, 186, 78, 183, 197, 69, 225, 191, 9, 203, 94= , 35, 86,
> >> 130, 157, 228, 244, 16, 177, 161, 98, 84, 101, 10, 213, 36, 7= 7, 23, 37,
> >> 33, 251, 132, 62, 99, 108, 52, 51, 219, 46, 130, 234, 168, 37= , 115, 156,
> >> 86, 239, 116, 30, 241, 249, 57, 126, 155, 73, 127, 120, 84, 2= 27, 216, 168,
> >> 170, 192, 106, 132, 244, 246, 65, 246, 115, 83, 192, 197, 111= , 31, 117, 81,
> >> 69, 34, 214, 0, 43, 207, 157, 40, 176, 63, 195, 121, 82, 204,= 190, 89,
> >> 21, 210, 249, 94, 211, 110, 156, 72, 134, 247, 169, 77, 241, = 52, 52, 218]
> >> P
> >> [246, 6, 54, 195, 162, 58, 75, 162, 244, 142, 225, 10, 177, 1= 83, 131, 3,
> >> 10, 93, 245, 99, 31, 130, 161, 104, 120, 15, 111, 19, 33, 20,= 186, 78,
> >> 36, 47, 0, 74, 114, 135, 181, 199, 129, 198, 235, 200, 164, 2= 47, 95, 33,
> >> 116, 52, 132, 246, 240, 208, 73, 199, 0, 223, 21, 199, 56, 1,= 78, 60,
> >> 159, 17, 244, 71, 136, 1, 180, 226, 213, 92, 1, 98, 118, 211,= 167, 206,
> >> 215, 251, 23, 15, 90, 81, 15, 146, 183, 104, 80, 165, 186, 21= 0, 216, 44,
> >> 213, 163, 93, 252, 217, 220, 244, 177, 21, 84, 243, 18, 223, = 221, 51, 108,
> >> 92, 109, 241, 51, 127, 110, 38, 129, 129, 233, 77, 129, 176, = 189, 230, 195]
> >> Q
> >> [184, 169, 66, 42, 242, 175, 253, 146, 76, 85, 199, 72, 179, = 155, 213, 73,
> >> 79, 250, 112, 251, 88, 35, 89, 99, 91, 43, 68, 197, 95, 236, = 146, 203,
> >> 111, 69, 35, 98, 246, 190, 186, 141, 215, 125, 251, 32, 97, 8= 5, 251, 134,
> >> 226, 200, 108, 167, 104, 251, 172, 105, 200, 138, 143, 116, 2= 13, 16, 94, 30,
> >> 142, 147, 60, 165, 149, 87, 41, 15, 187, 88, 152, 133, 5, 240= , 214, 50,
> >> 0, 5, 252, 62, 49, 91, 13, 251, 118, 208, 239, 165, 139, 118,= 221, 146,
> >> 15, 27, 7, 179, 186, 187, 204, 252, 148, 200, 117, 230, 166, = 206, 242, 113,
> >> 158, 92, 239, 108, 6, 145, 76, 13, 58, 54, 30, 150, 105, 34, = 53, 45]
> >> END RSA KEY PARAMETERS
> >> Encrypted Key
> >> [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193,= 6, 244,
> >> 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 24= 4, 188, 215,
> >> 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152,= 28, 149, 16,
> >> 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 194, = 58, 206, 201,
> >> 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 40, 119, 17= 0, 7, 36,
> >> 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 75, 32, 48, 193= , 119, 202,
> >> 41, 152, 210, 190, 68, 57, 119, 4, 197, 74, 7, 242, 239, 170,= 204, 73,
> >> 75, 213, 202, 113, 216, 18, 23, 66, 106, 208, 69, 244, 117, 1= 47, 2, 37,
> >> 207, 199, 184, 96, 102, 44, 70, 212, 87, 143, 253, 0, 166, 59= , 41, 115,
> >> 217, 80, 165, 87, 38, 5, 9, 184, 202, 68, 67, 176, 4, 87, 254= , 166,
> >> 227, 88, 124, 238, 249, 75, 114, 205, 148, 149, 45, 78, 193, = 134, 64, 189,
> >> 168, 76, 170, 76, 176, 72, 148, 77, 215, 159, 146, 55, 189, 2= 13, 85, 253,
> >> 135, 200, 59, 247, 79, 37, 22, 200, 32, 110, 53, 123, 54, 39,= 9, 178,
> >> 231, 238, 95, 25, 211, 143, 87, 220, 88, 138, 209, 13, 227, 7= 2, 58, 102,
> >> 164, 136, 241, 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 24= 8, 181, 138,
> >> 251, 116, 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 15= 3, 251]
> >> Encoded Encrypted Key
> >> IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYH= JUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfKKZjSvkQ5= dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz2VClVyYFCbjKREOwBFf= -puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8g7908lFsggbjV7NicJsufuXxnTj1= fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKBjsExQKZ-w
> >> Ciphertext
> >> [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 22= 9, 146, 217,
> >> 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 2= 21, 207, 239,
> >> 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 142= , 7, 69,
> >> 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 59,= 180, 107,
> >> 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 30, 2= 23, 147]
> >> Encoded Ciphertext
> >> _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6Bgj= gdFLjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M
> >> Secured Input
> >> eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiL= CJpdiI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO= 1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByTh= KI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1Fe= P_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8= g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKB= jsExQKZ-w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFL= jeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M
> >> Secured Input Bytes
> >> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48,= 69, 120,
> >> 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105,= 74, 66,
> >> 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 53= , 48,
> >> 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, = 74, 112,
> >> 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 8= 2, 69,
> >> 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 7= 4, 118,
> >> 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 5= 0, 104,
> >> 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, = 104,
> >> 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48,= 118,
> >> 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119= , 95, 71,
> >> 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95,= 67,
> >> 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81,= 99, 97,
> >> 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 11= 3, 66,
> >> 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 5= 4, 83,
> >> 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81= , 53, 100,
> >> 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 118,= 86, 121,
> >> 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 87, 8= 4, 65,
> >> 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 101= , 80, 95,
> >> 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 121, 89,= 70, 67,
> >> 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 117, 78, = 89, 102,
> >> 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 115, 71, 71= , 81,
> >> 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 100, 101,= 102, 107,
> >> 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 57, 48, 56, 1= 08, 70,
> >> 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 115, 117, 10= 2, 117, 88,
> >> 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 82, 68, 101, 78,= 73, 79,
> >> 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 103, 84, 83, 122,= 48, 111,
> >> 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 49, 122, 89, 108, 79= , 73,
> >> 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 90, 45, 119, 46, = 95, 90,
> >> 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 83, 67, 75, 105, = 114, 101,
> >> 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 105, 83, 71, 50, 8= 5, 106,
> >> 70, 117, 106, 81, 118, 100, 122, 45, 95, 80, 81, 100, 85, 99,= 70, 78,
> >> 107, 79, 117, 108, 101, 103, 68, 54, 66, 103, 106, 103, 100, = 70, 76, 106,
> >> 101, 66, 52, 72, 72, 79, 79, 55, 85, 72, 118, 80, 56, 80, 69,= 68,
> >> 117, 48, 97, 48, 115, 65, 50, 97, 95, 45, 67, 73, 48, 119, 50= , 89,
> >> 81, 81, 50, 81, 81, 101, 51, 53, 77]
> >> Integrity Value
> >> [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 1= 47, 102, 136,
> >> 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 1= 86, 15, 73]
> >> Encoded Integrity Value
> >> c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k
> >> JWE
> >> eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiL= CJpdiI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ.IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO= 1DImCn0vNeuoBq847Sl6qw_GHSYHJUQXtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByTh= KI261QevEK56SyAwwXfKKZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1Fe= P_QCmOylz2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9h8= g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK-3T1zYlOIiIKB= jsExQKZ-w._Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdFL= jeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M.c41k4T4eAgCCt63m8ZNmiOinMciFFypO= Fpvid7i6D0k
> >>
> >> <JWE.log>______________________________________________= _
> >> 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
>
>
>
> --
> --Breno
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

--485b3918a9c838c44f04c37f338c-- From James.H.Manger@team.telstra.com Wed Jun 27 23: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 DB4DF11E815F for ; Wed, 27 Jun 2012 23:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goZtZv09ZN19 for ; Wed, 27 Jun 2012 23:22: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 7926F11E8097 for ; Wed, 27 Jun 2012 23:22:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,489,1336312800"; d="scan'208,217";a="79986316" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 28 Jun 2012 16:22:46 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6755"; a="81863552" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcavi.tcif.telstra.com.au with ESMTP; 28 Jun 2012 16:22:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Thu, 28 Jun 2012 16:22:45 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 28 Jun 2012 16:22:41 +1000 Thread-Topic: Complete JWE computation example Thread-Index: Ac1T/GRGQNrJnE+VSraU0uTeYqzhVgA9cUew Message-ID: <255B9BB34FB7D647A506DC292726F6E114F730F5A4@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366569F40@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F730F5A4WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Complete JWE computation example 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, 28 Jun 2012 06:22:51 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F730F5A4WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNhbGN1bGF0aW9ucyBpbiB0aGVzZSBleGFtcGxlcyB3b3JrZWQgZm9yIG1lIHRvby4gUHJv dmlkaW5nIGJpbmFyeSB2YWx1ZXMgYXMgY29tbWEtc2VwYXJhdGVkIGRlY2ltYWwgdmFsdWVzIGZv ciBlYWNoIGJ5dGUgaXMgYSBiaXQgYW5ub3lpbmcuIEkgZ3Vlc3MgdGhpcyBpcyBhIEphdmFTY3Jp cHQgdGhpbmcuDQoNClRoZSBrZXkgZGVyaXZhdGlvbiBjYW5ub3QgcmVhbGx5IGNhbGwgaXRzZWxm IHRoZSBDb25jYXQgS0RGIGZyb20gTklTVCA4MDAgNTZBLiBMZWF2aW5nIHRoZSBBbGdvcml0aG1J RCwgUGFydHlVSW5mbyAoc2VuZGVyIGlkKSwgYW5kIFBhcnR5VkluZm8gKHJlY2VpdmVyIGlkKSBl bXB0eSBpcyBub3QgYWxsb3dlZC4gQWRkaXRpb25hbGx5LCB0aGUgTklTVCBzcGVj4oCZcyB3YXkg b2YgZGVyaXZpbmcgYW4gSE1BQyBhbmQgQUVTIGtleSB3b3VsZCBiZSB0byBydW4gdGhlIEtERiBv bmNlIHRvIGdlbmVyYXRlIGVub3VnaCBiaXRzIGZvciBib3RoIGtleXMgKOKAnGNvbmNhdGVuYXRl ZOKAnSkuIEpXRSwgaW4gY29udHJhc3QsIHJ1bnMgdGhlIEtERiB0d2ljZSB0byBnZXQgdGhlIEhN QUMgYW5kIEFFUyBrZXlzIHNlcGFyYXRlbHkuDQoNCk5vdGhpbmcgYWN0dWFsbHkgc3BlY2lmaWVz IHRoZSBhY3R1YWwga2V5IHNpemUgZm9yIHRoZSBIUzI1NiBjYWxjdWxhdGlvbi4gSldBIG9ubHkg c2F5cyAyNTYtYml0cyBpcyB0aGUgbWluaW11bSBrZXkgbGVuZ3RoLg0KDQpQbGVhc2UgcHV0IGEg a2V5IGlkIGluIHRoZSBoZWFkZXIuIEpXRSBkZWNyeXB0aW9uIHN0ZXAgNSBzYXlzIOKAnHZlcmlm eSB0aGF0IHRoZSBKV0UgSGVhZGVyIHJlZmVyZW5jZXMgYSBrZXkga25vd24gdG8gdGhlIHJlY2lw aWVudOKAnSB3aGljaCBpcyBhIGJpdCBoYXJkIHdpdGggbm8ga2V5IHJlZmVyZW5jZS4gRXZlcnlv bmUgc2hvdWxkIHN1cHBvcnQga2V5IHJvbGxvdmVyIChldmVuIGlmIG1hbnVhbGx5KSB3aGljaCBi YXNpY2FsbHkgbmVlZHMgYSBrZXkgaWQgc28gaXQgbWF5IGFzIHdlbGwgYmUgbWFuZGF0b3J5LiBJ ZiB0aGUga2V5IGlkIGlzIGNvbnZleWVkIG91dC1vZi1iYW5kIChvciBtZXJlbHkgaW1wbGllZCkg aXQgaXNu4oCZdCBwcm90ZWN0ZWQgYnkgdGhlIGludGVncml0eSBjaGVjayDigJMgd2hpY2ggYWxt b3N0IHN0YXJ0cyB0byB1bmRvIHRoZSBhcmd1bWVudCBmb3IgaW50ZWdyaXR5LXByb3RlY3Rpb24g b2YgdGhlIGhlYWRlci4NCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IGpvc2UtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1p a2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwgMjcgSnVuZSAyMDEyIDEwOjMzIEFNDQpUbzogam9z ZUBpZXRmLm9yZw0KU3ViamVjdDogW2pvc2VdIENvbXBsZXRlIEpXRSBjb21wdXRhdGlvbiBleGFt cGxlDQoNCkRlYXIgd29ya2luZyBncm91cCBtZW1iZXJzLA0KDQpGb3IgdGhlIG5leHQgcm91bmQg b2YgdGhlIEpPU0UgSldFIHNwZWMsIEnigJltIGFkZGluZyBleGFtcGxlIGVuY3J5cHRpb24gY29t cHV0YXRpb25zIHRvIGFpZCBpbXBsZW1lbnRlcnMuICBBbiBleGFtcGxlIEpXRSBjb21wdXRhdGlv biBpcyBpbmNsdWRlZCBiZWxvdywgaW4gY2FzZSB5b3XigJlkIGxpa2UgdG8gY29tcGFyZSB5b3Vy IGltcGxlbWVudGF0aW9ucyBhZ2FpbnN0IHRoZXNlLiAgVGhlc2UgdmFsdWVzIGhhdmUgYWxyZWFk eSBiZWVuIHZlcmlmaWVkIGJ5IHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMuDQoNClRo aXMgZXhhbXBsZSB1c2VzIHRoZSBoZWFkZXIgdmFsdWVzOg0KICAgIHsiYWxnIjoiUlNBMV81Iiwi ZW5jIjoiQTEyOENCQyIsImludCI6IkhTMjU2IiwiaXYiOiJBeFk4REN0RGFHbHNiR2xqYjNSb1pR In0NCuKApg0K --_000_255B9BB34FB7D647A506DC292726F6E114F730F5A4WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIGNh bGN1bGF0aW9ucyBpbiB0aGVzZSBleGFtcGxlcyB3b3JrZWQgZm9yIG1lIHRvby4gUHJvdmlkaW5n IGJpbmFyeSB2YWx1ZXMgYXMgY29tbWEtc2VwYXJhdGVkIGRlY2ltYWwgdmFsdWVzIGZvciBlYWNo IGJ5dGUgaXMgYSBiaXQgYW5ub3lpbmcuIEkgZ3Vlc3MgdGhpcyBpcyBhIEphdmFTY3JpcHQgdGhp bmcuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIGtleSBkZXJpdmF0aW9uIGNhbm5v dCByZWFsbHkgY2FsbCBpdHNlbGYgdGhlIENvbmNhdCBLREYgZnJvbSBOSVNUIDgwMCA1NkEuIExl YXZpbmcgdGhlIEFsZ29yaXRobUlELCBQYXJ0eVVJbmZvIChzZW5kZXIgaWQpLCBhbmQgUGFydHlW SW5mbyAocmVjZWl2ZXIgaWQpIGVtcHR5IGlzIG5vdCBhbGxvd2VkLiBBZGRpdGlvbmFsbHksIHRo ZSBOSVNUIHNwZWPigJlzIHdheSBvZiBkZXJpdmluZyBhbiBITUFDIGFuZCBBRVMga2V5IHdvdWxk IGJlIHRvIHJ1biB0aGUgS0RGIG9uY2UgdG8gZ2VuZXJhdGUgZW5vdWdoIGJpdHMgZm9yIGJvdGgg a2V5cyAo4oCcY29uY2F0ZW5hdGVk4oCdKS4gSldFLCBpbiBjb250cmFzdCwgcnVucyB0aGUgS0RG IHR3aWNlIHRvIGdldCB0aGUgSE1BQyBhbmQgQUVTIGtleXMgc2VwYXJhdGVseS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5Ob3RoaW5nIGFjdHVhbGx5IHNwZWNpZmllcyB0aGUgYWN0dWFs IGtleSBzaXplIGZvciB0aGUgSFMyNTYgY2FsY3VsYXRpb24uIEpXQSBvbmx5IHNheXMgMjU2LWJp dHMgaXMgdGhlIG1pbmltdW0ga2V5IGxlbmd0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz5QbGVhc2UgcHV0IGEga2V5IGlkIGluIHRoZSBoZWFkZXIuIEpXRSBkZWNyeXB0aW9uIHN0ZXAg NSBzYXlzIOKAnHZlcmlmeSB0aGF0IHRoZSBKV0UgSGVhZGVyIHJlZmVyZW5jZXMgYSBrZXkga25v d24gdG8gdGhlIHJlY2lwaWVudOKAnSB3aGljaCBpcyBhIGJpdCBoYXJkIHdpdGggbm8ga2V5IHJl ZmVyZW5jZS4gRXZlcnlvbmUgc2hvdWxkIHN1cHBvcnQga2V5IHJvbGxvdmVyIChldmVuIGlmIG1h bnVhbGx5KSB3aGljaCBiYXNpY2FsbHkgbmVlZHMgYSBrZXkgaWQgc28gaXQgbWF5IGFzIHdlbGwg YmUgbWFuZGF0b3J5LiBJZiB0aGUga2V5IGlkIGlzIGNvbnZleWVkIG91dC1vZi1iYW5kIChvciBt ZXJlbHkgaW1wbGllZCkgaXQgaXNu4oCZdCBwcm90ZWN0ZWQgYnkgdGhlIGludGVncml0eSBjaGVj ayDigJMgd2hpY2ggYWxtb3N0IHN0YXJ0cyB0byB1bmRvIHRoZSBhcmd1bWVudCBmb3IgaW50ZWdy aXR5LXByb3RlY3Rpb24gb2YgdGhlIGhlYWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxi PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBq b3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCAyNyBK dW5lIDIwMTIgMTA6MzMgQU08YnI+PGI+VG86PC9iPiBqb3NlQGlldGYub3JnPGJyPjxiPlN1Ympl Y3Q6PC9iPiBbam9zZV0gQ29tcGxldGUgSldFIGNvbXB1dGF0aW9uIGV4YW1wbGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPkRlYXIgd29ya2luZyBn cm91cCBtZW1iZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVM+Rm9yIHRoZSBuZXh0IHJvdW5kIG9mIHRoZSBKT1NFIEpXRSBz cGVjLCBJ4oCZbSBhZGRpbmcgZXhhbXBsZSBlbmNyeXB0aW9uIGNvbXB1dGF0aW9ucyB0byBhaWQg aW1wbGVtZW50ZXJzLiZuYnNwOyBBbiBleGFtcGxlIEpXRSBjb21wdXRhdGlvbiBpcyBpbmNsdWRl ZCBiZWxvdywgaW4gY2FzZSB5b3XigJlkIGxpa2UgdG8gY29tcGFyZSB5b3VyIGltcGxlbWVudGF0 aW9ucyBhZ2FpbnN0IHRoZXNlLiZuYnNwOyBUaGVzZSB2YWx1ZXMgaGF2ZSBhbHJlYWR5IGJlZW4g dmVyaWZpZWQgYnkgdHdvIGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPlRoaXMg ZXhhbXBsZSB1c2VzIHRoZSBoZWFkZXIgdmFsdWVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgeyZxdW90 O2FsZyZxdW90OzomcXVvdDtSU0ExXzUmcXVvdDssJnF1b3Q7ZW5jJnF1b3Q7OiZxdW90O0ExMjhD QkMmcXVvdDssJnF1b3Q7aW50JnF1b3Q7OiZxdW90O0hTMjU2JnF1b3Q7LCZxdW90O2l2JnF1b3Q7 OiZxdW90O0F4WThEQ3REYUdsc2JHbGpiM1JvWlEmcXVvdDt9PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E114F730F5A4WSMSG3153Vsrv_-- From ietf@augustcellars.com Wed Jun 27 23:35:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433A811E8176 for ; Wed, 27 Jun 2012 23:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prWS3Vtn1rDn for ; Wed, 27 Jun 2012 23:35:09 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id BCC7011E80E9 for ; Wed, 27 Jun 2012 23:35:09 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9F1D92C9FD; Wed, 27 Jun 2012 23:35:08 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" , "'Manger, James H'" References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Date: Wed, 27 Jun 2012 23:33:49 -0700 Message-ID: <01c301cd54f7$fb3f7e30$f1be7a90$@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: AQD47QI5KEiTUDL2CmgL/J0d6D+eqAIQ+tNPAngGm3sBp8FZzQCi2RReAsTTS8kCA+Ah3wFgm5IOAewtyZUBrdh95JgzXe/g Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] protected attributes 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, 28 Jun 2012 06:35:10 -0000 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Wednesday, June 27, 2012 6:50 PM > To: Manger, James H > Cc: jose@ietf.org > Subject: Re: [jose] protected attributes > > > On Jun 26, 2012, at 10:18 PM, Manger, James H wrote: > > > Richard Barnes wrote (in the thread "Re: [jose] New Version Notification > for draft-barnes-jose-jsms-00.txt"): > >> You can have something like JWT specify a body format that has the > >> protected parameters, so why does JWS/JWE need integrity-protected > >> attributes? > > > > > > One attribute is whether or not the content of this JWS/JWE is another > JWS/JWE. This attribute is more a part of the JWS/JWE processing than > metadata for the content. > > > > For instance, if a sender signs-then-encrypts content it would be good if an > attacker cannot change it to appear to be just encrypted content. > > Can you describe what attack this would prevent? > > Again noting precedent: If you look at S/MIME, for example, the Content- > Type of the MIME body is inside of the CMS EnvelopedData structure, so the > presence of SignedData on the inside would not be observable. > True and false - If you look at S/MIME you would see an id-data, however if you look at CMS you might see id-SignedData as the encapsulated content type. For S/MIME it would be data - since the next wrapping layer is mime not SignedData. Jim > > > Is it too unlikely that a receiving app will mistake a JWS for the content it > expected? If an app expected a JSON object as the content (eg as per JWT) > but got a JWS, is it conceivable that it could mistake the JWS header for the > JWT? > > In general, applications that use JOSE are going to need to specify what the > protected content must be. I think that if the above question arises, then > the application protocol is underspecified. > > --Richard > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Thu Jun 28 00:43: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 455CA21F8843 for ; Thu, 28 Jun 2012 00:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LAa5lDqF6cD for ; Thu, 28 Jun 2012 00:43:00 -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 2F09821F883E for ; Thu, 28 Jun 2012 00:42:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,490,1336312800"; d="scan'208";a="84815646" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 28 Jun 2012 17:42:58 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6755"; a="68283149" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdni.tcif.telstra.com.au with ESMTP; 28 Jun 2012 17:42:59 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 28 Jun 2012 17:42:58 +1000 From: "Manger, James H" To: Jim Schaad , "'Richard L. Barnes'" Date: Thu, 28 Jun 2012 17:42:57 +1000 Thread-Topic: [jose] protected attributes Thread-Index: AQD47QI5KEiTUDL2CmgL/J0d6D+eqAIQ+tNPAngGm3sBp8FZzQCi2RReAsTTS8kCA+Ah3wFgm5IOAewtyZUBrdh95JgzXe/ggAABYdA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F730F705@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> <01c301cd54f7$fb3f7e30$f1be7a90$@augustcellars.com> In-Reply-To: <01c301cd54f7$fb3f7e30$f1be7a90$@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 Cc: "jose@ietf.org" Subject: Re: [jose] protected attributes 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, 28 Jun 2012 07:43:01 -0000 UmljaGFyZCwNCg0KPj4+PiBZb3UgY2FuIGhhdmUgc29tZXRoaW5nIGxpa2UgSldUIHNwZWNpZnkg YSBib2R5IGZvcm1hdCB0aGF0IGhhcyB0aGUNCj4+Pj4gcHJvdGVjdGVkIHBhcmFtZXRlcnMsIHNv IHdoeSBkb2VzIEpXUy9KV0UgbmVlZCBpbnRlZ3JpdHktcHJvdGVjdGVkDQo+Pj4+IGF0dHJpYnV0 ZXM/DQoNCj4+PiBPbmUgYXR0cmlidXRlIGlzIHdoZXRoZXIgb3Igbm90IHRoZSBjb250ZW50IG9m IHRoaXMgSldTL0pXRSBpcw0KPj4+IGFub3RoZXIgSldTL0pXRS4gVGhpcyBhdHRyaWJ1dGUgaXMg bW9yZSBhIHBhcnQgb2YgdGhlIEpXUy9KV0UNCj4+PiBwcm9jZXNzaW5nIHRoYW4gbWV0YWRhdGEg Zm9yIHRoZSBjb250ZW50Lg0KPj4+DQo+Pj4gRm9yIGluc3RhbmNlLCBpZiBhIHNlbmRlciBzaWdu cy10aGVuLWVuY3J5cHRzIGNvbnRlbnQgaXQgd291bGQgYmUNCj4+PiBnb29kIGlmIGFuIGF0dGFj a2VyIGNhbm5vdCBjaGFuZ2UgaXQgdG8gYXBwZWFyIHRvIGJlIGp1c3QgZW5jcnlwdGVkDQo+Pj4g Y29udGVudC4NCg0KPj4gQ2FuIHlvdSBkZXNjcmliZSB3aGF0IGF0dGFjayB0aGlzIHdvdWxkIHBy ZXZlbnQ/DQoNCkkgY2FuIGRlc2NyaWJlIGEgc29tZXdoYXQgYXJ0aWZpY2lhbCBhdHRhY2suDQpB bGljZSBjcmVhdGVzIGEgbWVzc2FnZQ0KICB7ImlzcyI6IkJvYiIsInBlcm0iOiJyZWFkIiwiYWxn IjoiUlMyNTYifS57ImlzcyI6IkJvYiIsInBlcm0iOiJ3cml0ZSIsLi4ufQ0KQWxpY2Ugc2F5cyBp dCBpcyBhICJKV1QgYmFnIG9mIGNsYWltcyIgYW5kIGFza3MgQm9iIHRvIHNpZ24gaXQuDQpCb2Ig ZXhwZWN0cyBhIEpTT04gb2JqZWN0IHNvIG9ubHkgInNlZXMiIHRoZSBmaXJzdCBwYXJ0Lg0KSGUg Y29uZmlybXMgQWxpY2UgZG9lcyBoYXZlICJyZWFkIiBwZXJtaXNzaW9uLA0KY29uZmlybXMgaGUg aXMgbGlzdGVkIGFzIHRoZSBpc3N1ZXIsIGFuZCBhY2NlcHRzIGFueXRoaW5nIGVsc2UNCmFzIHVu dmVyaWZpZWQgdXNlci1hc3NlcnRlZCBzdHVmZiAobGlrZSBhIGxvdCBvZiBkZXRhaWxzIGluIA0K cHVibGljIGNlcnRpZmljYXRlcykuDQpCb2Igc2lnbnMgdGhlIG1lc3NhZ2UsIHByZXBlbmRpbmcg YW4gdW5wcm90ZWN0ZWQgaGVhZGVyIHdpdGggdGhlDQpkZXRhaWxzLg0KDQpBbGljZSBtb2RpZmll cyB0aGUgdW5wcm90ZWN0ZWQgSk9TRSBoZWFkZXIsDQphZGRpbmcgImVtYmVkIjp0cnVlIHRvIEJv YidzIGhlYWRlci4NCg0KQ2hhcmxpZSByZWNlaXZlcyB0aGUgbWVzc2FnZSBhbmQgcGFzc2VzIGl0 IHRvIGhpcyBKT1NFIGxpYnJhcnkuDQpUaGUgbGlicmFyeSB2ZXJpZmllcyBCb2IncyBzaWduYXR1 cmUsIGludGVycHJldHMgdGhlIGNvbnRlbnQNCmFzIGFub3RoZXIgSk9TRSBtZXNzYWdlLCB2ZXJp ZmllcyBBbGljZSdzIHNpZ25hdHVyZSwgYW5kIHBhc3Nlcw0KYmFjayB0byBDaGFybGllIHsiaXNz IjoiQm9iIiwicGVybSI6IndyaXRlIiwuLi59IHBsdXMgbWV0YWRhdGEgc2F5aW5nDQppdCB3YXMg c2lnbmVkIGJ5IEJvYiBhbmQgQWxpY2UuDQpDaGFybGllIHRydXN0cyBCb2IgYW5kIGhlbmNlIGdp dmVzIEFsaWNlIHdyaXRlIGFjY2Vzcy4NCkFUVEFDSyBTVUNDRUVERUQNCg0KVGhpcyBvbmx5IHdv cmtzIGlmIGEgYmxvY2sgb2YgZGF0YSBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgYQ0KdmFsaWQgSk9T RSBtZXNzYWdlIGJ5IG9uZSBwYXJ0eSBhbmQgYXMgdmFsaWQgYXBwbGljYXRpb24NCmNvbnRlbnQg YnkgYW5vdGhlciBwYXJ0eS4gVGhhdCBpcyBhIGJpdCB1bnVzdWFsIGJ1dCBmYXIgZnJvbQ0KaW1w b3NzaWJsZS4gQ29uY2F0ZW5hdGUgYSAqLkdJRiBhbmQgYSAqLlpJUCBmaWxlIGFuZCB5b3UNCmdl dCBhIHZhbGlkIGltYWdlIGFuZCBhIHZhbGlkIFpJUCBhcmNoaXZlIChzaW5jZSB0aGV5IGFyZQ0K cGFyc2VkIGZyb20gdGhlIHN0YXJ0ICYgZW5kIHJlc3BlY3RpdmVseSkuDQoNCg0KV2l0aG91dCBw cm90ZWN0aW5nIHRoZSAiZW1iZWQiIGF0dHJpYnV0ZSBKT1NFIGdpdmVzOg0KDQogICAgICAgICAg ICAgIFsgICAgICAgXSAgICBbICAgICAgIF0gLS0tLS0+IElOVkFMSUQNCiBjb250ZW50IC0tLT4g WyBKT1NFICBdIC0+IFsgSk9TRSAgXSAtb3ItLT4gY29udGVudA0KICAgICAgICAgICAgICBbIHdy YXAgIF0gICAgW3Vud3JhcCBdIC1vci0tPiBpbnRlcm1lZGlhdGUgY29udGVudA0KDQpJdCB3b3Vs ZCBiZSBuaWNlIG5vdCB0byBuZWVkIHRvIHJlbHkgb24gYXBwbGljYXRpb24NCmxvZ2ljIHRvIGRp c3Rpbmd1aXNoICJpbnRlcm1lZGlhdGUgY29udGVudCIgZnJvbQ0KdGhlIGFjdHVhbCAiY29udGVu dCIuIFRoYXQgaXMsIHRoZSAzcmQgb3B0aW9uIHNob3VsZCBiZQ0KZGV0ZWN0ZWQgYXMgSU5WQUxJ RCAoZWcgYnkgc2lnbmluZyB0aGUgImVtYmVkIiBhdHRyaWJ1dGUpLg0KDQoNCg0KPj4gQWdhaW4g bm90aW5nIHByZWNlZGVudDogSWYgeW91IGxvb2sgYXQgUy9NSU1FLCBmb3IgZXhhbXBsZSwgdGhl DQo+PiBDb250ZW50LVR5cGUgb2YgdGhlIE1JTUUgYm9keSBpcyBpbnNpZGUgb2YgdGhlIENNUyBF bnZlbG9wZWREYXRhDQo+PiBzdHJ1Y3R1cmUsIHNvIHRoZSBwcmVzZW5jZSBvZiBTaWduZWREYXRh IG9uIHRoZSBpbnNpZGUgd291bGQgbm90DQo+PiBiZSBvYnNlcnZhYmxlLg0KDQo+IFRydWUgYW5k IGZhbHNlIC0gSWYgeW91IGxvb2sgYXQgUy9NSU1FIHlvdSB3b3VsZCBzZWUgYW4gaWQtZGF0YSwN Cj4gaG93ZXZlciBpZiB5b3UgbG9vayBhdCBDTVMgeW91IG1pZ2h0IHNlZSBpZC1TaWduZWREYXRh IGFzIHRoZQ0KPiBlbmNhcHN1bGF0ZWQgY29udGVudCB0eXBlLiAgRm9yIFMvTUlNRSBpdCB3b3Vs ZCBiZSBkYXRhIC0gc2luY2UNCj4gdGhlIG5leHQgd3JhcHBpbmcgbGF5ZXIgaXMgbWltZSBub3Qg U2lnbmVkRGF0YS4NCg0KU28gZG9lcyBldmVyeSBhcHAgdXNpbmcgSk9TRSBuZWVkIHRvIGRlZmlu ZSBhIE1JTUUtbGlrZSBlbmNhcHN1bGF0aW9uDQphcm91bmQgaXRzIGNvbnRlbnQgKGxpa2UgUy9N SU1FIGRvZXMpIHRvIHVzZSBKT1NFIHNhZmVseT8NCldoYXQgYXJlIHRoZSBuZWNlc3NhcnkgZmVh dHVyZXMgb2YgdGhhdCBlbmNhcHN1bGF0aW9uPw0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From rbarnes@bbn.com Thu Jun 28 07:16: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 5F1B021F85A2 for ; Thu, 28 Jun 2012 07:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 128Mh+mhsQMq for ; Thu, 28 Jun 2012 07:16:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE1B21F859B for ; Thu, 28 Jun 2012 07:16:17 -0700 (PDT) Received: from dhcp-192-1-255-151.col.bbn.com ([192.1.255.151]:63552) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkFVw-000712-Rq; Thu, 28 Jun 2012 10:16:08 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F730F705@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 28 Jun 2012 10:16:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13DF3FD5-6613-4AC9-BBDB-94061F95EC94@bbn.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> <01c301cd54f7$fb3f7e30$f1be7a90$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F730F705@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] protected attributes 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, 28 Jun 2012 14:16:21 -0000 Hey James, There are a few problems with this scenario. =20 > I can describe a somewhat artificial attack. > Alice creates a message > = {"iss":"Bob","perm":"read","alg":"RS256"}.{"iss":"Bob","perm":"write",...}= > Alice says it is a "JWT bag of claims" and asks Bob to sign it. > Bob expects a JSON object so only "sees" the first part. > He confirms Alice does have "read" permission, > confirms he is listed as the issuer, and accepts anything else > as unverified user-asserted stuff (like a lot of details in=20 > public certificates). > Bob signs the message, prepending an unprotected header with the > details. Most clearly, Bob is being irresponsible. He should not be signing = anything that he doesn't want to assert. Before he signs, he should be = verifying that he understands and agrees with everything in the = assertion. Bob should have signed only the part that he "saw". (Read = the contract before you sign it!) Attacks that rely on irresponsible = signer practices call for operational guidelines, not protocol changes. > Alice modifies the unprotected JOSE header, > adding "embed":true to Bob's header. There's no such thing as an unprotected header in JWS. =20 What is "embed"? I don't see it in the JWT or JWS specs: > Charlie receives the message and passes it to his JOSE library. > The library verifies Bob's signature, interprets the content > as another JOSE message, verifies Alice's signature, and passes > back to Charlie {"iss":"Bob","perm":"write",...} plus metadata saying > it was signed by Bob and Alice. > Charlie trusts Bob and hence gives Alice write access. > ATTACK SUCCEEDED I don't see where Alice signed anything in this example. Maybe you = could flesh it out a little? > This only works if a block of data can be interpreted as a > valid JOSE message by one party and as valid application > content by another party. That is a bit unusual but far from > impossible. Concatenate a *.GIF and a *.ZIP file and you > get a valid image and a valid ZIP archive (since they are > parsed from the start & end respectively). >=20 >=20 > Without protecting the "embed" attribute JOSE gives: >=20 > [ ] [ ] -----> INVALID > content ---> [ JOSE ] -> [ JOSE ] -or--> content > [ wrap ] [unwrap ] -or--> intermediate content >=20 > It would be nice not to need to rely on application > logic to distinguish "intermediate content" from > the actual "content". That is, the 3rd option should be > detected as INVALID (eg by signing the "embed" attribute). I don't think it's unreasonable to have the application define what it = is that's inside the protected content. You can do this either by = having something inside the protected content that says what it is (in = which case it's protected), or by fixing the type in the application = specification (and verifying this on receipt). S/MIME follows the first pattern, by having an inner Content-Type that = tells you what the protected MIME entity is. Matt Miller's XMPP e2e = security draft follows the second pattern, requiring the protected = content to be an XMPP stanza. For something like JWT, I would think you would just do the latter, and = require that the inner body be a set of claims, formatted in JSON.=20 >>> Again noting precedent: If you look at S/MIME, for example, the >>> Content-Type of the MIME body is inside of the CMS EnvelopedData >>> structure, so the presence of SignedData on the inside would not >>> be observable. >=20 >> True and false - If you look at S/MIME you would see an id-data, >> however if you look at CMS you might see id-SignedData as the >> encapsulated content type. For S/MIME it would be data - since >> the next wrapping layer is mime not SignedData. >=20 > So does every app using JOSE need to define a MIME-like encapsulation > around its content (like S/MIME does) to use JOSE safely? > What are the necessary features of that encapsulation? See above. The application needs to either specify the type of the = protected content in-band (like S/MIME) or define a fixed content type = (like XMPP). --Richard From James.H.Manger@team.telstra.com Thu Jun 28 22:56: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 858FF11E80CA for ; Thu, 28 Jun 2012 22:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8a0VSHycFgs for ; Thu, 28 Jun 2012 22:56:41 -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 886E111E808F for ; Thu, 28 Jun 2012 22:56:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,496,1336312800"; d="scan'208";a="82228513" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 29 Jun 2012 15:56:32 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6756"; a="72886168" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 29 Jun 2012 15:56:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 29 Jun 2012 15:56:32 +1000 From: "Manger, James H" To: "Richard L. Barnes" Date: Fri, 29 Jun 2012 15:56:30 +1000 Thread-Topic: [jose] protected attributes Thread-Index: Ac1VOJVd6ZVfgmElRMmySmadchqy2wAXpEtA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F73F48F8@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> <01c301cd54f7$fb3f7e30$f1be7a90$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F730F705@WSMSG3153V.srv.dir.telstra.com> <13DF3FD5-6613-4AC9-BBDB-94061F95EC94@bbn.com> In-Reply-To: <13DF3FD5-6613-4AC9-BBDB-94061F95EC94@bbn.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 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] protected attributes 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, 29 Jun 2012 05:56:42 -0000 PiA+IEkgY2FuIGRlc2NyaWJlIGEgc29tZXdoYXQgYXJ0aWZpY2lhbCBhdHRhY2suDQo+ID4gQWxp Y2UgY3JlYXRlcyBhIG1lc3NhZ2UNCj4gPg0KPiB7ImlzcyI6IkJvYiIsInBlcm0iOiJyZWFkIiwi YWxnIjoiUlMyNTYifS57ImlzcyI6IkJvYiIsInBlcm0iOiJ3cml0ZSIsLg0KPiAuLn0NCj4gPiBB bGljZSBzYXlzIGl0IGlzIGEgIkpXVCBiYWcgb2YgY2xhaW1zIiBhbmQgYXNrcyBCb2IgdG8gc2ln biBpdC4NCj4gPiBCb2IgZXhwZWN0cyBhIEpTT04gb2JqZWN0IHNvIG9ubHkgInNlZXMiIHRoZSBm aXJzdCBwYXJ0Lg0KPiA+IEhlIGNvbmZpcm1zIEFsaWNlIGRvZXMgaGF2ZSAicmVhZCIgcGVybWlz c2lvbiwNCj4gPiBjb25maXJtcyBoZSBpcyBsaXN0ZWQgYXMgdGhlIGlzc3VlciwgYW5kIGFjY2Vw dHMgYW55dGhpbmcgZWxzZQ0KPiA+IGFzIHVudmVyaWZpZWQgdXNlci1hc3NlcnRlZCBzdHVmZiAo bGlrZSBhIGxvdCBvZiBkZXRhaWxzIGluDQo+ID4gcHVibGljIGNlcnRpZmljYXRlcykuDQo+ID4g Qm9iIHNpZ25zIHRoZSBtZXNzYWdlLCBwcmVwZW5kaW5nIGFuIHVucHJvdGVjdGVkIGhlYWRlciB3 aXRoIHRoZQ0KPiA+IGRldGFpbHMuDQogDQo+IE1vc3QgY2xlYXJseSwgQm9iIGlzIGJlaW5nIGly cmVzcG9uc2libGUuICBIZSBzaG91bGQgbm90IGJlIHNpZ25pbmcNCj4gYW55dGhpbmcgdGhhdCBo ZSBkb2Vzbid0IHdhbnQgdG8gYXNzZXJ0LiAgQmVmb3JlIGhlIHNpZ25zLCBoZSBzaG91bGQgYmUN Cj4gdmVyaWZ5aW5nIHRoYXQgaGUgdW5kZXJzdGFuZHMgYW5kIGFncmVlcyB3aXRoIGV2ZXJ5dGhp bmcgaW4gdGhlDQo+IGFzc2VydGlvbi4gIEJvYiBzaG91bGQgaGF2ZSBzaWduZWQgb25seSB0aGUg cGFydCB0aGF0IGhlICJzYXciLiAgKFJlYWQNCj4gdGhlIGNvbnRyYWN0IGJlZm9yZSB5b3Ugc2ln biBpdCEpICBBdHRhY2tzIHRoYXQgcmVseSBvbiBpcnJlc3BvbnNpYmxlDQo+IHNpZ25lciBwcmFj dGljZXMgY2FsbCBmb3Igb3BlcmF0aW9uYWwgZ3VpZGVsaW5lcywgbm90IHByb3RvY29sIGNoYW5n ZXMuDQoNCkJvYiBpcyBub3QgbmVjZXNzYXJpbHkgYmVpbmcgcXVpdGUgYXMgaXJyZXNwb25zaWJs ZSBhcyBoZSBzZWVtcy4NCg0KQW55IENBIHdpbGwgc2lnbiAyNTYgYnl0ZXMgdGhhdCBJIGNhbiBj aG9vc2UgYWxtb3N0IGFyYml0cmFyaWx5DQphcyBsb25nIGFzIEkgc2F5IHRoZSBieXRlcyBhcmUg YSAyMDQ4LWJpdCBSU0EgbW9kdWx1cy4NClRoZSBDQSBpc24ndCBpcnJlc3BvbnNpYmxlLCBldmVu IGlmIHRob3NlIDI1NiBieXRlcyBhcmUgdGhlDQpVVEYtOCBlbmNvZGluZyBvZiAiVGhpcyBDQSBw cm9taXNlcyB0byBnaXZlIHlvdSAkMU3igKYiLg0KVGhpcyBpcyBvbmx5IHNhZmUgYmVjYXVzZSBh IERFUi1lbmNvZGVkIFRCU0NlcnRpZmljYXRlIGhhcyBzbw0KbXVjaCBzdHJ1Y3R1cmUgdGhhdCBp dCBpcyBpbmNvbmNlaXZhYmxlIHRoYXQgdGhvc2UgYnl0ZXMgY291bGQNCmJlIG1pc2ludGVycHJl dGVkIGFzIHNvbWUgb3RoZXIgYXBwbGljYXRpb24gbWVzc2FnZS4NCg0KSXQgaXMgbm90IGFic29s dXRlbHkgY2xlYXIgdG8gbWUgdGhhdCBhIEpPU0UgbWVzc2FnZQ0KKGluIHdoYXRldmVyIHN5bnRh eCB3ZSBlbmQgdXAgd2l0aCkgd2lsbCBoYXZlIHNvIG11Y2ggc3RydWN0dXJlDQp0aGF0IGl0IGlz IGluY29uY2VpdmFibGUgdGhhdCBhIHZhbHVlIGNvdWxkIGJlIGNyZWF0ZWQgdGhhdA0Kd2FzIGJv dGggYSB2YWxpZCBKT1NFIG1lc3NhZ2UgYW5kIGEgdmFsaWQgYXBwbGljYXRpb24gbWVzc2FnZQ0K c2ltdWx0YW5lb3VzbHkuDQoNCg0KPiA+IEFsaWNlIG1vZGlmaWVzIHRoZSB1bnByb3RlY3RlZCBK T1NFIGhlYWRlciwNCj4gPiBhZGRpbmcgImVtYmVkIjp0cnVlIHRvIEJvYidzIGhlYWRlci4NCj4g DQo+IFRoZXJlJ3Mgbm8gc3VjaCB0aGluZyBhcyBhbiB1bnByb3RlY3RlZCBoZWFkZXIgaW4gSldT Lg0KDQpUaGUgd2hvbGUgaWRlYSBvZiB0aGlzIHRocmVhZCB3YXMgdG8gZGlzY3VzcyB5b3VyIHN1 Z2dlc3Rpb24NCnRvIHJlcGxhY2UgSldTIHdpdGggYSBzeW50YXggdGhhdCBoYWQgYW4gdW5wcm90 ZWN0ZWQgaGVhZGVyLg0KDQoNCj4gV2hhdCBpcyAiZW1iZWQiPyAgSSBkb24ndCBzZWUgaXQgaW4g dGhlIEpXVCBvciBKV1Mgc3BlY3M6DQoNCiJlbWJlZCI6dHJ1ZSBpcyBvbmUgcG9zc2libGUgd2F5 IHRvIGluZGljYXRlIHRoYXQgdGhlIGNvbnRlbnQNCmlzIGFub3RoZXIgSk9TRSBtZXNzYWdlLCBu b3QgdGhlIGZpbmFsIGNvbnRlbnQuDQpEaWNrIEhhcmR0IHN1Z2dlc3RlZCBhbiAiZW1iIiBlbGVt ZW50IGluIHRoZSBKU09OIGhlYWRlciwNCmluc3RlYWQgb2YgbXkgc3VnZ2VzdGlvbiBvZiB1c2lu ZyB0aGUgY2FzZSAodXBwZXIgb3IgbG93ZXIpDQpvZiBhIHByZWZpeCAoRS48aGVhZGVyPi4uLiBv ciBlLjxoZWFkZXI+Li4uKS4NClRoZSBjdXJyZW50IHNwZWNzIHVzZSAidHlwIjoiSldTIiBmb3Ig dGhlIGluZGljYXRpb24uDQpTb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4NCg0KDQo+ID4gQ2hhcmxp ZSByZWNlaXZlcyB0aGUgbWVzc2FnZSBhbmQgcGFzc2VzIGl0IHRvIGhpcyBKT1NFIGxpYnJhcnku DQo+ID4gVGhlIGxpYnJhcnkgdmVyaWZpZXMgQm9iJ3Mgc2lnbmF0dXJlLCBpbnRlcnByZXRzIHRo ZSBjb250ZW50DQo+ID4gYXMgYW5vdGhlciBKT1NFIG1lc3NhZ2UsIHZlcmlmaWVzIEFsaWNlJ3Mg c2lnbmF0dXJlLCBhbmQgcGFzc2VzDQo+ID4gYmFjayB0byBDaGFybGllIHsiaXNzIjoiQm9iIiwi cGVybSI6IndyaXRlIiwuLi59IHBsdXMgbWV0YWRhdGEgc2F5aW5nDQo+ID4gaXQgd2FzIHNpZ25l ZCBieSBCb2IgYW5kIEFsaWNlLg0KPiA+IENoYXJsaWUgdHJ1c3RzIEJvYiBhbmQgaGVuY2UgZ2l2 ZXMgQWxpY2Ugd3JpdGUgYWNjZXNzLg0KPiA+IEFUVEFDSyBTVUNDRUVERUQNCj4gDQo+IEkgZG9u J3Qgc2VlIHdoZXJlIEFsaWNlIHNpZ25lZCBhbnl0aGluZyBpbiB0aGlzIGV4YW1wbGUuICBNYXli ZSB5b3UNCj4gY291bGQgZmxlc2ggaXQgb3V0IGEgbGl0dGxlPw0KDQp7ImlzcyI6IkJvYiIsInBl cm0iOiJyZWFkIiwiYWxnIjoiUlMyNTYiLi4ufS57ImlzcyI6IkJvYiIsInBlcm0iOiJ3cml0ZSIs Li4ufS48c2lnbmF0dXJlPg0KDQpBbGljZSBjcmVhdGVzIHRoaXMgbWVzc2FnZS4gSXQgaXMgYSB2 YWxpZCBKT1NFIHNpZ25lZCBtZXNzYWdlIChlZyAiYWxnIjoiUlMyNTYiIGluIGhlYWRlciksIHdp dGggc29tZSBleHRyYSBmaWVsZHMgKGVnICJwZXJtIjoicmVhZCIpIHRoYXQgYXJlIHVucmVjb2du aXplZCAoaGVuY2UgaWdub3JlZCkgYnkgYSBKT1NFIHJlY2VpdmVyLg0KDQpUaGlzIHNhbWUgbWVz c2FnZSBpcyBhbHNvIGEgdmFsaWQgYXBwbGljYXRpb24gbWVzc2FnZSBmcm9tIEJvYidzIHBlcnNw ZWN0aXZlLiBQZXJoYXBzIEJvYiBpZ25vcmVzIHRoZSBmaWVsZHMgbGlrZSAiYWxnIiB0aGF0IGhp cyBhcHAgZG9lc24ndCByZWNvZ25pemVkIChqdXN0IGxpa2UgdGhlIEpPU0UgcHJvY2Vzc29yIGln bm9yZXMgdGhlICJwZXJtIiBmaWVsZCksIG9yIHBlcmhhcHMgdGhlIGV4dHJhIHN0dWZmIGlzIHVz ZXItY2hvc2VuIGxpa2UgdGhlIG1vZHVsdXMgaW4gYSBjZXJ0aWZpY2F0ZS4NCg0KQm9iIGFkZHMg YSBsYXllciBvZiBKT1NFIHByb3RlY3Rpb24gdG8gdGhlIG1lc3NhZ2UgYW5kIGV4cGVjdHMgQ2hh cmxpZSB0byByZW1vdmUganVzdCB0aGlzIGxheWVyLiBDaGFybGllIGhvd2V2ZXIgcmVtb3ZlcyBi b3RoIEJvYidzIGFuZCBBbGljZSdzIEpPU0UgbGF5ZXJzIHNpbmNlIHRoZSBpbmRpY2F0aW9uIG9m IGFub3RoZXIgbGF5ZXIgaW4gQm9iJ3MgaGVhZGVyIHdhcyBub3QgcHJvdGVjdGVkIHNvIGl0IGNv dWxkIGJlIG1vZGlmaWVkLiBDaGFybGllIHZlcmlmaWVzIHRoYXQgdGhlIG1lc3NhZ2UgaXMgZnJv bSBCb2IsIGFuZCB0aGUgZmluYWwgY29udGVudCBoYXMgInBlcm0iOiJ3cml0ZSIuDQoNCg0KPiA+ IFRoaXMgb25seSB3b3JrcyBpZiBhIGJsb2NrIG9mIGRhdGEgY2FuIGJlIGludGVycHJldGVkIGFz IGENCj4gPiB2YWxpZCBKT1NFIG1lc3NhZ2UgYnkgb25lIHBhcnR5IGFuZCBhcyB2YWxpZCBhcHBs aWNhdGlvbg0KPiA+IGNvbnRlbnQgYnkgYW5vdGhlciBwYXJ0eS4gVGhhdCBpcyBhIGJpdCB1bnVz dWFsIGJ1dCBmYXIgZnJvbQ0KPiA+IGltcG9zc2libGUuIENvbmNhdGVuYXRlIGEgKi5HSUYgYW5k IGEgKi5aSVAgZmlsZSBhbmQgeW91DQo+ID4gZ2V0IGEgdmFsaWQgaW1hZ2UgYW5kIGEgdmFsaWQg WklQIGFyY2hpdmUgKHNpbmNlIHRoZXkgYXJlDQo+ID4gcGFyc2VkIGZyb20gdGhlIHN0YXJ0ICYg ZW5kIHJlc3BlY3RpdmVseSkuDQo+ID4NCj4gPg0KPiA+IFdpdGhvdXQgcHJvdGVjdGluZyB0aGUg ImVtYmVkIiBhdHRyaWJ1dGUgSk9TRSBnaXZlczoNCj4gPg0KPiA+ICAgICAgICAgICAgICBbICAg ICAgIF0gICAgWyAgICAgICBdIC0tLS0tPiBJTlZBTElEDQo+ID4gY29udGVudCAtLS0+IFsgSk9T RSAgXSAtPiBbIEpPU0UgIF0gLW9yLS0+IGNvbnRlbnQNCj4gPiAgICAgICAgICAgICAgWyB3cmFw ICBdICAgIFt1bndyYXAgXSAtb3ItLT4gaW50ZXJtZWRpYXRlIGNvbnRlbnQNCj4gPg0KPiA+IEl0 IHdvdWxkIGJlIG5pY2Ugbm90IHRvIG5lZWQgdG8gcmVseSBvbiBhcHBsaWNhdGlvbg0KPiA+IGxv Z2ljIHRvIGRpc3Rpbmd1aXNoICJpbnRlcm1lZGlhdGUgY29udGVudCIgZnJvbQ0KPiA+IHRoZSBh Y3R1YWwgImNvbnRlbnQiLiBUaGF0IGlzLCB0aGUgM3JkIG9wdGlvbiBzaG91bGQgYmUNCj4gPiBk ZXRlY3RlZCBhcyBJTlZBTElEIChlZyBieSBzaWduaW5nIHRoZSAiZW1iZWQiIGF0dHJpYnV0ZSku DQo+IA0KPiBJIGRvbid0IHRoaW5rIGl0J3MgdW5yZWFzb25hYmxlIHRvIGhhdmUgdGhlIGFwcGxp Y2F0aW9uIGRlZmluZSB3aGF0IGl0DQo+IGlzIHRoYXQncyBpbnNpZGUgdGhlIHByb3RlY3RlZCBj b250ZW50LiAgWW91IGNhbiBkbyB0aGlzIGVpdGhlciBieQ0KPiBoYXZpbmcgc29tZXRoaW5nIGlu c2lkZSB0aGUgcHJvdGVjdGVkIGNvbnRlbnQgdGhhdCBzYXlzIHdoYXQgaXQgaXMgKGluDQo+IHdo aWNoIGNhc2UgaXQncyBwcm90ZWN0ZWQpLCBvciBieSBmaXhpbmcgdGhlIHR5cGUgaW4gdGhlIGFw cGxpY2F0aW9uDQo+IHNwZWNpZmljYXRpb24gKGFuZCB2ZXJpZnlpbmcgdGhpcyBvbiByZWNlaXB0 KS4NCj4gDQo+IFMvTUlNRSBmb2xsb3dzIHRoZSBmaXJzdCBwYXR0ZXJuLCBieSBoYXZpbmcgYW4g aW5uZXIgQ29udGVudC1UeXBlIHRoYXQNCj4gdGVsbHMgeW91IHdoYXQgdGhlIHByb3RlY3RlZCBN SU1FIGVudGl0eSBpcy4gIE1hdHQgTWlsbGVyJ3MgWE1QUCBlMmUNCj4gc2VjdXJpdHkgZHJhZnQg Zm9sbG93cyB0aGUgc2Vjb25kIHBhdHRlcm4sIHJlcXVpcmluZyB0aGUgcHJvdGVjdGVkDQo+IGNv bnRlbnQgdG8gYmUgYW4gWE1QUCA8bWVzc2FnZT4gc3RhbnphLg0KPiA8aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWlsbGVyLXhtcHAtZTJlLTAxPg0KPiANCj4gRm9yIHNvbWV0aGlu ZyBsaWtlIEpXVCwgSSB3b3VsZCB0aGluayB5b3Ugd291bGQganVzdCBkbyB0aGUgbGF0dGVyLCBh bmQNCj4gcmVxdWlyZSB0aGF0IHRoZSBpbm5lciBib2R5IGJlIGEgc2V0IG9mIGNsYWltcywgZm9y bWF0dGVkIGluIEpTT04uDQo+IA0KPiANCj4gPj4+IEFnYWluIG5vdGluZyBwcmVjZWRlbnQ6IElm IHlvdSBsb29rIGF0IFMvTUlNRSwgZm9yIGV4YW1wbGUsIHRoZQ0KPiA+Pj4gQ29udGVudC1UeXBl IG9mIHRoZSBNSU1FIGJvZHkgaXMgaW5zaWRlIG9mIHRoZSBDTVMgRW52ZWxvcGVkRGF0YQ0KPiA+ Pj4gc3RydWN0dXJlLCBzbyB0aGUgcHJlc2VuY2Ugb2YgU2lnbmVkRGF0YSBvbiB0aGUgaW5zaWRl IHdvdWxkIG5vdA0KPiA+Pj4gYmUgb2JzZXJ2YWJsZS4NCj4gPg0KPiA+PiBUcnVlIGFuZCBmYWxz ZSAtIElmIHlvdSBsb29rIGF0IFMvTUlNRSB5b3Ugd291bGQgc2VlIGFuIGlkLWRhdGEsDQo+ID4+ IGhvd2V2ZXIgaWYgeW91IGxvb2sgYXQgQ01TIHlvdSBtaWdodCBzZWUgaWQtU2lnbmVkRGF0YSBh cyB0aGUNCj4gPj4gZW5jYXBzdWxhdGVkIGNvbnRlbnQgdHlwZS4gIEZvciBTL01JTUUgaXQgd291 bGQgYmUgZGF0YSAtIHNpbmNlDQo+ID4+IHRoZSBuZXh0IHdyYXBwaW5nIGxheWVyIGlzIG1pbWUg bm90IFNpZ25lZERhdGEuDQo+ID4NCj4gPiBTbyBkb2VzIGV2ZXJ5IGFwcCB1c2luZyBKT1NFIG5l ZWQgdG8gZGVmaW5lIGEgTUlNRS1saWtlIGVuY2Fwc3VsYXRpb24NCj4gPiBhcm91bmQgaXRzIGNv bnRlbnQgKGxpa2UgUy9NSU1FIGRvZXMpIHRvIHVzZSBKT1NFIHNhZmVseT8NCj4gPiBXaGF0IGFy ZSB0aGUgbmVjZXNzYXJ5IGZlYXR1cmVzIG9mIHRoYXQgZW5jYXBzdWxhdGlvbj8NCj4gDQo+IFNl ZSBhYm92ZS4gIFRoZSBhcHBsaWNhdGlvbiBuZWVkcyB0byBlaXRoZXIgc3BlY2lmeSB0aGUgdHlw ZSBvZiB0aGUNCj4gcHJvdGVjdGVkIGNvbnRlbnQgaW4tYmFuZCAobGlrZSBTL01JTUUpIG9yIGRl ZmluZSBhIGZpeGVkIGNvbnRlbnQgdHlwZQ0KPiAobGlrZSBYTVBQKS4NCg0KDQoiZGVmaW5lIGEg Zml4ZWQgY29udGVudCB0eXBlIiBBTkQgZW5zdXJlIG5vIHZhbHVlIGNhbiBzaW11bHRhbmVvdXNs eSBsb29rIGxpa2UgYSB2YWx1ZSBvZiB0aGF0IGZpeGVkIGNvbnRlbnQgdHlwZSBhbmQgYSBKT1NF IG1lc3NhZ2UuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From Michael.Jones@microsoft.com Fri Jun 29 08:21: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 40C8121F875D for ; Fri, 29 Jun 2012 08:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iZ5pDrTdaB2 for ; Fri, 29 Jun 2012 08:20:56 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30221F86E5 for ; Fri, 29 Jun 2012 08:20:56 -0700 (PDT) Received: from mail144-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 15:19:07 +0000 Received: from mail144-tx2 (localhost [127.0.0.1]) by mail144-tx2-R.bigfish.com (Postfix) with ESMTP id C35ECE045F for ; Fri, 29 Jun 2012 15:19:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah34h) Received-SPF: pass (mail144-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=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail144-tx2 (localhost.localdomain [127.0.0.1]) by mail144-tx2 (MessageSwitch) id 1340983144622414_3618; Fri, 29 Jun 2012 15:19:04 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.237]) by mail144-tx2.bigfish.com (Postfix) with ESMTP id 890FE240044 for ; Fri, 29 Jun 2012 15:19:04 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 15:19:02 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Fri, 29 Jun 2012 15:20:50 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Second compute JWE computation example Thread-Index: Ac1WCsOvMw1U5OWeRpC0zgJyTb2gbw== Date: Fri, 29 Jun 2012 15:20:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Second compute JWE computation example 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, 29 Jun 2012 15:21:05 -0000 --_004_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear working group members, A second complete JWE computation example is included below. As I'd previo= usly written, I'm adding example encryption computations to the JWE spec to= aid implementers. These values have been verified by two independent impl= ementations. This example uses the header values: {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} This example verifies both the use of RSA-OAEP and the use of AES-GCM - inc= luding the use of the Additional Authenticated Data parameter and the Authe= ntication Tag output. Note that because the RSA-OAEP computation uses random values, the encrypte= d key computation will not be repeatable, although all resulting values wil= l be decryptable to retrieve the original key value. I'd be interested in hearing results from any of you who also try this JWE = with your implementation. Enjoy, -- Mike CMK (CEK) [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246= , 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} Header Bytes [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80, 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, 34, 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, 85, 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM2I= ifQ BEGIN RSA KEY PARAMETERS Exponent [1, 0, 1] Modulus [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30, 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193, 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78, 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35, 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201, 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231, 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196, 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 233, 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160, 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, 89, 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46, 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, 17, 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, 20, 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, 71, 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190, 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219, 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191, 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, 104, 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, 202, 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39, 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42, 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, 1, 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, 95, 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72, 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, 202, 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85, 195, 122, 241, 79, 251, 229, 183, 117= , 21, 123, 133, 142, 220, 153, 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, 69, 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The remaining RSA key parameters are included for completeness, but should = not be needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, 109, 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, 34, 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, 74, 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, 69, 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, 252, 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, 110, 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, 24, 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, 144, 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, 173, 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, 161, 13, 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, 135, 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, 86, 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, 13, 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209, 200, 252, 170, 172= , 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37, 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, 250, 143, 153, 217, 126, 109, 188= , 188, 126, 76, 39, 164, 127, 186, 49, 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, 134, 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, 39, 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255= , 46, 173, 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201, 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, 80, 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, 0, 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20, 184, 171, 231= , 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115, 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180, 163, 127, 130, 255, 20, 214= ] P [214, 190, 118, 94, 78, 58, 115, 226, 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44, 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74, 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178, 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, 32, 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151, 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91, 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, 183, 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, 229, 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 27, 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, 160, 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177, 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, 162, 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 222, 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54, 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58, 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key [142, 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, 46, 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, 209, 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, 135, 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117, 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, 46, 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236, 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, 208, 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, 39, 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, 77, 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, 95, 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 142, 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, 113, 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 164, 15, 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, 102, 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 211, 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 249, 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 17] Encoded Encrypted Key jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9ouRoO5= jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PKrIvU5ml= 1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6dbHV6I642= FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPh= IpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ Additional Authenticated Data eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM2I= ifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9ou= RoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PKrIv= U5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6dbHV6= I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22= YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ Additional Authenticated Data Bytes [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74, 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85, 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81, 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53, 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75, 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69, 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51, 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100, 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72, 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54, 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74, 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89, 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122, 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106, 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, 119, 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, 57, 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, 72, 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, 102, 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, 51, 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, 97, 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, 99, 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, 80, 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, 113, 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, 85, 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext [253, 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 246, 11= 6, 195, 212, 102, 37, 36, 175] Encoded Ciphertext _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity Value) [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, 114, 139] Encoded Authentication Tag (Encoded Integrity Value) YbZSeHCNDZBqAdzpROlyiw JWE eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM2I= ifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9ou= RoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PKrIv= U5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6dbHV6= I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22= YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUk= rw.YbZSeHCNDZBqAdzpROlyiw --_000_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear working group members,

 

A second complete JWE computation example is include= d below.  As I’d previously written, I’m adding example en= cryption computations to the JWE spec to aid implementers.  These valu= es have been verified by two independent implementations.

 

This example uses the header values:

    {"alg":"RSA-OAEP&q= uot;,"enc":"A256GCM","iv":"48V1_ALb6US04= U3b"}

 

This example verifies both the use of RSA-OAEP and t= he use of AES-GCM – including the use of the Additional Authenticated= Data parameter and the Authentication Tag output.

 

Note that because the RSA-OAEP computation uses rand= om values, the encrypted key computation will not be repeatable, although a= ll resulting values will be decryptable to retrieve the original key value.=

 

I’d be interested in hearing results from any = of you who also try this JWE with your implementation.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Enjoy,

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

 

CMK (CEK)

[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, = 255, 107, 154, 212, 246,

138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46,= 122, 234, 64, 252]

IV

[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, = 219]

Plaintext

[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, = 110, 100, 32, 112, 114,

111, 115, 112, 101, 114, 46]

Header

{"alg":"RSA-OAEP","enc"= ;:"A256GCM","iv":"48V1_ALb6US04U3b"}

Header Bytes

[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, = 79, 65, 69, 80,

34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54= , 71, 67, 77,

34, 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95= , 65, 76, 98,

54, 85, 83, 48, 52, 85, 51, 98, 34, 125]<= /p>

Encoded Header

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6= IjQ4VjFfQUxiNlVTMDRVM2IifQ

BEGIN RSA KEY PARAMETERS

Exponent

[1, 0, 1]

Modulus

[161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163,= 110, 57, 30, 135, 227,

9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227,= 193, 62, 5, 91,

241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81,= 103, 9, 161, 153, 157,

179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78, 93,= 140, 131, 87, 182,

169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35, 79, 2= 10, 222, 192, 208,

252, 49, 109, 138, 173, 253, 210, 166, 201, 63, 102,= 74, 5, 158, 41, 90,

144, 108, 160, 79, 10, 89, 222, 231, 172, 31, 227, 1= 97, 0, 19, 72, 81,

138, 78, 136, 221, 121, 118, 196, 17, 146, 10, 244, = 188, 72, 113, 55, 221,

162, 217, 171, 27, 57, 233, 210, 101, 236, 154, 199,= 56, 138, 239, 101, 48,

198, 186, 202, 160, 76, 111, 234, 71, 57, 183, 5, 21= 1, 171, 136, 126, 64,

40, 75, 58, 89, 244, 254, 107, 84, 103, 7, 236, 69, = 163, 18, 180, 251,

58, 153, 46, 151, 174, 12, 103, 197, 181, 161, 162, = 55, 250, 235, 123, 110,

17, 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130= , 246, 73, 195, 20,

108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, = 200, 61, 201, 71, 243,

1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 11= 8, 27, 197, 235, 232,

36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 1= 90, 253, 186, 186, 27]

D (private key exponent)

[144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, 6= 6, 73, 54, 16, 181,

233, 92, 54, 219, 101, 42, 35, 178, 63, 51, 43, 92, = 119, 136, 251, 41,

53, 23, 191, 164, 164, 60, 88, 227, 229, 152, 228, 2= 13, 149, 228, 169, 237,

104, 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97= , 88, 193, 215, 202,

248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61,= 129, 95, 39, 244, 122,

225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219,= 42, 86, 223, 32, 236,

39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, 1, = 42, 177, 24, 99,

142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, 95,= 187, 134, 71, 88,

96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72, 44= , 245, 95, 39, 194,

179, 175, 203, 122, 16, 112, 183, 17, 200, 202, 31, = 17, 138, 156, 184, 210,

157, 184, 154, 131, 128, 110, 12, 85, 195, 122, 241,= 79, 251, 229, 183, 117,

21, 123, 133, 142, 220, 153, 9, 59, 57, 105, 81, 255= , 138, 77, 82, 54,

62, 216, 38, 249, 208, 17, 197, 49, 45, 19, 232, 157= , 251, 131, 137, 175,

72, 126, 43, 229, 69, 179, 117, 82, 157, 213, 83, 35= , 57, 210, 197, 252,

171, 143, 194, 11, 47, 163, 6, 253, 75, 252, 96, 11,= 187, 84, 130, 210,

7, 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, 224,= 173, 56, 224, 201]

The remaining RSA key parameters are included for co= mpleteness, but should not be needed

DP

[100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29,= 109, 71, 188, 60, 88,

123, 104, 148, 60, 119, 49, 159, 206, 78, 140, 34, 2= 2, 248, 31, 121, 13,

210, 138, 183, 172, 94, 57, 189, 129, 158, 74, 46, 1= 9, 23, 190, 143, 174,

207, 226, 148, 37, 96, 241, 75, 154, 69, 67, 243, 52= , 122, 247, 104, 213,

210, 162, 69, 56, 213, 195, 252, 120, 55, 42, 178, 9= 2, 243, 57, 157, 66,

207, 145, 202, 84, 243, 110, 235, 158, 150, 115, 0, = 146, 169, 118, 21, 128,

130, 170, 215, 24, 160, 4, 9, 1, 244, 94, 222, 45, 1= 07, 57, 227, 157,

223, 243, 86, 144, 38, 101, 154, 186, 209, 99, 204, = 4, 199, 202, 114, 225]

DQ

[14, 173, 32, 126, 2, 117, 13, 209, 70, 94, 34, 239,= 64, 70, 103, 184,

161, 13, 209, 69, 38, 176, 144, 113, 146, 60, 157, 1= 15, 120, 248, 101, 135,

65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143,= 44, 28, 50, 86, 24,

131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 3= 5, 168, 13, 197, 122,

34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, = 209, 200, 252, 170, 172,

133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37, 87, = 132, 72, 232, 201,

13, 147, 216, 29, 209, 216, 242, 253, 91, 250, 143, = 153, 217, 126, 109, 188,

188, 126, 76, 39, 164, 127, 186, 49, 201, 226, 131, = 82, 162, 150, 142, 43]

InverseQ

[84, 131, 41, 49, 134, 207, 127, 142, 221, 79, 92, 6= 3, 204, 53, 23, 124,

248, 166, 177, 39, 160, 156, 195, 128, 215, 52, 218,= 95, 182, 134, 147, 255,

46, 173, 142, 145, 243, 230, 86, 212, 92, 84, 236, 9= , 86, 3, 34, 214,

201, 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 1= 16, 203, 167, 229, 80,

174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 1= 77, 113, 142, 0, 235,

252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181,= 153, 20, 184, 171, 231,

62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115= , 199, 40, 243, 244,

145, 127, 95, 38, 152, 215, 134, 171, 116, 180, 163,= 127, 130, 255, 20, 214]

P

[214, 190, 118, 94, 78, 58, 115, 226, 236, 124, 30, = 79, 227, 141, 169, 237,

171, 93, 61, 74, 241, 65, 44, 184, 154, 216, 191, 18= 1, 146, 55, 50, 7,

246, 18, 225, 85, 109, 74, 3, 6, 246, 145, 67, 228, = 150, 198, 70, 228,

154, 129, 51, 47, 178, 87, 174, 132, 129, 141, 42, 2= 02, 221, 130, 16, 129,

135, 76, 131, 32, 4, 61, 51, 227, 94, 255, 225, 35, = 111, 245, 121, 52,

143, 85, 151, 243, 47, 73, 95, 124, 217, 244, 220, 1= 33, 234, 88, 94, 76,

12, 91, 168, 81, 129, 52, 135, 54, 246, 190, 26, 229= , 55, 250, 202, 173,

183, 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111= , 0, 186, 10, 93]

Q

[192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, = 102, 7, 251, 229, 123,

206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 1= 39, 25, 27, 134,

178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, = 3, 117, 160, 216,

85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, = 26, 177, 167, 13,

236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 1= 40, 162, 53, 162, 102,

180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 2= 22, 32, 191, 17, 72,

152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54, = 69, 171, 84, 6,

121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58, 24= 1, 70, 71, 190, 215]

END RSA KEY PARAMETERS

Encrypted Key

[142, 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 4= 9, 95, 169, 220, 2,

46, 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 22= 3, 154, 95, 71, 209,

233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 1= 25, 22, 221, 135, 17,

67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171,= 95, 117, 202, 87, 251,

101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, = 46, 49, 198, 27, 31,

58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236, 65= , 143, 38, 43, 218,

195, 76, 140, 243, 71, 243, 79, 124, 216, 208, 242, = 171, 34, 245, 57, 154,

93, 76, 230, 204, 234, 82, 117, 248, 39, 13, 62, 60,= 215, 8, 51, 248,

254, 47, 150, 36, 46, 27, 247, 98, 77, 56, 92, 44, 1= 9, 39, 12, 77,

54, 101, 194, 126, 86, 0, 64, 239, 95, 211, 64, 26, = 219, 93, 211, 36,

154, 250, 117, 177, 213, 232, 142, 184, 216, 92, 20,= 248, 69, 175, 180, 71,

205, 221, 235, 224, 95, 113, 5, 33, 86, 18, 157, 61,= 199, 8, 121, 0,

0, 135, 65, 67, 220, 164, 15, 230, 155, 71, 53, 64, = 253, 209, 169, 255,

34, 64, 101, 7, 43, 102, 227, 83, 171, 52, 225, 119,= 253, 182, 96, 195,

225, 34, 156, 211, 202, 7, 194, 255, 137, 59, 170, 1= 72, 72, 234, 222, 203,

123, 249, 121, 254, 143, 173, 105, 65, 187, 189, 163= , 64, 151, 145, 99, 17]

Encoded Encrypted Key

jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iE= pxEqM30W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiv= aw0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO= 9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_= yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ

Additional Authenticated Data

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6= IjQ4VjFfQUxiNlVTMDRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6O= y-iEpxEqM30W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EG= PJivaw0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCfl= YAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_= dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ<= /o:p>

Additional Authenticated Data Bytes

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83= , 85, 48, 69, 116,

84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 8= 9, 121, 73, 54,

73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 7= 6, 67, 74, 112,

100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102,= 81, 85, 120, 105,

78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 10= 2, 81, 46, 106,

118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 6= 6, 53, 99, 120, 88,

54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 7= 5, 82, 116, 108,

109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69,= 97, 54, 79, 121,

45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51, = 89, 99, 82, 81,

56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100,= 54, 116, 102, 100,

99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72, 119, = 52, 100, 110, 77,

88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54, 76, 7= 7, 68, 101, 70,

82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74, 105= , 118, 97, 119,

48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89, 48, = 80, 75, 114, 73,

118, 85, 53, 109, 108, 49, 77, 53, 115, 122, 113, 85= , 110, 88, 52, 74,

119, 48, 45, 80, 78, 99, 73, 77, 95, 106, 45, 76, 53= , 89, 107, 76,

104, 118, 51, 89, 107, 48, 52, 88, 67, 119, 84, 74, = 119, 120, 78, 78,

109, 88, 67, 102, 108, 89, 65, 81, 79, 57, 102, 48, = 48, 65, 97, 50,

49, 51, 84, 74, 74, 114, 54, 100, 98, 72, 86, 54, 73= , 54, 52, 50,

70, 119, 85, 45, 69, 87, 118, 116, 69, 102, 78, 51, = 101, 118, 103, 88,

51, 69, 70, 73, 86, 89, 83, 110, 84, 51, 72, 67, 72,= 107, 65, 65,

73, 100, 66, 81, 57, 121, 107, 68, 45, 97, 98, 82, 1= 22, 86, 65, 95,

100, 71, 112, 95, 121, 74, 65, 90, 81, 99, 114, 90, = 117, 78, 84, 113,

122, 84, 104, 100, 95, 50, 50, 89, 77, 80, 104, 73, = 112, 122, 84, 121,

103, 102, 67, 95, 52, 107, 55, 113, 113, 120, 73, 54= , 116, 55, 76, 101,

95, 108, 53, 95, 111, 45, 116, 97, 85, 71, 55, 118, = 97, 78, 65, 108,

53, 70, 106, 69, 81]

Ciphertext

[253, 237, 181, 180, 97, 161, 105, 207, 233, 120, 65= , 100, 45, 122, 246, 116,

195, 212, 102, 37, 36, 175]

Encoded Ciphertext

_e21tGGhac_peEFkLXr2dMPUZiUkrw

Authentication Tag (Integrity Value)

[97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 2= 33, 68, 233, 114, 139]

Encoded Authentication Tag (Encoded Integrity Value)=

YbZSeHCNDZBqAdzpROlyiw

JWE

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6= IjQ4VjFfQUxiNlVTMDRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6O= y-iEpxEqM30W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EG= PJivaw0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCfl= YAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_= dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ._e21t= GGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw

 

--_000_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_ Content-Type: application/octet-stream; name="JWE2.log" Content-Description: JWE2.log Content-Disposition: attachment; filename="JWE2.log"; size=11194; creation-date="Tue, 26 Jun 2012 23:40:25 GMT"; modification-date="Fri, 29 Jun 2012 04:43:31 GMT" Content-Transfer-Encoding: base64 Q01LIChDRUspDQpbMTc3LCAxNjEsIDI0NCwgMTI4LCA4NCwgMTQzLCAyMjUsIDExNSwgNjMsIDE4 MCwgMywgMjU1LCAxMDcsIDE1NCwgMjEyLCAyNDYsDQogMTM4LCA3LCAxMTAsIDkxLCAxMTIsIDQ2 LCAzNCwgMTA1LCA0NywgMTMwLCAyMDMsIDQ2LCAxMjIsIDIzNCwgNjQsIDI1Ml0NCklWDQpbMjI3 LCAxOTcsIDExNywgMjUyLCAyLCAyMTksIDIzMywgNjgsIDE4MCwgMjI1LCA3NywgMjE5XQ0KUGxh aW50ZXh0DQpbNzYsIDEwNSwgMTE4LCAxMDEsIDMyLCAxMDgsIDExMSwgMTEwLCAxMDMsIDMyLCA5 NywgMTEwLCAxMDAsIDMyLCAxMTIsIDExNCwNCiAxMTEsIDExNSwgMTEyLCAxMDEsIDExNCwgNDZd DQpIZWFkZXINCnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIiwiaXYiOiI0OFYxX0FM YjZVUzA0VTNiIn0NCkhlYWRlciBCeXRlcw0KWzEyMywgMzQsIDk3LCAxMDgsIDEwMywgMzQsIDU4 LCAzNCwgODIsIDgzLCA2NSwgNDUsIDc5LCA2NSwgNjksIDgwLA0KIDM0LCA0NCwgMzQsIDEwMSwg MTEwLCA5OSwgMzQsIDU4LCAzNCwgNjUsIDUwLCA1MywgNTQsIDcxLCA2NywgNzcsDQogMzQsIDQ0 LCAzNCwgMTA1LCAxMTgsIDM0LCA1OCwgMzQsIDUyLCA1NiwgODYsIDQ5LCA5NSwgNjUsIDc2LCA5 OCwNCiA1NCwgODUsIDgzLCA0OCwgNTIsIDg1LCA1MSwgOTgsIDM0LCAxMjVdDQpFbmNvZGVkIEhl YWRlcg0KZXlKaGJHY2lPaUpTVTBFdFQwRkZVQ0lzSW1WdVl5STZJa0V5TlRaSFEwMGlMQ0pwZGlJ NklqUTRWakZmUVV4aU5sVlRNRFJWTTJJaWZRDQpCRUdJTiBSU0EgS0VZIFBBUkFNRVRFUlMNCkV4 cG9uZW50DQpbMSwgMCwgMV0NCk1vZHVsdXMNClsxNjEsIDE2OCwgODQsIDM0LCAxMzMsIDE3Niwg MjA4LCAxNzMsIDQ2LCAxNzYsIDE2MywgMTEwLCA1NywgMzAsIDEzNSwgMjI3LA0KIDksIDMxLCAy MjYsIDEyOCwgODQsIDkyLCAxMTYsIDI0MSwgNzAsIDI0OCwgMjcsIDIyNywgMTkzLCA2MiwgNSwg OTEsDQogMjQxLCAxNDUsIDIyNCwgMjA1LCAxNDEsIDE3NiwgMTg0LCAxMzMsIDIzOSwgNDMsIDgx LCAxMDMsIDksIDE2MSwgMTUzLCAxNTcsDQogMTc5LCAxMDQsIDEyMywgNTEsIDE4OSwgMzQsIDE1 MiwgNjksIDk3LCA2OSwgNzgsIDkzLCAxNDAsIDEzMSwgODcsIDE4MiwNCiAxNjksIDEwMSwgOTIs IDE0MiwgMywgMjIsIDE2NywgOCwgMjEyLCA1NiwgMzUsIDc5LCAyMTAsIDIyMiwgMTkyLCAyMDgs DQogMjUyLCA0OSwgMTA5LCAxMzgsIDE3MywgMjUzLCAyMTAsIDE2NiwgMjAxLCA2MywgMTAyLCA3 NCwgNSwgMTU4LCA0MSwgOTAsDQogMTQ0LCAxMDgsIDE2MCwgNzksIDEwLCA4OSwgMjIyLCAyMzEs IDE3MiwgMzEsIDIyNywgMTk3LCAwLCAxOSwgNzIsIDgxLA0KIDEzOCwgNzgsIDEzNiwgMjIxLCAx MjEsIDExOCwgMTk2LCAxNywgMTQ2LCAxMCwgMjQ0LCAxODgsIDcyLCAxMTMsIDU1LCAyMjEsDQog MTYyLCAyMTcsIDE3MSwgMjcsIDU3LCAyMzMsIDIxMCwgMTAxLCAyMzYsIDE1NCwgMTk5LCA1Niwg MTM4LCAyMzksIDEwMSwgNDgsDQogMTk4LCAxODYsIDIwMiwgMTYwLCA3NiwgMTExLCAyMzQsIDcx LCA1NywgMTgzLCA1LCAyMTEsIDE3MSwgMTM2LCAxMjYsIDY0LA0KIDQwLCA3NSwgNTgsIDg5LCAy NDQsIDI1NCwgMTA3LCA4NCwgMTAzLCA3LCAyMzYsIDY5LCAxNjMsIDE4LCAxODAsIDI1MSwNCiA1 OCwgMTUzLCA0NiwgMTUxLCAxNzQsIDEyLCAxMDMsIDE5NywgMTgxLCAxNjEsIDE2MiwgNTUsIDI1 MCwgMjM1LCAxMjMsIDExMCwNCiAxNywgMTEsIDE1OCwgMjQsIDQ3LCAxMzMsIDgsIDE5OSwgMjM1 LCAxMDcsIDEyNiwgMTMwLCAyNDYsIDczLCAxOTUsIDIwLA0KIDEwOCwgMjAyLCAxNzYsIDIxNCwg MTg3LCA0NSwgMTQ2LCAxODIsIDExOCwgNTQsIDMyLCAyMDAsIDYxLCAyMDEsIDcxLCAyNDMsDQog MSwgMjU1LCAxMzEsIDg0LCAzNywgMTExLCAyMTEsIDE2OCwgMjI4LCA0NSwgMTkyLCAxMTgsIDI3 LCAxOTcsIDIzNSwgMjMyLA0KIDM2LCAxMCwgMjMwLCAyNDgsIDE5MCwgODIsIDE4MiwgMTQwLCAz NSwgMjA0LCAxMDgsIDE5MCwgMjUzLCAxODYsIDE4NiwgMjddDQpEIChwcml2YXRlIGtleSBleHBv bmVudCkNClsxNDQsIDE4MywgMTA5LCAzNCwgNjIsIDEzNCwgMTA4LCA1NywgNDQsIDI1MiwgMTAs IDY2LCA3MywgNTQsIDE2LCAxODEsDQogMjMzLCA5MiwgNTQsIDIxOSwgMTAxLCA0MiwgMzUsIDE3 OCwgNjMsIDUxLCA0MywgOTIsIDExOSwgMTM2LCAyNTEsIDQxLA0KIDUzLCAyMywgMTkxLCAxNjQs IDE2NCwgNjAsIDg4LCAyMjcsIDIyOSwgMTUyLCAyMjgsIDIxMywgMTQ5LCAyMjgsIDE2OSwgMjM3 LA0KIDEwNCwgNzEsIDE1MSwgNzUsIDg4LCAyNTIsIDIxNiwgNzcsIDI1MSwgMjMxLCAyOCwgOTcs IDg4LCAxOTMsIDIxNSwgMjAyLA0KIDI0OCwgMjE2LCAxMjEsIDE5NSwgMjExLCAyNDUsIDI1MCwg MTEyLCA3MSwgMjQzLCA2MSwgMTI5LCA5NSwgMzksIDI0NCwgMTIyLA0KIDIyNSwgMjE3LCAxNjks IDIxMSwgMTY1LCA0OCwgMjUzLCAyMjAsIDU5LCAxMjIsIDIxOSwgNDIsIDg2LCAyMjMsIDMyLCAy MzYsDQogMzksIDQ4LCAxMDMsIDc4LCAxMjIsIDIxNiwgMTg3LCA4OCwgMTc2LCA4OSwgMjQsIDEs IDQyLCAxNzcsIDI0LCA5OSwNCiAxNDIsIDE3MCwgMSwgMTQ2LCA0MywgMywgMTA4LCA2NCwgMTk0 LCAxMjEsIDE4MiwgOTUsIDE4NywgMTM0LCA3MSwgODgsDQogOTYsIDEzNCwgNzQsIDEzMSwgMTY3 LCA2OSwgMTA2LCAxNDMsIDEyMSwgMjcsIDcyLCA0NCwgMjQ1LCA5NSwgMzksIDE5NCwNCiAxNzks IDE3NSwgMjAzLCAxMjIsIDE2LCAxMTIsIDE4MywgMTcsIDIwMCwgMjAyLCAzMSwgMTcsIDEzOCwg MTU2LCAxODQsIDIxMCwNCiAxNTcsIDE4NCwgMTU0LCAxMzEsIDEyOCwgMTEwLCAxMiwgODUsIDE5 NSwgMTIyLCAyNDEsIDc5LCAyNTEsIDIyOSwgMTgzLCAxMTcsDQogMjEsIDEyMywgMTMzLCAxNDIs IDIyMCwgMTUzLCA5LCA1OSwgNTcsIDEwNSwgODEsIDI1NSwgMTM4LCA3NywgODIsIDU0LA0KIDYy LCAyMTYsIDM4LCAyNDksIDIwOCwgMTcsIDE5NywgNDksIDQ1LCAxOSwgMjMyLCAxNTcsIDI1MSwg MTMxLCAxMzcsIDE3NSwNCiA3MiwgMTI2LCA0MywgMjI5LCA2OSwgMTc5LCAxMTcsIDgyLCAxNTcs IDIxMywgODMsIDM1LCA1NywgMjEwLCAxOTcsIDI1MiwNCiAxNzEsIDE0MywgMTk0LCAxMSwgNDcs IDE2MywgNiwgMjUzLCA3NSwgMjUyLCA5NiwgMTEsIDE4NywgODQsIDEzMCwgMjEwLA0KIDcsIDEy MSwgNzgsIDkxLCA3OSwgNTcsIDI1MSwgMTM4LCAxMzIsIDIyMCwgNjAsIDIyNCwgMTczLCA1Niwg MjI0LCAyMDFdDQpUaGUgcmVtYWluaW5nIFJTQSBrZXkgcGFyYW1ldGVycyBhcmUgaW5jbHVkZWQg Zm9yIGNvbXBsZXRlbmVzcywgYnV0IHNob3VsZCBub3QgYmUgbmVlZGVkDQpEUA0KWzEwMCwgMTc1 LCAxNTIsIDE5MiwgNzgsIDIyMSwgMTM3LCA3MiwgMTE2LCAxNjksIDI5LCAxMDksIDcxLCAxODgs IDYwLCA4OCwNCiAxMjMsIDEwNCwgMTQ4LCA2MCwgMTE5LCA0OSwgMTU5LCAyMDYsIDc4LCAxNDAs IDM0LCAyMiwgMjQ4LCAzMSwgMTIxLCAxMywNCiAyMTAsIDEzOCwgMTgzLCAxNzIsIDk0LCA1Nywg MTg5LCAxMjksIDE1OCwgNzQsIDQ2LCAxOSwgMjMsIDE5MCwgMTQzLCAxNzQsDQogMjA3LCAyMjYs IDE0OCwgMzcsIDk2LCAyNDEsIDc1LCAxNTQsIDY5LCA2NywgMjQzLCA1MiwgMTIyLCAyNDcsIDEw NCwgMjEzLA0KIDIxMCwgMTYyLCA2OSwgNTYsIDIxMywgMTk1LCAyNTIsIDEyMCwgNTUsIDQyLCAx NzgsIDkyLCAyNDMsIDU3LCAxNTcsIDY2LA0KIDIwNywgMTQ1LCAyMDIsIDg0LCAyNDMsIDExMCwg MjM1LCAxNTgsIDE1MCwgMTE1LCAwLCAxNDYsIDE2OSwgMTE4LCAyMSwgMTI4LA0KIDEzMCwgMTcw LCAyMTUsIDI0LCAxNjAsIDQsIDksIDEsIDI0NCwgOTQsIDIyMiwgNDUsIDEwNywgNTcsIDIyNywg MTU3LA0KIDIyMywgMjQzLCA4NiwgMTQ0LCAzOCwgMTAxLCAxNTQsIDE4NiwgMjA5LCA5OSwgMjA0 LCA0LCAxOTksIDIwMiwgMTE0LCAyMjVdDQpEUQ0KWzE0LCAxNzMsIDMyLCAxMjYsIDIsIDExNywg MTMsIDIwOSwgNzAsIDk0LCAzNCwgMjM5LCA2NCwgNzAsIDEwMywgMTg0LA0KIDE2MSwgMTMsIDIw OSwgNjksIDM4LCAxNzYsIDE0NCwgMTEzLCAxNDYsIDYwLCAxNTcsIDExNSwgMTIwLCAyNDgsIDEw MSwgMTM1LA0KIDY1LCAxMzYsIDE5NiwgNjQsIDIwMywgMjA2LCAxNzcsIDIxMCwgMjQxLCAxOTQs IDE0MywgNDQsIDI4LCA1MCwgODYsIDI0LA0KIDEzMSwgMTQwLCAxNjgsIDExLCAxMzQsIDI1LCAx MDcsIDIxNiwgNzcsIDg1LCAyMDMsIDM1LCAxNjgsIDEzLCAxOTcsIDEyMiwNCiAzNCwgMjQ1LCAy NDYsIDE4NSwgNjAsIDEzMSwgMTY0LCAzOSwgMjE5LCAyMTIsIDIzNywgMjA5LCAyMDAsIDI1Miwg MTcwLCAxNzIsDQogMTMzLCAxNjcsIDYzLCAxMTEsIDUyLCA0OCwgODQsIDEyNCwgMzIsIDM0LCAz NywgODcsIDEzMiwgNzIsIDIzMiwgMjAxLA0KIDEzLCAxNDcsIDIxNiwgMjksIDIwOSwgMjE2LCAy NDIsIDI1MywgOTEsIDI1MCwgMTQzLCAxNTMsIDIxNywgMTI2LCAxMDksIDE4OCwNCiAxODgsIDEy NiwgNzYsIDM5LCAxNjQsIDEyNywgMTg2LCA0OSwgMjAxLCAyMjYsIDEzMSwgODIsIDE2MiwgMTUw LCAxNDIsIDQzXQ0KSW52ZXJzZVENCls4NCwgMTMxLCA0MSwgNDksIDEzNCwgMjA3LCAxMjcsIDE0 MiwgMjIxLCA3OSwgOTIsIDYzLCAyMDQsIDUzLCAyMywgMTI0LA0KIDI0OCwgMTY2LCAxNzcsIDM5 LCAxNjAsIDE1NiwgMTk1LCAxMjgsIDIxNSwgNTIsIDIxOCwgOTUsIDE4MiwgMTM0LCAxNDcsIDI1 NSwNCiA0NiwgMTczLCAxNDIsIDE0NSwgMjQzLCAyMzAsIDg2LCAyMTIsIDkyLCA4NCwgMjM2LCA5 LCA4NiwgMywgMzQsIDIxNCwNCiAyMDEsIDE4NiwgMTcwLCAyMzQsIDIyMSwgMTIyLCA4NCwgODcs IDEyMywgMTMzLCA3LCAxMTYsIDIwMywgMTY3LCAyMjksIDgwLA0KIDE3NCwgMTgsIDE0OCwgMjM2 LCAxNTcsIDcsIDE3MywgOTYsIDE5MywgMTY5LCAyMDYsIDE3NywgMTEzLCAxNDIsIDAsIDIzNSwN CiAyNTIsIDIxNywgMTkzLCAyMzQsIDIwOCwgNzcsIDIyMiwgNDcsIDEyOSwgMjM1LCAxODEsIDE1 MywgMjAsIDE4NCwgMTcxLCAyMzEsDQogNjIsIDE3OSwgMzksIDE3NywgNjksIDUsIDE0OSwgMjQ1 LCAyOSwgMjAxLCAxODEsIDExNSwgMTk5LCA0MCwgMjQzLCAyNDQsDQogMTQ1LCAxMjcsIDk1LCAz OCwgMTUyLCAyMTUsIDEzNCwgMTcxLCAxMTYsIDE4MCwgMTYzLCAxMjcsIDEzMCwgMjU1LCAyMCwg MjE0XQ0KUA0KWzIxNCwgMTkwLCAxMTgsIDk0LCA3OCwgNTgsIDExNSwgMjI2LCAyMzYsIDEyNCwg MzAsIDc5LCAyMjcsIDE0MSwgMTY5LCAyMzcsDQogMTcxLCA5MywgNjEsIDc0LCAyNDEsIDY1LCA0 NCwgMTg0LCAxNTQsIDIxNiwgMTkxLCAxODEsIDE0NiwgNTUsIDUwLCA3LA0KIDI0NiwgMTgsIDIy NSwgODUsIDEwOSwgNzQsIDMsIDYsIDI0NiwgMTQ1LCA2NywgMjI4LCAxNTAsIDE5OCwgNzAsIDIy OCwNCiAxNTQsIDEyOSwgNTEsIDQ3LCAxNzgsIDg3LCAxNzQsIDEzMiwgMTI5LCAxNDEsIDQyLCAy MDIsIDIyMSwgMTMwLCAxNiwgMTI5LA0KIDEzNSwgNzYsIDEzMSwgMzIsIDQsIDYxLCA1MSwgMjI3 LCA5NCwgMjU1LCAyMjUsIDM1LCAxMTEsIDI0NSwgMTIxLCA1MiwNCiAxNDMsIDg1LCAxNTEsIDI0 MywgNDcsIDczLCA5NSwgMTI0LCAyMTcsIDI0NCwgMjIwLCAxMzMsIDIzNCwgODgsIDk0LCA3NiwN CiAxMiwgOTEsIDE2OCwgODEsIDEyOSwgNTIsIDEzNSwgNTQsIDI0NiwgMTkwLCAyNiwgMjI5LCA1 NSwgMjUwLCAyMDIsIDE3MywNCiAxODMsIDE5NSwgMzUsIDUsIDI3LCA3OCwgMTg0LCAyMjcsIDEz MCwgMzksIDE0NSwgMTExLCAwLCAxODYsIDEwLCA5M10NClENClsxOTIsIDE4MiwgMjQ3LCAyMzEs IDMwLCAyMjUsIDE1MywgNSwgMTUzLCAxNzcsIDk4LCAxMDIsIDcsIDI1MSwgMjI5LCAxMjMsDQog MjA2LCAyMjYsIDEzNCwgNiwgMTE3LCAyNDUsIDQ3LCAzNywgNCwgNjgsIDc4LCA0NCwgMTM5LCAy NSwgMjcsIDEzNCwNCiAxNzgsIDEwMSwgODcsIDE4OSwgMzAsIDQ3LCA5NiwgMTMsIDgwLCAxNDIs IDYsIDEwMSwgMywgMTE3LCAxNjAsIDIxNiwNCiA4NSwgNTIsIDE0MSwgMTk5LCAyNTUsIDUsIDIw MywgMTMsIDg4LCA5NywgMTc1LCA4NywgMjYsIDE3NywgMTY3LCAxMywNCiAyMzYsIDUyLCAyMDgs IDE1NywgMTg4LCAxMTMsIDIxLCA0MCwgMTIwLCAxNiwgMTI3LCAxNDAsIDE2MiwgNTMsIDE2Miwg MTAyLA0KIDE4MCwgNTgsIDE4NywgMjQ1LCA3OSwgMjE0LCAxNTEsIDMzLCAxMDgsIDc0LCAxOTMs IDIyMiwgMzIsIDE5MSwgMTcsIDcyLA0KIDE1MiwgMjI5LCAxNzEsIDIyMSwgNCwgNzUsIDI0NCwg MTYxLCAxLCA3MSwgNTcsIDU0LCA2OSwgMTcxLCA4NCwgNiwNCiAxMjEsIDEzMSwgMTAwLCAxNDgs IDIwMCwgMSwgMjUyLCAxOSwgMTc5LCA3MiwgNTgsIDI0MSwgNzAsIDcxLCAxOTAsIDIxNV0NCkVO RCBSU0EgS0VZIFBBUkFNRVRFUlMNCkVuY3J5cHRlZCBLZXkNClsxNDIsIDI1MiwgNDAsIDIwMiwg MjEsIDE3NywgNTYsIDE5OCwgMjMyLCA3LCAxNTEsIDQ5LCA5NSwgMTY5LCAyMjAsIDIsDQogNDYs IDIxNCwgMTY3LCAxMTYsIDU3LCAyMCwgMTY0LCAxMDksIDE1MCwgOTgsIDQ5LCAyMjMsIDE1NCwg OTUsIDcxLCAyMDksDQogMjMzLCAxNywgMTc0LCAxNDIsIDIwMywgMjMyLCAxMzIsIDE2NywgMTcs IDQyLCA1MSwgMTI1LCAyMiwgMjIxLCAxMzUsIDE3LA0KIDY3LCAxOTcsIDE0OCwgMjQ2LCAxMzks IDE0NSwgMTYwLCAyMzgsIDk5LCAxMTksIDE3MSwgOTUsIDExNywgMjAyLCA4NywgMjUxLA0KIDEw MSwgMjU0LCA1OCwgMjE1LCAxMzUsIDE5NSwgMTM1LCAxMDMsIDQ5LCAxMTksIDc2LCA0NiwgNDks IDE5OCwgMjcsIDMxLA0KIDU4LCA0NCwgMTkyLCAyMjIsIDIxLCAxNiwgMTMsIDIxNiwgMTYxLCAx NzksIDIzNiwgNjUsIDE0MywgMzgsIDQzLCAyMTgsDQogMTk1LCA3NiwgMTQwLCAyNDMsIDcxLCAy NDMsIDc5LCAxMjQsIDIxNiwgMjA4LCAyNDIsIDE3MSwgMzQsIDI0NSwgNTcsIDE1NCwNCiA5Mywg NzYsIDIzMCwgMjA0LCAyMzQsIDgyLCAxMTcsIDI0OCwgMzksIDEzLCA2MiwgNjAsIDIxNSwgOCwg NTEsIDI0OCwNCiAyNTQsIDQ3LCAxNTAsIDM2LCA0NiwgMjcsIDI0NywgOTgsIDc3LCA1NiwgOTIs IDQ0LCAxOSwgMzksIDEyLCA3NywNCiA1NCwgMTAxLCAxOTQsIDEyNiwgODYsIDAsIDY0LCAyMzks IDk1LCAyMTEsIDY0LCAyNiwgMjE5LCA5MywgMjExLCAzNiwNCiAxNTQsIDI1MCwgMTE3LCAxNzcs IDIxMywgMjMyLCAxNDIsIDE4NCwgMjE2LCA5MiwgMjAsIDI0OCwgNjksIDE3NSwgMTgwLCA3MSwN CiAyMDUsIDIyMSwgMjM1LCAyMjQsIDk1LCAxMTMsIDUsIDMzLCA4NiwgMTgsIDE1NywgNjEsIDE5 OSwgOCwgMTIxLCAwLA0KIDAsIDEzNSwgNjUsIDY3LCAyMjAsIDE2NCwgMTUsIDIzMCwgMTU1LCA3 MSwgNTMsIDY0LCAyNTMsIDIwOSwgMTY5LCAyNTUsDQogMzQsIDY0LCAxMDEsIDcsIDQzLCAxMDIs IDIyNywgODMsIDE3MSwgNTIsIDIyNSwgMTE5LCAyNTMsIDE4MiwgOTYsIDE5NSwNCiAyMjUsIDM0 LCAxNTYsIDIxMSwgMjAyLCA3LCAxOTQsIDI1NSwgMTM3LCA1OSwgMTcwLCAxNzIsIDcyLCAyMzQs IDIyMiwgMjAzLA0KIDEyMywgMjQ5LCAxMjEsIDI1NCwgMTQzLCAxNzMsIDEwNSwgNjUsIDE4Nywg MTg5LCAxNjMsIDY0LCAxNTEsIDE0NSwgOTksIDE3XQ0KRW5jb2RlZCBFbmNyeXB0ZWQgS2V5DQpq dndveWhXeE9NYm9CNWN4WDZuY0FpN1dwM1E1RktSdGxtSXgzNXBmUjlIcEVhNk95LWlFcHhFcU0z MFczWWNSUThXVTlvdVJvTzVqZDZ0ZmRjcFgtMlgtT3RlSHc0ZG5NWGRNTGpIR0d4ODZMTURlRlJB TjJLR3o3RUdQSml2YXcweU04MGZ6VDN6WTBQS3JJdlU1bWwxTTVzenFVblg0SncwLVBOY0lNX2ot TDVZa0xodjNZazA0WEN3VEp3eE5ObVhDZmxZQVFPOWYwMEFhMjEzVEpKcjZkYkhWNkk2NDJGd1Ut RVd2dEVmTjNldmdYM0VGSVZZU25UM0hDSGtBQUlkQlE5eWtELWFiUnpWQV9kR3BfeUpBWlFjclp1 TlRxelRoZF8yMllNUGhJcHpUeWdmQ180azdxcXhJNnQ3TGVfbDVfby10YVVHN3ZhTkFsNUZqRVEN CkFkZGl0aW9uYWwgQXV0aGVudGljYXRlZCBEYXRhDQpleUpoYkdjaU9pSlNVMEV0VDBGRlVDSXNJ bVZ1WXlJNklrRXlOVFpIUTAwaUxDSnBkaUk2SWpRNFZqRmZRVXhpTmxWVE1EUlZNMklpZlEuanZ3 b3loV3hPTWJvQjVjeFg2bmNBaTdXcDNRNUZLUnRsbUl4MzVwZlI5SHBFYTZPeS1pRXB4RXFNMzBX M1ljUlE4V1U5b3VSb081amQ2dGZkY3BYLTJYLU90ZUh3NGRuTVhkTUxqSEdHeDg2TE1EZUZSQU4y S0d6N0VHUEppdmF3MHlNODBmelQzelkwUEtySXZVNW1sMU01c3pxVW5YNEp3MC1QTmNJTV9qLUw1 WWtMaHYzWWswNFhDd1RKd3hOTm1YQ2ZsWUFRTzlmMDBBYTIxM1RKSnI2ZGJIVjZJNjQyRndVLUVX dnRFZk4zZXZnWDNFRklWWVNuVDNIQ0hrQUFJZEJROXlrRC1hYlJ6VkFfZEdwX3lKQVpRY3JadU5U cXpUaGRfMjJZTVBoSXB6VHlnZkNfNGs3cXF4STZ0N0xlX2w1X28tdGFVRzd2YU5BbDVGakVRDQpB ZGRpdGlvbmFsIEF1dGhlbnRpY2F0ZWQgRGF0YSBCeXRlcw0KWzEwMSwgMTIxLCA3NCwgMTA0LCA5 OCwgNzEsIDk5LCAxMDUsIDc5LCAxMDUsIDc0LCA4MywgODUsIDQ4LCA2OSwgMTE2LA0KIDg0LCA0 OCwgNzAsIDcwLCA4NSwgNjcsIDczLCAxMTUsIDczLCAxMDksIDg2LCAxMTcsIDg5LCAxMjEsIDcz LCA1NCwNCiA3MywgMTA3LCA2OSwgMTIxLCA3OCwgODQsIDkwLCA3MiwgODEsIDQ4LCA0OCwgMTA1 LCA3NiwgNjcsIDc0LCAxMTIsDQogMTAwLCAxMDUsIDczLCA1NCwgNzMsIDEwNiwgODEsIDUyLCA4 NiwgMTA2LCA3MCwgMTAyLCA4MSwgODUsIDEyMCwgMTA1LA0KIDc4LCAxMDgsIDg2LCA4NCwgNzcs IDY4LCA4MiwgODYsIDc3LCA1MCwgNzMsIDEwNSwgMTAyLCA4MSwgNDYsIDEwNiwNCiAxMTgsIDEx OSwgMTExLCAxMjEsIDEwNCwgODcsIDEyMCwgNzksIDc3LCA5OCwgMTExLCA2NiwgNTMsIDk5LCAx MjAsIDg4LA0KIDU0LCAxMTAsIDk5LCA2NSwgMTA1LCA1NSwgODcsIDExMiwgNTEsIDgxLCA1Mywg NzAsIDc1LCA4MiwgMTE2LCAxMDgsDQogMTA5LCA3MywgMTIwLCA1MSwgNTMsIDExMiwgMTAyLCA4 MiwgNTcsIDcyLCAxMTIsIDY5LCA5NywgNTQsIDc5LCAxMjEsDQogNDUsIDEwNSwgNjksIDExMiwg MTIwLCA2OSwgMTEzLCA3NywgNTEsIDQ4LCA4NywgNTEsIDg5LCA5OSwgODIsIDgxLA0KIDU2LCA4 NywgODUsIDU3LCAxMTEsIDExNywgODIsIDExMSwgNzksIDUzLCAxMDYsIDEwMCwgNTQsIDExNiwg MTAyLCAxMDAsDQogOTksIDExMiwgODgsIDQ1LCA1MCwgODgsIDQ1LCA3OSwgMTE2LCAxMDEsIDcy LCAxMTksIDUyLCAxMDAsIDExMCwgNzcsDQogODgsIDEwMCwgNzcsIDc2LCAxMDYsIDcyLCA3MSwg NzEsIDEyMCwgNTYsIDU0LCA3NiwgNzcsIDY4LCAxMDEsIDcwLA0KIDgyLCA2NSwgNzgsIDUwLCA3 NSwgNzEsIDEyMiwgNTUsIDY5LCA3MSwgODAsIDc0LCAxMDUsIDExOCwgOTcsIDExOSwNCiA0OCwg MTIxLCA3NywgNTYsIDQ4LCAxMDIsIDEyMiwgODQsIDUxLCAxMjIsIDg5LCA0OCwgODAsIDc1LCAx MTQsIDczLA0KIDExOCwgODUsIDUzLCAxMDksIDEwOCwgNDksIDc3LCA1MywgMTE1LCAxMjIsIDEx MywgODUsIDExMCwgODgsIDUyLCA3NCwNCiAxMTksIDQ4LCA0NSwgODAsIDc4LCA5OSwgNzMsIDc3 LCA5NSwgMTA2LCA0NSwgNzYsIDUzLCA4OSwgMTA3LCA3NiwNCiAxMDQsIDExOCwgNTEsIDg5LCAx MDcsIDQ4LCA1MiwgODgsIDY3LCAxMTksIDg0LCA3NCwgMTE5LCAxMjAsIDc4LCA3OCwNCiAxMDks IDg4LCA2NywgMTAyLCAxMDgsIDg5LCA2NSwgODEsIDc5LCA1NywgMTAyLCA0OCwgNDgsIDY1LCA5 NywgNTAsDQogNDksIDUxLCA4NCwgNzQsIDc0LCAxMTQsIDU0LCAxMDAsIDk4LCA3MiwgODYsIDU0 LCA3MywgNTQsIDUyLCA1MCwNCiA3MCwgMTE5LCA4NSwgNDUsIDY5LCA4NywgMTE4LCAxMTYsIDY5 LCAxMDIsIDc4LCA1MSwgMTAxLCAxMTgsIDEwMywgODgsDQogNTEsIDY5LCA3MCwgNzMsIDg2LCA4 OSwgODMsIDExMCwgODQsIDUxLCA3MiwgNjcsIDcyLCAxMDcsIDY1LCA2NSwNCiA3MywgMTAwLCA2 NiwgODEsIDU3LCAxMjEsIDEwNywgNjgsIDQ1LCA5NywgOTgsIDgyLCAxMjIsIDg2LCA2NSwgOTUs DQogMTAwLCA3MSwgMTEyLCA5NSwgMTIxLCA3NCwgNjUsIDkwLCA4MSwgOTksIDExNCwgOTAsIDEx NywgNzgsIDg0LCAxMTMsDQogMTIyLCA4NCwgMTA0LCAxMDAsIDk1LCA1MCwgNTAsIDg5LCA3Nywg ODAsIDEwNCwgNzMsIDExMiwgMTIyLCA4NCwgMTIxLA0KIDEwMywgMTAyLCA2NywgOTUsIDUyLCAx MDcsIDU1LCAxMTMsIDExMywgMTIwLCA3MywgNTQsIDExNiwgNTUsIDc2LCAxMDEsDQogOTUsIDEw OCwgNTMsIDk1LCAxMTEsIDQ1LCAxMTYsIDk3LCA4NSwgNzEsIDU1LCAxMTgsIDk3LCA3OCwgNjUs IDEwOCwNCiA1MywgNzAsIDEwNiwgNjksIDgxXQ0KQ2lwaGVydGV4dA0KWzI1MywgMjM3LCAxODEs IDE4MCwgOTcsIDE2MSwgMTA1LCAyMDcsIDIzMywgMTIwLCA2NSwgMTAwLCA0NSwgMTIyLCAyNDYs IDExNiwNCiAxOTUsIDIxMiwgMTAyLCAzNywgMzYsIDE3NV0NCkVuY29kZWQgQ2lwaGVydGV4dA0K X2UyMXRHR2hhY19wZUVGa0xYcjJkTVBVWmlVa3J3DQpBdXRoZW50aWNhdGlvbiBUYWcgKEludGVn cml0eSBWYWx1ZSkNCls5NywgMTgyLCA4MiwgMTIwLCAxMTIsIDE0MSwgMTMsIDE0NCwgMTA2LCAx LCAyMjAsIDIzMywgNjgsIDIzMywgMTE0LCAxMzldDQpFbmNvZGVkIEF1dGhlbnRpY2F0aW9uIFRh ZyAoRW5jb2RlZCBJbnRlZ3JpdHkgVmFsdWUpDQpZYlpTZUhDTkRaQnFBZHpwUk9seWl3DQpKV0UN CmV5SmhiR2NpT2lKU1UwRXRUMEZGVUNJc0ltVnVZeUk2SWtFeU5UWkhRMDBpTENKcGRpSTZJalE0 VmpGZlFVeGlObFZUTURSVk0ySWlmUS5qdndveWhXeE9NYm9CNWN4WDZuY0FpN1dwM1E1RktSdGxt SXgzNXBmUjlIcEVhNk95LWlFcHhFcU0zMFczWWNSUThXVTlvdVJvTzVqZDZ0ZmRjcFgtMlgtT3Rl SHc0ZG5NWGRNTGpIR0d4ODZMTURlRlJBTjJLR3o3RUdQSml2YXcweU04MGZ6VDN6WTBQS3JJdlU1 bWwxTTVzenFVblg0SncwLVBOY0lNX2otTDVZa0xodjNZazA0WEN3VEp3eE5ObVhDZmxZQVFPOWYw MEFhMjEzVEpKcjZkYkhWNkk2NDJGd1UtRVd2dEVmTjNldmdYM0VGSVZZU25UM0hDSGtBQUlkQlE5 eWtELWFiUnpWQV9kR3BfeUpBWlFjclp1TlRxelRoZF8yMllNUGhJcHpUeWdmQ180azdxcXhJNnQ3 TGVfbDVfby10YVVHN3ZhTkFsNUZqRVEuX2UyMXRHR2hhY19wZUVGa0xYcjJkTVBVWmlVa3J3Llli WlNlSENORFpCcUFkenBST2x5aXcNCg== --_004_4E1F6AAD24975D4BA5B16804296739436656E627TK5EX14MBXC283r_-- From kent@bbn.com Fri Jun 29 09:16: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 E6FA721F87B4 for ; Fri, 29 Jun 2012 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YA+rtn1RCV5 for ; Fri, 29 Jun 2012 09:16:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5186D21F87A8 for ; Fri, 29 Jun 2012 09:16:18 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55442 helo=[192.168.1.2]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Skdra-000J5g-L8; Fri, 29 Jun 2012 12:16:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F73F48F8@WSMSG3153V.srv.dir.telstra.com > References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.micr osoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com > <01c301cd54f7$fb3f7e30$f1be7a90$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F730F705@WSMSG3153V.srv.dir.telstra.com > <13DF3FD5-6613-4AC9-BBDB-94061F95EC94@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F73F48F8@WSMSG3153V.srv.dir.telstra.com > Date: Fri, 29 Jun 2012 12:11:34 -0400 To: "Manger, James H" From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: "Richard L. Barnes" , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] protected attributes 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, 29 Jun 2012 16:16:19 -0000 At 3:56 PM +1000 6/29/12, Manger, James H wrote: > > ... > >Bob is not necessarily being quite as irresponsible as he seems. > >Any CA will sign 256 bytes that I can choose almost arbitrarily >as long as I say the bytes are a 2048-bit RSA modulus. really? I would argue that any CA that signs an object without verifying that the object is a well-formed cert (or CRL) is=20 a pretty poor example of a CA. Also, what the CA signs, literally, is a hash of the object, not an RSA modulus, so I'm confused by your text above. I would agree with the statement that many (most?) CAs that use HSMs are employing hardware that will sign whatever it is handed, without being able to verify what it is. That's a different statement from what you said above. >The CA isn't irresponsible, even if those 256 bytes are the >UTF-8 encoding of "This CA promises to give you $1M=8A". again, disagree. >This is only safe because a DER-encoded TBSCertificate has so >much structure that it is inconceivable that those bytes could >be misinterpreted as some other application message. OK, we're getting closer to reality here. >It is not absolutely clear to me that a JOSE message >(in whatever syntax we end up with) will have so much structure >that it is inconceivable that a value could be created that >was both a valid JOSE message and a valid application message >simultaneously. That may be a valid concern, depending on the syntax. if the syntax of Jose objects is well-specified and declared, then this concern seems unwarranted. Steve From Michael.Jones@microsoft.com Fri Jun 29 10:09: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 0EFF021F87FE for ; Fri, 29 Jun 2012 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il2zzwbA4HRD for ; Fri, 29 Jun 2012 10:09:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A621F87FA for ; Fri, 29 Jun 2012 10:09:49 -0700 (PDT) Received: from mail148-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 17:07:59 +0000 Received: from mail148-va3 (localhost [127.0.0.1]) by mail148-va3-R.bigfish.com (Postfix) with ESMTP id AAFA3440301; Fri, 29 Jun 2012 17:07:59 +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: -28 X-BigFish: VS-28(zz9371I542M1418I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail148-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail148-va3 (localhost.localdomain [127.0.0.1]) by mail148-va3 (MessageSwitch) id 1340989677788249_16239; Fri, 29 Jun 2012 17:07:57 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.247]) by mail148-va3.bigfish.com (Postfix) with ESMTP id B394220049; Fri, 29 Jun 2012 17:07:57 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 17:07:54 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 29 Jun 2012 17:09:36 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: Comments on draft-ietf-jose-json-web-key-02 Thread-Index: Ac0163Sed6pM9c+JR7OKMRgzzwxF3QgLkV7w Date: Fri, 29 Jun 2012 17:09:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656EA5D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <020001cd360f$6da10190$48e304b0$@augustcellars.com> In-Reply-To: <020001cd360f$6da10190$48e304b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-02 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, 29 Jun 2012 17:09:51 -0000 Is there an alternative term you'd propose that we use instead of "algorith= m families" in the JWK spec, Jim? Thanks, -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Saturday, May 19, 2012 3:34 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-key-02 My apologies for introducing you to the term algorithm families. We don't = use it in the same way and thus I think that you should generally remove it= from the text. To me it is a very wide term and somewhat nebulous. Thus = I think of all of the DH algorithms as being in a family - but that family = could also include the ECDH algorithm as well as DSA depending on how one i= s using it. Thus for me an algorithm family is not restricted to a specifi= c instance (or small set of instances) such a DH & DSA but could be as larg= e as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have addi= tional fields defined that deal specifically with RSA-OAEP. The difference= is going to be a question of restriction of usage of the key to a single a= lgorithm vs allowing for all RSA algorithms. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word = implies to me that the list is not expandable. I would recommend something= along the lines of "An initial set of ... can be found in ..." 2. JSON needs to be expanded on first use Section 1 1. JSON needs to be expanded on first use. (Doing it on second use should= be fine and clearer) 2. See enumerated comment above 3. Don't use non-goals. The wording "The goals of this document do not in= clude ..." (Minor) 4. It is fine to tell me what documents they are used in. I don't know th= at we need to say what the fields are. (Minor)=20 Section 2 1. The phrase "For the purpose of this document" should be removed unless = this term is used in other ways elsewhere. Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members = are going to be required for the specific key being represented not to the = family - consider the case of RSA and RSA-OAEP - these are both in the same= family, but the fields required are different. 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. 3. I don't believe that para #3 is enforceable by parsers as they have bee= n presented to me. Please prove me wrong. 4. Let's look at the sentence "If present, they MUST be understood by im= plementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does = not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by al= l of the implementations.=20 The only entity that you can make the requirement on is the consumer. One = assumes that the "provider" would/might understand the field or it would no= t be there but it could have been added in transit and thus that is not the= case. 5. I find the last sentence of para #4 to be unreadable. I would start by= breaking it into two sentences and potentially move the first one into the= JWA document (that about parameters for keys). Section 4.1 1. Do you want to point to the JWA document or to the registry for the set = of defined algorithms? 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered= in section 4.0 3. The last two sentences in para #1 can be combined together. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it = will be easier to see what the list of defined values is. 2. See point #3 in section 4.1 Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think th= at the answer should be called out in text either way. 2. Is the string case sensitive? 3. Move the sentence "When used..." to a new paragraph. (suggestion) Section 6.1 1. Please make things easy for IANA - create a table with the fields across= the top and the values down the table. This will allow them to do their j= ob without having to go through the entire document and for us to be able t= o easily validate that they got it correct. Section 6.2 1. Please put in a registration section for the items you are registering i= n Section 4 in the JWK table. You can refer to JWA for creation of the tab= le. Appendix A 1. I am not sure why this appendix is in this document. From rbarnes@bbn.com Fri Jun 29 10:20: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 4F23B21F87B4 for ; Fri, 29 Jun 2012 10:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.459 X-Spam-Level: X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJlSMRluInYY for ; Fri, 29 Jun 2012 10:20:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA4621F8620 for ; Fri, 29 Jun 2012 10:20:02 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:54247) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkerR-0001kH-4y; Fri, 29 Jun 2012 13:20:01 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 29 Jun 2012 13:20:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Second compute JWE computation example 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, 29 Jun 2012 17:20:04 -0000 This seems underspecified. What parameters are you using for OAEP? = IIRC, it requires a digest algorithm and a masking generation function. = I don't see either of those specified in JWS or JWA. On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: > Dear working group members, > =20 > A second complete JWE computation example is included below. As I=92d = previously written, I=92m adding example encryption computations to the = JWE spec to aid implementers. These values have been verified by two = independent implementations. > =20 > This example uses the header values: > {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} > =20 > This example verifies both the use of RSA-OAEP and the use of AES-GCM = =96 including the use of the Additional Authenticated Data parameter and = the Authentication Tag output. > =20 > Note that because the RSA-OAEP computation uses random values, the = encrypted key computation will not be repeatable, although all resulting = values will be decryptable to retrieve the original key value. > =20 > I=92d be interested in hearing results from any of you who also try = this JWE with your implementation. > =20 > Enjoy, > -- Mike > =20 > CMK (CEK) > [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, = 212, 246, > 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, = 252] > IV > [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219] > Plaintext > [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, = 114, > 111, 115, 112, 101, 114, 46] > Header > {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} > Header Bytes > [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80, > 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, > 34, 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, > 54, 85, 83, 48, 52, 85, 51, 98, 34, 125] > Encoded Header > = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM2= IifQ > BEGIN RSA KEY PARAMETERS > Exponent > [1, 0, 1] > Modulus > [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30, 135, = 227, > 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193, 62, 5, 91, > 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161, 153, = 157, > 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78, 93, 140, 131, 87, = 182, > 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35, 79, 210, 222, 192, 208, > 252, 49, 109, 138, 173, 253, 210, 166, 201, 63, 102, 74, 5, 158, 41, = 90, > 144, 108, 160, 79, 10, 89, 222, 231, 172, 31, 227, 197, 0, 19, 72, 81, > 138, 78, 136, 221, 121, 118, 196, 17, 146, 10, 244, 188, 72, 113, 55, = 221, > 162, 217, 171, 27, 57, 233, 210, 101, 236, 154, 199, 56, 138, 239, = 101, 48, > 198, 186, 202, 160, 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, = 64, > 40, 75, 58, 89, 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, > 58, 153, 46, 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, = 110, > 17, 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, = 20, > 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, 71, = 243, > 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, = 232, > 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190, 253, 186, 186, = 27] > D (private key exponent) > [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, = 181, > 233, 92, 54, 219, 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, > 53, 23, 191, 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, = 237, > 104, 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, = 202, > 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39, 244, = 122, > 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42, 86, 223, 32, = 236, > 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, 1, 42, 177, 24, 99, > 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, 95, 187, 134, 71, 88, > 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72, 44, 245, 95, 39, = 194, > 179, 175, 203, 122, 16, 112, 183, 17, 200, 202, 31, 17, 138, 156, 184, = 210, > 157, 184, 154, 131, 128, 110, 12, 85, 195, 122, 241, 79, 251, 229, = 183, 117, > 21, 123, 133, 142, 220, 153, 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, > 62, 216, 38, 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, 131, 137, = 175, > 72, 126, 43, 229, 69, 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, = 252, > 171, 143, 194, 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, = 210, > 7, 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, = 201] > The remaining RSA key parameters are included for completeness, but = should not be needed > DP > [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, 109, 71, 188, 60, = 88, > 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, 34, 22, 248, 31, 121, = 13, > 210, 138, 183, 172, 94, 57, 189, 129, 158, 74, 46, 19, 23, 190, 143, = 174, > 207, 226, 148, 37, 96, 241, 75, 154, 69, 67, 243, 52, 122, 247, 104, = 213, > 210, 162, 69, 56, 213, 195, 252, 120, 55, 42, 178, 92, 243, 57, 157, = 66, > 207, 145, 202, 84, 243, 110, 235, 158, 150, 115, 0, 146, 169, 118, 21, = 128, > 130, 170, 215, 24, 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, > 223, 243, 86, 144, 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, = 225] > DQ > [14, 173, 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, > 161, 13, 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, = 135, > 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, 86, = 24, > 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, 13, 197, = 122, > 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209, 200, 252, = 170, 172, > 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37, 87, 132, 72, 232, 201, > 13, 147, 216, 29, 209, 216, 242, 253, 91, 250, 143, 153, 217, 126, = 109, 188, > 188, 126, 76, 39, 164, 127, 186, 49, 201, 226, 131, 82, 162, 150, 142, = 43] > InverseQ > [84, 131, 41, 49, 134, 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, = 124, > 248, 166, 177, 39, 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, = 147, 255, > 46, 173, 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, > 201, 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, = 80, > 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, 0, = 235, > 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20, 184, = 171, 231, > 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115, 199, 40, 243, = 244, > 145, 127, 95, 38, 152, 215, 134, 171, 116, 180, 163, 127, 130, 255, = 20, 214] > P > [214, 190, 118, 94, 78, 58, 115, 226, 236, 124, 30, 79, 227, 141, 169, = 237, > 171, 93, 61, 74, 241, 65, 44, 184, 154, 216, 191, 181, 146, 55, 50, 7, > 246, 18, 225, 85, 109, 74, 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, > 154, 129, 51, 47, 178, 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, = 129, > 135, 76, 131, 32, 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, > 143, 85, 151, 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, = 76, > 12, 91, 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, = 173, > 183, 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] > Q > [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, 229, = 123, > 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 27, 134, > 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, 160, 216, > 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177, 167, 13, > 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, 162, 53, 162, = 102, > 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 222, 32, 191, 17, = 72, > 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54, 69, 171, 84, 6, > 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58, 241, 70, 71, 190, = 215] > END RSA KEY PARAMETERS > Encrypted Key > [142, 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, = 2, > 46, 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, = 209, > 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, 135, = 17, > 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117, 202, 87, = 251, > 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, 46, 49, 198, 27, = 31, > 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236, 65, 143, 38, 43, = 218, > 195, 76, 140, 243, 71, 243, 79, 124, 216, 208, 242, 171, 34, 245, 57, = 154, > 93, 76, 230, 204, 234, 82, 117, 248, 39, 13, 62, 60, 215, 8, 51, 248, > 254, 47, 150, 36, 46, 27, 247, 98, 77, 56, 92, 44, 19, 39, 12, 77, > 54, 101, 194, 126, 86, 0, 64, 239, 95, 211, 64, 26, 219, 93, 211, 36, > 154, 250, 117, 177, 213, 232, 142, 184, 216, 92, 20, 248, 69, 175, = 180, 71, > 205, 221, 235, 224, 95, 113, 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, > 0, 135, 65, 67, 220, 164, 15, 230, 155, 71, 53, 64, 253, 209, 169, = 255, > 34, 64, 101, 7, 43, 102, 227, 83, 171, 52, 225, 119, 253, 182, 96, = 195, > 225, 34, 156, 211, 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, = 203, > 123, 249, 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, = 99, 17] > Encoded Encrypted Key > = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9ouRoO= 5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PKrIvU5= ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6dbHV6I= 642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22= YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ > Additional Authenticated Data > = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM2= IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9= ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PK= rIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6d= bHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzT= hd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ > Additional Authenticated Data Bytes > [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, > 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, > 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74, 112, > 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85, 120, 105, > 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81, 46, 106, > 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53, 99, 120, = 88, > 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75, 82, 116, 108, > 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69, 97, 54, 79, 121, > 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51, 89, 99, 82, 81, > 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100, 54, 116, 102, = 100, > 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72, 119, 52, 100, 110, 77, > 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54, 76, 77, 68, 101, 70, > 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74, 105, 118, 97, 119, > 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89, 48, 80, 75, 114, 73, > 118, 85, 53, 109, 108, 49, 77, 53, 115, 122, 113, 85, 110, 88, 52, 74, > 119, 48, 45, 80, 78, 99, 73, 77, 95, 106, 45, 76, 53, 89, 107, 76, > 104, 118, 51, 89, 107, 48, 52, 88, 67, 119, 84, 74, 119, 120, 78, 78, > 109, 88, 67, 102, 108, 89, 65, 81, 79, 57, 102, 48, 48, 65, 97, 50, > 49, 51, 84, 74, 74, 114, 54, 100, 98, 72, 86, 54, 73, 54, 52, 50, > 70, 119, 85, 45, 69, 87, 118, 116, 69, 102, 78, 51, 101, 118, 103, 88, > 51, 69, 70, 73, 86, 89, 83, 110, 84, 51, 72, 67, 72, 107, 65, 65, > 73, 100, 66, 81, 57, 121, 107, 68, 45, 97, 98, 82, 122, 86, 65, 95, > 100, 71, 112, 95, 121, 74, 65, 90, 81, 99, 114, 90, 117, 78, 84, 113, > 122, 84, 104, 100, 95, 50, 50, 89, 77, 80, 104, 73, 112, 122, 84, 121, > 103, 102, 67, 95, 52, 107, 55, 113, 113, 120, 73, 54, 116, 55, 76, = 101, > 95, 108, 53, 95, 111, 45, 116, 97, 85, 71, 55, 118, 97, 78, 65, 108, > 53, 70, 106, 69, 81] > Ciphertext > [253, 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, = 246, 116, > 195, 212, 102, 37, 36, 175] > Encoded Ciphertext > _e21tGGhac_peEFkLXr2dMPUZiUkrw > Authentication Tag (Integrity Value) > [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, 114, = 139] > Encoded Authentication Tag (Encoded Integrity Value) > YbZSeHCNDZBqAdzpROlyiw > JWE > = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM2= IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9= ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PK= rIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6d= bHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzT= hd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ._e21tGGhac_peEFkLXr2dM= PUZiUkrw.YbZSeHCNDZBqAdzpROlyiw > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jun 29 10:48: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 AAC8021F86D4 for ; Fri, 29 Jun 2012 10:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.683 X-Spam-Level: X-Spam-Status: No, score=-3.683 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgIjnoLLiFWs for ; Fri, 29 Jun 2012 10:48:20 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id BF2F521F86E0 for ; Fri, 29 Jun 2012 10:48:19 -0700 (PDT) Received: from mail97-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 17:46:28 +0000 Received: from mail97-db3 (localhost [127.0.0.1]) by mail97-db3-R.bigfish.com (Postfix) with ESMTP id 8E90E4A006B; Fri, 29 Jun 2012 17:46:28 +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: -28 X-BigFish: VS-28(zz98dI9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail97-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail97-db3 (localhost.localdomain [127.0.0.1]) by mail97-db3 (MessageSwitch) id 1340991986873970_18584; Fri, 29 Jun 2012 17:46:26 +0000 (UTC) Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.239]) by mail97-db3.bigfish.com (Postfix) with ESMTP id D35FEE0046; Fri, 29 Jun 2012 17:46:26 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 17:46:26 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 29 Jun 2012 17:48:07 +0000 From: Mike Jones To: "Richard L. Barnes" Thread-Topic: [jose] Second compute JWE computation example Thread-Index: Ac1WCsOvMw1U5OWeRpC0zgJyTb2gbwAEKXwAAACuMJA= Date: Fri, 29 Jun 2012 17:48:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> In-Reply-To: <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Second compute JWE computation example 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, 29 Jun 2012 17:48:21 -0000 Good catch. I'll add to the JWA spec that RSA-OAEP specifies the use of OA= EP padding with the default parameters defined by PKCS #1 v2.1 (RFC 3447) i= n Section A.2.1. -- Mike -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Friday, June 29, 2012 10:20 AM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Second compute JWE computation example This seems underspecified. What parameters are you using for OAEP? IIRC, = it requires a digest algorithm and a masking generation function. I don't = see either of those specified in JWS or JWA. On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: > Dear working group members, > =20 > A second complete JWE computation example is included below. As I'd prev= iously written, I'm adding example encryption computations to the JWE spec = to aid implementers. These values have been verified by two independent im= plementations. > =20 > This example uses the header values: > {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} > =20 > This example verifies both the use of RSA-OAEP and the use of AES-GCM - i= ncluding the use of the Additional Authenticated Data parameter and the Aut= hentication Tag output. > =20 > Note that because the RSA-OAEP computation uses random values, the encryp= ted key computation will not be repeatable, although all resulting values w= ill be decryptable to retrieve the original key value. > =20 > I'd be interested in hearing results from any of you who also try this JW= E with your implementation. > =20 > Enjoy, > -- Mike > =20 > CMK (CEK) > [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,=20 > 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,=20 > 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77,=20 > 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,=20 > 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 > {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} > Header Bytes > [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80,=20 > 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, 34,=20 > 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, 85,=20 > 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 > eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMD > RVM2IifQ > BEGIN RSA KEY PARAMETERS > Exponent > [1, 0, 1] > Modulus > [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30, 135,=20 > 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193, 62, 5,=20 > 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161,=20 > 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78, 93, 140,=20 > 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35, 79, 210,=20 > 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201, 63, 102,=20 > 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231, 172, 31, 227,=20 > 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196, 17, 146, 10,=20 > 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 233, 210, 101, 236,=20 > 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160, 76, 111, 234, 71,=20 > 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, 89, 244, 254, 107, 84,=20 > 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46, 151, 174, 12, 103,=20 > 197, 181, 161, 162, 55, 250, 235, 123, 110, 17, 11, 158, 24, 47, 133,=20 > 8, 199, 235, 107, 126, 130, 246, 73, 195, 20, 108, 202, 176, 214, 187,=20 > 45, 146, 182, 118, 54, 32, 200, 61, 201, 71, 243, 1, 255, 131, 84, 37,=20 > 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, 232, 36, 10, 230, 248,=20 > 190, 82, 182, 140, 35, 204, 108, 190, 253, 186, 186, 27] D (private=20 > key exponent) [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, 66,=20 > 73, 54, 16, 181, 233, 92, 54, 219, 101, 42, 35, 178, 63, 51, 43, 92,=20 > 119, 136, 251, 41, 53, 23, 191, 164, 164, 60, 88, 227, 229, 152, 228,=20 > 213, 149, 228, 169, 237, 104, 71, 151, 75, 88, 252, 216, 77, 251, 231,=20 > 28, 97, 88, 193, 215, 202, 248, 216, 121, 195, 211, 245, 250, 112, 71,=20 > 243, 61, 129, 95, 39, 244, 122, 225, 217, 169, 211, 165, 48, 253, 220,=20 > 59, 122, 219, 42, 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187,=20 > 88, 176, 89, 24, 1, 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64,=20 > 194, 121, 182, 95, 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106,=20 > 143, 121, 27, 72, 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112,=20 > 183, 17, 200, 202, 31, 17, 138, 156, 184, 210, 157, 184, 154, 131,=20 > 128, 110, 12, 85, 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133,=20 > 142, 220, 153, 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38,=20 > 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126,=20 > 43, 229, 69, 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171,=20 > 143, 194, 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7,=20 > 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201]=20 > The remaining RSA key parameters are included for completeness, but=20 > should not be needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116,=20 > 169, 29, 109, 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206,=20 > 78, 140, 34, 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189,=20 > 129, 158, 74, 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241,=20 > 75, 154, 69, 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213,=20 > 195, 252, 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84,=20 > 243, 110, 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170,=20 > 215, 24, 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243,=20 > 86, 144, 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ=20 > [14, 173, 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184,=20 > 161, 13, 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101,=20 > 135, 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50,=20 > 86, 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168,=20 > 13, 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209,=20 > 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37,=20 > 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, 250,=20 > 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,=20 > 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, 134,=20 > 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, 39,=20 > 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,=20 > 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201, 186,=20 > 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, 80, 174,=20 > 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, 0, 235,=20 > 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20, 184,=20 > 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115, 199,=20 > 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180, 163,=20 > 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, 226, 236,=20 > 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44, 184,=20 > 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74, 3, 6,=20 > 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178, 87, 174,=20 > 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, 32, 4, 61,=20 > 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151, 243, 47,=20 > 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91, 168, 81,=20 > 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, 183, 195, 35,=20 > 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q [192, 182,=20 > 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, 229, 123, 206,=20 > 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 27, 134, 178,=20 > 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, 160, 216, 85,=20 > 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177, 167, 13, 236,=20 > 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, 162, 53, 162, 102,=20 > 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 222, 32, 191, 17,=20 > 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54, 69, 171, 84,=20 > 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58, 241, 70, 71, 190,=20 > 215] END RSA KEY PARAMETERS Encrypted Key [142, 252, 40, 202, 21, 177,=20 > 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, 46, 214, 167, 116, 57, 20,=20 > 164, 109, 150, 98, 49, 223, 154, 95, 71, 209, 233, 17, 174, 142, 203,=20 > 232, 132, 167, 17, 42, 51, 125, 22, 221, 135, 17, 67, 197, 148, 246,=20 > 139, 145, 160, 238, 99, 119, 171, 95, 117, 202, 87, 251, 101, 254, 58,=20 > 215, 135, 195, 135, 103, 49, 119, 76, 46, 49, 198, 27, 31, 58, 44,=20 > 192, 222, 21, 16, 13, 216, 161, 179, 236, 65, 143, 38, 43, 218, 195,=20 > 76, 140, 243, 71, 243, 79, 124, 216, 208, 242, 171, 34, 245, 57, 154,=20 > 93, 76, 230, 204, 234, 82, 117, 248, 39, 13, 62, 60, 215, 8, 51, 248,=20 > 254, 47, 150, 36, 46, 27, 247, 98, 77, 56, 92, 44, 19, 39, 12, 77, 54,=20 > 101, 194, 126, 86, 0, 64, 239, 95, 211, 64, 26, 219, 93, 211, 36, 154,=20 > 250, 117, 177, 213, 232, 142, 184, 216, 92, 20, 248, 69, 175, 180, 71,=20 > 205, 221, 235, 224, 95, 113, 5, 33, 86, 18, 157, 61, 199, 8, 121, 0,=20 > 0, 135, 65, 67, 220, 164, 15, 230, 155, 71, 53, 64, 253, 209, 169,=20 > 255, 34, 64, 101, 7, 43, 102, 227, 83, 171, 52, 225, 119, 253, 182,=20 > 96, 195, 225, 34, 156, 211, 202, 7, 194, 255, 137, 59, 170, 172, 72,=20 > 234, 222, 203, 123, 249, 121, 254, 143, 173, 105, 65, 187, 189, 163,=20 > 64, 151, 145, 99, 17] Encoded Encrypted Key=20 > jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9o > uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY > 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa21 > 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJA > ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ > Additional Authenticated Data > eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMD > RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3 > YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0y > M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQ > O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzV > A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjE > Q > Additional Authenticated Data Bytes > [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116,=20 > 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54,=20 > 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74, 112,=20 > 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85, 120, 105,=20 > 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81, 46, 106,=20 > 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53, 99, 120,=20 > 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75, 82, 116,=20 > 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69, 97, 54, 79,=20 > 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51, 89, 99, 82,=20 > 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100, 54, 116, 102,=20 > 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72, 119, 52, 100, 110,=20 > 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54, 76, 77, 68, 101,=20 > 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74, 105, 118, 97,=20 > 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89, 48, 80, 75, 114,=20 > 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122, 113, 85, 110, 88, 52,=20 > 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106, 45, 76, 53, 89, 107, 76,=20 > 104, 118, 51, 89, 107, 48, 52, 88, 67, 119, 84, 74, 119, 120, 78, 78,=20 > 109, 88, 67, 102, 108, 89, 65, 81, 79, 57, 102, 48, 48, 65, 97, 50,=20 > 49, 51, 84, 74, 74, 114, 54, 100, 98, 72, 86, 54, 73, 54, 52, 50, 70,=20 > 119, 85, 45, 69, 87, 118, 116, 69, 102, 78, 51, 101, 118, 103, 88, 51,=20 > 69, 70, 73, 86, 89, 83, 110, 84, 51, 72, 67, 72, 107, 65, 65, 73, 100,=20 > 66, 81, 57, 121, 107, 68, 45, 97, 98, 82, 122, 86, 65, 95, 100, 71,=20 > 112, 95, 121, 74, 65, 90, 81, 99, 114, 90, 117, 78, 84, 113, 122, 84,=20 > 104, 100, 95, 50, 50, 89, 77, 80, 104, 73, 112, 122, 84, 121, 103,=20 > 102, 67, 95, 52, 107, 55, 113, 113, 120, 73, 54, 116, 55, 76, 101, 95,=20 > 108, 53, 95, 111, 45, 116, 97, 85, 71, 55, 118, 97, 78, 65, 108, 53,=20 > 70, 106, 69, 81] Ciphertext [253, 237, 181, 180, 97, 161, 105, 207,=20 > 233, 120, 65, 100, 45, 122, 246, 116, 195, 212, 102, 37, 36, 175]=20 > Encoded Ciphertext _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag=20 > (Integrity Value) [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220,=20 > 233, 68, 233, 114, 139] Encoded Authentication Tag (Encoded Integrity=20 > Value) YbZSeHCNDZBqAdzpROlyiw JWE=20 > eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM= 2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9= ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PKr= IvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6dbH= V6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_= 22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ._e21tGGhac_peEFkLXr2dMPUZi= Ukrw.YbZSeHCNDZBqAdzpROlyiw > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Fri Jun 29 10:52: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 CF08921F8685 for ; Fri, 29 Jun 2012 10:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmck25udiuuQ for ; Fri, 29 Jun 2012 10:52:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B654D21F8674 for ; Fri, 29 Jun 2012 10:52:41 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:54333) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkfMx-000JxD-U6; Fri, 29 Jun 2012 13:52:36 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F73F48F8@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 29 Jun 2012 13:52:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366560A72@TK5EX14MBXC283.redmond.corp.microsoft.com> <007301cd532c$f4e7f0c0$deb7d240$@augustcellars.com> <706BA894-367C-4AC5-B70A-21F9039C1F78@ve7jtb.com> <080F4097-F27D-4A31-832F-FF5CCF71A1CF@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F722F110@WSMSG3153V.srv.dir.telstra.com> <01c301cd54f7$fb3f7e30$f1be7a90$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F730F705@WSMSG3153V.srv.dir.telstra.com> <13DF3FD5-6613-4AC9-BBDB-94061F95EC94@bbn.com> <255B9BB34FB7D647A506DC292726F6E114F73F48F8@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] protected attributes 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, 29 Jun 2012 17:52:42 -0000 Top-posting two points for emphasis: 1. This problem could be avoided if JWT provided a way to distinguish a = claims object from a JWS, e.g., by putting the "emb" field *inside* the = object.=20 2. Nested signatures are an *awful* solution in this case. If you want = to have two people sign the same set of claims, parallel signatures = would be much cleaner. Consider also the "canonicalization bloat": If N = people sign, then the content gets base64-encoded N times, each time = increasing the length by a factor of ~1.5-2x. Compare this to just = adding a Signature object in JSMS. = JWS: Exponential cost JSMS: Linear cost=20 The choice seems clear to me :) (I admit that the JSON serialization of = JWS supports multiple parallel signers, so it's linear too.) Further replies inline. On Jun 29, 2012, at 1:56 AM, Manger, James H wrote: >>> I can describe a somewhat artificial attack. >>> Alice creates a message >>>=20 >> = {"iss":"Bob","perm":"read","alg":"RS256"}.{"iss":"Bob","perm":"write",. >> ..} >>> Alice says it is a "JWT bag of claims" and asks Bob to sign it. >>> Bob expects a JSON object so only "sees" the first part. >>> He confirms Alice does have "read" permission, >>> confirms he is listed as the issuer, and accepts anything else >>> as unverified user-asserted stuff (like a lot of details in >>> public certificates). >>> Bob signs the message, prepending an unprotected header with the >>> details. >=20 >> Most clearly, Bob is being irresponsible. He should not be signing >> anything that he doesn't want to assert. Before he signs, he should = be >> verifying that he understands and agrees with everything in the >> assertion. Bob should have signed only the part that he "saw". = (Read >> the contract before you sign it!) Attacks that rely on irresponsible >> signer practices call for operational guidelines, not protocol = changes. >=20 > Bob is not necessarily being quite as irresponsible as he seems. >=20 > Any CA will sign 256 bytes that I can choose almost arbitrarily > as long as I say the bytes are a 2048-bit RSA modulus. > The CA isn't irresponsible, even if those 256 bytes are the > UTF-8 encoding of "This CA promises to give you $1M=85". > This is only safe because a DER-encoded TBSCertificate has so > much structure that it is inconceivable that those bytes could > be misinterpreted as some other application message. >=20 > It is not absolutely clear to me that a JOSE message > (in whatever syntax we end up with) will have so much structure > that it is inconceivable that a value could be created that > was both a valid JOSE message and a valid application message > simultaneously. That's why it's important for the application to specify what the = content is that's being handled, and not just to say "Oh, it could be a = JWS, or it could be something else, you'll have to guess." =20 Your attack doesn't work in PKIX because the specification says "The = thing that's signed is a TBSCertificate, so these 256 octets are a = public key, so you should uses them like a public key, not a string." Your attack does work in JWS (with unprotected headers) because JWT = doesn't say what the interior octets are. This is not an issue of collisions between formats, it's an issue of = having sufficient specification that the recipient knows what he's = getting. If there's agreement between the signer and the recipient = about what the thing is, then collisions don't matter. >>> Alice modifies the unprotected JOSE header, >>> adding "embed":true to Bob's header. >>=20 >> There's no such thing as an unprotected header in JWS. >=20 > The whole idea of this thread was to discuss your suggestion > to replace JWS with a syntax that had an unprotected header. Oh, ok, sorry :) >> What is "embed"? I don't see it in the JWT or JWS specs: >=20 > "embed":true is one possible way to indicate that the content > is another JOSE message, not the final content. > Dick Hardt suggested an "emb" element in the JSON header, > instead of my suggestion of using the case (upper or lower) > of a prefix (E.
... or e.
...). > The current specs use "typ":"JWS" for the indication. > Sorry for the confusion. >=20 >=20 >>> Charlie receives the message and passes it to his JOSE library. >>> The library verifies Bob's signature, interprets the content >>> as another JOSE message, verifies Alice's signature, and passes >>> back to Charlie {"iss":"Bob","perm":"write",...} plus metadata = saying >>> it was signed by Bob and Alice. >>> Charlie trusts Bob and hence gives Alice write access. >>> ATTACK SUCCEEDED >>=20 >> I don't see where Alice signed anything in this example. Maybe you >> could flesh it out a little? >=20 > = {"iss":"Bob","perm":"read","alg":"RS256"...}.{"iss":"Bob","perm":"write",.= ..}. >=20 > Alice creates this message. It is a valid JOSE signed message (eg = "alg":"RS256" in header), with some extra fields (eg "perm":"read") that = are unrecognized (hence ignored) by a JOSE receiver. >=20 > This same message is also a valid application message from Bob's = perspective. Perhaps Bob ignores the fields like "alg" that his app = doesn't recognized (just like the JOSE processor ignores the "perm" = field), or perhaps the extra stuff is user-chosen like the modulus in a = certificate. >=20 > Bob adds a layer of JOSE protection to the message and expects Charlie = to remove just this layer. Charlie however removes both Bob's and = Alice's JOSE layers since the indication of another layer in Bob's = header was not protected so it could be modified. Charlie verifies that = the message is from Bob, and the final content has "perm":"write". >=20 >=20 >>> This only works if a block of data can be interpreted as a >>> valid JOSE message by one party and as valid application >>> content by another party. That is a bit unusual but far from >>> impossible. Concatenate a *.GIF and a *.ZIP file and you >>> get a valid image and a valid ZIP archive (since they are >>> parsed from the start & end respectively). >>>=20 >>>=20 >>> Without protecting the "embed" attribute JOSE gives: >>>=20 >>> [ ] [ ] -----> INVALID >>> content ---> [ JOSE ] -> [ JOSE ] -or--> content >>> [ wrap ] [unwrap ] -or--> intermediate content >>>=20 >>> It would be nice not to need to rely on application >>> logic to distinguish "intermediate content" from >>> the actual "content". That is, the 3rd option should be >>> detected as INVALID (eg by signing the "embed" attribute). >>=20 >> I don't think it's unreasonable to have the application define what = it >> is that's inside the protected content. You can do this either by >> having something inside the protected content that says what it is = (in >> which case it's protected), or by fixing the type in the application >> specification (and verifying this on receipt). >>=20 >> S/MIME follows the first pattern, by having an inner Content-Type = that >> tells you what the protected MIME entity is. Matt Miller's XMPP e2e >> security draft follows the second pattern, requiring the protected >> content to be an XMPP stanza. >> >>=20 >> For something like JWT, I would think you would just do the latter, = and >> require that the inner body be a set of claims, formatted in JSON. >>=20 >>=20 >>>>> Again noting precedent: If you look at S/MIME, for example, the >>>>> Content-Type of the MIME body is inside of the CMS EnvelopedData >>>>> structure, so the presence of SignedData on the inside would not >>>>> be observable. >>>=20 >>>> True and false - If you look at S/MIME you would see an id-data, >>>> however if you look at CMS you might see id-SignedData as the >>>> encapsulated content type. For S/MIME it would be data - since >>>> the next wrapping layer is mime not SignedData. >>>=20 >>> So does every app using JOSE need to define a MIME-like = encapsulation >>> around its content (like S/MIME does) to use JOSE safely? >>> What are the necessary features of that encapsulation? >>=20 >> See above. The application needs to either specify the type of the >> protected content in-band (like S/MIME) or define a fixed content = type >> (like XMPP). >=20 >=20 > "define a fixed content type" AND ensure no value can simultaneously = look like a value of that fixed content type and a JOSE message. If the content type is fixed, then there's no need to avoid collision = with JOSE: The content is always processed as the fixed content type, = never as a JOSE message. Likewise if the content type is specified, as = in S/MIME; the content is always processed as the specified content = type. That is, it's processed as JOSE only if the (protected) = content-type says it's JOSE. The only context where the protocol needs to worry about collisions is = if it *allows* them -- that is, it follows neither of the design = patterns above, and just allows either JOSE or content without a = signifier. To offer a concrete example, JWT could avoid this whole problem by = requiring that the inner JSON object contain a field "emb":true, = indicating whether the JSON is another JWS or the claims themselves (and = defaulting to false, obviously). That would be functionally equivalent = to putting it in a protected header value, but carry along all the = problems with signing cryptographic parameters.=20 --Richard From rbarnes@bbn.com Fri Jun 29 10:58: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 E3C7C21F8814 for ; Fri, 29 Jun 2012 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nzfC3QKRlR5 for ; Fri, 29 Jun 2012 10:58:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C313221F863C for ; Fri, 29 Jun 2012 10:58:21 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:54367) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkfSX-0002Ov-3z; Fri, 29 Jun 2012 13:58:21 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 29 Jun 2012 13:58:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 17:58:28 -0000 (Changed subject line to reflect topic change) Might be nice to have a way to specify the parameters, but fall back to = the default if the parameters are missing. =20 As an aside: This is why in JSMS all the crypto stuff gets bound up in = the AlgorithmIdentifier structure. Using that design pattern, you could = have: "rsa-oaep" =3D=3D Default parameters {"name": "rsa-oaep", ...} =3D=3D Specified parameters Likewise, for symmetric algorithms, having the crypto parameters (IV, = nonce, etc.) in the AlgorithmIdentifier helps remove the ambiguities = that JWE/JWS currently have with regard to things like what happens if = an algorithm doesn't require an IV. --Richard On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: > Good catch. I'll add to the JWA spec that RSA-OAEP specifies the use = of OAEP padding with the default parameters defined by PKCS #1 v2.1 (RFC = 3447) in Section A.2.1. >=20 > -- Mike >=20 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 > Sent: Friday, June 29, 2012 10:20 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] Second compute JWE computation example >=20 > This seems underspecified. What parameters are you using for OAEP? = IIRC, it requires a digest algorithm and a masking generation function. = I don't see either of those specified in JWS or JWA. >=20 >=20 >=20 > On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >=20 >> Dear working group members, >>=20 >> A second complete JWE computation example is included below. As I'd = previously written, I'm adding example encryption computations to the = JWE spec to aid implementers. These values have been verified by two = independent implementations. >>=20 >> This example uses the header values: >> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>=20 >> This example verifies both the use of RSA-OAEP and the use of AES-GCM = - including the use of the Additional Authenticated Data parameter and = the Authentication Tag output. >>=20 >> Note that because the RSA-OAEP computation uses random values, the = encrypted key computation will not be repeatable, although all resulting = values will be decryptable to retrieve the original key value. >>=20 >> I'd be interested in hearing results from any of you who also try = this JWE with your implementation. >>=20 >> Enjoy, >> -- Mike >>=20 >> CMK (CEK) >> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,=20 >> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,=20= >> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77,=20= >> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,=20 >> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >> Header Bytes >> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80,=20= >> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, 34,=20= >> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, 85,=20= >> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMD >> RVM2IifQ >> BEGIN RSA KEY PARAMETERS >> Exponent >> [1, 0, 1] >> Modulus >> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30, = 135,=20 >> 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193, 62, 5,=20= >> 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161,=20= >> 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78, 93, 140,=20= >> 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35, 79, 210,=20= >> 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201, 63, 102,=20= >> 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231, 172, 31, = 227,=20 >> 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196, 17, 146, 10,=20 >> 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 233, 210, 101, = 236,=20 >> 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160, 76, 111, 234, = 71,=20 >> 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, 89, 244, 254, 107, = 84,=20 >> 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46, 151, 174, 12, 103,=20= >> 197, 181, 161, 162, 55, 250, 235, 123, 110, 17, 11, 158, 24, 47, 133,=20= >> 8, 199, 235, 107, 126, 130, 246, 73, 195, 20, 108, 202, 176, 214, = 187,=20 >> 45, 146, 182, 118, 54, 32, 200, 61, 201, 71, 243, 1, 255, 131, 84, = 37,=20 >> 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, 232, 36, 10, 230, = 248,=20 >> 190, 82, 182, 140, 35, 204, 108, 190, 253, 186, 186, 27] D (private=20= >> key exponent) [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, 66,=20= >> 73, 54, 16, 181, 233, 92, 54, 219, 101, 42, 35, 178, 63, 51, 43, 92,=20= >> 119, 136, 251, 41, 53, 23, 191, 164, 164, 60, 88, 227, 229, 152, 228,=20= >> 213, 149, 228, 169, 237, 104, 71, 151, 75, 88, 252, 216, 77, 251, = 231,=20 >> 28, 97, 88, 193, 215, 202, 248, 216, 121, 195, 211, 245, 250, 112, = 71,=20 >> 243, 61, 129, 95, 39, 244, 122, 225, 217, 169, 211, 165, 48, 253, = 220,=20 >> 59, 122, 219, 42, 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187,=20= >> 88, 176, 89, 24, 1, 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, = 64,=20 >> 194, 121, 182, 95, 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106,=20= >> 143, 121, 27, 72, 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112,=20= >> 183, 17, 200, 202, 31, 17, 138, 156, 184, 210, 157, 184, 154, 131,=20 >> 128, 110, 12, 85, 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, = 133,=20 >> 142, 220, 153, 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38,=20= >> 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126,=20= >> 43, 229, 69, 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171,=20= >> 143, 194, 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7,=20= >> 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201]=20= >> The remaining RSA key parameters are included for completeness, but=20= >> should not be needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116,=20= >> 169, 29, 109, 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206,=20= >> 78, 140, 34, 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189,=20= >> 129, 158, 74, 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241,=20= >> 75, 154, 69, 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213,=20= >> 195, 252, 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84,=20= >> 243, 110, 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170,=20 >> 215, 24, 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243,=20= >> 86, 144, 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ=20= >> [14, 173, 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, = 184,=20 >> 161, 13, 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, = 101,=20 >> 135, 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50,=20= >> 86, 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168,=20= >> 13, 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, = 209,=20 >> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37,=20= >> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, 250,=20= >> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,=20 >> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, 134,=20= >> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, 39,=20= >> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,=20 >> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201, = 186,=20 >> 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, 80, 174,=20= >> 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, 0, 235,=20= >> 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20, 184,=20 >> 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115, 199,=20= >> 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180, 163,=20 >> 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, 226, 236,=20= >> 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44, 184,=20= >> 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74, 3, 6,=20= >> 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178, 87, 174,=20= >> 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, 32, 4, 61,=20= >> 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151, 243, 47,=20= >> 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91, 168, 81,=20 >> 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, 183, 195, 35,=20= >> 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q [192, 182,=20= >> 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, 229, 123, 206,=20= >> 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 27, 134, 178,=20= >> 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, 160, 216, 85,=20= >> 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177, 167, 13, = 236,=20 >> 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, 162, 53, 162, 102,=20= >> 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 222, 32, 191, 17,=20= >> 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54, 69, 171, 84,=20= >> 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58, 241, 70, 71, = 190,=20 >> 215] END RSA KEY PARAMETERS Encrypted Key [142, 252, 40, 202, 21, = 177,=20 >> 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, 46, 214, 167, 116, 57, 20,=20= >> 164, 109, 150, 98, 49, 223, 154, 95, 71, 209, 233, 17, 174, 142, 203,=20= >> 232, 132, 167, 17, 42, 51, 125, 22, 221, 135, 17, 67, 197, 148, 246,=20= >> 139, 145, 160, 238, 99, 119, 171, 95, 117, 202, 87, 251, 101, 254, = 58,=20 >> 215, 135, 195, 135, 103, 49, 119, 76, 46, 49, 198, 27, 31, 58, 44,=20 >> 192, 222, 21, 16, 13, 216, 161, 179, 236, 65, 143, 38, 43, 218, 195,=20= >> 76, 140, 243, 71, 243, 79, 124, 216, 208, 242, 171, 34, 245, 57, 154,=20= >> 93, 76, 230, 204, 234, 82, 117, 248, 39, 13, 62, 60, 215, 8, 51, 248,=20= >> 254, 47, 150, 36, 46, 27, 247, 98, 77, 56, 92, 44, 19, 39, 12, 77, = 54,=20 >> 101, 194, 126, 86, 0, 64, 239, 95, 211, 64, 26, 219, 93, 211, 36, = 154,=20 >> 250, 117, 177, 213, 232, 142, 184, 216, 92, 20, 248, 69, 175, 180, = 71,=20 >> 205, 221, 235, 224, 95, 113, 5, 33, 86, 18, 157, 61, 199, 8, 121, 0,=20= >> 0, 135, 65, 67, 220, 164, 15, 230, 155, 71, 53, 64, 253, 209, 169,=20 >> 255, 34, 64, 101, 7, 43, 102, 227, 83, 171, 52, 225, 119, 253, 182,=20= >> 96, 195, 225, 34, 156, 211, 202, 7, 194, 255, 137, 59, 170, 172, 72,=20= >> 234, 222, 203, 123, 249, 121, 254, 143, 173, 105, 65, 187, 189, 163,=20= >> 64, 151, 145, 99, 17] Encoded Encrypted Key=20 >> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9o >> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY >> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa21 >> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJA >> ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >> Additional Authenticated Data >> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMD >> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3 >> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0y >> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQ >> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzV >> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjE >> Q >> Additional Authenticated Data Bytes >> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, = 116,=20 >> 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54,=20= >> 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74, 112,=20= >> 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85, 120, = 105,=20 >> 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81, 46, 106,=20= >> 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53, 99, 120,=20= >> 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75, 82, 116,=20= >> 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69, 97, 54, 79,=20= >> 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51, 89, 99, 82,=20= >> 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100, 54, 116, = 102,=20 >> 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72, 119, 52, 100, = 110,=20 >> 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54, 76, 77, 68, 101,=20= >> 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74, 105, 118, 97,=20 >> 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89, 48, 80, 75, 114,=20= >> 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122, 113, 85, 110, 88, = 52,=20 >> 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106, 45, 76, 53, 89, 107, = 76,=20 >> 104, 118, 51, 89, 107, 48, 52, 88, 67, 119, 84, 74, 119, 120, 78, 78,=20= >> 109, 88, 67, 102, 108, 89, 65, 81, 79, 57, 102, 48, 48, 65, 97, 50,=20= >> 49, 51, 84, 74, 74, 114, 54, 100, 98, 72, 86, 54, 73, 54, 52, 50, 70,=20= >> 119, 85, 45, 69, 87, 118, 116, 69, 102, 78, 51, 101, 118, 103, 88, = 51,=20 >> 69, 70, 73, 86, 89, 83, 110, 84, 51, 72, 67, 72, 107, 65, 65, 73, = 100,=20 >> 66, 81, 57, 121, 107, 68, 45, 97, 98, 82, 122, 86, 65, 95, 100, 71,=20= >> 112, 95, 121, 74, 65, 90, 81, 99, 114, 90, 117, 78, 84, 113, 122, 84,=20= >> 104, 100, 95, 50, 50, 89, 77, 80, 104, 73, 112, 122, 84, 121, 103,=20 >> 102, 67, 95, 52, 107, 55, 113, 113, 120, 73, 54, 116, 55, 76, 101, = 95,=20 >> 108, 53, 95, 111, 45, 116, 97, 85, 71, 55, 118, 97, 78, 65, 108, 53,=20= >> 70, 106, 69, 81] Ciphertext [253, 237, 181, 180, 97, 161, 105, 207,=20= >> 233, 120, 65, 100, 45, 122, 246, 116, 195, 212, 102, 37, 36, 175]=20 >> Encoded Ciphertext _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag=20= >> (Integrity Value) [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220,=20= >> 233, 68, 233, 114, 139] Encoded Authentication Tag (Encoded Integrity=20= >> Value) YbZSeHCNDZBqAdzpROlyiw JWE=20 >> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMDRVM2= IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9= ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY0PK= rIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa213TJJr6d= bHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzT= hd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ._e21tGGhac_peEFkLXr2dM= PUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jun 29 11:06: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 B532921F8822 for ; Fri, 29 Jun 2012 11:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGDLgwad6rVJ for ; Fri, 29 Jun 2012 11:06:05 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id EE66F21F8820 for ; Fri, 29 Jun 2012 11:06:04 -0700 (PDT) Received: from mail188-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 18:04:14 +0000 Received: from mail188-va3 (localhost [127.0.0.1]) by mail188-va3-R.bigfish.com (Postfix) with ESMTP id 87C8726040E; Fri, 29 Jun 2012 18:04:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz98dI9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail188-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=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail188-va3 (localhost.localdomain [127.0.0.1]) by mail188-va3 (MessageSwitch) id 1340993051601980_16847; Fri, 29 Jun 2012 18:04:11 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.253]) by mail188-va3.bigfish.com (Postfix) with ESMTP id 8FCD64A0045; Fri, 29 Jun 2012 18:04:11 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 18:04:08 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Fri, 29 Jun 2012 18:05:45 +0000 From: Mike Jones To: "Richard L. Barnes" Thread-Topic: Algorithm parameters (was Re: [jose] Second compute JWE computation example) Thread-Index: AQHNViDISpo4kuZmXk6CfhBJMEAyn5cRlXzQ Date: Fri, 29 Jun 2012 18:05:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> In-Reply-To: <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 18:06:09 -0000 As a design principle, the working group decided early on to specify small = sets of algorithm combinations that are actually deployed in the wild. Thi= s aids both interoperability and reduces implementation complexity. There is a way to specify parameters - registering new "alg" values in JWA = that specify new algorithms and/or parameter combinations. If your applica= tion needs different OAEP parameter choices than the defaults, then by all = means, make the case to the working group that that combination should be a= dded to the JWA spec. Best wishes, -- Mike -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Friday, June 29, 2012 10:58 AM To: Mike Jones Cc: jose@ietf.org Subject: Algorithm parameters (was Re: [jose] Second compute JWE computatio= n example) (Changed subject line to reflect topic change) Might be nice to have a way to specify the parameters, but fall back to the= default if the parameters are missing. =20 As an aside: This is why in JSMS all the crypto stuff gets bound up in the = AlgorithmIdentifier structure. Using that design pattern, you could have: "rsa-oaep" =3D=3D Default parameters {"name": "rsa-oaep", ...} =3D=3D Specified parameters Likewise, for symmetric algorithms, having the crypto parameters (IV, nonce= , etc.) in the AlgorithmIdentifier helps remove the ambiguities that JWE/JW= S currently have with regard to things like what happens if an algorithm do= esn't require an IV. --Richard On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: > Good catch. I'll add to the JWA spec that RSA-OAEP specifies the use of = OAEP padding with the default parameters defined by PKCS #1 v2.1 (RFC 3447)= in Section A.2.1. >=20 > -- Mike >=20 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Friday, June 29, 2012 10:20 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] Second compute JWE computation example >=20 > This seems underspecified. What parameters are you using for OAEP? IIRC= , it requires a digest algorithm and a masking generation function. I don'= t see either of those specified in JWS or JWA. >=20 >=20 >=20 > On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >=20 >> Dear working group members, >>=20 >> A second complete JWE computation example is included below. As I'd pre= viously written, I'm adding example encryption computations to the JWE spec= to aid implementers. These values have been verified by two independent i= mplementations. >>=20 >> This example uses the header values: >> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>=20 >> This example verifies both the use of RSA-OAEP and the use of AES-GCM - = including the use of the Additional Authenticated Data parameter and the Au= thentication Tag output. >>=20 >> Note that because the RSA-OAEP computation uses random values, the encry= pted key computation will not be repeatable, although all resulting values = will be decryptable to retrieve the original key value. >>=20 >> I'd be interested in hearing results from any of you who also try this J= WE with your implementation. >>=20 >> Enjoy, >> -- Mike >>=20 >> CMK (CEK) >> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,=20 >> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,=20 >> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77,=20 >> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,=20 >> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >> Header Bytes >> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80,=20 >> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, 34,=20 >> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, 85,=20 >> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >> eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >> D >> RVM2IifQ >> BEGIN RSA KEY PARAMETERS >> Exponent >> [1, 0, 1] >> Modulus >> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30,=20 >> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193,=20 >> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103,=20 >> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78,=20 >> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35,=20 >> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201,=20 >> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231,=20 >> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196,=20 >> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 233,=20 >> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160,=20 >> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, 89,=20 >> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46,=20 >> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, 17,=20 >> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, 20,=20 >> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, 71,=20 >> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, 197,=20 >> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190,=20 >> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, 62,=20 >> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219,=20 >> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191,=20 >> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, 104,=20 >> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, 202,=20 >> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39,=20 >> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42,=20 >> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, 1,=20 >> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, 95,=20 >> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72,=20 >> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, 202,=20 >> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85,=20 >> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, 153,=20 >> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, 17,=20 >> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, 69,=20 >> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, 11,=20 >> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, 91,=20 >> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The remaining=20 >> RSA key parameters are included for completeness, but should not be=20 >> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, 109,=20 >> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, 34,=20 >> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, 74,=20 >> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, 69,=20 >> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, 252,=20 >> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, 110,=20 >> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, 24,=20 >> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, 144,=20 >> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, 173,=20 >> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, 161, 13,=20 >> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, 135,=20 >> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, 86,=20 >> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, 13,=20 >> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209,=20 >> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37,=20 >> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, 250,=20 >> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,=20 >> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, 134,=20 >> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, 39,=20 >> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,=20 >> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201,=20 >> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, 80,=20 >> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, 0,=20 >> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20,=20 >> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115,=20 >> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180,=20 >> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, 226,=20 >> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44,=20 >> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74,=20 >> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178,=20 >> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, 32,=20 >> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151,=20 >> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91,=20 >> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, 183,=20 >> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q=20 >> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, 229,=20 >> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 27,=20 >> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, 160,=20 >> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177,=20 >> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, 162,=20 >> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 222,=20 >> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54,=20 >> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58,=20 >> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key [142,=20 >> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, 46,=20 >> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, 209,=20 >> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, 135,=20 >> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117,=20 >> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, 46,=20 >> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236,=20 >> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, 208,=20 >> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, 39,=20 >> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, 77,=20 >> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, 95,=20 >> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 142,=20 >> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, 113,=20 >> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 164, 15,=20 >> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, 102,=20 >> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 211,=20 >> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 249,=20 >> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 17]=20 >> Encoded Encrypted Key=20 >> jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >> o=20 >> uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >> Y >> 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >> 1=20 >> 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >> A ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >> Additional Authenticated Data >> eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >> D >> RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >> 3=20 >> YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >> y=20 >> M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >> Q=20 >> O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >> V=20 >> A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >> E >> Q >> Additional Authenticated Data Bytes >> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,=20 >> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73,=20 >> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74,=20 >> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85,=20 >> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81,=20 >> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53,=20 >> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75,=20 >> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69,=20 >> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51,=20 >> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100,=20 >> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72,=20 >> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54,=20 >> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74,=20 >> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89,=20 >> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122,=20 >> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106,=20 >> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, 119,=20 >> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, 57,=20 >> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, 72,=20 >> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, 102,=20 >> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, 51,=20 >> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, 97,=20 >> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, 99,=20 >> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, 80,=20 >> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, 113,=20 >> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, 85,=20 >> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext [253,=20 >> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 246,=20 >> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity Value)=20 >> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, 114,=20 >> 139] Encoded Authentication Tag (Encoded Integrity >> Value) YbZSeHCNDZBqAdzpROlyiw JWE >> eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >> DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >> W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >> w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >> lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >> abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Fri Jun 29 11:19: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 AC0D721F885B for ; Fri, 29 Jun 2012 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWSdpGTU1u6R for ; Fri, 29 Jun 2012 11:19:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AC04421F8820 for ; Fri, 29 Jun 2012 11:19:39 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:54498) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Skfn9-0002nW-66; Fri, 29 Jun 2012 14:19:39 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 29 Jun 2012 14:19:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 18:19:41 -0000 You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 Besides, requiring new tokens for different parameter sets doesn't = prevent algorithm proliferation, it just makes it a bigger hassle. If = the parameters are explicitly specified (with defaults), then to add a = new algorithm, my code just has to support the new algorithm -- the code = paths to invoke it don't need to change. With a "single-token" = approach, I have to write a whole new handler for every combination of = parameters. And that's simpler? And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. --Richard On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: > As a design principle, the working group decided early on to specify = small sets of algorithm combinations that are actually deployed in the = wild. This aids both interoperability and reduces implementation = complexity. >=20 > There is a way to specify parameters - registering new "alg" values in = JWA that specify new algorithms and/or parameter combinations. If your = application needs different OAEP parameter choices than the defaults, = then by all means, make the case to the working group that that = combination should be added to the JWA spec. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 > Sent: Friday, June 29, 2012 10:58 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >=20 > (Changed subject line to reflect topic change) >=20 > Might be nice to have a way to specify the parameters, but fall back = to the default if the parameters are missing. =20 >=20 > As an aside: This is why in JSMS all the crypto stuff gets bound up in = the AlgorithmIdentifier structure. Using that design pattern, you could = have: > "rsa-oaep" =3D=3D Default parameters > {"name": "rsa-oaep", ...} =3D=3D Specified parameters >=20 > Likewise, for symmetric algorithms, having the crypto parameters (IV, = nonce, etc.) in the AlgorithmIdentifier helps remove the ambiguities = that JWE/JWS currently have with regard to things like what happens if = an algorithm doesn't require an IV. >=20 > --Richard >=20 >=20 >=20 > On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >=20 >> Good catch. I'll add to the JWA spec that RSA-OAEP specifies the use = of OAEP padding with the default parameters defined by PKCS #1 v2.1 (RFC = 3447) in Section A.2.1. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >> Sent: Friday, June 29, 2012 10:20 AM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Re: [jose] Second compute JWE computation example >>=20 >> This seems underspecified. What parameters are you using for OAEP? = IIRC, it requires a digest algorithm and a masking generation function. = I don't see either of those specified in JWS or JWA. >>=20 >>=20 >>=20 >> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>=20 >>> Dear working group members, >>>=20 >>> A second complete JWE computation example is included below. As I'd = previously written, I'm adding example encryption computations to the = JWE spec to aid implementers. These values have been verified by two = independent implementations. >>>=20 >>> This example uses the header values: >>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>=20 >>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>=20 >>> Note that because the RSA-OAEP computation uses random values, the = encrypted key computation will not be repeatable, although all resulting = values will be decryptable to retrieve the original key value. >>>=20 >>> I'd be interested in hearing results from any of you who also try = this JWE with your implementation. >>>=20 >>> Enjoy, >>> -- Mike >>>=20 >>> CMK (CEK) >>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,=20= >>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,=20= >>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77,=20= >>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,=20= >>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>> Header Bytes >>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80,=20= >>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, = 34,=20 >>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, = 85,=20 >>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>> D >>> RVM2IifQ >>> BEGIN RSA KEY PARAMETERS >>> Exponent >>> [1, 0, 1] >>> Modulus >>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30,=20 >>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193,=20= >>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103,=20= >>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78,=20= >>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, = 35,=20 >>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201,=20= >>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231,=20 >>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196,=20= >>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 233,=20= >>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160,=20= >>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, = 89,=20 >>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46,=20= >>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, 17,=20= >>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, 20,=20= >>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, = 71,=20 >>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, 197,=20= >>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190,=20 >>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, 62,=20= >>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219,=20 >>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191,=20 >>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, 104,=20= >>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, 202,=20= >>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39,=20 >>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42,=20= >>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, = 1,=20 >>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, = 95,=20 >>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72,=20= >>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, = 202,=20 >>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85,=20 >>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, 153,=20= >>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, 17,=20= >>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, 69,=20= >>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, = 11,=20 >>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, 91,=20= >>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>> RSA key parameters are included for completeness, but should not be=20= >>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, 109,=20= >>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, 34,=20= >>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, 74,=20= >>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, 69,=20= >>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, 252,=20 >>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, 110,=20= >>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, 24,=20 >>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, = 144,=20 >>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, 173,=20= >>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, 161, = 13,=20 >>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, 135,=20= >>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, 86,=20= >>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, 13,=20= >>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209,=20= >>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37,=20= >>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, = 250,=20 >>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,=20= >>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, = 134,=20 >>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, 39,=20= >>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,=20= >>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201,=20 >>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, = 80,=20 >>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, 0,=20= >>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20,=20= >>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115,=20= >>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180,=20= >>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, 226,=20= >>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44,=20= >>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74,=20= >>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178,=20= >>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, = 32,=20 >>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151,=20= >>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91,=20= >>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, = 183,=20 >>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q=20= >>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, = 229,=20 >>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 27,=20= >>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, = 160,=20 >>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177,=20 >>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, = 162,=20 >>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, = 222,=20 >>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54,=20= >>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58,=20 >>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key [142,=20 >>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, = 46,=20 >>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, 209,=20= >>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, = 135,=20 >>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117,=20 >>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, = 46,=20 >>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236,=20= >>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, 208,=20= >>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, 39,=20= >>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, 77,=20= >>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, 95,=20= >>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 142,=20 >>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, = 113,=20 >>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 164, = 15,=20 >>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, 102,=20= >>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 211,=20 >>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 249,=20 >>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 17]=20 >>> Encoded Encrypted Key=20 >>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>> o=20 >>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>> Y >>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>> 1=20 >>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>> A ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>> Additional Authenticated Data >>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>> D >>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>> 3=20 >>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>> y=20 >>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>> Q=20 >>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>> V=20 >>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>> E >>> Q >>> Additional Authenticated Data Bytes >>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,=20 >>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73,=20= >>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74,=20= >>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85,=20 >>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81,=20= >>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53,=20= >>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75,=20= >>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69,=20= >>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51,=20= >>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100,=20= >>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72,=20 >>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, = 54,=20 >>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, = 74,=20 >>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89,=20= >>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122,=20 >>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106,=20= >>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, 119,=20= >>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, 57,=20= >>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, 72,=20= >>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, 102,=20= >>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, 51,=20= >>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, 97,=20= >>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, 99,=20= >>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, = 80,=20 >>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, 113,=20= >>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, = 85,=20 >>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext [253,=20= >>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 246,=20= >>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity Value)=20= >>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, = 114,=20 >>> 139] Encoded Authentication Tag (Encoded Integrity >>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 From ve7jtb@ve7jtb.com Fri Jun 29 11:41: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 630A821F884E for ; Fri, 29 Jun 2012 11:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl0aEAUAnmNx for ; Fri, 29 Jun 2012 11:41:06 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8046D21F8844 for ; Fri, 29 Jun 2012 11:41:06 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3382992ggn.31 for ; Fri, 29 Jun 2012 11:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=tmt7MposArquzIzeWwM8seGH2R9fJhyBMyKI5zeGpB4=; b=IB0Re8JdhnUfz8wrANb5sqIl95YNUY/TiYlz78u4+YdqFu1LMfx9MbVZuzXs4uWOqm 2BLGBuBMMA75DiAm0C4u2CbDtqhQOjvV+rGHbmKb7s1MK3/l7d9V5cxoBqZroDgwTi1l IK4mEfaFljyUMZUHk6NoAKNhz5ldRbluc/89qpCMvI2pkeDEEkNXa53JnuK4NnThtwqJ 2XcNTV6WPFDw/OsoGdaFGVnwF/zC710rIjdeolqPjLPS+ypdUTf9bzEh6lWMCNi6U6yE u3HalSLlGuJMPaok5kBJRISV8goNvhqMzTOHUhoQR9xHfNsOW8Vo3T+GhF/ejdEdpCCB GuFw== Received: by 10.236.79.67 with SMTP id h43mr4415736yhe.122.1340995266004; Fri, 29 Jun 2012 11:41:06 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id a34sm7483982yhh.0.2012.06.29.11.41.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 11:41:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8D96286A-736F-4865-8665-2503B216478B"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> Date: Fri, 29 Jun 2012 14:40:56 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlo9SUExK800iS2aTKNugpD2cXUvUNXlLGIMAHBThKiWgK4LBx3G+2hmkJk5yXXYGhvsBG4 Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 18:41:08 -0000 --Apple-Mail=_8D96286A-736F-4865-8665-2503B216478B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think that you are both recommending the same thing, but not agreeing = somehow. Having large numbers of sub parameters that can be individually = specified, is a mess for interoperability and testing. If there is a reason to change a sub parameter then a new composite lag = can be specified in JWA. John B.=20 On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: > You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 >=20 > Besides, requiring new tokens for different parameter sets doesn't = prevent algorithm proliferation, it just makes it a bigger hassle. If = the parameters are explicitly specified (with defaults), then to add a = new algorithm, my code just has to support the new algorithm -- the code = paths to invoke it don't need to change. With a "single-token" = approach, I have to write a whole new handler for every combination of = parameters. And that's simpler? >=20 > And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 > On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >=20 >> As a design principle, the working group decided early on to specify = small sets of algorithm combinations that are actually deployed in the = wild. This aids both interoperability and reduces implementation = complexity. >>=20 >> There is a way to specify parameters - registering new "alg" values = in JWA that specify new algorithms and/or parameter combinations. If = your application needs different OAEP parameter choices than the = defaults, then by all means, make the case to the working group that = that combination should be added to the JWA spec. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >> Sent: Friday, June 29, 2012 10:58 AM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >>=20 >> (Changed subject line to reflect topic change) >>=20 >> Might be nice to have a way to specify the parameters, but fall back = to the default if the parameters are missing. =20 >>=20 >> As an aside: This is why in JSMS all the crypto stuff gets bound up = in the AlgorithmIdentifier structure. Using that design pattern, you = could have: >> "rsa-oaep" =3D=3D Default parameters >> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>=20 >> Likewise, for symmetric algorithms, having the crypto parameters (IV, = nonce, etc.) in the AlgorithmIdentifier helps remove the ambiguities = that JWE/JWS currently have with regard to things like what happens if = an algorithm doesn't require an IV. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>=20 >>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies the = use of OAEP padding with the default parameters defined by PKCS #1 v2.1 = (RFC 3447) in Section A.2.1. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>> Sent: Friday, June 29, 2012 10:20 AM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Re: [jose] Second compute JWE computation example >>>=20 >>> This seems underspecified. What parameters are you using for OAEP? = IIRC, it requires a digest algorithm and a masking generation function. = I don't see either of those specified in JWS or JWA. >>>=20 >>>=20 >>>=20 >>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>=20 >>>> Dear working group members, >>>>=20 >>>> A second complete JWE computation example is included below. As = I'd previously written, I'm adding example encryption computations to = the JWE spec to aid implementers. These values have been verified by = two independent implementations. >>>>=20 >>>> This example uses the header values: >>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>=20 >>>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>>=20 >>>> Note that because the RSA-OAEP computation uses random values, the = encrypted key computation will not be repeatable, although all resulting = values will be decryptable to retrieve the original key value. >>>>=20 >>>> I'd be interested in hearing results from any of you who also try = this JWE with your implementation. >>>>=20 >>>> Enjoy, >>>> -- Mike >>>>=20 >>>> CMK (CEK) >>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,=20= >>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,=20= >>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, = 77,=20 >>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,=20= >>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>> Header Bytes >>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80,=20= >>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, = 34,=20 >>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, = 85,=20 >>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>> D >>>> RVM2IifQ >>>> BEGIN RSA KEY PARAMETERS >>>> Exponent >>>> [1, 0, 1] >>>> Modulus >>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30,=20= >>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193,=20= >>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, = 103,=20 >>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78,=20= >>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, = 35,=20 >>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201,=20= >>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231,=20= >>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196,=20= >>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, = 233,=20 >>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160,=20= >>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, = 89,=20 >>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46,=20= >>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, 17,=20= >>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, 20,=20= >>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, = 71,=20 >>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, = 197,=20 >>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190,=20= >>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, 62,=20= >>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219,=20= >>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191,=20= >>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, 104,=20= >>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, 202,=20= >>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39,=20= >>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42,=20= >>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, = 1,=20 >>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, = 95,=20 >>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72,=20= >>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, = 202,=20 >>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85,=20= >>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, 153,=20= >>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, = 17,=20 >>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, = 69,=20 >>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, = 11,=20 >>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, = 91,=20 >>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>>> RSA key parameters are included for completeness, but should not be=20= >>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, 109,=20= >>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, 34,=20= >>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, = 74,=20 >>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, 69,=20= >>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, 252,=20= >>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, = 110,=20 >>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, 24,=20= >>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, = 144,=20 >>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, = 173,=20 >>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, 161, = 13,=20 >>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, 135,=20= >>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, = 86,=20 >>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, 13,=20= >>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209,=20= >>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37,=20= >>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, = 250,=20 >>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,=20= >>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, = 134,=20 >>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, = 39,=20 >>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,=20= >>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201,=20= >>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, = 80,=20 >>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, = 0,=20 >>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20,=20= >>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, = 115,=20 >>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180,=20= >>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, = 226,=20 >>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44,=20= >>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74,=20= >>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178,=20= >>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, = 32,=20 >>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151,=20= >>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91,=20= >>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, = 183,=20 >>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q=20= >>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, = 229,=20 >>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, = 27,=20 >>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, = 160,=20 >>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177,=20= >>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, = 162,=20 >>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, = 222,=20 >>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, = 54,=20 >>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58,=20= >>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key [142,=20= >>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, = 46,=20 >>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, = 209,=20 >>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, = 135,=20 >>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117,=20= >>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, = 46,=20 >>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236,=20= >>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, = 208,=20 >>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, = 39,=20 >>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, 77,=20= >>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, 95,=20= >>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 142,=20= >>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, = 113,=20 >>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 164, = 15,=20 >>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, 102,=20= >>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 211,=20= >>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 249,=20= >>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 17]=20= >>>> Encoded Encrypted Key=20 >>>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>>> o=20 >>>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>>> Y >>>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>>> 1=20 >>>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>>> A ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>> Additional Authenticated Data >>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>> D >>>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>>> 3=20 >>>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>>> y=20 >>>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>>> Q=20 >>>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>>> V=20 >>>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>>> E >>>> Q >>>> Additional Authenticated Data Bytes >>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,=20= >>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, = 73,=20 >>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74,=20= >>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85,=20= >>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, = 81,=20 >>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53,=20= >>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75,=20= >>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69,=20= >>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, = 51,=20 >>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, = 100,=20 >>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72,=20= >>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, = 54,=20 >>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, = 74,=20 >>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89,=20= >>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122,=20= >>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106,=20= >>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, = 119,=20 >>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, = 57,=20 >>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, 72,=20= >>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, 102,=20= >>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, 51,=20= >>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, 97,=20= >>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, 99,=20= >>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, = 80,=20 >>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, = 113,=20 >>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, = 85,=20 >>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext [253,=20= >>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 246,=20= >>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity Value)=20= >>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, = 114,=20 >>>> 139] Encoded Authentication Tag (Encoded Integrity >>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_8D96286A-736F-4865-8665-2503B216478B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTE4NDA1N1owIwYJKoZIhvcNAQkEMRYEFAbjYplvciwlSGWeiZ3NaTWpGxaOMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AI9HrOMgcft/avv0A23j/bqdEn6xd7jiP/SEZ0MyItShMPieqOdDcZdwkzN3ri9UKzeWNhDM5WDP pkweQGeaVDi0CyFWp6/VWorAfel0JR+nQlD+qw/o/2EqmUQo9xEqehb+OBrnhf9anIERassdjxo4 P6IbcHyWP00r8TG0tGdyvJTnq87yaV6EZsyfFWVOzOtzsmU45oLaY0ghTGx1rJd9Q4Evv6RbktcY f9O4GdlYwzdERQzumT0zhBWw9pLw5TFKohcYltHK1SLoqNeQTNs0yrn8kk701lq+pPBm15D9XPR8 nzMzgxrrBxnOfB7qX4HbjcqPps/sSyvBumPnm0kAAAAAAAA= --Apple-Mail=_8D96286A-736F-4865-8665-2503B216478B-- From rbarnes@bbn.com Fri Jun 29 12:04: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 452E621F889F for ; Fri, 29 Jun 2012 12:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K94L8rq2Ellw for ; Fri, 29 Jun 2012 12:04:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF7421F889E for ; Fri, 29 Jun 2012 12:04:33 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:54635) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkgUX-0003e3-IG; Fri, 29 Jun 2012 15:04:29 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 29 Jun 2012 15:04:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 19:04:35 -0000 No, I think we actually disagree :) I'm saying that disallowing the specification of parameters makes = extensibility much harder. Let's do some side-by-side comparisons: In terms of pseudo-code: -----BEGIN-WithParams----- alg =3D JSON.parse('{"name":"rsa-oaep", "hash": "foo", "mgf": "bar"}') hash =3D default_hash mgf =3D default_mgf if (alg instanceof Object): hash =3D Crypto.algorithmByName(alg["hash"]) mgf =3D Crypto.algorithmByName(alg["mgf"]) -----END-WithParams----- -----BEGIN-WithoutParams----- alg =3D "rsa-oaep-foo-bar" ### Table of sub-algorithms for every known combination (hash, mgf) =3D Crypto.subAlgorithmsByName(alg) -----END-WithoutParams----- In terms of keeping state: With parameters: I have to keep a table of cryptographic primitives. Without parameters: I have to keep a table of all the possible = combinations that are allowed. =20 In terms of adding a new sub-algorithm combination: With parameters: Just allow it. The code doesn't have to change. With parameters: Every implementation has to update their registry. Don't overestimate the interoperability problems. Allowing parameters = to be specified doesn't prevent combinatorial growth. Just look at the = TLS ciphersuite registry: = In either case, you can limit the proliferation by policy, instead of by = protocol. --Richard On Jun 29, 2012, at 2:40 PM, John Bradley wrote: > I think that you are both recommending the same thing, but not = agreeing somehow. >=20 > Having large numbers of sub parameters that can be individually = specified, is a mess for interoperability and testing. >=20 > If there is a reason to change a sub parameter then a new composite = lag can be specified in JWA. >=20 > John B.=20 > On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: >=20 >> You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 >>=20 >> Besides, requiring new tokens for different parameter sets doesn't = prevent algorithm proliferation, it just makes it a bigger hassle. If = the parameters are explicitly specified (with defaults), then to add a = new algorithm, my code just has to support the new algorithm -- the code = paths to invoke it don't need to change. With a "single-token" = approach, I have to write a whole new handler for every combination of = parameters. And that's simpler? >>=20 >> And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >>=20 >>> As a design principle, the working group decided early on to specify = small sets of algorithm combinations that are actually deployed in the = wild. This aids both interoperability and reduces implementation = complexity. >>>=20 >>> There is a way to specify parameters - registering new "alg" values = in JWA that specify new algorithms and/or parameter combinations. If = your application needs different OAEP parameter choices than the = defaults, then by all means, make the case to the working group that = that combination should be added to the JWA spec. >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>> Sent: Friday, June 29, 2012 10:58 AM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >>>=20 >>> (Changed subject line to reflect topic change) >>>=20 >>> Might be nice to have a way to specify the parameters, but fall back = to the default if the parameters are missing. =20 >>>=20 >>> As an aside: This is why in JSMS all the crypto stuff gets bound up = in the AlgorithmIdentifier structure. Using that design pattern, you = could have: >>> "rsa-oaep" =3D=3D Default parameters >>> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>>=20 >>> Likewise, for symmetric algorithms, having the crypto parameters = (IV, nonce, etc.) in the AlgorithmIdentifier helps remove the = ambiguities that JWE/JWS currently have with regard to things like what = happens if an algorithm doesn't require an IV. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>>=20 >>>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies the = use of OAEP padding with the default parameters defined by PKCS #1 v2.1 = (RFC 3447) in Section A.2.1. >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Friday, June 29, 2012 10:20 AM >>>> To: Mike Jones >>>> Cc: jose@ietf.org >>>> Subject: Re: [jose] Second compute JWE computation example >>>>=20 >>>> This seems underspecified. What parameters are you using for OAEP? = IIRC, it requires a digest algorithm and a masking generation function. = I don't see either of those specified in JWS or JWA. >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>>=20 >>>>> Dear working group members, >>>>>=20 >>>>> A second complete JWE computation example is included below. As = I'd previously written, I'm adding example encryption computations to = the JWE spec to aid implementers. These values have been verified by = two independent implementations. >>>>>=20 >>>>> This example uses the header values: >>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>=20 >>>>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>>>=20 >>>>> Note that because the RSA-OAEP computation uses random values, the = encrypted key computation will not be repeatable, although all resulting = values will be decryptable to retrieve the original key value. >>>>>=20 >>>>> I'd be interested in hearing results from any of you who also try = this JWE with your implementation. >>>>>=20 >>>>> Enjoy, >>>>> -- Mike >>>>>=20 >>>>> CMK (CEK) >>>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,=20= >>>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, = 122,=20 >>>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, = 77,=20 >>>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,=20= >>>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>> Header Bytes >>>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, = 80,=20 >>>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, = 34,=20 >>>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, = 85,=20 >>>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>> D >>>>> RVM2IifQ >>>>> BEGIN RSA KEY PARAMETERS >>>>> Exponent >>>>> [1, 0, 1] >>>>> Modulus >>>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30,=20= >>>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, = 193,=20 >>>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, = 103,=20 >>>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78,=20= >>>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, = 35,=20 >>>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, = 201,=20 >>>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231,=20= >>>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, = 196,=20 >>>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, = 233,=20 >>>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, = 160,=20 >>>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, = 89,=20 >>>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, = 46,=20 >>>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, 17,=20= >>>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, = 20,=20 >>>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, = 71,=20 >>>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, = 197,=20 >>>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190,=20= >>>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, = 62,=20 >>>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219,=20= >>>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191,=20= >>>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, = 104,=20 >>>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, = 202,=20 >>>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39,=20= >>>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42,=20= >>>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, = 1,=20 >>>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, = 95,=20 >>>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, = 72,=20 >>>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, = 202,=20 >>>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85,=20= >>>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, = 153,=20 >>>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, = 17,=20 >>>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, = 69,=20 >>>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, = 11,=20 >>>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, = 91,=20 >>>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>>>> RSA key parameters are included for completeness, but should not = be=20 >>>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, = 109,=20 >>>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, = 34,=20 >>>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, = 74,=20 >>>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, = 69,=20 >>>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, 252,=20= >>>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, = 110,=20 >>>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, 24,=20= >>>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, = 144,=20 >>>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, = 173,=20 >>>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, 161, = 13,=20 >>>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, 135,=20= >>>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, = 86,=20 >>>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, = 13,=20 >>>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209,=20= >>>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, = 37,=20 >>>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, = 250,=20 >>>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,=20= >>>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, = 134,=20 >>>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, = 39,=20 >>>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,=20= >>>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201,=20= >>>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, = 80,=20 >>>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, = 0,=20 >>>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20,=20= >>>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, = 115,=20 >>>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180,=20= >>>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, = 226,=20 >>>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, = 44,=20 >>>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, = 74,=20 >>>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178,=20= >>>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, = 32,=20 >>>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151,=20= >>>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91,=20= >>>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, = 183,=20 >>>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q=20= >>>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, = 229,=20 >>>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, = 27,=20 >>>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, = 160,=20 >>>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177,=20= >>>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, = 162,=20 >>>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, = 222,=20 >>>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, = 54,=20 >>>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58,=20= >>>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key [142,=20= >>>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, = 46,=20 >>>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, = 209,=20 >>>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, = 135,=20 >>>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117,=20= >>>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, = 46,=20 >>>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236,=20= >>>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, = 208,=20 >>>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, = 39,=20 >>>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, = 77,=20 >>>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, 95,=20= >>>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 142,=20= >>>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, = 113,=20 >>>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 164, = 15,=20 >>>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, 102,=20= >>>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 211,=20= >>>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 249,=20= >>>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 17]=20= >>>>> Encoded Encrypted Key=20 >>>>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>>>> o=20 >>>>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>>>> Y >>>>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>>>> 1=20 >>>>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>>>> A ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>>> Additional Authenticated Data >>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>> D >>>>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>>>> 3=20 >>>>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>>>> y=20 >>>>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>>>> Q=20 >>>>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>>>> V=20 >>>>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>>>> E >>>>> Q >>>>> Additional Authenticated Data Bytes >>>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,=20= >>>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, = 73,=20 >>>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74,=20= >>>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85,=20= >>>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, = 81,=20 >>>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, = 53,=20 >>>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, = 75,=20 >>>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69,=20= >>>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, = 51,=20 >>>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, = 100,=20 >>>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72,=20= >>>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, = 54,=20 >>>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, = 74,=20 >>>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89,=20= >>>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122,=20= >>>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, = 106,=20 >>>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, = 119,=20 >>>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, = 57,=20 >>>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, 72,=20= >>>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, = 102,=20 >>>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, = 51,=20 >>>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, = 97,=20 >>>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, = 99,=20 >>>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, = 80,=20 >>>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, = 113,=20 >>>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, = 85,=20 >>>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext = [253,=20 >>>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 246,=20= >>>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity = Value)=20 >>>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, = 114,=20 >>>>> 139] Encoded Authentication Tag (Encoded Integrity >>>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>>>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>>>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>>>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>>>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Fri Jun 29 12:55: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 C451821F88C0 for ; Fri, 29 Jun 2012 12:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC-Pu7X5sMi5 for ; Fri, 29 Jun 2012 12:55:12 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8C6621F88BD for ; Fri, 29 Jun 2012 12:55:11 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3479799ghb.31 for ; Fri, 29 Jun 2012 12:55:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=60Ll2uCEnBvf+MugCQ7YRpGqd+A1fSl59tDk6bPwf8A=; b=P0/eskyCr21Tbqt3FQtJew6Rq+e2kFXtzgibCNMvCamgz7+o5q4fTSZ8sxojyGR7NN ZWGqoGEhK/h2L7mcQ2dKtTAdX09v/sBRuHFBffhTnsmWz5JmDFiFpJ3BecHf4kNBFMZU x7UMEPjv0dSXNbRyqidlBtjcKtWr0rBSFJH74qUmjmUkPV2ZK/iPdQ+sLtQeTIt5lhAu 63CocDZ7k9766dbKOTgsv9g+izVxPG0abqIyO2nVeWa4G8yGIEVRpClX2ZQn2kNAekdF cveWdPU0Tch2L0+yA5Njl7aUASX4/L2zzAdtH7stI5nbKAOA+uu+A5jWG1rad1hypm4y YWVw== Received: by 10.236.187.2 with SMTP id x2mr4945202yhm.42.1340999705847; Fri, 29 Jun 2012 12:55:05 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id f68sm7889072yhh.22.2012.06.29.12.55.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 12:55:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_5A9FD851-A37E-4C20-A2D7-E1C343DFA46D"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> Date: Fri, 29 Jun 2012 15:54:56 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnx7n8AeScVvo9grROJ6s9iy9nCkfCqtw2LucFQEC5VOA67lGIE2zUpPblCUC9sUDfG95EA Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 19:55:13 -0000 --Apple-Mail=_5A9FD851-A37E-4C20-A2D7-E1C343DFA46D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I don't think we are trying to preclude parameters for new algorithms. The question is if for the core ones we have to define configurable = parameters for all possible parameters or if it is OK=20 to have a lag that specifies a fixed set of parameters and requires no = options. They are not necessarily mutually exclusive. John B. On 2012-06-29, at 3:04 PM, Richard L. Barnes wrote: > No, I think we actually disagree :) >=20 > I'm saying that disallowing the specification of parameters makes = extensibility much harder. Let's do some side-by-side comparisons: >=20 > In terms of pseudo-code: > -----BEGIN-WithParams----- > alg =3D JSON.parse('{"name":"rsa-oaep", "hash": "foo", "mgf": "bar"}') > hash =3D default_hash > mgf =3D default_mgf > if (alg instanceof Object): > hash =3D Crypto.algorithmByName(alg["hash"]) > mgf =3D Crypto.algorithmByName(alg["mgf"]) > -----END-WithParams----- >=20 > -----BEGIN-WithoutParams----- > alg =3D "rsa-oaep-foo-bar" > ### Table of sub-algorithms for every known combination > (hash, mgf) =3D Crypto.subAlgorithmsByName(alg) > -----END-WithoutParams----- >=20 > In terms of keeping state: > With parameters: I have to keep a table of cryptographic primitives. > Without parameters: I have to keep a table of all the possible = combinations that are allowed. =20 >=20 > In terms of adding a new sub-algorithm combination: > With parameters: Just allow it. The code doesn't have to change. > With parameters: Every implementation has to update their registry. >=20 > Don't overestimate the interoperability problems. Allowing parameters = to be specified doesn't prevent combinatorial growth. Just look at the = TLS ciphersuite registry: > = > In either case, you can limit the proliferation by policy, instead of = by protocol. >=20 > --Richard >=20 >=20 >=20 > On Jun 29, 2012, at 2:40 PM, John Bradley wrote: >=20 >> I think that you are both recommending the same thing, but not = agreeing somehow. >>=20 >> Having large numbers of sub parameters that can be individually = specified, is a mess for interoperability and testing. >>=20 >> If there is a reason to change a sub parameter then a new composite = lag can be specified in JWA. >>=20 >> John B.=20 >> On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: >>=20 >>> You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 >>>=20 >>> Besides, requiring new tokens for different parameter sets doesn't = prevent algorithm proliferation, it just makes it a bigger hassle. If = the parameters are explicitly specified (with defaults), then to add a = new algorithm, my code just has to support the new algorithm -- the code = paths to invoke it don't need to change. With a "single-token" = approach, I have to write a whole new handler for every combination of = parameters. And that's simpler? >>>=20 >>> And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >>>=20 >>>> As a design principle, the working group decided early on to = specify small sets of algorithm combinations that are actually deployed = in the wild. This aids both interoperability and reduces implementation = complexity. >>>>=20 >>>> There is a way to specify parameters - registering new "alg" values = in JWA that specify new algorithms and/or parameter combinations. If = your application needs different OAEP parameter choices than the = defaults, then by all means, make the case to the working group that = that combination should be added to the JWA spec. >>>>=20 >>>> Best wishes, >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>>> Sent: Friday, June 29, 2012 10:58 AM >>>> To: Mike Jones >>>> Cc: jose@ietf.org >>>> Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >>>>=20 >>>> (Changed subject line to reflect topic change) >>>>=20 >>>> Might be nice to have a way to specify the parameters, but fall = back to the default if the parameters are missing. =20 >>>>=20 >>>> As an aside: This is why in JSMS all the crypto stuff gets bound up = in the AlgorithmIdentifier structure. Using that design pattern, you = could have: >>>> "rsa-oaep" =3D=3D Default parameters >>>> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>>>=20 >>>> Likewise, for symmetric algorithms, having the crypto parameters = (IV, nonce, etc.) in the AlgorithmIdentifier helps remove the = ambiguities that JWE/JWS currently have with regard to things like what = happens if an algorithm doesn't require an IV. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>>>=20 >>>>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies the = use of OAEP padding with the default parameters defined by PKCS #1 v2.1 = (RFC 3447) in Section A.2.1. >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: Friday, June 29, 2012 10:20 AM >>>>> To: Mike Jones >>>>> Cc: jose@ietf.org >>>>> Subject: Re: [jose] Second compute JWE computation example >>>>>=20 >>>>> This seems underspecified. What parameters are you using for = OAEP? IIRC, it requires a digest algorithm and a masking generation = function. I don't see either of those specified in JWS or JWA. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>>>=20 >>>>>> Dear working group members, >>>>>>=20 >>>>>> A second complete JWE computation example is included below. As = I'd previously written, I'm adding example encryption computations to = the JWE spec to aid implementers. These values have been verified by = two independent implementations. >>>>>>=20 >>>>>> This example uses the header values: >>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>=20 >>>>>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>>>>=20 >>>>>> Note that because the RSA-OAEP computation uses random values, = the encrypted key computation will not be repeatable, although all = resulting values will be decryptable to retrieve the original key value. >>>>>>=20 >>>>>> I'd be interested in hearing results from any of you who also try = this JWE with your implementation. >>>>>>=20 >>>>>> Enjoy, >>>>>> -- Mike >>>>>>=20 >>>>>> CMK (CEK) >>>>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, = 154,=20 >>>>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, = 122,=20 >>>>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, = 77,=20 >>>>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, = 97,=20 >>>>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>> Header Bytes >>>>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, = 80,=20 >>>>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, = 34,=20 >>>>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, = 85,=20 >>>>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>> D >>>>>> RVM2IifQ >>>>>> BEGIN RSA KEY PARAMETERS >>>>>> Exponent >>>>>> [1, 0, 1] >>>>>> Modulus >>>>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30,=20= >>>>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, = 193,=20 >>>>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, = 103,=20 >>>>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, = 78,=20 >>>>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, = 35,=20 >>>>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, = 201,=20 >>>>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231,=20= >>>>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, = 196,=20 >>>>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, = 233,=20 >>>>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, = 160,=20 >>>>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, = 89,=20 >>>>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, = 46,=20 >>>>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, = 17,=20 >>>>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, = 20,=20 >>>>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, = 71,=20 >>>>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, = 197,=20 >>>>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190,=20= >>>>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, = 62,=20 >>>>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219,=20= >>>>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191,=20= >>>>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, = 104,=20 >>>>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, = 202,=20 >>>>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39,=20= >>>>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, = 42,=20 >>>>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, = 24, 1,=20 >>>>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, = 95,=20 >>>>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, = 72,=20 >>>>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, = 202,=20 >>>>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85,=20= >>>>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, = 153,=20 >>>>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, = 17,=20 >>>>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, = 69,=20 >>>>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, = 11,=20 >>>>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, = 91,=20 >>>>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>>>>> RSA key parameters are included for completeness, but should not = be=20 >>>>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, = 109,=20 >>>>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, = 34,=20 >>>>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, = 74,=20 >>>>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, = 69,=20 >>>>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, 252,=20= >>>>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, = 110,=20 >>>>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, 24,=20= >>>>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, = 144,=20 >>>>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, = 173,=20 >>>>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, 161, = 13,=20 >>>>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, = 135,=20 >>>>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, = 86,=20 >>>>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, = 13,=20 >>>>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, = 209,=20 >>>>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, = 37,=20 >>>>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, = 250,=20 >>>>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, = 49,=20 >>>>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, = 134,=20 >>>>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, = 39,=20 >>>>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, = 173,=20 >>>>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201,=20= >>>>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, = 80,=20 >>>>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, = 0,=20 >>>>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, = 20,=20 >>>>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, = 115,=20 >>>>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, = 180,=20 >>>>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, = 226,=20 >>>>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, = 44,=20 >>>>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, = 74,=20 >>>>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, = 178,=20 >>>>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, = 32,=20 >>>>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, = 151,=20 >>>>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, = 91,=20 >>>>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, = 183,=20 >>>>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] = Q=20 >>>>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, = 229,=20 >>>>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, = 27,=20 >>>>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, = 160,=20 >>>>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177,=20= >>>>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, = 162,=20 >>>>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, = 222,=20 >>>>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, = 54,=20 >>>>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58,=20= >>>>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key [142,=20= >>>>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, = 46,=20 >>>>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, = 209,=20 >>>>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, = 135,=20 >>>>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117,=20= >>>>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, = 46,=20 >>>>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, = 236,=20 >>>>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, = 208,=20 >>>>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, = 39,=20 >>>>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, = 77,=20 >>>>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, = 95,=20 >>>>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 142,=20= >>>>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, = 113,=20 >>>>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 164, = 15,=20 >>>>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, = 102,=20 >>>>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 211,=20= >>>>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 249,=20= >>>>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 17]=20= >>>>>> Encoded Encrypted Key=20 >>>>>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>>>>> o=20 >>>>>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>>>>> Y >>>>>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>>>>> 1=20 >>>>>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>>>>> A ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>>>> Additional Authenticated Data >>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>> D >>>>>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>>>>> 3=20 >>>>>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>>>>> y=20 >>>>>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>>>>> Q=20 >>>>>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>>>>> V=20 >>>>>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>>>>> E >>>>>> Q >>>>>> Additional Authenticated Data Bytes >>>>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,=20= >>>>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, = 73,=20 >>>>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, = 74,=20 >>>>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85,=20= >>>>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, = 81,=20 >>>>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, = 53,=20 >>>>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, = 75,=20 >>>>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, = 69,=20 >>>>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, = 51,=20 >>>>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, = 100,=20 >>>>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72,=20= >>>>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, = 54,=20 >>>>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, = 74,=20 >>>>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, = 89,=20 >>>>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122,=20= >>>>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, = 106,=20 >>>>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, = 119,=20 >>>>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, = 57,=20 >>>>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, = 72,=20 >>>>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, = 102,=20 >>>>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, = 51,=20 >>>>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, = 97,=20 >>>>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, = 99,=20 >>>>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, = 80,=20 >>>>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, = 113,=20 >>>>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, = 85,=20 >>>>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext = [253,=20 >>>>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, = 246,=20 >>>>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity = Value)=20 >>>>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, = 114,=20 >>>>>> 139] Encoded Authentication Tag (Encoded Integrity >>>>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>>>>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>>>>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>>>>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>>>>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>>>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_5A9FD851-A37E-4C20-A2D7-E1C343DFA46D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTE5NTQ1NlowIwYJKoZIhvcNAQkEMRYEFEfQBLvddNs+rsDW4a70/JcjwlCmMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACDSF40dhY7G/1MGFfP933dBZbbHJGVhTPLFchixYsJYc9PF5Z7vYBc8smwcm6iiZNQe/AvHr6r4 mz76TWkKfDII8TqEfELYMregCgggNyfZX2bH+qLR8Phg8YNFJdm44ZQ2264A8hLxN7E7u82Deafe deGvskU/guIsNZLg/jWx2F2LHlgkvwLwK+pWrlFuSXSHResWDKCoNSZWo3Uuwy4mF/xNFL5OA2vt 64nDvS5OWZc3hUCb00Td/+5vyKn1RLpTmBXvsa/i/TgZJb4FyWcXPoO2Ocywwr0gkE8qLcnJYFvG mhR4cWDNlB7PpUIFqLhxJ2SaJCZC03YPh8cTxdcAAAAAAAA= --Apple-Mail=_5A9FD851-A37E-4C20-A2D7-E1C343DFA46D-- From rbarnes@bbn.com Fri Jun 29 13:06:34 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 B45AC21F88D5 for ; Fri, 29 Jun 2012 13:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmcN-WB1A8b2 for ; Fri, 29 Jun 2012 13:06:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 60A0B21F88D4 for ; Fri, 29 Jun 2012 13:06:31 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55415) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkhSW-000LKz-Nc; Fri, 29 Jun 2012 16:06:28 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 29 Jun 2012 16:06:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <95299FC7-B2DF-4595-8767-35E2D1621204@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 20:06:34 -0000 On Jun 29, 2012, at 3:54 PM, John Bradley wrote: > I don't think we are trying to preclude parameters for new algorithms. >=20 > The question is if for the core ones we have to define configurable = parameters for all possible parameters or if it is OK=20 > to have a lag that specifies a fixed set of parameters and requires no = options. Ok. I thought that's what I suggested at first: A default version, but = also a syntax where you *can* specify parameters. For example (copying = and pasting from below): "rsa-oaep" =3D=3D Default parameters {"name": "rsa-oaep", "hash": "...", "mgf": "..."} =3D=3D Specified = parameters Is that what you mean? =20 I agree that they're not mutually exclusive, given that they can be = distinguished by type (string vs. object). What I don't think we should do is multiple single-token options for the = same algorithm. For example, there shouldn't be have: "rsa-oaep" // hash=3Dsha1, mgf=3Dmgf1(sha1) "rsa-oaep-sha256" // hash=3Dsha256, mgf=3Dmgf1(sha256) The second case should use specified parameters. --Richard > They are not necessarily mutually exclusive. >=20 > John B. >=20 > On 2012-06-29, at 3:04 PM, Richard L. Barnes wrote: >=20 >> No, I think we actually disagree :) >>=20 >> I'm saying that disallowing the specification of parameters makes = extensibility much harder. Let's do some side-by-side comparisons: >>=20 >> In terms of pseudo-code: >> -----BEGIN-WithParams----- >> alg =3D JSON.parse('{"name":"rsa-oaep", "hash": "foo", "mgf": = "bar"}') >> hash =3D default_hash >> mgf =3D default_mgf >> if (alg instanceof Object): >> hash =3D Crypto.algorithmByName(alg["hash"]) >> mgf =3D Crypto.algorithmByName(alg["mgf"]) >> -----END-WithParams----- >>=20 >> -----BEGIN-WithoutParams----- >> alg =3D "rsa-oaep-foo-bar" >> ### Table of sub-algorithms for every known combination >> (hash, mgf) =3D Crypto.subAlgorithmsByName(alg) >> -----END-WithoutParams----- >>=20 >> In terms of keeping state: >> With parameters: I have to keep a table of cryptographic primitives. >> Without parameters: I have to keep a table of all the possible = combinations that are allowed. =20 >>=20 >> In terms of adding a new sub-algorithm combination: >> With parameters: Just allow it. The code doesn't have to change. >> With parameters: Every implementation has to update their registry. >>=20 >> Don't overestimate the interoperability problems. Allowing = parameters to be specified doesn't prevent combinatorial growth. Just = look at the TLS ciphersuite registry: >> = >> In either case, you can limit the proliferation by policy, instead of = by protocol. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Jun 29, 2012, at 2:40 PM, John Bradley wrote: >>=20 >>> I think that you are both recommending the same thing, but not = agreeing somehow. >>>=20 >>> Having large numbers of sub parameters that can be individually = specified, is a mess for interoperability and testing. >>>=20 >>> If there is a reason to change a sub parameter then a new composite = lag can be specified in JWA. >>>=20 >>> John B.=20 >>> On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: >>>=20 >>>> You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 >>>>=20 >>>> Besides, requiring new tokens for different parameter sets doesn't = prevent algorithm proliferation, it just makes it a bigger hassle. If = the parameters are explicitly specified (with defaults), then to add a = new algorithm, my code just has to support the new algorithm -- the code = paths to invoke it don't need to change. With a "single-token" = approach, I have to write a whole new handler for every combination of = parameters. And that's simpler? >>>>=20 >>>> And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >>>>=20 >>>>> As a design principle, the working group decided early on to = specify small sets of algorithm combinations that are actually deployed = in the wild. This aids both interoperability and reduces implementation = complexity. >>>>>=20 >>>>> There is a way to specify parameters - registering new "alg" = values in JWA that specify new algorithms and/or parameter combinations. = If your application needs different OAEP parameter choices than the = defaults, then by all means, make the case to the working group that = that combination should be added to the JWA spec. >>>>>=20 >>>>> Best wishes, >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>>>> Sent: Friday, June 29, 2012 10:58 AM >>>>> To: Mike Jones >>>>> Cc: jose@ietf.org >>>>> Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >>>>>=20 >>>>> (Changed subject line to reflect topic change) >>>>>=20 >>>>> Might be nice to have a way to specify the parameters, but fall = back to the default if the parameters are missing. =20 >>>>>=20 >>>>> As an aside: This is why in JSMS all the crypto stuff gets bound = up in the AlgorithmIdentifier structure. Using that design pattern, you = could have: >>>>> "rsa-oaep" =3D=3D Default parameters >>>>> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>>>>=20 >>>>> Likewise, for symmetric algorithms, having the crypto parameters = (IV, nonce, etc.) in the AlgorithmIdentifier helps remove the = ambiguities that JWE/JWS currently have with regard to things like what = happens if an algorithm doesn't require an IV. >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>>>>=20 >>>>>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies the = use of OAEP padding with the default parameters defined by PKCS #1 v2.1 = (RFC 3447) in Section A.2.1. >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>> Sent: Friday, June 29, 2012 10:20 AM >>>>>> To: Mike Jones >>>>>> Cc: jose@ietf.org >>>>>> Subject: Re: [jose] Second compute JWE computation example >>>>>>=20 >>>>>> This seems underspecified. What parameters are you using for = OAEP? IIRC, it requires a digest algorithm and a masking generation = function. I don't see either of those specified in JWS or JWA. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>>>>=20 >>>>>>> Dear working group members, >>>>>>>=20 >>>>>>> A second complete JWE computation example is included below. As = I'd previously written, I'm adding example encryption computations to = the JWE spec to aid implementers. These values have been verified by = two independent implementations. >>>>>>>=20 >>>>>>> This example uses the header values: >>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>=20 >>>>>>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>>>>>=20 >>>>>>> Note that because the RSA-OAEP computation uses random values, = the encrypted key computation will not be repeatable, although all = resulting values will be decryptable to retrieve the original key value. >>>>>>>=20 >>>>>>> I'd be interested in hearing results from any of you who also = try this JWE with your implementation. >>>>>>>=20 >>>>>>> Enjoy, >>>>>>> -- Mike >>>>>>>=20 >>>>>>> CMK (CEK) >>>>>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, = 154,=20 >>>>>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, = 122,=20 >>>>>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, = 77,=20 >>>>>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, = 97,=20 >>>>>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>> Header Bytes >>>>>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, = 80,=20 >>>>>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, = 77, 34,=20 >>>>>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, = 54, 85,=20 >>>>>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>> D >>>>>>> RVM2IifQ >>>>>>> BEGIN RSA KEY PARAMETERS >>>>>>> Exponent >>>>>>> [1, 0, 1] >>>>>>> Modulus >>>>>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, = 30,=20 >>>>>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, = 193,=20 >>>>>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, = 103,=20 >>>>>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, = 78,=20 >>>>>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, = 56, 35,=20 >>>>>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, = 201,=20 >>>>>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, = 231,=20 >>>>>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, = 196,=20 >>>>>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, = 233,=20 >>>>>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, = 160,=20 >>>>>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, = 58, 89,=20 >>>>>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, = 46,=20 >>>>>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, = 17,=20 >>>>>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, = 20,=20 >>>>>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, = 201, 71,=20 >>>>>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, = 197,=20 >>>>>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, = 190,=20 >>>>>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, = 62,=20 >>>>>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, = 219,=20 >>>>>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, = 191,=20 >>>>>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, = 104,=20 >>>>>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, = 202,=20 >>>>>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, = 39,=20 >>>>>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, = 42,=20 >>>>>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, = 24, 1,=20 >>>>>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, = 182, 95,=20 >>>>>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, = 72,=20 >>>>>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, = 202,=20 >>>>>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, = 85,=20 >>>>>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, = 153,=20 >>>>>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, = 17,=20 >>>>>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, = 69,=20 >>>>>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, = 194, 11,=20 >>>>>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, = 91,=20 >>>>>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>>>>>> RSA key parameters are included for completeness, but should not = be=20 >>>>>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, = 109,=20 >>>>>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, = 34,=20 >>>>>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, = 74,=20 >>>>>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, = 69,=20 >>>>>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, = 252,=20 >>>>>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, = 110,=20 >>>>>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, = 24,=20 >>>>>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, = 144,=20 >>>>>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, = 173,=20 >>>>>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, = 161, 13,=20 >>>>>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, = 135,=20 >>>>>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, = 86,=20 >>>>>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, = 13,=20 >>>>>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, = 209,=20 >>>>>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, = 37,=20 >>>>>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, = 250,=20 >>>>>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, = 49,=20 >>>>>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, = 134,=20 >>>>>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, = 39,=20 >>>>>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, = 173,=20 >>>>>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, = 201,=20 >>>>>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, = 229, 80,=20 >>>>>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, = 142, 0,=20 >>>>>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, = 20,=20 >>>>>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, = 115,=20 >>>>>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, = 180,=20 >>>>>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, = 226,=20 >>>>>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, = 44,=20 >>>>>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, = 74,=20 >>>>>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, = 178,=20 >>>>>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, = 131, 32,=20 >>>>>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, = 151,=20 >>>>>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, = 91,=20 >>>>>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, = 183,=20 >>>>>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] = Q=20 >>>>>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, = 229,=20 >>>>>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, = 27,=20 >>>>>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, = 160,=20 >>>>>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, = 177,=20 >>>>>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, = 162,=20 >>>>>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, = 222,=20 >>>>>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, = 54,=20 >>>>>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, = 58,=20 >>>>>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key = [142,=20 >>>>>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, = 2, 46,=20 >>>>>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, = 209,=20 >>>>>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, = 135,=20 >>>>>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, = 117,=20 >>>>>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, = 76, 46,=20 >>>>>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, = 236,=20 >>>>>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, = 208,=20 >>>>>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, = 39,=20 >>>>>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, = 77,=20 >>>>>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, = 95,=20 >>>>>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, = 142,=20 >>>>>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, = 113,=20 >>>>>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, = 164, 15,=20 >>>>>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, = 102,=20 >>>>>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, = 211,=20 >>>>>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, = 249,=20 >>>>>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, = 17]=20 >>>>>>> Encoded Encrypted Key=20 >>>>>>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>>>>>> o=20 >>>>>>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>>>>>> Y >>>>>>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>>>>>> 1=20 >>>>>>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>>>>>> A ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>>>>> Additional Authenticated Data >>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>> D >>>>>>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>>>>>> 3=20 >>>>>>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>>>>>> y=20 >>>>>>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>>>>>> Q=20 >>>>>>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>>>>>> V=20 >>>>>>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>>>>>> E >>>>>>> Q >>>>>>> Additional Authenticated Data Bytes >>>>>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, = 69,=20 >>>>>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, = 73,=20 >>>>>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, = 74,=20 >>>>>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, = 85,=20 >>>>>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, = 81,=20 >>>>>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, = 53,=20 >>>>>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, = 75,=20 >>>>>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, = 69,=20 >>>>>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, = 51,=20 >>>>>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, = 100,=20 >>>>>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, = 72,=20 >>>>>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, = 56, 54,=20 >>>>>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, = 80, 74,=20 >>>>>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, = 89,=20 >>>>>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, = 122,=20 >>>>>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, = 106,=20 >>>>>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, = 119,=20 >>>>>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, = 57,=20 >>>>>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, = 72,=20 >>>>>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, = 102,=20 >>>>>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, = 51,=20 >>>>>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, = 97,=20 >>>>>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, = 99,=20 >>>>>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, = 77, 80,=20 >>>>>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, = 113,=20 >>>>>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, = 97, 85,=20 >>>>>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext = [253,=20 >>>>>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, = 246,=20 >>>>>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>>>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity = Value)=20 >>>>>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, = 114,=20 >>>>>>> 139] Encoded Authentication Tag (Encoded Integrity >>>>>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>>>>>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>>>>>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>>>>>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>>>>>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>>>>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 From ve7jtb@ve7jtb.com Fri Jun 29 13:20: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 2D54121F88BA for ; Fri, 29 Jun 2012 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsM49OhOmo1r for ; Fri, 29 Jun 2012 13:20:55 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 497C421F88CC for ; Fri, 29 Jun 2012 13:20:55 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3484362ggn.31 for ; Fri, 29 Jun 2012 13:20:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Ky0AF/2ssawS+XvLEL6RA8gD7+8SkyfJ259AdaqtEy8=; b=ZfNxBozWvLdL5hIOeuCoUUBaSsd4FH45cbPZa9lg1xXfFeUN6AyrOYBfBeEqb4RFXZ K12HbWXI+9ZQ2vIvfLbLnxJPf7s7q/gNVGiQ8BX1jz89xPfd+BIQI/E7Z79NgP0gCTew k8Gg5XEZcpTUyq0uxoBGcHRIuBZ2KLkhGV5K3q/YvVh0EOlMH7ZEyZYXJpDJB9gTQVvC pXDMwZ052dHWIh6WT9jS8lxxIWtXSogYqNtt7e0eMd5iuSfgi4HbtrwL16rX6Z9j7vjc 6nvF1baMTnViDQR/PENSN+xCaBSBBhy4x6tFRt1ZEyxDrH6yQ+Tmv7g+BdRQjZGYUOBt ss/Q== Received: by 10.100.81.11 with SMTP id e11mr1346227anb.80.1341001254511; Fri, 29 Jun 2012 13:20:54 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id w61sm8068942yhi.5.2012.06.29.13.20.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 13:20:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_FA6420FA-A47C-494E-9639-05CABE7790E5"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <95299FC7-B2DF-4595-8767-35E2D1621204@bbn.com> Date: Fri, 29 Jun 2012 16:20:36 -0400 Message-Id: <1E57B1F2-51B3-40CF-8AF1-60246DF5C970@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> <95299FC7-B2DF-4595-8767-35E2D1621204@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlcFmXuKFnLN3G0sZuD9gWX+wsjR4o9ACQE9EGF+whea0s06K/7xoVlq3S/ph+ERHbMlCla Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 20:20:58 -0000 --Apple-Mail=_FA6420FA-A47C-494E-9639-05CABE7790E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OK it wasn't initially clear to me that you were proposing alg itself be = a JSON object. I am not certain about having alg sometimes be a string and sometimes be = a object. I will think about it. John B. On 2012-06-29, at 4:06 PM, Richard L. Barnes wrote: >=20 > On Jun 29, 2012, at 3:54 PM, John Bradley wrote: >=20 >> I don't think we are trying to preclude parameters for new = algorithms. >>=20 >> The question is if for the core ones we have to define configurable = parameters for all possible parameters or if it is OK=20 >> to have a lag that specifies a fixed set of parameters and requires = no options. >=20 > Ok. I thought that's what I suggested at first: A default version, = but also a syntax where you *can* specify parameters. For example = (copying and pasting from below): > "rsa-oaep" =3D=3D Default parameters > {"name": "rsa-oaep", "hash": "...", "mgf": "..."} =3D=3D Specified = parameters >=20 > Is that what you mean? =20 >=20 > I agree that they're not mutually exclusive, given that they can be = distinguished by type (string vs. object). >=20 > What I don't think we should do is multiple single-token options for = the same algorithm. For example, there shouldn't be have: > "rsa-oaep" // hash=3Dsha1, mgf=3Dmgf1(sha1) > "rsa-oaep-sha256" // hash=3Dsha256, mgf=3Dmgf1(sha256) > The second case should use specified parameters. >=20 > --Richard >=20 >=20 >=20 >> They are not necessarily mutually exclusive. >>=20 >> John B. >>=20 >> On 2012-06-29, at 3:04 PM, Richard L. Barnes wrote: >>=20 >>> No, I think we actually disagree :) >>>=20 >>> I'm saying that disallowing the specification of parameters makes = extensibility much harder. Let's do some side-by-side comparisons: >>>=20 >>> In terms of pseudo-code: >>> -----BEGIN-WithParams----- >>> alg =3D JSON.parse('{"name":"rsa-oaep", "hash": "foo", "mgf": = "bar"}') >>> hash =3D default_hash >>> mgf =3D default_mgf >>> if (alg instanceof Object): >>> hash =3D Crypto.algorithmByName(alg["hash"]) >>> mgf =3D Crypto.algorithmByName(alg["mgf"]) >>> -----END-WithParams----- >>>=20 >>> -----BEGIN-WithoutParams----- >>> alg =3D "rsa-oaep-foo-bar" >>> ### Table of sub-algorithms for every known combination >>> (hash, mgf) =3D Crypto.subAlgorithmsByName(alg) >>> -----END-WithoutParams----- >>>=20 >>> In terms of keeping state: >>> With parameters: I have to keep a table of cryptographic primitives. >>> Without parameters: I have to keep a table of all the possible = combinations that are allowed. =20 >>>=20 >>> In terms of adding a new sub-algorithm combination: >>> With parameters: Just allow it. The code doesn't have to change. >>> With parameters: Every implementation has to update their registry. >>>=20 >>> Don't overestimate the interoperability problems. Allowing = parameters to be specified doesn't prevent combinatorial growth. Just = look at the TLS ciphersuite registry: >>> = >>> In either case, you can limit the proliferation by policy, instead = of by protocol. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Jun 29, 2012, at 2:40 PM, John Bradley wrote: >>>=20 >>>> I think that you are both recommending the same thing, but not = agreeing somehow. >>>>=20 >>>> Having large numbers of sub parameters that can be individually = specified, is a mess for interoperability and testing. >>>>=20 >>>> If there is a reason to change a sub parameter then a new composite = lag can be specified in JWA. >>>>=20 >>>> John B.=20 >>>> On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: >>>>=20 >>>>> You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 >>>>>=20 >>>>> Besides, requiring new tokens for different parameter sets doesn't = prevent algorithm proliferation, it just makes it a bigger hassle. If = the parameters are explicitly specified (with defaults), then to add a = new algorithm, my code just has to support the new algorithm -- the code = paths to invoke it don't need to change. With a "single-token" = approach, I have to write a whole new handler for every combination of = parameters. And that's simpler? >>>>>=20 >>>>> And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >>>>>=20 >>>>>> As a design principle, the working group decided early on to = specify small sets of algorithm combinations that are actually deployed = in the wild. This aids both interoperability and reduces implementation = complexity. >>>>>>=20 >>>>>> There is a way to specify parameters - registering new "alg" = values in JWA that specify new algorithms and/or parameter combinations. = If your application needs different OAEP parameter choices than the = defaults, then by all means, make the case to the working group that = that combination should be added to the JWA spec. >>>>>>=20 >>>>>> Best wishes, >>>>>> -- Mike >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>>>>> Sent: Friday, June 29, 2012 10:58 AM >>>>>> To: Mike Jones >>>>>> Cc: jose@ietf.org >>>>>> Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >>>>>>=20 >>>>>> (Changed subject line to reflect topic change) >>>>>>=20 >>>>>> Might be nice to have a way to specify the parameters, but fall = back to the default if the parameters are missing. =20 >>>>>>=20 >>>>>> As an aside: This is why in JSMS all the crypto stuff gets bound = up in the AlgorithmIdentifier structure. Using that design pattern, you = could have: >>>>>> "rsa-oaep" =3D=3D Default parameters >>>>>> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>>>>>=20 >>>>>> Likewise, for symmetric algorithms, having the crypto parameters = (IV, nonce, etc.) in the AlgorithmIdentifier helps remove the = ambiguities that JWE/JWS currently have with regard to things like what = happens if an algorithm doesn't require an IV. >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>>>>>=20 >>>>>>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies = the use of OAEP padding with the default parameters defined by PKCS #1 = v2.1 (RFC 3447) in Section A.2.1. >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>> Sent: Friday, June 29, 2012 10:20 AM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] Second compute JWE computation example >>>>>>>=20 >>>>>>> This seems underspecified. What parameters are you using for = OAEP? IIRC, it requires a digest algorithm and a masking generation = function. I don't see either of those specified in JWS or JWA. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>>>>>=20 >>>>>>>> Dear working group members, >>>>>>>>=20 >>>>>>>> A second complete JWE computation example is included below. = As I'd previously written, I'm adding example encryption computations to = the JWE spec to aid implementers. These values have been verified by = two independent implementations. >>>>>>>>=20 >>>>>>>> This example uses the header values: >>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>>=20 >>>>>>>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>>>>>>=20 >>>>>>>> Note that because the RSA-OAEP computation uses random values, = the encrypted key computation will not be repeatable, although all = resulting values will be decryptable to retrieve the original key value. >>>>>>>>=20 >>>>>>>> I'd be interested in hearing results from any of you who also = try this JWE with your implementation. >>>>>>>>=20 >>>>>>>> Enjoy, >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> CMK (CEK) >>>>>>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, = 154,=20 >>>>>>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, = 122,=20 >>>>>>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, = 225, 77,=20 >>>>>>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, = 97,=20 >>>>>>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>> Header Bytes >>>>>>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, = 80,=20 >>>>>>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, = 77, 34,=20 >>>>>>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, = 54, 85,=20 >>>>>>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>> D >>>>>>>> RVM2IifQ >>>>>>>> BEGIN RSA KEY PARAMETERS >>>>>>>> Exponent >>>>>>>> [1, 0, 1] >>>>>>>> Modulus >>>>>>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, = 30,=20 >>>>>>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, = 193,=20 >>>>>>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, = 103,=20 >>>>>>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, = 78,=20 >>>>>>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, = 56, 35,=20 >>>>>>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, = 201,=20 >>>>>>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, = 231,=20 >>>>>>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, = 196,=20 >>>>>>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, = 233,=20 >>>>>>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, = 160,=20 >>>>>>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, = 58, 89,=20 >>>>>>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, = 46,=20 >>>>>>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, = 17,=20 >>>>>>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, = 20,=20 >>>>>>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, = 201, 71,=20 >>>>>>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, = 197,=20 >>>>>>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, = 190,=20 >>>>>>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, = 62,=20 >>>>>>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, = 219,=20 >>>>>>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, = 191,=20 >>>>>>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, = 104,=20 >>>>>>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, = 202,=20 >>>>>>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, = 39,=20 >>>>>>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, = 42,=20 >>>>>>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, = 24, 1,=20 >>>>>>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, = 182, 95,=20 >>>>>>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, = 72,=20 >>>>>>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, = 200, 202,=20 >>>>>>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, = 85,=20 >>>>>>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, = 153,=20 >>>>>>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, = 208, 17,=20 >>>>>>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, = 229, 69,=20 >>>>>>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, = 194, 11,=20 >>>>>>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, = 78, 91,=20 >>>>>>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>>>>>>> RSA key parameters are included for completeness, but should = not be=20 >>>>>>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, = 109,=20 >>>>>>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, = 34,=20 >>>>>>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, = 158, 74,=20 >>>>>>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, = 69,=20 >>>>>>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, = 252,=20 >>>>>>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, = 110,=20 >>>>>>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, = 24,=20 >>>>>>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, = 86, 144,=20 >>>>>>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, = 173,=20 >>>>>>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, = 161, 13,=20 >>>>>>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, = 135,=20 >>>>>>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, = 50, 86,=20 >>>>>>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, = 13,=20 >>>>>>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, = 209,=20 >>>>>>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, = 37,=20 >>>>>>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, = 91, 250,=20 >>>>>>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, = 49,=20 >>>>>>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, = 49, 134,=20 >>>>>>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, = 177, 39,=20 >>>>>>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, = 173,=20 >>>>>>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, = 201,=20 >>>>>>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, = 229, 80,=20 >>>>>>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, = 142, 0,=20 >>>>>>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, = 20,=20 >>>>>>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, = 115,=20 >>>>>>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, = 180,=20 >>>>>>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, = 226,=20 >>>>>>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, = 44,=20 >>>>>>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, = 74,=20 >>>>>>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, = 178,=20 >>>>>>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, = 131, 32,=20 >>>>>>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, = 151,=20 >>>>>>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, = 91,=20 >>>>>>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, = 173, 183,=20 >>>>>>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, = 93] Q=20 >>>>>>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, = 251, 229,=20 >>>>>>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, = 25, 27,=20 >>>>>>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, = 117, 160,=20 >>>>>>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, = 177,=20 >>>>>>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, = 140, 162,=20 >>>>>>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, = 193, 222,=20 >>>>>>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, = 57, 54,=20 >>>>>>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, = 58,=20 >>>>>>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key = [142,=20 >>>>>>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, = 2, 46,=20 >>>>>>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, = 209,=20 >>>>>>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, = 221, 135,=20 >>>>>>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, = 117,=20 >>>>>>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, = 76, 46,=20 >>>>>>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, = 236,=20 >>>>>>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, = 208,=20 >>>>>>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, = 248, 39,=20 >>>>>>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, = 77,=20 >>>>>>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, = 95,=20 >>>>>>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, = 142,=20 >>>>>>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, = 95, 113,=20 >>>>>>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, = 164, 15,=20 >>>>>>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, = 102,=20 >>>>>>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, = 211,=20 >>>>>>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, = 249,=20 >>>>>>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, = 17]=20 >>>>>>>> Encoded Encrypted Key=20 >>>>>>>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>>>>>>> o=20 >>>>>>>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>>>>>>> Y >>>>>>>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>>>>>>> 1=20 >>>>>>>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>>>>>>> A = ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>>>>>> Additional Authenticated Data >>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>> D >>>>>>>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>>>>>>> 3=20 >>>>>>>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>>>>>>> y=20 >>>>>>>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>>>>>>> Q=20 >>>>>>>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>>>>>>> V=20 >>>>>>>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>>>>>>> E >>>>>>>> Q >>>>>>>> Additional Authenticated Data Bytes >>>>>>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, = 69,=20 >>>>>>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, = 121, 73,=20 >>>>>>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, = 74,=20 >>>>>>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, = 85,=20 >>>>>>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, = 102, 81,=20 >>>>>>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, = 53,=20 >>>>>>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, = 75,=20 >>>>>>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, = 69,=20 >>>>>>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, = 87, 51,=20 >>>>>>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, = 100,=20 >>>>>>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, = 72,=20 >>>>>>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, = 56, 54,=20 >>>>>>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, = 80, 74,=20 >>>>>>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, = 89,=20 >>>>>>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, = 122,=20 >>>>>>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, = 106,=20 >>>>>>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, = 119,=20 >>>>>>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, = 79, 57,=20 >>>>>>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, = 72,=20 >>>>>>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, = 102,=20 >>>>>>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, = 51,=20 >>>>>>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, = 97,=20 >>>>>>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, = 99,=20 >>>>>>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, = 77, 80,=20 >>>>>>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, = 113,=20 >>>>>>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, = 97, 85,=20 >>>>>>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext = [253,=20 >>>>>>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, = 246,=20 >>>>>>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>>>>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity = Value)=20 >>>>>>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, = 233, 114,=20 >>>>>>>> 139] Encoded Authentication Tag (Encoded Integrity >>>>>>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>>>>>>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>>>>>>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>>>>>>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>>>>>>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>>>>>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >=20 --Apple-Mail=_FA6420FA-A47C-494E-9639-05CABE7790E5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTIwMjAzNlowIwYJKoZIhvcNAQkEMRYEFGaSPd2R9E8oZLjK41e0N3hdlOiRMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AGkvG+1NM5nCB2SwDeiejzgiUDnL4HhnYqAHLPiRChF3/VLvQbtJK6ghPNa49Ajxc8cU8VO9JVRx KWc1YYz3s3CBM5nm57qbZqFC4SS8eLOqHAO/fj8cMYv7LxoYFyRc2tUxXYMYaD8Qpucn2Hdcuvwn s7vINmlrT9TrqrQCReLKbE3cJDr940VATmjJ1dINtsPF10CBBf/JwsG5ec65mauD/hSoqHECWeBM rwJ/7nI+EqzhP7Aa8gwxeQjV2JwR9Hqdy3+i7YoqRRUlUgo1guzQScGnI6bVzDxidqzio3yQsYN3 nYj3f2vmT7h6Y/ROa0NomsnYIGnAbS64SPUWPjwAAAAAAAA= --Apple-Mail=_FA6420FA-A47C-494E-9639-05CABE7790E5-- From Michael.Jones@microsoft.com Fri Jun 29 13:26:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625C811E807F for ; Fri, 29 Jun 2012 13:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.672 X-Spam-Level: X-Spam-Status: No, score=-3.672 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxwSWR+U-h3D for ; Fri, 29 Jun 2012 13:26:36 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id AD1EC11E8072 for ; Fri, 29 Jun 2012 13:26:35 -0700 (PDT) Received: from mail49-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 20:24:44 +0000 Received: from mail49-db3 (localhost [127.0.0.1]) by mail49-db3-R.bigfish.com (Postfix) with ESMTP id 63D7B3203E8; Fri, 29 Jun 2012 20:24:44 +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: -30 X-BigFish: VS-30(zz98dI9371I936eI542M1432I1418Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail49-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3 (MessageSwitch) id 1341001481626519_30277; Fri, 29 Jun 2012 20:24:41 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.236]) by mail49-db3.bigfish.com (Postfix) with ESMTP id 8C3892C0044; Fri, 29 Jun 2012 20:24:41 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 20:24:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Fri, 29 Jun 2012 20:26:28 +0000 From: Mike Jones To: John Bradley , "Richard L. Barnes" Thread-Topic: [jose] Algorithm parameters (was Re: Second compute JWE computation example) Thread-Index: AQHNVibA+9YYwAQyDkKwNKHfxXOhDJcRp7eAgAAOGACAAAM5AIAAA/MAgAABjFA= Date: Fri, 29 Jun 2012 20:26:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656F04A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> <95299FC7-B2DF-4595-8767-35E2D1621204@bbn.com> <1E57B1F2-51B3-40CF-8AF1-60246DF5C970@ve7jtb.com> In-Reply-To: <1E57B1F2-51B3-40CF-8AF1-60246DF5C970@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 20:26:38 -0000 Having polymorphic parameters seems more complex than the alternatives -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Friday, June 29, 2012 1:21 PM To: Richard L. Barnes Cc: Mike Jones; jose@ietf.org Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE comput= ation example) OK it wasn't initially clear to me that you were proposing alg itself be a = JSON object. I am not certain about having alg sometimes be a string and sometimes be a = object. I will think about it. John B. On 2012-06-29, at 4:06 PM, Richard L. Barnes wrote: >=20 > On Jun 29, 2012, at 3:54 PM, John Bradley wrote: >=20 >> I don't think we are trying to preclude parameters for new algorithms. >>=20 >> The question is if for the core ones we have to define configurable para= meters for all possible parameters or if it is OK=20 >> to have a lag that specifies a fixed set of parameters and requires no o= ptions. >=20 > Ok. I thought that's what I suggested at first: A default version, but a= lso a syntax where you *can* specify parameters. For example (copying and = pasting from below): > "rsa-oaep" =3D=3D Default parameters > {"name": "rsa-oaep", "hash": "...", "mgf": "..."} =3D=3D Specified parame= ters >=20 > Is that what you mean? =20 >=20 > I agree that they're not mutually exclusive, given that they can be disti= nguished by type (string vs. object). >=20 > What I don't think we should do is multiple single-token options for the = same algorithm. For example, there shouldn't be have: > "rsa-oaep" // hash=3Dsha1, mgf=3Dmgf1(sha1) > "rsa-oaep-sha256" // hash=3Dsha256, mgf=3Dmgf1(sha256) > The second case should use specified parameters. >=20 > --Richard >=20 >=20 >=20 >> They are not necessarily mutually exclusive. >>=20 >> John B. >>=20 >> On 2012-06-29, at 3:04 PM, Richard L. Barnes wrote: >>=20 >>> No, I think we actually disagree :) >>>=20 >>> I'm saying that disallowing the specification of parameters makes exten= sibility much harder. Let's do some side-by-side comparisons: >>>=20 >>> In terms of pseudo-code: >>> -----BEGIN-WithParams----- >>> alg =3D JSON.parse('{"name":"rsa-oaep", "hash": "foo", "mgf": "bar"}') >>> hash =3D default_hash >>> mgf =3D default_mgf >>> if (alg instanceof Object): >>> hash =3D Crypto.algorithmByName(alg["hash"]) >>> mgf =3D Crypto.algorithmByName(alg["mgf"]) >>> -----END-WithParams----- >>>=20 >>> -----BEGIN-WithoutParams----- >>> alg =3D "rsa-oaep-foo-bar" >>> ### Table of sub-algorithms for every known combination >>> (hash, mgf) =3D Crypto.subAlgorithmsByName(alg) >>> -----END-WithoutParams----- >>>=20 >>> In terms of keeping state: >>> With parameters: I have to keep a table of cryptographic primitives. >>> Without parameters: I have to keep a table of all the possible combinat= ions that are allowed. =20 >>>=20 >>> In terms of adding a new sub-algorithm combination: >>> With parameters: Just allow it. The code doesn't have to change. >>> With parameters: Every implementation has to update their registry. >>>=20 >>> Don't overestimate the interoperability problems. Allowing parameters = to be specified doesn't prevent combinatorial growth. Just look at the TLS = ciphersuite registry: >>> >>> In either case, you can limit the proliferation by policy, instead of b= y protocol. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Jun 29, 2012, at 2:40 PM, John Bradley wrote: >>>=20 >>>> I think that you are both recommending the same thing, but not agreein= g somehow. >>>>=20 >>>> Having large numbers of sub parameters that can be individually specif= ied, is a mess for interoperability and testing. >>>>=20 >>>> If there is a reason to change a sub parameter then a new composite la= g can be specified in JWA. >>>>=20 >>>> John B.=20 >>>> On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: >>>>=20 >>>>> You're conflating a bunch of things here. Obviously, the set of mand= atory to implement algorithms should be small. But the syntax does not nee= d to enforce that constraint.=20 >>>>>=20 >>>>> Besides, requiring new tokens for different parameter sets doesn't pr= event algorithm proliferation, it just makes it a bigger hassle. If the pa= rameters are explicitly specified (with defaults), then to add a new algori= thm, my code just has to support the new algorithm -- the code paths to inv= oke it don't need to change. With a "single-token" approach, I have to wri= te a whole new handler for every combination of parameters. And that's sim= pler? >>>>>=20 >>>>> And regardless, it still seems like a good idea to package more ephem= eral things like nonces and IVs in this way, since the required parameters = do vary from one algorithm to another. >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >>>>>=20 >>>>>> As a design principle, the working group decided early on to specify= small sets of algorithm combinations that are actually deployed in the wil= d. This aids both interoperability and reduces implementation complexity. >>>>>>=20 >>>>>> There is a way to specify parameters - registering new "alg" values = in JWA that specify new algorithms and/or parameter combinations. If your = application needs different OAEP parameter choices than the defaults, then = by all means, make the case to the working group that that combination shou= ld be added to the JWA spec. >>>>>>=20 >>>>>> Best wishes, >>>>>> -- Mike >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>>>>> Sent: Friday, June 29, 2012 10:58 AM >>>>>> To: Mike Jones >>>>>> Cc: jose@ietf.org >>>>>> Subject: Algorithm parameters (was Re: [jose] Second compute JWE com= putation example) >>>>>>=20 >>>>>> (Changed subject line to reflect topic change) >>>>>>=20 >>>>>> Might be nice to have a way to specify the parameters, but fall back= to the default if the parameters are missing. =20 >>>>>>=20 >>>>>> As an aside: This is why in JSMS all the crypto stuff gets bound up = in the AlgorithmIdentifier structure. Using that design pattern, you could= have: >>>>>> "rsa-oaep" =3D=3D Default parameters >>>>>> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>>>>>=20 >>>>>> Likewise, for symmetric algorithms, having the crypto parameters (IV= , nonce, etc.) in the AlgorithmIdentifier helps remove the ambiguities that= JWE/JWS currently have with regard to things like what happens if an algor= ithm doesn't require an IV. >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>>>>>=20 >>>>>>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies the u= se of OAEP padding with the default parameters defined by PKCS #1 v2.1 (RFC= 3447) in Section A.2.1. >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>> Sent: Friday, June 29, 2012 10:20 AM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] Second compute JWE computation example >>>>>>>=20 >>>>>>> This seems underspecified. What parameters are you using for OAEP?= IIRC, it requires a digest algorithm and a masking generation function. = I don't see either of those specified in JWS or JWA. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>>>>>=20 >>>>>>>> Dear working group members, >>>>>>>>=20 >>>>>>>> A second complete JWE computation example is included below. As I= 'd previously written, I'm adding example encryption computations to the JW= E spec to aid implementers. These values have been verified by two indepen= dent implementations. >>>>>>>>=20 >>>>>>>> This example uses the header values: >>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>>=20 >>>>>>>> This example verifies both the use of RSA-OAEP and the use of AES-= GCM - including the use of the Additional Authenticated Data parameter and = the Authentication Tag output. >>>>>>>>=20 >>>>>>>> Note that because the RSA-OAEP computation uses random values, the= encrypted key computation will not be repeatable, although all resulting v= alues will be decryptable to retrieve the original key value. >>>>>>>>=20 >>>>>>>> I'd be interested in hearing results from any of you who also try = this JWE with your implementation. >>>>>>>>=20 >>>>>>>> Enjoy, >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> CMK (CEK) >>>>>>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,= =20 >>>>>>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122= ,=20 >>>>>>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 7= 7,=20 >>>>>>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,= =20 >>>>>>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>> Header Bytes >>>>>>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80= ,=20 >>>>>>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, = 34,=20 >>>>>>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, = 85,=20 >>>>>>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>>>>>> eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNl= VTM >>>>>>>> D >>>>>>>> RVM2IifQ >>>>>>>> BEGIN RSA KEY PARAMETERS >>>>>>>> Exponent >>>>>>>> [1, 0, 1] >>>>>>>> Modulus >>>>>>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30,= =20 >>>>>>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193= ,=20 >>>>>>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 10= 3,=20 >>>>>>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78,= =20 >>>>>>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, = 35,=20 >>>>>>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201= ,=20 >>>>>>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231,= =20 >>>>>>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196= ,=20 >>>>>>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 23= 3,=20 >>>>>>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160= ,=20 >>>>>>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, = 89,=20 >>>>>>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46= ,=20 >>>>>>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, 17,= =20 >>>>>>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, 20= ,=20 >>>>>>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, = 71,=20 >>>>>>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, 19= 7,=20 >>>>>>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190,= =20 >>>>>>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, 34, 62= ,=20 >>>>>>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219,= =20 >>>>>>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191,= =20 >>>>>>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, 104= ,=20 >>>>>>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, 202= ,=20 >>>>>>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39,= =20 >>>>>>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42,= =20 >>>>>>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24,= 1,=20 >>>>>>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, = 95,=20 >>>>>>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72= ,=20 >>>>>>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, 2= 02,=20 >>>>>>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85,= =20 >>>>>>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, 153= ,=20 >>>>>>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, 1= 7,=20 >>>>>>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, 6= 9,=20 >>>>>>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, = 11,=20 >>>>>>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, 9= 1,=20 >>>>>>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The remain= ing=20 >>>>>>>> RSA key parameters are included for completeness, but should not b= e=20 >>>>>>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, 109= ,=20 >>>>>>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, 140, 34= ,=20 >>>>>>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, 158, 7= 4,=20 >>>>>>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, 154, 69= ,=20 >>>>>>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, 252,= =20 >>>>>>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, 243, 11= 0,=20 >>>>>>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, 24,= =20 >>>>>>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, 86, 1= 44,=20 >>>>>>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ [14, 17= 3,=20 >>>>>>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, 161, = 13,=20 >>>>>>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, 135,= =20 >>>>>>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50, 8= 6,=20 >>>>>>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168, 13= ,=20 >>>>>>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209,= =20 >>>>>>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37= ,=20 >>>>>>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, 2= 50,=20 >>>>>>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,= =20 >>>>>>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, 1= 34,=20 >>>>>>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, 3= 9,=20 >>>>>>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,= =20 >>>>>>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201,= =20 >>>>>>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, = 80,=20 >>>>>>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, = 0,=20 >>>>>>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20,= =20 >>>>>>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 11= 5,=20 >>>>>>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180,= =20 >>>>>>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, 22= 6,=20 >>>>>>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44= ,=20 >>>>>>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74= ,=20 >>>>>>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178,= =20 >>>>>>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, = 32,=20 >>>>>>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151,= =20 >>>>>>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91,= =20 >>>>>>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, 1= 83,=20 >>>>>>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q= =20 >>>>>>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, 2= 29,=20 >>>>>>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 2= 7,=20 >>>>>>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, 1= 60,=20 >>>>>>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177,= =20 >>>>>>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, 1= 62,=20 >>>>>>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 2= 22,=20 >>>>>>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 5= 4,=20 >>>>>>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58,= =20 >>>>>>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key [142,= =20 >>>>>>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, = 46,=20 >>>>>>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 71, 20= 9,=20 >>>>>>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 221, 1= 35,=20 >>>>>>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, 117,= =20 >>>>>>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, 76, = 46,=20 >>>>>>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, 236,= =20 >>>>>>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 216, 20= 8,=20 >>>>>>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 248, 3= 9,=20 >>>>>>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 98, 77= ,=20 >>>>>>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, 95,= =20 >>>>>>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 142,= =20 >>>>>>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, 1= 13,=20 >>>>>>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 164, = 15,=20 >>>>>>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, 102,= =20 >>>>>>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 211,= =20 >>>>>>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 249,= =20 >>>>>>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 17]= =20 >>>>>>>> Encoded Encrypted Key=20 >>>>>>>> jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8= WU9 >>>>>>>> o=20 >>>>>>>> uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fz= T3z >>>>>>>> Y >>>>>>>> 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00= Aa2 >>>>>>>> 1=20 >>>>>>>> 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp= _yJ >>>>>>>> A ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>>>>>> Additional Authenticated Data >>>>>>>> eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNl= VTM >>>>>>>> D >>>>>>>> RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM= 30W >>>>>>>> 3=20 >>>>>>>> YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiv= aw0 >>>>>>>> y=20 >>>>>>>> M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf= lYA >>>>>>>> Q=20 >>>>>>>> O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-a= bRz >>>>>>>> V=20 >>>>>>>> A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl= 5Fj >>>>>>>> E >>>>>>>> Q >>>>>>>> Additional Authenticated Data Bytes >>>>>>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,= =20 >>>>>>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 7= 3,=20 >>>>>>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74,= =20 >>>>>>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85,= =20 >>>>>>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 8= 1,=20 >>>>>>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53= ,=20 >>>>>>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75= ,=20 >>>>>>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69,= =20 >>>>>>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 5= 1,=20 >>>>>>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 10= 0,=20 >>>>>>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72,= =20 >>>>>>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, = 54,=20 >>>>>>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, = 74,=20 >>>>>>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89,= =20 >>>>>>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122,= =20 >>>>>>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106= ,=20 >>>>>>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, 11= 9,=20 >>>>>>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, 5= 7,=20 >>>>>>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, 72,= =20 >>>>>>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, 102= ,=20 >>>>>>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, 51= ,=20 >>>>>>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, 97= ,=20 >>>>>>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, 99= ,=20 >>>>>>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, = 80,=20 >>>>>>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, 11= 3,=20 >>>>>>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, = 85,=20 >>>>>>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext [253= ,=20 >>>>>>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 246,= =20 >>>>>>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>>>>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity Value= )=20 >>>>>>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, 1= 14,=20 >>>>>>>> 139] Encoded Authentication Tag (Encoded Integrity >>>>>>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>>>>>> eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNl= VTM >>>>>>>> DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEq= M30 >>>>>>>> W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJ= iva >>>>>>>> w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNm= XCf >>>>>>>> lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9y= kD- >>>>>>>> abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7= vaN >>>>>>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >=20 From rbarnes@bbn.com Fri Jun 29 13:28: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 7586721F889B for ; Fri, 29 Jun 2012 13:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S45jRC-yiYf3 for ; Fri, 29 Jun 2012 13:28:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B6A0621F8828 for ; Fri, 29 Jun 2012 13:28:46 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55535) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Skho0-000LVp-9G; Fri, 29 Jun 2012 16:28:40 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1E57B1F2-51B3-40CF-8AF1-60246DF5C970@ve7jtb.com> Date: Fri, 29 Jun 2012 16:28:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> <95299FC7-B2DF-4595-8767-35E2D1621204@bbn.com> <1E57B1F2-51B3-40CF-8AF1-60246DF5C970@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 20:28:49 -0000 FWIW, OAEP is a crappy example. The specified parameter thing is a lot more useful for things like DSA, = symmetric algorithms, and D-H algorithms: {name:"dsa", p:1, q:2, g:3} {name:"ecdsa", curve:"P-256"} {name:"aes-ccm", n:"ZONce...lU-g", m:8} {name:"dh-es", group: 14} {name:"ecdh-es", curve:"P-256"} Copied from: So in large part it's the same information that's already in a JWS/JWE, = it just packages it all together as an algorithm description. --Richard On Jun 29, 2012, at 4:20 PM, John Bradley wrote: > OK it wasn't initially clear to me that you were proposing alg itself = be a JSON object. >=20 > I am not certain about having alg sometimes be a string and sometimes = be a object. >=20 > I will think about it. >=20 > John B. >=20 >=20 > On 2012-06-29, at 4:06 PM, Richard L. Barnes wrote: >=20 >>=20 >> On Jun 29, 2012, at 3:54 PM, John Bradley wrote: >>=20 >>> I don't think we are trying to preclude parameters for new = algorithms. >>>=20 >>> The question is if for the core ones we have to define configurable = parameters for all possible parameters or if it is OK=20 >>> to have a lag that specifies a fixed set of parameters and requires = no options. >>=20 >> Ok. I thought that's what I suggested at first: A default version, = but also a syntax where you *can* specify parameters. For example = (copying and pasting from below): >> "rsa-oaep" =3D=3D Default parameters >> {"name": "rsa-oaep", "hash": "...", "mgf": "..."} =3D=3D Specified = parameters >>=20 >> Is that what you mean? =20 >>=20 >> I agree that they're not mutually exclusive, given that they can be = distinguished by type (string vs. object). >>=20 >> What I don't think we should do is multiple single-token options for = the same algorithm. For example, there shouldn't be have: >> "rsa-oaep" // hash=3Dsha1, mgf=3Dmgf1(sha1) >> "rsa-oaep-sha256" // hash=3Dsha256, mgf=3Dmgf1(sha256) >> The second case should use specified parameters. >>=20 >> --Richard >>=20 >>=20 >>=20 >>> They are not necessarily mutually exclusive. >>>=20 >>> John B. >>>=20 >>> On 2012-06-29, at 3:04 PM, Richard L. Barnes wrote: >>>=20 >>>> No, I think we actually disagree :) >>>>=20 >>>> I'm saying that disallowing the specification of parameters makes = extensibility much harder. Let's do some side-by-side comparisons: >>>>=20 >>>> In terms of pseudo-code: >>>> -----BEGIN-WithParams----- >>>> alg =3D JSON.parse('{"name":"rsa-oaep", "hash": "foo", "mgf": = "bar"}') >>>> hash =3D default_hash >>>> mgf =3D default_mgf >>>> if (alg instanceof Object): >>>> hash =3D Crypto.algorithmByName(alg["hash"]) >>>> mgf =3D Crypto.algorithmByName(alg["mgf"]) >>>> -----END-WithParams----- >>>>=20 >>>> -----BEGIN-WithoutParams----- >>>> alg =3D "rsa-oaep-foo-bar" >>>> ### Table of sub-algorithms for every known combination >>>> (hash, mgf) =3D Crypto.subAlgorithmsByName(alg) >>>> -----END-WithoutParams----- >>>>=20 >>>> In terms of keeping state: >>>> With parameters: I have to keep a table of cryptographic = primitives. >>>> Without parameters: I have to keep a table of all the possible = combinations that are allowed. =20 >>>>=20 >>>> In terms of adding a new sub-algorithm combination: >>>> With parameters: Just allow it. The code doesn't have to change. >>>> With parameters: Every implementation has to update their registry. >>>>=20 >>>> Don't overestimate the interoperability problems. Allowing = parameters to be specified doesn't prevent combinatorial growth. Just = look at the TLS ciphersuite registry: >>>> = >>>> In either case, you can limit the proliferation by policy, instead = of by protocol. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 29, 2012, at 2:40 PM, John Bradley wrote: >>>>=20 >>>>> I think that you are both recommending the same thing, but not = agreeing somehow. >>>>>=20 >>>>> Having large numbers of sub parameters that can be individually = specified, is a mess for interoperability and testing. >>>>>=20 >>>>> If there is a reason to change a sub parameter then a new = composite lag can be specified in JWA. >>>>>=20 >>>>> John B.=20 >>>>> On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>> You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 >>>>>>=20 >>>>>> Besides, requiring new tokens for different parameter sets = doesn't prevent algorithm proliferation, it just makes it a bigger = hassle. If the parameters are explicitly specified (with defaults), = then to add a new algorithm, my code just has to support the new = algorithm -- the code paths to invoke it don't need to change. With a = "single-token" approach, I have to write a whole new handler for every = combination of parameters. And that's simpler? >>>>>>=20 >>>>>> And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >>>>>>=20 >>>>>>> As a design principle, the working group decided early on to = specify small sets of algorithm combinations that are actually deployed = in the wild. This aids both interoperability and reduces implementation = complexity. >>>>>>>=20 >>>>>>> There is a way to specify parameters - registering new "alg" = values in JWA that specify new algorithms and/or parameter combinations. = If your application needs different OAEP parameter choices than the = defaults, then by all means, make the case to the working group that = that combination should be added to the JWA spec. >>>>>>>=20 >>>>>>> Best wishes, >>>>>>> -- Mike >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>>>>>> Sent: Friday, June 29, 2012 10:58 AM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >>>>>>>=20 >>>>>>> (Changed subject line to reflect topic change) >>>>>>>=20 >>>>>>> Might be nice to have a way to specify the parameters, but fall = back to the default if the parameters are missing. =20 >>>>>>>=20 >>>>>>> As an aside: This is why in JSMS all the crypto stuff gets bound = up in the AlgorithmIdentifier structure. Using that design pattern, you = could have: >>>>>>> "rsa-oaep" =3D=3D Default parameters >>>>>>> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>>>>>>=20 >>>>>>> Likewise, for symmetric algorithms, having the crypto parameters = (IV, nonce, etc.) in the AlgorithmIdentifier helps remove the = ambiguities that JWE/JWS currently have with regard to things like what = happens if an algorithm doesn't require an IV. >>>>>>>=20 >>>>>>> --Richard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>>>>>>=20 >>>>>>>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies = the use of OAEP padding with the default parameters defined by PKCS #1 = v2.1 (RFC 3447) in Section A.2.1. >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>> Sent: Friday, June 29, 2012 10:20 AM >>>>>>>> To: Mike Jones >>>>>>>> Cc: jose@ietf.org >>>>>>>> Subject: Re: [jose] Second compute JWE computation example >>>>>>>>=20 >>>>>>>> This seems underspecified. What parameters are you using for = OAEP? IIRC, it requires a digest algorithm and a masking generation = function. I don't see either of those specified in JWS or JWA. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>>>>>>=20 >>>>>>>>> Dear working group members, >>>>>>>>>=20 >>>>>>>>> A second complete JWE computation example is included below. = As I'd previously written, I'm adding example encryption computations to = the JWE spec to aid implementers. These values have been verified by = two independent implementations. >>>>>>>>>=20 >>>>>>>>> This example uses the header values: >>>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>>>=20 >>>>>>>>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>>>>>>>=20 >>>>>>>>> Note that because the RSA-OAEP computation uses random values, = the encrypted key computation will not be repeatable, although all = resulting values will be decryptable to retrieve the original key value. >>>>>>>>>=20 >>>>>>>>> I'd be interested in hearing results from any of you who also = try this JWE with your implementation. >>>>>>>>>=20 >>>>>>>>> Enjoy, >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>> CMK (CEK) >>>>>>>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, = 154,=20 >>>>>>>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, = 122,=20 >>>>>>>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, = 225, 77,=20 >>>>>>>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, = 97,=20 >>>>>>>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>>> Header Bytes >>>>>>>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, = 69, 80,=20 >>>>>>>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, = 77, 34,=20 >>>>>>>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, = 54, 85,=20 >>>>>>>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>>> D >>>>>>>>> RVM2IifQ >>>>>>>>> BEGIN RSA KEY PARAMETERS >>>>>>>>> Exponent >>>>>>>>> [1, 0, 1] >>>>>>>>> Modulus >>>>>>>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, = 30,=20 >>>>>>>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, = 193,=20 >>>>>>>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, = 81, 103,=20 >>>>>>>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, = 78,=20 >>>>>>>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, = 56, 35,=20 >>>>>>>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, = 201,=20 >>>>>>>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, = 231,=20 >>>>>>>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, = 196,=20 >>>>>>>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, = 57, 233,=20 >>>>>>>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, = 160,=20 >>>>>>>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, = 58, 89,=20 >>>>>>>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, = 153, 46,=20 >>>>>>>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, = 17,=20 >>>>>>>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, = 195, 20,=20 >>>>>>>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, = 201, 71,=20 >>>>>>>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, = 27, 197,=20 >>>>>>>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, = 190,=20 >>>>>>>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, = 34, 62,=20 >>>>>>>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, = 219,=20 >>>>>>>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, = 191,=20 >>>>>>>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, = 104,=20 >>>>>>>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, = 202,=20 >>>>>>>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, = 39,=20 >>>>>>>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, = 42,=20 >>>>>>>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, = 24, 1,=20 >>>>>>>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, = 182, 95,=20 >>>>>>>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, = 27, 72,=20 >>>>>>>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, = 200, 202,=20 >>>>>>>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, = 85,=20 >>>>>>>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, = 153,=20 >>>>>>>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, = 208, 17,=20 >>>>>>>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, = 229, 69,=20 >>>>>>>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, = 194, 11,=20 >>>>>>>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, = 78, 91,=20 >>>>>>>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>>>>>>>> RSA key parameters are included for completeness, but should = not be=20 >>>>>>>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, = 109,=20 >>>>>>>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, = 140, 34,=20 >>>>>>>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, = 158, 74,=20 >>>>>>>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, = 154, 69,=20 >>>>>>>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, = 252,=20 >>>>>>>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, = 243, 110,=20 >>>>>>>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, = 24,=20 >>>>>>>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, = 86, 144,=20 >>>>>>>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ = [14, 173,=20 >>>>>>>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, = 161, 13,=20 >>>>>>>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, = 135,=20 >>>>>>>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, = 50, 86,=20 >>>>>>>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, = 168, 13,=20 >>>>>>>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, = 209,=20 >>>>>>>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, = 34, 37,=20 >>>>>>>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, = 91, 250,=20 >>>>>>>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, = 49,=20 >>>>>>>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, = 49, 134,=20 >>>>>>>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, = 177, 39,=20 >>>>>>>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, = 173,=20 >>>>>>>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, = 201,=20 >>>>>>>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, = 229, 80,=20 >>>>>>>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, = 142, 0,=20 >>>>>>>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, = 20,=20 >>>>>>>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, = 181, 115,=20 >>>>>>>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, = 180,=20 >>>>>>>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, = 115, 226,=20 >>>>>>>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, = 65, 44,=20 >>>>>>>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, = 109, 74,=20 >>>>>>>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, = 178,=20 >>>>>>>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, = 131, 32,=20 >>>>>>>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, = 151,=20 >>>>>>>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, = 91,=20 >>>>>>>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, = 173, 183,=20 >>>>>>>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, = 93] Q=20 >>>>>>>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, = 251, 229,=20 >>>>>>>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, = 25, 27,=20 >>>>>>>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, = 117, 160,=20 >>>>>>>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, = 177,=20 >>>>>>>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, = 140, 162,=20 >>>>>>>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, = 193, 222,=20 >>>>>>>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, = 57, 54,=20 >>>>>>>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, = 58,=20 >>>>>>>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key = [142,=20 >>>>>>>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, = 2, 46,=20 >>>>>>>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, = 71, 209,=20 >>>>>>>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, = 221, 135,=20 >>>>>>>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, = 117,=20 >>>>>>>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, = 76, 46,=20 >>>>>>>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, = 236,=20 >>>>>>>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, = 216, 208,=20 >>>>>>>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, = 248, 39,=20 >>>>>>>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, = 98, 77,=20 >>>>>>>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, = 95,=20 >>>>>>>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, = 142,=20 >>>>>>>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, = 95, 113,=20 >>>>>>>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, = 164, 15,=20 >>>>>>>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, = 102,=20 >>>>>>>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, = 211,=20 >>>>>>>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, = 249,=20 >>>>>>>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, = 17]=20 >>>>>>>>> Encoded Encrypted Key=20 >>>>>>>>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>>>>>>>> o=20 >>>>>>>>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>>>>>>>> Y >>>>>>>>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>>>>>>>> 1=20 >>>>>>>>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>>>>>>>> A = ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>>>>>>> Additional Authenticated Data >>>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>>> D >>>>>>>>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>>>>>>>> 3=20 >>>>>>>>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>>>>>>>> y=20 >>>>>>>>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>>>>>>>> Q=20 >>>>>>>>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>>>>>>>> V=20 >>>>>>>>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>>>>>>>> E >>>>>>>>> Q >>>>>>>>> Additional Authenticated Data Bytes >>>>>>>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, = 69,=20 >>>>>>>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, = 121, 73,=20 >>>>>>>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, = 74,=20 >>>>>>>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, = 85,=20 >>>>>>>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, = 102, 81,=20 >>>>>>>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, = 66, 53,=20 >>>>>>>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, = 70, 75,=20 >>>>>>>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, = 69,=20 >>>>>>>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, = 87, 51,=20 >>>>>>>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, = 106, 100,=20 >>>>>>>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, = 72,=20 >>>>>>>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, = 56, 54,=20 >>>>>>>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, = 80, 74,=20 >>>>>>>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, = 89,=20 >>>>>>>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, = 122,=20 >>>>>>>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, = 106,=20 >>>>>>>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, = 67, 119,=20 >>>>>>>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, = 79, 57,=20 >>>>>>>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, = 72,=20 >>>>>>>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, = 102,=20 >>>>>>>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, = 84, 51,=20 >>>>>>>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, = 45, 97,=20 >>>>>>>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, = 81, 99,=20 >>>>>>>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, = 77, 80,=20 >>>>>>>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, = 113, 113,=20 >>>>>>>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, = 97, 85,=20 >>>>>>>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext = [253,=20 >>>>>>>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, = 246,=20 >>>>>>>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>>>>>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity = Value)=20 >>>>>>>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, = 233, 114,=20 >>>>>>>>> 139] Encoded Authentication Tag (Encoded Integrity >>>>>>>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>>>>>>>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>>>>>>>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>>>>>>>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>>>>>>>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>>>>>>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>=20 >>=20 >=20 From rbarnes@bbn.com Fri Jun 29 13:32: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 9BBEF21F88F0 for ; Fri, 29 Jun 2012 13:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAbGph2BA0rG for ; Fri, 29 Jun 2012 13:32:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE6521F88E0 for ; Fri, 29 Jun 2012 13:32:07 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55559) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkhrJ-0004zz-Bz; Fri, 29 Jun 2012 16:32:05 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656F04A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 29 Jun 2012 16:32:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <548F8894-6276-46F3-A277-CE341081A88F@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739436656E627@TK5EX14MBXC283.redmond.corp.microsoft.com> <5CC9068D-2B25-43B5-AB4C-82AEE008C669@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC31@TK5EX14MBXC283.redmond.corp.microsoft.com> <01648C62-6F52-4D60-B035-612BD5232D13@bbn.com> <4E1F6AAD24975D4BA5B16804296739436656EC8A@TK5EX14MBXC283.redmond.corp.microsoft.com> <118FB37C-9347-48A9-8331-3A2CFE085438@bbn.com> <8C23BA08-7AC3-4356-9C89-9D50B47193A2@bbn.com> <95299FC7-B2DF-4595-8767-35E2D1621204@bbn.com> <1E57B1F2-51B3-40CF-8AF1-60246DF5C970@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739436656F04A@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: John Bradley , "jose@ietf.org" Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE computation example) 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, 29 Jun 2012 20:32:09 -0000 Complex how? if (typeof(x) =3D=3D "string") { // Use default parameters } else if (typeof(x) =3D=3D "object") { // Use specified parameters } Copied from: On Jun 29, 2012, at 4:26 PM, Mike Jones wrote: > Having polymorphic parameters seems more complex than the alternatives >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Friday, June 29, 2012 1:21 PM > To: Richard L. Barnes > Cc: Mike Jones; jose@ietf.org > Subject: Re: [jose] Algorithm parameters (was Re: Second compute JWE = computation example) >=20 > OK it wasn't initially clear to me that you were proposing alg itself = be a JSON object. >=20 > I am not certain about having alg sometimes be a string and sometimes = be a object. >=20 > I will think about it. >=20 > John B. >=20 >=20 > On 2012-06-29, at 4:06 PM, Richard L. Barnes wrote: >=20 >>=20 >> On Jun 29, 2012, at 3:54 PM, John Bradley wrote: >>=20 >>> I don't think we are trying to preclude parameters for new = algorithms. >>>=20 >>> The question is if for the core ones we have to define configurable = parameters for all possible parameters or if it is OK=20 >>> to have a lag that specifies a fixed set of parameters and requires = no options. >>=20 >> Ok. I thought that's what I suggested at first: A default version, = but also a syntax where you *can* specify parameters. For example = (copying and pasting from below): >> "rsa-oaep" =3D=3D Default parameters >> {"name": "rsa-oaep", "hash": "...", "mgf": "..."} =3D=3D Specified = parameters >>=20 >> Is that what you mean? =20 >>=20 >> I agree that they're not mutually exclusive, given that they can be = distinguished by type (string vs. object). >>=20 >> What I don't think we should do is multiple single-token options for = the same algorithm. For example, there shouldn't be have: >> "rsa-oaep" // hash=3Dsha1, mgf=3Dmgf1(sha1) >> "rsa-oaep-sha256" // hash=3Dsha256, mgf=3Dmgf1(sha256) >> The second case should use specified parameters. >>=20 >> --Richard >>=20 >>=20 >>=20 >>> They are not necessarily mutually exclusive. >>>=20 >>> John B. >>>=20 >>> On 2012-06-29, at 3:04 PM, Richard L. Barnes wrote: >>>=20 >>>> No, I think we actually disagree :) >>>>=20 >>>> I'm saying that disallowing the specification of parameters makes = extensibility much harder. Let's do some side-by-side comparisons: >>>>=20 >>>> In terms of pseudo-code: >>>> -----BEGIN-WithParams----- >>>> alg =3D JSON.parse('{"name":"rsa-oaep", "hash": "foo", "mgf": = "bar"}') >>>> hash =3D default_hash >>>> mgf =3D default_mgf >>>> if (alg instanceof Object): >>>> hash =3D Crypto.algorithmByName(alg["hash"]) >>>> mgf =3D Crypto.algorithmByName(alg["mgf"]) >>>> -----END-WithParams----- >>>>=20 >>>> -----BEGIN-WithoutParams----- >>>> alg =3D "rsa-oaep-foo-bar" >>>> ### Table of sub-algorithms for every known combination >>>> (hash, mgf) =3D Crypto.subAlgorithmsByName(alg) >>>> -----END-WithoutParams----- >>>>=20 >>>> In terms of keeping state: >>>> With parameters: I have to keep a table of cryptographic = primitives. >>>> Without parameters: I have to keep a table of all the possible = combinations that are allowed. =20 >>>>=20 >>>> In terms of adding a new sub-algorithm combination: >>>> With parameters: Just allow it. The code doesn't have to change. >>>> With parameters: Every implementation has to update their registry. >>>>=20 >>>> Don't overestimate the interoperability problems. Allowing = parameters to be specified doesn't prevent combinatorial growth. Just = look at the TLS ciphersuite registry: >>>> = >>>> In either case, you can limit the proliferation by policy, instead = of by protocol. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 29, 2012, at 2:40 PM, John Bradley wrote: >>>>=20 >>>>> I think that you are both recommending the same thing, but not = agreeing somehow. >>>>>=20 >>>>> Having large numbers of sub parameters that can be individually = specified, is a mess for interoperability and testing. >>>>>=20 >>>>> If there is a reason to change a sub parameter then a new = composite lag can be specified in JWA. >>>>>=20 >>>>> John B.=20 >>>>> On 2012-06-29, at 2:19 PM, Richard L. Barnes wrote: >>>>>=20 >>>>>> You're conflating a bunch of things here. Obviously, the set of = mandatory to implement algorithms should be small. But the syntax does = not need to enforce that constraint.=20 >>>>>>=20 >>>>>> Besides, requiring new tokens for different parameter sets = doesn't prevent algorithm proliferation, it just makes it a bigger = hassle. If the parameters are explicitly specified (with defaults), = then to add a new algorithm, my code just has to support the new = algorithm -- the code paths to invoke it don't need to change. With a = "single-token" approach, I have to write a whole new handler for every = combination of parameters. And that's simpler? >>>>>>=20 >>>>>> And regardless, it still seems like a good idea to package more = ephemeral things like nonces and IVs in this way, since the required = parameters do vary from one algorithm to another. >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 29, 2012, at 2:05 PM, Mike Jones wrote: >>>>>>=20 >>>>>>> As a design principle, the working group decided early on to = specify small sets of algorithm combinations that are actually deployed = in the wild. This aids both interoperability and reduces implementation = complexity. >>>>>>>=20 >>>>>>> There is a way to specify parameters - registering new "alg" = values in JWA that specify new algorithms and/or parameter combinations. = If your application needs different OAEP parameter choices than the = defaults, then by all means, make the case to the working group that = that combination should be added to the JWA spec. >>>>>>>=20 >>>>>>> Best wishes, >>>>>>> -- Mike >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 >>>>>>> Sent: Friday, June 29, 2012 10:58 AM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Algorithm parameters (was Re: [jose] Second compute JWE = computation example) >>>>>>>=20 >>>>>>> (Changed subject line to reflect topic change) >>>>>>>=20 >>>>>>> Might be nice to have a way to specify the parameters, but fall = back to the default if the parameters are missing. =20 >>>>>>>=20 >>>>>>> As an aside: This is why in JSMS all the crypto stuff gets bound = up in the AlgorithmIdentifier structure. Using that design pattern, you = could have: >>>>>>> "rsa-oaep" =3D=3D Default parameters >>>>>>> {"name": "rsa-oaep", ...} =3D=3D Specified parameters >>>>>>>=20 >>>>>>> Likewise, for symmetric algorithms, having the crypto parameters = (IV, nonce, etc.) in the AlgorithmIdentifier helps remove the = ambiguities that JWE/JWS currently have with regard to things like what = happens if an algorithm doesn't require an IV. >>>>>>>=20 >>>>>>> --Richard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 29, 2012, at 1:48 PM, Mike Jones wrote: >>>>>>>=20 >>>>>>>> Good catch. I'll add to the JWA spec that RSA-OAEP specifies = the use of OAEP padding with the default parameters defined by PKCS #1 = v2.1 (RFC 3447) in Section A.2.1. >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >>>>>>>> Sent: Friday, June 29, 2012 10:20 AM >>>>>>>> To: Mike Jones >>>>>>>> Cc: jose@ietf.org >>>>>>>> Subject: Re: [jose] Second compute JWE computation example >>>>>>>>=20 >>>>>>>> This seems underspecified. What parameters are you using for = OAEP? IIRC, it requires a digest algorithm and a masking generation = function. I don't see either of those specified in JWS or JWA. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: >>>>>>>>=20 >>>>>>>>> Dear working group members, >>>>>>>>>=20 >>>>>>>>> A second complete JWE computation example is included below. = As I'd previously written, I'm adding example encryption computations to = the JWE spec to aid implementers. These values have been verified by = two independent implementations. >>>>>>>>>=20 >>>>>>>>> This example uses the header values: >>>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>>>=20 >>>>>>>>> This example verifies both the use of RSA-OAEP and the use of = AES-GCM - including the use of the Additional Authenticated Data = parameter and the Authentication Tag output. >>>>>>>>>=20 >>>>>>>>> Note that because the RSA-OAEP computation uses random values, = the encrypted key computation will not be repeatable, although all = resulting values will be decryptable to retrieve the original key value. >>>>>>>>>=20 >>>>>>>>> I'd be interested in hearing results from any of you who also = try this JWE with your implementation. >>>>>>>>>=20 >>>>>>>>> Enjoy, >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>> CMK (CEK) >>>>>>>>> [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, = 154,=20 >>>>>>>>> 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, = 122,=20 >>>>>>>>> 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, = 225, 77,=20 >>>>>>>>> 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, = 97,=20 >>>>>>>>> 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 >>>>>>>>> {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} >>>>>>>>> Header Bytes >>>>>>>>> [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, = 69, 80,=20 >>>>>>>>> 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, = 77, 34,=20 >>>>>>>>> 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, = 54, 85,=20 >>>>>>>>> 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 >>>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>>> D >>>>>>>>> RVM2IifQ >>>>>>>>> BEGIN RSA KEY PARAMETERS >>>>>>>>> Exponent >>>>>>>>> [1, 0, 1] >>>>>>>>> Modulus >>>>>>>>> [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, = 30,=20 >>>>>>>>> 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, = 193,=20 >>>>>>>>> 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, = 81, 103,=20 >>>>>>>>> 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, = 78,=20 >>>>>>>>> 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, = 56, 35,=20 >>>>>>>>> 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, = 201,=20 >>>>>>>>> 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, = 231,=20 >>>>>>>>> 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, = 196,=20 >>>>>>>>> 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, = 57, 233,=20 >>>>>>>>> 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, = 160,=20 >>>>>>>>> 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, = 58, 89,=20 >>>>>>>>> 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, = 153, 46,=20 >>>>>>>>> 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, = 17,=20 >>>>>>>>> 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, = 195, 20,=20 >>>>>>>>> 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, = 201, 71,=20 >>>>>>>>> 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, = 27, 197,=20 >>>>>>>>> 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, = 190,=20 >>>>>>>>> 253, 186, 186, 27] D (private key exponent) [144, 183, 109, = 34, 62,=20 >>>>>>>>> 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, = 219,=20 >>>>>>>>> 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, = 191,=20 >>>>>>>>> 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, = 104,=20 >>>>>>>>> 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, = 202,=20 >>>>>>>>> 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, = 39,=20 >>>>>>>>> 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, = 42,=20 >>>>>>>>> 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, = 24, 1,=20 >>>>>>>>> 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, = 182, 95,=20 >>>>>>>>> 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, = 27, 72,=20 >>>>>>>>> 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, = 200, 202,=20 >>>>>>>>> 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, = 85,=20 >>>>>>>>> 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, = 153,=20 >>>>>>>>> 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, = 208, 17,=20 >>>>>>>>> 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, = 229, 69,=20 >>>>>>>>> 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, = 194, 11,=20 >>>>>>>>> 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, = 78, 91,=20 >>>>>>>>> 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201] The = remaining=20 >>>>>>>>> RSA key parameters are included for completeness, but should = not be=20 >>>>>>>>> needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116, 169, 29, = 109,=20 >>>>>>>>> 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206, 78, = 140, 34,=20 >>>>>>>>> 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189, 129, = 158, 74,=20 >>>>>>>>> 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241, 75, = 154, 69,=20 >>>>>>>>> 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213, 195, = 252,=20 >>>>>>>>> 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84, = 243, 110,=20 >>>>>>>>> 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170, 215, = 24,=20 >>>>>>>>> 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243, = 86, 144,=20 >>>>>>>>> 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ = [14, 173,=20 >>>>>>>>> 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184, = 161, 13,=20 >>>>>>>>> 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101, = 135,=20 >>>>>>>>> 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, = 50, 86,=20 >>>>>>>>> 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, = 168, 13,=20 >>>>>>>>> 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, = 209,=20 >>>>>>>>> 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, = 34, 37,=20 >>>>>>>>> 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, = 91, 250,=20 >>>>>>>>> 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, = 49,=20 >>>>>>>>> 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, = 49, 134,=20 >>>>>>>>> 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, = 177, 39,=20 >>>>>>>>> 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, = 173,=20 >>>>>>>>> 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, = 201,=20 >>>>>>>>> 186, 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, = 229, 80,=20 >>>>>>>>> 174, 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, = 142, 0,=20 >>>>>>>>> 235, 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, = 20,=20 >>>>>>>>> 184, 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, = 181, 115,=20 >>>>>>>>> 199, 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, = 180,=20 >>>>>>>>> 163, 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, = 115, 226,=20 >>>>>>>>> 236, 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, = 65, 44,=20 >>>>>>>>> 184, 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, = 109, 74,=20 >>>>>>>>> 3, 6, 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, = 178,=20 >>>>>>>>> 87, 174, 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, = 131, 32,=20 >>>>>>>>> 4, 61, 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, = 151,=20 >>>>>>>>> 243, 47, 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, = 91,=20 >>>>>>>>> 168, 81, 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, = 173, 183,=20 >>>>>>>>> 195, 35, 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, = 93] Q=20 >>>>>>>>> [192, 182, 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, = 251, 229,=20 >>>>>>>>> 123, 206, 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, = 25, 27,=20 >>>>>>>>> 134, 178, 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, = 117, 160,=20 >>>>>>>>> 216, 85, 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, = 177,=20 >>>>>>>>> 167, 13, 236, 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, = 140, 162,=20 >>>>>>>>> 53, 162, 102, 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, = 193, 222,=20 >>>>>>>>> 32, 191, 17, 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, = 57, 54,=20 >>>>>>>>> 69, 171, 84, 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, = 58,=20 >>>>>>>>> 241, 70, 71, 190, 215] END RSA KEY PARAMETERS Encrypted Key = [142,=20 >>>>>>>>> 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, = 2, 46,=20 >>>>>>>>> 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, = 71, 209,=20 >>>>>>>>> 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, = 221, 135,=20 >>>>>>>>> 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 95, = 117,=20 >>>>>>>>> 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 119, = 76, 46,=20 >>>>>>>>> 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 179, = 236,=20 >>>>>>>>> 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, = 216, 208,=20 >>>>>>>>> 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, = 248, 39,=20 >>>>>>>>> 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, = 98, 77,=20 >>>>>>>>> 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 239, = 95,=20 >>>>>>>>> 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, = 142,=20 >>>>>>>>> 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, = 95, 113,=20 >>>>>>>>> 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, = 164, 15,=20 >>>>>>>>> 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 43, = 102,=20 >>>>>>>>> 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, = 211,=20 >>>>>>>>> 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, = 249,=20 >>>>>>>>> 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, = 17]=20 >>>>>>>>> Encoded Encrypted Key=20 >>>>>>>>> = jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9 >>>>>>>>> o=20 >>>>>>>>> = uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3z >>>>>>>>> Y >>>>>>>>> = 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa2 >>>>>>>>> 1=20 >>>>>>>>> = 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJ >>>>>>>>> A = ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ >>>>>>>>> Additional Authenticated Data >>>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>>> D >>>>>>>>> = RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W >>>>>>>>> 3=20 >>>>>>>>> = YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0 >>>>>>>>> y=20 >>>>>>>>> = M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYA >>>>>>>>> Q=20 >>>>>>>>> = O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRz >>>>>>>>> V=20 >>>>>>>>> = A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5Fj >>>>>>>>> E >>>>>>>>> Q >>>>>>>>> Additional Authenticated Data Bytes >>>>>>>>> [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, = 69,=20 >>>>>>>>> 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, = 121, 73,=20 >>>>>>>>> 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, = 74,=20 >>>>>>>>> 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, = 85,=20 >>>>>>>>> 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, = 102, 81,=20 >>>>>>>>> 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, = 66, 53,=20 >>>>>>>>> 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, = 70, 75,=20 >>>>>>>>> 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, = 69,=20 >>>>>>>>> 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, = 87, 51,=20 >>>>>>>>> 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, = 106, 100,=20 >>>>>>>>> 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, = 72,=20 >>>>>>>>> 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, = 56, 54,=20 >>>>>>>>> 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, = 80, 74,=20 >>>>>>>>> 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, = 89,=20 >>>>>>>>> 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, = 122,=20 >>>>>>>>> 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, = 106,=20 >>>>>>>>> 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, = 67, 119,=20 >>>>>>>>> 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, = 79, 57,=20 >>>>>>>>> 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, = 72,=20 >>>>>>>>> 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, = 102,=20 >>>>>>>>> 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, = 84, 51,=20 >>>>>>>>> 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, = 45, 97,=20 >>>>>>>>> 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, = 81, 99,=20 >>>>>>>>> 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, = 77, 80,=20 >>>>>>>>> 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, = 113, 113,=20 >>>>>>>>> 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, = 97, 85,=20 >>>>>>>>> 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] Ciphertext = [253,=20 >>>>>>>>> 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, = 246,=20 >>>>>>>>> 116, 195, 212, 102, 37, 36, 175] Encoded Ciphertext=20 >>>>>>>>> _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag (Integrity = Value)=20 >>>>>>>>> [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, = 233, 114,=20 >>>>>>>>> 139] Encoded Authentication Tag (Encoded Integrity >>>>>>>>> Value) YbZSeHCNDZBqAdzpROlyiw JWE >>>>>>>>> = eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTM >>>>>>>>> = DRVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30 >>>>>>>>> = W3YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva >>>>>>>>> = w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCf >>>>>>>>> = lYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD- >>>>>>>>> = abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaN >>>>>>>>> Al5FjEQ._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> jose mailing list >>>>>>>>> jose@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>=20 >>=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose