Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D862521F8758 for ; Mon, 15 Oct 2012 23:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZwiWDNwzj0e for ; Mon, 15 Oct 2012 23:59:12 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4F13921F8750 for ; Mon, 15 Oct 2012 23:59:10 -0700 (PDT) Received: from mail31-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 06:59:09 +0000 Received: from mail31-am1 (localhost [127.0.0.1]) by mail31-am1-R.bigfish.com (Postfix) with ESMTP id B2451A02C9 for ; Tue, 16 Oct 2012 06:59:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail31-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1 (MessageSwitch) id 1350370746406674_25753; Tue, 16 Oct 2012 06:59:06 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.230]) by mail31-am1.bigfish.com (Postfix) with ESMTP id 60418400049 for ; Tue, 16 Oct 2012 06:59:06 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 06:59:06 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 06:59:02 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JOSE and JWT specs incorporating working group decisions since IETF 84 Thread-Index: Ac2ra69SDtelvfepRBCO1gAjjbxxsQ== Date: Tue, 16 Oct 2012 06:59:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] JOSE and JWT specs incorporating working group decisions since IETF 84 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:59:17 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (J= WS, JWE, JWK, JWA, JWT) specifications have been released. These versions = incorporate the decisions made by the JOSE working group during and since IETF 84. The primary change was revising the JWE format to always use AEAD encryptio= n algorithms. The companion change was defining two new composite AEAD alg= orithms "A128CBC+HS256" and "A256CBC+HS512" that use AES CBC to perform enc= ryption and matching HMAC SHA-2 algorithms to perform an integrity check on= the ciphertext and the parameters used to create it. Other than that, all changes were local in scope, with no changes to JWS - = other than changing the format of the "x5c" (X.509 Certificate Chain) from = a string containing a list of certificate values to an array of strings con= taining certificate values. Likewise, the only changes to JWT were to trac= k changes made in the specs that it uses. Having addressed all the open issues with resolutions with apparent working= group consensus, it's my hope that the working group will decide to send t= hese specifications to working group last call at IETF 85. The companion JWS JSON Serialization and JWE JSON Serialization specs were = also updated. The working group specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04 The individual submission specifications are available at: * http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization= -02 * http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization= -02 The document history entries (also in the specifications) are as follows: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06 * Changed x5c (X.509 Certificate Chain) representation from being a sin= gle string to being an array of strings, each containing a single base64 en= coded DER certificate value, representing elements of the certificate chain= . * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06 * Removed the int and kdf parameters and defined the new composite AEAD= algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of A= ES CBC, which required the use of separate integrity and key derivation fun= ctions. * Included additional values in the Concat KDF calculation -- the desir= ed output size and the algorithm value, and optionally PartyUInfo and Party= VInfo values. Added the optional header parameters apu (agreement PartyUInf= o), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encry= ption PartyVInfo). Updated the KDF examples accordingly. * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. * Changed x5c (X.509 Certificate Chain) representation from being a sin= gle string to being an array of strings, each containing a single base64 en= coded DER certificate value, representing elements of the certificate chain= . * Added an AES Key Wrap example. * Reordered the encryption steps so CMK creation is first, when require= d. * Correct statements in examples about which algorithms produce reprodu= cible results. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 * Changed the name of the JWK RSA exponent parameter from exp to xpo so= as to allow the potential use of the name exp for a future extension that = might define an expiration parameter for keys. (The exp name is already use= d for this purpose in the JWT specification.) * Clarify that the alg (algorithm family) member is REQUIRED. * Correct an instance of "JWK" that should have been "JWK Set". * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06 * Removed the int and kdf parameters and defined the new composite AEAD= algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of A= ES CBC, which required the use of separate integrity and key derivation fun= ctions. * Included additional values in the Concat KDF calculation -- the desir= ed output size and the algorithm value, and optionally PartyUInfo and Party= VInfo values. Added the optional header parameters apu (agreement PartyUInf= o), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encry= ption PartyVInfo). * Changed the name of the JWK RSA exponent parameter from exp to xpo so= as to allow the potential use of the name exp for a future extension that = might define an expiration parameter for keys. (The exp name is already use= d for this purpose in the JWT specification.) * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04 * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. * Reference RFC 6755 -- An IETF URN Sub-Namespace for OAuth. http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-02 * Changed to use an array of structures for per-recipient values, rathe= r than a set of parallel arrays. http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-02 * Changed to use an array of structures for per-recipient values, rathe= r than a set of parallel arrays. * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-06= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0= 6.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-06.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0= 6.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-04.ht= ml * http://self-issued.info/docs/draft-jones-jose-jws-json-serializati= on-02.html * http://self-issued.info/docs/draft-jones-jose-jwe-json-serializati= on-02.html -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

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

 

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

 

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

 

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

 

The working group specifications are available at:

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

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

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

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

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

 

The individual submission specifications are availab= le at:

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

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

 

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

HTML formatted versions are available at:=

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

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

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

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

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

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

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

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366853BB5TK5EX14MBXC284r_--